* [PATCH 13/14] input: touchscreen: sama5d2_rts: SAMA5D2 Resistive touchscreen driver
From: Eugen Hristev @ 2017-12-22 15:07 UTC (permalink / raw)
To: nicolas.ferre, ludovic.desroches, alexandre.belloni, linux-iio,
linux-arm-kernel, devicetree, linux-kernel, jic23, linux-input,
dmitry.torokhov
Cc: Eugen Hristev
In-Reply-To: <1513955241-10985-1-git-send-email-eugen.hristev@microchip.com>
This is the implementation of the Microchip SAMA5D2 SOC resistive
touchscreen driver.
The driver registers an input device and connects to the give IIO device
from devicetree. It requires an IIO trigger (acting as a consumer) and
three IIO channels : one for X position, one for Y position and one
for pressure.
It the reports the values to the input subsystem.
Some parts of this driver are based on the initial original work by
Mohamed Jamsheeth Hajanajubudeen and Bandaru Venkateswara Swamy
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
drivers/input/touchscreen/Kconfig | 13 ++
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/sama5d2_rts.c | 287 ++++++++++++++++++++++++++++++++
3 files changed, 301 insertions(+)
create mode 100644 drivers/input/touchscreen/sama5d2_rts.c
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 64b30fe..db8f541 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -126,6 +126,19 @@ config TOUCHSCREEN_ATMEL_MXT_T37
Say Y here if you want support to output data from the T37
Diagnostic Data object using a V4L device.
+config TOUCHSCREEN_SAMA5D2
+ tristate "Microchip SAMA5D2 resistive touchscreen support"
+ depends on ARCH_AT91
+ depends on AT91_SAMA5D2_ADC
+ help
+ Say Y here if you have 4-wire touchscreen connected
+ to ADC Controller on your SAMA5D2 Microchip SoC.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called sama5d2_rts.
+
config TOUCHSCREEN_AUO_PIXCIR
tristate "AUO in-cell touchscreen using Pixcir ICs"
depends on I2C
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index 850c156..9a2772e 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_TOUCHSCREEN_AD7879_SPI) += ad7879-spi.o
obj-$(CONFIG_TOUCHSCREEN_ADS7846) += ads7846.o
obj-$(CONFIG_TOUCHSCREEN_AR1021_I2C) += ar1021_i2c.o
obj-$(CONFIG_TOUCHSCREEN_ATMEL_MXT) += atmel_mxt_ts.o
+obj-$(CONFIG_TOUCHSCREEN_SAMA5D2) += sama5d2_rts.o
obj-$(CONFIG_TOUCHSCREEN_AUO_PIXCIR) += auo-pixcir-ts.o
obj-$(CONFIG_TOUCHSCREEN_BU21013) += bu21013_ts.o
obj-$(CONFIG_TOUCHSCREEN_CHIPONE_ICN8318) += chipone_icn8318.o
diff --git a/drivers/input/touchscreen/sama5d2_rts.c b/drivers/input/touchscreen/sama5d2_rts.c
new file mode 100644
index 0000000..e2ae413
--- /dev/null
+++ b/drivers/input/touchscreen/sama5d2_rts.c
@@ -0,0 +1,287 @@
+/*
+ * Microchip resistive touchscreen (RTS) driver for SAMA5D2.
+ *
+ * Copyright (C) 2017 Microchip Technology,
+ * Author: Eugen Hristev <eugen.hristev@microchip.com>
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+#include <linux/input.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/platform_device.h>
+#include <linux/iio/consumer.h>
+#include <linux/iio/trigger.h>
+#include <linux/iio/trigger_consumer.h>
+
+#define DRIVER_NAME "sama5d2_rts"
+#define MAX_POS_MASK GENMASK(11, 0)
+#define AT91_RTS_DEFAULT_PRESSURE_THRESHOLD 10000
+
+/**
+ * at91_rts - at91 resistive touchscreen information struct
+ * @input: the input device structure that we register
+ * @chan_x: X channel to IIO device to get position on X axis
+ * @chan_y: Y channel to IIO device to get position on Y axis
+ * @chan_pressure: pressure channel to IIO device to get pressure
+ * @trig: trigger to IIO device to register to for polling
+ * @rts_pf: pollfunc for the trigger to be called by IIO dev
+ * @pressure_threshold: number representing the threshold for the pressure
+ * @adc_connected: to know if adc device is connected
+ * @workq: to defer computations to this work queue for reporting
+ */
+struct at91_rts {
+ struct input_dev *input;
+ struct iio_channel *chan_x, *chan_y, *chan_pressure;
+ struct iio_trigger *trig;
+ struct iio_poll_func *rts_pf;
+ u32 pressure_threshold;
+ bool adc_connected;
+ struct work_struct workq;
+};
+
+static irqreturn_t at91_rts_trigger_handler(int irq, void *p)
+{
+ struct at91_rts *st = ((struct iio_poll_func *)p)->p;
+
+ schedule_work(&st->workq);
+
+ return IRQ_HANDLED;
+}
+
+static void at91_rts_workq_handler(struct work_struct *workq)
+{
+ struct at91_rts *st = container_of(workq, struct at91_rts, workq);
+ unsigned int x, y, press;
+ int ret;
+
+ /* read the channels, if all good, report touch */
+ ret = iio_read_channel_raw(st->chan_x, &x);
+ if (ret < 0)
+ goto at91_rts_workq_handler_end_touch;
+
+ ret = iio_read_channel_raw(st->chan_y, &y);
+ if (ret < 0)
+ goto at91_rts_workq_handler_end_touch;
+
+ ret = iio_read_channel_raw(st->chan_pressure, &press);
+ if (ret < 0)
+ goto at91_rts_workq_handler_end_touch;
+
+ /* if pressure too low, don't report */
+ if (press > st->pressure_threshold)
+ goto at91_rts_workq_handler_exit;
+
+ input_report_abs(st->input, ABS_X, x);
+ input_report_abs(st->input, ABS_Y, y);
+ input_report_abs(st->input, ABS_PRESSURE, press);
+ input_report_key(st->input, BTN_TOUCH, 1);
+ input_sync(st->input);
+
+ iio_trigger_notify_done(st->trig);
+ return;
+
+at91_rts_workq_handler_end_touch:
+ /* report end of touch */
+ input_report_key(st->input, BTN_TOUCH, 0);
+ input_sync(st->input);
+at91_rts_workq_handler_exit:
+ iio_trigger_notify_done(st->trig);
+}
+
+static int at91_rts_open(struct input_dev *dev)
+{
+ int ret;
+ struct at91_rts *st = input_get_drvdata(dev);
+
+ /* avoid multiple initialization in case touchscreen is opened again */
+ if (st->adc_connected)
+ return 0;
+
+ /*
+ * First, look for the channels. It is possible that the ADC device
+ * did not probe yet, but we already probed, so we returning probe defer
+ * doesn't make much sense.
+ */
+ st->chan_x = iio_channel_get(dev->dev.parent, "x");
+ if (IS_ERR_OR_NULL(st->chan_x)) {
+ dev_err(dev->dev.parent, "cannot get X channel from ADC");
+ ret = PTR_ERR(st->chan_x);
+ goto at91_rts_open_free_chan;
+ }
+
+ st->chan_y = iio_channel_get(dev->dev.parent, "y");
+ if (IS_ERR_OR_NULL(st->chan_y)) {
+ dev_err(dev->dev.parent, "cannot get Y channel from ADC");
+ ret = PTR_ERR(st->chan_y);
+ goto at91_rts_open_free_chan;
+ }
+
+ st->chan_pressure = iio_channel_get(dev->dev.parent, "pressure");
+ if (IS_ERR_OR_NULL(st->chan_pressure)) {
+ dev_err(dev->dev.parent, "cannot get pressure channel from ADC");
+ ret = PTR_ERR(st->chan_pressure);
+ goto at91_rts_open_free_chan;
+ }
+
+ /* look for the trigger in device tree */
+ st->trig = iio_trigger_find(dev->dev.parent, NULL);
+ if (IS_ERR_OR_NULL(st->trig)) {
+ dev_err(dev->dev.parent, "cannot get trigger from ADC");
+ ret = PTR_ERR(st->trig);
+ goto at91_rts_open_free_chan;
+ }
+
+ /* allocate a pollfunc for the trigger */
+ st->rts_pf = iio_alloc_pollfunc(at91_rts_trigger_handler, NULL,
+ IRQF_ONESHOT, NULL,
+ dev->dev.parent->of_node->name);
+ if (!st->rts_pf) {
+ ret = -ENOMEM;
+ dev_err(dev->dev.parent, "cannot allocate trigger pollfunc");
+ goto at91_rts_open_free_chan;
+ }
+
+ iio_pollfunc_set_private_data(st->rts_pf, st);
+
+ /*
+ * Attach the pollfunc to the trigger. This will also call the
+ * configure function to enable the trigger
+ */
+ ret = iio_trigger_attach_poll_func(st->trig, st->rts_pf);
+ if (ret)
+ goto at91_rts_open_dealloc_pf;
+
+ dev_dbg(dev->dev.parent, "channels found, attached to trigger");
+
+ st->adc_connected = true;
+ return 0;
+
+at91_rts_open_dealloc_pf:
+ iio_dealloc_pollfunc(st->rts_pf);
+at91_rts_open_free_chan:
+ if (!IS_ERR_OR_NULL(st->chan_x))
+ iio_channel_release(st->chan_x);
+ if (!IS_ERR_OR_NULL(st->chan_y))
+ iio_channel_release(st->chan_y);
+ if (!IS_ERR_OR_NULL(st->chan_pressure))
+ iio_channel_release(st->chan_pressure);
+ /*
+ * Avoid keeping old values in channel pointers. in case some channel
+ * failed and we reopen them, and now fail, we will have invalid values
+ * to release. So write them as NULL now.
+ */
+ st->chan_x = NULL;
+ st->chan_y = NULL;
+ st->chan_pressure = NULL;
+ return ret;
+}
+
+static void at91_rts_close(struct input_dev *dev)
+{
+ struct at91_rts *st = input_get_drvdata(dev);
+
+ if (!st->adc_connected)
+ return;
+
+ iio_trigger_detach_poll_func(st->trig, st->rts_pf);
+ iio_dealloc_pollfunc(st->rts_pf);
+
+ if (!IS_ERR_OR_NULL(st->chan_x))
+ iio_channel_release(st->chan_x);
+ if (!IS_ERR_OR_NULL(st->chan_y))
+ iio_channel_release(st->chan_y);
+ if (!IS_ERR_OR_NULL(st->chan_pressure))
+ iio_channel_release(st->chan_pressure);
+
+ st->adc_connected = false;
+}
+
+static int at91_rts_probe(struct platform_device *pdev)
+{
+ int ret;
+ struct at91_rts *st;
+ struct input_dev *input;
+ struct device *dev = &pdev->dev;
+ struct device_node *node = dev->of_node;
+
+ st = devm_kzalloc(dev, sizeof(struct at91_rts), GFP_KERNEL);
+ if (!st)
+ return -ENOMEM;
+ st->adc_connected = false;
+
+ INIT_WORK(&st->workq, at91_rts_workq_handler);
+
+ input = devm_input_allocate_device(dev);
+ if (!input) {
+ dev_err(dev, "failed to allocate input device\n");
+ return -ENOMEM;
+ }
+
+ ret = of_property_read_u32(node, "microchip,pressure-threshold",
+ &st->pressure_threshold);
+ if (ret < 0) {
+ dev_dbg(dev, "can't get touchscreen pressure threshold property.\n");
+ st->pressure_threshold = AT91_RTS_DEFAULT_PRESSURE_THRESHOLD;
+ }
+
+ input->name = DRIVER_NAME;
+ input->id.bustype = BUS_HOST;
+ input->dev.parent = &pdev->dev;
+ input->open = at91_rts_open;
+ input->close = at91_rts_close;
+
+ input_set_abs_params(input, ABS_X, 0, MAX_POS_MASK - 1, 0, 0);
+ input_set_abs_params(input, ABS_Y, 0, MAX_POS_MASK, 0, 0);
+ input_set_abs_params(input, ABS_PRESSURE, 0, 0xffffff, 0, 0);
+
+ input->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
+ input->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
+
+ st->input = input;
+ input_set_drvdata(input, st);
+
+ ret = input_register_device(input);
+ if (ret) {
+ dev_err(dev, "failed to register input device: %d", ret);
+ return ret;
+ }
+
+ platform_set_drvdata(pdev, st);
+
+ dev_info(dev, "probed successfully\n");
+ return 0;
+}
+
+static int at91_rts_remove(struct platform_device *pdev)
+{
+ struct at91_rts *st = platform_get_drvdata(pdev);
+
+ input_unregister_device(st->input);
+
+ return 0;
+}
+
+static const struct of_device_id at91_rts_of_match[] = {
+ {
+ .compatible = "microchip,sama5d2-resistive-touch",
+ }, {
+ /* sentinel */
+ },
+};
+MODULE_DEVICE_TABLE(of, at91_rts_of_match);
+
+static struct platform_driver atmel_rts_driver = {
+ .probe = at91_rts_probe,
+ .remove = at91_rts_remove,
+ .driver = {
+ .name = DRIVER_NAME,
+ .of_match_table = of_match_ptr(at91_rts_of_match),
+ },
+};
+
+module_platform_driver(atmel_rts_driver);
+
+MODULE_AUTHOR("Eugen Hristev <eugen.hristev@microchip.com>");
+MODULE_DESCRIPTION("Microchip SAMA5D2 Resistive Touch Driver");
+MODULE_LICENSE("GPL v2");
--
2.7.4
^ permalink raw reply related
* [PATCH 14/14] ARM: dts: at91: sama5d2: Add resistive touch device
From: Eugen Hristev @ 2017-12-22 15:07 UTC (permalink / raw)
To: nicolas.ferre, ludovic.desroches, alexandre.belloni, linux-iio,
linux-arm-kernel, devicetree, linux-kernel, jic23, linux-input,
dmitry.torokhov
Cc: Eugen Hristev
In-Reply-To: <1513955241-10985-1-git-send-email-eugen.hristev@microchip.com>
Add the resistive touchscreen device, and the cell numbers to the
ADC device.
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
---
arch/arm/boot/dts/sama5d2.dtsi | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
index b1a26b4..30b3797 100644
--- a/arch/arm/boot/dts/sama5d2.dtsi
+++ b/arch/arm/boot/dts/sama5d2.dtsi
@@ -402,7 +402,6 @@
compatible = "atmel,hlcdc-display-controller";
#address-cells = <1>;
#size-cells = <0>;
-
port@0 {
#address-cells = <1>;
#size-cells = <0>;
@@ -1431,6 +1430,17 @@
atmel,max-sample-rate-hz = <20000000>;
atmel,startup-time-ms = <4>;
atmel,trigger-edge-type = <IRQ_TYPE_EDGE_RISING>;
+ #io-channel-cells = <1>;
+ #io-trigger-cells = <1>;
+ status = "disabled";
+ };
+
+ resistive_touch: resistive-touch {
+ compatible = "microchip,sama5d2-resistive-touch";
+ io-channels = <&adc 19>, <&adc 20>, <&adc 21>;
+ io-channel-names = "x", "y", "pressure";
+ io-triggers = <&adc 1>;
+ microchip,pressure-threshold = <10000>;
status = "disabled";
};
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v6 04/11] thermal: armada: Clarify control registers accesses
From: Gregory CLEMENT @ 2017-12-22 15:33 UTC (permalink / raw)
To: Miquel Raynal
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Antoine Tenart, Nadav Haklai, Baruch Siach,
David Sniatkiwicz
In-Reply-To: <20171222093226.23456-5-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Miquel,
On ven., déc. 22 2017, Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Bindings were incomplete for a long time by only exposing one of the two
> available control registers. To ease the migration to the full bindings
> (already in use for the Armada 375 SoC), rename the pointers for
> clarification. This way, it will only be needed to add another pointer
> to access the other control register when the time comes.
>
> This avoids dangerous situations where the offset 0 of the control
> area can be either one register or the other depending on the bindings
> used. After this change, device trees of other SoCs could be migrated to
> the "full" bindings if they may benefit from features from the
> unaccessible register, without any change in the driver.
>
> Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Reviewed-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
I tested that there was no regression on an Armada XP based board:
PlatHome OpenBlocks AX3-4, and on an Armada 388 one: SolidRun Clearfog
A1. For both of them it was OK:
Tested-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Gregory
> ---
> drivers/thermal/armada_thermal.c | 76 ++++++++++++++++++++++++++++------------
> 1 file changed, 54 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index f350d7efd35a..d58376eba6d9 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -39,12 +39,21 @@
> #define A375_HW_RESETn BIT(8)
> #define A380_HW_RESET BIT(8)
>
> +/* Legacy bindings */
> +#define LEGACY_CONTROL_MEM_LEN 0x4
> +
> +/* Current bindings with the 2 control registers under the same memory area */
> +#define LEGACY_CONTROL1_OFFSET 0x0
> +#define CONTROL0_OFFSET 0x0
> +#define CONTROL1_OFFSET 0x4
> +
> struct armada_thermal_data;
>
> /* Marvell EBU Thermal Sensor Dev Structure */
> struct armada_thermal_priv {
> void __iomem *sensor;
> - void __iomem *control;
> + void __iomem *control0;
> + void __iomem *control1;
> struct armada_thermal_data *data;
> };
>
> @@ -66,27 +75,28 @@ struct armada_thermal_data {
> unsigned int temp_shift;
> unsigned int temp_mask;
> u32 is_valid_bit;
> + bool needs_control0;
> };
>
> static void armadaxp_init_sensor(struct platform_device *pdev,
> struct armada_thermal_priv *priv)
> {
> - unsigned long reg;
> + u32 reg;
>
> - reg = readl_relaxed(priv->control);
> + reg = readl_relaxed(priv->control1);
> reg |= PMU_TDC0_OTF_CAL_MASK;
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> /* Reference calibration value */
> reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
> reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> /* Reset the sensor */
> - reg = readl_relaxed(priv->control);
> - writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
> + reg = readl_relaxed(priv->control1);
> + writel((reg | PMU_TDC0_SW_RST_MASK), priv->control1);
>
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> /* Enable the sensor */
> reg = readl_relaxed(priv->sensor);
> @@ -97,19 +107,19 @@ static void armadaxp_init_sensor(struct platform_device *pdev,
> static void armada370_init_sensor(struct platform_device *pdev,
> struct armada_thermal_priv *priv)
> {
> - unsigned long reg;
> + u32 reg;
>
> - reg = readl_relaxed(priv->control);
> + reg = readl_relaxed(priv->control1);
> reg |= PMU_TDC0_OTF_CAL_MASK;
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> /* Reference calibration value */
> reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
> reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> reg &= ~PMU_TDC0_START_CAL_MASK;
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
>
> msleep(10);
> }
> @@ -117,30 +127,30 @@ static void armada370_init_sensor(struct platform_device *pdev,
> static void armada375_init_sensor(struct platform_device *pdev,
> struct armada_thermal_priv *priv)
> {
> - unsigned long reg;
> + u32 reg;
>
> - reg = readl(priv->control + 4);
> + reg = readl(priv->control1);
> reg &= ~(A375_UNIT_CONTROL_MASK << A375_UNIT_CONTROL_SHIFT);
> reg &= ~A375_READOUT_INVERT;
> reg &= ~A375_HW_RESETn;
>
> - writel(reg, priv->control + 4);
> + writel(reg, priv->control1);
> msleep(20);
>
> reg |= A375_HW_RESETn;
> - writel(reg, priv->control + 4);
> + writel(reg, priv->control1);
> msleep(50);
> }
>
> static void armada380_init_sensor(struct platform_device *pdev,
> struct armada_thermal_priv *priv)
> {
> - unsigned long reg = readl_relaxed(priv->control);
> + u32 reg = readl_relaxed(priv->control1);
>
> /* Reset hardware once */
> if (!(reg & A380_HW_RESET)) {
> reg |= A380_HW_RESET;
> - writel(reg, priv->control);
> + writel(reg, priv->control1);
> msleep(10);
> }
> }
> @@ -214,6 +224,7 @@ static const struct armada_thermal_data armada375_data = {
> .coef_b = 3171900000UL,
> .coef_m = 10000000UL,
> .coef_div = 13616,
> + .needs_control0 = true,
> };
>
> static const struct armada_thermal_data armada380_data = {
> @@ -253,6 +264,7 @@ MODULE_DEVICE_TABLE(of, armada_thermal_id_table);
>
> static int armada_thermal_probe(struct platform_device *pdev)
> {
> + void __iomem *control = NULL;
> struct thermal_zone_device *thermal;
> const struct of_device_id *match;
> struct armada_thermal_priv *priv;
> @@ -272,11 +284,31 @@ static int armada_thermal_probe(struct platform_device *pdev)
> return PTR_ERR(priv->sensor);
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
> - priv->control = devm_ioremap_resource(&pdev->dev, res);
> - if (IS_ERR(priv->control))
> - return PTR_ERR(priv->control);
> + control = devm_ioremap_resource(&pdev->dev, res);
> + if (IS_ERR(control))
> + return PTR_ERR(control);
>
> priv->data = (struct armada_thermal_data *)match->data;
> +
> + /*
> + * Legacy DT bindings only described "control1" register (also referred
> + * as "control MSB" on old documentation). New bindings cover
> + * "control0/control LSB" and "control1/control MSB" registers within
> + * the same resource, which is then of size 8 instead of 4.
> + */
> + if (resource_size(res) == LEGACY_CONTROL_MEM_LEN) {
> + /* ->control0 unavailable in this configuration */
> + if (priv->data->needs_control0) {
> + dev_err(&pdev->dev, "No access to control0 register\n");
> + return -EINVAL;
> + }
> +
> + priv->control1 = control + LEGACY_CONTROL1_OFFSET;
> + } else {
> + priv->control0 = control + CONTROL0_OFFSET;
> + priv->control1 = control + CONTROL1_OFFSET;
> + }
> +
> priv->data->init_sensor(pdev, priv);
>
> thermal = thermal_zone_device_register("armada_thermal", 0, 0,
> --
> 2.11.0
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 11/11] thermal: armada: Give meaningful names to the thermal zones
From: Gregory CLEMENT @ 2017-12-22 15:36 UTC (permalink / raw)
To: Miquel Raynal
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland, linux-pm,
devicetree, linux-arm-kernel, Thomas Petazzoni, Antoine Tenart,
Nadav Haklai, Baruch Siach, David Sniatkiwicz
In-Reply-To: <20171222093226.23456-12-miquel.raynal@free-electrons.com>
Hi Miquel,
On ven., déc. 22 2017, Miquel Raynal <miquel.raynal@free-electrons.com> wrote:
> After registration to the thermal core, sysfs will make one entry
> per instance of the driver in /sys/class/thermal_zoneX and
> /sys/class/hwmon/hwmonX, X being the index of the instance, all of them
> having the type/name "armada_thermal".
>
> Until now there was only one thermal zone per SoC but SoCs like Armada
> A7K and Armada A8K have respectively two and three thermal zones (one
> per AP and one per CP) and this number is subject to grow in the future.
>
> Use dev_name() instead of the "armada_thermal" string to get a
> meaningful name and be able to identify the thermal zones from
> userspace.
>
> Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
> Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
And here I also tested that when all the series was applied there was no
regression on an Armada XP based board: PlatHome OpenBlocks AX3-4, and
on an Armada 388 one: SolidRun Clearfog A1. hera again for both of them
it was OK:
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Gregory
> ---
> drivers/thermal/armada_thermal.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
> index ea958e651312..454137f78eb3 100644
> --- a/drivers/thermal/armada_thermal.c
> +++ b/drivers/thermal/armada_thermal.c
> @@ -406,8 +406,8 @@ static int armada_thermal_probe(struct platform_device *pdev)
>
> priv->data->init_sensor(pdev, priv);
>
> - thermal = thermal_zone_device_register("armada_thermal", 0, 0,
> - priv, &ops, NULL, 0, 0);
> + thermal = thermal_zone_device_register(dev_name(&pdev->dev), 0, 0, priv,
> + &ops, NULL, 0, 0);
> if (IS_ERR(thermal)) {
> dev_err(&pdev->dev,
> "Failed to register thermal zone device\n");
> --
> 2.11.0
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 1/5] bindings: regulator: added support for suspend states
From: Mark Brown @ 2017-12-22 15:49 UTC (permalink / raw)
To: Chunyan Zhang; +Cc: Rob Herring, devicetree, linux-kernel, Chunyan Zhang
In-Reply-To: <CAG2=9p9ahGgnz1Gos-o-o5PB9UH--2t3Lv54PaK5_f2jpNQnDQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]
On Fri, Dec 22, 2017 at 02:05:21PM +0800, Chunyan Zhang wrote:
> On 22 December 2017 at 07:26, Rob Herring <robh@kernel.org> wrote:
> > On Thu, Dec 21, 2017 at 02:25:02PM +0800, Chunyan Zhang wrote:
> >> + - regulator-suspend-microvolt: the default voltage which regulator
> >> + should be set in suspend, this can be adjusted among
> >> + <regulator-suspend-min-microvolt, regulator-suspend-max-microvolt>
> > Perhaps this should stay a single property with: <target> <min> <max>
> Do you mean that change the property name from "regulator-suspend-microvolt" to
> "regulator-suspend-target-microvolt"?
> "regulator-suspend-microvolt" is the one that some SoC is using. My
> intention was just to keep that configuration still working.
Yeah, the regulator-suspend-microvolt is an existing property. Thinking
about it we should probably say that it's equivalent to setting both
-min and -max to the same value and possibly mark it as deprecated too.
It is documented in regulator.txt already.
> > Though why would you ever not try to set to the minimum voltage within
> > the range of <min> to <max>?
> IIUC, you mean just removing "regulator-suspend-microvolt", and use
> "regulator-suspend-min-microvolt" as the default value for suspend
> voltage?
> I think that can work, but would it be better to not remove that right
> now, since some one is using that?
Indeed. I think my suggestion above would cover things.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-binding: can: mcp2517fd: document device tree bindings
From: Patrick Menschel @ 2017-12-22 15:50 UTC (permalink / raw)
To: kernel-TqfNSX0MhmxHKSADF0wUEw
Cc: linux-can-u79uwXL29TY76Z2rM5mHXA, devicetree
In-Reply-To: <4E2DB518-A148-46CE-8267-73D292991BD2-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1867 bytes --]
Hi Martin,
as I wrote earlier, I would save the GPIO_LIB part for a driver update
later on as to me there seems to be no daily use case.
I think SLEEP is the preferred solution.
If the device is in SLEEP after probing, the logical step would be to
disable GPIO functions and configure INT0/GPIO0/XSTBY to XSTBY thus the
transceiver is also sleeping.
Best practice usually comes from practical usage.
If there already is a reference design PCB with the mcp2517fd, it would
make sense to see what the designer did connect to the optional GPIO
pins and then guess what additional use cases could be of interest.
Without that knowledge, you're prone to do over-engineering.
Regards,
Patrick
Am 17.12.2017 um 15:34 schrieb kernel-TqfNSX0MhmxHKSADF0wUEw@public.gmane.org:
> Hi Patrick!
>
> So I started implementing the GPIO_LIB implementation but
> I have hit an issue where I would like to get some feedback.
>
> So in principle the gpiolib works, but only if the device is
> not asleep and the clock is enabled, which at this very moment means
> that the can interface has to be up and running.
>
> So at this very moment the only option that I see would be to
> disable the sleep mode which the device enters after probing until
> the can-network interface is enabled (which enables the clock and
> start the oscillator) - with SLEEP enabled when GPIOLIB support
> is disabled.
>
> This is obviously not optimal from the power perspective…
>
> The other option would be starting the clock and oscillator
> as soon as a set_direction* (or reques/free) function is called.
> (where I would need to start using locks to avoid race conditions
> as well as clock usage counters...).
>
> Which of the above is the preferred solution? Are there other ideas
> how I could solve this dilemma?
>
>
> Martin
>
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3992 bytes --]
^ permalink raw reply
* Re: [PATCH v6 11/11] thermal: armada: Give meaningful names to the thermal zones
From: Miquel RAYNAL @ 2017-12-22 15:51 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland,
linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Antoine Tenart, Nadav Haklai, Baruch Siach,
David Sniatkiwicz
In-Reply-To: <873742epwb.fsf-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hello Gregory,
On Fri, 22 Dec 2017 16:36:04 +0100
Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi Miquel,
>
> On ven., déc. 22 2017, Miquel Raynal
> <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
> > After registration to the thermal core, sysfs will make one entry
> > per instance of the driver in /sys/class/thermal_zoneX and
> > /sys/class/hwmon/hwmonX, X being the index of the instance, all of
> > them having the type/name "armada_thermal".
> >
> > Until now there was only one thermal zone per SoC but SoCs like
> > Armada A7K and Armada A8K have respectively two and three thermal
> > zones (one per AP and one per CP) and this number is subject to
> > grow in the future.
> >
> > Use dev_name() instead of the "armada_thermal" string to get a
> > meaningful name and be able to identify the thermal zones from
> > userspace.
> >
> > Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> > Reviewed-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>
> And here I also tested that when all the series was applied there was
> no regression on an Armada XP based board: PlatHome OpenBlocks AX3-4,
> and on an Armada 388 one: SolidRun Clearfog A1. hera again for both
> of them it was OK:
Thank you for testing, on my side I checked the last version (minor
changes) with both an Armada-385-AP and an Armada-8040-DB.
I will resend the series very soon.
Thanks,
Miquèl
>
> Tested-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>
> Gregory
>
> > ---
> > drivers/thermal/armada_thermal.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/thermal/armada_thermal.c
> > b/drivers/thermal/armada_thermal.c index ea958e651312..454137f78eb3
> > 100644 --- a/drivers/thermal/armada_thermal.c
> > +++ b/drivers/thermal/armada_thermal.c
> > @@ -406,8 +406,8 @@ static int armada_thermal_probe(struct
> > platform_device *pdev)
> > priv->data->init_sensor(pdev, priv);
> >
> > - thermal = thermal_zone_device_register("armada_thermal",
> > 0, 0,
> > - priv, &ops, NULL,
> > 0, 0);
> > + thermal =
> > thermal_zone_device_register(dev_name(&pdev->dev), 0, 0, priv,
> > + &ops, NULL, 0, 0);
> > if (IS_ERR(thermal)) {
> > dev_err(&pdev->dev,
> > "Failed to register thermal zone
> > device\n"); --
> > 2.11.0
> >
>
--
Miquel Raynal, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 14/14] ARM: dts: at91: sama5d2: Add resistive touch device
From: Alexandre Belloni @ 2017-12-22 16:10 UTC (permalink / raw)
To: Eugen Hristev
Cc: nicolas.ferre-UWL1GkI3JZL3oGB3hsPCZA,
ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
linux-input-u79uwXL29TY76Z2rM5mHXA,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <1513955241-10985-15-git-send-email-eugen.hristev-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
Hi,
On 22/12/2017 at 17:07:21 +0200, Eugen Hristev wrote:
> Add the resistive touchscreen device, and the cell numbers to the
> ADC device.
>
> Signed-off-by: Eugen Hristev <eugen.hristev-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
> ---
> arch/arm/boot/dts/sama5d2.dtsi | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sama5d2.dtsi b/arch/arm/boot/dts/sama5d2.dtsi
> index b1a26b4..30b3797 100644
> --- a/arch/arm/boot/dts/sama5d2.dtsi
> +++ b/arch/arm/boot/dts/sama5d2.dtsi
> @@ -402,7 +402,6 @@
> compatible = "atmel,hlcdc-display-controller";
> #address-cells = <1>;
> #size-cells = <0>;
> -
This is an unrelated change.
> port@0 {
> #address-cells = <1>;
> #size-cells = <0>;
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH v7 00/11] Armada thermal: improvements and A7K/A8K SoCs support
From: Miquel Raynal @ 2017-12-22 16:14 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Gregory Clement, Antoine Tenart, Nadav Haklai,
Miquel Raynal, Baruch Siach, David Sniatkiwicz
Hi,
This series takes over Baruch's series by integrating his patches about
supporting thermal on Armada 7K and 8K SoCs within a larger series with
several improvements on the armada_thermal.c driver.
For now, Armada 380 and CP110 compatibles share the same initialization
routine but this will probably change in the near future when adding
support for overheat interrupts.
DT bindings documentation is updated to match existing code.
Armada AP806 and CP110 DT are also updated with thermal nodes and have
already been accepted (thus absent in this series).
Thank you,
Miquèl
Changes since v6:
- Added Gregory's Tested-by tags.
- Added Rob's Reviewed-by tag on the bindings.
- Addressed Baruch's comment on the temperature derivation.
Baruch Siach (4):
dt-bindings: thermal: Describe Armada AP806 and CP110
thermal: armada: Use msleep for long delays
thermal: armada: Add support for Armada AP806
thermal: armada: Add support for Armada CP110
Miquel Raynal (7):
thermal: armada: Simplify the check of the validity bit
thermal: armada: Clarify control registers accesses
thermal: armada: Use real status register name
thermal: armada: Update Kconfig and module description
thermal: armada: Change sensors trim default value
thermal: armada: Wait sensors validity before exiting the init
callback
thermal: armada: Give meaningful names to the thermal zones
.../devicetree/bindings/thermal/armada-thermal.txt | 37 ++-
drivers/thermal/Kconfig | 4 +-
drivers/thermal/armada_thermal.c | 253 +++++++++++++++------
3 files changed, 214 insertions(+), 80 deletions(-)
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v7 01/11] dt-bindings: thermal: Describe Armada AP806 and CP110
From: Miquel Raynal @ 2017-12-22 16:14 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Gregory Clement, Antoine Tenart, Nadav Haklai,
Miquel Raynal, Baruch Siach, David Sniatkiwicz
In-Reply-To: <20171222161413.20816-1-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
Add compatible strings for AP806 and CP110 that are part of the Armada
8k/7k line of SoCs.
Add a note on the differences in the size of the control area in
different bindings. This is an existing difference between the Armada
375 binding and the other boards already supported. The new AP806 and
CP110 bindings are similar to the existing Armada 375 in this regard.
Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
[<miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: reword, additional details]
Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Reviewed-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
.../devicetree/bindings/thermal/armada-thermal.txt | 37 +++++++++++++++-------
1 file changed, 25 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
index 24aacf8948c5..e0d013a2e66d 100644
--- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
@@ -2,22 +2,35 @@
Required properties:
-- compatible: Should be set to one of the following:
- marvell,armada370-thermal
- marvell,armada375-thermal
- marvell,armada380-thermal
- marvell,armadaxp-thermal
+- compatible: Should be set to one of the following:
+ * marvell,armada370-thermal
+ * marvell,armada375-thermal
+ * marvell,armada380-thermal
+ * marvell,armadaxp-thermal
+ * marvell,armada-ap806-thermal
+ * marvell,armada-cp110-thermal
-- reg: Device's register space.
- Two entries are expected, see the examples below.
- The first one is required for the sensor register;
- the second one is required for the control register
- to be used for sensor initialization (a.k.a. calibration).
+- reg: Device's register space.
+ Two entries are expected, see the examples below. The first one points
+ to the status register (4B). The second one points to the control
+ registers (8B).
+ Note: The compatibles marvell,armada370-thermal,
+ marvell,armada380-thermal, and marvell,armadaxp-thermal must point to
+ "control MSB/control 1", with size of 4 (deprecated binding), or point
+ to "control LSB/control 0" with size of 8 (current binding). All other
+ compatibles must point to "control LSB/control 0" with size of 8.
-Example:
+Examples:
+ /* Legacy bindings */
thermal@d0018300 {
compatible = "marvell,armada370-thermal";
- reg = <0xd0018300 0x4
+ reg = <0xd0018300 0x4
0xd0018304 0x4>;
};
+
+ ap_thermal: thermal@6f8084 {
+ compatible = "marvell,armada-ap806-thermal";
+ reg = <0x6f808C 0x4>,
+ <0x6f8084 0x8>;
+ };
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v7 02/11] thermal: armada: Use msleep for long delays
From: Miquel Raynal @ 2017-12-22 16:14 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland
Cc: linux-pm, devicetree, linux-arm-kernel, Thomas Petazzoni,
Gregory Clement, Antoine Tenart, Nadav Haklai, Miquel Raynal,
Baruch Siach, David Sniatkiwicz
In-Reply-To: <20171222161413.20816-1-miquel.raynal@free-electrons.com>
From: Baruch Siach <baruch@tkos.co.il>
Use msleep for long (> 10ms) delays, instead of the busy waiting mdelay.
All delays are called from the probe routine, where scheduling is
allowed.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 706d74798cbe..6c4af2622d4f 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -113,7 +113,7 @@ static void armada370_init_sensor(struct platform_device *pdev,
reg &= ~PMU_TDC0_START_CAL_MASK;
writel(reg, priv->control);
- mdelay(10);
+ msleep(10);
}
static void armada375_init_sensor(struct platform_device *pdev,
@@ -127,11 +127,11 @@ static void armada375_init_sensor(struct platform_device *pdev,
reg &= ~A375_HW_RESETn;
writel(reg, priv->control + 4);
- mdelay(20);
+ msleep(20);
reg |= A375_HW_RESETn;
writel(reg, priv->control + 4);
- mdelay(50);
+ msleep(50);
}
static void armada380_init_sensor(struct platform_device *pdev,
@@ -143,7 +143,7 @@ static void armada380_init_sensor(struct platform_device *pdev,
if (!(reg & A380_HW_RESET)) {
reg |= A380_HW_RESET;
writel(reg, priv->control);
- mdelay(10);
+ msleep(10);
}
}
--
2.11.0
^ permalink raw reply related
* [PATCH v7 03/11] thermal: armada: Simplify the check of the validity bit
From: Miquel Raynal @ 2017-12-22 16:14 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland
Cc: linux-pm, devicetree, linux-arm-kernel, Thomas Petazzoni,
Gregory Clement, Antoine Tenart, Nadav Haklai, Miquel Raynal,
Baruch Siach, David Sniatkiwicz
In-Reply-To: <20171222161413.20816-1-miquel.raynal@free-electrons.com>
All Armada SoCs use one bit to declare if the sensor values are valid.
This bit moves across the versions of the IP.
The method until then was to do both a shift and compare with an useless
flag of "0x1". It is clearer and quicker to directly save the value that
must be ANDed instead of the bit position and do a single bitwise AND
operation.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index 6c4af2622d4f..f350d7efd35a 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -24,8 +24,6 @@
#include <linux/of_device.h>
#include <linux/thermal.h>
-#define THERMAL_VALID_MASK 0x1
-
/* Thermal Manager Control and Status Register */
#define PMU_TDC0_SW_RST_MASK (0x1 << 1)
#define PMU_TM_DISABLE_OFFS 0
@@ -67,7 +65,7 @@ struct armada_thermal_data {
/* Register shift and mask to access the sensor temperature */
unsigned int temp_shift;
unsigned int temp_mask;
- unsigned int is_valid_shift;
+ u32 is_valid_bit;
};
static void armadaxp_init_sensor(struct platform_device *pdev,
@@ -149,9 +147,9 @@ static void armada380_init_sensor(struct platform_device *pdev,
static bool armada_is_valid(struct armada_thermal_priv *priv)
{
- unsigned long reg = readl_relaxed(priv->sensor);
+ u32 reg = readl_relaxed(priv->sensor);
- return (reg >> priv->data->is_valid_shift) & THERMAL_VALID_MASK;
+ return reg & priv->data->is_valid_bit;
}
static int armada_get_temp(struct thermal_zone_device *thermal,
@@ -199,7 +197,7 @@ static const struct armada_thermal_data armadaxp_data = {
static const struct armada_thermal_data armada370_data = {
.is_valid = armada_is_valid,
.init_sensor = armada370_init_sensor,
- .is_valid_shift = 9,
+ .is_valid_bit = BIT(9),
.temp_shift = 10,
.temp_mask = 0x1ff,
.coef_b = 3153000000UL,
@@ -210,7 +208,7 @@ static const struct armada_thermal_data armada370_data = {
static const struct armada_thermal_data armada375_data = {
.is_valid = armada_is_valid,
.init_sensor = armada375_init_sensor,
- .is_valid_shift = 10,
+ .is_valid_bit = BIT(10),
.temp_shift = 0,
.temp_mask = 0x1ff,
.coef_b = 3171900000UL,
@@ -221,7 +219,7 @@ static const struct armada_thermal_data armada375_data = {
static const struct armada_thermal_data armada380_data = {
.is_valid = armada_is_valid,
.init_sensor = armada380_init_sensor,
- .is_valid_shift = 10,
+ .is_valid_bit = BIT(10),
.temp_shift = 0,
.temp_mask = 0x3ff,
.coef_b = 1172499100UL,
--
2.11.0
^ permalink raw reply related
* [PATCH v7 04/11] thermal: armada: Clarify control registers accesses
From: Miquel Raynal @ 2017-12-22 16:14 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland
Cc: linux-pm, devicetree, linux-arm-kernel, Thomas Petazzoni,
Gregory Clement, Antoine Tenart, Nadav Haklai, Miquel Raynal,
Baruch Siach, David Sniatkiwicz
In-Reply-To: <20171222161413.20816-1-miquel.raynal@free-electrons.com>
Bindings were incomplete for a long time by only exposing one of the two
available control registers. To ease the migration to the full bindings
(already in use for the Armada 375 SoC), rename the pointers for
clarification. This way, it will only be needed to add another pointer
to access the other control register when the time comes.
This avoids dangerous situations where the offset 0 of the control
area can be either one register or the other depending on the bindings
used. After this change, device trees of other SoCs could be migrated to
the "full" bindings if they may benefit from features from the
unaccessible register, without any change in the driver.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 76 ++++++++++++++++++++++++++++------------
1 file changed, 54 insertions(+), 22 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index f350d7efd35a..d58376eba6d9 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -39,12 +39,21 @@
#define A375_HW_RESETn BIT(8)
#define A380_HW_RESET BIT(8)
+/* Legacy bindings */
+#define LEGACY_CONTROL_MEM_LEN 0x4
+
+/* Current bindings with the 2 control registers under the same memory area */
+#define LEGACY_CONTROL1_OFFSET 0x0
+#define CONTROL0_OFFSET 0x0
+#define CONTROL1_OFFSET 0x4
+
struct armada_thermal_data;
/* Marvell EBU Thermal Sensor Dev Structure */
struct armada_thermal_priv {
void __iomem *sensor;
- void __iomem *control;
+ void __iomem *control0;
+ void __iomem *control1;
struct armada_thermal_data *data;
};
@@ -66,27 +75,28 @@ struct armada_thermal_data {
unsigned int temp_shift;
unsigned int temp_mask;
u32 is_valid_bit;
+ bool needs_control0;
};
static void armadaxp_init_sensor(struct platform_device *pdev,
struct armada_thermal_priv *priv)
{
- unsigned long reg;
+ u32 reg;
- reg = readl_relaxed(priv->control);
+ reg = readl_relaxed(priv->control1);
reg |= PMU_TDC0_OTF_CAL_MASK;
- writel(reg, priv->control);
+ writel(reg, priv->control1);
/* Reference calibration value */
reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
- writel(reg, priv->control);
+ writel(reg, priv->control1);
/* Reset the sensor */
- reg = readl_relaxed(priv->control);
- writel((reg | PMU_TDC0_SW_RST_MASK), priv->control);
+ reg = readl_relaxed(priv->control1);
+ writel((reg | PMU_TDC0_SW_RST_MASK), priv->control1);
- writel(reg, priv->control);
+ writel(reg, priv->control1);
/* Enable the sensor */
reg = readl_relaxed(priv->sensor);
@@ -97,19 +107,19 @@ static void armadaxp_init_sensor(struct platform_device *pdev,
static void armada370_init_sensor(struct platform_device *pdev,
struct armada_thermal_priv *priv)
{
- unsigned long reg;
+ u32 reg;
- reg = readl_relaxed(priv->control);
+ reg = readl_relaxed(priv->control1);
reg |= PMU_TDC0_OTF_CAL_MASK;
- writel(reg, priv->control);
+ writel(reg, priv->control1);
/* Reference calibration value */
reg &= ~PMU_TDC0_REF_CAL_CNT_MASK;
reg |= (0xf1 << PMU_TDC0_REF_CAL_CNT_OFFS);
- writel(reg, priv->control);
+ writel(reg, priv->control1);
reg &= ~PMU_TDC0_START_CAL_MASK;
- writel(reg, priv->control);
+ writel(reg, priv->control1);
msleep(10);
}
@@ -117,30 +127,30 @@ static void armada370_init_sensor(struct platform_device *pdev,
static void armada375_init_sensor(struct platform_device *pdev,
struct armada_thermal_priv *priv)
{
- unsigned long reg;
+ u32 reg;
- reg = readl(priv->control + 4);
+ reg = readl(priv->control1);
reg &= ~(A375_UNIT_CONTROL_MASK << A375_UNIT_CONTROL_SHIFT);
reg &= ~A375_READOUT_INVERT;
reg &= ~A375_HW_RESETn;
- writel(reg, priv->control + 4);
+ writel(reg, priv->control1);
msleep(20);
reg |= A375_HW_RESETn;
- writel(reg, priv->control + 4);
+ writel(reg, priv->control1);
msleep(50);
}
static void armada380_init_sensor(struct platform_device *pdev,
struct armada_thermal_priv *priv)
{
- unsigned long reg = readl_relaxed(priv->control);
+ u32 reg = readl_relaxed(priv->control1);
/* Reset hardware once */
if (!(reg & A380_HW_RESET)) {
reg |= A380_HW_RESET;
- writel(reg, priv->control);
+ writel(reg, priv->control1);
msleep(10);
}
}
@@ -214,6 +224,7 @@ static const struct armada_thermal_data armada375_data = {
.coef_b = 3171900000UL,
.coef_m = 10000000UL,
.coef_div = 13616,
+ .needs_control0 = true,
};
static const struct armada_thermal_data armada380_data = {
@@ -253,6 +264,7 @@ MODULE_DEVICE_TABLE(of, armada_thermal_id_table);
static int armada_thermal_probe(struct platform_device *pdev)
{
+ void __iomem *control = NULL;
struct thermal_zone_device *thermal;
const struct of_device_id *match;
struct armada_thermal_priv *priv;
@@ -272,11 +284,31 @@ static int armada_thermal_probe(struct platform_device *pdev)
return PTR_ERR(priv->sensor);
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- priv->control = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(priv->control))
- return PTR_ERR(priv->control);
+ control = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(control))
+ return PTR_ERR(control);
priv->data = (struct armada_thermal_data *)match->data;
+
+ /*
+ * Legacy DT bindings only described "control1" register (also referred
+ * as "control MSB" on old documentation). New bindings cover
+ * "control0/control LSB" and "control1/control MSB" registers within
+ * the same resource, which is then of size 8 instead of 4.
+ */
+ if (resource_size(res) == LEGACY_CONTROL_MEM_LEN) {
+ /* ->control0 unavailable in this configuration */
+ if (priv->data->needs_control0) {
+ dev_err(&pdev->dev, "No access to control0 register\n");
+ return -EINVAL;
+ }
+
+ priv->control1 = control + LEGACY_CONTROL1_OFFSET;
+ } else {
+ priv->control0 = control + CONTROL0_OFFSET;
+ priv->control1 = control + CONTROL1_OFFSET;
+ }
+
priv->data->init_sensor(pdev, priv);
thermal = thermal_zone_device_register("armada_thermal", 0, 0,
--
2.11.0
^ permalink raw reply related
* [PATCH v7 05/11] thermal: armada: Use real status register name
From: Miquel Raynal @ 2017-12-22 16:14 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland
Cc: linux-pm, devicetree, linux-arm-kernel, Thomas Petazzoni,
Gregory Clement, Antoine Tenart, Nadav Haklai, Miquel Raynal,
Baruch Siach, David Sniatkiwicz
In-Reply-To: <20171222161413.20816-1-miquel.raynal@free-electrons.com>
Three 32-bit registers are used to drive the thermal IP: control0,
control1 and status. The two control registers share the same name both
in the documentation and in the code, while the latter is referred as
"sensor" in the code. Rename this pointer to be called "status" in order
to be aligned with the documentation.
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index d58376eba6d9..ceebabf45c53 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -51,7 +51,7 @@ struct armada_thermal_data;
/* Marvell EBU Thermal Sensor Dev Structure */
struct armada_thermal_priv {
- void __iomem *sensor;
+ void __iomem *status;
void __iomem *control0;
void __iomem *control1;
struct armada_thermal_data *data;
@@ -99,9 +99,9 @@ static void armadaxp_init_sensor(struct platform_device *pdev,
writel(reg, priv->control1);
/* Enable the sensor */
- reg = readl_relaxed(priv->sensor);
+ reg = readl_relaxed(priv->status);
reg &= ~PMU_TM_DISABLE_MASK;
- writel(reg, priv->sensor);
+ writel(reg, priv->status);
}
static void armada370_init_sensor(struct platform_device *pdev,
@@ -157,7 +157,7 @@ static void armada380_init_sensor(struct platform_device *pdev,
static bool armada_is_valid(struct armada_thermal_priv *priv)
{
- u32 reg = readl_relaxed(priv->sensor);
+ u32 reg = readl_relaxed(priv->status);
return reg & priv->data->is_valid_bit;
}
@@ -176,7 +176,7 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
return -EIO;
}
- reg = readl_relaxed(priv->sensor);
+ reg = readl_relaxed(priv->status);
reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
/* Get formula coeficients */
@@ -279,9 +279,9 @@ static int armada_thermal_probe(struct platform_device *pdev)
return -ENOMEM;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->sensor = devm_ioremap_resource(&pdev->dev, res);
- if (IS_ERR(priv->sensor))
- return PTR_ERR(priv->sensor);
+ priv->status = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(priv->status))
+ return PTR_ERR(priv->status);
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
control = devm_ioremap_resource(&pdev->dev, res);
--
2.11.0
^ permalink raw reply related
* [PATCH v7 06/11] thermal: armada: Add support for Armada AP806
From: Miquel Raynal @ 2017-12-22 16:14 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Gregory Clement, Antoine Tenart, Nadav Haklai,
Miquel Raynal, Baruch Siach, David Sniatkiwicz
In-Reply-To: <20171222161413.20816-1-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
From: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
The AP806 component is integrated in the Armada 8K and 7K lines of
processors.
The thermal sensor sample field on the status register is a signed
value. Extend armada_get_temp() and the driver structure to handle
signed values.
Signed-off-by: Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org>
[<miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>: Changes when applying over the
previous patches, including the register names changes, also switched
the coefficients values to s64 instead of unsigned long to deal with
negative values and used do_div instead of the traditionnal '/']
Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Reviewed-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Tested-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
drivers/thermal/armada_thermal.c | 74 +++++++++++++++++++++++++++++++---------
1 file changed, 58 insertions(+), 16 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index ceebabf45c53..f35289b1cea9 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -47,6 +47,11 @@
#define CONTROL0_OFFSET 0x0
#define CONTROL1_OFFSET 0x4
+/* TSEN refers to the temperature sensors within the AP */
+#define CONTROL0_TSEN_START BIT(0)
+#define CONTROL0_TSEN_RESET BIT(1)
+#define CONTROL0_TSEN_ENABLE BIT(2)
+
struct armada_thermal_data;
/* Marvell EBU Thermal Sensor Dev Structure */
@@ -66,10 +71,11 @@ struct armada_thermal_data {
bool (*is_valid)(struct armada_thermal_priv *);
/* Formula coeficients: temp = (b - m * reg) / div */
- unsigned long coef_b;
- unsigned long coef_m;
- unsigned long coef_div;
+ s64 coef_b;
+ s64 coef_m;
+ u32 coef_div;
bool inverted;
+ bool signed_sample;
/* Register shift and mask to access the sensor temperature */
unsigned int temp_shift;
@@ -155,6 +161,18 @@ static void armada380_init_sensor(struct platform_device *pdev,
}
}
+static void armada_ap806_init_sensor(struct platform_device *pdev,
+ struct armada_thermal_priv *priv)
+{
+ u32 reg;
+
+ reg = readl_relaxed(priv->control0);
+ reg &= ~CONTROL0_TSEN_RESET;
+ reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
+ writel(reg, priv->control0);
+ msleep(10);
+}
+
static bool armada_is_valid(struct armada_thermal_priv *priv)
{
u32 reg = readl_relaxed(priv->status);
@@ -163,11 +181,11 @@ static bool armada_is_valid(struct armada_thermal_priv *priv)
}
static int armada_get_temp(struct thermal_zone_device *thermal,
- int *temp)
+ int *temp)
{
struct armada_thermal_priv *priv = thermal->devdata;
- unsigned long reg;
- unsigned long m, b, div;
+ u32 reg, div;
+ s64 sample, b, m;
/* Valid check */
if (priv->data->is_valid && !priv->data->is_valid(priv)) {
@@ -178,6 +196,11 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
reg = readl_relaxed(priv->status);
reg = (reg >> priv->data->temp_shift) & priv->data->temp_mask;
+ if (priv->data->signed_sample)
+ /* The most significant bit is the sign bit */
+ sample = sign_extend32(reg, fls(priv->data->temp_mask) - 1);
+ else
+ sample = reg;
/* Get formula coeficients */
b = priv->data->coef_b;
@@ -185,9 +208,10 @@ static int armada_get_temp(struct thermal_zone_device *thermal,
div = priv->data->coef_div;
if (priv->data->inverted)
- *temp = ((m * reg) - b) / div;
+ *temp = div_s64((m * sample) - b, div);
else
- *temp = (b - (m * reg)) / div;
+ *temp = div_s64(b - (m * sample), div);
+
return 0;
}
@@ -199,8 +223,8 @@ static const struct armada_thermal_data armadaxp_data = {
.init_sensor = armadaxp_init_sensor,
.temp_shift = 10,
.temp_mask = 0x1ff,
- .coef_b = 3153000000UL,
- .coef_m = 10000000UL,
+ .coef_b = 3153000000ULL,
+ .coef_m = 10000000ULL,
.coef_div = 13825,
};
@@ -210,8 +234,8 @@ static const struct armada_thermal_data armada370_data = {
.is_valid_bit = BIT(9),
.temp_shift = 10,
.temp_mask = 0x1ff,
- .coef_b = 3153000000UL,
- .coef_m = 10000000UL,
+ .coef_b = 3153000000ULL,
+ .coef_m = 10000000ULL,
.coef_div = 13825,
};
@@ -221,8 +245,8 @@ static const struct armada_thermal_data armada375_data = {
.is_valid_bit = BIT(10),
.temp_shift = 0,
.temp_mask = 0x1ff,
- .coef_b = 3171900000UL,
- .coef_m = 10000000UL,
+ .coef_b = 3171900000ULL,
+ .coef_m = 10000000ULL,
.coef_div = 13616,
.needs_control0 = true,
};
@@ -233,12 +257,26 @@ static const struct armada_thermal_data armada380_data = {
.is_valid_bit = BIT(10),
.temp_shift = 0,
.temp_mask = 0x3ff,
- .coef_b = 1172499100UL,
- .coef_m = 2000096UL,
+ .coef_b = 1172499100ULL,
+ .coef_m = 2000096ULL,
.coef_div = 4201,
.inverted = true,
};
+static const struct armada_thermal_data armada_ap806_data = {
+ .is_valid = armada_is_valid,
+ .init_sensor = armada_ap806_init_sensor,
+ .is_valid_bit = BIT(16),
+ .temp_shift = 0,
+ .temp_mask = 0x3ff,
+ .coef_b = -150000LL,
+ .coef_m = 423ULL,
+ .coef_div = 1,
+ .inverted = true,
+ .signed_sample = true,
+ .needs_control0 = true,
+};
+
static const struct of_device_id armada_thermal_id_table[] = {
{
.compatible = "marvell,armadaxp-thermal",
@@ -257,6 +295,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
.data = &armada380_data,
},
{
+ .compatible = "marvell,armada-ap806-thermal",
+ .data = &armada_ap806_data,
+ },
+ {
/* sentinel */
},
};
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v7 07/11] thermal: armada: Add support for Armada CP110
From: Miquel Raynal @ 2017-12-22 16:14 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland
Cc: linux-pm, devicetree, linux-arm-kernel, Thomas Petazzoni,
Gregory Clement, Antoine Tenart, Nadav Haklai, Miquel Raynal,
Baruch Siach, David Sniatkiwicz
In-Reply-To: <20171222161413.20816-1-miquel.raynal@free-electrons.com>
From: Baruch Siach <baruch@tkos.co.il>
The CP110 component is integrated in the Armada 8k and 7k lines of
processors.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
[<miquel.raynal@free-electrons.com>: renamed the register pointers as
well as some definitions related to the new register names and
simplified the init sequence for Armada 380]
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/armada_thermal.c | 33 ++++++++++++++++++++++++++-------
1 file changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index f35289b1cea9..f2eba2a6f1a5 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -37,7 +37,6 @@
#define A375_UNIT_CONTROL_MASK 0x7
#define A375_READOUT_INVERT BIT(15)
#define A375_HW_RESETn BIT(8)
-#define A380_HW_RESET BIT(8)
/* Legacy bindings */
#define LEGACY_CONTROL_MEM_LEN 0x4
@@ -52,6 +51,10 @@
#define CONTROL0_TSEN_RESET BIT(1)
#define CONTROL0_TSEN_ENABLE BIT(2)
+/* EXT_TSEN refers to the external temperature sensors, out of the AP */
+#define CONTROL1_EXT_TSEN_SW_RESET BIT(7)
+#define CONTROL1_EXT_TSEN_HW_RESETn BIT(8)
+
struct armada_thermal_data;
/* Marvell EBU Thermal Sensor Dev Structure */
@@ -153,12 +156,11 @@ static void armada380_init_sensor(struct platform_device *pdev,
{
u32 reg = readl_relaxed(priv->control1);
- /* Reset hardware once */
- if (!(reg & A380_HW_RESET)) {
- reg |= A380_HW_RESET;
- writel(reg, priv->control1);
- msleep(10);
- }
+ /* Disable the HW/SW reset */
+ reg |= CONTROL1_EXT_TSEN_HW_RESETn;
+ reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
+ writel(reg, priv->control1);
+ msleep(10);
}
static void armada_ap806_init_sensor(struct platform_device *pdev,
@@ -277,6 +279,19 @@ static const struct armada_thermal_data armada_ap806_data = {
.needs_control0 = true,
};
+static const struct armada_thermal_data armada_cp110_data = {
+ .is_valid = armada_is_valid,
+ .init_sensor = armada380_init_sensor,
+ .is_valid_bit = BIT(10),
+ .temp_shift = 0,
+ .temp_mask = 0x3ff,
+ .coef_b = 1172499100ULL,
+ .coef_m = 2000096ULL,
+ .coef_div = 4201,
+ .inverted = true,
+ .needs_control0 = true,
+};
+
static const struct of_device_id armada_thermal_id_table[] = {
{
.compatible = "marvell,armadaxp-thermal",
@@ -299,6 +314,10 @@ static const struct of_device_id armada_thermal_id_table[] = {
.data = &armada_ap806_data,
},
{
+ .compatible = "marvell,armada-cp110-thermal",
+ .data = &armada_cp110_data,
+ },
+ {
/* sentinel */
},
};
--
2.11.0
^ permalink raw reply related
* [PATCH v7 08/11] thermal: armada: Update Kconfig and module description
From: Miquel Raynal @ 2017-12-22 16:14 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland
Cc: linux-pm, devicetree, linux-arm-kernel, Thomas Petazzoni,
Gregory Clement, Antoine Tenart, Nadav Haklai, Miquel Raynal,
Baruch Siach, David Sniatkiwicz
In-Reply-To: <20171222161413.20816-1-miquel.raynal@free-electrons.com>
Update Armada thermal driver Kconfig entry as well as the driver's
MODULE_DESCRIPTION content, now that 64-bit SoCs are also supported,
eg. Armada 7K and Armada 8K.
Use the generic term "Marvell EBU Armada SoCs" instead of listing all
the supported SoCs everywhere (excepted in the Kconfig description,
where it is useful to have a list).
Signed-off-by: Miquel Raynal <miquel.raynal@free-electrons.com>
Reviewed-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
drivers/thermal/Kconfig | 4 ++--
drivers/thermal/armada_thermal.c | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 315ae2926e20..b6adc54b96f1 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -301,13 +301,13 @@ config DB8500_THERMAL
thermal zone if trip points reached.
config ARMADA_THERMAL
- tristate "Armada 370/XP thermal management"
+ tristate "Marvell EBU Armada SoCs thermal management"
depends on ARCH_MVEBU || COMPILE_TEST
depends on HAS_IOMEM
depends on OF
help
Enable this option if you want to have support for thermal management
- controller present in Armada 370 and Armada XP SoC.
+ controller present in Marvell EBU Armada SoCs (370,375,XP,38x,7K,8K).
config DA9062_THERMAL
tristate "DA9062/DA9061 Dialog Semiconductor thermal driver"
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index f2eba2a6f1a5..d426b230e1c5 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -1,5 +1,5 @@
/*
- * Marvell Armada 370/XP thermal sensor driver
+ * Marvell EBU Armada SoCs thermal sensor driver
*
* Copyright (C) 2013 Marvell
*
@@ -407,5 +407,5 @@ static struct platform_driver armada_thermal_driver = {
module_platform_driver(armada_thermal_driver);
MODULE_AUTHOR("Ezequiel Garcia <ezequiel.garcia@free-electrons.com>");
-MODULE_DESCRIPTION("Armada 370/XP thermal driver");
+MODULE_DESCRIPTION("Marvell EBU Armada SoCs thermal driver");
MODULE_LICENSE("GPL v2");
--
2.11.0
^ permalink raw reply related
* [PATCH v7 09/11] thermal: armada: Change sensors trim default value
From: Miquel Raynal @ 2017-12-22 16:14 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Gregory Clement, Antoine Tenart, Nadav Haklai,
Miquel Raynal, Baruch Siach, David Sniatkiwicz
In-Reply-To: <20171222161413.20816-1-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Errata #132698 highlights an error in the default value of Tc trim.
Set this parameter to b'011.
Suggested-by: David Sniatkiwicz <davidsn-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Reviewed-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
drivers/thermal/armada_thermal.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index d426b230e1c5..e6025d215cb5 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -46,6 +46,10 @@
#define CONTROL0_OFFSET 0x0
#define CONTROL1_OFFSET 0x4
+/* Errata fields */
+#define CONTROL0_TSEN_TC_TRIM_MASK 0x7
+#define CONTROL0_TSEN_TC_TRIM_VAL 0x3
+
/* TSEN refers to the temperature sensors within the AP */
#define CONTROL0_TSEN_START BIT(0)
#define CONTROL0_TSEN_RESET BIT(1)
@@ -161,6 +165,15 @@ static void armada380_init_sensor(struct platform_device *pdev,
reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
writel(reg, priv->control1);
msleep(10);
+
+ /* Set Tsen Tc Trim to correct default value (errata #132698) */
+ if (priv->control0) {
+ reg = readl_relaxed(priv->control0);
+ reg &= ~CONTROL0_TSEN_TC_TRIM_MASK;
+ reg |= CONTROL0_TSEN_TC_TRIM_VAL;
+ writel(reg, priv->control0);
+ msleep(10);
+ }
}
static void armada_ap806_init_sensor(struct platform_device *pdev,
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v7 10/11] thermal: armada: Wait sensors validity before exiting the init callback
From: Miquel Raynal @ 2017-12-22 16:14 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Gregory Clement, Antoine Tenart, Nadav Haklai,
Miquel Raynal, Baruch Siach, David Sniatkiwicz
In-Reply-To: <20171222161413.20816-1-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The thermal core will check for sensors validity right after the
initialization callback has returned. As the initialization routine make
a reset, the sensors are not ready immediately and the core spawns an
error in the dmesg. Avoid this annoying situation by polling on the
validity bit before exiting from these routines. This also avoid the use
of blind sleeps.
Suggested-by: David Sniatkiwicz <davidsn-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Reviewed-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
drivers/thermal/armada_thermal.c | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index e6025d215cb5..a4befd2d683d 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -23,6 +23,7 @@
#include <linux/platform_device.h>
#include <linux/of_device.h>
#include <linux/thermal.h>
+#include <linux/iopoll.h>
/* Thermal Manager Control and Status Register */
#define PMU_TDC0_SW_RST_MASK (0x1 << 1)
@@ -59,6 +60,9 @@
#define CONTROL1_EXT_TSEN_SW_RESET BIT(7)
#define CONTROL1_EXT_TSEN_HW_RESETn BIT(8)
+#define STATUS_POLL_PERIOD_US 1000
+#define STATUS_POLL_TIMEOUT_US 100000
+
struct armada_thermal_data;
/* Marvell EBU Thermal Sensor Dev Structure */
@@ -155,6 +159,16 @@ static void armada375_init_sensor(struct platform_device *pdev,
msleep(50);
}
+static void armada_wait_sensor_validity(struct armada_thermal_priv *priv)
+{
+ u32 reg;
+
+ readl_relaxed_poll_timeout(priv->status, reg,
+ reg & priv->data->is_valid_bit,
+ STATUS_POLL_PERIOD_US,
+ STATUS_POLL_TIMEOUT_US);
+}
+
static void armada380_init_sensor(struct platform_device *pdev,
struct armada_thermal_priv *priv)
{
@@ -164,7 +178,6 @@ static void armada380_init_sensor(struct platform_device *pdev,
reg |= CONTROL1_EXT_TSEN_HW_RESETn;
reg &= ~CONTROL1_EXT_TSEN_SW_RESET;
writel(reg, priv->control1);
- msleep(10);
/* Set Tsen Tc Trim to correct default value (errata #132698) */
if (priv->control0) {
@@ -172,8 +185,10 @@ static void armada380_init_sensor(struct platform_device *pdev,
reg &= ~CONTROL0_TSEN_TC_TRIM_MASK;
reg |= CONTROL0_TSEN_TC_TRIM_VAL;
writel(reg, priv->control0);
- msleep(10);
}
+
+ /* Wait the sensors to be valid or the core will warn the user */
+ armada_wait_sensor_validity(priv);
}
static void armada_ap806_init_sensor(struct platform_device *pdev,
@@ -185,7 +200,9 @@ static void armada_ap806_init_sensor(struct platform_device *pdev,
reg &= ~CONTROL0_TSEN_RESET;
reg |= CONTROL0_TSEN_START | CONTROL0_TSEN_ENABLE;
writel(reg, priv->control0);
- msleep(10);
+
+ /* Wait the sensors to be valid or the core will warn the user */
+ armada_wait_sensor_validity(priv);
}
static bool armada_is_valid(struct armada_thermal_priv *priv)
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v7 11/11] thermal: armada: Give meaningful names to the thermal zones
From: Miquel Raynal @ 2017-12-22 16:14 UTC (permalink / raw)
To: Zhang Rui, Eduardo Valentin, Rob Herring, Mark Rutland
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Thomas Petazzoni, Gregory Clement, Antoine Tenart, Nadav Haklai,
Miquel Raynal, Baruch Siach, David Sniatkiwicz
In-Reply-To: <20171222161413.20816-1-miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
After registration to the thermal core, sysfs will make one entry
per instance of the driver in /sys/class/thermal_zoneX and
/sys/class/hwmon/hwmonX, X being the index of the instance, all of them
having the type/name "armada_thermal".
Until now there was only one thermal zone per SoC but SoCs like Armada
A7K and Armada A8K have respectively two and three thermal zones (one
per AP and one per CP) and this number is subject to grow in the future.
Use dev_name() instead of the "armada_thermal" string to get a
meaningful name and be able to identify the thermal zones from
userspace.
Signed-off-by: Miquel Raynal <miquel.raynal-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Reviewed-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Tested-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
drivers/thermal/armada_thermal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/armada_thermal.c b/drivers/thermal/armada_thermal.c
index a4befd2d683d..4c275ec10ac5 100644
--- a/drivers/thermal/armada_thermal.c
+++ b/drivers/thermal/armada_thermal.c
@@ -402,8 +402,8 @@ static int armada_thermal_probe(struct platform_device *pdev)
priv->data->init_sensor(pdev, priv);
- thermal = thermal_zone_device_register("armada_thermal", 0, 0,
- priv, &ops, NULL, 0, 0);
+ thermal = thermal_zone_device_register(dev_name(&pdev->dev), 0, 0, priv,
+ &ops, NULL, 0, 0);
if (IS_ERR(thermal)) {
dev_err(&pdev->dev,
"Failed to register thermal zone device\n");
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCHv3 RESEND 1/3] Documentation: dt: memory: ti-emif: add edac support under emif
From: Tero Kristo @ 2017-12-22 16:23 UTC (permalink / raw)
To: devicetree; +Cc: Tony Lindgren, Rob Herring, linux-omap, linux-arm-kernel
Certain revisions of the TI EMIF IP contain ECC support in them. Reflect
this in the DT binding.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Rob Herring <robh+dt@kernel.org>
---
Just resending this patch, missed adding devicetree list on this previously
and it got lost.
.../devicetree/bindings/memory-controllers/ti/emif.txt | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
index 0db6047..f56a347 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
@@ -3,12 +3,16 @@
EMIF - External Memory Interface - is an SDRAM controller used in
TI SoCs. EMIF supports, based on the IP revision, one or more of
DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
-of the EMIF IP and memory parts attached to it.
+of the EMIF IP and memory parts attached to it. Certain revisions
+of the EMIF IP controller also contain optional ECC support, which
+corrects one bit errors and detects two bit errors.
Required properties:
- compatible : Should be of the form "ti,emif-<ip-rev>" where <ip-rev>
is the IP revision of the specific EMIF instance.
For am437x should be ti,emif-am4372.
+ For dra7xx should be ti,emif-dra7xx.
+ For k2x family, should be ti,emif-keystone.
- phy-type : <u32> indicating the DDR phy type. Following are the
allowed values
@@ -42,6 +46,10 @@ Optional properties:
- hw-caps-temp-alert : Have this property if the controller
has capability for generating SDRAM temperature alerts
+- interrupts : A list of interrupt specifiers for memory
+ controller interrupts, if available. Required for EMIF instances
+ that support ECC.
+
Example:
emif1: emif@0x4c000000 {
@@ -54,3 +62,9 @@ emif1: emif@0x4c000000 {
hw-caps-ll-interface;
hw-caps-temp-alert;
};
+
+emif1: emif@4c000000 {
+ compatible = "ti,emif-dra7";
+ reg = <0x4c000000 0x200>;
+ interrupts = <GIC_SPI 105 IRQ_TYPE_LEVEL_HIGH>;
+};
--
1.9.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply related
* Re: [PATCH 13/14] input: touchscreen: sama5d2_rts: SAMA5D2 Resistive touchscreen driver
From: Philippe Ombredanne @ 2017-12-22 16:29 UTC (permalink / raw)
To: Eugen Hristev
Cc: Nicolas Ferre, ludovic.desroches-UWL1GkI3JZL3oGB3hsPCZA,
Alexandre Belloni, linux-iio-u79uwXL29TY76Z2rM5mHXA,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS, LKML,
Jonathan Cameron, linux-input-u79uwXL29TY76Z2rM5mHXA,
Dmitry Torokhov
In-Reply-To: <1513955241-10985-14-git-send-email-eugen.hristev-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
Eugen,
On Fri, Dec 22, 2017 at 4:07 PM, Eugen Hristev
<eugen.hristev-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org> wrote:
> This is the implementation of the Microchip SAMA5D2 SOC resistive
> touchscreen driver.
<snip>
> --- /dev/null
> +++ b/drivers/input/touchscreen/sama5d2_rts.c
> @@ -0,0 +1,287 @@
> +/*
> + * Microchip resistive touchscreen (RTS) driver for SAMA5D2.
> + *
> + * Copyright (C) 2017 Microchip Technology,
> + * Author: Eugen Hristev <eugen.hristev-UWL1GkI3JZL3oGB3hsPCZA@public.gmane.org>
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + */
IMHO this should be this as a the first line instead as documented in
Thomas patch set [0] :
> +// SPDX-License-Identifier: GPL-2.0
I am just a lowly messenger and my weightless voice is as light as the
down feather of a new born goose. But if you have concerns with using
C++ comment styles as you should, please read Linus [1][2][3],
Thomas[4] and Greg[5] comments on the topic.
[0] https://lkml.org/lkml/2017/12/4/934
[1] https://lkml.org/lkml/2017/11/2/715
[2] https://lkml.org/lkml/2017/11/25/125
[3] https://lkml.org/lkml/2017/11/25/133
[4] https://lkml.org/lkml/2017/11/2/805
[5] https://lkml.org/lkml/2017/10/19/165
--
Cordially
Philippe Ombredanne, a kernel licensing scruffy
^ permalink raw reply
* Re: [PATCH v4] hwrng: exynos - add Samsung Exynos True RNG driver
From: Łukasz Stelmach @ 2017-12-22 16:38 UTC (permalink / raw)
To: Philippe Ombredanne
Cc: Andrew F . Davis, PrasannaKumar Muralidharan, Rob Herring,
Matt Mackall, Herbert Xu, Krzysztof Kozlowski, Kukjin Kim,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-crypto, linux-samsung-soc, LKML, Marek Szyprowski,
Bartlomiej Zolnierkiewicz
In-Reply-To: <CAOFm3uG2aBHWUgVyzPuU8XJaLbm78cWEuWvgLEvNfc-hiefAbw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2533 bytes --]
It was <2017-12-22 pią 14:34>, when Philippe Ombredanne wrote:
> Łukasz,
>
> On Fri, Dec 22, 2017 at 2:23 PM, Łukasz Stelmach <l.stelmach@samsung.com> wrote:
>> Add support for True Random Number Generator found in Samsung Exynos
>> 5250+ SoCs.
>>
>> Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
>> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
>
> <snip>
>
>> --- /dev/null
>> +++ b/drivers/char/hw_random/exynos-trng.c
>> @@ -0,0 +1,245 @@
>> +/*
>> + * RNG driver for Exynos TRNGs
>> + *
>> + * Author: Łukasz Stelmach <l.stelmach@samsung.com>
>> + *
>> + * Copyright 2017 (c) Samsung Electronics Software, Inc.
>> + *
>> + * Based on the Exynos PRNG driver drivers/crypto/exynos-rng by
>> + * Krzysztof Kozłowski <krzk@kernel.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation;
>> + *
>> + * 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.
>> + */
>
>
> Would you mind using the new SPDX tags documented in Thomas patch set
> [1] rather than this fine but longer legalese?
>
> And if you could spread the word to others in your team this would be very nice.
> See also this fine article posted by Mauro on the Samsung Open Source
> Group Blog [2]
> Thank you!
Cool! We've been using SPDX to tag RPM packages in Tizen for three years or
more. ;-)
>> +MODULE_LICENSE("GPL");
>
> Per module.h this means GPL2 or later. This is not matching your
> license above which does not state any version and therefore would
> mean GPL1 or later,
Thanks for spotting. My intention is GPL-2.0.
> Please make sure you use something and common rather than this and
> make sure your MODULE_LICENSE is consistent with the top level
> license.
>
> Was it this way in the code from Krzysztof?
Yes. And omap-rng, the second of my sources of reference, too. Actually,
the majority of modules still specify "GPL".
281 | "Dual */*"
2082 | "GPL v2"
6359 | "GPL"
---- +---------
8784 | Total
Fixing.
> [1] https://lkml.org/lkml/2017/12/4/934
> [2] https://blogs.s-osg.org/linux-kernel-license-practices-revisited-spdx/
--
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]
^ permalink raw reply
* [PATCH v5] hwrng: exynos - add Samsung Exynos True RNG driver
From: Łukasz Stelmach @ 2017-12-22 16:48 UTC (permalink / raw)
To: Philippe Ombredanne, Andrew F . Davis, PrasannaKumar Muralidharan,
Rob Herring, Matt Mackall, Herbert Xu, Krzysztof Kozlowski,
Kukjin Kim, devicetree, linux-crypto, linux-samsung-soc,
linux-kernel
Cc: Łukasz Stelmach, Marek Szyprowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <20171222132338.30054-1-l.stelmach@samsung.com>
Add support for True Random Number Generator found in Samsung Exynos
5250+ SoCs.
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
---
Changes since v4:
- SPDX license header instead of the traditional blurb.
- MODULE_LICENSE("GPL v2") instead of "GPL"
Thank you, Philippe Ombredanne.
MAINTAINERS | 7 ++
drivers/char/hw_random/Kconfig | 12 ++
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/exynos-trng.c | 237 +++++++++++++++++++++++++++++++++++
4 files changed, 257 insertions(+)
create mode 100644 drivers/char/hw_random/exynos-trng.c
diff --git a/MAINTAINERS b/MAINTAINERS
index e6d849d0d153..1082846edb9b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11933,6 +11933,13 @@ S: Maintained
F: drivers/crypto/exynos-rng.c
F: Documentation/devicetree/bindings/crypto/samsung,exynos-rng4.txt
+SAMSUNG EXYNOS TRUE RANDOM NUMBER GENERATOR (TRNG) DRIVER
+M: Łukasz Stelmach <l.stelmach@samsung.com>
+L: linux-samsung-soc@vger.kernel.org
+S: Maintained
+F: drivers/char/hw_random/exynos-trng.c
+F: Documentation/devicetree/bindings/rng/samsung,exynos5250-trng.txt
+
SAMSUNG FRAMEBUFFER DRIVER
M: Jingoo Han <jingoohan1@gmail.com>
L: linux-fbdev@vger.kernel.org
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 90e4bb24819e..32f715394904 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -437,6 +437,18 @@ config HW_RANDOM_S390
If unsure, say Y.
+config HW_RANDOM_EXYNOS
+ tristate "Samsung Exynos True Random Number Generator support"
+ depends on ARCH_EXYNOS || COMPILE_TEST
+ default HW_RANDOM
+ ---help---
+ This driver provides support for the True Random Number
+ Generator available in Exynos SoCs.
+
+ To compile this driver as a module, choose M here: the module
+ will be called exynos-trng.
+
+ If unsure, say Y.
endif # HW_RANDOM
config UML_RANDOM
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index e7146a84d44a..7c8a66fe8cf6 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_HW_RANDOM_GEODE) += geode-rng.o
obj-$(CONFIG_HW_RANDOM_N2RNG) += n2-rng.o
n2-rng-y := n2-drv.o n2-asm.o
obj-$(CONFIG_HW_RANDOM_VIA) += via-rng.o
+obj-$(CONFIG_HW_RANDOM_EXYNOS) += exynos-trng.o
obj-$(CONFIG_HW_RANDOM_IXP4XX) += ixp4xx-rng.o
obj-$(CONFIG_HW_RANDOM_OMAP) += omap-rng.o
obj-$(CONFIG_HW_RANDOM_OMAP3_ROM) += omap3-rom-rng.o
diff --git a/drivers/char/hw_random/exynos-trng.c b/drivers/char/hw_random/exynos-trng.c
new file mode 100644
index 000000000000..34d6f51ecbee
--- /dev/null
+++ b/drivers/char/hw_random/exynos-trng.c
@@ -0,0 +1,237 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RNG driver for Exynos TRNGs
+ *
+ * Author: Łukasz Stelmach <l.stelmach@samsung.com>
+ *
+ * Copyright 2017 (c) Samsung Electronics Software, Inc.
+ *
+ * Based on the Exynos PRNG driver drivers/crypto/exynos-rng by
+ * Krzysztof Kozłowski <krzk@kernel.org>
+ */
+
+#include <linux/clk.h>
+#include <linux/crypto.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/hw_random.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+
+#define EXYNOS_TRNG_CLKDIV (0x0)
+
+#define EXYNOS_TRNG_CTRL (0x20)
+#define EXYNOS_TRNG_CTRL_RNGEN BIT(31)
+
+#define EXYNOS_TRNG_POST_CTRL (0x30)
+#define EXYNOS_TRNG_ONLINE_CTRL (0x40)
+#define EXYNOS_TRNG_ONLINE_STAT (0x44)
+#define EXYNOS_TRNG_ONLINE_MAXCHI2 (0x48)
+#define EXYNOS_TRNG_FIFO_CTRL (0x50)
+#define EXYNOS_TRNG_FIFO_0 (0x80)
+#define EXYNOS_TRNG_FIFO_1 (0x84)
+#define EXYNOS_TRNG_FIFO_2 (0x88)
+#define EXYNOS_TRNG_FIFO_3 (0x8c)
+#define EXYNOS_TRNG_FIFO_4 (0x90)
+#define EXYNOS_TRNG_FIFO_5 (0x94)
+#define EXYNOS_TRNG_FIFO_6 (0x98)
+#define EXYNOS_TRNG_FIFO_7 (0x9c)
+#define EXYNOS_TRNG_FIFO_LEN (8)
+#define EXYNOS_TRNG_CLOCK_RATE (500000)
+
+
+struct exynos_trng_dev {
+ struct device *dev;
+ void __iomem *mem;
+ struct clk *clk;
+ struct hwrng rng;
+};
+
+static int exynos_trng_do_read(struct hwrng *rng, void *data, size_t max,
+ bool wait)
+{
+ struct exynos_trng_dev *trng;
+ u32 val;
+
+ max = min_t(size_t, max, (EXYNOS_TRNG_FIFO_LEN * 4));
+
+ trng = (struct exynos_trng_dev *)rng->priv;
+
+ writel_relaxed(max * 8, trng->mem + EXYNOS_TRNG_FIFO_CTRL);
+ val = readl_poll_timeout(trng->mem + EXYNOS_TRNG_FIFO_CTRL, val,
+ val == 0, 200, 1000000);
+ if (val < 0)
+ return val;
+
+ memcpy_fromio(data, trng->mem + EXYNOS_TRNG_FIFO_0, max);
+
+ return max;
+}
+
+static int exynos_trng_init(struct hwrng *rng)
+{
+ struct exynos_trng_dev *trng = (struct exynos_trng_dev *)rng->priv;
+ unsigned long sss_rate;
+ u32 val;
+
+ sss_rate = clk_get_rate(trng->clk);
+
+ /*
+ * For most TRNG circuits the clock frequency of under 500 kHz
+ * is safe.
+ */
+ val = sss_rate / (EXYNOS_TRNG_CLOCK_RATE * 2);
+ if (val > 0x7fff) {
+ dev_err(trng->dev, "clock divider too large: %d", val);
+ return -ERANGE;
+ }
+ val = val << 1;
+ writel_relaxed(val, trng->mem + EXYNOS_TRNG_CLKDIV);
+
+ /* Enable the generator. */
+ val = EXYNOS_TRNG_CTRL_RNGEN;
+ writel_relaxed(val, trng->mem + EXYNOS_TRNG_CTRL);
+
+ /*
+ * Disable post-processing. /dev/hwrng is supposed to deliver
+ * unprocessed data.
+ */
+ writel_relaxed(0, trng->mem + EXYNOS_TRNG_POST_CTRL);
+
+ return 0;
+}
+
+static int exynos_trng_probe(struct platform_device *pdev)
+{
+ struct exynos_trng_dev *trng;
+ struct resource *res;
+ int ret = -ENOMEM;
+
+ trng = devm_kzalloc(&pdev->dev, sizeof(*trng), GFP_KERNEL);
+ if (!trng)
+ return ret;
+
+ trng->rng.name = devm_kstrdup(&pdev->dev, dev_name(&pdev->dev),
+ GFP_KERNEL);
+ if (!trng->rng.name)
+ return ret;
+
+ trng->rng.init = exynos_trng_init;
+ trng->rng.read = exynos_trng_do_read;
+ trng->rng.priv = (unsigned long) trng;
+
+ platform_set_drvdata(pdev, trng);
+ trng->dev = &pdev->dev;
+
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ trng->mem = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(trng->mem)) {
+ dev_err(&pdev->dev, "Could not map IO resources.\n");
+ return PTR_ERR(trng->mem);
+ }
+
+ pm_runtime_enable(&pdev->dev);
+ ret = pm_runtime_get_sync(&pdev->dev);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Could not get runtime PM.\n");
+ goto err_pm_get;
+ }
+
+ trng->clk = devm_clk_get(&pdev->dev, "secss");
+ if (IS_ERR(trng->clk)) {
+ ret = PTR_ERR(trng->clk);
+ dev_err(&pdev->dev, "Could not get clock.\n");
+ goto err_clock;
+ }
+
+ ret = clk_prepare_enable(trng->clk);
+ if (ret) {
+ dev_err(&pdev->dev, "Could not enable the clk.\n");
+ goto err_clock;
+ }
+
+ ret = hwrng_register(&trng->rng);
+ if (ret) {
+ dev_err(&pdev->dev, "Could not register hwrng device.\n");
+ goto err_register;
+ }
+
+ dev_info(&pdev->dev, "Exynos True Random Number Generator.\n");
+
+ return 0;
+
+err_register:
+ clk_disable_unprepare(trng->clk);
+
+err_clock:
+ pm_runtime_put_sync(&pdev->dev);
+
+err_pm_get:
+ pm_runtime_disable(&pdev->dev);
+
+ return ret;
+}
+
+static int exynos_trng_remove(struct platform_device *pdev)
+{
+ struct exynos_trng_dev *trng = platform_get_drvdata(pdev);
+
+ hwrng_unregister(&trng->rng);
+ clk_disable_unprepare(trng->clk);
+
+ pm_runtime_put_sync(&pdev->dev);
+ pm_runtime_disable(&pdev->dev);
+
+ return 0;
+}
+
+static int __maybe_unused exynos_trng_suspend(struct device *dev)
+{
+ pm_runtime_put_sync(dev);
+
+ return 0;
+}
+
+static int __maybe_unused exynos_trng_resume(struct device *dev)
+{
+ int ret;
+
+ ret = pm_runtime_get_sync(dev);
+ if (ret < 0) {
+ dev_err(dev, "Could not get runtime PM.\n");
+ pm_runtime_put_noidle(dev);
+ return ret;
+ }
+
+ return 0;
+}
+
+static SIMPLE_DEV_PM_OPS(exynos_trng_pm_ops, exynos_trng_suspend,
+ exynos_trng_resume);
+
+static const struct of_device_id exynos_trng_dt_match[] = {
+ {
+ .compatible = "samsung,exynos5250-trng",
+ },
+ { },
+};
+MODULE_DEVICE_TABLE(of, exynos_trng_dt_match);
+
+static struct platform_driver exynos_trng_driver = {
+ .driver = {
+ .name = "exynos-trng",
+ .pm = &exynos_trng_pm_ops,
+ .of_match_table = exynos_trng_dt_match,
+ },
+ .probe = exynos_trng_probe,
+ .remove = exynos_trng_remove,
+};
+
+module_platform_driver(exynos_trng_driver);
+MODULE_AUTHOR("Łukasz Stelmach");
+MODULE_DESCRIPTION("H/W TRNG driver for Exynos chips");
+MODULE_LICENSE("GPL v2");
--
2.11.0
^ permalink raw reply related
* Re: [PATCH v2 1/5] dt-bindings: at24: consistently document the compatible property
From: Peter Rosin @ 2017-12-22 16:58 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Bartosz Golaszewski, Andy Shevchenko, Rob Herring, Mark Rutland,
David Lechner, Divagar Mohandass, Linux I2C,
devicetree-u79uwXL29TY76Z2rM5mHXA, Linux Kernel
In-Reply-To: <CABxcv=kkp_Ck_JdDGomAGmSsTiCg82X67j5hEsvRnnY3RDMMfg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 2017-12-22 00:38, Javier Martinez Canillas wrote:
> Hello Peter,
>
> On Fri, Dec 22, 2017 at 12:07 AM, Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org> wrote:
>> On 2017-12-21 21:27, Javier Martinez Canillas wrote:
>>> Hello Peter,
>>>
>>> On Thu, Dec 21, 2017 at 5:20 PM, Peter Rosin <peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org> wrote:
>>>> On 2017-12-21 14:48, Bartosz Golaszewski wrote:
>>>>> Current description of the compatible property for at24 is quite vague.
>>>>>
>>>>> Specify an exact list of accepted compatibles and document the - now
>>>>> deprecated - strings which were previously used in device tree files.
>>>>
>>>> Why is it suddenly deprecated to correctly specify what hardware you
>>>> have, e.g. "nxp,24c32". In this case the manufacturer is nxp, damnit.
>>>
>>> Sorry but I disagree.
>>>
>>> When you specify a compatible string, you are not specifying a
>>> particular hardware but a device programming model.
>>
>> That's not what it says in https://elinux.org/Device_Tree_Usage
>
> I think the most up-to-date DT reference is at:
>
> https://www.devicetree.org/
>
>> in the "Understanding the compatible Property" section. I quote:
>>
>> compatible is a list of strings. The first string in the
>> list specifies the exact device that the node represents
>> in the form "<manufacturer>,<model>". The following strings
>> represent other devices that the device is compatible with.
>>
>> Pretty clearly talks about devices and not programming models. But
>> maybe I shouldn't trust that reference? What should I be reading
>> instead?
>>
>
> For example the latest spec draft
> (https://github.com/devicetree-org/devicetree-specification/releases/download/v0.2-rc1/devicetree-specification-v0.2-rc1.pdf)
> says:
>
> "The compatible property value consists of one or more strings that
> define the specific programming model for the device. This list of
> strings should be used by a client program for device driver
> selection. The property value consists of a concatenated list of null
> terminated strings, from most specific to most general. They allow a
> device to express its compatibility with a family of similar devices,
> potentially allowing a single device driver to match against several
> devices."
>
> The recommended format is "manufacturer,model", where manufacturer is
> a string describing the name of the manufacturer (such as a stock
> ticker symbol), and model specifies the model number."
>
> Example:
>
> compatible = "fsl,mpc8641", "ns16550";
>
> In this example, an operating system would first try to locate a
> device driver that supported fsl,mpc8641. If a driver was not found,
> it would then try to locate a driver that supported the more general
> ns16550 device type."
Yes, that's a bit different from the wording on the elinux site. Thanks
for the pointer! Google was not my friend on this occasion, since I
managed to miss that site in my searches. Maybe it has gotten a higher
rank now that 0.2 is out, because now I find it easily?
>>> It's very common to use a compatible string that doesn't match exactly
>>> the specific hardware used. That's why it's called _compatible_ BTW.
>>
>> That's not how I read the above.
>>
>
> That's not how I read it nor my experience with DT, but of course I
> may be wrong on this.
Either way, it should not be wrong to specify the more specific binding
before the generic fallback, as is done in the at91-tse850-3.dts
example I gave below.
>>> For example when a DTS define a UART node with an ns16550 compatible,
>>> they don't really mean that have a UART IC manufactured by National
>>> Semiconductor.
>>
>> That just tells me that most people are a little bit lazy and ready
>> to cut a corner or two when they can get away with it. Or that there
>> is some form of misunderstanding at work...
>>
>
> For example, I usually see that different SoC families from the same
> vendor use the same compatible string for integrated peripherals just
> because are the same from a programming model point of view.
>
> TI am33xx SoCs use a lot of omap3 compatible strings on their nodes
> and its similar on Exynos SoCs which are the two ARM SoCs I'm most
> familiar with. Following your logic that's wrong and instead a new
> compatible string should be added for the GPIO or pinctrl drivers even
> when are the same because refer to different devices.
Considering the above quote from the actual DT spec, I wouldn't say wrong.
But I'd still say that it should be preferred to list the actual device
before the fallback to some generic programming model compatible or some
previous version of the hardware/IP-block. Just in case an unintended
difference is discovered late in the game...
>>>> Sure, it happens to be compatible with "atmel,24c32", but that is
>>>> supposed to be written with a fallback as
>>>>
>>>> "nxp,24c32", "atmel,24c32"
>>>
>>> This isn't a requirement really, systems integrators are free to use
>>> more than one <manufacturer,model> tuple in the compatible string if
>>> they want the DTB to be future proof, just in case there's a need for
>>> a more specific driver or if the programming model happened to not be
>>> the same at the end. This is usually done for the boards compatible
>>> string as an example, even when there isn't a struct machine_desc for
>>> the specific board compatible and only for the SoC family.
>>>
>>> So it's OK if you want to define the compatible as "nxp,24c32",
>>> "atmel,24c32", but that's a general OF concept and not something
>>> related to the at24 eeprom driver so I'm not sure if it should be
>>> mentioned in the at24 DT binding doc.
>>
>> One problem is that if "nxp,24c32" (or "nxp,24c02" as in the example
>> below) is not a valid compatible, the tooling will be correct to
>> complain about it. Currently, it is just a checkpatch deficiency that
>> it complains like this:
>>
>> $ scripts/checkpatch.pl -f arch/arm/boot/dts/at91-tse850-3.dts
>> WARNING: DT compatible string "nxp,24c02" appears un-documented -- check ./Documentation/devicetree/bindings/
>> #249: FILE: arch/arm/boot/dts/at91-tse850-3.dts:249:
>> + compatible = "nxp,24c02", "atmel,24c02";
>>
>
> But isn't that a bug in checkpatch? as long as there's a valid
> <manufacturer,model> tuple in the compatible string, it shouldn't
> complain.
Then there is a significant risk that speeling mistakes are not
caught. So, I don't think it will be considered a bug unless a DT
guru says so of course. I think the checkpatch intention is to catch
all undocumented compatibles. But I don't know of course...
>>>> if I understand correctly. So, why is that deprecated in this case?
>>>>
>>>> What if (a few years down the line) it is discovered that some weird
>>>> quirk is needed that is only appropriate for nxp chips?
>>>>
>>>> nxp is of course just an example, pick any manufacturer of eeproms
>>>> (supposedly) compatible with the atmel interface.
>>>>
>>>
>>> That's indeed a possibility and the reason why most DT nodes have a
>>> more specific <manufacturer,model> before the generic one matched by
>>> drivers. I really doubt that in the future it will be found that a
>>> more specific compatible string is needed for one manufacturer in this
>>> case, specially since the driver didn't even care about the
>>> manufacturers until recently.
>>
>> I'm not talking about the driver. But if what you say is true, that
>> change would have broken a number of existing DTBs. Is that really the
>> case?
>>
>
> Sorry, I didn't get which change you meant.
I meant whatever change you implied with "the driver didn't even care
about the manufacturers until recently". However, on second reading it
may be the case that "care" did not imply that a breaking change was
made, that was however my interpretation. Oh well...
>>> So I think that makes no sense for a driver to support all possible
>>> manufacturers as possible compatible strings if all the devices have
>>> the same exact programming model.
>>
>> That's what the fallback is for. With that in place the driver can
>> start to care when there is a need but until then it can work just
>> as it always has. Without knowing the specific device, the driver has
>> less chance to adapt when the unexpected is discovered. But again,
>> I'm not really discussing driver details, I'm complaining about the
>> proposed changes to the bindings. I simply don't see how they make
>> sense.
>>
>
> My point is that saying in a DT binding that you could have a more
> specific <manufacturer,model> followed by a generic one is redundant.
> That's already something one can do to make the DT future proof and
> latter if is found that the more specific pair is needed, then
> compatible can be added to the OF device ID table making the driver to
> match that an the <manufacturer,model> added to the DT binding making
> it formal.
>
> That's my understanding at least, but I could be completely wrong too
> since I'm not a DT expert.
My understanding is that in order to do that future proofing, you first
have to document the more specific binding. Note that documenting the
more specific binding will not add any burden whatsoever to the driver,
as long as the fallback is in place, at least until a difference
between the specific and the generic device or programming model is
discovered... So, until you need to use the specific compatible, it is
pure documentation overhead.
This 1/5 patch deprecates the more specific bindings, and that seems to
be the wrong direction. *More* of the specific compatibles should be
encouraged (and documented) instead of less.
But what do I know? Anyway, I'll shut up now, I think I've made my point...
Cheers,
Peter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox