* [PATCH 0/3] thermal: bcm281xx: Add thermal driver
@ 2013-09-23 17:51 Wendy Ng
2013-09-23 17:51 ` [PATCH 1/3] " Wendy Ng
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Wendy Ng @ 2013-09-23 17:51 UTC (permalink / raw)
To: Rob Herring, Stephen Warren
Cc: devicetree, linux-kernel, linux-pm, Christian Daudt, Markus Mayer,
Wendy Ng
This patch series adds the support of the thermal driver for Broadcom
bcm281xx family of SoCs.
Wendy Ng (3):
thermal: bcm281xx: Add thermal driver
ARM: bcm281xx: Turn on Thermal and HWMON drivers.
ARM: bcm281xx: Add thermal driver to device tree.
.../bindings/thermal/bcm-kona-thermal.txt | 18 +++
arch/arm/boot/dts/bcm11351-brt.dts | 4 +-
arch/arm/boot/dts/bcm11351.dtsi | 6 +
arch/arm/boot/dts/bcm28155-ap.dts | 4 +
arch/arm/configs/bcm_defconfig | 3 +-
drivers/thermal/Kconfig | 10 ++
drivers/thermal/Makefile | 1 +
drivers/thermal/bcm_thermal.c | 170 ++++++++++++++++++++
8 files changed, 214 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt
create mode 100644 drivers/thermal/bcm_thermal.c
--
1.7.9.5
^ permalink raw reply [flat|nested] 15+ messages in thread* [PATCH 1/3] thermal: bcm281xx: Add thermal driver 2013-09-23 17:51 [PATCH 0/3] thermal: bcm281xx: Add thermal driver Wendy Ng @ 2013-09-23 17:51 ` Wendy Ng 2013-09-23 18:19 ` Eduardo Valentin 2013-09-25 19:26 ` Matt Porter 2013-09-23 17:51 ` [PATCH 2/3] ARM: bcm281xx: Turn on Thermal and HWMON drivers Wendy Ng 2013-09-23 17:51 ` [PATCH 3/3] ARM: bcm281xx: Add thermal driver to device tree Wendy Ng 2 siblings, 2 replies; 15+ messages in thread From: Wendy Ng @ 2013-09-23 17:51 UTC (permalink / raw) To: Rob Herring, Stephen Warren Cc: devicetree, linux-kernel, linux-pm, Christian Daudt, Markus Mayer, Wendy Ng This adds the support for reading out temperature from Broadcom bcm281xx SoCs. Signed-off-by: Wendy Ng <wendy.ng@broadcom.com> Reviewed-by: Markus Mayer <mmayer@broadcom.com> Reviewed-by: Christian Daudt <csd@broadcom.com> --- .../bindings/thermal/bcm-kona-thermal.txt | 18 +++ drivers/thermal/Kconfig | 10 ++ drivers/thermal/Makefile | 1 + drivers/thermal/bcm_thermal.c | 170 ++++++++++++++++++++ 4 files changed, 199 insertions(+) create mode 100644 Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt create mode 100644 drivers/thermal/bcm_thermal.c diff --git a/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt new file mode 100644 index 0000000..acca99e --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt @@ -0,0 +1,18 @@ +* Broadcom Kona Thermal Management Unit + +This version is for the BCM281xx family of SoCs. + +Required properties: +- compatible : "brcm,bcm11351-thermal", "brcm,kona-thermal" +- reg : Address range of the thermal register +- thermal-name: this entry must be specified and it will be passed into +thermal_zone_device_register(). This name will also be reported under Hwmon +sysfs 'name' attribute. + +Example: + thermal@34008000 { + compatible = "brcm,bcm11351-thermal", "brcm,kona-thermal"; + reg = <0x34008000 0x0024>; + thermal-name = "bcm_kona_therm"; + status = "disabled"; + }; diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig index dbfc390..7f823f0 100644 --- a/drivers/thermal/Kconfig +++ b/drivers/thermal/Kconfig @@ -134,6 +134,16 @@ config KIRKWOOD_THERMAL Support for the Kirkwood thermal sensor driver into the Linux thermal framework. Only kirkwood 88F6282 and 88F6283 have this sensor. +config BCM_THERMAL + tristate "Temperature sensor on Broadcom BCM281xx family of SoCs" + depends on ARCH_BCM + default y + help + If you say yes here you get support for TMU (Thermal Management + Unit) on Broadcom BCM281xx family of SoCs. This provides thermal + monitoring of CPU clusters, graphics, and SoC glue, but does not + include monitoring of charger temperature. + config DOVE_THERMAL tristate "Temperature sensor on Marvell Dove SoCs" depends on ARCH_DOVE diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile index 584b363..3ea8c1c 100644 --- a/drivers/thermal/Makefile +++ b/drivers/thermal/Makefile @@ -21,6 +21,7 @@ obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o obj-y += samsung/ +obj-$(CONFIG_BCM_THERMAL) += bcm_thermal.o obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o diff --git a/drivers/thermal/bcm_thermal.c b/drivers/thermal/bcm_thermal.c new file mode 100644 index 0000000..131d3c4 --- /dev/null +++ b/drivers/thermal/bcm_thermal.c @@ -0,0 +1,170 @@ +/* + * Copyright 2013 Broadcom Corporation. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License, version 2, + * as published by the Free Software Foundation (the "GPL"). + * + * 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. + * + * A copy of the GPL is available at http://www.broadcom.com/licenses/GPLv2.php, + * or by writing to the Free Software Foundation, Inc., + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + */ + +/** +* Broadcom Thermal Management Unit - bcm_tmu +*/ +#include <linux/module.h> +#include <linux/err.h> +#include <linux/kernel.h> +#include <linux/platform_device.h> +#include <linux/io.h> +#include <linux/thermal.h> +#include <linux/of.h> + +/* From TMON Register Database */ +#define TMON_TEMP_VAL_OFFSET 0x0000001c +#define TMON_TEMP_VAL_TEMP_VAL_SHIFT 0 +#define TMON_TEMP_VAL_TEMP_VAL_MASK 0x000003ff + +/* Broadcom Thermal Zone Device Structure */ +struct bcm_thermal_zone_priv { + char name[THERMAL_NAME_LENGTH]; + void __iomem *base; +}; + +/* Temperature conversion function for TMON block */ +static long raw_to_mcelsius(u32 raw) +{ + /* + * According to Broadcom internal Analog Module Specification + * the formula for converting TMON block output to temperature in + * degree Celsius is: + * T = 428 - (0.561 * raw) + * Note: the valid operating range for the TMON block is -40C to 125C + */ + return 428000 - (561 * (long)raw); +} + +/* Get temperature callback function for thermal zone */ +static int bcm_get_temp(struct thermal_zone_device *thermal, + unsigned long *temp) +{ + u32 raw; + long mcelsius; + struct bcm_thermal_zone_priv *priv = thermal->devdata; + + if (!priv) { + pr_err("%s: thermal zone number %d devdata not initialized.\n", + __func__, thermal->id); + return -EINVAL; + } + + raw = (readl(priv->base + TMON_TEMP_VAL_OFFSET) + & TMON_TEMP_VAL_TEMP_VAL_MASK) >> TMON_TEMP_VAL_TEMP_VAL_SHIFT; + + pr_debug("%s: thermal zone number %d raw temp 0x%x\n", __func__, + thermal->id, raw); + + mcelsius = raw_to_mcelsius(raw); + + /* + * Since 'mcelsius' might be negative, we need to limit it to smallest + * unsigned value before returning it to thermal framework. + */ + if (mcelsius < 0) + *temp = 0; + else + *temp = mcelsius; + + pr_debug("%s: thermal zone number %d final temp %d\n", __func__, + thermal->id, (int) *temp); + + return 0; +} + +/* Operation callback functions for thermal zone */ +static struct thermal_zone_device_ops bcm_dev_ops = { + .get_temp = bcm_get_temp, +}; + +static const struct of_device_id bcm_tmu_match_table[] = { + { .compatible = "brcm,kona-thermal" }, + {}, +}; +MODULE_DEVICE_TABLE(of, bcm_tmu_match_table); + +static int bcm_tmu_probe(struct platform_device *pdev) +{ + struct thermal_zone_device *thermal = NULL; + struct bcm_thermal_zone_priv *priv; + struct resource *res; + const char *str; + + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); + if (!priv) { + dev_err(&pdev->dev, "Failed to malloc priv.\n"); + return -ENOMEM; + } + + /* Obtain the tmu name from device tree file */ + if (of_property_read_string(pdev->dev.of_node, "thermal-name", + &str) == 0) { + strlcpy(priv->name, str, sizeof(priv->name)); + } else { + dev_err(&pdev->dev, "Failed to get thermal-name from DT.\n"); + return -EINVAL; + } + + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); + priv->base = devm_ioremap_resource(&pdev->dev, res); + if (IS_ERR(priv->base)) + return PTR_ERR(priv->base); + + thermal = thermal_zone_device_register(priv->name, 0, 0, priv, + &bcm_dev_ops, NULL, 0, 0); + if (IS_ERR(thermal)) { + dev_err(&pdev->dev, + "Failed to register Broadcom thermal zone device.\n"); + return PTR_ERR(thermal); + } + + platform_set_drvdata(pdev, thermal); + + dev_info(&pdev->dev, "Broadcom Thermal Monitor Initialized.\n"); + + return 0; +} + +static int bcm_tmu_remove(struct platform_device *pdev) +{ + struct thermal_zone_device *broadcom_thermal = + platform_get_drvdata(pdev); + + thermal_zone_device_unregister(broadcom_thermal); + + dev_info(&pdev->dev, "Broadcom Thermal Monitor Uninitialized.\n"); + + return 0; +} + +static struct platform_driver bcm_tmu_driver = { + .driver = { + .name = "bcm-thermal", + .owner = THIS_MODULE, + .of_match_table = bcm_tmu_match_table, + }, + .probe = bcm_tmu_probe, + .remove = bcm_tmu_remove, +}; + +module_platform_driver(bcm_tmu_driver); + +MODULE_DESCRIPTION("Broadcom Thermal Driver"); +MODULE_AUTHOR("Broadcom"); +MODULE_LICENSE("GPL v2"); +MODULE_ALIAS("platform:bcm-thermal"); -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH 1/3] thermal: bcm281xx: Add thermal driver 2013-09-23 17:51 ` [PATCH 1/3] " Wendy Ng @ 2013-09-23 18:19 ` Eduardo Valentin 2013-09-23 22:43 ` Wendy Ng 2013-09-25 19:26 ` Matt Porter 1 sibling, 1 reply; 15+ messages in thread From: Eduardo Valentin @ 2013-09-23 18:19 UTC (permalink / raw) To: Wendy Ng, Mark Rutland Cc: Rob Herring, Stephen Warren, devicetree, linux-kernel, linux-pm, Christian Daudt, Markus Mayer, eduardo.valentin [-- Attachment #1: Type: text/plain, Size: 9102 bytes --] On 23-09-2013 13:51, Wendy Ng wrote: > This adds the support for reading out temperature from Broadcom bcm281xx > SoCs. > > Signed-off-by: Wendy Ng <wendy.ng@broadcom.com> > Reviewed-by: Markus Mayer <mmayer@broadcom.com> > Reviewed-by: Christian Daudt <csd@broadcom.com> > --- > .../bindings/thermal/bcm-kona-thermal.txt | 18 +++ > drivers/thermal/Kconfig | 10 ++ > drivers/thermal/Makefile | 1 + > drivers/thermal/bcm_thermal.c | 170 ++++++++++++++++++++ > 4 files changed, 199 insertions(+) > create mode 100644 Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt > create mode 100644 drivers/thermal/bcm_thermal.c > > diff --git a/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt > new file mode 100644 > index 0000000..acca99e > --- /dev/null > +++ b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt > @@ -0,0 +1,18 @@ > +* Broadcom Kona Thermal Management Unit > + > +This version is for the BCM281xx family of SoCs. > + > +Required properties: > +- compatible : "brcm,bcm11351-thermal", "brcm,kona-thermal" > +- reg : Address range of the thermal register > +- thermal-name: this entry must be specified and it will be passed into > +thermal_zone_device_register(). This name will also be reported under Hwmon > +sysfs 'name' attribute. > + > +Example: > + thermal@34008000 { > + compatible = "brcm,bcm11351-thermal", "brcm,kona-thermal"; > + reg = <0x34008000 0x0024>; > + thermal-name = "bcm_kona_therm"; > + status = "disabled"; > + }; > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig > index dbfc390..7f823f0 100644 > --- a/drivers/thermal/Kconfig > +++ b/drivers/thermal/Kconfig > @@ -134,6 +134,16 @@ config KIRKWOOD_THERMAL > Support for the Kirkwood thermal sensor driver into the Linux thermal > framework. Only kirkwood 88F6282 and 88F6283 have this sensor. > > +config BCM_THERMAL > + tristate "Temperature sensor on Broadcom BCM281xx family of SoCs" > + depends on ARCH_BCM > + default y > + help > + If you say yes here you get support for TMU (Thermal Management > + Unit) on Broadcom BCM281xx family of SoCs. This provides thermal > + monitoring of CPU clusters, graphics, and SoC glue, but does not > + include monitoring of charger temperature. > + > config DOVE_THERMAL > tristate "Temperature sensor on Marvell Dove SoCs" > depends on ARCH_DOVE > diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile > index 584b363..3ea8c1c 100644 > --- a/drivers/thermal/Makefile > +++ b/drivers/thermal/Makefile > @@ -21,6 +21,7 @@ obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o > obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o > obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o > obj-y += samsung/ > +obj-$(CONFIG_BCM_THERMAL) += bcm_thermal.o > obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o > obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o > obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o > diff --git a/drivers/thermal/bcm_thermal.c b/drivers/thermal/bcm_thermal.c > new file mode 100644 > index 0000000..131d3c4 > --- /dev/null > +++ b/drivers/thermal/bcm_thermal.c > @@ -0,0 +1,170 @@ > +/* > + * Copyright 2013 Broadcom Corporation. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License, version 2, > + * as published by the Free Software Foundation (the "GPL"). > + * > + * 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. > + * > + * A copy of the GPL is available at http://www.broadcom.com/licenses/GPLv2.php, > + * or by writing to the Free Software Foundation, Inc., > + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. > + */ > + > +/** > +* Broadcom Thermal Management Unit - bcm_tmu > +*/ > +#include <linux/module.h> > +#include <linux/err.h> > +#include <linux/kernel.h> > +#include <linux/platform_device.h> > +#include <linux/io.h> > +#include <linux/thermal.h> > +#include <linux/of.h> > + > +/* From TMON Register Database */ > +#define TMON_TEMP_VAL_OFFSET 0x0000001c > +#define TMON_TEMP_VAL_TEMP_VAL_SHIFT 0 > +#define TMON_TEMP_VAL_TEMP_VAL_MASK 0x000003ff > + > +/* Broadcom Thermal Zone Device Structure */ > +struct bcm_thermal_zone_priv { > + char name[THERMAL_NAME_LENGTH]; > + void __iomem *base; > +}; > + > +/* Temperature conversion function for TMON block */ > +static long raw_to_mcelsius(u32 raw) > +{ > + /* > + * According to Broadcom internal Analog Module Specification > + * the formula for converting TMON block output to temperature in > + * degree Celsius is: > + * T = 428 - (0.561 * raw) > + * Note: the valid operating range for the TMON block is -40C to 125C > + */ > + return 428000 - (561 * (long)raw); > +} > + > +/* Get temperature callback function for thermal zone */ > +static int bcm_get_temp(struct thermal_zone_device *thermal, > + unsigned long *temp) > +{ > + u32 raw; > + long mcelsius; > + struct bcm_thermal_zone_priv *priv = thermal->devdata; > + > + if (!priv) { > + pr_err("%s: thermal zone number %d devdata not initialized.\n", > + __func__, thermal->id); > + return -EINVAL; > + } > + > + raw = (readl(priv->base + TMON_TEMP_VAL_OFFSET) > + & TMON_TEMP_VAL_TEMP_VAL_MASK) >> TMON_TEMP_VAL_TEMP_VAL_SHIFT; > + > + pr_debug("%s: thermal zone number %d raw temp 0x%x\n", __func__, > + thermal->id, raw); > + > + mcelsius = raw_to_mcelsius(raw); > + > + /* > + * Since 'mcelsius' might be negative, we need to limit it to smallest > + * unsigned value before returning it to thermal framework. > + */ > + if (mcelsius < 0) > + *temp = 0; > + else > + *temp = mcelsius; > + > + pr_debug("%s: thermal zone number %d final temp %d\n", __func__, > + thermal->id, (int) *temp); > + > + return 0; > +} > + > +/* Operation callback functions for thermal zone */ > +static struct thermal_zone_device_ops bcm_dev_ops = { > + .get_temp = bcm_get_temp, > +}; > + > +static const struct of_device_id bcm_tmu_match_table[] = { > + { .compatible = "brcm,kona-thermal" }, > + {}, > +}; > +MODULE_DEVICE_TABLE(of, bcm_tmu_match_table); > + > +static int bcm_tmu_probe(struct platform_device *pdev) > +{ > + struct thermal_zone_device *thermal = NULL; > + struct bcm_thermal_zone_priv *priv; > + struct resource *res; > + const char *str; > + > + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); > + if (!priv) { > + dev_err(&pdev->dev, "Failed to malloc priv.\n"); > + return -ENOMEM; > + } > + > + /* Obtain the tmu name from device tree file */ > + if (of_property_read_string(pdev->dev.of_node, "thermal-name", Hello Wendy, I would prefer we wait until the work for thermal data [1] gets accepted before accepting this driver, specially because you are adding device specific DT entry to help in your registration with the thermal framework. With the mentioned work you wont need it at all. All best, [1] - http://lkml.org/lkml/2013/9/15/122 > + &str) == 0) { > + strlcpy(priv->name, str, sizeof(priv->name)); > + } else { > + dev_err(&pdev->dev, "Failed to get thermal-name from DT.\n"); > + return -EINVAL; > + } > + > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); > + priv->base = devm_ioremap_resource(&pdev->dev, res); > + if (IS_ERR(priv->base)) > + return PTR_ERR(priv->base); > + > + thermal = thermal_zone_device_register(priv->name, 0, 0, priv, > + &bcm_dev_ops, NULL, 0, 0); > + if (IS_ERR(thermal)) { > + dev_err(&pdev->dev, > + "Failed to register Broadcom thermal zone device.\n"); > + return PTR_ERR(thermal); > + } > + > + platform_set_drvdata(pdev, thermal); > + > + dev_info(&pdev->dev, "Broadcom Thermal Monitor Initialized.\n"); > + > + return 0; > +} > + > +static int bcm_tmu_remove(struct platform_device *pdev) > +{ > + struct thermal_zone_device *broadcom_thermal = > + platform_get_drvdata(pdev); > + > + thermal_zone_device_unregister(broadcom_thermal); > + > + dev_info(&pdev->dev, "Broadcom Thermal Monitor Uninitialized.\n"); > + > + return 0; > +} > + > +static struct platform_driver bcm_tmu_driver = { > + .driver = { > + .name = "bcm-thermal", > + .owner = THIS_MODULE, > + .of_match_table = bcm_tmu_match_table, > + }, > + .probe = bcm_tmu_probe, > + .remove = bcm_tmu_remove, > +}; > + > +module_platform_driver(bcm_tmu_driver); > + > +MODULE_DESCRIPTION("Broadcom Thermal Driver"); > +MODULE_AUTHOR("Broadcom"); > +MODULE_LICENSE("GPL v2"); > +MODULE_ALIAS("platform:bcm-thermal"); > -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 295 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/3] thermal: bcm281xx: Add thermal driver 2013-09-23 18:19 ` Eduardo Valentin @ 2013-09-23 22:43 ` Wendy Ng 2013-09-23 23:46 ` Eduardo Valentin 0 siblings, 1 reply; 15+ messages in thread From: Wendy Ng @ 2013-09-23 22:43 UTC (permalink / raw) To: Eduardo Valentin, Mark Rutland Cc: Rob Herring, Stephen Warren, devicetree, linux-kernel, linux-pm, Christian Daudt, Markus Mayer On 9/23/2013 11:19 AM, Eduardo Valentin wrote: > On 23-09-2013 13:51, Wendy Ng wrote: >> This adds the support for reading out temperature from Broadcom bcm281xx >> SoCs. >> >> Signed-off-by: Wendy Ng <wendy.ng@broadcom.com> >> Reviewed-by: Markus Mayer <mmayer@broadcom.com> >> Reviewed-by: Christian Daudt <csd@broadcom.com> >> --- >> .../bindings/thermal/bcm-kona-thermal.txt | 18 +++ >> drivers/thermal/Kconfig | 10 ++ >> drivers/thermal/Makefile | 1 + >> drivers/thermal/bcm_thermal.c | 170 ++++++++++++++++++++ >> 4 files changed, 199 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >> create mode 100644 drivers/thermal/bcm_thermal.c >> >> diff --git a/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >> new file mode 100644 >> index 0000000..acca99e >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >> @@ -0,0 +1,18 @@ >> +* Broadcom Kona Thermal Management Unit >> + >> +This version is for the BCM281xx family of SoCs. >> + >> +Required properties: >> +- compatible : "brcm,bcm11351-thermal", "brcm,kona-thermal" >> +- reg : Address range of the thermal register >> +- thermal-name: this entry must be specified and it will be passed into >> +thermal_zone_device_register(). This name will also be reported under Hwmon >> +sysfs 'name' attribute. >> + >> +Example: >> + thermal@34008000 { >> + compatible = "brcm,bcm11351-thermal", "brcm,kona-thermal"; >> + reg = <0x34008000 0x0024>; >> + thermal-name = "bcm_kona_therm"; >> + status = "disabled"; >> + }; >> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >> index dbfc390..7f823f0 100644 >> --- a/drivers/thermal/Kconfig >> +++ b/drivers/thermal/Kconfig >> @@ -134,6 +134,16 @@ config KIRKWOOD_THERMAL >> Support for the Kirkwood thermal sensor driver into the Linux thermal >> framework. Only kirkwood 88F6282 and 88F6283 have this sensor. >> >> +config BCM_THERMAL >> + tristate "Temperature sensor on Broadcom BCM281xx family of SoCs" >> + depends on ARCH_BCM >> + default y >> + help >> + If you say yes here you get support for TMU (Thermal Management >> + Unit) on Broadcom BCM281xx family of SoCs. This provides thermal >> + monitoring of CPU clusters, graphics, and SoC glue, but does not >> + include monitoring of charger temperature. >> + >> config DOVE_THERMAL >> tristate "Temperature sensor on Marvell Dove SoCs" >> depends on ARCH_DOVE >> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile >> index 584b363..3ea8c1c 100644 >> --- a/drivers/thermal/Makefile >> +++ b/drivers/thermal/Makefile >> @@ -21,6 +21,7 @@ obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o >> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o >> obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o >> obj-y += samsung/ >> +obj-$(CONFIG_BCM_THERMAL) += bcm_thermal.o >> obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o >> obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o >> obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o >> diff --git a/drivers/thermal/bcm_thermal.c b/drivers/thermal/bcm_thermal.c >> new file mode 100644 >> index 0000000..131d3c4 >> --- /dev/null >> +++ b/drivers/thermal/bcm_thermal.c >> @@ -0,0 +1,170 @@ >> +/* >> + * Copyright 2013 Broadcom Corporation. >> + * >> + * This program is free software; you can redistribute it and/or modify >> + * it under the terms of the GNU General Public License, version 2, >> + * as published by the Free Software Foundation (the "GPL"). >> + * >> + * 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. >> + * >> + * A copy of the GPL is available at http://www.broadcom.com/licenses/GPLv2.php, >> + * or by writing to the Free Software Foundation, Inc., >> + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. >> + */ >> + >> +/** >> +* Broadcom Thermal Management Unit - bcm_tmu >> +*/ >> +#include <linux/module.h> >> +#include <linux/err.h> >> +#include <linux/kernel.h> >> +#include <linux/platform_device.h> >> +#include <linux/io.h> >> +#include <linux/thermal.h> >> +#include <linux/of.h> >> + >> +/* From TMON Register Database */ >> +#define TMON_TEMP_VAL_OFFSET 0x0000001c >> +#define TMON_TEMP_VAL_TEMP_VAL_SHIFT 0 >> +#define TMON_TEMP_VAL_TEMP_VAL_MASK 0x000003ff >> + >> +/* Broadcom Thermal Zone Device Structure */ >> +struct bcm_thermal_zone_priv { >> + char name[THERMAL_NAME_LENGTH]; >> + void __iomem *base; >> +}; >> + >> +/* Temperature conversion function for TMON block */ >> +static long raw_to_mcelsius(u32 raw) >> +{ >> + /* >> + * According to Broadcom internal Analog Module Specification >> + * the formula for converting TMON block output to temperature in >> + * degree Celsius is: >> + * T = 428 - (0.561 * raw) >> + * Note: the valid operating range for the TMON block is -40C to 125C >> + */ >> + return 428000 - (561 * (long)raw); >> +} >> + >> +/* Get temperature callback function for thermal zone */ >> +static int bcm_get_temp(struct thermal_zone_device *thermal, >> + unsigned long *temp) >> +{ >> + u32 raw; >> + long mcelsius; >> + struct bcm_thermal_zone_priv *priv = thermal->devdata; >> + >> + if (!priv) { >> + pr_err("%s: thermal zone number %d devdata not initialized.\n", >> + __func__, thermal->id); >> + return -EINVAL; >> + } >> + >> + raw = (readl(priv->base + TMON_TEMP_VAL_OFFSET) >> + & TMON_TEMP_VAL_TEMP_VAL_MASK) >> TMON_TEMP_VAL_TEMP_VAL_SHIFT; >> + >> + pr_debug("%s: thermal zone number %d raw temp 0x%x\n", __func__, >> + thermal->id, raw); >> + >> + mcelsius = raw_to_mcelsius(raw); >> + >> + /* >> + * Since 'mcelsius' might be negative, we need to limit it to smallest >> + * unsigned value before returning it to thermal framework. >> + */ >> + if (mcelsius < 0) >> + *temp = 0; >> + else >> + *temp = mcelsius; >> + >> + pr_debug("%s: thermal zone number %d final temp %d\n", __func__, >> + thermal->id, (int) *temp); >> + >> + return 0; >> +} >> + >> +/* Operation callback functions for thermal zone */ >> +static struct thermal_zone_device_ops bcm_dev_ops = { >> + .get_temp = bcm_get_temp, >> +}; >> + >> +static const struct of_device_id bcm_tmu_match_table[] = { >> + { .compatible = "brcm,kona-thermal" }, >> + {}, >> +}; >> +MODULE_DEVICE_TABLE(of, bcm_tmu_match_table); >> + >> +static int bcm_tmu_probe(struct platform_device *pdev) >> +{ >> + struct thermal_zone_device *thermal = NULL; >> + struct bcm_thermal_zone_priv *priv; >> + struct resource *res; >> + const char *str; >> + >> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); >> + if (!priv) { >> + dev_err(&pdev->dev, "Failed to malloc priv.\n"); >> + return -ENOMEM; >> + } >> + >> + /* Obtain the tmu name from device tree file */ >> + if (of_property_read_string(pdev->dev.of_node, "thermal-name", > Hello Wendy, > > I would prefer we wait until the work for thermal data [1] gets accepted > before accepting this driver, specially because you are adding device > specific DT entry to help in your registration with the thermal > framework. With the mentioned work you wont need it at all. > > All best, > > [1] - http://lkml.org/lkml/2013/9/15/122 Hello Eduardo, Since your changes are quite extensive, would you recommend me to get your 16 patches into my local workspace and try to integrate the code from my patches on the top of your patches at this time? Or should I wait until your patches get accepted. Thanks, -Wendy >> + &str) == 0) { >> + strlcpy(priv->name, str, sizeof(priv->name)); >> + } else { >> + dev_err(&pdev->dev, "Failed to get thermal-name from DT.\n"); >> + return -EINVAL; >> + } >> + >> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); >> + priv->base = devm_ioremap_resource(&pdev->dev, res); >> + if (IS_ERR(priv->base)) >> + return PTR_ERR(priv->base); >> + >> + thermal = thermal_zone_device_register(priv->name, 0, 0, priv, >> + &bcm_dev_ops, NULL, 0, 0); >> + if (IS_ERR(thermal)) { >> + dev_err(&pdev->dev, >> + "Failed to register Broadcom thermal zone device.\n"); >> + return PTR_ERR(thermal); >> + } >> + >> + platform_set_drvdata(pdev, thermal); >> + >> + dev_info(&pdev->dev, "Broadcom Thermal Monitor Initialized.\n"); >> + >> + return 0; >> +} >> + >> +static int bcm_tmu_remove(struct platform_device *pdev) >> +{ >> + struct thermal_zone_device *broadcom_thermal = >> + platform_get_drvdata(pdev); >> + >> + thermal_zone_device_unregister(broadcom_thermal); >> + >> + dev_info(&pdev->dev, "Broadcom Thermal Monitor Uninitialized.\n"); >> + >> + return 0; >> +} >> + >> +static struct platform_driver bcm_tmu_driver = { >> + .driver = { >> + .name = "bcm-thermal", >> + .owner = THIS_MODULE, >> + .of_match_table = bcm_tmu_match_table, >> + }, >> + .probe = bcm_tmu_probe, >> + .remove = bcm_tmu_remove, >> +}; >> + >> +module_platform_driver(bcm_tmu_driver); >> + >> +MODULE_DESCRIPTION("Broadcom Thermal Driver"); >> +MODULE_AUTHOR("Broadcom"); >> +MODULE_LICENSE("GPL v2"); >> +MODULE_ALIAS("platform:bcm-thermal"); >> > -- -Wendy ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/3] thermal: bcm281xx: Add thermal driver 2013-09-23 22:43 ` Wendy Ng @ 2013-09-23 23:46 ` Eduardo Valentin 2013-10-04 22:17 ` Wendy Ng 0 siblings, 1 reply; 15+ messages in thread From: Eduardo Valentin @ 2013-09-23 23:46 UTC (permalink / raw) To: Wendy Ng Cc: Eduardo Valentin, Mark Rutland, Rob Herring, Stephen Warren, devicetree, linux-kernel, linux-pm, Christian Daudt, Markus Mayer [-- Attachment #1: Type: text/plain, Size: 11129 bytes --] On 23-09-2013 18:43, Wendy Ng wrote: > > On 9/23/2013 11:19 AM, Eduardo Valentin wrote: >> On 23-09-2013 13:51, Wendy Ng wrote: >>> This adds the support for reading out temperature from Broadcom bcm281xx >>> SoCs. >>> >>> Signed-off-by: Wendy Ng <wendy.ng@broadcom.com> >>> Reviewed-by: Markus Mayer <mmayer@broadcom.com> >>> Reviewed-by: Christian Daudt <csd@broadcom.com> >>> --- >>> .../bindings/thermal/bcm-kona-thermal.txt | 18 +++ >>> drivers/thermal/Kconfig | 10 ++ >>> drivers/thermal/Makefile | 1 + >>> drivers/thermal/bcm_thermal.c | 170 >>> ++++++++++++++++++++ >>> 4 files changed, 199 insertions(+) >>> create mode 100644 >>> Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>> create mode 100644 drivers/thermal/bcm_thermal.c >>> >>> diff --git >>> a/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>> b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>> new file mode 100644 >>> index 0000000..acca99e >>> --- /dev/null >>> +++ b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>> @@ -0,0 +1,18 @@ >>> +* Broadcom Kona Thermal Management Unit >>> + >>> +This version is for the BCM281xx family of SoCs. >>> + >>> +Required properties: >>> +- compatible : "brcm,bcm11351-thermal", "brcm,kona-thermal" >>> +- reg : Address range of the thermal register >>> +- thermal-name: this entry must be specified and it will be passed into >>> +thermal_zone_device_register(). This name will also be reported >>> under Hwmon >>> +sysfs 'name' attribute. >>> + >>> +Example: >>> + thermal@34008000 { >>> + compatible = "brcm,bcm11351-thermal", "brcm,kona-thermal"; >>> + reg = <0x34008000 0x0024>; >>> + thermal-name = "bcm_kona_therm"; >>> + status = "disabled"; >>> + }; >>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >>> index dbfc390..7f823f0 100644 >>> --- a/drivers/thermal/Kconfig >>> +++ b/drivers/thermal/Kconfig >>> @@ -134,6 +134,16 @@ config KIRKWOOD_THERMAL >>> Support for the Kirkwood thermal sensor driver into the Linux >>> thermal >>> framework. Only kirkwood 88F6282 and 88F6283 have this sensor. >>> +config BCM_THERMAL >>> + tristate "Temperature sensor on Broadcom BCM281xx family of SoCs" >>> + depends on ARCH_BCM >>> + default y >>> + help >>> + If you say yes here you get support for TMU (Thermal Management >>> + Unit) on Broadcom BCM281xx family of SoCs. This provides thermal >>> + monitoring of CPU clusters, graphics, and SoC glue, but does not >>> + include monitoring of charger temperature. >>> + >>> config DOVE_THERMAL >>> tristate "Temperature sensor on Marvell Dove SoCs" >>> depends on ARCH_DOVE >>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile >>> index 584b363..3ea8c1c 100644 >>> --- a/drivers/thermal/Makefile >>> +++ b/drivers/thermal/Makefile >>> @@ -21,6 +21,7 @@ obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o >>> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o >>> obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o >>> obj-y += samsung/ >>> +obj-$(CONFIG_BCM_THERMAL) += bcm_thermal.o >>> obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o >>> obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o >>> obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o >>> diff --git a/drivers/thermal/bcm_thermal.c >>> b/drivers/thermal/bcm_thermal.c >>> new file mode 100644 >>> index 0000000..131d3c4 >>> --- /dev/null >>> +++ b/drivers/thermal/bcm_thermal.c >>> @@ -0,0 +1,170 @@ >>> +/* >>> + * Copyright 2013 Broadcom Corporation. >>> + * >>> + * This program is free software; you can redistribute it and/or modify >>> + * it under the terms of the GNU General Public License, version 2, >>> + * as published by the Free Software Foundation (the "GPL"). >>> + * >>> + * 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. >>> + * >>> + * A copy of the GPL is available at >>> http://www.broadcom.com/licenses/GPLv2.php, >>> + * or by writing to the Free Software Foundation, Inc., >>> + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. >>> + */ >>> + >>> +/** >>> +* Broadcom Thermal Management Unit - bcm_tmu >>> +*/ >>> +#include <linux/module.h> >>> +#include <linux/err.h> >>> +#include <linux/kernel.h> >>> +#include <linux/platform_device.h> >>> +#include <linux/io.h> >>> +#include <linux/thermal.h> >>> +#include <linux/of.h> >>> + >>> +/* From TMON Register Database */ >>> +#define TMON_TEMP_VAL_OFFSET 0x0000001c >>> +#define TMON_TEMP_VAL_TEMP_VAL_SHIFT 0 >>> +#define TMON_TEMP_VAL_TEMP_VAL_MASK 0x000003ff >>> + >>> +/* Broadcom Thermal Zone Device Structure */ >>> +struct bcm_thermal_zone_priv { >>> + char name[THERMAL_NAME_LENGTH]; >>> + void __iomem *base; >>> +}; >>> + >>> +/* Temperature conversion function for TMON block */ >>> +static long raw_to_mcelsius(u32 raw) >>> +{ >>> + /* >>> + * According to Broadcom internal Analog Module Specification >>> + * the formula for converting TMON block output to temperature in >>> + * degree Celsius is: >>> + * T = 428 - (0.561 * raw) >>> + * Note: the valid operating range for the TMON block is -40C to >>> 125C >>> + */ >>> + return 428000 - (561 * (long)raw); >>> +} >>> + >>> +/* Get temperature callback function for thermal zone */ >>> +static int bcm_get_temp(struct thermal_zone_device *thermal, >>> + unsigned long *temp) >>> +{ >>> + u32 raw; >>> + long mcelsius; >>> + struct bcm_thermal_zone_priv *priv = thermal->devdata; >>> + >>> + if (!priv) { >>> + pr_err("%s: thermal zone number %d devdata not initialized.\n", >>> + __func__, thermal->id); >>> + return -EINVAL; >>> + } >>> + >>> + raw = (readl(priv->base + TMON_TEMP_VAL_OFFSET) >>> + & TMON_TEMP_VAL_TEMP_VAL_MASK) >> TMON_TEMP_VAL_TEMP_VAL_SHIFT; >>> + >>> + pr_debug("%s: thermal zone number %d raw temp 0x%x\n", __func__, >>> + thermal->id, raw); >>> + >>> + mcelsius = raw_to_mcelsius(raw); >>> + >>> + /* >>> + * Since 'mcelsius' might be negative, we need to limit it to >>> smallest >>> + * unsigned value before returning it to thermal framework. >>> + */ >>> + if (mcelsius < 0) >>> + *temp = 0; >>> + else >>> + *temp = mcelsius; >>> + >>> + pr_debug("%s: thermal zone number %d final temp %d\n", __func__, >>> + thermal->id, (int) *temp); >>> + >>> + return 0; >>> +} >>> + >>> +/* Operation callback functions for thermal zone */ >>> +static struct thermal_zone_device_ops bcm_dev_ops = { >>> + .get_temp = bcm_get_temp, >>> +}; >>> + >>> +static const struct of_device_id bcm_tmu_match_table[] = { >>> + { .compatible = "brcm,kona-thermal" }, >>> + {}, >>> +}; >>> +MODULE_DEVICE_TABLE(of, bcm_tmu_match_table); >>> + >>> +static int bcm_tmu_probe(struct platform_device *pdev) >>> +{ >>> + struct thermal_zone_device *thermal = NULL; >>> + struct bcm_thermal_zone_priv *priv; >>> + struct resource *res; >>> + const char *str; >>> + >>> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); >>> + if (!priv) { >>> + dev_err(&pdev->dev, "Failed to malloc priv.\n"); >>> + return -ENOMEM; >>> + } >>> + >>> + /* Obtain the tmu name from device tree file */ >>> + if (of_property_read_string(pdev->dev.of_node, "thermal-name", >> Hello Wendy, >> >> I would prefer we wait until the work for thermal data [1] gets accepted >> before accepting this driver, specially because you are adding device >> specific DT entry to help in your registration with the thermal >> framework. With the mentioned work you wont need it at all. >> >> All best, >> >> [1] - http://lkml.org/lkml/2013/9/15/122 > Hello Eduardo, > > Since your changes are quite extensive, would you recommend me to get > your 16 patches into my local workspace and try to integrate the code > from my patches on the top of your patches at this time? Or should I > wait until your patches get accepted. Hello again Wendy, The only part I am concerned is the device tree entry you are creating for your device/driver. That could be obsolete in near future with the work I am doing currently. The work is, as you mentioned, quite extensive, but should make things easier for device driver writer. If you want, of course, it would be great if you could rebase your work on top of mine and try it out on your side and let me know the outcome. Comments on the proposed binding and documentation is also welcome. Let me know if there is something that it is not clear. > > Thanks, > -Wendy >>> + &str) == 0) { >>> + strlcpy(priv->name, str, sizeof(priv->name)); >>> + } else { >>> + dev_err(&pdev->dev, "Failed to get thermal-name from DT.\n"); >>> + return -EINVAL; >>> + } >>> + >>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>> + priv->base = devm_ioremap_resource(&pdev->dev, res); >>> + if (IS_ERR(priv->base)) >>> + return PTR_ERR(priv->base); >>> + >>> + thermal = thermal_zone_device_register(priv->name, 0, 0, priv, >>> + &bcm_dev_ops, NULL, 0, 0); >>> + if (IS_ERR(thermal)) { >>> + dev_err(&pdev->dev, >>> + "Failed to register Broadcom thermal zone device.\n"); >>> + return PTR_ERR(thermal); >>> + } >>> + >>> + platform_set_drvdata(pdev, thermal); >>> + >>> + dev_info(&pdev->dev, "Broadcom Thermal Monitor Initialized.\n"); >>> + >>> + return 0; >>> +} >>> + >>> +static int bcm_tmu_remove(struct platform_device *pdev) >>> +{ >>> + struct thermal_zone_device *broadcom_thermal = >>> + platform_get_drvdata(pdev); >>> + >>> + thermal_zone_device_unregister(broadcom_thermal); >>> + >>> + dev_info(&pdev->dev, "Broadcom Thermal Monitor Uninitialized.\n"); >>> + >>> + return 0; >>> +} >>> + >>> +static struct platform_driver bcm_tmu_driver = { >>> + .driver = { >>> + .name = "bcm-thermal", >>> + .owner = THIS_MODULE, >>> + .of_match_table = bcm_tmu_match_table, >>> + }, >>> + .probe = bcm_tmu_probe, >>> + .remove = bcm_tmu_remove, >>> +}; >>> + >>> +module_platform_driver(bcm_tmu_driver); >>> + >>> +MODULE_DESCRIPTION("Broadcom Thermal Driver"); >>> +MODULE_AUTHOR("Broadcom"); >>> +MODULE_LICENSE("GPL v2"); >>> +MODULE_ALIAS("platform:bcm-thermal"); >>> >> > -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 295 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/3] thermal: bcm281xx: Add thermal driver 2013-09-23 23:46 ` Eduardo Valentin @ 2013-10-04 22:17 ` Wendy Ng 2013-10-07 14:52 ` Eduardo Valentin 0 siblings, 1 reply; 15+ messages in thread From: Wendy Ng @ 2013-10-04 22:17 UTC (permalink / raw) To: Eduardo Valentin Cc: Mark Rutland, Rob Herring, Stephen Warren, devicetree, linux-kernel, linux-pm, Christian Daudt, Markus Mayer Hello Eduardo, I have rebased my work on the top of yours and tried out the new way of registering the thermal zone. The new method is certainly making things easier for me to create a new thermal zone device driver. But I have some questions and I hope to hear back from you before I upload my new patch set that is based on your changes. 1. I found that the hwmon sysfs interface is no longer created when I call thermal_zone_of_sensor_register() to register my thermal sensor. I believe it is because you purposely hard-coded 'no_hwmon' to true. Would it be possible to let the users to control this option as part of the sensor register function? 2. The of_thermal_get_temp() output parameter 'temp' is an unsigned value in order to conforms with the thermal framework 'get_temp' function prototype. But the new sensor interface 'get_temp' callback function (defined in __thermal_zone struct) expects 'temp' to be signed. So technically, a negative value can be returned from the underlying sensor function. Should some checks be added to of_thermal_get_temp() to ensure that a negative value (i.e. a very large unsigned value) won't be passed back to the thermal framework? Or should the 'get_temp' function prototype in __thermal_zone struct be changed with 'unsigned' temperature value and it will be the responsibility of the underlying function to do the check? 3. Your documentation (thermal.txt) seems to suggest that the 'cooling-attachments' are one of the required properties for 'thermal-zones' node in the device tree binding files. However, I don't have any cooling device ready in my current patch series yet and therefore I tried to leave out the 'cooling-attachments' node from the 'thermal-zones' node. It seems to be working just find and I can register the sensor and read out the temperature once the target platform has been booted up. Is this your expectation that people can leave the 'cooling-attachments' node out? I want to make sure I can still submit a new patch set for this series with just the functionality of reading out the temperature from the thermal sensor. Thanks, -Wendy On 9/23/2013 4:46 PM, Eduardo Valentin wrote: > On 23-09-2013 18:43, Wendy Ng wrote: >> On 9/23/2013 11:19 AM, Eduardo Valentin wrote: >>> On 23-09-2013 13:51, Wendy Ng wrote: >>>> This adds the support for reading out temperature from Broadcom bcm281xx >>>> SoCs. >>>> >>>> Signed-off-by: Wendy Ng <wendy.ng@broadcom.com> >>>> Reviewed-by: Markus Mayer <mmayer@broadcom.com> >>>> Reviewed-by: Christian Daudt <csd@broadcom.com> >>>> --- >>>> .../bindings/thermal/bcm-kona-thermal.txt | 18 +++ >>>> drivers/thermal/Kconfig | 10 ++ >>>> drivers/thermal/Makefile | 1 + >>>> drivers/thermal/bcm_thermal.c | 170 >>>> ++++++++++++++++++++ >>>> 4 files changed, 199 insertions(+) >>>> create mode 100644 >>>> Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>> create mode 100644 drivers/thermal/bcm_thermal.c >>>> >>>> diff --git >>>> a/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>> b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>> new file mode 100644 >>>> index 0000000..acca99e >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>> @@ -0,0 +1,18 @@ >>>> +* Broadcom Kona Thermal Management Unit >>>> + >>>> +This version is for the BCM281xx family of SoCs. >>>> + >>>> +Required properties: >>>> +- compatible : "brcm,bcm11351-thermal", "brcm,kona-thermal" >>>> +- reg : Address range of the thermal register >>>> +- thermal-name: this entry must be specified and it will be passed into >>>> +thermal_zone_device_register(). This name will also be reported >>>> under Hwmon >>>> +sysfs 'name' attribute. >>>> + >>>> +Example: >>>> + thermal@34008000 { >>>> + compatible = "brcm,bcm11351-thermal", "brcm,kona-thermal"; >>>> + reg = <0x34008000 0x0024>; >>>> + thermal-name = "bcm_kona_therm"; >>>> + status = "disabled"; >>>> + }; >>>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >>>> index dbfc390..7f823f0 100644 >>>> --- a/drivers/thermal/Kconfig >>>> +++ b/drivers/thermal/Kconfig >>>> @@ -134,6 +134,16 @@ config KIRKWOOD_THERMAL >>>> Support for the Kirkwood thermal sensor driver into the Linux >>>> thermal >>>> framework. Only kirkwood 88F6282 and 88F6283 have this sensor. >>>> +config BCM_THERMAL >>>> + tristate "Temperature sensor on Broadcom BCM281xx family of SoCs" >>>> + depends on ARCH_BCM >>>> + default y >>>> + help >>>> + If you say yes here you get support for TMU (Thermal Management >>>> + Unit) on Broadcom BCM281xx family of SoCs. This provides thermal >>>> + monitoring of CPU clusters, graphics, and SoC glue, but does not >>>> + include monitoring of charger temperature. >>>> + >>>> config DOVE_THERMAL >>>> tristate "Temperature sensor on Marvell Dove SoCs" >>>> depends on ARCH_DOVE >>>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile >>>> index 584b363..3ea8c1c 100644 >>>> --- a/drivers/thermal/Makefile >>>> +++ b/drivers/thermal/Makefile >>>> @@ -21,6 +21,7 @@ obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o >>>> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o >>>> obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o >>>> obj-y += samsung/ >>>> +obj-$(CONFIG_BCM_THERMAL) += bcm_thermal.o >>>> obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o >>>> obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o >>>> obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o >>>> diff --git a/drivers/thermal/bcm_thermal.c >>>> b/drivers/thermal/bcm_thermal.c >>>> new file mode 100644 >>>> index 0000000..131d3c4 >>>> --- /dev/null >>>> +++ b/drivers/thermal/bcm_thermal.c >>>> @@ -0,0 +1,170 @@ >>>> +/* >>>> + * Copyright 2013 Broadcom Corporation. >>>> + * >>>> + * This program is free software; you can redistribute it and/or modify >>>> + * it under the terms of the GNU General Public License, version 2, >>>> + * as published by the Free Software Foundation (the "GPL"). >>>> + * >>>> + * 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. >>>> + * >>>> + * A copy of the GPL is available at >>>> http://www.broadcom.com/licenses/GPLv2.php, >>>> + * or by writing to the Free Software Foundation, Inc., >>>> + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. >>>> + */ >>>> + >>>> +/** >>>> +* Broadcom Thermal Management Unit - bcm_tmu >>>> +*/ >>>> +#include <linux/module.h> >>>> +#include <linux/err.h> >>>> +#include <linux/kernel.h> >>>> +#include <linux/platform_device.h> >>>> +#include <linux/io.h> >>>> +#include <linux/thermal.h> >>>> +#include <linux/of.h> >>>> + >>>> +/* From TMON Register Database */ >>>> +#define TMON_TEMP_VAL_OFFSET 0x0000001c >>>> +#define TMON_TEMP_VAL_TEMP_VAL_SHIFT 0 >>>> +#define TMON_TEMP_VAL_TEMP_VAL_MASK 0x000003ff >>>> + >>>> +/* Broadcom Thermal Zone Device Structure */ >>>> +struct bcm_thermal_zone_priv { >>>> + char name[THERMAL_NAME_LENGTH]; >>>> + void __iomem *base; >>>> +}; >>>> + >>>> +/* Temperature conversion function for TMON block */ >>>> +static long raw_to_mcelsius(u32 raw) >>>> +{ >>>> + /* >>>> + * According to Broadcom internal Analog Module Specification >>>> + * the formula for converting TMON block output to temperature in >>>> + * degree Celsius is: >>>> + * T = 428 - (0.561 * raw) >>>> + * Note: the valid operating range for the TMON block is -40C to >>>> 125C >>>> + */ >>>> + return 428000 - (561 * (long)raw); >>>> +} >>>> + >>>> +/* Get temperature callback function for thermal zone */ >>>> +static int bcm_get_temp(struct thermal_zone_device *thermal, >>>> + unsigned long *temp) >>>> +{ >>>> + u32 raw; >>>> + long mcelsius; >>>> + struct bcm_thermal_zone_priv *priv = thermal->devdata; >>>> + >>>> + if (!priv) { >>>> + pr_err("%s: thermal zone number %d devdata not initialized.\n", >>>> + __func__, thermal->id); >>>> + return -EINVAL; >>>> + } >>>> + >>>> + raw = (readl(priv->base + TMON_TEMP_VAL_OFFSET) >>>> + & TMON_TEMP_VAL_TEMP_VAL_MASK) >> TMON_TEMP_VAL_TEMP_VAL_SHIFT; >>>> + >>>> + pr_debug("%s: thermal zone number %d raw temp 0x%x\n", __func__, >>>> + thermal->id, raw); >>>> + >>>> + mcelsius = raw_to_mcelsius(raw); >>>> + >>>> + /* >>>> + * Since 'mcelsius' might be negative, we need to limit it to >>>> smallest >>>> + * unsigned value before returning it to thermal framework. >>>> + */ >>>> + if (mcelsius < 0) >>>> + *temp = 0; >>>> + else >>>> + *temp = mcelsius; >>>> + >>>> + pr_debug("%s: thermal zone number %d final temp %d\n", __func__, >>>> + thermal->id, (int) *temp); >>>> + >>>> + return 0; >>>> +} >>>> + >>>> +/* Operation callback functions for thermal zone */ >>>> +static struct thermal_zone_device_ops bcm_dev_ops = { >>>> + .get_temp = bcm_get_temp, >>>> +}; >>>> + >>>> +static const struct of_device_id bcm_tmu_match_table[] = { >>>> + { .compatible = "brcm,kona-thermal" }, >>>> + {}, >>>> +}; >>>> +MODULE_DEVICE_TABLE(of, bcm_tmu_match_table); >>>> + >>>> +static int bcm_tmu_probe(struct platform_device *pdev) >>>> +{ >>>> + struct thermal_zone_device *thermal = NULL; >>>> + struct bcm_thermal_zone_priv *priv; >>>> + struct resource *res; >>>> + const char *str; >>>> + >>>> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); >>>> + if (!priv) { >>>> + dev_err(&pdev->dev, "Failed to malloc priv.\n"); >>>> + return -ENOMEM; >>>> + } >>>> + >>>> + /* Obtain the tmu name from device tree file */ >>>> + if (of_property_read_string(pdev->dev.of_node, "thermal-name", >>> Hello Wendy, >>> >>> I would prefer we wait until the work for thermal data [1] gets accepted >>> before accepting this driver, specially because you are adding device >>> specific DT entry to help in your registration with the thermal >>> framework. With the mentioned work you wont need it at all. >>> >>> All best, >>> >>> [1] - http://lkml.org/lkml/2013/9/15/122 >> Hello Eduardo, >> >> Since your changes are quite extensive, would you recommend me to get >> your 16 patches into my local workspace and try to integrate the code >> from my patches on the top of your patches at this time? Or should I >> wait until your patches get accepted. > Hello again Wendy, > > The only part I am concerned is the device tree entry you are creating > for your device/driver. That could be obsolete in near future with the > work I am doing currently. > > The work is, as you mentioned, quite extensive, but should make things > easier for device driver writer. If you want, of course, it would be > great if you could rebase your work on top of mine and try it out on > your side and let me know the outcome. > > Comments on the proposed binding and documentation is also welcome. Let > me know if there is something that it is not clear. > >> Thanks, >> -Wendy >>>> + &str) == 0) { >>>> + strlcpy(priv->name, str, sizeof(priv->name)); >>>> + } else { >>>> + dev_err(&pdev->dev, "Failed to get thermal-name from DT.\n"); >>>> + return -EINVAL; >>>> + } >>>> + >>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>>> + priv->base = devm_ioremap_resource(&pdev->dev, res); >>>> + if (IS_ERR(priv->base)) >>>> + return PTR_ERR(priv->base); >>>> + >>>> + thermal = thermal_zone_device_register(priv->name, 0, 0, priv, >>>> + &bcm_dev_ops, NULL, 0, 0); >>>> + if (IS_ERR(thermal)) { >>>> + dev_err(&pdev->dev, >>>> + "Failed to register Broadcom thermal zone device.\n"); >>>> + return PTR_ERR(thermal); >>>> + } >>>> + >>>> + platform_set_drvdata(pdev, thermal); >>>> + >>>> + dev_info(&pdev->dev, "Broadcom Thermal Monitor Initialized.\n"); >>>> + >>>> + return 0; >>>> +} >>>> + >>>> +static int bcm_tmu_remove(struct platform_device *pdev) >>>> +{ >>>> + struct thermal_zone_device *broadcom_thermal = >>>> + platform_get_drvdata(pdev); >>>> + >>>> + thermal_zone_device_unregister(broadcom_thermal); >>>> + >>>> + dev_info(&pdev->dev, "Broadcom Thermal Monitor Uninitialized.\n"); >>>> + >>>> + return 0; >>>> +} >>>> + >>>> +static struct platform_driver bcm_tmu_driver = { >>>> + .driver = { >>>> + .name = "bcm-thermal", >>>> + .owner = THIS_MODULE, >>>> + .of_match_table = bcm_tmu_match_table, >>>> + }, >>>> + .probe = bcm_tmu_probe, >>>> + .remove = bcm_tmu_remove, >>>> +}; >>>> + >>>> +module_platform_driver(bcm_tmu_driver); >>>> + >>>> +MODULE_DESCRIPTION("Broadcom Thermal Driver"); >>>> +MODULE_AUTHOR("Broadcom"); >>>> +MODULE_LICENSE("GPL v2"); >>>> +MODULE_ALIAS("platform:bcm-thermal"); >>>> > -- Best regards, -Wendy ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/3] thermal: bcm281xx: Add thermal driver 2013-10-04 22:17 ` Wendy Ng @ 2013-10-07 14:52 ` Eduardo Valentin 2013-10-07 16:12 ` Eduardo Valentin 0 siblings, 1 reply; 15+ messages in thread From: Eduardo Valentin @ 2013-10-07 14:52 UTC (permalink / raw) To: Wendy Ng Cc: Eduardo Valentin, Mark Rutland, Rob Herring, Stephen Warren, devicetree, linux-kernel, linux-pm, Christian Daudt, Markus Mayer [-- Attachment #1: Type: text/plain, Size: 15564 bytes --] On 04-10-2013 18:17, Wendy Ng wrote: > Hello Eduardo, > Hello Wendy, > I have rebased my work on the top of yours and tried out the new way of > registering the thermal zone. The new method is certainly making > things easier for me to create a new thermal zone device driver. But I > have some questions and I hope to hear back from you before I upload my > new patch set that is based on your changes. Great that you gave it a shot. Thanks for that. > > 1. I found that the hwmon sysfs interface is no longer created when I > call thermal_zone_of_sensor_register() to register my thermal sensor. I > believe it is because you purposely hard-coded 'no_hwmon' to true. > Would it be possible to let the users to control this option as part of > the sensor register function? Hmmm.. I also thought of allowing the thermal to hwmon interface configurable. But the interface gets created in different path from the sensor registration, which makes things a bit harder. The zones are probed while parsing the DT file. While the sensors get linked, thermal_zone_of_sensor_register(), typically when sensors are probed. Do you have a real use case for using the thermal to hwmon interface? Durgadoss (original author) and Rui were considering deprecating and finally removing it. If yes, it is time to rise your voice here. > > 2. The of_thermal_get_temp() output parameter 'temp' is an unsigned > value in order to conforms with the thermal framework 'get_temp' > function prototype. But the new sensor interface 'get_temp' callback > function (defined in __thermal_zone struct) expects 'temp' to be > signed. So technically, a negative value can be returned from the > underlying sensor function. Should some checks be added to > of_thermal_get_temp() to ensure that a negative value (i.e. a very large > unsigned value) won't be passed back to the thermal framework? Or > should the 'get_temp' function prototype in __thermal_zone struct be > changed with 'unsigned' temperature value and it will be the > responsibility of the underlying function to do the check? > I could for sure, add a warning inside of_thermal_get_temp(). But in general, I believe the thermal framework has to cover for signed temperature values, even if typical usage is on positive temperature range. Mainly for correct temperature representation. > 3. Your documentation (thermal.txt) seems to suggest that the > 'cooling-attachments' are one of the required properties for > 'thermal-zones' node in the device tree binding files. However, I don't Hmm... That was not the intention. > have any cooling device ready in my current patch series yet and > therefore I tried to leave out the 'cooling-attachments' node from the > 'thermal-zones' node. It seems to be working just find and I can > register the sensor and read out the temperature once the target > platform has been booted up. Is this your expectation that people can > leave the 'cooling-attachments' node out? I want to make sure I can > still submit a new patch set for this series with just the functionality > of reading out the temperature from the thermal sensor. So, let me try to clarify a couple of things. First thing is that the cooling-attachments has been renamed to cooling-maps, just a new naming convention. Also, there are thermal zones that do not have cooling-maps, they just describe thermal shutdown by software, thermal zones with only CRITICAL trip points, for instance. For this reason, thermal zones must be probed properly without cooling-maps. I need to double check the documentation in this case, I believe. > > Thanks, > -Wendy > > On 9/23/2013 4:46 PM, Eduardo Valentin wrote: >> On 23-09-2013 18:43, Wendy Ng wrote: >>> On 9/23/2013 11:19 AM, Eduardo Valentin wrote: >>>> On 23-09-2013 13:51, Wendy Ng wrote: >>>>> This adds the support for reading out temperature from Broadcom >>>>> bcm281xx >>>>> SoCs. >>>>> >>>>> Signed-off-by: Wendy Ng <wendy.ng@broadcom.com> >>>>> Reviewed-by: Markus Mayer <mmayer@broadcom.com> >>>>> Reviewed-by: Christian Daudt <csd@broadcom.com> >>>>> --- >>>>> .../bindings/thermal/bcm-kona-thermal.txt | 18 +++ >>>>> drivers/thermal/Kconfig | 10 ++ >>>>> drivers/thermal/Makefile | 1 + >>>>> drivers/thermal/bcm_thermal.c | 170 >>>>> ++++++++++++++++++++ >>>>> 4 files changed, 199 insertions(+) >>>>> create mode 100644 >>>>> Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>> create mode 100644 drivers/thermal/bcm_thermal.c >>>>> >>>>> diff --git >>>>> a/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>> b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>> new file mode 100644 >>>>> index 0000000..acca99e >>>>> --- /dev/null >>>>> +++ b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>> @@ -0,0 +1,18 @@ >>>>> +* Broadcom Kona Thermal Management Unit >>>>> + >>>>> +This version is for the BCM281xx family of SoCs. >>>>> + >>>>> +Required properties: >>>>> +- compatible : "brcm,bcm11351-thermal", "brcm,kona-thermal" >>>>> +- reg : Address range of the thermal register >>>>> +- thermal-name: this entry must be specified and it will be passed >>>>> into >>>>> +thermal_zone_device_register(). This name will also be reported >>>>> under Hwmon >>>>> +sysfs 'name' attribute. >>>>> + >>>>> +Example: >>>>> + thermal@34008000 { >>>>> + compatible = "brcm,bcm11351-thermal", "brcm,kona-thermal"; >>>>> + reg = <0x34008000 0x0024>; >>>>> + thermal-name = "bcm_kona_therm"; >>>>> + status = "disabled"; >>>>> + }; >>>>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >>>>> index dbfc390..7f823f0 100644 >>>>> --- a/drivers/thermal/Kconfig >>>>> +++ b/drivers/thermal/Kconfig >>>>> @@ -134,6 +134,16 @@ config KIRKWOOD_THERMAL >>>>> Support for the Kirkwood thermal sensor driver into the Linux >>>>> thermal >>>>> framework. Only kirkwood 88F6282 and 88F6283 have this >>>>> sensor. >>>>> +config BCM_THERMAL >>>>> + tristate "Temperature sensor on Broadcom BCM281xx family of SoCs" >>>>> + depends on ARCH_BCM >>>>> + default y >>>>> + help >>>>> + If you say yes here you get support for TMU (Thermal Management >>>>> + Unit) on Broadcom BCM281xx family of SoCs. This provides >>>>> thermal >>>>> + monitoring of CPU clusters, graphics, and SoC glue, but does >>>>> not >>>>> + include monitoring of charger temperature. >>>>> + >>>>> config DOVE_THERMAL >>>>> tristate "Temperature sensor on Marvell Dove SoCs" >>>>> depends on ARCH_DOVE >>>>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile >>>>> index 584b363..3ea8c1c 100644 >>>>> --- a/drivers/thermal/Makefile >>>>> +++ b/drivers/thermal/Makefile >>>>> @@ -21,6 +21,7 @@ obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o >>>>> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o >>>>> obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o >>>>> obj-y += samsung/ >>>>> +obj-$(CONFIG_BCM_THERMAL) += bcm_thermal.o >>>>> obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o >>>>> obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o >>>>> obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o >>>>> diff --git a/drivers/thermal/bcm_thermal.c >>>>> b/drivers/thermal/bcm_thermal.c >>>>> new file mode 100644 >>>>> index 0000000..131d3c4 >>>>> --- /dev/null >>>>> +++ b/drivers/thermal/bcm_thermal.c >>>>> @@ -0,0 +1,170 @@ >>>>> +/* >>>>> + * Copyright 2013 Broadcom Corporation. >>>>> + * >>>>> + * This program is free software; you can redistribute it and/or >>>>> modify >>>>> + * it under the terms of the GNU General Public License, version 2, >>>>> + * as published by the Free Software Foundation (the "GPL"). >>>>> + * >>>>> + * 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. >>>>> + * >>>>> + * A copy of the GPL is available at >>>>> http://www.broadcom.com/licenses/GPLv2.php, >>>>> + * or by writing to the Free Software Foundation, Inc., >>>>> + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. >>>>> + */ >>>>> + >>>>> +/** >>>>> +* Broadcom Thermal Management Unit - bcm_tmu >>>>> +*/ >>>>> +#include <linux/module.h> >>>>> +#include <linux/err.h> >>>>> +#include <linux/kernel.h> >>>>> +#include <linux/platform_device.h> >>>>> +#include <linux/io.h> >>>>> +#include <linux/thermal.h> >>>>> +#include <linux/of.h> >>>>> + >>>>> +/* From TMON Register Database */ >>>>> +#define TMON_TEMP_VAL_OFFSET 0x0000001c >>>>> +#define TMON_TEMP_VAL_TEMP_VAL_SHIFT 0 >>>>> +#define TMON_TEMP_VAL_TEMP_VAL_MASK 0x000003ff >>>>> + >>>>> +/* Broadcom Thermal Zone Device Structure */ >>>>> +struct bcm_thermal_zone_priv { >>>>> + char name[THERMAL_NAME_LENGTH]; >>>>> + void __iomem *base; >>>>> +}; >>>>> + >>>>> +/* Temperature conversion function for TMON block */ >>>>> +static long raw_to_mcelsius(u32 raw) >>>>> +{ >>>>> + /* >>>>> + * According to Broadcom internal Analog Module Specification >>>>> + * the formula for converting TMON block output to temperature in >>>>> + * degree Celsius is: >>>>> + * T = 428 - (0.561 * raw) >>>>> + * Note: the valid operating range for the TMON block is -40C to >>>>> 125C >>>>> + */ >>>>> + return 428000 - (561 * (long)raw); >>>>> +} >>>>> + >>>>> +/* Get temperature callback function for thermal zone */ >>>>> +static int bcm_get_temp(struct thermal_zone_device *thermal, >>>>> + unsigned long *temp) >>>>> +{ >>>>> + u32 raw; >>>>> + long mcelsius; >>>>> + struct bcm_thermal_zone_priv *priv = thermal->devdata; >>>>> + >>>>> + if (!priv) { >>>>> + pr_err("%s: thermal zone number %d devdata not >>>>> initialized.\n", >>>>> + __func__, thermal->id); >>>>> + return -EINVAL; >>>>> + } >>>>> + >>>>> + raw = (readl(priv->base + TMON_TEMP_VAL_OFFSET) >>>>> + & TMON_TEMP_VAL_TEMP_VAL_MASK) >> >>>>> TMON_TEMP_VAL_TEMP_VAL_SHIFT; >>>>> + >>>>> + pr_debug("%s: thermal zone number %d raw temp 0x%x\n", __func__, >>>>> + thermal->id, raw); >>>>> + >>>>> + mcelsius = raw_to_mcelsius(raw); >>>>> + >>>>> + /* >>>>> + * Since 'mcelsius' might be negative, we need to limit it to >>>>> smallest >>>>> + * unsigned value before returning it to thermal framework. >>>>> + */ >>>>> + if (mcelsius < 0) >>>>> + *temp = 0; >>>>> + else >>>>> + *temp = mcelsius; >>>>> + >>>>> + pr_debug("%s: thermal zone number %d final temp %d\n", __func__, >>>>> + thermal->id, (int) *temp); >>>>> + >>>>> + return 0; >>>>> +} >>>>> + >>>>> +/* Operation callback functions for thermal zone */ >>>>> +static struct thermal_zone_device_ops bcm_dev_ops = { >>>>> + .get_temp = bcm_get_temp, >>>>> +}; >>>>> + >>>>> +static const struct of_device_id bcm_tmu_match_table[] = { >>>>> + { .compatible = "brcm,kona-thermal" }, >>>>> + {}, >>>>> +}; >>>>> +MODULE_DEVICE_TABLE(of, bcm_tmu_match_table); >>>>> + >>>>> +static int bcm_tmu_probe(struct platform_device *pdev) >>>>> +{ >>>>> + struct thermal_zone_device *thermal = NULL; >>>>> + struct bcm_thermal_zone_priv *priv; >>>>> + struct resource *res; >>>>> + const char *str; >>>>> + >>>>> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); >>>>> + if (!priv) { >>>>> + dev_err(&pdev->dev, "Failed to malloc priv.\n"); >>>>> + return -ENOMEM; >>>>> + } >>>>> + >>>>> + /* Obtain the tmu name from device tree file */ >>>>> + if (of_property_read_string(pdev->dev.of_node, "thermal-name", >>>> Hello Wendy, >>>> >>>> I would prefer we wait until the work for thermal data [1] gets >>>> accepted >>>> before accepting this driver, specially because you are adding device >>>> specific DT entry to help in your registration with the thermal >>>> framework. With the mentioned work you wont need it at all. >>>> >>>> All best, >>>> >>>> [1] - http://lkml.org/lkml/2013/9/15/122 >>> Hello Eduardo, >>> >>> Since your changes are quite extensive, would you recommend me to get >>> your 16 patches into my local workspace and try to integrate the code >>> from my patches on the top of your patches at this time? Or should I >>> wait until your patches get accepted. >> Hello again Wendy, >> >> The only part I am concerned is the device tree entry you are creating >> for your device/driver. That could be obsolete in near future with the >> work I am doing currently. >> >> The work is, as you mentioned, quite extensive, but should make things >> easier for device driver writer. If you want, of course, it would be >> great if you could rebase your work on top of mine and try it out on >> your side and let me know the outcome. >> >> Comments on the proposed binding and documentation is also welcome. Let >> me know if there is something that it is not clear. >> >>> Thanks, >>> -Wendy >>>>> + &str) == 0) { >>>>> + strlcpy(priv->name, str, sizeof(priv->name)); >>>>> + } else { >>>>> + dev_err(&pdev->dev, "Failed to get thermal-name from DT.\n"); >>>>> + return -EINVAL; >>>>> + } >>>>> + >>>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>>>> + priv->base = devm_ioremap_resource(&pdev->dev, res); >>>>> + if (IS_ERR(priv->base)) >>>>> + return PTR_ERR(priv->base); >>>>> + >>>>> + thermal = thermal_zone_device_register(priv->name, 0, 0, priv, >>>>> + &bcm_dev_ops, NULL, 0, 0); >>>>> + if (IS_ERR(thermal)) { >>>>> + dev_err(&pdev->dev, >>>>> + "Failed to register Broadcom thermal zone device.\n"); >>>>> + return PTR_ERR(thermal); >>>>> + } >>>>> + >>>>> + platform_set_drvdata(pdev, thermal); >>>>> + >>>>> + dev_info(&pdev->dev, "Broadcom Thermal Monitor Initialized.\n"); >>>>> + >>>>> + return 0; >>>>> +} >>>>> + >>>>> +static int bcm_tmu_remove(struct platform_device *pdev) >>>>> +{ >>>>> + struct thermal_zone_device *broadcom_thermal = >>>>> + platform_get_drvdata(pdev); >>>>> + >>>>> + thermal_zone_device_unregister(broadcom_thermal); >>>>> + >>>>> + dev_info(&pdev->dev, "Broadcom Thermal Monitor >>>>> Uninitialized.\n"); >>>>> + >>>>> + return 0; >>>>> +} >>>>> + >>>>> +static struct platform_driver bcm_tmu_driver = { >>>>> + .driver = { >>>>> + .name = "bcm-thermal", >>>>> + .owner = THIS_MODULE, >>>>> + .of_match_table = bcm_tmu_match_table, >>>>> + }, >>>>> + .probe = bcm_tmu_probe, >>>>> + .remove = bcm_tmu_remove, >>>>> +}; >>>>> + >>>>> +module_platform_driver(bcm_tmu_driver); >>>>> + >>>>> +MODULE_DESCRIPTION("Broadcom Thermal Driver"); >>>>> +MODULE_AUTHOR("Broadcom"); >>>>> +MODULE_LICENSE("GPL v2"); >>>>> +MODULE_ALIAS("platform:bcm-thermal"); >>>>> >> > -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 295 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/3] thermal: bcm281xx: Add thermal driver 2013-10-07 14:52 ` Eduardo Valentin @ 2013-10-07 16:12 ` Eduardo Valentin 2013-10-07 17:52 ` Wendy Ng 0 siblings, 1 reply; 15+ messages in thread From: Eduardo Valentin @ 2013-10-07 16:12 UTC (permalink / raw) To: Eduardo Valentin Cc: Wendy Ng, Mark Rutland, Rob Herring, Stephen Warren, devicetree, linux-kernel, linux-pm, Christian Daudt, Markus Mayer [-- Attachment #1: Type: text/plain, Size: 16417 bytes --] On 07-10-2013 10:52, Eduardo Valentin wrote: > On 04-10-2013 18:17, Wendy Ng wrote: >> Hello Eduardo, >> > > Hello Wendy, > >> I have rebased my work on the top of yours and tried out the new way of >> registering the thermal zone. The new method is certainly making >> things easier for me to create a new thermal zone device driver. But I >> have some questions and I hope to hear back from you before I upload my >> new patch set that is based on your changes. > > Great that you gave it a shot. Thanks for that. > >> >> 1. I found that the hwmon sysfs interface is no longer created when I >> call thermal_zone_of_sensor_register() to register my thermal sensor. I >> believe it is because you purposely hard-coded 'no_hwmon' to true. >> Would it be possible to let the users to control this option as part of >> the sensor register function? > > Hmmm.. I also thought of allowing the thermal to hwmon interface > configurable. But the interface gets created in different path from the > sensor registration, which makes things a bit harder. The zones are > probed while parsing the DT file. While the sensors get linked, > thermal_zone_of_sensor_register(), typically when sensors are probed. > > Do you have a real use case for using the thermal to hwmon interface? > Durgadoss (original author) and Rui were considering deprecating and > finally removing it. If yes, it is time to rise your voice here. > >> >> 2. The of_thermal_get_temp() output parameter 'temp' is an unsigned >> value in order to conforms with the thermal framework 'get_temp' >> function prototype. But the new sensor interface 'get_temp' callback >> function (defined in __thermal_zone struct) expects 'temp' to be >> signed. So technically, a negative value can be returned from the >> underlying sensor function. Should some checks be added to >> of_thermal_get_temp() to ensure that a negative value (i.e. a very large >> unsigned value) won't be passed back to the thermal framework? Or >> should the 'get_temp' function prototype in __thermal_zone struct be >> changed with 'unsigned' temperature value and it will be the >> responsibility of the underlying function to do the check? >> > > I could for sure, add a warning inside of_thermal_get_temp(). But in > general, I believe the thermal framework has to cover for signed > temperature values, even if typical usage is on positive temperature > range. Mainly for correct temperature representation. > > >> 3. Your documentation (thermal.txt) seems to suggest that the >> 'cooling-attachments' are one of the required properties for >> 'thermal-zones' node in the device tree binding files. However, I don't > > Hmm... That was not the intention. > >> have any cooling device ready in my current patch series yet and >> therefore I tried to leave out the 'cooling-attachments' node from the >> 'thermal-zones' node. It seems to be working just find and I can >> register the sensor and read out the temperature once the target >> platform has been booted up. Is this your expectation that people can >> leave the 'cooling-attachments' node out? I want to make sure I can >> still submit a new patch set for this series with just the functionality >> of reading out the temperature from the thermal sensor. > > So, let me try to clarify a couple of things. First thing is that the > cooling-attachments has been renamed to cooling-maps, just a new naming > convention. Also, there are thermal zones that do not have > cooling-maps, they just describe thermal shutdown by software, thermal > zones with only CRITICAL trip points, for instance. For this reason, > thermal zones must be probed properly without cooling-maps. I need to > double check the documentation in this case, I believe. Just to clarify a bit, this does not mean we should allow having thermal zones only for monitoring. If you are generating a thermal zone, it means you want to cover thermal limits. The example I gave was a thermal zone that does not have cooling-maps, but it does have a thermal constraint, a trip point which is CRITICAL, meaning, the silicon state is not reliable anymore. > >> >> Thanks, >> -Wendy >> >> On 9/23/2013 4:46 PM, Eduardo Valentin wrote: >>> On 23-09-2013 18:43, Wendy Ng wrote: >>>> On 9/23/2013 11:19 AM, Eduardo Valentin wrote: >>>>> On 23-09-2013 13:51, Wendy Ng wrote: >>>>>> This adds the support for reading out temperature from Broadcom >>>>>> bcm281xx >>>>>> SoCs. >>>>>> >>>>>> Signed-off-by: Wendy Ng <wendy.ng@broadcom.com> >>>>>> Reviewed-by: Markus Mayer <mmayer@broadcom.com> >>>>>> Reviewed-by: Christian Daudt <csd@broadcom.com> >>>>>> --- >>>>>> .../bindings/thermal/bcm-kona-thermal.txt | 18 +++ >>>>>> drivers/thermal/Kconfig | 10 ++ >>>>>> drivers/thermal/Makefile | 1 + >>>>>> drivers/thermal/bcm_thermal.c | 170 >>>>>> ++++++++++++++++++++ >>>>>> 4 files changed, 199 insertions(+) >>>>>> create mode 100644 >>>>>> Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>>> create mode 100644 drivers/thermal/bcm_thermal.c >>>>>> >>>>>> diff --git >>>>>> a/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>>> b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>>> new file mode 100644 >>>>>> index 0000000..acca99e >>>>>> --- /dev/null >>>>>> +++ b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>>> @@ -0,0 +1,18 @@ >>>>>> +* Broadcom Kona Thermal Management Unit >>>>>> + >>>>>> +This version is for the BCM281xx family of SoCs. >>>>>> + >>>>>> +Required properties: >>>>>> +- compatible : "brcm,bcm11351-thermal", "brcm,kona-thermal" >>>>>> +- reg : Address range of the thermal register >>>>>> +- thermal-name: this entry must be specified and it will be passed >>>>>> into >>>>>> +thermal_zone_device_register(). This name will also be reported >>>>>> under Hwmon >>>>>> +sysfs 'name' attribute. >>>>>> + >>>>>> +Example: >>>>>> + thermal@34008000 { >>>>>> + compatible = "brcm,bcm11351-thermal", "brcm,kona-thermal"; >>>>>> + reg = <0x34008000 0x0024>; >>>>>> + thermal-name = "bcm_kona_therm"; >>>>>> + status = "disabled"; >>>>>> + }; >>>>>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >>>>>> index dbfc390..7f823f0 100644 >>>>>> --- a/drivers/thermal/Kconfig >>>>>> +++ b/drivers/thermal/Kconfig >>>>>> @@ -134,6 +134,16 @@ config KIRKWOOD_THERMAL >>>>>> Support for the Kirkwood thermal sensor driver into the Linux >>>>>> thermal >>>>>> framework. Only kirkwood 88F6282 and 88F6283 have this >>>>>> sensor. >>>>>> +config BCM_THERMAL >>>>>> + tristate "Temperature sensor on Broadcom BCM281xx family of SoCs" >>>>>> + depends on ARCH_BCM >>>>>> + default y >>>>>> + help >>>>>> + If you say yes here you get support for TMU (Thermal Management >>>>>> + Unit) on Broadcom BCM281xx family of SoCs. This provides >>>>>> thermal >>>>>> + monitoring of CPU clusters, graphics, and SoC glue, but does >>>>>> not >>>>>> + include monitoring of charger temperature. >>>>>> + >>>>>> config DOVE_THERMAL >>>>>> tristate "Temperature sensor on Marvell Dove SoCs" >>>>>> depends on ARCH_DOVE >>>>>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile >>>>>> index 584b363..3ea8c1c 100644 >>>>>> --- a/drivers/thermal/Makefile >>>>>> +++ b/drivers/thermal/Makefile >>>>>> @@ -21,6 +21,7 @@ obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o >>>>>> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o >>>>>> obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o >>>>>> obj-y += samsung/ >>>>>> +obj-$(CONFIG_BCM_THERMAL) += bcm_thermal.o >>>>>> obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o >>>>>> obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o >>>>>> obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o >>>>>> diff --git a/drivers/thermal/bcm_thermal.c >>>>>> b/drivers/thermal/bcm_thermal.c >>>>>> new file mode 100644 >>>>>> index 0000000..131d3c4 >>>>>> --- /dev/null >>>>>> +++ b/drivers/thermal/bcm_thermal.c >>>>>> @@ -0,0 +1,170 @@ >>>>>> +/* >>>>>> + * Copyright 2013 Broadcom Corporation. >>>>>> + * >>>>>> + * This program is free software; you can redistribute it and/or >>>>>> modify >>>>>> + * it under the terms of the GNU General Public License, version 2, >>>>>> + * as published by the Free Software Foundation (the "GPL"). >>>>>> + * >>>>>> + * 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. >>>>>> + * >>>>>> + * A copy of the GPL is available at >>>>>> http://www.broadcom.com/licenses/GPLv2.php, >>>>>> + * or by writing to the Free Software Foundation, Inc., >>>>>> + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. >>>>>> + */ >>>>>> + >>>>>> +/** >>>>>> +* Broadcom Thermal Management Unit - bcm_tmu >>>>>> +*/ >>>>>> +#include <linux/module.h> >>>>>> +#include <linux/err.h> >>>>>> +#include <linux/kernel.h> >>>>>> +#include <linux/platform_device.h> >>>>>> +#include <linux/io.h> >>>>>> +#include <linux/thermal.h> >>>>>> +#include <linux/of.h> >>>>>> + >>>>>> +/* From TMON Register Database */ >>>>>> +#define TMON_TEMP_VAL_OFFSET 0x0000001c >>>>>> +#define TMON_TEMP_VAL_TEMP_VAL_SHIFT 0 >>>>>> +#define TMON_TEMP_VAL_TEMP_VAL_MASK 0x000003ff >>>>>> + >>>>>> +/* Broadcom Thermal Zone Device Structure */ >>>>>> +struct bcm_thermal_zone_priv { >>>>>> + char name[THERMAL_NAME_LENGTH]; >>>>>> + void __iomem *base; >>>>>> +}; >>>>>> + >>>>>> +/* Temperature conversion function for TMON block */ >>>>>> +static long raw_to_mcelsius(u32 raw) >>>>>> +{ >>>>>> + /* >>>>>> + * According to Broadcom internal Analog Module Specification >>>>>> + * the formula for converting TMON block output to temperature in >>>>>> + * degree Celsius is: >>>>>> + * T = 428 - (0.561 * raw) >>>>>> + * Note: the valid operating range for the TMON block is -40C to >>>>>> 125C >>>>>> + */ >>>>>> + return 428000 - (561 * (long)raw); >>>>>> +} >>>>>> + >>>>>> +/* Get temperature callback function for thermal zone */ >>>>>> +static int bcm_get_temp(struct thermal_zone_device *thermal, >>>>>> + unsigned long *temp) >>>>>> +{ >>>>>> + u32 raw; >>>>>> + long mcelsius; >>>>>> + struct bcm_thermal_zone_priv *priv = thermal->devdata; >>>>>> + >>>>>> + if (!priv) { >>>>>> + pr_err("%s: thermal zone number %d devdata not >>>>>> initialized.\n", >>>>>> + __func__, thermal->id); >>>>>> + return -EINVAL; >>>>>> + } >>>>>> + >>>>>> + raw = (readl(priv->base + TMON_TEMP_VAL_OFFSET) >>>>>> + & TMON_TEMP_VAL_TEMP_VAL_MASK) >> >>>>>> TMON_TEMP_VAL_TEMP_VAL_SHIFT; >>>>>> + >>>>>> + pr_debug("%s: thermal zone number %d raw temp 0x%x\n", __func__, >>>>>> + thermal->id, raw); >>>>>> + >>>>>> + mcelsius = raw_to_mcelsius(raw); >>>>>> + >>>>>> + /* >>>>>> + * Since 'mcelsius' might be negative, we need to limit it to >>>>>> smallest >>>>>> + * unsigned value before returning it to thermal framework. >>>>>> + */ >>>>>> + if (mcelsius < 0) >>>>>> + *temp = 0; >>>>>> + else >>>>>> + *temp = mcelsius; >>>>>> + >>>>>> + pr_debug("%s: thermal zone number %d final temp %d\n", __func__, >>>>>> + thermal->id, (int) *temp); >>>>>> + >>>>>> + return 0; >>>>>> +} >>>>>> + >>>>>> +/* Operation callback functions for thermal zone */ >>>>>> +static struct thermal_zone_device_ops bcm_dev_ops = { >>>>>> + .get_temp = bcm_get_temp, >>>>>> +}; >>>>>> + >>>>>> +static const struct of_device_id bcm_tmu_match_table[] = { >>>>>> + { .compatible = "brcm,kona-thermal" }, >>>>>> + {}, >>>>>> +}; >>>>>> +MODULE_DEVICE_TABLE(of, bcm_tmu_match_table); >>>>>> + >>>>>> +static int bcm_tmu_probe(struct platform_device *pdev) >>>>>> +{ >>>>>> + struct thermal_zone_device *thermal = NULL; >>>>>> + struct bcm_thermal_zone_priv *priv; >>>>>> + struct resource *res; >>>>>> + const char *str; >>>>>> + >>>>>> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); >>>>>> + if (!priv) { >>>>>> + dev_err(&pdev->dev, "Failed to malloc priv.\n"); >>>>>> + return -ENOMEM; >>>>>> + } >>>>>> + >>>>>> + /* Obtain the tmu name from device tree file */ >>>>>> + if (of_property_read_string(pdev->dev.of_node, "thermal-name", >>>>> Hello Wendy, >>>>> >>>>> I would prefer we wait until the work for thermal data [1] gets >>>>> accepted >>>>> before accepting this driver, specially because you are adding device >>>>> specific DT entry to help in your registration with the thermal >>>>> framework. With the mentioned work you wont need it at all. >>>>> >>>>> All best, >>>>> >>>>> [1] - http://lkml.org/lkml/2013/9/15/122 >>>> Hello Eduardo, >>>> >>>> Since your changes are quite extensive, would you recommend me to get >>>> your 16 patches into my local workspace and try to integrate the code >>>> from my patches on the top of your patches at this time? Or should I >>>> wait until your patches get accepted. >>> Hello again Wendy, >>> >>> The only part I am concerned is the device tree entry you are creating >>> for your device/driver. That could be obsolete in near future with the >>> work I am doing currently. >>> >>> The work is, as you mentioned, quite extensive, but should make things >>> easier for device driver writer. If you want, of course, it would be >>> great if you could rebase your work on top of mine and try it out on >>> your side and let me know the outcome. >>> >>> Comments on the proposed binding and documentation is also welcome. Let >>> me know if there is something that it is not clear. >>> >>>> Thanks, >>>> -Wendy >>>>>> + &str) == 0) { >>>>>> + strlcpy(priv->name, str, sizeof(priv->name)); >>>>>> + } else { >>>>>> + dev_err(&pdev->dev, "Failed to get thermal-name from DT.\n"); >>>>>> + return -EINVAL; >>>>>> + } >>>>>> + >>>>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>>>>> + priv->base = devm_ioremap_resource(&pdev->dev, res); >>>>>> + if (IS_ERR(priv->base)) >>>>>> + return PTR_ERR(priv->base); >>>>>> + >>>>>> + thermal = thermal_zone_device_register(priv->name, 0, 0, priv, >>>>>> + &bcm_dev_ops, NULL, 0, 0); >>>>>> + if (IS_ERR(thermal)) { >>>>>> + dev_err(&pdev->dev, >>>>>> + "Failed to register Broadcom thermal zone device.\n"); >>>>>> + return PTR_ERR(thermal); >>>>>> + } >>>>>> + >>>>>> + platform_set_drvdata(pdev, thermal); >>>>>> + >>>>>> + dev_info(&pdev->dev, "Broadcom Thermal Monitor Initialized.\n"); >>>>>> + >>>>>> + return 0; >>>>>> +} >>>>>> + >>>>>> +static int bcm_tmu_remove(struct platform_device *pdev) >>>>>> +{ >>>>>> + struct thermal_zone_device *broadcom_thermal = >>>>>> + platform_get_drvdata(pdev); >>>>>> + >>>>>> + thermal_zone_device_unregister(broadcom_thermal); >>>>>> + >>>>>> + dev_info(&pdev->dev, "Broadcom Thermal Monitor >>>>>> Uninitialized.\n"); >>>>>> + >>>>>> + return 0; >>>>>> +} >>>>>> + >>>>>> +static struct platform_driver bcm_tmu_driver = { >>>>>> + .driver = { >>>>>> + .name = "bcm-thermal", >>>>>> + .owner = THIS_MODULE, >>>>>> + .of_match_table = bcm_tmu_match_table, >>>>>> + }, >>>>>> + .probe = bcm_tmu_probe, >>>>>> + .remove = bcm_tmu_remove, >>>>>> +}; >>>>>> + >>>>>> +module_platform_driver(bcm_tmu_driver); >>>>>> + >>>>>> +MODULE_DESCRIPTION("Broadcom Thermal Driver"); >>>>>> +MODULE_AUTHOR("Broadcom"); >>>>>> +MODULE_LICENSE("GPL v2"); >>>>>> +MODULE_ALIAS("platform:bcm-thermal"); >>>>>> >>> >> > > -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 295 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/3] thermal: bcm281xx: Add thermal driver 2013-10-07 16:12 ` Eduardo Valentin @ 2013-10-07 17:52 ` Wendy Ng 2013-10-07 22:32 ` Eduardo Valentin 0 siblings, 1 reply; 15+ messages in thread From: Wendy Ng @ 2013-10-07 17:52 UTC (permalink / raw) To: Eduardo Valentin Cc: Mark Rutland, Rob Herring, Stephen Warren, devicetree, linux-kernel, linux-pm, Christian Daudt, Markus Mayer On 10/7/2013 9:12 AM, Eduardo Valentin wrote: > On 07-10-2013 10:52, Eduardo Valentin wrote: >> On 04-10-2013 18:17, Wendy Ng wrote: >>> Hello Eduardo, >>> >> Hello Wendy, >> >>> I have rebased my work on the top of yours and tried out the new way of >>> registering the thermal zone. The new method is certainly making >>> things easier for me to create a new thermal zone device driver. But I >>> have some questions and I hope to hear back from you before I upload my >>> new patch set that is based on your changes. >> Great that you gave it a shot. Thanks for that. >> >>> 1. I found that the hwmon sysfs interface is no longer created when I >>> call thermal_zone_of_sensor_register() to register my thermal sensor. I >>> believe it is because you purposely hard-coded 'no_hwmon' to true. >>> Would it be possible to let the users to control this option as part of >>> the sensor register function? >> Hmmm.. I also thought of allowing the thermal to hwmon interface >> configurable. But the interface gets created in different path from the >> sensor registration, which makes things a bit harder. The zones are >> probed while parsing the DT file. While the sensors get linked, >> thermal_zone_of_sensor_register(), typically when sensors are probed. >> >> Do you have a real use case for using the thermal to hwmon interface? >> Durgadoss (original author) and Rui were considering deprecating and >> finally removing it. If yes, it is time to rise your voice here. >> >>> 2. The of_thermal_get_temp() output parameter 'temp' is an unsigned >>> value in order to conforms with the thermal framework 'get_temp' >>> function prototype. But the new sensor interface 'get_temp' callback >>> function (defined in __thermal_zone struct) expects 'temp' to be >>> signed. So technically, a negative value can be returned from the >>> underlying sensor function. Should some checks be added to >>> of_thermal_get_temp() to ensure that a negative value (i.e. a very large >>> unsigned value) won't be passed back to the thermal framework? Or >>> should the 'get_temp' function prototype in __thermal_zone struct be >>> changed with 'unsigned' temperature value and it will be the >>> responsibility of the underlying function to do the check? >>> >> I could for sure, add a warning inside of_thermal_get_temp(). But in >> general, I believe the thermal framework has to cover for signed >> temperature values, even if typical usage is on positive temperature >> range. Mainly for correct temperature representation. >> >> >>> 3. Your documentation (thermal.txt) seems to suggest that the >>> 'cooling-attachments' are one of the required properties for >>> 'thermal-zones' node in the device tree binding files. However, I don't >> Hmm... That was not the intention. >> >>> have any cooling device ready in my current patch series yet and >>> therefore I tried to leave out the 'cooling-attachments' node from the >>> 'thermal-zones' node. It seems to be working just find and I can >>> register the sensor and read out the temperature once the target >>> platform has been booted up. Is this your expectation that people can >>> leave the 'cooling-attachments' node out? I want to make sure I can >>> still submit a new patch set for this series with just the functionality >>> of reading out the temperature from the thermal sensor. >> So, let me try to clarify a couple of things. First thing is that the >> cooling-attachments has been renamed to cooling-maps, just a new naming >> convention. Also, there are thermal zones that do not have >> cooling-maps, they just describe thermal shutdown by software, thermal >> zones with only CRITICAL trip points, for instance. For this reason, >> thermal zones must be probed properly without cooling-maps. I need to >> double check the documentation in this case, I believe. > Just to clarify a bit, this does not mean we should allow having thermal > zones only for monitoring. If you are generating a thermal zone, it > means you want to cover thermal limits. The example I gave was a thermal > zone that does not have cooling-maps, but it does have a thermal > constraint, a trip point which is CRITICAL, meaning, the silicon state > is not reliable anymore. Hi Eduardo, Thanks for your clarification. Yes, there are thermal limits that I need to specify through the trip points. The issue I am facing is that I don't have the cooling device that needs to be associated with the trip point in this patch series yet. I was hoping to get the thermal sensor driver code into the mainline first. The addition for the cooling device and the "cooling-maps" node will be added in another patch series. Since this patch series is now gated by your work, I am wondering if you are targeting to get your patch series (http://lkml.org/lkml/2013/9/15/122) into 3.13? I would like to get an idea of the timeline such that I can plan out my work as well. Thanks! >>> Thanks, >>> -Wendy >>> >>> On 9/23/2013 4:46 PM, Eduardo Valentin wrote: >>>> On 23-09-2013 18:43, Wendy Ng wrote: >>>>> On 9/23/2013 11:19 AM, Eduardo Valentin wrote: >>>>>> On 23-09-2013 13:51, Wendy Ng wrote: >>>>>>> This adds the support for reading out temperature from Broadcom >>>>>>> bcm281xx >>>>>>> SoCs. >>>>>>> >>>>>>> Signed-off-by: Wendy Ng <wendy.ng@broadcom.com> >>>>>>> Reviewed-by: Markus Mayer <mmayer@broadcom.com> >>>>>>> Reviewed-by: Christian Daudt <csd@broadcom.com> >>>>>>> --- >>>>>>> .../bindings/thermal/bcm-kona-thermal.txt | 18 +++ >>>>>>> drivers/thermal/Kconfig | 10 ++ >>>>>>> drivers/thermal/Makefile | 1 + >>>>>>> drivers/thermal/bcm_thermal.c | 170 >>>>>>> ++++++++++++++++++++ >>>>>>> 4 files changed, 199 insertions(+) >>>>>>> create mode 100644 >>>>>>> Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>>>> create mode 100644 drivers/thermal/bcm_thermal.c >>>>>>> >>>>>>> diff --git >>>>>>> a/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>>>> b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>>>> new file mode 100644 >>>>>>> index 0000000..acca99e >>>>>>> --- /dev/null >>>>>>> +++ b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>>>> @@ -0,0 +1,18 @@ >>>>>>> +* Broadcom Kona Thermal Management Unit >>>>>>> + >>>>>>> +This version is for the BCM281xx family of SoCs. >>>>>>> + >>>>>>> +Required properties: >>>>>>> +- compatible : "brcm,bcm11351-thermal", "brcm,kona-thermal" >>>>>>> +- reg : Address range of the thermal register >>>>>>> +- thermal-name: this entry must be specified and it will be passed >>>>>>> into >>>>>>> +thermal_zone_device_register(). This name will also be reported >>>>>>> under Hwmon >>>>>>> +sysfs 'name' attribute. >>>>>>> + >>>>>>> +Example: >>>>>>> + thermal@34008000 { >>>>>>> + compatible = "brcm,bcm11351-thermal", "brcm,kona-thermal"; >>>>>>> + reg = <0x34008000 0x0024>; >>>>>>> + thermal-name = "bcm_kona_therm"; >>>>>>> + status = "disabled"; >>>>>>> + }; >>>>>>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >>>>>>> index dbfc390..7f823f0 100644 >>>>>>> --- a/drivers/thermal/Kconfig >>>>>>> +++ b/drivers/thermal/Kconfig >>>>>>> @@ -134,6 +134,16 @@ config KIRKWOOD_THERMAL >>>>>>> Support for the Kirkwood thermal sensor driver into the Linux >>>>>>> thermal >>>>>>> framework. Only kirkwood 88F6282 and 88F6283 have this >>>>>>> sensor. >>>>>>> +config BCM_THERMAL >>>>>>> + tristate "Temperature sensor on Broadcom BCM281xx family of SoCs" >>>>>>> + depends on ARCH_BCM >>>>>>> + default y >>>>>>> + help >>>>>>> + If you say yes here you get support for TMU (Thermal Management >>>>>>> + Unit) on Broadcom BCM281xx family of SoCs. This provides >>>>>>> thermal >>>>>>> + monitoring of CPU clusters, graphics, and SoC glue, but does >>>>>>> not >>>>>>> + include monitoring of charger temperature. >>>>>>> + >>>>>>> config DOVE_THERMAL >>>>>>> tristate "Temperature sensor on Marvell Dove SoCs" >>>>>>> depends on ARCH_DOVE >>>>>>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile >>>>>>> index 584b363..3ea8c1c 100644 >>>>>>> --- a/drivers/thermal/Makefile >>>>>>> +++ b/drivers/thermal/Makefile >>>>>>> @@ -21,6 +21,7 @@ obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o >>>>>>> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o >>>>>>> obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o >>>>>>> obj-y += samsung/ >>>>>>> +obj-$(CONFIG_BCM_THERMAL) += bcm_thermal.o >>>>>>> obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o >>>>>>> obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o >>>>>>> obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o >>>>>>> diff --git a/drivers/thermal/bcm_thermal.c >>>>>>> b/drivers/thermal/bcm_thermal.c >>>>>>> new file mode 100644 >>>>>>> index 0000000..131d3c4 >>>>>>> --- /dev/null >>>>>>> +++ b/drivers/thermal/bcm_thermal.c >>>>>>> @@ -0,0 +1,170 @@ >>>>>>> +/* >>>>>>> + * Copyright 2013 Broadcom Corporation. >>>>>>> + * >>>>>>> + * This program is free software; you can redistribute it and/or >>>>>>> modify >>>>>>> + * it under the terms of the GNU General Public License, version 2, >>>>>>> + * as published by the Free Software Foundation (the "GPL"). >>>>>>> + * >>>>>>> + * 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. >>>>>>> + * >>>>>>> + * A copy of the GPL is available at >>>>>>> http://www.broadcom.com/licenses/GPLv2.php, >>>>>>> + * or by writing to the Free Software Foundation, Inc., >>>>>>> + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. >>>>>>> + */ >>>>>>> + >>>>>>> +/** >>>>>>> +* Broadcom Thermal Management Unit - bcm_tmu >>>>>>> +*/ >>>>>>> +#include <linux/module.h> >>>>>>> +#include <linux/err.h> >>>>>>> +#include <linux/kernel.h> >>>>>>> +#include <linux/platform_device.h> >>>>>>> +#include <linux/io.h> >>>>>>> +#include <linux/thermal.h> >>>>>>> +#include <linux/of.h> >>>>>>> + >>>>>>> +/* From TMON Register Database */ >>>>>>> +#define TMON_TEMP_VAL_OFFSET 0x0000001c >>>>>>> +#define TMON_TEMP_VAL_TEMP_VAL_SHIFT 0 >>>>>>> +#define TMON_TEMP_VAL_TEMP_VAL_MASK 0x000003ff >>>>>>> + >>>>>>> +/* Broadcom Thermal Zone Device Structure */ >>>>>>> +struct bcm_thermal_zone_priv { >>>>>>> + char name[THERMAL_NAME_LENGTH]; >>>>>>> + void __iomem *base; >>>>>>> +}; >>>>>>> + >>>>>>> +/* Temperature conversion function for TMON block */ >>>>>>> +static long raw_to_mcelsius(u32 raw) >>>>>>> +{ >>>>>>> + /* >>>>>>> + * According to Broadcom internal Analog Module Specification >>>>>>> + * the formula for converting TMON block output to temperature in >>>>>>> + * degree Celsius is: >>>>>>> + * T = 428 - (0.561 * raw) >>>>>>> + * Note: the valid operating range for the TMON block is -40C to >>>>>>> 125C >>>>>>> + */ >>>>>>> + return 428000 - (561 * (long)raw); >>>>>>> +} >>>>>>> + >>>>>>> +/* Get temperature callback function for thermal zone */ >>>>>>> +static int bcm_get_temp(struct thermal_zone_device *thermal, >>>>>>> + unsigned long *temp) >>>>>>> +{ >>>>>>> + u32 raw; >>>>>>> + long mcelsius; >>>>>>> + struct bcm_thermal_zone_priv *priv = thermal->devdata; >>>>>>> + >>>>>>> + if (!priv) { >>>>>>> + pr_err("%s: thermal zone number %d devdata not >>>>>>> initialized.\n", >>>>>>> + __func__, thermal->id); >>>>>>> + return -EINVAL; >>>>>>> + } >>>>>>> + >>>>>>> + raw = (readl(priv->base + TMON_TEMP_VAL_OFFSET) >>>>>>> + & TMON_TEMP_VAL_TEMP_VAL_MASK) >> >>>>>>> TMON_TEMP_VAL_TEMP_VAL_SHIFT; >>>>>>> + >>>>>>> + pr_debug("%s: thermal zone number %d raw temp 0x%x\n", __func__, >>>>>>> + thermal->id, raw); >>>>>>> + >>>>>>> + mcelsius = raw_to_mcelsius(raw); >>>>>>> + >>>>>>> + /* >>>>>>> + * Since 'mcelsius' might be negative, we need to limit it to >>>>>>> smallest >>>>>>> + * unsigned value before returning it to thermal framework. >>>>>>> + */ >>>>>>> + if (mcelsius < 0) >>>>>>> + *temp = 0; >>>>>>> + else >>>>>>> + *temp = mcelsius; >>>>>>> + >>>>>>> + pr_debug("%s: thermal zone number %d final temp %d\n", __func__, >>>>>>> + thermal->id, (int) *temp); >>>>>>> + >>>>>>> + return 0; >>>>>>> +} >>>>>>> + >>>>>>> +/* Operation callback functions for thermal zone */ >>>>>>> +static struct thermal_zone_device_ops bcm_dev_ops = { >>>>>>> + .get_temp = bcm_get_temp, >>>>>>> +}; >>>>>>> + >>>>>>> +static const struct of_device_id bcm_tmu_match_table[] = { >>>>>>> + { .compatible = "brcm,kona-thermal" }, >>>>>>> + {}, >>>>>>> +}; >>>>>>> +MODULE_DEVICE_TABLE(of, bcm_tmu_match_table); >>>>>>> + >>>>>>> +static int bcm_tmu_probe(struct platform_device *pdev) >>>>>>> +{ >>>>>>> + struct thermal_zone_device *thermal = NULL; >>>>>>> + struct bcm_thermal_zone_priv *priv; >>>>>>> + struct resource *res; >>>>>>> + const char *str; >>>>>>> + >>>>>>> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); >>>>>>> + if (!priv) { >>>>>>> + dev_err(&pdev->dev, "Failed to malloc priv.\n"); >>>>>>> + return -ENOMEM; >>>>>>> + } >>>>>>> + >>>>>>> + /* Obtain the tmu name from device tree file */ >>>>>>> + if (of_property_read_string(pdev->dev.of_node, "thermal-name", >>>>>> Hello Wendy, >>>>>> >>>>>> I would prefer we wait until the work for thermal data [1] gets >>>>>> accepted >>>>>> before accepting this driver, specially because you are adding device >>>>>> specific DT entry to help in your registration with the thermal >>>>>> framework. With the mentioned work you wont need it at all. >>>>>> >>>>>> All best, >>>>>> >>>>>> [1] - http://lkml.org/lkml/2013/9/15/122 >>>>> Hello Eduardo, >>>>> >>>>> Since your changes are quite extensive, would you recommend me to get >>>>> your 16 patches into my local workspace and try to integrate the code >>>>> from my patches on the top of your patches at this time? Or should I >>>>> wait until your patches get accepted. >>>> Hello again Wendy, >>>> >>>> The only part I am concerned is the device tree entry you are creating >>>> for your device/driver. That could be obsolete in near future with the >>>> work I am doing currently. >>>> >>>> The work is, as you mentioned, quite extensive, but should make things >>>> easier for device driver writer. If you want, of course, it would be >>>> great if you could rebase your work on top of mine and try it out on >>>> your side and let me know the outcome. >>>> >>>> Comments on the proposed binding and documentation is also welcome. Let >>>> me know if there is something that it is not clear. >>>> >>>>> Thanks, >>>>> -Wendy >>>>>>> + &str) == 0) { >>>>>>> + strlcpy(priv->name, str, sizeof(priv->name)); >>>>>>> + } else { >>>>>>> + dev_err(&pdev->dev, "Failed to get thermal-name from DT.\n"); >>>>>>> + return -EINVAL; >>>>>>> + } >>>>>>> + >>>>>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>>>>>> + priv->base = devm_ioremap_resource(&pdev->dev, res); >>>>>>> + if (IS_ERR(priv->base)) >>>>>>> + return PTR_ERR(priv->base); >>>>>>> + >>>>>>> + thermal = thermal_zone_device_register(priv->name, 0, 0, priv, >>>>>>> + &bcm_dev_ops, NULL, 0, 0); >>>>>>> + if (IS_ERR(thermal)) { >>>>>>> + dev_err(&pdev->dev, >>>>>>> + "Failed to register Broadcom thermal zone device.\n"); >>>>>>> + return PTR_ERR(thermal); >>>>>>> + } >>>>>>> + >>>>>>> + platform_set_drvdata(pdev, thermal); >>>>>>> + >>>>>>> + dev_info(&pdev->dev, "Broadcom Thermal Monitor Initialized.\n"); >>>>>>> + >>>>>>> + return 0; >>>>>>> +} >>>>>>> + >>>>>>> +static int bcm_tmu_remove(struct platform_device *pdev) >>>>>>> +{ >>>>>>> + struct thermal_zone_device *broadcom_thermal = >>>>>>> + platform_get_drvdata(pdev); >>>>>>> + >>>>>>> + thermal_zone_device_unregister(broadcom_thermal); >>>>>>> + >>>>>>> + dev_info(&pdev->dev, "Broadcom Thermal Monitor >>>>>>> Uninitialized.\n"); >>>>>>> + >>>>>>> + return 0; >>>>>>> +} >>>>>>> + >>>>>>> +static struct platform_driver bcm_tmu_driver = { >>>>>>> + .driver = { >>>>>>> + .name = "bcm-thermal", >>>>>>> + .owner = THIS_MODULE, >>>>>>> + .of_match_table = bcm_tmu_match_table, >>>>>>> + }, >>>>>>> + .probe = bcm_tmu_probe, >>>>>>> + .remove = bcm_tmu_remove, >>>>>>> +}; >>>>>>> + >>>>>>> +module_platform_driver(bcm_tmu_driver); >>>>>>> + >>>>>>> +MODULE_DESCRIPTION("Broadcom Thermal Driver"); >>>>>>> +MODULE_AUTHOR("Broadcom"); >>>>>>> +MODULE_LICENSE("GPL v2"); >>>>>>> +MODULE_ALIAS("platform:bcm-thermal"); >>>>>>> >> > -- Best regards, -Wendy ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/3] thermal: bcm281xx: Add thermal driver 2013-10-07 17:52 ` Wendy Ng @ 2013-10-07 22:32 ` Eduardo Valentin 2013-10-07 23:11 ` Wendy Ng 0 siblings, 1 reply; 15+ messages in thread From: Eduardo Valentin @ 2013-10-07 22:32 UTC (permalink / raw) To: Wendy Ng Cc: Eduardo Valentin, Mark Rutland, Rob Herring, Stephen Warren, devicetree, linux-kernel, linux-pm, Christian Daudt, Markus Mayer [-- Attachment #1: Type: text/plain, Size: 19441 bytes --] On 07-10-2013 13:52, Wendy Ng wrote: > > On 10/7/2013 9:12 AM, Eduardo Valentin wrote: >> On 07-10-2013 10:52, Eduardo Valentin wrote: >>> On 04-10-2013 18:17, Wendy Ng wrote: >>>> Hello Eduardo, >>>> >>> Hello Wendy, >>> >>>> I have rebased my work on the top of yours and tried out the new way of >>>> registering the thermal zone. The new method is certainly making >>>> things easier for me to create a new thermal zone device driver. But I >>>> have some questions and I hope to hear back from you before I upload my >>>> new patch set that is based on your changes. >>> Great that you gave it a shot. Thanks for that. >>> >>>> 1. I found that the hwmon sysfs interface is no longer created when I >>>> call thermal_zone_of_sensor_register() to register my thermal >>>> sensor. I >>>> believe it is because you purposely hard-coded 'no_hwmon' to true. >>>> Would it be possible to let the users to control this option as part of >>>> the sensor register function? >>> Hmmm.. I also thought of allowing the thermal to hwmon interface >>> configurable. But the interface gets created in different path from the >>> sensor registration, which makes things a bit harder. The zones are >>> probed while parsing the DT file. While the sensors get linked, >>> thermal_zone_of_sensor_register(), typically when sensors are probed. >>> >>> Do you have a real use case for using the thermal to hwmon interface? >>> Durgadoss (original author) and Rui were considering deprecating and >>> finally removing it. If yes, it is time to rise your voice here. >>> >>>> 2. The of_thermal_get_temp() output parameter 'temp' is an unsigned >>>> value in order to conforms with the thermal framework 'get_temp' >>>> function prototype. But the new sensor interface 'get_temp' callback >>>> function (defined in __thermal_zone struct) expects 'temp' to be >>>> signed. So technically, a negative value can be returned from the >>>> underlying sensor function. Should some checks be added to >>>> of_thermal_get_temp() to ensure that a negative value (i.e. a very >>>> large >>>> unsigned value) won't be passed back to the thermal framework? Or >>>> should the 'get_temp' function prototype in __thermal_zone struct be >>>> changed with 'unsigned' temperature value and it will be the >>>> responsibility of the underlying function to do the check? >>>> >>> I could for sure, add a warning inside of_thermal_get_temp(). But in >>> general, I believe the thermal framework has to cover for signed >>> temperature values, even if typical usage is on positive temperature >>> range. Mainly for correct temperature representation. >>> >>> >>>> 3. Your documentation (thermal.txt) seems to suggest that the >>>> 'cooling-attachments' are one of the required properties for >>>> 'thermal-zones' node in the device tree binding files. However, I >>>> don't >>> Hmm... That was not the intention. >>> >>>> have any cooling device ready in my current patch series yet and >>>> therefore I tried to leave out the 'cooling-attachments' node from the >>>> 'thermal-zones' node. It seems to be working just find and I can >>>> register the sensor and read out the temperature once the target >>>> platform has been booted up. Is this your expectation that people can >>>> leave the 'cooling-attachments' node out? I want to make sure I can >>>> still submit a new patch set for this series with just the >>>> functionality >>>> of reading out the temperature from the thermal sensor. >>> So, let me try to clarify a couple of things. First thing is that the >>> cooling-attachments has been renamed to cooling-maps, just a new naming >>> convention. Also, there are thermal zones that do not have >>> cooling-maps, they just describe thermal shutdown by software, thermal >>> zones with only CRITICAL trip points, for instance. For this reason, >>> thermal zones must be probed properly without cooling-maps. I need to >>> double check the documentation in this case, I believe. >> Just to clarify a bit, this does not mean we should allow having thermal >> zones only for monitoring. If you are generating a thermal zone, it >> means you want to cover thermal limits. The example I gave was a thermal >> zone that does not have cooling-maps, but it does have a thermal >> constraint, a trip point which is CRITICAL, meaning, the silicon state >> is not reliable anymore. > Hi Eduardo, > > Thanks for your clarification. Yes, there are thermal limits that I > need to specify through the trip points. The issue I am facing is that > I don't have the cooling device that needs to be associated with the > trip point in this patch series yet. I was hoping to get the thermal > sensor driver code into the mainline first. The addition for the > cooling device and the "cooling-maps" node will be added in another > patch series. Wendy, Let me try to understand it properly. What cooling device is missing? Is it only the kernel code or the its DT bindings too? Does it prevent you to define the bindings? I believe it should be fine to have the bindings without the kernel code (as long as the bindings are correct). I have also tried this patch series on top of a systems with missing cpufreq support. That means, I had all the thermal bindings, but the cooling device was not loaded in the system. Unfortunately, the zones would only have the critical trip points as runtime effect. But nothing really broke dramatically. > > Since this patch series is now gated by your work, I am wondering if you > are targeting to get your patch series > (http://lkml.org/lkml/2013/9/15/122) into 3.13? I would like to get an > idea of the timeline such that I can plan out my work as well. Regarding timing, I cannot promise you that my patch series is making 3.13, because I cannot proceed / queue this work without a proper review and acks from device tree maintainers. I would really appreciate if we could make it for 3.13, but that is not only on my hands. As Mark R. said, it is a bit complex binding and it is better to have more than one device tree maintainer review/ack. Regarding your driver, my major concern on it is just the fact that you are using one driver specific device tree property, which will get soon deprecated. That is why I have kindly requested you to wait on my work, this way we avoid compatibility issues between DT and kernel version. > > Thanks! >>>> Thanks, >>>> -Wendy >>>> >>>> On 9/23/2013 4:46 PM, Eduardo Valentin wrote: >>>>> On 23-09-2013 18:43, Wendy Ng wrote: >>>>>> On 9/23/2013 11:19 AM, Eduardo Valentin wrote: >>>>>>> On 23-09-2013 13:51, Wendy Ng wrote: >>>>>>>> This adds the support for reading out temperature from Broadcom >>>>>>>> bcm281xx >>>>>>>> SoCs. >>>>>>>> >>>>>>>> Signed-off-by: Wendy Ng <wendy.ng@broadcom.com> >>>>>>>> Reviewed-by: Markus Mayer <mmayer@broadcom.com> >>>>>>>> Reviewed-by: Christian Daudt <csd@broadcom.com> >>>>>>>> --- >>>>>>>> .../bindings/thermal/bcm-kona-thermal.txt | 18 +++ >>>>>>>> drivers/thermal/Kconfig | 10 ++ >>>>>>>> drivers/thermal/Makefile | 1 + >>>>>>>> drivers/thermal/bcm_thermal.c | 170 >>>>>>>> ++++++++++++++++++++ >>>>>>>> 4 files changed, 199 insertions(+) >>>>>>>> create mode 100644 >>>>>>>> Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>>>>> create mode 100644 drivers/thermal/bcm_thermal.c >>>>>>>> >>>>>>>> diff --git >>>>>>>> a/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>>>>> b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>>>>> new file mode 100644 >>>>>>>> index 0000000..acca99e >>>>>>>> --- /dev/null >>>>>>>> +++ >>>>>>>> b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>>>>> @@ -0,0 +1,18 @@ >>>>>>>> +* Broadcom Kona Thermal Management Unit >>>>>>>> + >>>>>>>> +This version is for the BCM281xx family of SoCs. >>>>>>>> + >>>>>>>> +Required properties: >>>>>>>> +- compatible : "brcm,bcm11351-thermal", "brcm,kona-thermal" >>>>>>>> +- reg : Address range of the thermal register >>>>>>>> +- thermal-name: this entry must be specified and it will be passed >>>>>>>> into >>>>>>>> +thermal_zone_device_register(). This name will also be reported >>>>>>>> under Hwmon >>>>>>>> +sysfs 'name' attribute. >>>>>>>> + >>>>>>>> +Example: >>>>>>>> + thermal@34008000 { >>>>>>>> + compatible = "brcm,bcm11351-thermal", "brcm,kona-thermal"; >>>>>>>> + reg = <0x34008000 0x0024>; >>>>>>>> + thermal-name = "bcm_kona_therm"; >>>>>>>> + status = "disabled"; >>>>>>>> + }; >>>>>>>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >>>>>>>> index dbfc390..7f823f0 100644 >>>>>>>> --- a/drivers/thermal/Kconfig >>>>>>>> +++ b/drivers/thermal/Kconfig >>>>>>>> @@ -134,6 +134,16 @@ config KIRKWOOD_THERMAL >>>>>>>> Support for the Kirkwood thermal sensor driver into >>>>>>>> the Linux >>>>>>>> thermal >>>>>>>> framework. Only kirkwood 88F6282 and 88F6283 have this >>>>>>>> sensor. >>>>>>>> +config BCM_THERMAL >>>>>>>> + tristate "Temperature sensor on Broadcom BCM281xx family of >>>>>>>> SoCs" >>>>>>>> + depends on ARCH_BCM >>>>>>>> + default y >>>>>>>> + help >>>>>>>> + If you say yes here you get support for TMU (Thermal >>>>>>>> Management >>>>>>>> + Unit) on Broadcom BCM281xx family of SoCs. This provides >>>>>>>> thermal >>>>>>>> + monitoring of CPU clusters, graphics, and SoC glue, but does >>>>>>>> not >>>>>>>> + include monitoring of charger temperature. >>>>>>>> + >>>>>>>> config DOVE_THERMAL >>>>>>>> tristate "Temperature sensor on Marvell Dove SoCs" >>>>>>>> depends on ARCH_DOVE >>>>>>>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile >>>>>>>> index 584b363..3ea8c1c 100644 >>>>>>>> --- a/drivers/thermal/Makefile >>>>>>>> +++ b/drivers/thermal/Makefile >>>>>>>> @@ -21,6 +21,7 @@ obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o >>>>>>>> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o >>>>>>>> obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o >>>>>>>> obj-y += samsung/ >>>>>>>> +obj-$(CONFIG_BCM_THERMAL) += bcm_thermal.o >>>>>>>> obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o >>>>>>>> obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o >>>>>>>> obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o >>>>>>>> diff --git a/drivers/thermal/bcm_thermal.c >>>>>>>> b/drivers/thermal/bcm_thermal.c >>>>>>>> new file mode 100644 >>>>>>>> index 0000000..131d3c4 >>>>>>>> --- /dev/null >>>>>>>> +++ b/drivers/thermal/bcm_thermal.c >>>>>>>> @@ -0,0 +1,170 @@ >>>>>>>> +/* >>>>>>>> + * Copyright 2013 Broadcom Corporation. >>>>>>>> + * >>>>>>>> + * This program is free software; you can redistribute it and/or >>>>>>>> modify >>>>>>>> + * it under the terms of the GNU General Public License, >>>>>>>> version 2, >>>>>>>> + * as published by the Free Software Foundation (the "GPL"). >>>>>>>> + * >>>>>>>> + * 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. >>>>>>>> + * >>>>>>>> + * A copy of the GPL is available at >>>>>>>> http://www.broadcom.com/licenses/GPLv2.php, >>>>>>>> + * or by writing to the Free Software Foundation, Inc., >>>>>>>> + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. >>>>>>>> + */ >>>>>>>> + >>>>>>>> +/** >>>>>>>> +* Broadcom Thermal Management Unit - bcm_tmu >>>>>>>> +*/ >>>>>>>> +#include <linux/module.h> >>>>>>>> +#include <linux/err.h> >>>>>>>> +#include <linux/kernel.h> >>>>>>>> +#include <linux/platform_device.h> >>>>>>>> +#include <linux/io.h> >>>>>>>> +#include <linux/thermal.h> >>>>>>>> +#include <linux/of.h> >>>>>>>> + >>>>>>>> +/* From TMON Register Database */ >>>>>>>> +#define TMON_TEMP_VAL_OFFSET 0x0000001c >>>>>>>> +#define TMON_TEMP_VAL_TEMP_VAL_SHIFT 0 >>>>>>>> +#define TMON_TEMP_VAL_TEMP_VAL_MASK 0x000003ff >>>>>>>> + >>>>>>>> +/* Broadcom Thermal Zone Device Structure */ >>>>>>>> +struct bcm_thermal_zone_priv { >>>>>>>> + char name[THERMAL_NAME_LENGTH]; >>>>>>>> + void __iomem *base; >>>>>>>> +}; >>>>>>>> + >>>>>>>> +/* Temperature conversion function for TMON block */ >>>>>>>> +static long raw_to_mcelsius(u32 raw) >>>>>>>> +{ >>>>>>>> + /* >>>>>>>> + * According to Broadcom internal Analog Module Specification >>>>>>>> + * the formula for converting TMON block output to >>>>>>>> temperature in >>>>>>>> + * degree Celsius is: >>>>>>>> + * T = 428 - (0.561 * raw) >>>>>>>> + * Note: the valid operating range for the TMON block is >>>>>>>> -40C to >>>>>>>> 125C >>>>>>>> + */ >>>>>>>> + return 428000 - (561 * (long)raw); >>>>>>>> +} >>>>>>>> + >>>>>>>> +/* Get temperature callback function for thermal zone */ >>>>>>>> +static int bcm_get_temp(struct thermal_zone_device *thermal, >>>>>>>> + unsigned long *temp) >>>>>>>> +{ >>>>>>>> + u32 raw; >>>>>>>> + long mcelsius; >>>>>>>> + struct bcm_thermal_zone_priv *priv = thermal->devdata; >>>>>>>> + >>>>>>>> + if (!priv) { >>>>>>>> + pr_err("%s: thermal zone number %d devdata not >>>>>>>> initialized.\n", >>>>>>>> + __func__, thermal->id); >>>>>>>> + return -EINVAL; >>>>>>>> + } >>>>>>>> + >>>>>>>> + raw = (readl(priv->base + TMON_TEMP_VAL_OFFSET) >>>>>>>> + & TMON_TEMP_VAL_TEMP_VAL_MASK) >> >>>>>>>> TMON_TEMP_VAL_TEMP_VAL_SHIFT; >>>>>>>> + >>>>>>>> + pr_debug("%s: thermal zone number %d raw temp 0x%x\n", >>>>>>>> __func__, >>>>>>>> + thermal->id, raw); >>>>>>>> + >>>>>>>> + mcelsius = raw_to_mcelsius(raw); >>>>>>>> + >>>>>>>> + /* >>>>>>>> + * Since 'mcelsius' might be negative, we need to limit it to >>>>>>>> smallest >>>>>>>> + * unsigned value before returning it to thermal framework. >>>>>>>> + */ >>>>>>>> + if (mcelsius < 0) >>>>>>>> + *temp = 0; >>>>>>>> + else >>>>>>>> + *temp = mcelsius; >>>>>>>> + >>>>>>>> + pr_debug("%s: thermal zone number %d final temp %d\n", >>>>>>>> __func__, >>>>>>>> + thermal->id, (int) *temp); >>>>>>>> + >>>>>>>> + return 0; >>>>>>>> +} >>>>>>>> + >>>>>>>> +/* Operation callback functions for thermal zone */ >>>>>>>> +static struct thermal_zone_device_ops bcm_dev_ops = { >>>>>>>> + .get_temp = bcm_get_temp, >>>>>>>> +}; >>>>>>>> + >>>>>>>> +static const struct of_device_id bcm_tmu_match_table[] = { >>>>>>>> + { .compatible = "brcm,kona-thermal" }, >>>>>>>> + {}, >>>>>>>> +}; >>>>>>>> +MODULE_DEVICE_TABLE(of, bcm_tmu_match_table); >>>>>>>> + >>>>>>>> +static int bcm_tmu_probe(struct platform_device *pdev) >>>>>>>> +{ >>>>>>>> + struct thermal_zone_device *thermal = NULL; >>>>>>>> + struct bcm_thermal_zone_priv *priv; >>>>>>>> + struct resource *res; >>>>>>>> + const char *str; >>>>>>>> + >>>>>>>> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); >>>>>>>> + if (!priv) { >>>>>>>> + dev_err(&pdev->dev, "Failed to malloc priv.\n"); >>>>>>>> + return -ENOMEM; >>>>>>>> + } >>>>>>>> + >>>>>>>> + /* Obtain the tmu name from device tree file */ >>>>>>>> + if (of_property_read_string(pdev->dev.of_node, "thermal-name", >>>>>>> Hello Wendy, >>>>>>> >>>>>>> I would prefer we wait until the work for thermal data [1] gets >>>>>>> accepted >>>>>>> before accepting this driver, specially because you are adding >>>>>>> device >>>>>>> specific DT entry to help in your registration with the thermal >>>>>>> framework. With the mentioned work you wont need it at all. >>>>>>> >>>>>>> All best, >>>>>>> >>>>>>> [1] - http://lkml.org/lkml/2013/9/15/122 >>>>>> Hello Eduardo, >>>>>> >>>>>> Since your changes are quite extensive, would you recommend me to get >>>>>> your 16 patches into my local workspace and try to integrate the code >>>>>> from my patches on the top of your patches at this time? Or should I >>>>>> wait until your patches get accepted. >>>>> Hello again Wendy, >>>>> >>>>> The only part I am concerned is the device tree entry you are creating >>>>> for your device/driver. That could be obsolete in near future with the >>>>> work I am doing currently. >>>>> >>>>> The work is, as you mentioned, quite extensive, but should make things >>>>> easier for device driver writer. If you want, of course, it would be >>>>> great if you could rebase your work on top of mine and try it out on >>>>> your side and let me know the outcome. >>>>> >>>>> Comments on the proposed binding and documentation is also welcome. >>>>> Let >>>>> me know if there is something that it is not clear. >>>>> >>>>>> Thanks, >>>>>> -Wendy >>>>>>>> + &str) == 0) { >>>>>>>> + strlcpy(priv->name, str, sizeof(priv->name)); >>>>>>>> + } else { >>>>>>>> + dev_err(&pdev->dev, "Failed to get thermal-name from >>>>>>>> DT.\n"); >>>>>>>> + return -EINVAL; >>>>>>>> + } >>>>>>>> + >>>>>>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>>>>>>> + priv->base = devm_ioremap_resource(&pdev->dev, res); >>>>>>>> + if (IS_ERR(priv->base)) >>>>>>>> + return PTR_ERR(priv->base); >>>>>>>> + >>>>>>>> + thermal = thermal_zone_device_register(priv->name, 0, 0, priv, >>>>>>>> + &bcm_dev_ops, NULL, 0, 0); >>>>>>>> + if (IS_ERR(thermal)) { >>>>>>>> + dev_err(&pdev->dev, >>>>>>>> + "Failed to register Broadcom thermal zone device.\n"); >>>>>>>> + return PTR_ERR(thermal); >>>>>>>> + } >>>>>>>> + >>>>>>>> + platform_set_drvdata(pdev, thermal); >>>>>>>> + >>>>>>>> + dev_info(&pdev->dev, "Broadcom Thermal Monitor >>>>>>>> Initialized.\n"); >>>>>>>> + >>>>>>>> + return 0; >>>>>>>> +} >>>>>>>> + >>>>>>>> +static int bcm_tmu_remove(struct platform_device *pdev) >>>>>>>> +{ >>>>>>>> + struct thermal_zone_device *broadcom_thermal = >>>>>>>> + platform_get_drvdata(pdev); >>>>>>>> + >>>>>>>> + thermal_zone_device_unregister(broadcom_thermal); >>>>>>>> + >>>>>>>> + dev_info(&pdev->dev, "Broadcom Thermal Monitor >>>>>>>> Uninitialized.\n"); >>>>>>>> + >>>>>>>> + return 0; >>>>>>>> +} >>>>>>>> + >>>>>>>> +static struct platform_driver bcm_tmu_driver = { >>>>>>>> + .driver = { >>>>>>>> + .name = "bcm-thermal", >>>>>>>> + .owner = THIS_MODULE, >>>>>>>> + .of_match_table = bcm_tmu_match_table, >>>>>>>> + }, >>>>>>>> + .probe = bcm_tmu_probe, >>>>>>>> + .remove = bcm_tmu_remove, >>>>>>>> +}; >>>>>>>> + >>>>>>>> +module_platform_driver(bcm_tmu_driver); >>>>>>>> + >>>>>>>> +MODULE_DESCRIPTION("Broadcom Thermal Driver"); >>>>>>>> +MODULE_AUTHOR("Broadcom"); >>>>>>>> +MODULE_LICENSE("GPL v2"); >>>>>>>> +MODULE_ALIAS("platform:bcm-thermal"); >>>>>>>> >>> >> > -- You have got to be excited about what you are doing. (L. Lamport) Eduardo Valentin [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 295 bytes --] ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/3] thermal: bcm281xx: Add thermal driver 2013-10-07 22:32 ` Eduardo Valentin @ 2013-10-07 23:11 ` Wendy Ng 0 siblings, 0 replies; 15+ messages in thread From: Wendy Ng @ 2013-10-07 23:11 UTC (permalink / raw) To: Eduardo Valentin Cc: Mark Rutland, Rob Herring, Stephen Warren, devicetree, linux-kernel, linux-pm, Christian Daudt, Markus Mayer On 10/7/2013 3:32 PM, Eduardo Valentin wrote: > On 07-10-2013 13:52, Wendy Ng wrote: >> On 10/7/2013 9:12 AM, Eduardo Valentin wrote: >>> On 07-10-2013 10:52, Eduardo Valentin wrote: >>>> On 04-10-2013 18:17, Wendy Ng wrote: >>>>> Hello Eduardo, >>>>> >>>> Hello Wendy, >>>> >>>>> I have rebased my work on the top of yours and tried out the new way of >>>>> registering the thermal zone. The new method is certainly making >>>>> things easier for me to create a new thermal zone device driver. But I >>>>> have some questions and I hope to hear back from you before I upload my >>>>> new patch set that is based on your changes. >>>> Great that you gave it a shot. Thanks for that. >>>> >>>>> 1. I found that the hwmon sysfs interface is no longer created when I >>>>> call thermal_zone_of_sensor_register() to register my thermal >>>>> sensor. I >>>>> believe it is because you purposely hard-coded 'no_hwmon' to true. >>>>> Would it be possible to let the users to control this option as part of >>>>> the sensor register function? >>>> Hmmm.. I also thought of allowing the thermal to hwmon interface >>>> configurable. But the interface gets created in different path from the >>>> sensor registration, which makes things a bit harder. The zones are >>>> probed while parsing the DT file. While the sensors get linked, >>>> thermal_zone_of_sensor_register(), typically when sensors are probed. >>>> >>>> Do you have a real use case for using the thermal to hwmon interface? >>>> Durgadoss (original author) and Rui were considering deprecating and >>>> finally removing it. If yes, it is time to rise your voice here. >>>> >>>>> 2. The of_thermal_get_temp() output parameter 'temp' is an unsigned >>>>> value in order to conforms with the thermal framework 'get_temp' >>>>> function prototype. But the new sensor interface 'get_temp' callback >>>>> function (defined in __thermal_zone struct) expects 'temp' to be >>>>> signed. So technically, a negative value can be returned from the >>>>> underlying sensor function. Should some checks be added to >>>>> of_thermal_get_temp() to ensure that a negative value (i.e. a very >>>>> large >>>>> unsigned value) won't be passed back to the thermal framework? Or >>>>> should the 'get_temp' function prototype in __thermal_zone struct be >>>>> changed with 'unsigned' temperature value and it will be the >>>>> responsibility of the underlying function to do the check? >>>>> >>>> I could for sure, add a warning inside of_thermal_get_temp(). But in >>>> general, I believe the thermal framework has to cover for signed >>>> temperature values, even if typical usage is on positive temperature >>>> range. Mainly for correct temperature representation. >>>> >>>> >>>>> 3. Your documentation (thermal.txt) seems to suggest that the >>>>> 'cooling-attachments' are one of the required properties for >>>>> 'thermal-zones' node in the device tree binding files. However, I >>>>> don't >>>> Hmm... That was not the intention. >>>> >>>>> have any cooling device ready in my current patch series yet and >>>>> therefore I tried to leave out the 'cooling-attachments' node from the >>>>> 'thermal-zones' node. It seems to be working just find and I can >>>>> register the sensor and read out the temperature once the target >>>>> platform has been booted up. Is this your expectation that people can >>>>> leave the 'cooling-attachments' node out? I want to make sure I can >>>>> still submit a new patch set for this series with just the >>>>> functionality >>>>> of reading out the temperature from the thermal sensor. >>>> So, let me try to clarify a couple of things. First thing is that the >>>> cooling-attachments has been renamed to cooling-maps, just a new naming >>>> convention. Also, there are thermal zones that do not have >>>> cooling-maps, they just describe thermal shutdown by software, thermal >>>> zones with only CRITICAL trip points, for instance. For this reason, >>>> thermal zones must be probed properly without cooling-maps. I need to >>>> double check the documentation in this case, I believe. >>> Just to clarify a bit, this does not mean we should allow having thermal >>> zones only for monitoring. If you are generating a thermal zone, it >>> means you want to cover thermal limits. The example I gave was a thermal >>> zone that does not have cooling-maps, but it does have a thermal >>> constraint, a trip point which is CRITICAL, meaning, the silicon state >>> is not reliable anymore. >> Hi Eduardo, >> >> Thanks for your clarification. Yes, there are thermal limits that I >> need to specify through the trip points. The issue I am facing is that >> I don't have the cooling device that needs to be associated with the >> trip point in this patch series yet. I was hoping to get the thermal >> sensor driver code into the mainline first. The addition for the >> cooling device and the "cooling-maps" node will be added in another >> patch series. > Wendy, > > Let me try to understand it properly. What cooling device is missing? Is > it only the kernel code or the its DT bindings too? Does it prevent you > to define the bindings? I believe it should be fine to have the bindings > without the kernel code (as long as the bindings are correct). > > I have also tried this patch series on top of a systems with missing > cpufreq support. That means, I had all the thermal bindings, but the > cooling device was not loaded in the system. Unfortunately, the zones > would only have the critical trip points as runtime effect. But nothing > really broke dramatically. > Hi Eduardo, Sorry, I probably have confused you. You are correct -- things seem to work just fine for me when I have all the thermal binding specified in the device tree file (*.dts/dtsi) despite the missing cpufreq support in my kernel code. I even tried to remove the 'cooling-attachments' (a.k.a cooling-maps) from the device tree files and the thermal sensor can still be registered to the thermal zone. So my original question about the documentation is just to get a clarification on what is the expected behavior when I left out what is specified as the *required* properties in the thermal-zones node in the device tree file. > >> Since this patch series is now gated by your work, I am wondering if you >> are targeting to get your patch series >> (http://lkml.org/lkml/2013/9/15/122) into 3.13? I would like to get an >> idea of the timeline such that I can plan out my work as well. > Regarding timing, I cannot promise you that my patch series is making > 3.13, because I cannot proceed / queue this work without a proper review > and acks from device tree maintainers. I would really appreciate if we > could make it for 3.13, but that is not only on my hands. As Mark R. > said, it is a bit complex binding and it is better to have more than one > device tree maintainer review/ack. > > Regarding your driver, my major concern on it is just the fact that you > are using one driver specific device tree property, which will get soon > deprecated. That is why I have kindly requested you to wait on my work, > this way we avoid compatibility issues between DT and kernel version. >> Thanks! >>>>> Thanks, >>>>> -Wendy >>>>> >>>>> On 9/23/2013 4:46 PM, Eduardo Valentin wrote: >>>>>> On 23-09-2013 18:43, Wendy Ng wrote: >>>>>>> On 9/23/2013 11:19 AM, Eduardo Valentin wrote: >>>>>>>> On 23-09-2013 13:51, Wendy Ng wrote: >>>>>>>>> This adds the support for reading out temperature from Broadcom >>>>>>>>> bcm281xx >>>>>>>>> SoCs. >>>>>>>>> >>>>>>>>> Signed-off-by: Wendy Ng <wendy.ng@broadcom.com> >>>>>>>>> Reviewed-by: Markus Mayer <mmayer@broadcom.com> >>>>>>>>> Reviewed-by: Christian Daudt <csd@broadcom.com> >>>>>>>>> --- >>>>>>>>> .../bindings/thermal/bcm-kona-thermal.txt | 18 +++ >>>>>>>>> drivers/thermal/Kconfig | 10 ++ >>>>>>>>> drivers/thermal/Makefile | 1 + >>>>>>>>> drivers/thermal/bcm_thermal.c | 170 >>>>>>>>> ++++++++++++++++++++ >>>>>>>>> 4 files changed, 199 insertions(+) >>>>>>>>> create mode 100644 >>>>>>>>> Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>>>>>> create mode 100644 drivers/thermal/bcm_thermal.c >>>>>>>>> >>>>>>>>> diff --git >>>>>>>>> a/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>>>>>> b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>>>>>> new file mode 100644 >>>>>>>>> index 0000000..acca99e >>>>>>>>> --- /dev/null >>>>>>>>> +++ >>>>>>>>> b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >>>>>>>>> @@ -0,0 +1,18 @@ >>>>>>>>> +* Broadcom Kona Thermal Management Unit >>>>>>>>> + >>>>>>>>> +This version is for the BCM281xx family of SoCs. >>>>>>>>> + >>>>>>>>> +Required properties: >>>>>>>>> +- compatible : "brcm,bcm11351-thermal", "brcm,kona-thermal" >>>>>>>>> +- reg : Address range of the thermal register >>>>>>>>> +- thermal-name: this entry must be specified and it will be passed >>>>>>>>> into >>>>>>>>> +thermal_zone_device_register(). This name will also be reported >>>>>>>>> under Hwmon >>>>>>>>> +sysfs 'name' attribute. >>>>>>>>> + >>>>>>>>> +Example: >>>>>>>>> + thermal@34008000 { >>>>>>>>> + compatible = "brcm,bcm11351-thermal", "brcm,kona-thermal"; >>>>>>>>> + reg = <0x34008000 0x0024>; >>>>>>>>> + thermal-name = "bcm_kona_therm"; >>>>>>>>> + status = "disabled"; >>>>>>>>> + }; >>>>>>>>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >>>>>>>>> index dbfc390..7f823f0 100644 >>>>>>>>> --- a/drivers/thermal/Kconfig >>>>>>>>> +++ b/drivers/thermal/Kconfig >>>>>>>>> @@ -134,6 +134,16 @@ config KIRKWOOD_THERMAL >>>>>>>>> Support for the Kirkwood thermal sensor driver into >>>>>>>>> the Linux >>>>>>>>> thermal >>>>>>>>> framework. Only kirkwood 88F6282 and 88F6283 have this >>>>>>>>> sensor. >>>>>>>>> +config BCM_THERMAL >>>>>>>>> + tristate "Temperature sensor on Broadcom BCM281xx family of >>>>>>>>> SoCs" >>>>>>>>> + depends on ARCH_BCM >>>>>>>>> + default y >>>>>>>>> + help >>>>>>>>> + If you say yes here you get support for TMU (Thermal >>>>>>>>> Management >>>>>>>>> + Unit) on Broadcom BCM281xx family of SoCs. This provides >>>>>>>>> thermal >>>>>>>>> + monitoring of CPU clusters, graphics, and SoC glue, but does >>>>>>>>> not >>>>>>>>> + include monitoring of charger temperature. >>>>>>>>> + >>>>>>>>> config DOVE_THERMAL >>>>>>>>> tristate "Temperature sensor on Marvell Dove SoCs" >>>>>>>>> depends on ARCH_DOVE >>>>>>>>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile >>>>>>>>> index 584b363..3ea8c1c 100644 >>>>>>>>> --- a/drivers/thermal/Makefile >>>>>>>>> +++ b/drivers/thermal/Makefile >>>>>>>>> @@ -21,6 +21,7 @@ obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o >>>>>>>>> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o >>>>>>>>> obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o >>>>>>>>> obj-y += samsung/ >>>>>>>>> +obj-$(CONFIG_BCM_THERMAL) += bcm_thermal.o >>>>>>>>> obj-$(CONFIG_DOVE_THERMAL) += dove_thermal.o >>>>>>>>> obj-$(CONFIG_DB8500_THERMAL) += db8500_thermal.o >>>>>>>>> obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o >>>>>>>>> diff --git a/drivers/thermal/bcm_thermal.c >>>>>>>>> b/drivers/thermal/bcm_thermal.c >>>>>>>>> new file mode 100644 >>>>>>>>> index 0000000..131d3c4 >>>>>>>>> --- /dev/null >>>>>>>>> +++ b/drivers/thermal/bcm_thermal.c >>>>>>>>> @@ -0,0 +1,170 @@ >>>>>>>>> +/* >>>>>>>>> + * Copyright 2013 Broadcom Corporation. >>>>>>>>> + * >>>>>>>>> + * This program is free software; you can redistribute it and/or >>>>>>>>> modify >>>>>>>>> + * it under the terms of the GNU General Public License, >>>>>>>>> version 2, >>>>>>>>> + * as published by the Free Software Foundation (the "GPL"). >>>>>>>>> + * >>>>>>>>> + * 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. >>>>>>>>> + * >>>>>>>>> + * A copy of the GPL is available at >>>>>>>>> http://www.broadcom.com/licenses/GPLv2.php, >>>>>>>>> + * or by writing to the Free Software Foundation, Inc., >>>>>>>>> + * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. >>>>>>>>> + */ >>>>>>>>> + >>>>>>>>> +/** >>>>>>>>> +* Broadcom Thermal Management Unit - bcm_tmu >>>>>>>>> +*/ >>>>>>>>> +#include <linux/module.h> >>>>>>>>> +#include <linux/err.h> >>>>>>>>> +#include <linux/kernel.h> >>>>>>>>> +#include <linux/platform_device.h> >>>>>>>>> +#include <linux/io.h> >>>>>>>>> +#include <linux/thermal.h> >>>>>>>>> +#include <linux/of.h> >>>>>>>>> + >>>>>>>>> +/* From TMON Register Database */ >>>>>>>>> +#define TMON_TEMP_VAL_OFFSET 0x0000001c >>>>>>>>> +#define TMON_TEMP_VAL_TEMP_VAL_SHIFT 0 >>>>>>>>> +#define TMON_TEMP_VAL_TEMP_VAL_MASK 0x000003ff >>>>>>>>> + >>>>>>>>> +/* Broadcom Thermal Zone Device Structure */ >>>>>>>>> +struct bcm_thermal_zone_priv { >>>>>>>>> + char name[THERMAL_NAME_LENGTH]; >>>>>>>>> + void __iomem *base; >>>>>>>>> +}; >>>>>>>>> + >>>>>>>>> +/* Temperature conversion function for TMON block */ >>>>>>>>> +static long raw_to_mcelsius(u32 raw) >>>>>>>>> +{ >>>>>>>>> + /* >>>>>>>>> + * According to Broadcom internal Analog Module Specification >>>>>>>>> + * the formula for converting TMON block output to >>>>>>>>> temperature in >>>>>>>>> + * degree Celsius is: >>>>>>>>> + * T = 428 - (0.561 * raw) >>>>>>>>> + * Note: the valid operating range for the TMON block is >>>>>>>>> -40C to >>>>>>>>> 125C >>>>>>>>> + */ >>>>>>>>> + return 428000 - (561 * (long)raw); >>>>>>>>> +} >>>>>>>>> + >>>>>>>>> +/* Get temperature callback function for thermal zone */ >>>>>>>>> +static int bcm_get_temp(struct thermal_zone_device *thermal, >>>>>>>>> + unsigned long *temp) >>>>>>>>> +{ >>>>>>>>> + u32 raw; >>>>>>>>> + long mcelsius; >>>>>>>>> + struct bcm_thermal_zone_priv *priv = thermal->devdata; >>>>>>>>> + >>>>>>>>> + if (!priv) { >>>>>>>>> + pr_err("%s: thermal zone number %d devdata not >>>>>>>>> initialized.\n", >>>>>>>>> + __func__, thermal->id); >>>>>>>>> + return -EINVAL; >>>>>>>>> + } >>>>>>>>> + >>>>>>>>> + raw = (readl(priv->base + TMON_TEMP_VAL_OFFSET) >>>>>>>>> + & TMON_TEMP_VAL_TEMP_VAL_MASK) >> >>>>>>>>> TMON_TEMP_VAL_TEMP_VAL_SHIFT; >>>>>>>>> + >>>>>>>>> + pr_debug("%s: thermal zone number %d raw temp 0x%x\n", >>>>>>>>> __func__, >>>>>>>>> + thermal->id, raw); >>>>>>>>> + >>>>>>>>> + mcelsius = raw_to_mcelsius(raw); >>>>>>>>> + >>>>>>>>> + /* >>>>>>>>> + * Since 'mcelsius' might be negative, we need to limit it to >>>>>>>>> smallest >>>>>>>>> + * unsigned value before returning it to thermal framework. >>>>>>>>> + */ >>>>>>>>> + if (mcelsius < 0) >>>>>>>>> + *temp = 0; >>>>>>>>> + else >>>>>>>>> + *temp = mcelsius; >>>>>>>>> + >>>>>>>>> + pr_debug("%s: thermal zone number %d final temp %d\n", >>>>>>>>> __func__, >>>>>>>>> + thermal->id, (int) *temp); >>>>>>>>> + >>>>>>>>> + return 0; >>>>>>>>> +} >>>>>>>>> + >>>>>>>>> +/* Operation callback functions for thermal zone */ >>>>>>>>> +static struct thermal_zone_device_ops bcm_dev_ops = { >>>>>>>>> + .get_temp = bcm_get_temp, >>>>>>>>> +}; >>>>>>>>> + >>>>>>>>> +static const struct of_device_id bcm_tmu_match_table[] = { >>>>>>>>> + { .compatible = "brcm,kona-thermal" }, >>>>>>>>> + {}, >>>>>>>>> +}; >>>>>>>>> +MODULE_DEVICE_TABLE(of, bcm_tmu_match_table); >>>>>>>>> + >>>>>>>>> +static int bcm_tmu_probe(struct platform_device *pdev) >>>>>>>>> +{ >>>>>>>>> + struct thermal_zone_device *thermal = NULL; >>>>>>>>> + struct bcm_thermal_zone_priv *priv; >>>>>>>>> + struct resource *res; >>>>>>>>> + const char *str; >>>>>>>>> + >>>>>>>>> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL); >>>>>>>>> + if (!priv) { >>>>>>>>> + dev_err(&pdev->dev, "Failed to malloc priv.\n"); >>>>>>>>> + return -ENOMEM; >>>>>>>>> + } >>>>>>>>> + >>>>>>>>> + /* Obtain the tmu name from device tree file */ >>>>>>>>> + if (of_property_read_string(pdev->dev.of_node, "thermal-name", >>>>>>>> Hello Wendy, >>>>>>>> >>>>>>>> I would prefer we wait until the work for thermal data [1] gets >>>>>>>> accepted >>>>>>>> before accepting this driver, specially because you are adding >>>>>>>> device >>>>>>>> specific DT entry to help in your registration with the thermal >>>>>>>> framework. With the mentioned work you wont need it at all. >>>>>>>> >>>>>>>> All best, >>>>>>>> >>>>>>>> [1] - http://lkml.org/lkml/2013/9/15/122 >>>>>>> Hello Eduardo, >>>>>>> >>>>>>> Since your changes are quite extensive, would you recommend me to get >>>>>>> your 16 patches into my local workspace and try to integrate the code >>>>>>> from my patches on the top of your patches at this time? Or should I >>>>>>> wait until your patches get accepted. >>>>>> Hello again Wendy, >>>>>> >>>>>> The only part I am concerned is the device tree entry you are creating >>>>>> for your device/driver. That could be obsolete in near future with the >>>>>> work I am doing currently. >>>>>> >>>>>> The work is, as you mentioned, quite extensive, but should make things >>>>>> easier for device driver writer. If you want, of course, it would be >>>>>> great if you could rebase your work on top of mine and try it out on >>>>>> your side and let me know the outcome. >>>>>> >>>>>> Comments on the proposed binding and documentation is also welcome. >>>>>> Let >>>>>> me know if there is something that it is not clear. >>>>>> >>>>>>> Thanks, >>>>>>> -Wendy >>>>>>>>> + &str) == 0) { >>>>>>>>> + strlcpy(priv->name, str, sizeof(priv->name)); >>>>>>>>> + } else { >>>>>>>>> + dev_err(&pdev->dev, "Failed to get thermal-name from >>>>>>>>> DT.\n"); >>>>>>>>> + return -EINVAL; >>>>>>>>> + } >>>>>>>>> + >>>>>>>>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0); >>>>>>>>> + priv->base = devm_ioremap_resource(&pdev->dev, res); >>>>>>>>> + if (IS_ERR(priv->base)) >>>>>>>>> + return PTR_ERR(priv->base); >>>>>>>>> + >>>>>>>>> + thermal = thermal_zone_device_register(priv->name, 0, 0, priv, >>>>>>>>> + &bcm_dev_ops, NULL, 0, 0); >>>>>>>>> + if (IS_ERR(thermal)) { >>>>>>>>> + dev_err(&pdev->dev, >>>>>>>>> + "Failed to register Broadcom thermal zone device.\n"); >>>>>>>>> + return PTR_ERR(thermal); >>>>>>>>> + } >>>>>>>>> + >>>>>>>>> + platform_set_drvdata(pdev, thermal); >>>>>>>>> + >>>>>>>>> + dev_info(&pdev->dev, "Broadcom Thermal Monitor >>>>>>>>> Initialized.\n"); >>>>>>>>> + >>>>>>>>> + return 0; >>>>>>>>> +} >>>>>>>>> + >>>>>>>>> +static int bcm_tmu_remove(struct platform_device *pdev) >>>>>>>>> +{ >>>>>>>>> + struct thermal_zone_device *broadcom_thermal = >>>>>>>>> + platform_get_drvdata(pdev); >>>>>>>>> + >>>>>>>>> + thermal_zone_device_unregister(broadcom_thermal); >>>>>>>>> + >>>>>>>>> + dev_info(&pdev->dev, "Broadcom Thermal Monitor >>>>>>>>> Uninitialized.\n"); >>>>>>>>> + >>>>>>>>> + return 0; >>>>>>>>> +} >>>>>>>>> + >>>>>>>>> +static struct platform_driver bcm_tmu_driver = { >>>>>>>>> + .driver = { >>>>>>>>> + .name = "bcm-thermal", >>>>>>>>> + .owner = THIS_MODULE, >>>>>>>>> + .of_match_table = bcm_tmu_match_table, >>>>>>>>> + }, >>>>>>>>> + .probe = bcm_tmu_probe, >>>>>>>>> + .remove = bcm_tmu_remove, >>>>>>>>> +}; >>>>>>>>> + >>>>>>>>> +module_platform_driver(bcm_tmu_driver); >>>>>>>>> + >>>>>>>>> +MODULE_DESCRIPTION("Broadcom Thermal Driver"); >>>>>>>>> +MODULE_AUTHOR("Broadcom"); >>>>>>>>> +MODULE_LICENSE("GPL v2"); >>>>>>>>> +MODULE_ALIAS("platform:bcm-thermal"); >>>>>>>>> > -- Best regards, -Wendy ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/3] thermal: bcm281xx: Add thermal driver 2013-09-23 17:51 ` [PATCH 1/3] " Wendy Ng 2013-09-23 18:19 ` Eduardo Valentin @ 2013-09-25 19:26 ` Matt Porter 2013-09-27 22:49 ` Wendy Ng 1 sibling, 1 reply; 15+ messages in thread From: Matt Porter @ 2013-09-25 19:26 UTC (permalink / raw) To: Wendy Ng Cc: Rob Herring, Stephen Warren, devicetree, linux-kernel, linux-pm, Christian Daudt, Markus Mayer On Mon, Sep 23, 2013 at 10:51:36AM -0700, Wendy Ng wrote: > This adds the support for reading out temperature from Broadcom bcm281xx > SoCs. > > Signed-off-by: Wendy Ng <wendy.ng@broadcom.com> > Reviewed-by: Markus Mayer <mmayer@broadcom.com> > Reviewed-by: Christian Daudt <csd@broadcom.com> > --- > .../bindings/thermal/bcm-kona-thermal.txt | 18 +++ > drivers/thermal/Kconfig | 10 ++ > drivers/thermal/Makefile | 1 + > drivers/thermal/bcm_thermal.c | 170 ++++++++++++++++++++ > 4 files changed, 199 insertions(+) > create mode 100644 Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt > create mode 100644 drivers/thermal/bcm_thermal.c > > diff --git a/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt > new file mode 100644 > index 0000000..acca99e > --- /dev/null > +++ b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt > @@ -0,0 +1,18 @@ > +* Broadcom Kona Thermal Management Unit > + > +This version is for the BCM281xx family of SoCs. > + > +Required properties: > +- compatible : "brcm,bcm11351-thermal", "brcm,kona-thermal" > +- reg : Address range of the thermal register > +- thermal-name: this entry must be specified and it will be passed into > +thermal_zone_device_register(). This name will also be reported under Hwmon > +sysfs 'name' attribute. > + > +Example: > + thermal@34008000 { > + compatible = "brcm,bcm11351-thermal", "brcm,kona-thermal"; > + reg = <0x34008000 0x0024>; > + thermal-name = "bcm_kona_therm"; > + status = "disabled"; > + }; > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig > index dbfc390..7f823f0 100644 > --- a/drivers/thermal/Kconfig > +++ b/drivers/thermal/Kconfig > @@ -134,6 +134,16 @@ config KIRKWOOD_THERMAL > Support for the Kirkwood thermal sensor driver into the Linux thermal > framework. Only kirkwood 88F6282 and 88F6283 have this sensor. > > +config BCM_THERMAL > + tristate "Temperature sensor on Broadcom BCM281xx family of SoCs" > + depends on ARCH_BCM Hi Wendy, I just noticed that, depending on acceptance, this could collide with Christian's ARCH_BCM->ARCH_BCM_MOBILE rename that is expected to go into 3.13. I'm not sure if this series is targeted for 3.13 (due to the discussion about Eduardo's subsystem changes that impact it). If it is, you might want to rebase on Christian's rename series http://www.spinics.net/lists/arm-kernel/msg274963.html and use ARCH_BCM_MOBILE here. -Matt > + default y > + help > + If you say yes here you get support for TMU (Thermal Management > + Unit) on Broadcom BCM281xx family of SoCs. This provides thermal > + monitoring of CPU clusters, graphics, and SoC glue, but does not > + include monitoring of charger temperature. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/3] thermal: bcm281xx: Add thermal driver 2013-09-25 19:26 ` Matt Porter @ 2013-09-27 22:49 ` Wendy Ng 0 siblings, 0 replies; 15+ messages in thread From: Wendy Ng @ 2013-09-27 22:49 UTC (permalink / raw) To: Matt Porter Cc: Rob Herring, Stephen Warren, devicetree, linux-kernel, linux-pm, Christian Daudt, Markus Mayer On 9/25/2013 12:26 PM, Matt Porter wrote: > On Mon, Sep 23, 2013 at 10:51:36AM -0700, Wendy Ng wrote: >> This adds the support for reading out temperature from Broadcom bcm281xx >> SoCs. >> >> Signed-off-by: Wendy Ng <wendy.ng@broadcom.com> >> Reviewed-by: Markus Mayer <mmayer@broadcom.com> >> Reviewed-by: Christian Daudt <csd@broadcom.com> >> --- >> .../bindings/thermal/bcm-kona-thermal.txt | 18 +++ >> drivers/thermal/Kconfig | 10 ++ >> drivers/thermal/Makefile | 1 + >> drivers/thermal/bcm_thermal.c | 170 ++++++++++++++++++++ >> 4 files changed, 199 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >> create mode 100644 drivers/thermal/bcm_thermal.c >> >> diff --git a/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >> new file mode 100644 >> index 0000000..acca99e >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/thermal/bcm-kona-thermal.txt >> @@ -0,0 +1,18 @@ >> +* Broadcom Kona Thermal Management Unit >> + >> +This version is for the BCM281xx family of SoCs. >> + >> +Required properties: >> +- compatible : "brcm,bcm11351-thermal", "brcm,kona-thermal" >> +- reg : Address range of the thermal register >> +- thermal-name: this entry must be specified and it will be passed into >> +thermal_zone_device_register(). This name will also be reported under Hwmon >> +sysfs 'name' attribute. >> + >> +Example: >> + thermal@34008000 { >> + compatible = "brcm,bcm11351-thermal", "brcm,kona-thermal"; >> + reg = <0x34008000 0x0024>; >> + thermal-name = "bcm_kona_therm"; >> + status = "disabled"; >> + }; >> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >> index dbfc390..7f823f0 100644 >> --- a/drivers/thermal/Kconfig >> +++ b/drivers/thermal/Kconfig >> @@ -134,6 +134,16 @@ config KIRKWOOD_THERMAL >> Support for the Kirkwood thermal sensor driver into the Linux thermal >> framework. Only kirkwood 88F6282 and 88F6283 have this sensor. >> >> +config BCM_THERMAL >> + tristate "Temperature sensor on Broadcom BCM281xx family of SoCs" >> + depends on ARCH_BCM > Hi Wendy, > > I just noticed that, depending on acceptance, this could collide with > Christian's ARCH_BCM->ARCH_BCM_MOBILE rename that is expected to go into > 3.13. I'm not sure if this series is targeted for 3.13 (due to the discussion > about Eduardo's subsystem changes that impact it). If it is, you might > want to rebase on Christian's rename series > http://www.spinics.net/lists/arm-kernel/msg274963.html and use > ARCH_BCM_MOBILE here. > > -Matt Hi Matt, I have uploaded v2 of this thermal driver patch series to make it compatible with Christian's ARCH_BCM->ARCH_BCM_MOBILE changes. Thanks for pointing this out! >> + default y >> + help >> + If you say yes here you get support for TMU (Thermal Management >> + Unit) on Broadcom BCM281xx family of SoCs. This provides thermal >> + monitoring of CPU clusters, graphics, and SoC glue, but does not >> + include monitoring of charger temperature. > -- Best regards, -Wendy ^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 2/3] ARM: bcm281xx: Turn on Thermal and HWMON drivers. 2013-09-23 17:51 [PATCH 0/3] thermal: bcm281xx: Add thermal driver Wendy Ng 2013-09-23 17:51 ` [PATCH 1/3] " Wendy Ng @ 2013-09-23 17:51 ` Wendy Ng 2013-09-23 17:51 ` [PATCH 3/3] ARM: bcm281xx: Add thermal driver to device tree Wendy Ng 2 siblings, 0 replies; 15+ messages in thread From: Wendy Ng @ 2013-09-23 17:51 UTC (permalink / raw) To: Rob Herring, Stephen Warren Cc: devicetree, linux-kernel, linux-pm, Christian Daudt, Markus Mayer, Wendy Ng This enables the thermal and HWMON drivers for Broadcom bcm281xx SoCs. Signed-off-by: Wendy Ng <wendy.ng@broadcom.com> Reviewed-by: Markus Mayer <mmayer@broadcom.com> Reviewed-by: Christian Daudt <csd@broadcom.com> --- arch/arm/configs/bcm_defconfig | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig index 6e49310..1474661 100644 --- a/arch/arm/configs/bcm_defconfig +++ b/arch/arm/configs/bcm_defconfig @@ -83,7 +83,8 @@ CONFIG_SERIAL_8250_DW=y CONFIG_HW_RANDOM=y CONFIG_I2C=y CONFIG_I2C_CHARDEV=y -# CONFIG_HWMON is not set +CONFIG_THERMAL=y +CONFIG_HWMON=y CONFIG_VIDEO_OUTPUT_CONTROL=y CONFIG_FB=y CONFIG_BACKLIGHT_LCD_SUPPORT=y -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH 3/3] ARM: bcm281xx: Add thermal driver to device tree. 2013-09-23 17:51 [PATCH 0/3] thermal: bcm281xx: Add thermal driver Wendy Ng 2013-09-23 17:51 ` [PATCH 1/3] " Wendy Ng 2013-09-23 17:51 ` [PATCH 2/3] ARM: bcm281xx: Turn on Thermal and HWMON drivers Wendy Ng @ 2013-09-23 17:51 ` Wendy Ng 2 siblings, 0 replies; 15+ messages in thread From: Wendy Ng @ 2013-09-23 17:51 UTC (permalink / raw) To: Rob Herring, Stephen Warren Cc: devicetree, linux-kernel, linux-pm, Christian Daudt, Markus Mayer, Wendy Ng This patch adds the device tree node for Broadcom bcm281xx SoCs thermal driver. Signed-off-by: Wendy Ng <wendy.ng@broadcom.com> Reviewed-by: Markus Mayer <mmayer@broadcom.com> Reviewed-by: Christian Daudt <csd@broadcom.com> --- arch/arm/boot/dts/bcm11351-brt.dts | 4 +++- arch/arm/boot/dts/bcm11351.dtsi | 6 ++++++ arch/arm/boot/dts/bcm28155-ap.dts | 4 ++++ 3 files changed, 13 insertions(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/bcm11351-brt.dts b/arch/arm/boot/dts/bcm11351-brt.dts index 9d36eb4..0771b6b 100644 --- a/arch/arm/boot/dts/bcm11351-brt.dts +++ b/arch/arm/boot/dts/bcm11351-brt.dts @@ -43,5 +43,7 @@ status = "okay"; }; - + thermal@34008000 { + status = "okay"; + }; }; diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi index 05a5aab..aa13353 100644 --- a/arch/arm/boot/dts/bcm11351.dtsi +++ b/arch/arm/boot/dts/bcm11351.dtsi @@ -96,4 +96,10 @@ status = "disabled"; }; + thermal@34008000 { + compatible = "brcm,bcm11351-thermal", "brcm,kona-thermal"; + reg = <0x34008000 0x0024>; + thermal-name = "bcm_kona_therm"; + status = "disabled"; + }; }; diff --git a/arch/arm/boot/dts/bcm28155-ap.dts b/arch/arm/boot/dts/bcm28155-ap.dts index 96ae67a..a39aa47 100644 --- a/arch/arm/boot/dts/bcm28155-ap.dts +++ b/arch/arm/boot/dts/bcm28155-ap.dts @@ -42,4 +42,8 @@ max-frequency = <48000000>; status = "okay"; }; + + thermal@34008000 { + status = "okay"; + }; }; -- 1.7.9.5 ^ permalink raw reply related [flat|nested] 15+ messages in thread
end of thread, other threads:[~2013-10-07 23:11 UTC | newest] Thread overview: 15+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-09-23 17:51 [PATCH 0/3] thermal: bcm281xx: Add thermal driver Wendy Ng 2013-09-23 17:51 ` [PATCH 1/3] " Wendy Ng 2013-09-23 18:19 ` Eduardo Valentin 2013-09-23 22:43 ` Wendy Ng 2013-09-23 23:46 ` Eduardo Valentin 2013-10-04 22:17 ` Wendy Ng 2013-10-07 14:52 ` Eduardo Valentin 2013-10-07 16:12 ` Eduardo Valentin 2013-10-07 17:52 ` Wendy Ng 2013-10-07 22:32 ` Eduardo Valentin 2013-10-07 23:11 ` Wendy Ng 2013-09-25 19:26 ` Matt Porter 2013-09-27 22:49 ` Wendy Ng 2013-09-23 17:51 ` [PATCH 2/3] ARM: bcm281xx: Turn on Thermal and HWMON drivers Wendy Ng 2013-09-23 17:51 ` [PATCH 3/3] ARM: bcm281xx: Add thermal driver to device tree Wendy Ng
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox