[GIT PULL] Thermal-SoC management changes for v5.4-rc1
Hello Linus, Please consider the following thermal soc changes for v5.4-rc1. This is a really small pull in the midst of a lot of pending patches. We are in the middle of restructuring how we are maintaining the thermal subsystem, as per discussion in our last LPC. For now, I am sending just some changes that were pending in my tree. Looking forward to get a more streamlined process in the next merge window. The following changes since commit 56037cadf60461b4a2996b4d8f0057c4d343c17c: Merge tag 'regulator-fix-v5.3-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator (2019-09-09 10:58:57 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal linus for you to fetch changes up to 6c375eccded41df8033ed55a1b785531b304fc67: thermal: db8500: Rewrite to be a pure OF sensor (2019-09-24 22:59:22 -0700) Dan Carpenter (1): thermal: thermal_mmio: remove some dead code Linus Walleij (3): thermal: db8500: Finalize device tree conversion thermal: db8500: Use dev helper variable thermal: db8500: Rewrite to be a pure OF sensor drivers/mfd/db8500-prcmu.c | 53 +-- drivers/thermal/Kconfig | 2 +- drivers/thermal/db8500_thermal.c | 486 ++- drivers/thermal/thermal_mmio.c | 7 - include/linux/platform_data/db8500_thermal.h | 29 -- 5 files changed, 114 insertions(+), 463 deletions(-) delete mode 100644 include/linux/platform_data/db8500_thermal.h
Re: [PATCHv2 2/2] hwmon: core: fix potential memory leak in *hwmon_device_register*
On Wed, Jun 05, 2019 at 01:38:38PM -0700, Guenter Roeck wrote:
> On Wed, May 29, 2019 at 07:56:05PM -0700, Eduardo Valentin wrote:
> > When registering a hwmon device with HWMON_C_REGISTER_TZ flag
> > in place, the hwmon subsystem will attempt to register the device
> > also with the thermal subsystem. When the of-thermal registration
> > fails, __hwmon_device_register jumps to ida_remove, leaving
> > the locally allocated hwdev pointer.
> >
> > This patch fixes the leak by jumping to a new label that
> > will first unregister hdev and then fall into the kfree of hwdev
> > to finally remove the idas and propagate the error code.
> >
>
> Hah, actually this is wrong. hwdev is freed indirectly with the
> device_unregister() call. See commit 74e3512731bd ("hwmon: (core)
> Fix double-free in __hwmon_device_register()").
heh.. I see it now. Well, it is not a straight catch though.
>
> It may make sense to add a respective comment to the code, though.
>
I agree. Or a simple comment saying "dont worry about freeing hwdev
because hwmon_dev_release() takes care of it".
Are you patching it ?
> Guenter
>
> > Cc: Jean Delvare
> > Cc: Guenter Roeck
> > Cc: linux-hw...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Eduardo Valentin
> > ---
> > V1->V2: removed the device_unregister() before jumping
> > into the new label, as suggested in the first review round.
> >
> > drivers/hwmon/hwmon.c | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/hwmon/hwmon.c b/drivers/hwmon/hwmon.c
> > index 429784edd5ff..620f05fc412a 100644
> > --- a/drivers/hwmon/hwmon.c
> > +++ b/drivers/hwmon/hwmon.c
> > @@ -652,10 +652,8 @@ __hwmon_device_register(struct device *dev, const char
> > *name, void *drvdata,
> > if (info[i]->config[j] & HWMON_T_INPUT) {
> > err = hwmon_thermal_add_sensor(dev,
> > hwdev, j);
> > - if (err) {
> > - device_unregister(hdev);
> > - goto ida_remove;
> > - }
> > + if (err)
> > + goto device_unregister;
> > }
> > }
> > }
> > @@ -663,6 +661,8 @@ __hwmon_device_register(struct device *dev, const char
> > *name, void *drvdata,
> >
> > return hdev;
> >
> > +device_unregister:
> > + device_unregister(hdev);
> > free_hwmon:
> > kfree(hwdev);
> > ida_remove:
--
All the best,
Eduardo Valentin
Re: [PATCH][next] drivers: thermal: tsens: remove redundant u32 comparison with less than zero
hey Colin,
On Fri, May 31, 2019 at 11:57:08AM +0100, Colin King wrote:
> From: Colin Ian King
>
> The u32 variable hw_id is unsigned and cannot be less than zero so
> the comparison with less than zero is always false and hence is redundant
> and can be removed.
>
> Addresses-Coverity: ("Unsigned compared against 0")
> Signed-off-by: Colin Ian King
Thanks for the patch but the commit that introduced this has been
reverted. I pushed an update on my -next branch to silence this in the
linux-next tree too.
> ---
> drivers/thermal/qcom/tsens-common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/qcom/tsens-common.c
> b/drivers/thermal/qcom/tsens-common.c
> index 928e8e81ba69..f4419f45025d 100644
> --- a/drivers/thermal/qcom/tsens-common.c
> +++ b/drivers/thermal/qcom/tsens-common.c
> @@ -69,7 +69,7 @@ bool is_sensor_enabled(struct tsens_priv *priv, u32 hw_id)
> u32 val;
> int ret;
>
> - if ((hw_id > (priv->num_sensors - 1)) || (hw_id < 0))
> + if (hw_id > (priv->num_sensors - 1))
> return -EINVAL;
> ret = regmap_field_read(priv->rf[SENSOR_EN], );
> if (ret)
Re: [PATCHv7 2/3] i2c: slave-mqueue: add a slave backend to receive and queue messages
On Wed, Jun 05, 2019 at 08:02:11PM +0300, Andy Shevchenko wrote: > On Wed, Jun 5, 2019 at 7:48 PM Eduardo Valentin wrote: > > > > From: Haiyue Wang > > > > Some protocols over I2C are designed for bi-directional transferring > > messages by using I2C Master Write protocol. Like the MCTP (Management > > Component Transport Protocol) and IPMB (Intelligent Platform Management > > Bus), they both require that the userspace can receive messages from > > I2C dirvers under slave mode. > > > > This new slave mqueue backend is used to receive and queue messages, it > > will exposes these messages to userspace by sysfs bin file. > > > > Note: DT interface and a couple of minor fixes here and there > > by Eduardo, so I kept the original authorship here. > > FWIW, > Reviewed-by: Andy Shevchenko Great! > > though I prefer simple dropping of of_match_ptr(), and by the way, > #include is superfluous and may be changed to > mod_devicetable.h. > > Leave above to Wolfram to judge. Wolfram, any objections on this series? > > > Cc: Rob Herring > > Cc: Mark Rutland > > Cc: Wolfram Sang > > Cc: Andy Shevchenko > > Cc: linux-...@vger.kernel.org > > Cc: devicet...@vger.kernel.org > > Cc: linux-kernel@vger.kernel.org > > Signed-off-by: Haiyue Wang > > Signed-off-by: Eduardo Valentin > > --- > > > > From V6 -> V7: > > - fixed compile warm when CONFIG_OF=n by wrapping of table into ifdef > > - minor changes: kobj_to_dev(), moved BUILD_BUG_ON() to start of function, > > and flagged DT table sentinel in a more strict way. > > - Also added a MODULE_DEVICE_TABLE() for the of table. > > > > Documentation/i2c/slave-mqueue-backend.rst | 124 > > MAINTAINERS| 8 + > > drivers/i2c/Kconfig| 25 +++ > > drivers/i2c/Makefile | 1 + > > drivers/i2c/i2c-slave-mqueue.c | 215 + > > 5 files changed, 373 insertions(+) > > create mode 100644 Documentation/i2c/slave-mqueue-backend.rst > > create mode 100644 drivers/i2c/i2c-slave-mqueue.c > > > > diff --git a/Documentation/i2c/slave-mqueue-backend.rst > > b/Documentation/i2c/slave-mqueue-backend.rst > > new file mode 100644 > > index ..376dff998fa3 > > --- /dev/null > > +++ b/Documentation/i2c/slave-mqueue-backend.rst > > @@ -0,0 +1,124 @@ > > +.. SPDX-License-Identifier: GPL-2.0 > > + > > += > > +Linux I2C slave message queue backend > > += > > + > > +:Author: Haiyue Wang > > + > > +Some protocols over I2C/SMBus are designed for bi-directional transferring > > +messages by using I2C Master Write protocol. This requires that both sides > > +of the communication have slave addresses. > > + > > +Like MCTP (Management Component Transport Protocol) and IPMB (Intelligent > > +Platform Management Bus), they both require that the userspace can receive > > +messages from i2c drivers under slave mode. > > + > > +This I2C slave mqueue (message queue) backend is used to receive and queue > > +messages from the remote i2c intelligent device; and it will add the target > > +slave address (with R/W# bit is always 0) into the message at the first > > byte, > > +so that userspace can use this byte to dispatch the messages into different > > +handling modules. Also, like IPMB, the address byte is in its message > > format, > > +it needs it to do checksum. > > + > > +For messages are time related, so this backend will flush the oldest > > message > > +to queue the newest one. > > + > > +Link > > + > > +`Intelligent Platform Management Bus > > +Communications Protocol Specification > > +<https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmp-spec-v1.0.pdf>`_ > > + > > +`Management Component Transport Protocol (MCTP) > > +SMBus/I2C Transport Binding Specification > > +<https://www.dmtf.org/sites/default/files/standards/documents/DSP0237_1.1.0.pdf>`_ > > + > > +How to use > > +-- > > +For example, the I2C5 bus has slave address 0x10, the below command will > > create > > +the related message queue interface: > > + > > +echo slave-mqueue 0x1010 > /sys/bus/i2c/devices/i2c-5/new_device > > + > > +Then you can dump the messages like this: > > + > > +hexdump -C /sys/bus/i2c/devices/5-1010/slave-mqueue
[PATCHv7 3/3] Documentation: ABI: Add i2c-slave-mqueue sysfs documentation
Document the slave-mqueue sysfs attribute used by the i2c-slave-mqueue driver. Cc: Rob Herring Cc: Mark Rutland Cc: Wolfram Sang Cc: linux-...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- changes from V6 to V7: - none .../ABI/testing/sysfs-bus-i2c-devices-slave-mqueue | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-slave-mqueue diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-slave-mqueue b/Documentation/ABI/testing/sysfs-bus-i2c-devices-slave-mqueue new file mode 100644 index ..28318108ce85 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-slave-mqueue @@ -0,0 +1,10 @@ +What: /sys/bus/i2c/devices/*/slave-mqueue +Date: May 2019 +KernelVersion: 5.2 +Contact: Eduardo Valentin +Description: + Reading to this file will return exactly one message, + when available, of the i2c-slave-mqueue device attached + to that bus. Userspace can also poll on this file to + get notified when new messages are available. +Users: i2c-slave-mqueue driver -- 2.21.0
[PATCHv7 2/3] i2c: slave-mqueue: add a slave backend to receive and queue messages
From: Haiyue Wang
Some protocols over I2C are designed for bi-directional transferring
messages by using I2C Master Write protocol. Like the MCTP (Management
Component Transport Protocol) and IPMB (Intelligent Platform Management
Bus), they both require that the userspace can receive messages from
I2C dirvers under slave mode.
This new slave mqueue backend is used to receive and queue messages, it
will exposes these messages to userspace by sysfs bin file.
Note: DT interface and a couple of minor fixes here and there
by Eduardo, so I kept the original authorship here.
Cc: Rob Herring
Cc: Mark Rutland
Cc: Wolfram Sang
Cc: Andy Shevchenko
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Haiyue Wang
Signed-off-by: Eduardo Valentin
---
>From V6 -> V7:
- fixed compile warm when CONFIG_OF=n by wrapping of table into ifdef
- minor changes: kobj_to_dev(), moved BUILD_BUG_ON() to start of function,
and flagged DT table sentinel in a more strict way.
- Also added a MODULE_DEVICE_TABLE() for the of table.
Documentation/i2c/slave-mqueue-backend.rst | 124
MAINTAINERS| 8 +
drivers/i2c/Kconfig| 25 +++
drivers/i2c/Makefile | 1 +
drivers/i2c/i2c-slave-mqueue.c | 215 +
5 files changed, 373 insertions(+)
create mode 100644 Documentation/i2c/slave-mqueue-backend.rst
create mode 100644 drivers/i2c/i2c-slave-mqueue.c
diff --git a/Documentation/i2c/slave-mqueue-backend.rst
b/Documentation/i2c/slave-mqueue-backend.rst
new file mode 100644
index ..376dff998fa3
--- /dev/null
+++ b/Documentation/i2c/slave-mqueue-backend.rst
@@ -0,0 +1,124 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+Linux I2C slave message queue backend
+=
+
+:Author: Haiyue Wang
+
+Some protocols over I2C/SMBus are designed for bi-directional transferring
+messages by using I2C Master Write protocol. This requires that both sides
+of the communication have slave addresses.
+
+Like MCTP (Management Component Transport Protocol) and IPMB (Intelligent
+Platform Management Bus), they both require that the userspace can receive
+messages from i2c drivers under slave mode.
+
+This I2C slave mqueue (message queue) backend is used to receive and queue
+messages from the remote i2c intelligent device; and it will add the target
+slave address (with R/W# bit is always 0) into the message at the first byte,
+so that userspace can use this byte to dispatch the messages into different
+handling modules. Also, like IPMB, the address byte is in its message format,
+it needs it to do checksum.
+
+For messages are time related, so this backend will flush the oldest message
+to queue the newest one.
+
+Link
+
+`Intelligent Platform Management Bus
+Communications Protocol Specification
+<https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmp-spec-v1.0.pdf>`_
+
+`Management Component Transport Protocol (MCTP)
+SMBus/I2C Transport Binding Specification
+<https://www.dmtf.org/sites/default/files/standards/documents/DSP0237_1.1.0.pdf>`_
+
+How to use
+--
+For example, the I2C5 bus has slave address 0x10, the below command will create
+the related message queue interface:
+
+echo slave-mqueue 0x1010 > /sys/bus/i2c/devices/i2c-5/new_device
+
+Then you can dump the messages like this:
+
+hexdump -C /sys/bus/i2c/devices/5-1010/slave-mqueue
+
+Code Example
+
+*Note: call 'lseek' before 'read', this is a requirement from kernfs' design.*
+
+::
+
+ #include
+ #include
+ #include
+ #include
+ #include
+ #include
+ #include
+
+ int main(int argc, char *argv[])
+ {
+ int i, r;
+ struct pollfd pfd;
+ struct timespec ts;
+ unsigned char data[256];
+
+ pfd.fd = open(argv[1], O_RDONLY | O_NONBLOCK);
+ if (pfd.fd < 0)
+ return -1;
+
+ pfd.events = POLLPRI;
+
+ while (1) {
+ r = poll(, 1, 5000);
+
+ if (r < 0)
+ break;
+
+ if (r == 0 || !(pfd.revents & POLLPRI))
+ continue;
+
+ lseek(pfd.fd, 0, SEEK_SET);
+ r = read(pfd.fd, data, sizeof(data));
+ if (r <= 0)
+ continue;
+
+ clock_gettime(CLOCK_MONOTONIC, );
+ printf("[%ld.%.9ld] :", ts.tv_sec, ts.tv_nsec);
+ for (i = 0; i < r; i++)
+ printf(" %02x", data[i]);
+ printf("\n");
+ }
+
+ close(pfd.fd);
+
+ return 0;
+ }
+
+Result
+--
+*./a.out "/sys/bus/i2c/devices/5-1010/slave-mqueue"*
+
+::
+
+ [10183.232500449] : 20 18 c8 2c 78 0
[PATCHv7 1/3] dt-bindings: i2c: document bindings for i2c-slave-mqueue
Document the i2c-slave-mqueue binding by adding
descriptor, required properties, and example.
Cc: Rob Herring
Cc: Mark Rutland
Cc: Wolfram Sang
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
Changes from V6 to V7:
- none
.../bindings/i2c/i2c-slave-mqueue.txt | 34 +++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-slave-mqueue.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-slave-mqueue.txt
b/Documentation/devicetree/bindings/i2c/i2c-slave-mqueue.txt
new file mode 100644
index ..eb1881a4fc0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-slave-mqueue.txt
@@ -0,0 +1,34 @@
+===
+Device Tree for I2C slave message queue backend
+===
+
+Some protocols over I2C/SMBus are designed for bi-directional transferring
+messages by using I2C Master Write protocol. This requires that both sides
+of the communication have slave addresses.
+
+This I2C slave mqueue (message queue) is used to receive and queue
+messages from the remote i2c intelligent device; and it will add the target
+slave address (with R/W# bit is always 0) into the message at the first byte.
+
+Links
+
+`Intelligent Platform Management Bus
+Communications Protocol Specification
+<https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmp-spec-v1.0.pdf>`_
+
+`Management Component Transport Protocol (MCTP)
+SMBus/I2C Transport Binding Specification
+<https://www.dmtf.org/sites/default/files/standards/documents/DSP0237_1.1.0.pdf>`_
+
+Required Properties:
+- compatible : should be "i2c-slave-mqueue"
+- reg : slave address
+
+Example:
+
+i2c {
+ slave_mqueue: i2c-slave-mqueue {
+ compatible = "i2c-slave-mqueue";
+ reg = <0x10>;
+ };
+};
--
2.21.0
Re: [PATCH v2 1/2] dt-bindings: interrupt-controller: Amazon's Annapurna Labs FIC
On Wed, Jun 05, 2019 at 01:52:00PM +0300, Talel Shenhar wrote:
> Document Amazon's Annapurna Labs Fabric Interrupt Controller SoC binding.
>
> Signed-off-by: Talel Shenhar
> ---
> .../interrupt-controller/amazon,al-fic.txt | 22
> ++
> 1 file changed, 22 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.txt
>
> diff --git
> a/Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.txt
> b/Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.txt
> new file mode 100644
> index 000..a2f31a6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.txt
> @@ -0,0 +1,22 @@
> +Amazon's Annapurna Labs Fabric Interrupt Controller
> +
> +Required properties:
> +
> +- compatible: should be "amazon,al-fic"
> +- reg: physical base address and size of the registers
> +- interrupt-controller: identifies the node as an interrupt controller
> +- #interrupt-cells: must be 2.
It would be great if you describe what the 2 numbers must represent here..
> +- interrupt-parent: specifies the parent interrupt controller.
> +- interrupts: describes which input line in the interrupt parent, this
> + fic's output is connected to.
> +
> +Example:
> +
> +amazon_fic: amazon_fic {
> + compatible = "amazon,al-fic";
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + reg = <0x0 0xfd8a8500 0x0 0x1000>;
> + interrupt-parent = <>;
> + interrupts = ;
> +};
> --
> 2.7.4
>
--
All the best,
Eduardo Valentin
Re: [PATCH 2/3] i2c: slave-mqueue: add a slave backend to receive and queue messages
On Wed, Jun 05, 2019 at 06:20:37PM +0300, Andy Shevchenko wrote:
> On Wed, Jun 5, 2019 at 5:32 PM Eduardo Valentin wrote:
> > On Wed, Jun 05, 2019 at 11:25:39AM +0300, Andy Shevchenko wrote:
> > > On Wed, Jun 5, 2019 at 6:30 AM Eduardo Valentin wrote:
>
> > Well, yes, but the point is you would be switching from a simple AND (&)
> > operation
> > to a division...
> >
> > I am keeping the power of 2 dep so that we can keep this with a simple &.
>
> Works for me.
>
> > > > > > + .of_match_table =
> > > > > > of_match_ptr(i2c_slave_mqueue_of_match),
> > > > >
> > > > > Wouldn't compiler warn you due to unused data?
> > > > > Perhaps drop of_match_ptr() for good...
> > > >
> > > > Not sure what you meant here. I dont see any compiler warning.
> > > > Also, of_match_ptr seams to be well spread in the kernel.
> > >
> > > If this will be compiled with CONFIG_OF=n...
> >
> > I see.. I obviously did not test with that config..
> >
> > > Though I didn't check all dependencies to see if it even possible. In
> > > any case of_match_ptr() is redundant in both cases here.
> > > Either you need to protect i2c_slave_mqueue_of_match with #ifdef
> > > CONFIG_OF, or drop the macro use.
> >
> > I will wrap it into CONFIG_OF..
>
> Would be this expected to work in the case of CONFIG_OF=n?
> If no, why to introduce ugly #ifdef:s and additional macros?
I do hate those too...
> Wouldn't be better to have
> depends on OF || COMPILE_TEST
Well, technically, the original author had a case for using this
without CONFIG_OF. That is why I did not force here to be a strong
dependency on CONFIG_OF. So, I guess in this case the driver will
work properly in both cases if we:
+#ifdef CONFIG_OF
+static const struct of_device_id i2c_slave_mqueue_of_match[] = {
+ {
+ .compatible = "i2c-slave-mqueue",
+ },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, i2c_slave_mqueue_of_match);
+#endif
+
+static struct i2c_driver i2c_slave_mqueue_driver = {
+ .driver = {
+ .name = "i2c-slave-mqueue",
+ .of_match_table = of_match_ptr(i2c_slave_mqueue_of_match),
+ },
+ .probe = i2c_slave_mqueue_probe,
+ .remove = i2c_slave_mqueue_remove,
+ .id_table = i2c_slave_mqueue_id,
+};
The above is a well stablish pattern across the drivers.
> ?
>
> --
> With Best Regards,
> Andy Shevchenko
--
All the best,
Eduardo Valentin
Re: [PATCH 2/3] i2c: slave-mqueue: add a slave backend to receive and queue messages
On Wed, Jun 05, 2019 at 11:25:39AM +0300, Andy Shevchenko wrote:
> On Wed, Jun 5, 2019 at 6:30 AM Eduardo Valentin wrote:
> >
> > Hey Andry,
> >
> > Long time no seeing :-)
>
> True!
>
>
> > > > +#define MQ_MSGBUF_SIZE CONFIG_I2C_SLAVE_MQUEUE_MESSAGE_SIZE
> > > > +#define MQ_QUEUE_SIZE CONFIG_I2C_SLAVE_MQUEUE_QUEUE_SIZE
> > >
> > > > +#define MQ_QUEUE_NEXT(x) (((x) + 1) & (MQ_QUEUE_SIZE - 1))
> > >
> > > Also possible ((x + 1) % ..._SIZE)
> >
> > Right.. but I suppose the original idea is to avoid divisions on the
> > hotpath.
> >
> > So, I am actually fine with the limitation of only using power of 2.
>
> The original code implies that anyway, so, my proposal doesn't
> restrict it any farther.
Well, yes, but the point is you would be switching from a simple AND (&)
operation
to a division...
I am keeping the power of 2 dep so that we can keep this with a simple &.
> > > > + {
> > > > + .compatible = "i2c-slave-mqueue",
> > > > + },
> > >
> > > > + { },
> > >
> > > No need for comma here.
> >
> > It does not hurt to have it either :-)
>
> It's just a protection against some weird cases of adding entries
> behind the terminator.
Fair..
>
> > > > + .of_match_table = of_match_ptr(i2c_slave_mqueue_of_match),
> > >
> > > Wouldn't compiler warn you due to unused data?
> > > Perhaps drop of_match_ptr() for good...
> >
> >
> > Not sure what you meant here. I dont see any compiler warning.
> > Also, of_match_ptr seams to be well spread in the kernel.
>
> If this will be compiled with CONFIG_OF=n...
I see.. I obviously did not test with that config..
> Though I didn't check all dependencies to see if it even possible. In
> any case of_match_ptr() is redundant in both cases here.
> Either you need to protect i2c_slave_mqueue_of_match with #ifdef
> CONFIG_OF, or drop the macro use.
I will wrap it into CONFIG_OF..
>
> P.S. Taking into account the last part, I would wait for v7 with that
> fixed followed by fixing other nits.
I agree, the warn on CONFIG_OF=n is enough to spin out an extra version.
I will include the other nits too.
>
> --
> With Best Regards,
> Andy Shevchenko
--
All the best,
Eduardo Valentin
Re: [PATCH 2/3] i2c: slave-mqueue: add a slave backend to receive and queue messages
Hey Andry,
Long time no seeing :-)
On Tue, Jun 04, 2019 at 08:16:11PM +0300, Andy Shevchenko wrote:
> On Thu, May 30, 2019 at 09:33:46PM -0700, Eduardo Valentin wrote:
> > From: Haiyue Wang
> >
> > Some protocols over I2C are designed for bi-directional transferring
> > messages by using I2C Master Write protocol. Like the MCTP (Management
> > Component Transport Protocol) and IPMB (Intelligent Platform Management
> > Bus), they both require that the userspace can receive messages from
> > I2C dirvers under slave mode.
> >
> > This new slave mqueue backend is used to receive and queue messages, it
> > will exposes these messages to userspace by sysfs bin file.
> >
> > Note: DT interface and a couple of minor fixes here and there
> > by Eduardo, so I kept the original authorship here.
>
> > +#define MQ_MSGBUF_SIZE CONFIG_I2C_SLAVE_MQUEUE_MESSAGE_SIZE
> > +#define MQ_QUEUE_SIZE CONFIG_I2C_SLAVE_MQUEUE_QUEUE_SIZE
>
> > +#define MQ_QUEUE_NEXT(x) (((x) + 1) & (MQ_QUEUE_SIZE - 1))
>
> Also possible ((x + 1) % ..._SIZE)
Right.. but I suppose the original idea is to avoid divisions on the hotpath.
So, I am actually fine with the limitation of only using power of 2.
>
> > + mq = dev_get_drvdata(container_of(kobj, struct device, kobj));
>
> kobj_to_dev()
Well, yeah, I guess this is a nit, but I can add that in case of a real need
for a v7.
>
> > +static int i2c_slave_mqueue_probe(struct i2c_client *client,
> > + const struct i2c_device_id *id)
> > +{
> > + struct device *dev = >dev;
> > + struct mq_queue *mq;
> > + int ret, i;
> > + void *buf;
> > +
> > + mq = devm_kzalloc(dev, sizeof(*mq), GFP_KERNEL);
> > + if (!mq)
> > + return -ENOMEM;
> > +
>
> > + BUILD_BUG_ON(!is_power_of_2(MQ_QUEUE_SIZE));
>
> Perhaps start function with this kind of assertions?
>
same here, in case I see a huge ask for a v7, I can move this up.
> > +
> > + buf = devm_kmalloc_array(dev, MQ_QUEUE_SIZE, MQ_MSGBUF_SIZE,
> > +GFP_KERNEL);
> > + if (!buf)
> > + return -ENOMEM;
> > +
> > + for (i = 0; i < MQ_QUEUE_SIZE; i++)
> > + mq->queue[i].buf = buf + i * MQ_MSGBUF_SIZE;
>
>
> Just wondering if kfifo API can bring an advantage here?
>
Well, then again, I suppose the idea is simplify here, not if we need to go
kfifo as the Protocol on top of this is perfectly fine with the current
discipline of just having a simple drop of older messages.
> > + return 0;
> > +}
>
> > +static const struct of_device_id i2c_slave_mqueue_of_match[] = {
> > + {
> > + .compatible = "i2c-slave-mqueue",
> > + },
>
> > + { },
>
> No need for comma here.
It does not hurt to have it either :-)
>
> > +};
>
> > +
> > +static struct i2c_driver i2c_slave_mqueue_driver = {
> > + .driver = {
> > + .name = "i2c-slave-mqueue",
>
> > + .of_match_table = of_match_ptr(i2c_slave_mqueue_of_match),
>
> Wouldn't compiler warn you due to unused data?
> Perhaps drop of_match_ptr() for good...
Not sure what you meant here. I dont see any compiler warning.
Also, of_match_ptr seams to be well spread in the kernel.
>
> > + },
> > + .probe = i2c_slave_mqueue_probe,
> > + .remove = i2c_slave_mqueue_remove,
> > + .id_table = i2c_slave_mqueue_id,
> > +};
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
--
All the best,
Eduardo Valentin
[GIT PULL] Thermal-SoC management fixes for v5.2-rc3
Please consider the following thermal soc changes for v5.2-rc3. This is really a single revert, detected to cause issues on the tsens driver. The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07: Linux 5.2-rc2 (2019-05-26 16:49:19 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes for you to fetch changes up to ca657468a0d4bcc25445f6636485a19a525267bd: Revert "drivers: thermal: tsens: Add new operation to check if a sensor is enabled" (2019-05-28 19:30:33 -0700) Specifics: - Revert tsens change that is reported to cause issues. BR, -------- Eduardo Valentin (1): Revert "drivers: thermal: tsens: Add new operation to check if a sensor is enabled" drivers/thermal/qcom/tsens-common.c | 14 -- drivers/thermal/qcom/tsens-v0_1.c | 1 - drivers/thermal/qcom/tsens-v2.c | 1 - drivers/thermal/qcom/tsens.c| 5 - drivers/thermal/qcom/tsens.h| 1 - 5 files changed, 22 deletions(-)
[PATCH 1/3] dt-bindings: i2c: document bindings for i2c-slave-mqueue
Document the i2c-slave-mqueue binding by adding
descriptor, required properties, and example.
Cc: Rob Herring
Cc: Mark Rutland
Cc: Wolfram Sang
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin
---
.../bindings/i2c/i2c-slave-mqueue.txt | 34 +++
1 file changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-slave-mqueue.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-slave-mqueue.txt
b/Documentation/devicetree/bindings/i2c/i2c-slave-mqueue.txt
new file mode 100644
index ..eb1881a4fc0e
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-slave-mqueue.txt
@@ -0,0 +1,34 @@
+===
+Device Tree for I2C slave message queue backend
+===
+
+Some protocols over I2C/SMBus are designed for bi-directional transferring
+messages by using I2C Master Write protocol. This requires that both sides
+of the communication have slave addresses.
+
+This I2C slave mqueue (message queue) is used to receive and queue
+messages from the remote i2c intelligent device; and it will add the target
+slave address (with R/W# bit is always 0) into the message at the first byte.
+
+Links
+
+`Intelligent Platform Management Bus
+Communications Protocol Specification
+<https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmp-spec-v1.0.pdf>`_
+
+`Management Component Transport Protocol (MCTP)
+SMBus/I2C Transport Binding Specification
+<https://www.dmtf.org/sites/default/files/standards/documents/DSP0237_1.1.0.pdf>`_
+
+Required Properties:
+- compatible : should be "i2c-slave-mqueue"
+- reg : slave address
+
+Example:
+
+i2c {
+ slave_mqueue: i2c-slave-mqueue {
+ compatible = "i2c-slave-mqueue";
+ reg = <0x10>;
+ };
+};
--
2.21.0
[PATCH 2/3] i2c: slave-mqueue: add a slave backend to receive and queue messages
From: Haiyue Wang
Some protocols over I2C are designed for bi-directional transferring
messages by using I2C Master Write protocol. Like the MCTP (Management
Component Transport Protocol) and IPMB (Intelligent Platform Management
Bus), they both require that the userspace can receive messages from
I2C dirvers under slave mode.
This new slave mqueue backend is used to receive and queue messages, it
will exposes these messages to userspace by sysfs bin file.
Note: DT interface and a couple of minor fixes here and there
by Eduardo, so I kept the original authorship here.
Cc: Rob Herring
Cc: Mark Rutland
Cc: Wolfram Sang
Cc: linux-...@vger.kernel.org
Cc: devicet...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Haiyue Wang
Signed-off-by: Eduardo Valentin
---
Documentation/i2c/slave-mqueue-backend.rst | 124
MAINTAINERS| 8 +
drivers/i2c/Kconfig| 25 +++
drivers/i2c/Makefile | 1 +
drivers/i2c/i2c-slave-mqueue.c | 211 +
5 files changed, 369 insertions(+)
create mode 100644 Documentation/i2c/slave-mqueue-backend.rst
create mode 100644 drivers/i2c/i2c-slave-mqueue.c
diff --git a/Documentation/i2c/slave-mqueue-backend.rst
b/Documentation/i2c/slave-mqueue-backend.rst
new file mode 100644
index ..376dff998fa3
--- /dev/null
+++ b/Documentation/i2c/slave-mqueue-backend.rst
@@ -0,0 +1,124 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+Linux I2C slave message queue backend
+=
+
+:Author: Haiyue Wang
+
+Some protocols over I2C/SMBus are designed for bi-directional transferring
+messages by using I2C Master Write protocol. This requires that both sides
+of the communication have slave addresses.
+
+Like MCTP (Management Component Transport Protocol) and IPMB (Intelligent
+Platform Management Bus), they both require that the userspace can receive
+messages from i2c drivers under slave mode.
+
+This I2C slave mqueue (message queue) backend is used to receive and queue
+messages from the remote i2c intelligent device; and it will add the target
+slave address (with R/W# bit is always 0) into the message at the first byte,
+so that userspace can use this byte to dispatch the messages into different
+handling modules. Also, like IPMB, the address byte is in its message format,
+it needs it to do checksum.
+
+For messages are time related, so this backend will flush the oldest message
+to queue the newest one.
+
+Link
+
+`Intelligent Platform Management Bus
+Communications Protocol Specification
+<https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmp-spec-v1.0.pdf>`_
+
+`Management Component Transport Protocol (MCTP)
+SMBus/I2C Transport Binding Specification
+<https://www.dmtf.org/sites/default/files/standards/documents/DSP0237_1.1.0.pdf>`_
+
+How to use
+--
+For example, the I2C5 bus has slave address 0x10, the below command will create
+the related message queue interface:
+
+echo slave-mqueue 0x1010 > /sys/bus/i2c/devices/i2c-5/new_device
+
+Then you can dump the messages like this:
+
+hexdump -C /sys/bus/i2c/devices/5-1010/slave-mqueue
+
+Code Example
+
+*Note: call 'lseek' before 'read', this is a requirement from kernfs' design.*
+
+::
+
+ #include
+ #include
+ #include
+ #include
+ #include
+ #include
+ #include
+
+ int main(int argc, char *argv[])
+ {
+ int i, r;
+ struct pollfd pfd;
+ struct timespec ts;
+ unsigned char data[256];
+
+ pfd.fd = open(argv[1], O_RDONLY | O_NONBLOCK);
+ if (pfd.fd < 0)
+ return -1;
+
+ pfd.events = POLLPRI;
+
+ while (1) {
+ r = poll(, 1, 5000);
+
+ if (r < 0)
+ break;
+
+ if (r == 0 || !(pfd.revents & POLLPRI))
+ continue;
+
+ lseek(pfd.fd, 0, SEEK_SET);
+ r = read(pfd.fd, data, sizeof(data));
+ if (r <= 0)
+ continue;
+
+ clock_gettime(CLOCK_MONOTONIC, );
+ printf("[%ld.%.9ld] :", ts.tv_sec, ts.tv_nsec);
+ for (i = 0; i < r; i++)
+ printf(" %02x", data[i]);
+ printf("\n");
+ }
+
+ close(pfd.fd);
+
+ return 0;
+ }
+
+Result
+--
+*./a.out "/sys/bus/i2c/devices/5-1010/slave-mqueue"*
+
+::
+
+ [10183.232500449] : 20 18 c8 2c 78 01 5b
+ [10183.479358348] : 20 18 c8 2c 78 01 5b
+ [10183.726556812] : 20 18 c8 2c 78 01 5b
+ [10183.972605863] : 20 18 c8 2c 78 01 5b
+ [10184.220124772] : 20 18 c8 2c 78 01 5b
+ [10184.467764166] : 20 18 c8 2c 78 01 5b
+ [10193.233421784] : 20 18 c8 2c 7c 01 57
+ [10193.480273
[PATCH 3/3] Documentation: ABI: Add i2c-slave-mqueue sysfs documentation
Document the slave-mqueue sysfs attribute used by the i2c-slave-mqueue driver. Cc: Rob Herring Cc: Mark Rutland Cc: Wolfram Sang Cc: linux-...@vger.kernel.org Cc: devicet...@vger.kernel.org Cc: linux-kernel@vger.kernel.org Signed-off-by: Eduardo Valentin --- .../ABI/testing/sysfs-bus-i2c-devices-slave-mqueue | 10 ++ 1 file changed, 10 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-slave-mqueue diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-slave-mqueue b/Documentation/ABI/testing/sysfs-bus-i2c-devices-slave-mqueue new file mode 100644 index ..28318108ce85 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-slave-mqueue @@ -0,0 +1,10 @@ +What: /sys/bus/i2c/devices/*/slave-mqueue +Date: May 2019 +KernelVersion: 5.2 +Contact: Eduardo Valentin +Description: + Reading to this file will return exactly one message, + when available, of the i2c-slave-mqueue device attached + to that bus. Userspace can also poll on this file to + get notified when new messages are available. +Users: i2c-slave-mqueue driver -- 2.21.0
[PATCH 0/3] introduce i2c-slave-mqueue
Wolfram, I am sending you the i2c-slave-mqueue driver. Apparently Haiyue had to move on to another project and does not have cycles to continue with the comments on this driver after some time waiting for feedback, that is essentially why I took over. Here is a small changelog from V5 to V6: - Added DT support for probing via Device Tree - Docummented DT bindings - Documented sysfs ABI - Small fixes on wording and Kconfig entries. Haiyue's V5: https://lkml.org/lkml/2018/4/23/835 BR, Eduardo Valentin (2): dt-bindings: i2c: document bindings for i2c-slave-mqueue Documentation: ABI: Add i2c-slave-mqueue sysfs documentation Haiyue Wang (1): i2c: slave-mqueue: add a slave backend to receive and queue messages .../sysfs-bus-i2c-devices-slave-mqueue| 10 + .../bindings/i2c/i2c-slave-mqueue.txt | 34 +++ Documentation/i2c/slave-mqueue-backend.rst| 124 ++ MAINTAINERS | 8 + drivers/i2c/Kconfig | 25 +++ drivers/i2c/Makefile | 1 + drivers/i2c/i2c-slave-mqueue.c| 211 ++ 7 files changed, 413 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-bus-i2c-devices-slave-mqueue create mode 100644 Documentation/devicetree/bindings/i2c/i2c-slave-mqueue.txt create mode 100644 Documentation/i2c/slave-mqueue-backend.rst create mode 100644 drivers/i2c/i2c-slave-mqueue.c -- 2.21.0
Re: [PATCH v3 3/8] drivers/soc: xdma: Add user interface
ags))
> + mask |= EPOLLIN | EPOLLRDNORM;
> + }
> +
> + if (req & (EPOLLOUT | EPOLLWRNORM)) {
> + if (test_bit(XDMA_IN_PRG, >flags))
> + poll_wait(file, >wait, wait);
> +
> + if (!test_bit(XDMA_IN_PRG, >flags))
> + mask |= EPOLLOUT | EPOLLWRNORM;
> + }
> +
> + return mask;
> +}
> +
> +static void aspeed_xdma_vma_close(struct vm_area_struct *vma)
> +{
> + struct aspeed_xdma_client *client = vma->vm_private_data;
> +
> + gen_pool_free(client->ctx->vga_pool, (unsigned long)client->virt,
> + client->size);
> +
> + client->virt = NULL;
> + client->phys = 0;
> + client->size = 0;
> +}
> +
> +static const struct vm_operations_struct aspeed_xdma_vm_ops = {
> + .close =aspeed_xdma_vma_close,
> +};
> +
> +static int aspeed_xdma_mmap(struct file *file, struct vm_area_struct *vma)
> +{
> + int rc;
> + struct aspeed_xdma_client *client = file->private_data;
> + struct aspeed_xdma *ctx = client->ctx;
> +
> + /* restrict file to one mapping */
> + if (client->size)
> + return -ENOMEM;
> +
> + client->size = vma->vm_end - vma->vm_start;
> + client->virt = gen_pool_dma_alloc(ctx->vga_pool, client->size,
> + >phys);
> + if (!client->virt) {
> + client->phys = 0;
> + client->size = 0;
> + return -ENOMEM;
> + }
> +
> + vma->vm_pgoff = (client->phys - ctx->vga_phys) >> PAGE_SHIFT;
> + vma->vm_ops = _xdma_vm_ops;
> + vma->vm_private_data = client;
> +
> + rc = dma_mmap_coherent(ctx->dev, vma, ctx->vga_virt, ctx->vga_dma,
> +ctx->vga_size);
> + if (rc) {
> + gen_pool_free(ctx->vga_pool, (unsigned long)client->virt,
> + client->size);
> +
> + client->virt = NULL;
> + client->phys = 0;
> + client->size = 0;
> + return rc;
> + }
> +
> + dev_dbg(ctx->dev, "mmap: v[%08lx] to p[%08x], s[%08x]\n",
> + vma->vm_start, (u32)client->phys, client->size);
> +
> + return 0;
> +}
> +
> +static int aspeed_xdma_open(struct inode *inode, struct file *file)
> +{
> + struct miscdevice *misc = file->private_data;
> + struct aspeed_xdma *ctx = container_of(misc, struct aspeed_xdma, misc);
> + struct aspeed_xdma_client *client = kzalloc(sizeof(*client),
> + GFP_KERNEL);
> +
> + if (!client)
> + return -ENOMEM;
> +
> + client->ctx = ctx;
> + file->private_data = client;
> + return 0;
> +}
> +
> +static int aspeed_xdma_release(struct inode *inode, struct file *file)
> +{
> + struct aspeed_xdma_client *client = file->private_data;
> +
> + if (client->ctx->current_client == client)
> + client->ctx->current_client = NULL;
> +
> + kfree(client);
> + return 0;
> +}
> +
> +static const struct file_operations aspeed_xdma_fops = {
> + .owner = THIS_MODULE,
> + .write = aspeed_xdma_write,
> + .poll = aspeed_xdma_poll,
> + .mmap = aspeed_xdma_mmap,
> + .open = aspeed_xdma_open,
> + .release= aspeed_xdma_release,
> +};
> +
> static int aspeed_xdma_init_mem(struct aspeed_xdma *ctx)
> {
> int rc;
> @@ -431,6 +612,8 @@ static int aspeed_xdma_probe(struct platform_device *pdev)
> ctx->dev = dev;
> platform_set_drvdata(pdev, ctx);
> init_waitqueue_head(>wait);
> + mutex_init(>list_lock);
> + mutex_init(>start_lock);
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> ctx->base = devm_ioremap_resource(dev, res);
> @@ -482,6 +665,23 @@ static int aspeed_xdma_probe(struct platform_device
> *pdev)
>
> aspeed_xdma_init_eng(ctx);
>
> + ctx->misc.minor = MISC_DYNAMIC_MINOR;
> + ctx->misc.fops = _xdma_fops;
> + ctx->misc.name = "xdma";
tiny bit here, should this be named more specific ? something like
"aspeed_xdma" ?
> + ctx->misc.parent = dev;
> + rc = misc_register(>misc);
> + if (rc) {
> + dev_err(dev, "Unable to register xdma miscdevice.\n");
> +
> + gen_pool_free(ctx->vga_pool, (unsigned long)ctx->cmdq_vga_virt,
> + XDMA_CMDQ_SIZE);
> + dma_free_coherent(dev, ctx->vga_size, ctx->vga_virt,
> + ctx->vga_dma);
> + dma_release_declared_memory(dev);
> + reset_control_assert(ctx->reset);
> + return rc;
> + }
> +
> return 0;
> }
>
> @@ -489,6 +689,7 @@ static int aspeed_xdma_remove(struct platform_device
> *pdev)
> {
> struct aspeed_xdma *ctx = platform_get_drvdata(pdev);
>
> + misc_deregister(>misc);
> gen_pool_free(ctx->vga_pool, (unsigned long)ctx->cmdq_vga_virt,
> XDMA_CMDQ_SIZE);
> dma_free_coherent(ctx->dev, ctx->vga_size, ctx->vga_virt,
> --
> 1.8.3.1
>
--
All the best,
Eduardo Valentin
Re: [PATCH v3 5/8] drivers/soc: xdma: Add PCI device configuration sysfs
stead?
> + return count;
> +}
> +static DEVICE_ATTR(pcidev, 0644, aspeed_xdma_show_pcidev,
> +aspeed_xdma_store_pcidev);
> +
> static int aspeed_xdma_probe(struct platform_device *pdev)
> {
> int irq;
> int rc;
> + u32 conf;
> struct resource *res;
> struct device *dev = >dev;
> struct aspeed_xdma *ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
> @@ -657,7 +743,14 @@ static int aspeed_xdma_probe(struct platform_device
> *pdev)
>
> msleep(10);
>
> - rc = aspeed_xdma_init_mem(ctx);
> + if (aspeed_xdma_pcidev_to_conf(ctx, _pcidev, )) {
> + conf = aspeed_xdma_vga_pcie_conf;
> + strcpy(ctx->pcidev, "vga");
> + } else {
> + strcpy(ctx->pcidev, _pcidev);
> + }
same...
> +
> + rc = aspeed_xdma_init_mem(ctx, conf);
> if (rc) {
> reset_control_assert(ctx->reset);
> return rc;
> @@ -682,6 +775,8 @@ static int aspeed_xdma_probe(struct platform_device *pdev)
> return rc;
> }
>
> + device_create_file(dev, _attr_pcidev);
Should we consider using one of the default attributes here instead of
device_create_file()?
http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/
BTW, was this ABI documented? Is this the same file documented in patch 2?
> +
> return 0;
> }
>
> @@ -689,6 +784,8 @@ static int aspeed_xdma_remove(struct platform_device
> *pdev)
> {
> struct aspeed_xdma *ctx = platform_get_drvdata(pdev);
>
> + device_remove_file(ctx->dev, _attr_pcidev);
> +
> misc_deregister(>misc);
> gen_pool_free(ctx->vga_pool, (unsigned long)ctx->cmdq_vga_virt,
> XDMA_CMDQ_SIZE);
> --
> 1.8.3.1
>
--
All the best,
Eduardo Valentin
Re: [PATCH v3 2/8] drivers/soc: Add Aspeed XDMA Engine Driver
tx->dev = dev;
> + platform_set_drvdata(pdev, ctx);
> + init_waitqueue_head(>wait);
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + ctx->base = devm_ioremap_resource(dev, res);
> + if (IS_ERR(ctx->base)) {
> + dev_err(dev, "Unable to ioremap registers.\n");
> + return PTR_ERR(ctx->base);
> + }
> +
> + irq = irq_of_parse_and_map(dev->of_node, 0);
> + if (!irq) {
> + dev_err(dev, "Unable to find IRQ.\n");
> + return -ENODEV;
> + }
> +
> + rc = devm_request_irq(dev, irq, aspeed_xdma_irq, IRQF_SHARED,
> + DEVICE_NAME, ctx);
> + if (rc < 0) {
> + dev_err(dev, "Unable to request IRQ %d.\n", irq);
> + return rc;
> + }
> +
> + ctx->scu = syscon_regmap_lookup_by_compatible("aspeed,ast2500-scu");
> + if (IS_ERR(ctx->scu)) {
> + dev_err(ctx->dev, "Unable to grab SCU regs.\n");
> + return PTR_ERR(ctx->scu);
> + }
> +
> + ctx->reset = devm_reset_control_get_exclusive(dev, NULL);
> + if (IS_ERR(ctx->reset)) {
> + dev_err(dev, "Unable to request reset control.\n");
> + return PTR_ERR(ctx->reset);
> + }
> +
> + ctx->vga_pool = devm_gen_pool_create(dev, ilog2(PAGE_SIZE), -1, NULL);
> + if (!ctx->vga_pool) {
> + dev_err(dev, "Unable to setup genalloc pool.\n");
> + return -ENOMEM;
> + }
> +
> + reset_control_deassert(ctx->reset);
> +
> + msleep(10);
Why 10ms again? :-)
> +
> + rc = aspeed_xdma_init_mem(ctx);
> + if (rc) {
> + reset_control_assert(ctx->reset);
> + return rc;
> + }
> +
> + aspeed_xdma_init_eng(ctx);
> +
> + return 0;
> +}
> +
> +static int aspeed_xdma_remove(struct platform_device *pdev)
> +{
> + struct aspeed_xdma *ctx = platform_get_drvdata(pdev);
> +
> + gen_pool_free(ctx->vga_pool, (unsigned long)ctx->cmdq_vga_virt,
> + XDMA_CMDQ_SIZE);
> + dma_free_coherent(ctx->dev, ctx->vga_size, ctx->vga_virt,
> + ctx->vga_dma);
> + dma_release_declared_memory(ctx->dev);
> + reset_control_assert(ctx->reset);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id aspeed_xdma_match[] = {
> + { .compatible = "aspeed,ast2500-xdma" },
> + { },
> +};
> +
> +static struct platform_driver aspeed_xdma_driver = {
> + .probe = aspeed_xdma_probe,
> + .remove = aspeed_xdma_remove,
> + .driver = {
> + .name = DEVICE_NAME,
> + .of_match_table = aspeed_xdma_match,
> + },
> +};
> +
> +module_platform_driver(aspeed_xdma_driver);
> +
> +MODULE_AUTHOR("Eddie James");
> +MODULE_DESCRIPTION("Aspeed XDMA Engine Driver");
> +MODULE_LICENSE("GPL v2");
> diff --git a/include/uapi/linux/aspeed-xdma.h
> b/include/uapi/linux/aspeed-xdma.h
> new file mode 100644
> index 000..998459e
> --- /dev/null
> +++ b/include/uapi/linux/aspeed-xdma.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/* Copyright IBM Corp 2019 */
> +
> +#ifndef _UAPI_LINUX_ASPEED_XDMA_H_
> +#define _UAPI_LINUX_ASPEED_XDMA_H_
> +
> +#include
> +
> +/*
> + * aspeed_xdma_op
> + *
> + * host_addr: the DMA address on the host side, typically configured by PCI
> + *subsystem
> + *
> + * len: the size of the transfer in bytes; it should be a multiple of 16
> bytes
> + *
> + * upstream: boolean indicating the direction of the DMA operation; upstream
> + * means a transfer from the BMC to the host
> + */
> +struct aspeed_xdma_op {
> + __u64 host_addr;
> + __u32 len;
> + __u32 upstream;
> +};
> +
> +#endif /* _UAPI_LINUX_ASPEED_XDMA_H_ */
> --
> 1.8.3.1
>
--
All the best,
Eduardo Valentin
Re: [PATCH i2c/slave-mqueue v5] i2c: slave-mqueue: add a slave backend to receive and queue messages
On Wed, May 29, 2019 at 08:46:48PM -0700, Eduardo Valentin wrote:
> On Tue, Apr 24, 2018 at 01:06:32AM +0800, Haiyue Wang wrote:
> > Some protocols over I2C are designed for bi-directional transferring
> > messages by using I2C Master Write protocol. Like the MCTP (Management
> > Component Transport Protocol) and IPMB (Intelligent Platform Management
> > Bus), they both require that the userspace can receive messages from
> > I2C dirvers under slave mode.
> >
> > This new slave mqueue backend is used to receive and queue messages, it
> > will exposes these messages to userspace by sysfs bin file.
> >
> > Signed-off-by: Haiyue Wang
> > ---
> > v4 -> v5:
> > - Typo: bellowing -> the below
> >
> > v3 -> v4:
> > - Drop the small message after receiving I2C STOP.
> >
> > v2 -> v3:
> > - Just remove the ';' after the end '}' of i2c_slave_mqueue_probe().
> >
> > v1 -> v2:
> > - Change MQ_MSGBUF_SIZE and MQ_QUEUE_SIZE to be configurable by Kconfig.
> > ---
> > Documentation/i2c/slave-mqueue-backend.rst | 125 ++
> > drivers/i2c/Kconfig| 25
> > drivers/i2c/Makefile | 1 +
> > drivers/i2c/i2c-slave-mqueue.c | 203
> > +
> > 4 files changed, 354 insertions(+)
> > create mode 100644 Documentation/i2c/slave-mqueue-backend.rst
> > create mode 100644 drivers/i2c/i2c-slave-mqueue.c
> >
> > diff --git a/Documentation/i2c/slave-mqueue-backend.rst
> > b/Documentation/i2c/slave-mqueue-backend.rst
> > new file mode 100644
> > index 000..3966cf0
> > --- /dev/null
> > +++ b/Documentation/i2c/slave-mqueue-backend.rst
> > @@ -0,0 +1,125 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
> > +=
> > +Linux I2C slave message queue backend
> > +=
> > +
> > +:Author: Haiyue Wang
> > +
> > +Some protocols over I2C/SMBus are designed for bi-directional transferring
> > +messages by using I2C Master Write protocol. This requires that both sides
> > +of the communication have slave addresses.
> > +
> > +Like MCTP (Management Component Transport Protocol) and IPMB (Intelligent
> > +Platform Management Bus), they both require that the userspace can receive
> > +messages from i2c dirvers under slave mode.
>
> s/dirvers/drivers/g
>
> > +
> > +This I2C slave mqueue (message queue) backend is used to receive and queue
> > +messages from the remote i2c intelligent device; and it will add the target
> > +slave address (with R/W# bit is always 0) into the message at the first
> > byte,
> > +so that userspace can use this byte to dispatch the messages into different
> > +handling modules. Also, like IPMB, the address byte is in its message
> > format,
> > +it needs it to do checksum.
> > +
> > +For messages are time related, so this backend will flush the oldest
> > message
> > +to queue the newest one.
> > +
> > +Link
> > +
> > +`Intelligent Platform Management Bus
> > +Communications Protocol Specification
> > +<https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmp-spec-v1.0.pdf>`_
> > +
> > +`Management Component Transport Protocol (MCTP)
> > +SMBus/I2C Transport Binding Specification
> > +<https://www.dmtf.org/sites/default/files/standards/documents/DSP0237_1.1.0.pdf>`_
> > +
> > +How to use
> > +--
> > +For example, the I2C5 bus has slave address 0x10, the below command will
> > create
> > +the related message queue interface:
> > +
> > +echo slave-mqueue 0x1010 > /sys/bus/i2c/devices/i2c-5/new_device
> > +
> > +Then you can dump the messages like this:
> > +
> > +hexdump -C /sys/bus/i2c/devices/5-1010/slave-mqueue
> > +
> > +Code Example
> > +
> > +*Note: call 'lseek' before 'read', this is a requirement from kernfs'
> > design.*
> > +
> > +::
> > +
> > + #include
> > + #include
> > + #include
> > + #include
> > + #include
> > + #include
> > + #include
> > +
> > + int main(int argc, char *argv[])
> > + {
> > + int i, r;
> > + struct pollfd pfd;
> > + struct timespec ts;
> > + unsigned char data[256];
> > +
> > + pfd.fd = open(argv[1], O_RDONLY | O_NONBLOCK);
> > + if
Re: [PATCH i2c/slave-mqueue v5] i2c: slave-mqueue: add a slave backend to receive and queue messages
;< 1;
> + break;
> +
> + case I2C_SLAVE_WRITE_RECEIVED:
> + if (msg->len < MQ_MSGBUF_SIZE) {
> + msg->buf[msg->len++] = *val;
> + } else {
> + dev_err(>dev, "message is truncated!\n");
> + mq->truncated = 1;
> + ret = -EINVAL;
> + }
> + break;
> +
> + case I2C_SLAVE_STOP:
> + if (unlikely(mq->truncated || msg->len < 2))
> + break;
> +
> + spin_lock(>lock);
> + mq->in = MQ_QUEUE_NEXT(mq->in);
> + mq->curr = >queue[mq->in];
> + mq->curr->len = 0;
> +
> + /* Flush the oldest message */
> + if (mq->out == mq->in)
> + mq->out = MQ_QUEUE_NEXT(mq->out);
> + spin_unlock(>lock);
> +
> + kernfs_notify(mq->kn);
> + break;
> +
> + default:
> + *val = 0xFF;
> + break;
> + }
> +
> + return ret;
> +}
> +
> +static ssize_t i2c_slave_mqueue_bin_read(struct file *filp,
> + struct kobject *kobj,
> + struct bin_attribute *attr,
> + char *buf, loff_t pos, size_t count)
> +{
> + struct mq_queue *mq;
> + struct mq_msg *msg;
> + unsigned long flags;
> + bool more = false;
> + ssize_t ret = 0;
> +
> + mq = dev_get_drvdata(container_of(kobj, struct device, kobj));
> +
> + spin_lock_irqsave(>lock, flags);
> + if (mq->out != mq->in) {
> + msg = >queue[mq->out];
> +
> + if (msg->len <= count) {
> + ret = msg->len;
> + memcpy(buf, msg->buf, ret);
> + } else {
> + ret = -EOVERFLOW; /* Drop this HUGE one. */
> + }
> +
> + mq->out = MQ_QUEUE_NEXT(mq->out);
> + if (mq->out != mq->in)
> + more = true;
> + }
> + spin_unlock_irqrestore(>lock, flags);
> +
> + if (more)
> + kernfs_notify(mq->kn);
> +
> + return ret;
> +}
> +
> +static int i2c_slave_mqueue_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct device *dev = >dev;
> + struct mq_queue *mq;
> + int ret, i;
> + void *buf;
> +
> + mq = devm_kzalloc(dev, sizeof(*mq), GFP_KERNEL);
> + if (!mq)
> + return -ENOMEM;
> +
> + BUILD_BUG_ON(!is_power_of_2(MQ_QUEUE_SIZE));
> +
> + buf = devm_kmalloc_array(dev, MQ_QUEUE_SIZE, MQ_MSGBUF_SIZE,
> + GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + for (i = 0; i < MQ_QUEUE_SIZE; i++)
> + mq->queue[i].buf = buf + i * MQ_MSGBUF_SIZE;
> +
> + i2c_set_clientdata(client, mq);
> +
> + spin_lock_init(>lock);
> + mq->curr = >queue[0];
> +
> + sysfs_bin_attr_init(>bin);
> + mq->bin.attr.name = "slave-mqueue";
> + mq->bin.attr.mode = 0400;
> + mq->bin.read = i2c_slave_mqueue_bin_read;
> + mq->bin.size = MQ_MSGBUF_SIZE * MQ_QUEUE_SIZE;
> +
> + ret = sysfs_create_bin_file(>kobj, >bin);
> + if (ret)
> + return ret;
> +
> + mq->kn = kernfs_find_and_get(dev->kobj.sd, mq->bin.attr.name);
> + if (!mq->kn) {
> + sysfs_remove_bin_file(>kobj, >bin);
> + return -EFAULT;
> + }
> +
> + ret = i2c_slave_register(client, i2c_slave_mqueue_callback);
> + if (ret) {
> + kernfs_put(mq->kn);
> + sysfs_remove_bin_file(>kobj, >bin);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int i2c_slave_mqueue_remove(struct i2c_client *client)
> +{
> + struct mq_queue *mq = i2c_get_clientdata(client);
> +
> + i2c_slave_unregister(client);
> +
> + kernfs_put(mq->kn);
> + sysfs_remove_bin_file(>dev.kobj, >bin);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id i2c_slave_mqueue_id[] = {
> + { "slave-mqueue", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, i2c_slave_mqueue_id);
> +
Can we have this driver supporting device tree based probing?
> +static struct i2c_driver i2c_slave_mqueue_driver = {
> + .driver = {
> + .name = "i2c-slave-mqueue",
> + },
> + .probe = i2c_slave_mqueue_probe,
> + .remove = i2c_slave_mqueue_remove,
> + .id_table = i2c_slave_mqueue_id,
> +};
> +module_i2c_driver(i2c_slave_mqueue_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Haiyue Wang ");
> +MODULE_DESCRIPTION("I2C slave mode for receiving and queuing messages");
> --
> 2.7.4
>
--
All the best,
Eduardo Valentin
Re: [PATCH i2c/slave-mqueue v5] i2c: slave-mqueue: add a slave backend to receive and queue messages
On Thu, May 30, 2019 at 09:33:34AM +0800, Wang, Haiyue wrote:
>
> 在 2019-05-30 07:11, Eduardo Valentin 写道:
> >>>>>>+
> >>>>>>+ case I2C_SLAVE_WRITE_RECEIVED:
> >>>>>>+ if (msg->len < MQ_MSGBUF_SIZE) {
> >>>>>>+ msg->buf[msg->len++] = *val;
> >>>>>Do we need to lock the accesses to msg->buf? how about to msg->len?
> >>>this code goes access and modify data here, e.g. msg->len and msg->buf.
> >>>
> >>>On this case (I2C_SLAVE_WRITE_RECEIVED), this code wont protect access.
> >>>
> >>>This can cause concurrence issues if you receive an IRQ when the user
> >>>is on your bin_read().
> >>User will not touch 'msg = mq->curr;', just touch 'msg =
> >>>queue[mq->out];'
> >What happens if mq->curr == mq->queue[mq->out]?
> >
> 1. The Read will check.
>
> + spin_lock_irqsave(>lock, flags);
> + if (mq->out != mq->in) {
> + msg = >queue[mq->out];
>
> 2. Flush the oldeast message. ^_^
>
> + case I2C_SLAVE_STOP:
> + if (unlikely(mq->truncated || msg->len < 2))
> + break;
> +
> + spin_lock(>lock);
> + mq->in = MQ_QUEUE_NEXT(mq->in);
> + mq->curr = >queue[mq->in];
> + mq->curr->len = 0;
> +
> + /* Flush the oldest message */
> + if (mq->out == mq->in)
> + mq->out = MQ_QUEUE_NEXT(mq->out);
Yeah, I see. We keep on dropping messages (old ones) when the queue is full...
> + spin_unlock(>lock);
>
--
All the best,
Eduardo Valentin
Re: [PATCH i2c/slave-mqueue v5] i2c: slave-mqueue: add a slave backend to receive and queue messages
mq->truncated = 0;
> +
> + msg->len = 1;
> + msg->buf[0] = client->addr << 1;
> + break;
> +
> + case I2C_SLAVE_WRITE_RECEIVED:
> + if (msg->len < MQ_MSGBUF_SIZE) {
> + msg->buf[msg->len++] = *val;
> + } else {
> + dev_err(>dev, "message is truncated!\n");
> + mq->truncated = 1;
> + ret = -EINVAL;
> + }
> + break;
> +
> + case I2C_SLAVE_STOP:
> + if (unlikely(mq->truncated || msg->len < 2))
> + break;
> +
> + spin_lock(>lock);
> + mq->in = MQ_QUEUE_NEXT(mq->in);
> + mq->curr = >queue[mq->in];
> + mq->curr->len = 0;
> +
> + /* Flush the oldest message */
> + if (mq->out == mq->in)
> + mq->out = MQ_QUEUE_NEXT(mq->out);
> + spin_unlock(>lock);
> +
> + kernfs_notify(mq->kn);
> + break;
> +
> + default:
> + *val = 0xFF;
> + break;
> + }
> +
> + return ret;
> +}
> +
> +static ssize_t i2c_slave_mqueue_bin_read(struct file *filp,
> + struct kobject *kobj,
> + struct bin_attribute *attr,
> + char *buf, loff_t pos, size_t count)
> +{
> + struct mq_queue *mq;
> + struct mq_msg *msg;
> + unsigned long flags;
> + bool more = false;
> + ssize_t ret = 0;
> +
> + mq = dev_get_drvdata(container_of(kobj, struct device, kobj));
> +
> + spin_lock_irqsave(>lock, flags);
> + if (mq->out != mq->in) {
> + msg = >queue[mq->out];
> +
> + if (msg->len <= count) {
> + ret = msg->len;
> + memcpy(buf, msg->buf, ret);
> + } else {
> + ret = -EOVERFLOW; /* Drop this HUGE one. */
> + }
> +
> + mq->out = MQ_QUEUE_NEXT(mq->out);
> + if (mq->out != mq->in)
> + more = true;
> + }
> + spin_unlock_irqrestore(>lock, flags);
> +
> + if (more)
> + kernfs_notify(mq->kn);
> +
> + return ret;
> +}
> +
> +static int i2c_slave_mqueue_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct device *dev = >dev;
> + struct mq_queue *mq;
> + int ret, i;
> + void *buf;
> +
> + mq = devm_kzalloc(dev, sizeof(*mq), GFP_KERNEL);
> + if (!mq)
> + return -ENOMEM;
> +
> + BUILD_BUG_ON(!is_power_of_2(MQ_QUEUE_SIZE));
> +
> + buf = devm_kmalloc_array(dev, MQ_QUEUE_SIZE, MQ_MSGBUF_SIZE,
> + GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + for (i = 0; i < MQ_QUEUE_SIZE; i++)
> + mq->queue[i].buf = buf + i * MQ_MSGBUF_SIZE;
> +
> + i2c_set_clientdata(client, mq);
> +
> + spin_lock_init(>lock);
> + mq->curr = >queue[0];
> +
> + sysfs_bin_attr_init(>bin);
> + mq->bin.attr.name = "slave-mqueue";
> + mq->bin.attr.mode = 0400;
> + mq->bin.read = i2c_slave_mqueue_bin_read;
> + mq->bin.size = MQ_MSGBUF_SIZE * MQ_QUEUE_SIZE;
> +
> + ret = sysfs_create_bin_file(>kobj, >bin);
> + if (ret)
> + return ret;
> +
> + mq->kn = kernfs_find_and_get(dev->kobj.sd, mq->bin.attr.name);
> + if (!mq->kn) {
> + sysfs_remove_bin_file(>kobj, >bin);
> + return -EFAULT;
> + }
> +
> + ret = i2c_slave_register(client, i2c_slave_mqueue_callback);
> + if (ret) {
> + kernfs_put(mq->kn);
> + sysfs_remove_bin_file(>kobj, >bin);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int i2c_slave_mqueue_remove(struct i2c_client *client)
> +{
> + struct mq_queue *mq = i2c_get_clientdata(client);
> +
> + i2c_slave_unregister(client);
> +
> + kernfs_put(mq->kn);
> + sysfs_remove_bin_file(>dev.kobj, >bin);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id i2c_slave_mqueue_id[] = {
> + { "slave-mqueue", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, i2c_slave_mqueue_id);
Also, can we have device tree support for this driver?
> +
> +static struct i2c_driver i2c_slave_mqueue_driver = {
> + .driver = {
> + .name = "i2c-slave-mqueue",
> + },
> + .probe = i2c_slave_mqueue_probe,
> + .remove = i2c_slave_mqueue_remove,
> + .id_table = i2c_slave_mqueue_id,
> +};
> +module_i2c_driver(i2c_slave_mqueue_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Haiyue Wang ");
> +MODULE_DESCRIPTION("I2C slave mode for receiving and queuing messages");
> --
> 2.7.4
>
--
All the best,
Eduardo Valentin
Re: [PATCH i2c/slave-mqueue v5] i2c: slave-mqueue: add a slave backend to receive and queue messages
Hello, On Sat, May 25, 2019 at 01:10:46PM +0800, Wang, Haiyue wrote: > > 在 2019-05-25 01:33, Eduardo Valentin 写道: > >Hey, > > > >On Fri, May 24, 2019 at 10:43:16AM +0800, Wang, Haiyue wrote: > >>Thanks for interest, the design idea is from: > >> > >>https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/i2c-slave-eeprom.c?h=v5.2-rc1 > >> > >>and > >> > >>https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/i2c/slave-interface > >> > >>Then you will get the answer. ;-) > >Well, maybe :-) see further comments inline.. > Please see in line. And how about the test result in your real system ? It > works as expected ? > >>BR, > >> > >>Haiyue > >> > >> > >>在 2019-05-24 06:03, Eduardo Valentin 写道: > >>>Hey Wang, > >>> > >>>On Tue, Apr 24, 2018 at 01:06:32AM +0800, Haiyue Wang wrote: > >>>>Some protocols over I2C are designed for bi-directional transferring > >>>>messages by using I2C Master Write protocol. Like the MCTP (Management > >>>>Component Transport Protocol) and IPMB (Intelligent Platform Management > >>>>Bus), they both require that the userspace can receive messages from > >>>>I2C dirvers under slave mode. > >>>> > >>>>This new slave mqueue backend is used to receive and queue messages, it > >>>>will exposes these messages to userspace by sysfs bin file. > >>>> > >>>>Signed-off-by: Haiyue Wang > >>>>--- > >>>>v4 -> v5: > >>>> - Typo: bellowing -> the below > >>>> > >>>>v3 -> v4: > >>>> - Drop the small message after receiving I2C STOP. > >>>> > >>>>v2 -> v3: > >>>> - Just remove the ';' after the end '}' of i2c_slave_mqueue_probe(). > >>>> > >>>>v1 -> v2: > >>>> - Change MQ_MSGBUF_SIZE and MQ_QUEUE_SIZE to be configurable by Kconfig. > >>>>--- > >>>> Documentation/i2c/slave-mqueue-backend.rst | 125 ++ > >>>> drivers/i2c/Kconfig| 25 > >>>> drivers/i2c/Makefile | 1 + > >>>> drivers/i2c/i2c-slave-mqueue.c | 203 > >>>> + > >>>> 4 files changed, 354 insertions(+) > >>>> create mode 100644 Documentation/i2c/slave-mqueue-backend.rst > >>>> create mode 100644 drivers/i2c/i2c-slave-mqueue.c > >>>> > >>>>diff --git a/Documentation/i2c/slave-mqueue-backend.rst > >>>>b/Documentation/i2c/slave-mqueue-backend.rst > >>>>new file mode 100644 > >>>>index 000..3966cf0 > >>>>--- /dev/null > >>>>+++ b/Documentation/i2c/slave-mqueue-backend.rst > >>>>@@ -0,0 +1,125 @@ > >>>>+.. SPDX-License-Identifier: GPL-2.0 > >>>>+ > >>>>+= > >>>>+Linux I2C slave message queue backend > >>>>+= > >>>>+ > >>>>+:Author: Haiyue Wang > >>>>+ > >>>>+Some protocols over I2C/SMBus are designed for bi-directional > >>>>transferring > >>>>+messages by using I2C Master Write protocol. This requires that both > >>>>sides > >>>>+of the communication have slave addresses. > >>>>+ > >>>>+Like MCTP (Management Component Transport Protocol) and IPMB (Intelligent > >>>>+Platform Management Bus), they both require that the userspace can > >>>>receive > >>>>+messages from i2c dirvers under slave mode. > >>>>+ > >>>>+This I2C slave mqueue (message queue) backend is used to receive and > >>>>queue > >>>>+messages from the remote i2c intelligent device; and it will add the > >>>>target > >>>>+slave address (with R/W# bit is always 0) into the message at the first > >>>>byte, > >>>>+so that userspace can use this byte to dispatch the messages into > >>>>different > >>>>+handling modules. Also, like IPMB, the address byte is in its message > >>>>format, > >>>>+it needs it to do checksum. > >>>>+ > >>>>
Re: [PATCH] thermal/drivers/of: Add a get_temp_id callback function
On Thu, May 23, 2019 at 07:48:56PM -0700, Andrey Smirnov wrote: > On Mon, Apr 29, 2019 at 9:51 AM Daniel Lezcano > wrote: > > > > On 24/04/2019 01:08, Daniel Lezcano wrote: > > > On 23/04/2019 17:44, Eduardo Valentin wrote: > > >> Hello, > > >> > > >> On Tue, Apr 16, 2019 at 07:22:03PM +0200, Daniel Lezcano wrote: > > >>> Currently when we register a sensor, we specify the sensor id and a data > > >>> pointer to be passed when the get_temp function is called. However the > > >>> sensor_id is not passed to the get_temp callback forcing the driver to > > >>> do extra allocation and adding back pointer to find out from the sensor > > >>> information the driver data and then back to the sensor id. > > >>> > > >>> Add a new callback get_temp_id() which will be called if set. It will > > >>> call the get_temp_id() with the sensor id. > > >>> > > >>> That will be more consistent with the registering function. > > >> > > >> I still do not understand why we need to have a get_id callback. > > >> The use cases I have seen so far, which I have been intentionally > > >> rejecting, are > > >> mainly solvable by creating other compatible entries. And really, if you > > >> have, say a bandgap, chip that supports multiple sensors, but on > > >> SoC version A it has 5 sensors, and on SoC version B it has only 4, > > >> or on SoC version C, it has 5 but they are either logially located > > >> in different places (gpu vs iva regions), these are all cases in which > > >> you want a different compatible! > > >> > > >> Do you mind sharing why you need a get sensor id callback? > > > > > > It is not a get sensor id callback, it is a get_temp callback which pass > > > the sensor id. > > > > > > See in the different drivers, it is a common pattern there is a > > > structure for the driver, then a structure for the sensor. When the > > > get_temp is called, the callback needs info from the sensor structure > > > and from the driver structure, so a back pointer to the driver structure > > > is added in the sensor structure. > > Do you mind sending a patch showing how one could convert an existing driver to use this new API? > > Hi Eduardo, > > > > does the explanation clarifies the purpose of this change? > > > > Eduardo, did you ever have a chance to revisit this thread? I would > really like to make some progress on this one to unblock my i.MX8MQ > hwmon series. The problem I have with this patch is that it is an API which resides only in of-thermal. Growing APIs on DT only diverges of-thermal from thermal core and platform drivers. Besides, this patch needs to document the API in Documention/ > > Thanks, > Andrey Smirnov
Re: [PATCH RESEND V13 2/5] thermal: of-thermal: add API for getting sensor ID from DT
On Tue, May 28, 2019 at 02:06:18PM +0800, anson.hu...@nxp.com wrote:
> From: Anson Huang
>
> On some platforms like i.MX8QXP, the thermal driver needs a
> real HW sensor ID from DT thermal zone, the HW sensor ID is
> used to get temperature from SCU firmware, and the virtual
> sensor ID starting from 0 to N is NOT used at all, this patch
> adds new API thermal_zone_of_get_sensor_id() to provide the
> feature of getting sensor ID from DT thermal zone's node.
>
> Signed-off-by: Anson Huang
> ---
> Changes since V12:
> - adjust the second parameter of thermal_zone_of_get_sensor_id() API,
> then caller no need
> to pass the of_phandle_args structure and put the sensor_specs.np
> manually, also putting
> the sensor node device check inside this API to make it easy for
> usage;
What happened to using nxp,resource-id property in your driver?
Why do we need this as an API in of-thermal? What other drivers may
benefit of this?
Regardless, this patch needs to document the new API under
Documentation/
> ---
> drivers/thermal/of-thermal.c | 66
> +---
> include/linux/thermal.h | 10 +++
> 2 files changed, 60 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> index dc5093b..a53792b 100644
> --- a/drivers/thermal/of-thermal.c
> +++ b/drivers/thermal/of-thermal.c
> @@ -449,6 +449,54 @@ thermal_zone_of_add_sensor(struct device_node *zone,
> }
>
> /**
> + * thermal_zone_of_get_sensor_id - get sensor ID from a DT thermal zone
> + * @tz_np: a valid thermal zone device node.
> + * @sensor_np: a sensor node of a valid sensor device.
> + * @id: a sensor ID pointer will be passed back.
> + *
> + * This function will get sensor ID from a given thermal zone node, use
> + * "thermal-sensors" as list name, and get sensor ID from first phandle's
> + * argument.
> + *
> + * Return: 0 on success, proper error code otherwise.
> + */
> +
> +int thermal_zone_of_get_sensor_id(struct device_node *tz_np,
> + struct device_node *sensor_np,
> + u32 *id)
> +{
> + struct of_phandle_args sensor_specs;
> + int ret;
> +
> + ret = of_parse_phandle_with_args(tz_np,
> + "thermal-sensors",
> + "#thermal-sensor-cells",
> + 0,
> + _specs);
> + if (ret)
> + return ret;
> +
> + if (sensor_specs.np != sensor_np) {
> + of_node_put(sensor_specs.np);
> + return -ENODEV;
> + }
> +
> + if (sensor_specs.args_count >= 1) {
> + *id = sensor_specs.args[0];
> + WARN(sensor_specs.args_count > 1,
> + "%pOFn: too many cells in sensor specifier %d\n",
> + sensor_specs.np, sensor_specs.args_count);
> + } else {
> + *id = 0;
> + }
> +
> + of_node_put(sensor_specs.np);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(thermal_zone_of_get_sensor_id);
> +
> +/**
> * thermal_zone_of_sensor_register - registers a sensor to a DT thermal zone
> * @dev: a valid struct device pointer of a sensor device. Must contain
> * a valid .of_node, for the sensor node.
> @@ -499,36 +547,22 @@ thermal_zone_of_sensor_register(struct device *dev, int
> sensor_id, void *data,
> sensor_np = of_node_get(dev->of_node);
>
> for_each_available_child_of_node(np, child) {
> - struct of_phandle_args sensor_specs;
> int ret, id;
>
> /* For now, thermal framework supports only 1 sensor per zone */
> - ret = of_parse_phandle_with_args(child, "thermal-sensors",
> - "#thermal-sensor-cells",
> - 0, _specs);
> + ret = thermal_zone_of_get_sensor_id(child, sensor_np, );
> if (ret)
> continue;
>
> - if (sensor_specs.args_count >= 1) {
> - id = sensor_specs.args[0];
> - WARN(sensor_specs.args_count > 1,
> - "%pOFn: too many cells in sensor specifier %d\n",
> - sensor_specs.np, sensor_specs.args_count);
> - } else {
> - id = 0;
> - }
> -
> - if (sensor_specs.np == sensor_np && id == sensor_id) {
> + if (id == sensor_id) {
> tzd = thermal_zone_of_add_sensor(child, sensor_np,
>data, ops);
> if (!IS_ERR(tzd))
> tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED);
>
> - of_node_put(sensor_specs.np);
> of_node_put(child);
> goto exit;
> }
> -
Re: [PATCH] arm64: dts: ls1028a: Add Thermal Monitor Unit node
On Thu, Apr 25, 2019 at 04:26:40PM +0800, Yuantian Tang wrote:
> The Thermal Monitoring Unit (TMU) monitors and reports the
> temperature from 2 remote temperature measurement sites
> located on ls1028a chip.
> Add TMU dts node to enable this feature.
>
> Signed-off-by: Yuantian Tang
I dont see anything wrong from a thermal standpoint.
Acked-by: Eduardo Valentin
Please get this via your arch tree maintainer to avoid merge conflicts.
> ---
> arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 114
>
> 1 files changed, 114 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> index b045812..a25f5fc 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a.dtsi
> @@ -29,6 +29,7 @@
> clocks = < 1 0>;
> next-level-cache = <>;
> cpu-idle-states = <_PH20>;
> + #cooling-cells = <2>;
> };
>
> cpu1: cpu@1 {
> @@ -39,6 +40,7 @@
> clocks = < 1 0>;
> next-level-cache = <>;
> cpu-idle-states = <_PH20>;
> + #cooling-cells = <2>;
> };
>
> l2: l2-cache {
> @@ -398,6 +400,118 @@
> status = "disabled";
> };
>
> + tmu: tmu@1f0 {
> + compatible = "fsl,qoriq-tmu";
> + reg = <0x0 0x1f8 0x0 0x1>;
> + interrupts = <0 23 0x4>;
> + fsl,tmu-range = <0xb 0xa0026 0x80048 0x70061>;
> + fsl,tmu-calibration = <0x 0x0024
> +0x0001 0x002b
> +0x0002 0x0031
> +0x0003 0x0038
> +0x0004 0x003f
> +0x0005 0x0045
> +0x0006 0x004c
> +0x0007 0x0053
> +0x0008 0x0059
> +0x0009 0x0060
> +0x000a 0x0066
> +0x000b 0x006d
> +
> +0x0001 0x001c
> +0x00010001 0x0024
> +0x00010002 0x002c
> +0x00010003 0x0035
> +0x00010004 0x003d
> +0x00010005 0x0045
> +0x00010006 0x004d
> +0x00010007 0x0045
> +0x00010008 0x005e
> +0x00010009 0x0066
> +0x0001000a 0x006e
> +
> +0x0002 0x0018
> +0x00020001 0x0022
> +0x00020002 0x002d
> +0x00020003 0x0038
> +0x00020004 0x0043
> +0x00020005 0x004d
> +0x00020006 0x0058
> +0x00020007 0x0063
> +0x00020008 0x006e
> +
> +0x0003 0x0010
> +0x00030001 0x001c
> +0x00030002 0x0029
> +0x00030003 0x0036
> +0x00030004 0x0042
> +0x00030005 0x004f
> +0x00030006 0x005b
> +0x00030007 0x0068>;
> + little-endian;
> + #thermal-sensor-cells = <1>;
> + };
> +
> +
Re: [PATCH -next] drivers: thermal: tsens: Change hw_id type to int in is_sensor_enabled
YueHaibing,
On Mon, May 27, 2019 at 09:41:24PM +0800, YueHaibing wrote:
> Sensor hw_id is int type other u32, is_sensor_enabled
> should use int to compare, this fix smatch warning:
>
> drivers/thermal/qcom/tsens-common.c:72
> is_sensor_enabled() warn: unsigned 'hw_id' is never less than zero.
>
> Fixes: 3e6a8fb33084 ("drivers: thermal: tsens: Add new operation to check if
> a sensor is enabled")
Thanks for the patch, but we had to revert this commit which was
causing some issues. So, your patch is not applicable.
> Signed-off-by: YueHaibing
Thank you anyways.
> ---
> drivers/thermal/qcom/tsens-common.c | 2 +-
> drivers/thermal/qcom/tsens.h| 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/qcom/tsens-common.c
> b/drivers/thermal/qcom/tsens-common.c
> index 928e8e81ba69..5df4eed84535 100644
> --- a/drivers/thermal/qcom/tsens-common.c
> +++ b/drivers/thermal/qcom/tsens-common.c
> @@ -64,7 +64,7 @@ void compute_intercept_slope(struct tsens_priv *priv, u32
> *p1,
> }
> }
>
> -bool is_sensor_enabled(struct tsens_priv *priv, u32 hw_id)
> +bool is_sensor_enabled(struct tsens_priv *priv, int hw_id)
> {
> u32 val;
> int ret;
> diff --git a/drivers/thermal/qcom/tsens.h b/drivers/thermal/qcom/tsens.h
> index eefe3844fb4e..15264806f6a8 100644
> --- a/drivers/thermal/qcom/tsens.h
> +++ b/drivers/thermal/qcom/tsens.h
> @@ -315,7 +315,7 @@ void compute_intercept_slope(struct tsens_priv *priv, u32
> *pt1, u32 *pt2, u32 mo
> int init_common(struct tsens_priv *priv);
> int get_temp_tsens_valid(struct tsens_priv *priv, int i, int *temp);
> int get_temp_common(struct tsens_priv *priv, int i, int *temp);
> -bool is_sensor_enabled(struct tsens_priv *priv, u32 hw_id);
> +bool is_sensor_enabled(struct tsens_priv *priv, int hw_id);
>
> /* TSENS target */
> extern const struct tsens_plat_data data_8960;
Re: [PATCH] thermal: tsens: Remove unnecessary comparison of unsigned integer with < 0
Gustavo,
On Mon, May 27, 2019 at 11:08:25AM -0500, Gustavo A. R. Silva wrote:
> There is no need to compare hw_id with < 0 because such comparison
> of an unsigned value is always false.
>
> Fix this by removing such comparison.
Thanks for fixing this. But we had to revert the commit that introduces
this issue. So this patch is no longer applicable.
>
> Addresses-Coverity-ID: 1445440 ("Unsigned compared against 0")
> Fixes: 3e6a8fb33084 ("drivers: thermal: tsens: Add new operation to check if
> a sensor is enabled")
> Signed-off-by: Gustavo A. R. Silva
> ---
> drivers/thermal/qcom/tsens-common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/qcom/tsens-common.c
> b/drivers/thermal/qcom/tsens-common.c
> index 928e8e81ba69..94878ad35464 100644
> --- a/drivers/thermal/qcom/tsens-common.c
> +++ b/drivers/thermal/qcom/tsens-common.c
> @@ -69,7 +69,7 @@ bool is_sensor_enabled(struct tsens_priv *priv, u32 hw_id)
> u32 val;
> int ret;
>
> - if ((hw_id > (priv->num_sensors - 1)) || (hw_id < 0))
> + if (hw_id > priv->num_sensors - 1)
> return -EINVAL;
> ret = regmap_field_read(priv->rf[SENSOR_EN], );
> if (ret)
[PATCH 1/1] Revert "drivers: thermal: tsens: Add new operation to check if a sensor is enabled"
This reverts commit 3e6a8fb3308419129c7a52de6eb42feef5a919a0.
Cc: Andy Gross
Cc: David Brown
Cc: Amit Kucheria
Cc: Zhang Rui
Cc: Daniel Lezcano
Suggested-by: Amit Kucheria
Reported-by: Andy Gross
Signed-off-by: Eduardo Valentin
---
Added this for next -rc, as per request.
drivers/thermal/qcom/tsens-common.c | 14 --
drivers/thermal/qcom/tsens-v0_1.c | 1 -
drivers/thermal/qcom/tsens-v2.c | 1 -
drivers/thermal/qcom/tsens.c| 5 -
drivers/thermal/qcom/tsens.h| 1 -
5 files changed, 22 deletions(-)
diff --git a/drivers/thermal/qcom/tsens-common.c
b/drivers/thermal/qcom/tsens-common.c
index 928e8e8..528df88 100644
--- a/drivers/thermal/qcom/tsens-common.c
+++ b/drivers/thermal/qcom/tsens-common.c
@@ -64,20 +64,6 @@ void compute_intercept_slope(struct tsens_priv *priv, u32
*p1,
}
}
-bool is_sensor_enabled(struct tsens_priv *priv, u32 hw_id)
-{
- u32 val;
- int ret;
-
- if ((hw_id > (priv->num_sensors - 1)) || (hw_id < 0))
- return -EINVAL;
- ret = regmap_field_read(priv->rf[SENSOR_EN], );
- if (ret)
- return ret;
-
- return val & (1 << hw_id);
-}
-
static inline int code_to_degc(u32 adc_code, const struct tsens_sensor *s)
{
int degc, num, den;
diff --git a/drivers/thermal/qcom/tsens-v0_1.c
b/drivers/thermal/qcom/tsens-v0_1.c
index a319283..6f26fad 100644
--- a/drivers/thermal/qcom/tsens-v0_1.c
+++ b/drivers/thermal/qcom/tsens-v0_1.c
@@ -334,7 +334,6 @@ static const struct reg_field
tsens_v0_1_regfields[MAX_REGFIELDS] = {
/* CTRL_OFFSET */
[TSENS_EN] = REG_FIELD(SROT_CTRL_OFF, 0, 0),
[TSENS_SW_RST] = REG_FIELD(SROT_CTRL_OFF, 1, 1),
- [SENSOR_EN]= REG_FIELD(SROT_CTRL_OFF, 3, 13),
/* - TM -- */
/* INTERRUPT ENABLE */
diff --git a/drivers/thermal/qcom/tsens-v2.c b/drivers/thermal/qcom/tsens-v2.c
index 1099069..0a4f2b8 100644
--- a/drivers/thermal/qcom/tsens-v2.c
+++ b/drivers/thermal/qcom/tsens-v2.c
@@ -44,7 +44,6 @@ static const struct reg_field
tsens_v2_regfields[MAX_REGFIELDS] = {
/* CTRL_OFF */
[TSENS_EN] = REG_FIELD(SROT_CTRL_OFF,0, 0),
[TSENS_SW_RST] = REG_FIELD(SROT_CTRL_OFF,1, 1),
- [SENSOR_EN]= REG_FIELD(SROT_CTRL_OFF,3, 18),
/* - TM -- */
/* INTERRUPT ENABLE */
diff --git a/drivers/thermal/qcom/tsens.c b/drivers/thermal/qcom/tsens.c
index 36b0b52..0627d86 100644
--- a/drivers/thermal/qcom/tsens.c
+++ b/drivers/thermal/qcom/tsens.c
@@ -85,11 +85,6 @@ static int tsens_register(struct tsens_priv *priv)
struct thermal_zone_device *tzd;
for (i = 0; i < priv->num_sensors; i++) {
- if (!is_sensor_enabled(priv, priv->sensor[i].hw_id)) {
- dev_err(priv->dev, "sensor %d: disabled\n",
- priv->sensor[i].hw_id);
- continue;
- }
priv->sensor[i].priv = priv;
priv->sensor[i].id = i;
tzd = devm_thermal_zone_of_sensor_register(priv->dev, i,
diff --git a/drivers/thermal/qcom/tsens.h b/drivers/thermal/qcom/tsens.h
index eefe384..2fd9499 100644
--- a/drivers/thermal/qcom/tsens.h
+++ b/drivers/thermal/qcom/tsens.h
@@ -315,7 +315,6 @@ void compute_intercept_slope(struct tsens_priv *priv, u32
*pt1, u32 *pt2, u32 mo
int init_common(struct tsens_priv *priv);
int get_temp_tsens_valid(struct tsens_priv *priv, int i, int *temp);
int get_temp_common(struct tsens_priv *priv, int i, int *temp);
-bool is_sensor_enabled(struct tsens_priv *priv, u32 hw_id);
/* TSENS target */
extern const struct tsens_plat_data data_8960;
--
2.1.4
Re: [PATCH i2c/slave-mqueue v5] i2c: slave-mqueue: add a slave backend to receive and queue messages
Hey, On Fri, May 24, 2019 at 10:43:16AM +0800, Wang, Haiyue wrote: > Thanks for interest, the design idea is from: > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/i2c/i2c-slave-eeprom.c?h=v5.2-rc1 > > and > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/i2c/slave-interface > > Then you will get the answer. ;-) Well, maybe :-) see further comments inline.. > > BR, > > Haiyue > > > 在 2019-05-24 06:03, Eduardo Valentin 写道: > >Hey Wang, > > > >On Tue, Apr 24, 2018 at 01:06:32AM +0800, Haiyue Wang wrote: > >>Some protocols over I2C are designed for bi-directional transferring > >>messages by using I2C Master Write protocol. Like the MCTP (Management > >>Component Transport Protocol) and IPMB (Intelligent Platform Management > >>Bus), they both require that the userspace can receive messages from > >>I2C dirvers under slave mode. > >> > >>This new slave mqueue backend is used to receive and queue messages, it > >>will exposes these messages to userspace by sysfs bin file. > >> > >>Signed-off-by: Haiyue Wang > >>--- > >>v4 -> v5: > >> - Typo: bellowing -> the below > >> > >>v3 -> v4: > >> - Drop the small message after receiving I2C STOP. > >> > >>v2 -> v3: > >> - Just remove the ';' after the end '}' of i2c_slave_mqueue_probe(). > >> > >>v1 -> v2: > >> - Change MQ_MSGBUF_SIZE and MQ_QUEUE_SIZE to be configurable by Kconfig. > >>--- > >> Documentation/i2c/slave-mqueue-backend.rst | 125 ++ > >> drivers/i2c/Kconfig| 25 > >> drivers/i2c/Makefile | 1 + > >> drivers/i2c/i2c-slave-mqueue.c | 203 > >> + > >> 4 files changed, 354 insertions(+) > >> create mode 100644 Documentation/i2c/slave-mqueue-backend.rst > >> create mode 100644 drivers/i2c/i2c-slave-mqueue.c > >> > >>diff --git a/Documentation/i2c/slave-mqueue-backend.rst > >>b/Documentation/i2c/slave-mqueue-backend.rst > >>new file mode 100644 > >>index 000..3966cf0 > >>--- /dev/null > >>+++ b/Documentation/i2c/slave-mqueue-backend.rst > >>@@ -0,0 +1,125 @@ > >>+.. SPDX-License-Identifier: GPL-2.0 > >>+ > >>+= > >>+Linux I2C slave message queue backend > >>+= > >>+ > >>+:Author: Haiyue Wang > >>+ > >>+Some protocols over I2C/SMBus are designed for bi-directional transferring > >>+messages by using I2C Master Write protocol. This requires that both sides > >>+of the communication have slave addresses. > >>+ > >>+Like MCTP (Management Component Transport Protocol) and IPMB (Intelligent > >>+Platform Management Bus), they both require that the userspace can receive > >>+messages from i2c dirvers under slave mode. > >>+ > >>+This I2C slave mqueue (message queue) backend is used to receive and queue > >>+messages from the remote i2c intelligent device; and it will add the target > >>+slave address (with R/W# bit is always 0) into the message at the first > >>byte, > >>+so that userspace can use this byte to dispatch the messages into different > >>+handling modules. Also, like IPMB, the address byte is in its message > >>format, > >>+it needs it to do checksum. > >>+ > >>+For messages are time related, so this backend will flush the oldest > >>message > >>+to queue the newest one. > >>+ > >>+Link > >>+ > >>+`Intelligent Platform Management Bus > >>+Communications Protocol Specification > >>+<https://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/ipmp-spec-v1.0.pdf>`_ > >>+ > >>+`Management Component Transport Protocol (MCTP) > >>+SMBus/I2C Transport Binding Specification > >>+<https://www.dmtf.org/sites/default/files/standards/documents/DSP0237_1.1.0.pdf>`_ > >>+ > >>+How to use > >>+-- > >>+For example, the I2C5 bus has slave address 0x10, the below command will > >>create > >>+the related message queue interface: > >>+ > >>+echo slave-mqueue 0x1010 > /sys/bus/i2c/devices/i2c-5/new_device > >>+ > >>+Then you can dump the messages like this: > >>+ > >>+h
[GIT PULL] Thermal-SoC management fixes for v5.2-rc2
Hello Linus, Please consider the following thermal soc fixes for v5.2-rc2. The following changes since commit 4dde821e4296e156d133b98ddc4c45861935a4fb: Merge tag 'xfs-5.2-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux (2019-05-23 11:18:18 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes for you to fetch changes up to 6a310f8f97bb8bc2e2bb9db6f49a1b8678c8d144: thermal: rcar_gen3_thermal: Update temperature conversion method (2019-05-23 21:58:25 -0700) Specifics: - revert pinctrl settings on rockchip which causes boot failure on rk3288. Proper follow up patch being discussed. Meanwhile reverting gets those booting again. - Minor fixes on rcar and tegra BR, Eduardo Heiko Stuebner (1): Revert "thermal: rockchip: fix up the tsadc pinctrl setting error" Yoshihiro Kaneko (3): thermal: rcar_gen3_thermal: Update value of Tj_1 thermal: rcar_gen3_thermal: Update calculation formula of IRQTEMP thermal: rcar_gen3_thermal: Update temperature conversion method YueHaibing (1): thermal: tegra: Make tegra210_tsensor_thermtrips static drivers/thermal/rcar_gen3_thermal.c | 92 --- drivers/thermal/rockchip_thermal.c| 36 +--- drivers/thermal/tegra/tegra210-soctherm.c | 2 +- 3 files changed, 64 insertions(+), 66 deletions(-)
Re: [GIT PULL] Thermal-SoC management changes for v5.2-rc1
Hello, On Fri, May 24, 2019 at 10:23:09AM +0200, Tomeu Vizoso wrote: > On Fri, 24 May 2019 at 04:40, Eduardo Valentin wrote: > > > > On Thu, May 23, 2019 at 11:46:47AM +0200, Tomeu Vizoso wrote: > > > Hi Eduardo, > > > > > > I saw that for 5.1 [0] you included a kernelci boot report for your > > > tree, but not for 5.2. Have you found anything that should be improved > > > in KernelCI for it to be more useful to maintainers like you? > > > > Honestly, I take a couple of automated testing as input before sending > > my pulls to Linux: (a) my local test, (b) kernel-ci, and (c) 0-day. > > > > There was really no reason specifically for me to not add the report > > from kernelci, except.. > > > > > > [0] > > > https://lore.kernel.org/lkml/20190306161207.GA7365@localhost.localdomain/ > > > > > > I found about this when trying to understand why the boot on the > > > veyron-jaq board has been broken in 5.2-rc1. > > > > > > > I remember a report saying this failed, but from what I could tell from > > the boot log, the board booted and hit terminal. But apparently, after > > all reports from developers, the veyron-jaq boards were in a hang state. > > > > That was hard for me to tell from your logs, as they looked like > > a regular boot that hits terminal. > > > > Maybe I should have looked for a specific output of a command you guys > > run, saying "successful boot" somewhere? > > I think what is easiest and clearest is to consider the bisection > reports as a very strong indication that something is quite wrong in > the branch. OK. I hear you. > > Because if a board stopped booting and the bisection found a > suspicious patch, and reverting it gets the board booting again, then > chances are very high that the patch in question broke that boot. > Yeah, for sure If I had understood the report properly I could have nacked the patch. > Do you think the wording could be improved to make it clearer? Or > maybe some other changes to make all this more useful to maintainers > like you? > Well, from my perspective, I need to judge if the failure on your report is really related to my changes. Many times, specially on build errors, we get failures that are unrelated. Build errors are more straight forward do judge. Similarly, we need to find out if a boot issue is caused by a change on the branch or something existing. On boot issues from kernelci reports, I think the false negatives I have been seeing is lab/boards failing to boot. Those can also be easy to spot as the in most cases the kernel wont even load. For this particular case, as I described before, the kernel would load and hit the shell command line, but in fact it was in hang state IIRC. That is probably why it has not straight forward to understand from the log. Maybe a successful boot message somewhere would have helped to spot the problem (or the opposite of it, something saying, I was expecting to execute a command and board was unresponsive).
Re: [PATCH] dt-bindings: thermal: Make cooling-maps property optional
On Wed, May 15, 2019 at 05:36:47PM +0800, Yuantian Tang wrote: > There may be no cooling device on system, or there are no enough > cooling devices for each thermal zone in multiple thermal zone > cases since cooling devices can't be shared. > So make this property optional to remove such limitations. Yeah, I am not sure that is enough reason to make this property optional. Let me maybe ask you why do you care creating a thermal zone if your control has no actions? Or rather, why bothering setting up a control that has no actuators? > > Signed-off-by: Yuantian Tang > --- > .../devicetree/bindings/thermal/thermal.txt|4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt > b/Documentation/devicetree/bindings/thermal/thermal.txt > index ca14ba9..694e834 100644 > --- a/Documentation/devicetree/bindings/thermal/thermal.txt > +++ b/Documentation/devicetree/bindings/thermal/thermal.txt > @@ -142,11 +142,11 @@ Required properties: > - trips: A sub-node which is a container of only trip point nodes >Type: sub-node required to describe the thermal zone. > > + > +Optional property: > - cooling-maps: A sub-node which is a container of only cooling > device >Type: sub-node map nodes, used to describe the relation between trips > and cooling devices. > - > -Optional property: > - coefficients: An array of integers (one signed cell) > containing >Type: arraycoefficients to compose a linear relation > between >Elem size: one cellthe sensors listed in the thermal-sensors > property. > -- > 1.7.1 >
Re: [GIT PULL] Thermal-SoC management changes for v5.2-rc1
On Thu, May 23, 2019 at 11:46:47AM +0200, Tomeu Vizoso wrote: > Hi Eduardo, > > I saw that for 5.1 [0] you included a kernelci boot report for your > tree, but not for 5.2. Have you found anything that should be improved > in KernelCI for it to be more useful to maintainers like you? Honestly, I take a couple of automated testing as input before sending my pulls to Linux: (a) my local test, (b) kernel-ci, and (c) 0-day. There was really no reason specifically for me to not add the report from kernelci, except.. > > [0] https://lore.kernel.org/lkml/20190306161207.GA7365@localhost.localdomain/ > > I found about this when trying to understand why the boot on the > veyron-jaq board has been broken in 5.2-rc1. > I remember a report saying this failed, but from what I could tell from the boot log, the board booted and hit terminal. But apparently, after all reports from developers, the veyron-jaq boards were in a hang state. That was hard for me to tell from your logs, as they looked like a regular boot that hits terminal. Maybe I should have looked for a specific output of a command you guys run, saying "successful boot" somewhere? > Thanks, > > Tomeu > > On Thu, 16 May 2019 at 06:43, Eduardo Valentin wrote: > > > > Hello Linus, > > > > Please consider the following thermal soc changes for v5.2-rc1. > > > > The following changes since commit 37624b58542fb9f2d9a70e6ea006ef8a5f66c30b: > > > > Linux 5.1-rc7 (2019-04-28 17:04:13 -0700) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal > > linus > > > > for you to fetch changes up to 37bcec5d9f71bd13142a97d2196b293c9ac23823: > > > > hwmon: (pwm-fan) Use devm_thermal_of_cooling_device_register (2019-05-14 > > 07:00:47 -0700) > > > > Specifics: > > - thermal core has a new devm_* API for registering cooling devices, thanks > > to Guenter R. > > I took the entire series, that is why you see changes on drivers/hwmon in > > this pull. > > - rockchip thermal driver gains support to PX30 SoC, thanks to Elaine Z. > > - the generic-adc thermal driver now considers the lookup table DT property > > as optional, > > thanks to Jean-Francois D. > > - Refactoring of tsens thermal driver, thanks to Amit K. > > - Cleanups on cpu cooling driver, thanks to Daniel L. > > - broadcom thermal driver dropped support to ACPI, thanks to Srinath M. > > - tegra thermal driver gains support to OC hw throttle and GPU throtle, > > thanks to Wei Ni. > > - Fixes in several thermal drivers. > > > > BR, > > > > Eduardo Valentin > > > > > > Amit Kucheria (21): > > drivers: thermal: tsens: Document the data structures > > drivers: thermal: tsens: Rename tsens_data > > drivers: thermal: tsens: Rename tsens_device > > drivers: thermal: tsens: Rename variable tmdev > > drivers: thermal: tsens: Use consistent names for variables > > drivers: thermal: tsens: Function prototypes should have argument > > names > > drivers: thermal: tsens: Rename tsens-8916 to prepare to merge with > > tsens-8974 > > drivers: thermal: tsens: Rename constants to prepare to merge with > > tsens-8974 > > drivers: thermal: tsens: Merge tsens-8974 into tsens-v0_1 > > drivers: thermal: tsens: Introduce reg_fields to deal with register > > description > > drivers: thermal: tsens: Save reference to the device pointer and use > > it > > drivers: thermal: tsens: Don't print error message on -EPROBE_DEFER > > drivers: thermal: tsens: Add new operation to check if a sensor is > > enabled > > drivers: thermal: tsens: change data type for sensor IDs > > drivers: thermal: tsens: Introduce IP-specific max_sensor count > > drivers: thermal: tsens: simplify get_temp_tsens_v2 routine > > drivers: thermal: tsens: Move get_temp_tsens_v2 to allow sharing > > drivers: thermal: tsens: Common get_temp() learns to do ADC conversion > > dt: thermal: tsens: Add bindings for qcs404 > > drivers: thermal: tsens: Add generic support for TSENS v1 IP > > drivers: thermal: tsens: Move calibration constants to header file > > > > Andrey Smirnov (1): > > thermal: qoriq: Remove unnecessary DT node is NULL check > > > > Daniel Lezcano (4): > > thermal/drivers/cpu_cooling: Remove pointless test in power2state() > > thermal/drivers/cpu_cooling: F
Re: [GIT PULL] Thermal-SoC management changes for v5.2-rc1
On Thu, May 16, 2019 at 09:55:33AM -0700, Guenter Roeck wrote:
> On 5/16/19 8:07 AM, Linus Torvalds wrote:
> >On Wed, May 15, 2019 at 9:43 PM Eduardo Valentin wrote:
> >>
> >>- thermal core has a new devm_* API for registering cooling devices, thanks
> >>to Guenter R.
> >> I took the entire series, that is why you see changes on drivers/hwmon
> >> in this pull.
> >
> >This clashed badly with commit 6b1ec4789fb1 ("hwmon: (pwm-fan) Add RPM
> >support via external interrupt"), which added a timer to the pwm-fan
> >handling.
> >
> >In particular, that timer now needed the same kind of cleanup changes,
> >and I'd like you guys (particularly Guenther, who was involved on both
> >sides) to double-check my merge.
> >
> >The way I solved it was to just make the pwm_fan_pwm_disable()
> >callback do both the pwm_diable() _and_ the del_timer_sync() on the
> >new timer. That seemed to be the simplest solution that meshed with
> >the new devm cleanup model, but while I build-tested the result, I
> >obviously did no actual use testing. And maybe there's some reason why
> >that approach is flawed.
> >
> >Guenther?
>
> Sorry for the trouble. Looks like I did too much cleanup this time around.
>
> Looks ok. I'll have to send a follow-up patch - we should check the
> return value of devm_add_action_or_reset(). No idea why I didn't do that
> in this series. I'll do that after the commit window closes (and after
> I am back from vacation).
OK... From what I could tell, looked fine from a thermal perspective.
>
> Thanks a lot for sorting this out.
>
> Guenter
Re: [PATCH v3 1/3] thermal: rockchip: fix up the tsadc pinctrl setting error
On Thu, May 23, 2019 at 09:34:37AM +0800, elaine.zhang wrote:
> hi, Heiko & Enric:
>
> 在 2019/5/22 下午8:27, Heiko Stuebner 写道:
> >Hi Enric,
> >
> >Am Montag, 20. Mai 2019, 15:38:32 CEST schrieb Enric Balletbo Serra:
> >>Hi all,
> >>
> >>As pointed by [1] and [2] this commit, that now is upstream, breaks
> >>veyron (rk3288) and kevin (rk3399) boards. The problem is especially
> >>critical for veyron boards because they don't boot anymore.
> >>
> >>I didn't look deep at the problem but I have some concerns about this
> >>patch, see below.
> >>
> >>[1] https://www.spinics.net/lists/linux-rockchip/msg24657.html
> >>[2] https://www.spinics.net/lists/linux-rockchip/msg24735.html
> >>
> >>Missatge de Daniel Lezcano del dia dt., 30
> >>d’abr. 2019 a les 15:39:
> >>>On 30/04/2019 12:09, Elaine Zhang wrote:
> Explicitly use the pinctrl to set/unset the right mode
> instead of relying on the pinctrl init mode.
> And it requires setting the tshut polarity before select pinctrl.
>
> When the temperature sensor mode is set to 0, it will automatically
> reset the board via the Clock-Reset-Unit (CRU) if the over temperature
> threshold is reached. However, when the pinctrl initializes, it does a
> transition to "otp_out" which may lead the SoC restart all the time.
>
> "otp_out" IO may be connected to the RESET circuit on the hardware.
> If the IO is in the wrong state, it will trigger RESET.
> (similar to the effect of pressing the RESET button)
> which will cause the soc to restart all the time.
>
> Signed-off-by: Elaine Zhang
> >>>Reviewed-by: Daniel Lezcano
> >>>
> >>>
> >>>
> ---
> drivers/thermal/rockchip_thermal.c | 36
> +---
> 1 file changed, 33 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/rockchip_thermal.c
> b/drivers/thermal/rockchip_thermal.c
> index 9c7643d62ed7..6dc7fc516abf 100644
> --- a/drivers/thermal/rockchip_thermal.c
> +++ b/drivers/thermal/rockchip_thermal.c
> @@ -172,6 +172,9 @@ struct rockchip_thermal_data {
> int tshut_temp;
> enum tshut_mode tshut_mode;
> enum tshut_polarity tshut_polarity;
> + struct pinctrl *pinctrl;
> + struct pinctrl_state *gpio_state;
> + struct pinctrl_state *otp_state;
> };
>
> /**
> @@ -1242,6 +1245,8 @@ static int rockchip_thermal_probe(struct
> platform_device *pdev)
> return error;
> }
>
> + thermal->chip->control(thermal->regs, false);
> +
> >>That's the line that causes the hang. Commenting this makes the veyron
> >>boot again. Probably this needs to go after chip->initialize?
> >It needs to go after the clk_enable calls.
> >At this point the tsadc may still be unclocked.
>
> The clk is enable by default.
>
>
> The reason for this modification:
>
> The otp Pin polarity setting for tsadc must be set when tsadc is turned off.
>
> The order:
>
> Close the tsadc->Set the otp pin polarity ->Set the pinctrl->initialize the
> tsadc->Open the tsadc
>
>
> As for the problem you mentioned, I guess: The default polarity of otp does
> not match the default state, that is, the otp is triggered by default, and
> then the reset circuit of the hardware takes effect and is restarted all the
> time.
> Modification:
> 1. For this hardware, otp pin default state is modified.
> 2. The mode of using CRU is rockchip,hw-tshut-mode = <0> in DTS;
> /* tshut mode 0:CRU 1:GPIO */
>
> Recommended use method 2. You can try it.
>
> >
> error = clk_prepare_enable(thermal->clk);
> if (error) {
> dev_err(>dev, "failed to enable converter clock:
> %d\n",
> @@ -1267,6 +1272,30 @@ static int rockchip_thermal_probe(struct
> platform_device *pdev)
> thermal->chip->initialize(thermal->grf, thermal->regs,
> thermal->tshut_polarity);
>
> + if (thermal->tshut_mode == TSHUT_MODE_GPIO) {
> + thermal->pinctrl = devm_pinctrl_get(>dev);
> + if (IS_ERR(thermal->pinctrl)) {
> + dev_err(>dev, "failed to find thermal
> pinctrl\n");
> + return PTR_ERR(thermal->pinctrl);
> + }
> +
> + thermal->gpio_state = pinctrl_lookup_state(thermal->pinctrl,
> +"gpio");
> >>Shouldn't this mode be documented properly in the binding first?
> >More importantly, it should be _backwards-compatible_, aka work with
> >old devicetrees without that property and not break thermal handling for
> >them entirely.
> If need _backwards-compatible_, It's can't return
> PTR_ERR(thermal->pinctrl) when get
>
> devm_pinctrl_get failed.
>
> >
> >>The binding [3] talks about init, default and sleep states but *not*
> >>gpio and otpout. The patch series
Re: [PATCH] Revert "thermal: rockchip: fix up the tsadc pinctrl setting error"
On Wed, May 22, 2019 at 08:34:34AM -0700, Doug Anderson wrote:
> Hi,
>
> On Wed, May 22, 2019 at 7:12 AM Heiko Stuebner wrote:
> >
> > This reverts commit 28694e009e512451ead5519dd801f9869acb1f60.
> >
> > The commit causes multiple issues in that:
> > - the added call to ->control does potentially run unclocked
> > causing a hang of the machine
> > - the added pinctrl-states are undocumented in the binding
> > - the added pinctrl-states are not backwards compatible, breaking
> > old devicetrees.
> >
> > Fixes: 28694e009e51 ("thermal: rockchip: fix up the tsadc pinctrl setting
> > error")
> > Signed-off-by: Heiko Stuebner
> > ---
> > drivers/thermal/rockchip_thermal.c | 36 +++---
> > 1 file changed, 3 insertions(+), 33 deletions(-)
>
> In case it helps with the urgency, there are lots of people who have
> all independently needed to identify which commit stopped their boards
> from booting mainline or broke temperature reading. I'm aware of at
> least these reports:
>
> Reported-by: kernelci.org bot
> Reported-by: Enric Balletbo Serra
> Reported-by: Vicente Bergas
> Reported-by: Jack Mitchell
> Reported-by: Douglas Anderson
>
> I can confirm that my board boots again after this revert, thus:
>
> Tested-by: Douglas Anderson
I see. I can collect this revert if that is what unblocks you guys.
Elaine, do you mind checking why these pinctrl changes are causing
boot issues?
Re: [PATCH i2c/slave-mqueue v5] i2c: slave-mqueue: add a slave backend to receive and queue messages
msg->len = 1;
> + msg->buf[0] = client->addr << 1;
> + break;
> +
> + case I2C_SLAVE_WRITE_RECEIVED:
> + if (msg->len < MQ_MSGBUF_SIZE) {
> + msg->buf[msg->len++] = *val;
Do we need to lock the accesses to msg->buf? how about to msg->len?
> + } else {
> + dev_err(>dev, "message is truncated!\n");
> + mq->truncated = 1;
> + ret = -EINVAL;
> + }
> + break;
> +
> + case I2C_SLAVE_STOP:
> + if (unlikely(mq->truncated || msg->len < 2))
> + break;
> +
> + spin_lock(>lock);
> + mq->in = MQ_QUEUE_NEXT(mq->in);
> + mq->curr = >queue[mq->in];
> + mq->curr->len = 0;
> +
> + /* Flush the oldest message */
> + if (mq->out == mq->in)
> + mq->out = MQ_QUEUE_NEXT(mq->out);
> + spin_unlock(>lock);
> +
> + kernfs_notify(mq->kn);
> + break;
> +
> + default:
> + *val = 0xFF;
> + break;
> + }
> +
> + return ret;
> +}
> +
> +static ssize_t i2c_slave_mqueue_bin_read(struct file *filp,
> + struct kobject *kobj,
> + struct bin_attribute *attr,
> + char *buf, loff_t pos, size_t count)
> +{
> + struct mq_queue *mq;
> + struct mq_msg *msg;
> + unsigned long flags;
> + bool more = false;
> + ssize_t ret = 0;
> +
> + mq = dev_get_drvdata(container_of(kobj, struct device, kobj));
> +
> + spin_lock_irqsave(>lock, flags);
> + if (mq->out != mq->in) {
> + msg = >queue[mq->out];
> +
> + if (msg->len <= count) {
> + ret = msg->len;
> + memcpy(buf, msg->buf, ret);
Is buf a userspace pointer? should it be a copy_to_user() here?
> + } else {
> + ret = -EOVERFLOW; /* Drop this HUGE one. */
> + }
> +
> + mq->out = MQ_QUEUE_NEXT(mq->out);
> + if (mq->out != mq->in)
> + more = true;
> + }
> + spin_unlock_irqrestore(>lock, flags);
> +
> + if (more)
> + kernfs_notify(mq->kn);
> +
> + return ret;
> +}
> +
> +static int i2c_slave_mqueue_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct device *dev = >dev;
> + struct mq_queue *mq;
> + int ret, i;
> + void *buf;
> +
> + mq = devm_kzalloc(dev, sizeof(*mq), GFP_KERNEL);
> + if (!mq)
> + return -ENOMEM;
> +
> + BUILD_BUG_ON(!is_power_of_2(MQ_QUEUE_SIZE));
> +
> + buf = devm_kmalloc_array(dev, MQ_QUEUE_SIZE, MQ_MSGBUF_SIZE,
> + GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + for (i = 0; i < MQ_QUEUE_SIZE; i++)
> + mq->queue[i].buf = buf + i * MQ_MSGBUF_SIZE;
> +
> + i2c_set_clientdata(client, mq);
> +
> + spin_lock_init(>lock);
> + mq->curr = >queue[0];
> +
> + sysfs_bin_attr_init(>bin);
> + mq->bin.attr.name = "slave-mqueue";
> + mq->bin.attr.mode = 0400;
> + mq->bin.read = i2c_slave_mqueue_bin_read;
> + mq->bin.size = MQ_MSGBUF_SIZE * MQ_QUEUE_SIZE;
> +
> + ret = sysfs_create_bin_file(>kobj, >bin);
> + if (ret)
> + return ret;
> +
> + mq->kn = kernfs_find_and_get(dev->kobj.sd, mq->bin.attr.name);
> + if (!mq->kn) {
> + sysfs_remove_bin_file(>kobj, >bin);
> + return -EFAULT;
> + }
> +
> + ret = i2c_slave_register(client, i2c_slave_mqueue_callback);
> + if (ret) {
> + kernfs_put(mq->kn);
> + sysfs_remove_bin_file(>kobj, >bin);
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static int i2c_slave_mqueue_remove(struct i2c_client *client)
> +{
> + struct mq_queue *mq = i2c_get_clientdata(client);
> +
> + i2c_slave_unregister(client);
> +
> + kernfs_put(mq->kn);
> + sysfs_remove_bin_file(>dev.kobj, >bin);
> +
> + return 0;
> +}
> +
> +static const struct i2c_device_id i2c_slave_mqueue_id[] = {
> + { "slave-mqueue", 0 },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, i2c_slave_mqueue_id);
> +
> +static struct i2c_driver i2c_slave_mqueue_driver = {
> + .driver = {
> + .name = "i2c-slave-mqueue",
> + },
> + .probe = i2c_slave_mqueue_probe,
> + .remove = i2c_slave_mqueue_remove,
> + .id_table = i2c_slave_mqueue_id,
> +};
> +module_i2c_driver(i2c_slave_mqueue_driver);
> +
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Haiyue Wang ");
> +MODULE_DESCRIPTION("I2C slave mode for receiving and queuing messages");
> --
> 2.7.4
>
--
All the best,
Eduardo Valentin
[GIT PULL] Thermal-SoC management changes for v5.2-rc1
Hello Linus, Please consider the following thermal soc changes for v5.2-rc1. The following changes since commit 37624b58542fb9f2d9a70e6ea006ef8a5f66c30b: Linux 5.1-rc7 (2019-04-28 17:04:13 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal linus for you to fetch changes up to 37bcec5d9f71bd13142a97d2196b293c9ac23823: hwmon: (pwm-fan) Use devm_thermal_of_cooling_device_register (2019-05-14 07:00:47 -0700) Specifics: - thermal core has a new devm_* API for registering cooling devices, thanks to Guenter R. I took the entire series, that is why you see changes on drivers/hwmon in this pull. - rockchip thermal driver gains support to PX30 SoC, thanks to Elaine Z. - the generic-adc thermal driver now considers the lookup table DT property as optional, thanks to Jean-Francois D. - Refactoring of tsens thermal driver, thanks to Amit K. - Cleanups on cpu cooling driver, thanks to Daniel L. - broadcom thermal driver dropped support to ACPI, thanks to Srinath M. - tegra thermal driver gains support to OC hw throttle and GPU throtle, thanks to Wei Ni. - Fixes in several thermal drivers. BR, Eduardo Valentin Amit Kucheria (21): drivers: thermal: tsens: Document the data structures drivers: thermal: tsens: Rename tsens_data drivers: thermal: tsens: Rename tsens_device drivers: thermal: tsens: Rename variable tmdev drivers: thermal: tsens: Use consistent names for variables drivers: thermal: tsens: Function prototypes should have argument names drivers: thermal: tsens: Rename tsens-8916 to prepare to merge with tsens-8974 drivers: thermal: tsens: Rename constants to prepare to merge with tsens-8974 drivers: thermal: tsens: Merge tsens-8974 into tsens-v0_1 drivers: thermal: tsens: Introduce reg_fields to deal with register description drivers: thermal: tsens: Save reference to the device pointer and use it drivers: thermal: tsens: Don't print error message on -EPROBE_DEFER drivers: thermal: tsens: Add new operation to check if a sensor is enabled drivers: thermal: tsens: change data type for sensor IDs drivers: thermal: tsens: Introduce IP-specific max_sensor count drivers: thermal: tsens: simplify get_temp_tsens_v2 routine drivers: thermal: tsens: Move get_temp_tsens_v2 to allow sharing drivers: thermal: tsens: Common get_temp() learns to do ADC conversion dt: thermal: tsens: Add bindings for qcs404 drivers: thermal: tsens: Add generic support for TSENS v1 IP drivers: thermal: tsens: Move calibration constants to header file Andrey Smirnov (1): thermal: qoriq: Remove unnecessary DT node is NULL check Daniel Lezcano (4): thermal/drivers/cpu_cooling: Remove pointless test in power2state() thermal/drivers/cpu_cooling: Fixup the header and copyright thermal/drivers/cpu_cooling: Add Software Package Data Exchange (SPDX) thermal/drivers/cpu_cooling: Remove pointless field Elaine Zhang (3): thermal: rockchip: fix up the tsadc pinctrl setting error dt-bindings: rockchip-thermal: Support the PX30 SoC compatible thermal: rockchip: Support the PX30 SoC in thermal driver Enrico Weigelt, metux IT consult (1): drivers: thermal: Kconfig: pedantic cleanups Guenter Roeck (6): thermal: Introduce devm_thermal_of_cooling_device_register hwmon: (aspeed-pwm-tacho) Use devm_thermal_of_cooling_device_register hwmon: (gpio-fan) Use devm_thermal_of_cooling_device_register hwmon: (mlxreg-fan) Use devm_thermal_of_cooling_device_register hwmon: (npcm750-pwm-fan) Use devm_thermal_of_cooling_device_register hwmon: (pwm-fan) Use devm_thermal_of_cooling_device_register Hoan Nguyen An (1): thermal: rcar_gen3_thermal: Fix init value of IRQCTL register Jean-Francois Dagenais (2): thermal: generic-adc: make lookup table optional dt-bindings: thermal: generic-adc: make lookup-table optional Jiada Wang (3): thermal: rcar_gen3_thermal: fix interrupt type thermal: rcar_gen3_thermal: disable interrupt in .remove thermal: rcar_gen3_thermal: Fix to show correct trip points number Matthias Kaehlcke (1): thermal: cpu_cooling: Actually trace CPU load in thermal_power_cpu_get_power Srinath Mannam (1): thermal: broadcom: Remove ACPI support Talel Shenhar (3): dt-bindings: thermal: al-thermal: Add binding documentation thermal: Introduce Amazon's Annapurna Labs Thermal Driver thermal: Fix build error of missing devm_ioremap_resource on UM Wei Ni (9): of: Add bindings of thermtrip for Tegra soctherm thermal: tegra: support hw and sw shutdown of: Add bindings of gpu hw throttle for Tegra soctherm thermal: tegra: add support for gpu hw-throttle thermal: tegra: add support for thermal IRQ
Re: [PATCH v3 3/3] thermal: cpu_cooling: Migrate to using the EM framework
Hey Quentin,
On Tue, May 14, 2019 at 08:15:08AM +0100, Quentin Perret wrote:
> Hi Eduardo,
>
> On Monday 13 May 2019 at 20:40:59 (-0700), Eduardo Valentin wrote:
> > On Fri, May 03, 2019 at 10:44:09AM +0100, Quentin Perret wrote:
> > > The newly introduced Energy Model framework manages power cost tables in
> > > a generic way. Moreover, it supports a several types of models since the
> > > tables can come from DT or firmware (through SCMI) for example. On the
> > > other hand, the cpu_cooling subsystem manages its own power cost tables
> > > using only DT data.
> > >
> > > In order to avoid the duplication of data in the kernel, and in order to
> > > enable IPA with EMs coming from more than just DT, remove the private
> > > tables from cpu_cooling.c and migrate it to using the centralized EM
> > > framework.
> > >
> > > The case where the thermal subsystem is used without an Energy Model
> > > (cpufreq_cooling_ops) is handled by looking directly at CPUFreq's
> > > frequency table which is already a dependency for cpu_cooling.c anyway.
> > > Since the thermal framework expects the cooling states in a particular
> > > order, bail out whenever the CPUFreq table is unsorted, since that is
> > > fairly uncommon in general, and there are currently no users of
> > > cpu_cooling for this use-case.
> >
> > Will this break DT in any way? After this change, are the existing DTs
> > still compatible with this cpu cooling?
>
> Yes, all existing DTs stay compatible with this CPU cooling. The EM can
> still be built using the 'dynamic-power-coefficient' DT property thanks
> to the recently introduced dev_pm_opp_of_register_em() helper, see
> a4f342b9607d ("PM / OPP: Introduce a power estimation helper"). And all
> relevant cpufreq drivers have already been updated to use that function.
I see..
>
> So, this patch should cause no functional change for all existing users.
> It's really just plumbing. I can probably explain that better in this
> commit message rather than the cover letter if you feel it is necessary.
>
Yes I would prefer if this info goes into the commit message.
> Thanks,
> Quentin
Re: linux-next: manual merge of the thermal-soc tree with Linus' tree
Hey Stephen, On Tue, May 14, 2019 at 02:40:06PM +1000, Stephen Rothwell wrote: > Hi Eduardo, > > On Mon, 13 May 2019 20:44:11 -0700 Eduardo Valentin > wrote: > > > > Thanks for spotting this. I am re-doing the branch based off v5.1-rc7, > > where the last conflict went in with my current queue. > > Its really not worth the rebase. Just fix the build problem and send it > all to Linus. Yeah, I think I was not super clear in my first email. I am about to send the content of my branch to Linus. This specific conflict was because a change in MAINTAINERS went in before the change I have in it, causing a conflict there. The rebase is simply to make it easier for him to pull when I send the git pull. > > -- > Cheers, > Stephen Rothwell
Re: linux-next: manual merge of the thermal-soc tree with Linus' tree
Stephen,
On Mon, May 13, 2019 at 10:49:28AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the thermal-soc tree got a conflict in:
>
> MAINTAINERS
>
> between commit:
>
> f23afd75fc99 ("RDMA/efa: Add driver to Kconfig/Makefile")
>
> from Linus' tree and commit:
>
> 7e34eb7dd067 ("thermal: Introduce Amazon's Annapurna Labs Thermal Driver")
>
> from the thermal-soc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
Thanks for spotting this. I am re-doing the branch based off v5.1-rc7,
where the last conflict went in with my current queue.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc MAINTAINERS
> index 2ff031b5e620,7defe065470d..
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@@ -745,15 -744,12 +745,21 @@@ S:Supporte
> F: Documentation/networking/device_drivers/amazon/ena.txt
> F: drivers/net/ethernet/amazon/
>
> + AMAZON ANNAPURNA LABS THERMAL MMIO DRIVER
> + M: Talel Shenhar
> + S: Maintained
> + F: Documentation/devicetree/bindings/thermal/amazon,al-thermal.txt
> + F: drivers/thermal/thermal_mmio.c
> +
> +AMAZON RDMA EFA DRIVER
> +M: Gal Pressman
> +R: Yossi Leybovich
> +L: linux-r...@vger.kernel.org
> +Q: https://patchwork.kernel.org/project/linux-rdma/list/
> +S: Supported
> +F: drivers/infiniband/hw/efa/
> +F: include/uapi/rdma/efa-abi.h
> +
> AMD CRYPTOGRAPHIC COPROCESSOR (CCP) DRIVER
> M: Tom Lendacky
> M: Gary Hook
Re: [PATCH v3 3/3] thermal: cpu_cooling: Migrate to using the EM framework
On Fri, May 03, 2019 at 10:44:09AM +0100, Quentin Perret wrote:
> The newly introduced Energy Model framework manages power cost tables in
> a generic way. Moreover, it supports a several types of models since the
> tables can come from DT or firmware (through SCMI) for example. On the
> other hand, the cpu_cooling subsystem manages its own power cost tables
> using only DT data.
>
> In order to avoid the duplication of data in the kernel, and in order to
> enable IPA with EMs coming from more than just DT, remove the private
> tables from cpu_cooling.c and migrate it to using the centralized EM
> framework.
>
> The case where the thermal subsystem is used without an Energy Model
> (cpufreq_cooling_ops) is handled by looking directly at CPUFreq's
> frequency table which is already a dependency for cpu_cooling.c anyway.
> Since the thermal framework expects the cooling states in a particular
> order, bail out whenever the CPUFreq table is unsorted, since that is
> fairly uncommon in general, and there are currently no users of
> cpu_cooling for this use-case.
Will this break DT in any way? After this change, are the existing DTs
still compatible with this cpu cooling?
>
> Signed-off-by: Quentin Perret
> ---
> drivers/thermal/Kconfig | 1 +
> drivers/thermal/cpu_cooling.c | 238 --
> 2 files changed, 82 insertions(+), 157 deletions(-)
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 653aa27a25a4..d695bd33c440 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -144,6 +144,7 @@ config THERMAL_GOV_USER_SPACE
>
> config THERMAL_GOV_POWER_ALLOCATOR
> bool "Power allocator thermal governor"
> + depends on ENERGY_MODEL
> help
> Enable this to manage platform thermals by dynamically
> allocating and limiting power to devices.
> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c
> index f7c1f49ec87f..322ea89dd078 100644
> --- a/drivers/thermal/cpu_cooling.c
> +++ b/drivers/thermal/cpu_cooling.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -48,19 +49,6 @@
> * ...
> */
>
> -/**
> - * struct freq_table - frequency table along with power entries
> - * @frequency: frequency in KHz
> - * @power: power in mW
> - *
> - * This structure is built when the cooling device registers and helps
> - * in translating frequency to power and vice versa.
> - */
> -struct freq_table {
> - u32 frequency;
> - u32 power;
> -};
> -
> /**
> * struct time_in_idle - Idle time stats
> * @time: previous reading of the absolute time that this cpu was idle
> @@ -82,7 +70,7 @@ struct time_in_idle {
> * frequency.
> * @max_level: maximum cooling level. One less than total number of valid
> * cpufreq frequencies.
> - * @freq_table: Freq table in descending order of frequencies
> + * @em: Reference on the Energy Model of the device
> * @cdev: thermal_cooling_device pointer to keep track of the
> * registered cooling device.
> * @policy: cpufreq policy.
> @@ -98,7 +86,7 @@ struct cpufreq_cooling_device {
> unsigned int cpufreq_state;
> unsigned int clipped_freq;
> unsigned int max_level;
> - struct freq_table *freq_table; /* In descending order */
> + struct em_perf_domain *em;
> struct thermal_cooling_device *cdev;
> struct cpufreq_policy *policy;
> struct list_head node;
> @@ -121,14 +109,14 @@ static LIST_HEAD(cpufreq_cdev_list);
> static unsigned long get_level(struct cpufreq_cooling_device *cpufreq_cdev,
> unsigned int freq)
> {
> - struct freq_table *freq_table = cpufreq_cdev->freq_table;
> - unsigned long level;
> + int i;
>
> - for (level = 1; level <= cpufreq_cdev->max_level; level++)
> - if (freq > freq_table[level].frequency)
> + for (i = cpufreq_cdev->max_level - 1; i >= 0; i--) {
> + if (freq > cpufreq_cdev->em->table[i].frequency)
> break;
> + }
>
> - return level - 1;
> + return cpufreq_cdev->max_level - i - 1;
> }
>
> /**
> @@ -184,105 +172,30 @@ static int cpufreq_thermal_notifier(struct
> notifier_block *nb,
> return NOTIFY_OK;
> }
>
> -/**
> - * update_freq_table() - Update the freq table with power numbers
> - * @cpufreq_cdev:the cpufreq cooling device in which to update the table
> - * @capacitance: dynamic power coefficient for these cpus
> - *
> - * Update the freq table with power numbers. This table will be used in
> - * cpu_power_to_freq() and cpu_freq_to_power() to convert between power and
> - * frequency efficiently. Power is stored in mW, frequency in KHz. The
> - * resulting table is in descending order.
> - *
> - * Return: 0 on success, -EINVAL if there are no OPPs for any CPUs,
> - * or -ENOMEM if we run out of memory.
> - */
> -static int update_freq_table(struct cpufreq_cooling_device
Re: [PATCH - resend 1/3] thermal/drivers/cpu_cooling: Fixup the header and copyright
On Sun, Apr 28, 2019 at 11:51:03AM +0200, Daniel Lezcano wrote: > The copyright format does not conform to the format requested by > Linaro: https://wiki.linaro.org/Copyright > > Fix it. > > Signed-off-by: Daniel Lezcano > Viresh Kumar Based on the series and other patches of it, I am assuming this is an Acked-by.. Applied as Acked-by. > --- > drivers/thermal/cpu_cooling.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c > index ee8419a6390c..42aeb9087cab 100644 > --- a/drivers/thermal/cpu_cooling.c > +++ b/drivers/thermal/cpu_cooling.c > @@ -2,9 +2,11 @@ > * linux/drivers/thermal/cpu_cooling.c > * > * Copyright (C) 2012 Samsung Electronics Co., > Ltd(http://www.samsung.com) > - * Copyright (C) 2012 Amit Daniel > * > - * Copyright (C) 2014 Viresh Kumar > + * Copyright (C) 2012-2018 Linaro Limited. > + * > + * Authors: Amit Daniel > + * Viresh Kumar > * > * ~~ > * This program is free software; you can redistribute it and/or modify
Re: [PATCH 1/7] thermal/drivers/core: Remove the module Kconfig's option
Hello, On Tue, Apr 02, 2019 at 06:12:44PM +0200, Daniel Lezcano wrote: > The module support for the thermal subsystem makes little sense: > - some subsystems relying on it are not modules, thus forcing the >framework to be compiled in > - it is compiled in for almost every configs, the remaining ones >are a few platforms where I don't see why we can not switch the thermal >to 'y'. The drivers can stay in tristate. > - platforms need the thermal to be ready as soon as possible at boot time >in order to mitigate > > Usually the subsystems framework are compiled-in and the plugs are as module. > > Remove the module option. The removal of the module related dead code will > come after this patch gets in or is acked. I remember some buzilla entry around this some time back. Rui, do you remember why you made this to be module? I dont have strong opinion here, but I would like to see a better description why we are going this direction rather than "most people dont use it as module". Was there any particular specific technical motivation? > > Signed-off-by: Daniel Lezcano > Acked-by: Guenter Roeck > For mini2440: > Acked-by: Krzysztof Kozlowski > --- > arch/arm/configs/mini2440_defconfig| 2 +- > arch/arm/configs/pxa_defconfig | 2 +- > arch/mips/configs/ip22_defconfig | 2 +- > arch/mips/configs/ip27_defconfig | 2 +- > arch/unicore32/configs/unicore32_defconfig | 2 +- > drivers/thermal/Kconfig| 4 ++-- > 6 files changed, 7 insertions(+), 7 deletions(-) > > diff --git a/arch/arm/configs/mini2440_defconfig > b/arch/arm/configs/mini2440_defconfig > index d95a8059d30b..0cf1c120c4bb 100644 > --- a/arch/arm/configs/mini2440_defconfig > +++ b/arch/arm/configs/mini2440_defconfig > @@ -152,7 +152,7 @@ CONFIG_SPI_S3C24XX=y > CONFIG_SPI_SPIDEV=y > CONFIG_GPIO_SYSFS=y > CONFIG_SENSORS_LM75=y > -CONFIG_THERMAL=m > +CONFIG_THERMAL=y > CONFIG_WATCHDOG=y > CONFIG_S3C2410_WATCHDOG=y > CONFIG_FB=y > diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig > index d4654755b09c..d4f9dda3a52f 100644 > --- a/arch/arm/configs/pxa_defconfig > +++ b/arch/arm/configs/pxa_defconfig > @@ -387,7 +387,7 @@ CONFIG_SENSORS_LM75=m > CONFIG_SENSORS_LM90=m > CONFIG_SENSORS_LM95245=m > CONFIG_SENSORS_NTC_THERMISTOR=m > -CONFIG_THERMAL=m > +CONFIG_THERMAL=y > CONFIG_WATCHDOG=y > CONFIG_XILINX_WATCHDOG=m > CONFIG_SA1100_WATCHDOG=m > diff --git a/arch/mips/configs/ip22_defconfig > b/arch/mips/configs/ip22_defconfig > index ff40fbc2f439..21a1168ae301 100644 > --- a/arch/mips/configs/ip22_defconfig > +++ b/arch/mips/configs/ip22_defconfig > @@ -228,7 +228,7 @@ CONFIG_SERIAL_IP22_ZILOG=m > # CONFIG_HW_RANDOM is not set > CONFIG_RAW_DRIVER=m > # CONFIG_HWMON is not set > -CONFIG_THERMAL=m > +CONFIG_THERMAL=y > CONFIG_WATCHDOG=y > CONFIG_INDYDOG=m > # CONFIG_VGA_CONSOLE is not set > diff --git a/arch/mips/configs/ip27_defconfig > b/arch/mips/configs/ip27_defconfig > index 81c47e18131b..54db5dedf776 100644 > --- a/arch/mips/configs/ip27_defconfig > +++ b/arch/mips/configs/ip27_defconfig > @@ -271,7 +271,7 @@ CONFIG_I2C_PARPORT_LIGHT=m > CONFIG_I2C_TAOS_EVM=m > CONFIG_I2C_STUB=m > # CONFIG_HWMON is not set > -CONFIG_THERMAL=m > +CONFIG_THERMAL=y > CONFIG_MFD_PCF50633=m > CONFIG_PCF50633_ADC=m > CONFIG_PCF50633_GPIO=m > diff --git a/arch/unicore32/configs/unicore32_defconfig > b/arch/unicore32/configs/unicore32_defconfig > index aebd01fc28e5..360cc9abcdb0 100644 > --- a/arch/unicore32/configs/unicore32_defconfig > +++ b/arch/unicore32/configs/unicore32_defconfig > @@ -119,7 +119,7 @@ CONFIG_I2C_PUV3=y > #Hardware Monitoring support > #CONFIG_SENSORS_LM75=m > #Generic Thermal sysfs driver > -#CONFIG_THERMAL=m > +#CONFIG_THERMAL=y > #CONFIG_THERMAL_HWMON=y > > #Multimedia support > diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig > index 653aa27a25a4..ccf5b9408d7a 100644 > --- a/drivers/thermal/Kconfig > +++ b/drivers/thermal/Kconfig > @@ -3,7 +3,7 @@ > # > > menuconfig THERMAL > - tristate "Generic Thermal sysfs driver" > + bool "Generic Thermal sysfs driver" > help > Generic Thermal Sysfs driver offers a generic mechanism for > thermal management. Usually it's made up of one or more thermal > @@ -11,7 +11,7 @@ menuconfig THERMAL > Each thermal zone contains its own temperature, trip points, > cooling devices. > All platforms with ACPI thermal support can use this driver. > - If you want this support, you should say Y or M here. > + If you want this support, you should say Y here. > > if THERMAL > > -- > 2.17.1 >
Re: [PATCH v2 12/12] thermal: tegra: enable OC hw throttle
On Thu, Feb 21, 2019 at 06:18:47PM +0800, Wei Ni wrote:
> Parse Over Current settings from DT and program them to
> generate interrupts. Also enable hw throttling whenever
> there are OC events. Log the OC events as debug messages.
>
> Signed-off-by: Wei Ni
I applied this series except for this specific patch which:
a. does not apply clean
b. does not compile.
Please rebase on top of my -linus branch and resend this. remember to
checkpatch and compile and boot test before sending.
> ---
> drivers/thermal/tegra/soctherm.c | 130
> ---
> 1 file changed, 120 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/thermal/tegra/soctherm.c
> b/drivers/thermal/tegra/soctherm.c
> index b8c66368e54e..6e3f329d1ac4 100644
> --- a/drivers/thermal/tegra/soctherm.c
> +++ b/drivers/thermal/tegra/soctherm.c
> @@ -106,9 +106,26 @@
> #define STATS_CTL_CLR_UP 0x2
> #define STATS_CTL_EN_UP 0x1
>
> +#define OC1_CFG 0x310
> +#define OC1_CFG_LONG_LATENCY_MASKBIT(6)
> +#define OC1_CFG_HW_RESTORE_MASK BIT(5)
> +#define OC1_CFG_PWR_GOOD_MASK_MASK BIT(4)
> +#define OC1_CFG_THROTTLE_MODE_MASK (0x3 << 2)
> +#define OC1_CFG_ALARM_POLARITY_MASK BIT(1)
> +#define OC1_CFG_EN_THROTTLE_MASK BIT(0)
> +
> +#define OC1_CNT_THRESHOLD0x314
> +#define OC1_THROTTLE_PERIOD 0x318
> +#define OC1_ALARM_COUNT 0x31c
> +#define OC1_FILTER 0x320
> +#define OC1_STATS0x3a8
> +
> #define OC_INTR_STATUS 0x39c
> #define OC_INTR_ENABLE 0x3a0
> #define OC_INTR_DISABLE 0x3a4
> +#define OC_STATS_CTL 0x3c4
> +#define OC_STATS_CTL_CLR_ALL 0x2
> +#define OC_STATS_CTL_EN_ALL 0x1
>
> #define OC_INTR_OC1_MASK BIT(0)
> #define OC_INTR_OC2_MASK BIT(1)
> @@ -207,6 +224,25 @@
> #define THROT_DELAY_CTRL(throt) (THROT_DELAY_LITE + \
> (THROT_OFFSET * throt))
>
> +#define ALARM_OFFSET 0x14
> +#define ALARM_CFG(throt) (OC1_CFG + \
> + (ALARM_OFFSET * (throt - THROTTLE_OC1)))
> +
> +#define ALARM_CNT_THRESHOLD(throt) (OC1_CNT_THRESHOLD + \
> + (ALARM_OFFSET * (throt - THROTTLE_OC1)))
> +
> +#define ALARM_THROTTLE_PERIOD(throt) (OC1_THROTTLE_PERIOD + \
> + (ALARM_OFFSET * (throt - THROTTLE_OC1)))
> +
> +#define ALARM_ALARM_COUNT(throt) (OC1_ALARM_COUNT + \
> + (ALARM_OFFSET * (throt - THROTTLE_OC1)))
> +
> +#define ALARM_FILTER(throt) (OC1_FILTER + \
> + (ALARM_OFFSET * (throt - THROTTLE_OC1)))
> +
> +#define ALARM_STATS(throt) (OC1_STATS + \
> + (4 * (throt - THROTTLE_OC1)))
> +
> /* get CCROC_THROT_PSKIP_xxx offset per HIGH/MED/LOW vect*/
> #define CCROC_THROT_OFFSET 0x0c
> #define CCROC_THROT_PSKIP_CTRL_CPU_REG(vect)(CCROC_THROT_PSKIP_CTRL_CPU
> + \
> @@ -218,6 +254,9 @@
> #define THERMCTL_LVL_REGS_SIZE 0x20
> #define THERMCTL_LVL_REG(rg, lv) ((rg) + ((lv) * THERMCTL_LVL_REGS_SIZE))
>
> +#define OC_THROTTLE_MODE_DISABLED0
> +#define OC_THROTTLE_MODE_BRIEF 2
> +
> static const int min_low_temp = -127000;
> static const int max_high_temp = 127000;
>
> @@ -266,6 +305,15 @@ struct tegra_thermctl_zone {
> const struct tegra_tsensor_group *sg;
> };
>
> +struct soctherm_oc_cfg {
> + u32 active_low;
> + u32 throt_period;
> + u32 alarm_cnt_thresh;
> + u32 alarm_filter;
> + u32 mode;
> + bool intr_en;
> +};
> +
> struct soctherm_throt_cfg {
> const char *name;
> unsigned int id;
> @@ -273,6 +321,7 @@ struct soctherm_throt_cfg {
> u8 cpu_throt_level;
> u32 cpu_throt_depth;
> u32 gpu_throt_level;
> + struct soctherm_oc_cfg oc_cfg;
> struct thermal_cooling_device *cdev;
> bool init;
> };
> @@ -715,7 +764,7 @@ static int tegra_soctherm_set_hwtrips(struct device *dev,
> return 0;
> }
>
> - for (i = 0; i < THROTTLE_SIZE; i++) {
> + for (i = 0; i < THROTTLE_OC1; i++) {
> struct thermal_cooling_device *cdev;
>
> if (!ts->throt_cfgs[i].init)
> @@ -1537,6 +1586,32 @@ static int soctherm_thermtrips_parse(struct
> platform_device *pdev)
> return 0;
> }
>
> +static void soctherm_oc_cfg_parse(struct device *dev,
> + struct device_node *np_oc,
> + struct soctherm_throt_cfg *stc)
> +{
> + u32
Re: [PATCH] thermal/drivers/of: Add a get_temp_id callback function
Hello,
On Tue, Apr 16, 2019 at 07:22:03PM +0200, Daniel Lezcano wrote:
> Currently when we register a sensor, we specify the sensor id and a data
> pointer to be passed when the get_temp function is called. However the
> sensor_id is not passed to the get_temp callback forcing the driver to
> do extra allocation and adding back pointer to find out from the sensor
> information the driver data and then back to the sensor id.
>
> Add a new callback get_temp_id() which will be called if set. It will
> call the get_temp_id() with the sensor id.
>
> That will be more consistent with the registering function.
I still do not understand why we need to have a get_id callback.
The use cases I have seen so far, which I have been intentionally rejecting, are
mainly solvable by creating other compatible entries. And really, if you
have, say a bandgap, chip that supports multiple sensors, but on
SoC version A it has 5 sensors, and on SoC version B it has only 4,
or on SoC version C, it has 5 but they are either logially located
in different places (gpu vs iva regions), these are all cases in which
you want a different compatible!
Do you mind sharing why you need a get sensor id callback?
>
> Signed-off-by: Daniel Lezcano
> Tested-by: Andrey Smirnov
> ---
> drivers/thermal/of-thermal.c | 19 +--
> include/linux/thermal.h | 1 +
> 2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/thermal/of-thermal.c b/drivers/thermal/of-thermal.c
> index 2df059cc07e2..787d1cbe13f3 100644
> --- a/drivers/thermal/of-thermal.c
> +++ b/drivers/thermal/of-thermal.c
> @@ -78,6 +78,8 @@ struct __thermal_zone {
>
> /* sensor interface */
> void *sensor_data;
> + int sensor_id;
> +
> const struct thermal_zone_of_device_ops *ops;
> };
>
> @@ -88,10 +90,14 @@ static int of_thermal_get_temp(struct thermal_zone_device
> *tz,
> {
> struct __thermal_zone *data = tz->devdata;
>
> - if (!data->ops->get_temp)
> - return -EINVAL;
> + if (data->ops->get_temp)
> + return data->ops->get_temp(data->sensor_data, temp);
>
> - return data->ops->get_temp(data->sensor_data, temp);
> + if (data->ops->get_temp_id)
> + return data->ops->get_temp_id(data->sensor_id,
> + data->sensor_data, temp);
> +
> + return -EINVAL;
> }
>
> static int of_thermal_set_trips(struct thermal_zone_device *tz,
> @@ -407,8 +413,8 @@ static struct thermal_zone_device_ops of_thermal_ops = {
> /*** sensor API ***/
>
> static struct thermal_zone_device *
> -thermal_zone_of_add_sensor(struct device_node *zone,
> -struct device_node *sensor, void *data,
> +thermal_zone_of_add_sensor(struct device_node *zone, struct device_node
> *sensor,
> +int sensor_id, void *data,
> const struct thermal_zone_of_device_ops *ops)
> {
> struct thermal_zone_device *tzd;
> @@ -426,6 +432,7 @@ thermal_zone_of_add_sensor(struct device_node *zone,
> mutex_lock(>lock);
> tz->ops = ops;
> tz->sensor_data = data;
> + tz->sensor_id = sensor_id;
>
> tzd->ops->get_temp = of_thermal_get_temp;
> tzd->ops->get_trend = of_thermal_get_trend;
> @@ -516,7 +523,7 @@ thermal_zone_of_sensor_register(struct device *dev, int
> sensor_id, void *data,
> }
>
> if (sensor_specs.np == sensor_np && id == sensor_id) {
> - tzd = thermal_zone_of_add_sensor(child, sensor_np,
> + tzd = thermal_zone_of_add_sensor(child, sensor_np,
> sensor_id,
>data, ops);
> if (!IS_ERR(tzd))
> tzd->ops->set_mode(tzd, THERMAL_DEVICE_ENABLED);
> diff --git a/include/linux/thermal.h b/include/linux/thermal.h
> index 5f4705f46c2f..2762d7e6dd86 100644
> --- a/include/linux/thermal.h
> +++ b/include/linux/thermal.h
> @@ -351,6 +351,7 @@ struct thermal_genl_event {
> * hardware.
> */
> struct thermal_zone_of_device_ops {
> + int (*get_temp_id)(int, void *, int *);
> int (*get_temp)(void *, int *);
> int (*get_trend)(void *, int, enum thermal_trend *);
> int (*set_trips)(void *, int, int);
> --
> 2.17.1
>
[GIT PULL] Thermal-SoC management changes for v5.1-rc1
Hello Linus, Please consider the following thermal soc changes for v5.1-rc1. The following changes since commit 8834f5600cf3c8db365e18a3d5cac2c2780c81e5: Linux 5.0-rc5 (2019-02-03 13:48:04 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal linus for you to fetch changes up to 6269e9f790e8d442b3e1529bf3b3de452dd4ac92: thermal: rcar_gen3_thermal: Register hwmon sysfs interface (2019-02-20 17:23:40 -0800) Kernel CI output: Full Boot Summary: https://kernelci.org/boot/all/job/evalenti/branch/for-kernelci/kernel/v5.0-rc5-15-g6269e9f790e8/ Full Build Summary: https://kernelci.org/build/evalenti/branch/for-kernelci/kernel/v5.0-rc5-15-g6269e9f790e8/ Specifics: - mediatek thermal now supports MT8183 - broadcom thermal now supports Stingray - qoirq now supports multiple sensors - fixes on different drivers: rcar, tsens, tegra Some new drivers are still pending further review and I chose to leave them for the next merge window while still sending this material. BR, Marek Vasut (1): thermal: rcar_gen3_thermal: Register hwmon sysfs interface Michael Kao (7): thermal: mediatek: fix register index error thermal: mediatek: add common index of vts settings. thermal: mediatek: add calibration item thermal: mediatek: add thermal controller offset thermal: mediatek: add flag for bank selection dt-bindings: thermal: add binding document for mt8183 thermal controller thermal: mediatek: add support for MT8183 Peng Hao (1): thermal/qcom/tsens-common : fix possible object reference leak Pramod Kumar (2): dt-bindings: thermal: Add binding document for SR thermal thermal: broadcom: Add Stingray thermal driver Wei Ni (3): thermal: tegra: remove unnecessary warnings thermal: tegra: fix memory allocation thermal: tegra: add get_trend ops Yuantian Tang (1): thermal: qoriq: add multiple sensors support .../bindings/thermal/brcm,sr-thermal.txt | 105 +++ .../bindings/thermal/mediatek-thermal.txt | 1 + drivers/thermal/Kconfig| 3 +- drivers/thermal/broadcom/Kconfig | 9 + drivers/thermal/broadcom/Makefile | 1 + drivers/thermal/broadcom/sr-thermal.c | 121 drivers/thermal/mtk_thermal.c | 316 + drivers/thermal/qcom/tsens-common.c| 33 ++- drivers/thermal/qoriq_thermal.c| 104 +++ drivers/thermal/rcar_gen3_thermal.c| 19 ++ drivers/thermal/tegra/soctherm.c | 38 ++- 11 files changed, 620 insertions(+), 130 deletions(-) create mode 100644 Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt create mode 100644 drivers/thermal/broadcom/sr-thermal.c
Re: [PATCH V8 1/4] dt-bindings: fsl: scu: add thermal binding
On Sat, Feb 23, 2019 at 01:38:00PM -0800, Eduardo Valentin wrote:
> On Thu, Feb 21, 2019 at 06:38:30AM +, Anson Huang wrote:
> > NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
> > system controller, the system controller is in charge of system
> > power, clock and thermal sensors etc. management, Linux kernel
> > has to communicate with system controller via MU (message unit)
> > IPC to get temperature from thermal sensors, this patch adds
> > binding doc for i.MX system controller thermal driver.
> >
> > Signed-off-by: Anson Huang
> > Reviewed-by: Rob Herring
> > ---
> > Changes since V7:
> > - remove unused property "tsens-num";
> > - improve the compatible description;
> > - update examples according to latest dts file.
> > ---
> > .../devicetree/bindings/arm/freescale/fsl,scu.txt | 19
> > +++
> > 1 file changed, 19 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > index 72d481c..d89147e 100644
> > --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > @@ -122,6 +122,19 @@ RTC bindings based on SCU Message Protocol
> > Required properties:
> > - compatible: should be "fsl,imx8qxp-sc-rtc";
> >
> > +Thermal bindings based on SCU Message Protocol
> > +
> > +
> > +Required properties:
> > +- compatible: Should be :
> > + "fsl,imx8qxp-sc-thermal"
> > + followed by "fsl,imx-sc-thermal";
> > +
> > +- #thermal-sensor-cells: See
> > Documentation/devicetree/bindings/thermal/thermal.txt
> > + for a description.
> > +
> > +- imx,sensor-resource-id: Property array to specify each thermal zone's
> > sensor resource ID.
>
> If this is an array...
>
> > +
> > Example (imx8qxp):
> > -
> > lsio_mu1: mailbox@5d1c {
> > @@ -168,6 +181,12 @@ firmware {
> > rtc: rtc {
> > compatible = "fsl,imx8qxp-sc-rtc";
> > };
> > +
> > + tsens: thermal-sensor {
> > + compatible = "fsl,imx8qxp-sc-thermal",
> > "fsl,imx-sc-thermal";
> > + #thermal-sensor-cells = <0>;
> > + imx,sensor-resource-id = ;
>
> then this example should have an array, to be better express how this is
> supposed to work. Can you please resend this with an array instead?
I mean this could be one example of an array with more than one element.
>
> > + };
> > };
> > };
> >
> > --
> > 2.7.4
> >
Re: [PATCH V8 2/4] thermal: imx_sc: add i.MX system controller thermal support
Hey Anson,
On Thu, Feb 21, 2019 at 06:38:39AM +, Anson Huang wrote:
> i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
> inside, the system controller is in charge of controlling power,
> clock and thermal sensors etc..
>
> This patch adds i.MX system controller thermal driver support,
> Linux kernel has to communicate with system controller via MU
> (message unit) IPC to get each thermal sensor's temperature,
> it supports multiple sensors which are passed from device tree,
> please see the binding doc for details.
>
> Signed-off-by: Anson Huang
> ---
> Changes since V7:
> - remove unused structure imx_sc_thermal_data to simply the driver;
> - move the "imx,sensor-resource-id" property from thermal zone node to
> scu tsens node, and
> get this property using phandle;
> - remove unused sensor number got from dts, now it is not needed.
> ---
> drivers/thermal/Kconfig | 11 +++
> drivers/thermal/Makefile | 1 +
> drivers/thermal/imx_sc_thermal.c | 144
> +++
> 3 files changed, 156 insertions(+)
> create mode 100644 drivers/thermal/imx_sc_thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 58bb7d7..fec0ef5 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -223,6 +223,17 @@ config IMX_THERMAL
> cpufreq is used as the cooling device to throttle CPUs when the
> passive trip is crossed.
>
> +config IMX_SC_THERMAL
> + tristate "Temperature sensor driver for NXP i.MX SoCs with System
> Controller"
> + depends on (ARCH_MXC && IMX_SCU) || COMPILE_TEST
> + depends on OF
> + help
> + Support for Temperature Monitor (TEMPMON) found on NXP i.MX SoCs with
> + system controller inside, Linux kernel has to communicate with system
> + controller via MU (message unit) IPC to get temperature from thermal
> + sensor. It supports one critical trip point and one
> + passive trip point for each thermal sensor.
> +
> config MAX77620_THERMAL
> tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
> depends on MFD_MAX77620
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 486d682..4062627 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -40,6 +40,7 @@ obj-$(CONFIG_DB8500_THERMAL)+= db8500_thermal.o
> obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
> obj-$(CONFIG_TANGO_THERMAL) += tango_thermal.o
> obj-$(CONFIG_IMX_THERMAL)+= imx_thermal.o
> +obj-$(CONFIG_IMX_SC_THERMAL) += imx_sc_thermal.o
> obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
> obj-$(CONFIG_QORIQ_THERMAL) += qoriq_thermal.o
> obj-$(CONFIG_DA9062_THERMAL) += da9062-thermal.o
> diff --git a/drivers/thermal/imx_sc_thermal.c
> b/drivers/thermal/imx_sc_thermal.c
> new file mode 100644
> index 000..145e73b
> --- /dev/null
> +++ b/drivers/thermal/imx_sc_thermal.c
> @@ -0,0 +1,144 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2018-2019 NXP.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "thermal_core.h"
> +
> +#define IMX_SC_MISC_FUNC_GET_TEMP13
> +#define IMX_SC_C_TEMP0
> +
> +static struct imx_sc_ipc *thermal_ipc_handle;
> +
> +struct imx_sc_sensor {
> + struct thermal_zone_device *tzd;
> + u32 resource_id;
> +};
> +
> +struct req_get_temp {
> + u16 resource_id;
> + u8 type;
> +} __packed;
> +
> +struct resp_get_temp {
> + u16 celsius;
> + u8 tenths;
> +} __packed;
> +
> +struct imx_sc_msg_misc_get_temp {
> + struct imx_sc_rpc_msg hdr;
> + union {
> + struct req_get_temp req;
> + struct resp_get_temp resp;
> + } data;
> +} __packed;
> +
> +static int imx_sc_thermal_get_temp(void *data, int *temp)
> +{
> + struct imx_sc_msg_misc_get_temp msg;
> + struct imx_sc_rpc_msg *hdr =
> + struct imx_sc_sensor *sensor = data;
> + int ret;
> +
> + msg.data.req.resource_id = sensor->resource_id;
> + msg.data.req.type = IMX_SC_C_TEMP;
> +
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_MISC;
> + hdr->func = IMX_SC_MISC_FUNC_GET_TEMP;
> + hdr->size = 2;
> +
> + ret = imx_scu_call_rpc(thermal_ipc_handle, , true);
> + if (ret) {
> + pr_err("read temp sensor %d failed, ret %d\n",
> + sensor->resource_id, ret);
> + return ret;
> + }
> +
> + *temp = msg.data.resp.celsius * 1000 + msg.data.resp.tenths * 100;
> +
> + return 0;
> +}
> +
> +static const struct thermal_zone_of_device_ops imx_sc_thermal_ops = {
> + .get_temp = imx_sc_thermal_get_temp,
> +};
> +
> +static int imx_sc_thermal_probe(struct platform_device *pdev)
> +{
> + struct device_node *np, *sensor_np;
> + int ret, i = 0;
> +
> + ret = imx_scu_get_handle(_ipc_handle);
> +
Re: [PATCH V8 1/4] dt-bindings: fsl: scu: add thermal binding
On Thu, Feb 21, 2019 at 06:38:30AM +, Anson Huang wrote:
> NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
> system controller, the system controller is in charge of system
> power, clock and thermal sensors etc. management, Linux kernel
> has to communicate with system controller via MU (message unit)
> IPC to get temperature from thermal sensors, this patch adds
> binding doc for i.MX system controller thermal driver.
>
> Signed-off-by: Anson Huang
> Reviewed-by: Rob Herring
> ---
> Changes since V7:
> - remove unused property "tsens-num";
> - improve the compatible description;
> - update examples according to latest dts file.
> ---
> .../devicetree/bindings/arm/freescale/fsl,scu.txt | 19
> +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> index 72d481c..d89147e 100644
> --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> @@ -122,6 +122,19 @@ RTC bindings based on SCU Message Protocol
> Required properties:
> - compatible: should be "fsl,imx8qxp-sc-rtc";
>
> +Thermal bindings based on SCU Message Protocol
> +
> +
> +Required properties:
> +- compatible:Should be :
> + "fsl,imx8qxp-sc-thermal"
> + followed by "fsl,imx-sc-thermal";
> +
> +- #thermal-sensor-cells: See
> Documentation/devicetree/bindings/thermal/thermal.txt
> + for a description.
> +
> +- imx,sensor-resource-id:Property array to specify each thermal zone's
> sensor resource ID.
If this is an array...
> +
> Example (imx8qxp):
> -
> lsio_mu1: mailbox@5d1c {
> @@ -168,6 +181,12 @@ firmware {
> rtc: rtc {
> compatible = "fsl,imx8qxp-sc-rtc";
> };
> +
> + tsens: thermal-sensor {
> + compatible = "fsl,imx8qxp-sc-thermal",
> "fsl,imx-sc-thermal";
> + #thermal-sensor-cells = <0>;
> + imx,sensor-resource-id = ;
then this example should have an array, to be better express how this is
supposed to work. Can you please resend this with an array instead?
> + };
> };
> };
>
> --
> 2.7.4
>
Re: [PATCH V7 2/4] thermal: imx_sc: add i.MX system controller thermal support
On Wed, Feb 20, 2019 at 06:53:40AM +, Anson Huang wrote:
> i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
> inside, the system controller is in charge of controlling power,
> clock and thermal sensors etc..
>
> This patch adds i.MX system controller thermal driver support,
> Linux kernel has to communicate with system controller via MU
> (message unit) IPC to get each thermal sensor's temperature,
> it supports multiple sensors which are passed from device tree,
> please see the binding doc for details.
>
> Signed-off-by: Anson Huang
> ---
> Changes since V6:
> - use "fsl,imx-sc-thermal" compatible to make SC thermal driver more
> generic for other i.MX8 SoCs
> with system controller inside.
> ---
> drivers/thermal/Kconfig | 11 +++
> drivers/thermal/Makefile | 1 +
> drivers/thermal/imx_sc_thermal.c | 161
> +++
> 3 files changed, 173 insertions(+)
> create mode 100644 drivers/thermal/imx_sc_thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 58bb7d7..fec0ef5 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -223,6 +223,17 @@ config IMX_THERMAL
> cpufreq is used as the cooling device to throttle CPUs when the
> passive trip is crossed.
>
> +config IMX_SC_THERMAL
> + tristate "Temperature sensor driver for NXP i.MX SoCs with System
> Controller"
> + depends on (ARCH_MXC && IMX_SCU) || COMPILE_TEST
> + depends on OF
> + help
> + Support for Temperature Monitor (TEMPMON) found on NXP i.MX SoCs with
> + system controller inside, Linux kernel has to communicate with system
> + controller via MU (message unit) IPC to get temperature from thermal
> + sensor. It supports one critical trip point and one
> + passive trip point for each thermal sensor.
> +
> config MAX77620_THERMAL
> tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
> depends on MFD_MAX77620
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 486d682..4062627 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -40,6 +40,7 @@ obj-$(CONFIG_DB8500_THERMAL)+= db8500_thermal.o
> obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
> obj-$(CONFIG_TANGO_THERMAL) += tango_thermal.o
> obj-$(CONFIG_IMX_THERMAL)+= imx_thermal.o
> +obj-$(CONFIG_IMX_SC_THERMAL) += imx_sc_thermal.o
> obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
> obj-$(CONFIG_QORIQ_THERMAL) += qoriq_thermal.o
> obj-$(CONFIG_DA9062_THERMAL) += da9062-thermal.o
> diff --git a/drivers/thermal/imx_sc_thermal.c
> b/drivers/thermal/imx_sc_thermal.c
> new file mode 100644
> index 000..1a8b978
> --- /dev/null
> +++ b/drivers/thermal/imx_sc_thermal.c
> @@ -0,0 +1,161 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2018-2019 NXP.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "thermal_core.h"
> +
> +#define IMX_SC_MISC_FUNC_GET_TEMP13
> +#define IMX_SC_C_TEMP0
> +
> +static struct imx_sc_ipc *thermal_ipc_handle;
> +
> +struct imx_sc_sensor {
> + struct thermal_zone_device *tzd;
> + u32 resource_id;
> +};
> +
> +struct imx_sc_thermal_data {
> + struct imx_sc_sensor *sensor;
> +};
> +
> +struct req_get_temp {
> + u16 resource_id;
> + u8 type;
> +} __packed;
> +
> +struct resp_get_temp {
> + u16 celsius;
> + u8 tenths;
> +} __packed;
> +
> +struct imx_sc_msg_misc_get_temp {
> + struct imx_sc_rpc_msg hdr;
> + union {
> + struct req_get_temp req;
> + struct resp_get_temp resp;
> + } data;
> +} __packed;
> +
> +static int imx_sc_thermal_get_temp(void *data, int *temp)
> +{
> + struct imx_sc_msg_misc_get_temp msg;
> + struct imx_sc_rpc_msg *hdr =
> + struct imx_sc_sensor *sensor = data;
> + int ret;
> +
> + msg.data.req.resource_id = sensor->resource_id;
> + msg.data.req.type = IMX_SC_C_TEMP;
> +
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_MISC;
> + hdr->func = IMX_SC_MISC_FUNC_GET_TEMP;
> + hdr->size = 2;
> +
> + ret = imx_scu_call_rpc(thermal_ipc_handle, , true);
> + if (ret) {
> + pr_err("read temp sensor %d failed, ret %d\n",
> + sensor->resource_id, ret);
> + return ret;
> + }
> +
> + *temp = msg.data.resp.celsius * 1000 + msg.data.resp.tenths * 100;
> +
> + return 0;
> +}
> +
> +static const struct thermal_zone_of_device_ops imx_sc_thermal_ops = {
> + .get_temp = imx_sc_thermal_get_temp,
> +};
> +
> +static int imx_sc_thermal_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct device_node *sensor_np = NULL;
> + struct imx_sc_thermal_data *data;
> + struct imx_sc_sensor *sensors;
> + u32
Re: [PATCH V7 4/4] arm64: dts: imx: add i.MX8QXP thermal support
On Wed, Feb 20, 2019 at 06:53:58AM +, Anson Huang wrote:
> Add i.MX8QXP CPU thermal zone support.
>
> Signed-off-by: Anson Huang
> ---
> Changes since V6:
> - add fallback compatible string "fsl,imx-sc-thermal" according to i.MX
> SC thermal driver
> update.
> ---
> arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 28
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> index 4c3dd95..24b03d6 100644
> --- a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
>
> / {
> interrupt-parent = <>;
> @@ -116,6 +117,12 @@
> rtc: rtc {
> compatible = "fsl,imx8qxp-sc-rtc";
> };
> +
> + tsens: thermal-sensor {
> + compatible = "fsl,imx8qxp-sc-thermal",
> "fsl,imx-sc-thermal";
> + tsens-num = <1>;
> + #thermal-sensor-cells = <1>;
> + };
> };
>
> timer {
> @@ -443,4 +450,25 @@
> power-domains = < IMX_SC_R_GPIO_7>;
> };
> };
> +
> + thermal_zones: thermal-zones {
> + cpu-thermal0 {
> + polling-delay-passive = <250>;
> + polling-delay = <2000>;
> + thermal-sensors = < 0>;
> + imx,sensor-resource-id = <355>;
> + trips {
> + cpu_alert0: trip0 {
> + temperature = <107000>;
> + hysteresis = <2000>;
> + type = "passive";
Please add your cooling maps for a passive trip point.
> + };
> + cpu_crit0: trip1 {
> + temperature = <127000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> + };
> };
> --
> 2.7.4
>
Re: [PATCH 12/12] thermal: qoriq: Add support for multiple thremal sites
On Mon, Feb 18, 2019 at 11:11:41AM -0800, Andrey Smirnov wrote:
> TMU IP block provides temerature measurement for up to 16 sites,
> current implementation of the driver however hardcodes a single site
> ID. Change the code so it would be possible to reference multiple
> sites as indivudial sensors and get their temperature readings.
small typo: indivudial/individual.
>
> Signed-off-by: Andrey Smirnov
> Cc: Chris Healy
> Cc: Lucas Stach
> Cc: Zhang Rui
> Cc: Eduardo Valentin
> Cc: Daniel Lezcano
> Cc: linux-...@nxp.com
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/thermal/qoriq_thermal.c | 132
> 1 file changed, 84 insertions(+), 48 deletions(-)
>
> diff --git a/drivers/thermal/qoriq_thermal.c b/drivers/thermal/qoriq_thermal.c
> index f746c62789b0..6cc6e6b36fb0 100644
> --- a/drivers/thermal/qoriq_thermal.c
> +++ b/drivers/thermal/qoriq_thermal.c
> @@ -24,6 +24,8 @@
> #define TMR_DISABLE 0x0
> #define TMR_ME 0x8000
> #define TMR_ALPF 0x0c00
> +#define TMR_ALPF_MASKGENMASK(27, 26)
> +
>
> #define REGS_TMTMIR 0x008 /* Temperature measurement interval Register */
> #define TMTMIR_DEFAULT 0x000f
> @@ -41,21 +43,32 @@
> #define REGS_TTRnCR(n) (0xf10 + 4 * (n)) /* Temperature Range n
> * Control Register
> */
> +struct qoriq_tmu_sensor {
> + struct thermal_zone_device *tz;
> + int id;
> +};
> +
> /*
> * Thermal zone data
> */
> struct qoriq_tmu_data {
> struct thermal_zone_device *tz;
> struct regmap *regmap;
> - int sensor_id;
> + struct qoriq_tmu_sensor sensors[SITES_MAX];
> };
>
> +static struct qoriq_tmu_data *qoriq_sensor_to_data(struct qoriq_tmu_sensor
> *s)
> +{
> + return container_of(s, struct qoriq_tmu_data, sensors[s->id]);
> +}
> +
> static int tmu_get_temp(void *p, int *temp)
> {
> u32 val;
> - struct qoriq_tmu_data *data = p;
> + struct qoriq_tmu_sensor *s = p;
> + struct qoriq_tmu_data *data = qoriq_sensor_to_data(s);
>
> - regmap_read(data->regmap, REGS_TRITSR(data->sensor_id), );
> + regmap_read(data->regmap, REGS_TRITSR(s->id), );
> if (!(val & TRITSR_V))
> return -ENODATA;
>
> @@ -63,38 +76,86 @@ static int tmu_get_temp(void *p, int *temp)
> return 0;
> }
>
> -static int qoriq_tmu_get_sensor_id(void)
> +static const struct thermal_zone_of_device_ops tmu_tz_ops = {
> + .get_temp = tmu_get_temp,
> +};
> +
> +static int qoriq_tmu_populate_sensors(struct device *dev,
> + struct qoriq_tmu_data *data)
> {
> - int ret, id;
> + int ret, id, i, count = 0;
> struct of_phandle_args sensor_specs;
> struct device_node *np, *sensor_np;
> + struct qoriq_tmu_sensor *s;
>
> np = of_find_node_by_name(NULL, "thermal-zones");
> if (!np)
> return -ENODEV;
>
> - sensor_np = of_get_next_child(np, NULL);
> - ret = of_parse_phandle_with_args(sensor_np, "thermal-sensors",
> - "#thermal-sensor-cells",
> - 0, _specs);
> - if (ret) {
> - id = ret;
> - goto out;
> + for_each_child_of_node(np, sensor_np) {
> + u16 msite;
> +
> + ret = of_parse_phandle_with_args(sensor_np, "thermal-sensors",
> + "#thermal-sensor-cells",
> + 0, _specs);
> + if (ret)
> + break;
> +
> + if (sensor_specs.args_count != 1) {
> + pr_err("%pOFn: Invalid number of cells in sensor
> specifier %d\n",
> +sensor_specs.np, sensor_specs.args_count);
> + ret = -EINVAL;
> + break;
> + }
> +
> + id = sensor_specs.args[0];
> + if (id >= SITES_MAX) {
> + ret = -EINVAL;
> + dev_err(dev, "Sensor id %d is out of range\n", id);
> + break;
> + }
> +
> + msite = BIT(15 - id);
> + /* Enable monitoring of that particular sensor*/
> + regmap_update_bits(data->regmap, REGS_TMR, msite, msite);
> +
> + s = >sensors[id];
> + s->id = id;
> + count++;
Not
Re: [PATCH 00/12] QorIQ TMU multi-sensor and HWMON support
Hey Andrey On Mon, Feb 18, 2019 at 11:11:29AM -0800, Andrey Smirnov wrote: > Everyone: > > This series contains patches adding support for HWMON integration, > multi-sensor support as well as a small fix and general improvements > (hopefully) for TMU driver I made while working on it on i.MX8MQ. > > Feedback is welcome! What branch is this patch series based off? Would you mind re-sending the series based off my -linus branch? There has been an addition on qoriq driver to support multiple sensors and the code has shifted and your series does not apply over there. > > Thanks, > Andrey Smirnov > > Andrey Smirnov (12): > thermal_hwmon: Add devres wrapper for thermal_add_hwmon_sysfs() > thermal: qoriq: Remove unnecessary DT node is NULL check > thermal: qoriq: Add local struct device pointer in qoriq_tmu_probe() > thermal: qoriq: Don't pass platform_device to qoriq_tmu_calibration() > thermal: qoriq: Convert driver to use devm_ioremap() > thermal: qoriq: Add hwmon support > thermal: qoriq: Convert driver to use regmap API > thermal: qoriq: Enable monitoring before querying temperature > thermal: qoriq: Do not report invalid temperature reading > thermal: qoriq: Simplify error handling in qoriq_tmu_get_sensor_id() > thermal: qoriq: Be more strict when parsing "thermal-sensors" > thermal: qoriq: Add support for multiple thremal sites > > drivers/thermal/qoriq_thermal.c | 326 ++-- > drivers/thermal/thermal_hwmon.c | 28 +++ > drivers/thermal/thermal_hwmon.h | 7 + > 3 files changed, 214 insertions(+), 147 deletions(-) > > -- > 2.20.1 >
Re: [PATCH v1 00/12] qcom: dts: thermal cleanups
On Wed, Feb 20, 2019 at 03:09:36PM +0530, Amit Kucheria wrote: > On Wed, Feb 20, 2019 at 6:56 AM Eduardo Valentin wrote: > > > > Hey > > On Mon, Feb 18, 2019 at 06:05:14PM +0530, Amit Kucheria wrote: > > > - Expose all temperature sensors on msm8916, msm996, msm8998, sdm845 > > > - split up the register address map for msm8998 > > > - standardize names of the various thermal-zones across boards to make it > > > easy for test scripts to parse > > > > > > > I am generally fine with the effort but please fix the following > > (applies for the whole series) wrt to required properties for DT > > thermal: > > a. Trip points for your zones > > Thanks for the review. > > In some cases, the temperatures are just exposed so something in > userspace might read it and do something with it. We don't expect > kernel trips for them. Would a hwmon driver make more sense here? > > Adding trip points also requires me to add cooling-maps (your point b. below). Yes. > > I guess I'm looking for an example of how to just expose sensor > temperatures w/o any associated trips and cooling maps. > > > b. Cooling Mappings for zones that have passive trips. > > > > From what I can see currently only CPUs and GPUs (among the major heat > sources) can passively reduce heat by reducing frequencies. > > Things like cameras, display, video might have a more ON/OFF approach > to throttling that might be controlled from userspace. And we don't > have a way to tell in DT that these zones are managed in userspace You can always add a Hot trip point. To my understanding that is for notifying userspace. > (https://patchwork.kernel.org/patch/10259487/)
Re: [PATCH v1 00/12] qcom: dts: thermal cleanups
Hey On Mon, Feb 18, 2019 at 06:05:14PM +0530, Amit Kucheria wrote: > - Expose all temperature sensors on msm8916, msm996, msm8998, sdm845 > - split up the register address map for msm8998 > - standardize names of the various thermal-zones across boards to make it > easy for test scripts to parse > I am generally fine with the effort but please fix the following (applies for the whole series) wrt to required properties for DT thermal: a. Trip points for your zones b. Cooling Mappings for zones that have passive trips. > Amit Kucheria (12): > arm64: dts: msm8998: thermal: split address space into two > arm64: dts: msm8998: efficiency is not valid property > arm64: dts: msm8916: thermal: Add sensor for modem > arm64: dts: msm8996: thermal: Add temperature sensors near major > peripherals > arm64: dts: msm8998: thermal: Fix the cpu sensor numbers > arm64: dts: msm8998: thermal: Fix the gpu sensor number > arm64: dts: msm8998: thermal: GPU has two sensors, add the second > arm64: dts: msm8998: thermal: Add temperature sensors near major > peripherals > arm64: dts: sdm845: thermal: Add temperature sensors near major > peripherals > arm64: dts: msm8998: thermal: Make trip names consistent > arm64: dts: msm8916: thermal: Make trip names consistent > arm64: dts: msm8996: thermal: Make trip names consistent > > arch/arm64/boot/dts/qcom/msm8916.dtsi | 30 +++-- > arch/arm64/boot/dts/qcom/msm8996.dtsi | 122 ++-- > arch/arm64/boot/dts/qcom/msm8998.dtsi | 154 ++ > arch/arm64/boot/dts/qcom/sdm845.dtsi | 91 +++ > 4 files changed, 328 insertions(+), 69 deletions(-) > > -- > 2.17.1 >
Re: [PATCH v1 04/12] arm64: dts: msm8996: thermal: Add temperature sensors near major peripherals
On Mon, Feb 18, 2019 at 06:05:18PM +0530, Amit Kucheria wrote:
> msm8996 has a total of 21 temperature sensors. Populate DT with
> information about them.
>
> There are 2 sensors on each of the cpus - one on the top, the other
> below (we only expose one on the top in DT for now). For the GPU, we
> expose both, the one on the top and the one below.
>
> Depending on the version of the silicon, sensor 2 is either placed near
> the L3 cache or the venus video decoder. It would've been nice to be
> able to be version-specific but we don't have DTs that differentiate the
> two versions of silicon yet.
>
> Signed-off-by: Amit Kucheria
> ---
> arch/arm64/boot/dts/qcom/msm8996.dtsi | 98 +++
> 1 file changed, 98 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> index ae6e9f0778f0..8e36a39e1386 100644
> --- a/arch/arm64/boot/dts/qcom/msm8996.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8996.dtsi
> @@ -237,6 +237,104 @@
> };
> };
> };
> +
> + gpu-thermal-top {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = < 6>;
> +
> + trips {
> + gpu1_alert0: trip-point@0 {
> + temperature = <75000>;
> + hysteresis = <2000>;
> + type = "passive";
What is the cooling map for this?
> + };
> +
> + gpu1_crit: gpu_crit {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> +
> + gpu-thermal-bottom {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = < 7>;
> +
> + trips {
> + gpu2_alert0: trip-point@0 {
> + temperature = <75000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + gpu2_crit: gpu_crit {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> +
> + m4m-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = < 1>;
> + };
> +
> + l3_or_venus-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = < 2>;
> + };
> +
> + cluster0-l2-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = < 7>;
> + };
> +
> + cluster1-l2-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = < 12>;
> + };
> +
> + camera-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = < 1>;
> + };
> +
> + q6-dsp-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = < 2>;
> + };
> +
> + mem-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = < 3>;
> + };
> +
> + modemtx-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = < 4>;
> + };
> };
>
> timer {
> --
> 2.17.1
>
Re: [PATCH v1 03/12] arm64: dts: msm8916: thermal: Add sensor for modem
On Mon, Feb 18, 2019 at 06:05:17PM +0530, Amit Kucheria wrote:
> On platforms that have a modem, sensor 0 monitors the modem.
>
> Signed-off-by: Amit Kucheria
> ---
> arch/arm64/boot/dts/qcom/msm8916.dtsi | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> index 9e598ab438a1..9e4a82e5e0b4 100644
> --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi
> +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi
> @@ -278,7 +278,13 @@
> type = "critical";
> };
> };
> + };
> +
> + modem-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
>
> + thermal-sensors = < 0>;
A thermal zone with no trips no cooling? Please check the thermal.txt
binding for the required properties.
> };
>
> };
> --
> 2.17.1
>
Re: [PATCH v1 01/12] of: Add bindings of thermtrip for Tegra soctherm
On Fri, Dec 28, 2018 at 11:28:42AM +0800, Wei Ni wrote:
>
>
> On 28/12/2018 7:06 AM, Rob Herring wrote:
> > On Tue, Dec 18, 2018 at 03:34:33PM +0800, Wei Ni wrote:
> >> Add optional property "nvidia,thermtrips".
> >> If present, these trips will be used as HW shutdown trips,
> >> and critical trips will be used as SW shutdown trips.
> >>
> >> Signed-off-by: Wei Ni
> >> ---
> >> .../bindings/thermal/nvidia,tegra124-soctherm.txt| 20
> >> +---
> >> 1 file changed, 17 insertions(+), 3 deletions(-)
> >>
> >> diff --git
> >> a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
> >> b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
> >> index b6c0ae53d4dc..ab66d6feab4b 100644
> >> ---
> >> a/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
> >> +++
> >> b/Documentation/devicetree/bindings/thermal/nvidia,tegra124-soctherm.txt
> >> @@ -55,10 +55,21 @@ Required properties :
> >>- #cooling-cells: Should be 1. This cooling device only support
> >> on/off state.
> >> See ./thermal.txt for a description of this property.
> >>
> >> +Optional properties:
> >> +- nvidia,thermtrips : When present, this property specifies the
> >> temperature at
> >> + which the soctherm hardware will assert the thermal trigger signal to
> >> the
> >> + Power Management IC, which can be configured to reset or shutdown the
> >> device.
> >> + It is an array of pairs where each pair represents a tsensor id
> >> followed by a
> >> + temperature in milli Celcius. In the absence of this property the
> >> critical
> >> + trip point will be used for thermtrip temperature.
> >> +
> >> Note:
> >> -- the "critical" type trip points will be set to SOC_THERM hardware as the
> >> -shut down temperature. Once the temperature of this thermal zone is higher
> >> -than it, the system will be shutdown or reset by hardware.
> >> +- the "critical" type trip points will be used to set the temperature at
> >> which
> >> +the SOC_THERM hardware will assert a thermal trigger if the
> >> "nvidia,thermtrips"
> >> +property is missing. When the thermtrips property is present, the breach
> >> of a
> >> +critical trip point is reported back to the thermal framework to implement
> >> +software shutdown.
> >
> > This hardly seems like a NVidia specific concept. A h/w shutdown
> > temperature... Come up with something common.
>
> Hi Rob,
> In current thermal framework, it doesn't support to set h/w shutdown
> trips, the "critical" trip is used for s/w shutdown. I noticed that in
> rockchip-thermal driver, it also used "rockchip,hw-tshut-temp" to set
> h/w shutdown temperature.
Why a critical trip point cannot be used for your hw shutdown too?
>
> >
> > Also, we already have a temperature table. Why do we need temperatures
> > in 2 places.
>
> Sorry, what do you mean temperature table? Do you mean the trip nodes?
>
> Thanks.
> Wei.
>
> >
> >> +
> >> - the "hot" type trip points will be set to SOC_THERM hardware as the
> >> throttle
> >> temperature. Once the the temperature of this thermal zone is higher
> >> than it, it will trigger the HW throttle event.
> >> @@ -79,6 +90,9 @@ Example :
> >>
> >>#thermal-sensor-cells = <1>;
> >>
> >> + nvidia,thermtrips = >> + TEGRA124_SOCTHERM_SENSOR_GPU 103000>;
> >> +
> >>throttle-cfgs {
> >>/*
> >> * When the "heavy" cooling device triggered,
> >> --
> >> 2.7.4
> >>
Re: [PATCH v1 13/24] drivers: thermal: tsens: Print IP version
On Thu, Feb 07, 2019 at 04:19:31PM +0530, Amit Kucheria wrote:
> On some TSENS IP, version is stored. Print that version at init.
>
> Signed-off-by: Amit Kucheria
> ---
> drivers/thermal/qcom/tsens-common.c | 23 ++-
> 1 file changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/thermal/qcom/tsens-common.c
> b/drivers/thermal/qcom/tsens-common.c
> index aae3d71d7eed..39cd5733fd44 100644
> --- a/drivers/thermal/qcom/tsens-common.c
> +++ b/drivers/thermal/qcom/tsens-common.c
> @@ -121,7 +121,7 @@ int __init init_common(struct tsens_priv *priv)
> void __iomem *tm_base, *srot_base;
> struct device *dev = priv->dev;
> struct resource *res;
> - u32 enabled;
> + u32 enabled, maj_ver, min_ver;
> int ret, i, j;
> struct platform_device *op = of_find_device_by_node(priv->dev->of_node);
>
> @@ -155,6 +155,27 @@ int __init init_common(struct tsens_priv *priv)
> if (IS_ERR(priv->tm_map))
> return PTR_ERR(priv->tm_map);
>
> + for (i = 0; i < MAX_REGFIELDS; i++) {
> + priv->rf[i] = NULL;
> + }
> +
> + /* alloc regmap_fields in srot_map */
> + if (priv->feat->ver_info) {
> + for (i = 0, j = VER_MAJOR; i < 2; i++, j++) {
> + priv->rf[j] = devm_regmap_field_alloc(dev,
> priv->srot_map,
> + priv->fields[j]);
> + if (IS_ERR(priv->rf[j]))
> + return PTR_ERR(priv->rf[j]);
> + }
> + ret = regmap_field_read(priv->rf[VER_MAJOR], _ver);
> + if (ret)
> + return ret;
> + ret = regmap_field_read(priv->rf[VER_MINOR], _ver);
> + if (ret)
> + return ret;
> + dev_info(dev, "version: %d.%d\n", maj_ver, min_ver);
Is this really needed? Printing stuff into kernel log during boot can
just add a lot of info that ends up just slowing down things. Besides,
if this info is important shouldnt be available somewhere else as the
kernel log is a circular buffer and eventually that line will get
wrapped up?
> + }
> +
> priv->rf[TSENS_EN] = devm_regmap_field_alloc(dev, priv->srot_map,
>priv->fields[TSENS_EN]);
> if (IS_ERR(priv->rf[TSENS_EN]))
> --
> 2.17.1
>
Re: [PATCH v1 21/24] drivers: thermal: tsens: Add generic support for TSENS v1 IP
On Thu, Feb 07, 2019 at 04:19:39PM +0530, Amit Kucheria wrote:
> qcs404 has a single TSENS IP block with 10 sensors. It uses version 1.4
> of the TSENS IP, functionality for which is encapsulated inside the
> qcom,tsens-v1 compatible.
>
> Signed-off-by: Amit Kucheria
> ---
> drivers/thermal/qcom/Makefile | 4 +-
> drivers/thermal/qcom/tsens-v1.c | 229
> drivers/thermal/qcom/tsens.c| 3 +
> drivers/thermal/qcom/tsens.h| 3 +
> 4 files changed, 238 insertions(+), 1 deletion(-)
> create mode 100644 drivers/thermal/qcom/tsens-v1.c
>
> diff --git a/drivers/thermal/qcom/Makefile b/drivers/thermal/qcom/Makefile
> index 7fa3cadce760..fc6fe50cdde4 100644
> --- a/drivers/thermal/qcom/Makefile
> +++ b/drivers/thermal/qcom/Makefile
> @@ -1,3 +1,5 @@
> obj-$(CONFIG_QCOM_TSENS) += qcom_tsens.o
> -qcom_tsens-y += tsens.o tsens-common.o tsens-v0_1.o
> tsens-8960.o tsens-v2.o
> +
> +qcom_tsens-y += tsens.o tsens-common.o tsens-v0_1.o \
> +tsens-8960.o tsens-v2.o tsens-v1.o
> obj-$(CONFIG_QCOM_SPMI_TEMP_ALARM) += qcom-spmi-temp-alarm.o
> diff --git a/drivers/thermal/qcom/tsens-v1.c b/drivers/thermal/qcom/tsens-v1.c
> new file mode 100644
> index ..417e2c2de1a1
> --- /dev/null
> +++ b/drivers/thermal/qcom/tsens-v1.c
> @@ -0,0 +1,229 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2019, Linaro Limited
> + */
> +
> +#include
> +#include
> +#include
> +#include "tsens.h"
> +
> +/* - SROT -- */
> +#define SROT_HW_VER_OFF 0x
> +#define SROT_CTRL_OFF0x0004
> +
> +/* - TM -- */
> +#define TM_INT_EN_OFF0x
> +#define TM_Sn_UPPER_LOWER_STATUS_CTRL_OFF0x0004
> +#define TM_Sn_STATUS_OFF 0x0044
> +#define TM_TRDY_OFF 0x0084
> +
> +/* eeprom layout data for qcs404/405 (v1) */
> +#define BASE0_MASK 0x07f8
> +#define BASE1_MASK 0x0007f800
> +#define BASE0_SHIFT 3
> +#define BASE1_SHIFT 11
> +
> +#define S0_P1_MASK 0x003f
> +#define S1_P1_MASK 0x0003f000
> +#define S2_P1_MASK 0x3f00
> +#define S3_P1_MASK 0x03f0
> +#define S4_P1_MASK 0x003f
> +#define S5_P1_MASK 0x003f
> +#define S6_P1_MASK 0x0003f000
> +#define S7_P1_MASK 0x3f00
> +#define S8_P1_MASK 0x03f0
> +#define S9_P1_MASK 0x003f
> +
> +#define S0_P2_MASK 0x0fc0
> +#define S1_P2_MASK 0x00fc
> +#define S2_P2_MASK_1_0 0xc000
> +#define S2_P2_MASK_5_2 0x000f
> +#define S3_P2_MASK 0xfc00
> +#define S4_P2_MASK 0x0fc0
> +#define S5_P2_MASK 0x0fc0
> +#define S6_P2_MASK 0x00fc
> +#define S7_P2_MASK_1_0 0xc000
> +#define S7_P2_MASK_5_2 0x000f
> +#define S8_P2_MASK 0xfc00
> +#define S9_P2_MASK 0x0fc0
> +
> +#define S0_P1_SHIFT 0
> +#define S0_P2_SHIFT 6
> +#define S1_P1_SHIFT 12
> +#define S1_P2_SHIFT 18
> +#define S2_P1_SHIFT 24
> +#define S2_P2_SHIFT_1_0 30
> +
> +#define S2_P2_SHIFT_5_2 0
> +#define S3_P1_SHIFT 4
> +#define S3_P2_SHIFT 10
> +#define S4_P1_SHIFT 16
> +#define S4_P2_SHIFT 22
> +
> +#define S5_P1_SHIFT 0
> +#define S5_P2_SHIFT 6
> +#define S6_P1_SHIFT 12
> +#define S6_P2_SHIFT 18
> +#define S7_P1_SHIFT 24
> +#define S7_P2_SHIFT_1_0 30
> +
> +#define S7_P2_SHIFT_5_2 0
> +#define S8_P1_SHIFT 4
> +#define S8_P2_SHIFT 10
> +#define S9_P1_SHIFT 16
> +#define S9_P2_SHIFT 22
> +
> +#define CAL_SEL_MASK 7
Why not using the macros on bits.h?
> +#define CAL_SEL_SHIFT0
> +
> +static int calibrate_v1(struct tsens_priv *priv)
> +{
> + u32 base0 = 0, base1 = 0;
> + u32 p1[10], p2[10];
> + u32 mode = 0, lsb = 0, msb = 0;
> + u32 *qfprom_cdata;
> + int i;
> +
> + qfprom_cdata = (u32 *)qfprom_read(priv->dev, "calib");
> + if (IS_ERR(qfprom_cdata))
> + return PTR_ERR(qfprom_cdata);
> +
> + mode = (qfprom_cdata[4] & CAL_SEL_MASK) >> CAL_SEL_SHIFT;
> + dev_dbg(priv->dev, "calibration mode is %d\n", mode);
> +
> + switch (mode) {
> + case TWO_PT_CALIB:
> + base1 = (qfprom_cdata[4] & BASE1_MASK) >> BASE1_SHIFT;
> + p2[0] = (qfprom_cdata[0] & S0_P2_MASK) >> S0_P2_SHIFT;
> + p2[1] = (qfprom_cdata[0] & S1_P2_MASK) >> S1_P2_SHIFT;
> + /* This value is split over two registers, 2 bits and 4 bits */
> + lsb = (qfprom_cdata[0] & S2_P2_MASK_1_0) >> S2_P2_SHIFT_1_0;
> + msb = (qfprom_cdata[1] & S2_P2_MASK_5_2) >> S2_P2_SHIFT_5_2;
> + p2[2] = msb << 2 | lsb;
> + p2[3] = (qfprom_cdata[1] & S3_P2_MASK) >> S3_P2_SHIFT;
> + p2[4] = (qfprom_cdata[1] & S4_P2_MASK) >> S4_P2_SHIFT;
> + p2[5] = (qfprom_cdata[2] & S5_P2_MASK) >> S5_P2_SHIFT;
> + p2[6] = (qfprom_cdata[2] & S6_P2_MASK) >> S6_P2_SHIFT;
> + /* This value is split over two
Re: [PATCH v1 23/24] arm64: dts: qcom: qcs404: Add thermal zones for each sensor
On Thu, Feb 07, 2019 at 04:19:41PM +0530, Amit Kucheria wrote:
> qcs404 has 10 sensors connected to the single TSENS IP. Define a thermal
> zone for each of those sensors to expose the temperature of each zone.
>
> Signed-off-by: Amit Kucheria
> ---
> arch/arm64/boot/dts/qcom/qcs404.dtsi | 243 +++
> 1 file changed, 243 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> index 57d14d8f0c90..ca99c45864df 100644
> --- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> +++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> @@ -3,6 +3,7 @@
>
> #include
> #include
> +#include
>
> / {
> interrupt-parent = <>;
> @@ -30,6 +31,7 @@
> reg = <0x100>;
> enable-method = "psci";
> next-level-cache = <_0>;
> + #cooling-cells= <2>;
> };
>
> CPU1: cpu@101 {
> @@ -38,6 +40,7 @@
> reg = <0x101>;
> enable-method = "psci";
> next-level-cache = <_0>;
> + #cooling-cells= <2>;
> };
>
> CPU2: cpu@102 {
> @@ -46,6 +49,7 @@
> reg = <0x102>;
> enable-method = "psci";
> next-level-cache = <_0>;
> + #cooling-cells= <2>;
> };
>
> CPU3: cpu@103 {
> @@ -54,6 +58,7 @@
> reg = <0x103>;
> enable-method = "psci";
> next-level-cache = <_0>;
> + #cooling-cells= <2>;
> };
>
> L2_0: l2-cache {
> @@ -507,4 +512,242 @@
> #interrupt-cells = <2>;
> };
> };
> +
> + thermal-zones {
There are several zones with passive trips and no cooling maps.
> + aoss-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = < 0>;
> +
> + trips {
> + aoss_alert0: trip-point@0 {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> + aoss_crit: aoss_crit {
> + temperature = <11>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> +
> + dsp-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = < 1>;
> +
> + trips {
> + dsp_alert0: trip-point@0 {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> + dsp_crit: dsp_crit {
> + temperature = <11>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> +
> + lpass-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = < 2>;
> +
> + trips {
> + lpass_alert0: trip-point@0 {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> + lpass_crit: lpass_crit {
> + temperature = <11>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> +
> + wlan-thermal {
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> +
> + thermal-sensors = < 3>;
> +
> + trips {
> + wlan_alert0: trip-point@0 {
> + temperature = <95000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> + wlan_crit: wlan_crit {
> + temperature =
Re: [PATCH V6 1/4] dt-bindings: fsl: scu: add thermal binding
On Tue, Feb 19, 2019 at 07:20:58AM +, Anson Huang wrote:
> Ping...
I will take a look on this.
>
> Best Regards!
> Anson Huang
>
> > -Original Message-
> > From: Anson Huang
> > Sent: 2019年2月13日 13:36
> > To: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> > s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> > catalin.mari...@arm.com; will.dea...@arm.com; rui.zh...@intel.com;
> > edubez...@gmail.com; daniel.lezc...@linaro.org; Aisheng Dong
> > ; ulf.hans...@linaro.org; Daniel Baluta
> > ; horms+rene...@verge.net.au; Andy Gross
> > ; he...@sntech.de; a...@arndb.de;
> > maxime.rip...@bootlin.com; ja...@amarulasolutions.com;
> > bjorn.anders...@linaro.org; enric.balle...@collabora.com;
> > marc.w.gonza...@free.fr; o...@lixom.net; devicet...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> > p...@vger.kernel.org
> > Cc: dl-linux-imx
> > Subject: RE: [PATCH V6 1/4] dt-bindings: fsl: scu: add thermal binding
> >
> > Gental ping...
> >
> > Best Regards!
> > Anson Huang
> >
> > > -Original Message-
> > > From: Anson Huang
> > > Sent: 2019年2月7日 17:53
> > > To: robh...@kernel.org; mark.rutl...@arm.com; shawn...@kernel.org;
> > > s.ha...@pengutronix.de; ker...@pengutronix.de; feste...@gmail.com;
> > > catalin.mari...@arm.com; will.dea...@arm.com; rui.zh...@intel.com;
> > > edubez...@gmail.com; daniel.lezc...@linaro.org; Aisheng Dong
> > > ; ulf.hans...@linaro.org; Daniel Baluta
> > > ; horms+rene...@verge.net.au; Andy Gross
> > > ; he...@sntech.de; a...@arndb.de;
> > > maxime.rip...@bootlin.com; ja...@amarulasolutions.com;
> > > bjorn.anders...@linaro.org; enric.balle...@collabora.com;
> > > marc.w.gonza...@free.fr; o...@lixom.net; devicet...@vger.kernel.org;
> > > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> > > linux- p...@vger.kernel.org
> > > Cc: dl-linux-imx
> > > Subject: [PATCH V6 1/4] dt-bindings: fsl: scu: add thermal binding
> > >
> > > NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system
> > > controller, the system controller is in charge of system power, clock
> > > and thermal sensors etc. management, Linux kernel has to communicate
> > > with system controller via MU (message unit) IPC to get temperature
> > > from thermal sensors, this patch adds binding doc for i.MX system
> > > controller thermal driver.
> > >
> > > Signed-off-by: Anson Huang
> > > Reviewed-by: Rob Herring
> > > ---
> > > ChangeLog since V5:
> > > - add "imx,sensor-resource-id" in each thermal zone to pass resource
> > > ID for thermal driver.
> > > ---
> > > .../devicetree/bindings/arm/freescale/fsl,scu.txt| 20
> > >
> > > 1 file changed, 20 insertions(+)
> > >
> > > diff --git
> > > a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > > b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > > index 72d481c..4b79751 100644
> > > --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > > +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
> > > @@ -122,6 +122,20 @@ RTC bindings based on SCU Message Protocol
> > > Required properties:
> > > - compatible: should be "fsl,imx8qxp-sc-rtc";
> > >
> > > +Thermal bindings based on SCU Message Protocol
> > > +
> > > +
> > > +Required properties:
> > > +- compatible : Must be "fsl,imx8qxp-sc-thermal";
> > > +- tsens-num : Total number of thermal sensors supported;
> > > +- #thermal-sensor-cells : Should be 1. See
> > > +
> > > Documentation/devicetree/bindings/thermal/thermal.txt
> > > + for a description.
> > > +- imx,sensor-resource-id : This property should be defined in each
> > > +thermal
> > > zone
> > > +of thermal-zones node, it passes each thermal
> > > zone's
> > > +resource id for thermal driver to get temperature
> > > via
> > > +SCU IPC.
> > > +
> > > Example (imx8qxp):
> > > -
> > > lsio_mu1: mailbox@5d1c {
> > > @@ -168,6 +182,12 @@ firmware {
> > > rtc: rtc {
> > > compatible = "fsl,imx8qxp-sc-rtc";
> > > };
> > > +
> > > + tsens: thermal-sensor {
> > > + compatible = "fsl,imx8qxp-sc-thermal";
> > > + tsens-num = <1>;
> > > + #thermal-sensor-cells = <1>;
> > > + };
> > > };
> > > };
> > >
> > > --
> > > 2.7.4
>
Re: [GIT PULL] Thermal-SoC management fixes for v5.0-rc6
Hey,
Thanks for the note, but..
On Sun, Feb 10, 2019 at 04:25:16AM +, pr-tracker-...@kernel.org wrote:
> The pull request you sent on Sat, 9 Feb 2019 20:17:23 -0800:
>
> > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal
> > fixes
>
> has been merged into torvalds/linux.git:
> https://git.kernel.org/torvalds/c/7ad915f5ebf5b9e7ca98a7048d8f84a631fe388b
I think the bot is off here because the above commit is about a merge
from the linux-omap tree from Tony.
7ad915f5ebf5 ("Merge tag 'omap-for-v3.10-rc1/fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes")
not the above pull. In fact, this pull was not merged so far, as per the log
of v5.0-rc6. I mean, this is a very late fixes pull anyways and I can always
resend the pull, but I believe the bot got confused this time.
>
> Thank you!
>
> --
> Deet-doot-dot, I am a bot.
> https://korg.wiki.kernel.org/userdoc/prtracker
[GIT PULL] Thermal-SoC management fixes for v5.0-rc6
Hello Linus, Please consider pulling from git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes to receive Thermal-SoC Management fixes for v5.0-rc6 with top-most bf78f133cd39e0ed41551150909e41513958a738: thermal: cpu_cooling: Clarify error message (2019-02-05 15:50:13 -0800) on top of commit 8834f5600cf3c8db365e18a3d5cac2c2780c81e5: Linux 5.0-rc5 (2019-02-03 13:48:04 -0800) Specifics: - Minor fixes on of-thermal and cpu cooling. BR, Eduardo Amit Kucheria (2): thermal: of-thermal: Print name of device node with error thermal: cpu_cooling: Clarify error message drivers/thermal/cpu_cooling.c | 2 +- drivers/thermal/of-thermal.c | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
Re: [PATCH 4/7] thermal: mediatek: add thermal controller offset
On Fri, Feb 01, 2019 at 03:38:10PM +0800, michael@mediatek.com wrote:
> From: Michael Kao
>
> One thermal controller can read four sensors at most,
> so we need to add controller_offset for the project with
> more than four sensors to reuse the same register settings.
>
> Signed-off-by: Michael Kao
> ---
> drivers/thermal/mtk_thermal.c | 79
> +--
> 1 file changed, 54 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> index 45c6587..e5cf3f4 100644
> --- a/drivers/thermal/mtk_thermal.c
> +++ b/drivers/thermal/mtk_thermal.c
> @@ -105,6 +105,9 @@
> /* The number of sensing points per bank */
> #define MT8173_NUM_SENSORS_PER_ZONE 4
>
> +/* The number of controller in the MT8173 */
> +#define MT8173_NUM_CONTROLLER1
> +
> /* The calibration coefficient of sensor */
> #define MT8173_CALIBRATION 165
>
> @@ -150,6 +153,9 @@ enum {
> /* The number of sensing points per bank */
> #define MT2701_NUM_SENSORS_PER_ZONE 3
>
> +/* The number of controller in the MT2701 */
> +#define MT2701_NUM_CONTROLLER1
> +
> /* The calibration coefficient of sensor */
> #define MT2701_CALIBRATION 165
>
> @@ -168,6 +174,9 @@ enum {
> /* The number of sensing points per bank */
> #define MT2712_NUM_SENSORS_PER_ZONE 4
>
> +/* The number of controller in the MT2712 */
> +#define MT2712_NUM_CONTROLLER1
> +
> /* The calibration coefficient of sensor */
> #define MT2712_CALIBRATION 165
>
> @@ -176,6 +185,7 @@ enum {
> #define MT7622_NUM_ZONES 1
> #define MT7622_NUM_SENSORS_PER_ZONE 1
> #define MT7622_TS1 0
> +#define MT7622_NUM_CONTROLLER1
>
> /* The calibration coefficient of sensor */
> #define MT7622_CALIBRATION 165
> @@ -201,6 +211,8 @@ struct mtk_thermal_data {
> const int *msr;
> const int *adcpnp;
> const int cali_val;
> + const int num_controller;
> + const int *controller_offset;
> struct thermal_bank_cfg bank_data[];
> };
>
> @@ -240,6 +252,7 @@ struct mtk_thermal {
> };
>
> static const int mt8173_mux_values[MT8173_NUM_SENSORS] = { 0, 1, 2, 3, 16 };
> +static const int mt8173_tc_offset[MT8173_NUM_CONTROLLER] = { 0x0, };
>
> static const int mt8173_vts_index[MT8173_NUM_SENSORS] = {
> VTS1, VTS2, VTS3, VTS4, VTSABB
> @@ -259,6 +272,7 @@ struct mtk_thermal {
> };
>
> static const int mt2701_mux_values[MT2701_NUM_SENSORS] = { 0, 1, 16 };
> +static const int mt2701_tc_offset[MT2701_NUM_CONTROLLER] = { 0x0, };
>
> static const int mt2701_vts_index[MT2701_NUM_SENSORS] = {
> VTS1, VTS2, VTS3
> @@ -278,6 +292,7 @@ struct mtk_thermal {
> };
>
> static const int mt2712_mux_values[MT2712_NUM_SENSORS] = { 0, 1, 2, 3 };
> +static const int mt2712_tc_offset[MT2712_NUM_CONTROLLER] = { 0x0, };
>
> static const int mt2712_vts_index[MT2712_NUM_SENSORS] = {
> VTS1, VTS2, VTS3, VTS4
> @@ -289,6 +304,7 @@ struct mtk_thermal {
> static const int mt7622_adcpnp[MT7622_NUM_SENSORS_PER_ZONE] = {
> TEMP_ADCPNP0, };
> static const int mt7622_mux_values[MT7622_NUM_SENSORS] = { 0, };
> static const int mt7622_vts_index[MT7622_NUM_SENSORS] = { VTS1 };
> +static const int mt7622_tc_offset[MT7622_NUM_CONTROLLER] = { 0x0, };
>
> /**
> * The MT8173 thermal controller has four banks. Each bank can read up to
> @@ -309,6 +325,8 @@ struct mtk_thermal {
> .num_sensors = MT8173_NUM_SENSORS,
> .vts_index = mt8173_vts_index,
> .cali_val = MT8173_CALIBRATION,
> + .num_controller = MT8173_NUM_CONTROLLER,
> + .controller_offset = mt8173_tc_offset,
> .bank_data = {
> {
> .num_sensors = 2,
> @@ -345,6 +363,8 @@ struct mtk_thermal {
> .num_sensors = MT2701_NUM_SENSORS,
> .vts_index = mt2701_vts_index,
> .cali_val = MT2701_CALIBRATION,
> + .num_controller = MT2701_NUM_CONTROLLER,
> + .controller_offset = mt2701_tc_offset,
> .bank_data = {
> {
> .num_sensors = 3,
> @@ -372,6 +392,8 @@ struct mtk_thermal {
> .num_sensors = MT2712_NUM_SENSORS,
> .vts_index = mt2712_vts_index,
> .cali_val = MT2712_CALIBRATION,
> + .num_controller = MT2712_NUM_CONTROLLER,
> + .controller_offset = mt2712_tc_offset,
> .bank_data = {
> {
> .num_sensors = 4,
> @@ -393,6 +415,8 @@ struct mtk_thermal {
> .num_sensors = MT7622_NUM_SENSORS,
> .vts_index = mt7622_vts_index,
> .cali_val = MT7622_CALIBRATION,
> + .num_controller = MT7622_NUM_CONTROLLER,
> + .controller_offset = mt7622_tc_offset,
> .bank_data = {
> {
> .num_sensors = 1,
> @@ -523,19 +547,23 @@ static int mtk_read_temp(void *data, int *temperature)
> };
>
> static void mtk_thermal_init_bank(struct mtk_thermal *mt, int num,
> - u32
Re: [PATCH 3/7] thermal: mediatek: add calibration item
On Mon, Feb 04, 2019 at 06:31:41PM +0100, Matthias Brugger wrote:
>
>
> On 01/02/2019 08:38, michael@mediatek.com wrote:
> > From: Michael Kao
> >
> > Add calibration item in thermal_data to support
> > the project with different calibration coefficient.
> >
> > Signed-off-by: Michael Kao
> > ---
> > drivers/thermal/mtk_thermal.c | 19 ++-
> > 1 file changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/thermal/mtk_thermal.c b/drivers/thermal/mtk_thermal.c
> > index 07f8ad7..45c6587 100644
> > --- a/drivers/thermal/mtk_thermal.c
> > +++ b/drivers/thermal/mtk_thermal.c
> > @@ -105,6 +105,9 @@
> > /* The number of sensing points per bank */
> > #define MT8173_NUM_SENSORS_PER_ZONE4
> >
> > +/* The calibration coefficient of sensor */
> > +#define MT8173_CALIBRATION 165
> > +
>
> Calibration value is the same for all SoCs (including mt8183), we can define
> it
> once and use it in all mtk_thermal structs.
Well, on patch 7 we have:
+#define MT8183_CALIBRATION 153
>
> Regards,
> Matthias
>
>
> > /*
> > * Layout of the fuses providing the calibration data
> > * These macros could be used for MT8173, MT2701, and MT2712.
> > @@ -147,6 +150,9 @@ enum {
> > /* The number of sensing points per bank */
> > #define MT2701_NUM_SENSORS_PER_ZONE3
> >
> > +/* The calibration coefficient of sensor */
> > +#define MT2701_CALIBRATION 165
> > +
> > /* MT2712 thermal sensors */
> > #define MT2712_TS1 0
> > #define MT2712_TS2 1
> > @@ -162,12 +168,18 @@ enum {
> > /* The number of sensing points per bank */
> > #define MT2712_NUM_SENSORS_PER_ZONE4
> >
> > +/* The calibration coefficient of sensor */
> > +#define MT2712_CALIBRATION 165
> > +
> > #define MT7622_TEMP_AUXADC_CHANNEL 11
> > #define MT7622_NUM_SENSORS 1
> > #define MT7622_NUM_ZONES 1
> > #define MT7622_NUM_SENSORS_PER_ZONE1
> > #define MT7622_TS1 0
> >
> > +/* The calibration coefficient of sensor */
> > +#define MT7622_CALIBRATION 165
> > +
> > struct mtk_thermal;
> >
> > struct thermal_bank_cfg {
> > @@ -188,6 +200,7 @@ struct mtk_thermal_data {
> > const int *sensor_mux_values;
> > const int *msr;
> > const int *adcpnp;
> > + const int cali_val;
> > struct thermal_bank_cfg bank_data[];
> > };
> >
> > @@ -295,6 +308,7 @@ struct mtk_thermal {
> > .num_banks = MT8173_NUM_ZONES,
> > .num_sensors = MT8173_NUM_SENSORS,
> > .vts_index = mt8173_vts_index,
> > + .cali_val = MT8173_CALIBRATION,
> > .bank_data = {
> > {
> > .num_sensors = 2,
> > @@ -330,6 +344,7 @@ struct mtk_thermal {
> > .num_banks = 1,
> > .num_sensors = MT2701_NUM_SENSORS,
> > .vts_index = mt2701_vts_index,
> > + .cali_val = MT2701_CALIBRATION,
> > .bank_data = {
> > {
> > .num_sensors = 3,
> > @@ -356,6 +371,7 @@ struct mtk_thermal {
> > .num_banks = 1,
> > .num_sensors = MT2712_NUM_SENSORS,
> > .vts_index = mt2712_vts_index,
> > + .cali_val = MT2712_CALIBRATION,
> > .bank_data = {
> > {
> > .num_sensors = 4,
> > @@ -376,6 +392,7 @@ struct mtk_thermal {
> > .num_banks = MT7622_NUM_ZONES,
> > .num_sensors = MT7622_NUM_SENSORS,
> > .vts_index = mt7622_vts_index,
> > + .cali_val = MT7622_CALIBRATION,
> > .bank_data = {
> > {
> > .num_sensors = 1,
> > @@ -402,7 +419,7 @@ static int raw_to_mcelsius(struct mtk_thermal *mt, int
> > sensno, s32 raw)
> > raw &= 0xfff;
> >
> > tmp = 203450520 << 3;
> > - tmp /= 165 + mt->o_slope;
> > + tmp /= mt->conf->cali_val + mt->o_slope;
> > tmp /= 1 + mt->adc_ge;
> > tmp *= raw - mt->vts[sensno] - 3350;
> > tmp >>= 3;
> >
Re: [PATCH v3 1/1] arm64: dts: sdm845: wireup the thermal trip points to cpufreq
On Mon, Jan 21, 2019 at 11:38:34PM +0530, Amit Kucheria wrote:
> Since all cpus in the big and little clusters, respectively, are in the
> same frequency domain, use all of them for mitigation in the
> cooling-map. We end up with two cooling devices - one each for the big
> and little clusters.
>
> We throttle lightly at the first trip point, just removing the boost
> frequency. At the next trip point we allow ourselves to be throttled to
> any extent.
>
>From OF thermal descriptor, this patch looks fine to me:
Acked-by: Eduardo Valentin
> Signed-off-by: Amit Kucheria
> ---
> arch/arm64/boot/dts/qcom/sdm845.dtsi | 225 +--
> 1 file changed, 209 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index c27cbd3bcb0a..878f661d16eb 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
>
> / {
> interrupt-parent = <>;
> @@ -99,6 +100,7 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x0>;
> enable-method = "psci";
> + #cooling-cells = <2>;
> next-level-cache = <_0>;
> L2_0: l2-cache {
> compatible = "cache";
> @@ -114,6 +116,7 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x100>;
> enable-method = "psci";
> + #cooling-cells = <2>;
> next-level-cache = <_100>;
> L2_100: l2-cache {
> compatible = "cache";
> @@ -126,6 +129,7 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x200>;
> enable-method = "psci";
> + #cooling-cells = <2>;
> next-level-cache = <_200>;
> L2_200: l2-cache {
> compatible = "cache";
> @@ -138,6 +142,7 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x300>;
> enable-method = "psci";
> + #cooling-cells = <2>;
> next-level-cache = <_300>;
> L2_300: l2-cache {
> compatible = "cache";
> @@ -150,6 +155,7 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x400>;
> enable-method = "psci";
> + #cooling-cells = <2>;
> next-level-cache = <_400>;
> L2_400: l2-cache {
> compatible = "cache";
> @@ -162,6 +168,7 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x500>;
> enable-method = "psci";
> + #cooling-cells = <2>;
> next-level-cache = <_500>;
> L2_500: l2-cache {
> compatible = "cache";
> @@ -174,6 +181,7 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x600>;
> enable-method = "psci";
> + #cooling-cells = <2>;
> next-level-cache = <_600>;
> L2_600: l2-cache {
> compatible = "cache";
> @@ -186,6 +194,7 @@
> compatible = "qcom,kryo385";
> reg = <0x0 0x700>;
> enable-method = "psci";
> + #cooling-cells = <2>;
> next-level-cache = <_700>;
> L2_700: l2-cache {
> compatible = "cache";
> @@ -1691,18 +1700,41 @@
> thermal-sensors = < 1>;
>
> trips {
> - cpu_alert0: trip0 {
> + cpu0_alert1: trip-point@0 {
> temperature = <75000>;
>
Re: [PATCH v6 0/3] Stingray thermal driver support
Hello, On Mon, Feb 04, 2019 at 04:16:19PM -0800, Ray Jui wrote: > Hi Zhang/Eduardo, > > Can this patch series be merged? It looks like Srinath has addressed all > review comments? I will take a look. Side note, thermal patches are reviewed on linux...@vger.kernel.org. Copying that list it does help because that is how the patches get assigned in patchwork.kernel.org. > > The following tag should be added to the binding document patch: > > Reviewed-by: Rob Herring > > Thanks, > > Ray > > On 1/3/2019 12:55 AM, Srinath Mannam wrote: > > These patches adds the stingray thermal driver and its > > corresponding DT nodes with documentation. > > > > Changes from v5 > > - Addressed Eduardo Valentin comments. > > > > Changes from v4 > > - Addressed Rob Herring comments on DT parameters and > > thermal driver architecture. > > - Removed brcm,max-crit-temp DT parameter > > - Changed driver to thermal sensor registration model. > > - Added trip DT properties. > > > > Changes from v3 > > - Addressed Daniel lezcano comments. > > - Elaborated commit description of thermal driver patch. > > - Added brcm,max-crit-temp DT parameter. > > > > Changes from v2: > > - All stingray TMON DT nodes are combine together into single. > > Temperature registers are combined into one mem resource. > > brcm,tmon-mask parameter has available TMONs mask value. > > - All available TMONs are initialized together in single > > instance of driver probe call. > > > > Changes from v1: > > - Fixed auto build sparce warning. > > > > Pramod Kumar (3): > > dt-bindings: thermal: Add binding document for SR thermal > > thermal: broadcom: Add Stingray thermal driver > > arm64: dts: stingray: Add Stingray Thermal DT support. > > > > .../bindings/thermal/brcm,sr-thermal.txt | 105 ++ > > .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 89 +++ > > drivers/thermal/Kconfig| 3 +- > > drivers/thermal/broadcom/Kconfig | 9 ++ > > drivers/thermal/broadcom/Makefile | 1 + > > drivers/thermal/broadcom/sr-thermal.c | 122 > > + > > 6 files changed, 328 insertions(+), 1 deletion(-) > > create mode 100644 > > Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt > > create mode 100644 drivers/thermal/broadcom/sr-thermal.c > >
Re: [PATCH v1 0/2] thermal: trivial fixes to error messages
On Mon, Jan 21, 2019 at 03:12:21PM +0530, Amit Kucheria wrote: > Fix up a couple of error messages > > Amit Kucheria (2): > thermal: of-thermal: Print name of device node with error > thermal: cpu_cooling: Clarify error message > > drivers/thermal/cpu_cooling.c | 2 +- > drivers/thermal/of-thermal.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) Collecting these. > > -- > 2.17.1
Re: [PATCH V5 2/4] thermal: imx_sc: add i.MX system controller thermal support
On Tue, Jan 22, 2019 at 06:54:30AM +, Anson Huang wrote: > Hi, Eduardo > > Best Regards! > Anson Huang > > > -Original Message- > > From: Anson Huang > > Sent: 2019年1月10日 17:28 > > To: 'Eduardo Valentin' > > Cc: 'robh...@kernel.org' ; 'mark.rutl...@arm.com' > > ; 'catalin.mari...@arm.com' > > ; 'will.dea...@arm.com' > > ; 'rui.zh...@intel.com' ; > > 'daniel.lezc...@linaro.org' ; Aisheng Dong > > ; 's.ha...@pengutronix.de' > > ; 'shawn...@kernel.org' ; > > Andy Gross ; 'a...@arndb.de' ; > > 'horms+rene...@verge.net.au' ; > > 'he...@sntech.de' ; 'bjorn.anders...@linaro.org' > > ; 'enric.balle...@collabora.com' > > ; 'amit.kuche...@linaro.org' > > ; 'ezequ...@collabora.com' > > ; 'o...@lixom.net' ; > > 'devicet...@vger.kernel.org' ; > > 'linux-kernel@vger.kernel.org' ; > > 'linux-arm-ker...@lists.infradead.org' > > ; > > 'linux...@vger.kernel.org' ; dl-linux-imx > > > > Subject: RE: [PATCH V5 2/4] thermal: imx_sc: add i.MX system controller > > thermal support > > > > Hi, Eduardo > > > > Best Regards! > > Anson Huang > > > > > -Original Message- > > > From: Anson Huang > > > Sent: 2018年12月26日 11:36 > > > To: 'Eduardo Valentin' > > > Cc: robh...@kernel.org; mark.rutl...@arm.com; > > catalin.mari...@arm.com; > > > will.dea...@arm.com; rui.zh...@intel.com; daniel.lezc...@linaro.org; > > > Aisheng Dong ; s.ha...@pengutronix.de; > > > shawn...@kernel.org; Andy Gross ; > > > a...@arndb.de; > > > horms+rene...@verge.net.au; he...@sntech.de; > > > horms+bjorn.anders...@linaro.org; > > > enric.balle...@collabora.com; amit.kuche...@linaro.org; > > > ezequ...@collabora.com; o...@lixom.net; devicet...@vger.kernel.org; > > > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > > > linux...@vger.kernel.org; dl-linux-imx > > > Subject: RE: [PATCH V5 2/4] thermal: imx_sc: add i.MX system > > > controller thermal support > > > > > > Hi, Eduardo > > > > > > Best Regards! > > > Anson Huang > > > > > > > -Original Message- > > > > From: Eduardo Valentin [mailto:edubez...@gmail.com] > > > > Sent: 2018年12月26日 6:44 > > > > To: Anson Huang > > > > Cc: robh...@kernel.org; mark.rutl...@arm.com; > > > catalin.mari...@arm.com; > > > > will.dea...@arm.com; rui.zh...@intel.com; daniel.lezc...@linaro.org; > > > > Aisheng Dong ; s.ha...@pengutronix.de; > > > > shawn...@kernel.org; Andy Gross ; > > > > a...@arndb.de; > > > > horms+rene...@verge.net.au; he...@sntech.de; > > > > horms+bjorn.anders...@linaro.org; > > > > enric.balle...@collabora.com; amit.kuche...@linaro.org; > > > > ezequ...@collabora.com; o...@lixom.net; devicet...@vger.kernel.org; > > > > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > > > > linux...@vger.kernel.org; dl-linux-imx > > > > Subject: Re: [PATCH V5 2/4] thermal: imx_sc: add i.MX system > > > > controller thermal support > > > > > > > > On Thu, Dec 20, 2018 at 09:08:32AM +, Anson Huang wrote: > > > > > i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller > > > > > inside, the system controller is in charge of controlling power, > > > > > clock and thermal sensors etc.. > > > > > > > > > > This patch adds i.MX system controller thermal driver support, > > > > > Linux kernel has to communicate with system controller via MU > > > > > (message > > > > > unit) IPC to get each thermal sensor's temperature, it supports > > > > > multiple sensors which are passed from device tree, please see the > > > > > binding doc for details. > > > > > > > > > > Signed-off-by: Anson Huang > > > > > --- > > > > > ChangeLog since V4: > > > > > - Add driver dependency on IMX_SCU to avoid compile error when > > > > IMX_SCU is NOT selected; > > > > > - Remove unnecessary of different errors handle for > > > > imx_scu_get_handle, already included in API. > > > > > --- > > > > > drivers/thermal/Kconfig | 11 +++ > > > > > drivers/thermal/Makefile | 1 + > > > > > drivers/thermal/imx_sc_thermal.c | 200 > > > > >
Re: [PATCH V5 2/4] thermal: imx_sc: add i.MX system controller thermal support
On Tue, Jan 22, 2019 at 06:54:30AM +, Anson Huang wrote: > Hi, Eduardo > > Best Regards! > Anson Huang Taking a look > > > -Original Message- > > From: Anson Huang > > Sent: 2019年1月10日 17:28 > > To: 'Eduardo Valentin' > > Cc: 'robh...@kernel.org' ; 'mark.rutl...@arm.com' > > ; 'catalin.mari...@arm.com' > > ; 'will.dea...@arm.com' > > ; 'rui.zh...@intel.com' ; > > 'daniel.lezc...@linaro.org' ; Aisheng Dong > > ; 's.ha...@pengutronix.de' > > ; 'shawn...@kernel.org' ; > > Andy Gross ; 'a...@arndb.de' ; > > 'horms+rene...@verge.net.au' ; > > 'he...@sntech.de' ; 'bjorn.anders...@linaro.org' > > ; 'enric.balle...@collabora.com' > > ; 'amit.kuche...@linaro.org' > > ; 'ezequ...@collabora.com' > > ; 'o...@lixom.net' ; > > 'devicet...@vger.kernel.org' ; > > 'linux-kernel@vger.kernel.org' ; > > 'linux-arm-ker...@lists.infradead.org' > > ; > > 'linux...@vger.kernel.org' ; dl-linux-imx > > > > Subject: RE: [PATCH V5 2/4] thermal: imx_sc: add i.MX system controller > > thermal support > > > > Hi, Eduardo > > > > Best Regards! > > Anson Huang > > > > > -Original Message- > > > From: Anson Huang > > > Sent: 2018年12月26日 11:36 > > > To: 'Eduardo Valentin' > > > Cc: robh...@kernel.org; mark.rutl...@arm.com; > > catalin.mari...@arm.com; > > > will.dea...@arm.com; rui.zh...@intel.com; daniel.lezc...@linaro.org; > > > Aisheng Dong ; s.ha...@pengutronix.de; > > > shawn...@kernel.org; Andy Gross ; > > > a...@arndb.de; > > > horms+rene...@verge.net.au; he...@sntech.de; > > > horms+bjorn.anders...@linaro.org; > > > enric.balle...@collabora.com; amit.kuche...@linaro.org; > > > ezequ...@collabora.com; o...@lixom.net; devicet...@vger.kernel.org; > > > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > > > linux...@vger.kernel.org; dl-linux-imx > > > Subject: RE: [PATCH V5 2/4] thermal: imx_sc: add i.MX system > > > controller thermal support > > > > > > Hi, Eduardo > > > > > > Best Regards! > > > Anson Huang > > > > > > > -Original Message- > > > > From: Eduardo Valentin [mailto:edubez...@gmail.com] > > > > Sent: 2018年12月26日 6:44 > > > > To: Anson Huang > > > > Cc: robh...@kernel.org; mark.rutl...@arm.com; > > > catalin.mari...@arm.com; > > > > will.dea...@arm.com; rui.zh...@intel.com; daniel.lezc...@linaro.org; > > > > Aisheng Dong ; s.ha...@pengutronix.de; > > > > shawn...@kernel.org; Andy Gross ; > > > > a...@arndb.de; > > > > horms+rene...@verge.net.au; he...@sntech.de; > > > > horms+bjorn.anders...@linaro.org; > > > > enric.balle...@collabora.com; amit.kuche...@linaro.org; > > > > ezequ...@collabora.com; o...@lixom.net; devicet...@vger.kernel.org; > > > > linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org; > > > > linux...@vger.kernel.org; dl-linux-imx > > > > Subject: Re: [PATCH V5 2/4] thermal: imx_sc: add i.MX system > > > > controller thermal support > > > > > > > > On Thu, Dec 20, 2018 at 09:08:32AM +, Anson Huang wrote: > > > > > i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller > > > > > inside, the system controller is in charge of controlling power, > > > > > clock and thermal sensors etc.. > > > > > > > > > > This patch adds i.MX system controller thermal driver support, > > > > > Linux kernel has to communicate with system controller via MU > > > > > (message > > > > > unit) IPC to get each thermal sensor's temperature, it supports > > > > > multiple sensors which are passed from device tree, please see the > > > > > binding doc for details. > > > > > > > > > > Signed-off-by: Anson Huang > > > > > --- > > > > > ChangeLog since V4: > > > > > - Add driver dependency on IMX_SCU to avoid compile error when > > > > IMX_SCU is NOT selected; > > > > > - Remove unnecessary of different errors handle for > > > > imx_scu_get_handle, already included in API. > > > > > --- > > > > > drivers/thermal/Kconfig | 11 +++ > > > > > drivers/thermal/Makefile | 1 + > > > > > drivers/thermal/imx_sc_thermal.c | 200 > > > > >
[GIT PULL v2] Thermal-SoC management updates for v4.21-rc1
Hello Linus, Please consider pulling from git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal linus to receive Thermal-SoC Management updates for v4.21-rc1 with top-most 9d216211fded20fff301d0317af3238d8383634c: thermal: generic-adc: Fix adc to temp interpolation (2019-01-02 04:47:23 -0800) on top of commit 0072a0c14d5b7cb72c611d396f143f5dcd73ebe2: Merge tag 'media/v4.20-4' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media (2018-12-03 11:29:20 -0800) Specifics: - Tegra DT binding documentation for Tegra194 - Armada now supports ap806 and cp110 - RCAR thermal now supports R8A774C0 and R8A77990 - Fixes on thermal_hwmon, IMX, generic-ADC, ST, RCAR, Broadcom, Uniphier, QCOM, Tegra, PowerClamp, and Armada thermal drivers. CI: Full Boot Summary: https://kernelci.org/boot/all/job/evalenti/branch/for-kernelci/kernel/v4.20-rc5-43-g9d216211fded/ Full Build Summary: https://kernelci.org/build/evalenti/branch/for-kernelci/kernel/v4.20-rc5-43-g9d216211fded/ Also, made sure to not add new warnings on make allmodconfig, allyesconfig, allnoconfig (including x86 as well). BR, Anson Huang (2): thermal: imx: fix for dependency on cpu-freq thermal: imx: save one condition block for normal case of nvmem initialization Arnd Bergmann (1): thermal: st: fix Makefile typo Bjorn Andersson (1): thermal: generic-adc: Fix adc to temp interpolation Eduardo Valentin (1): thermal: hwmon: inline helpers when CONFIG_THERMAL_HWMON is not set Fabrizio Castro (2): dt-bindings: thermal: rcar-thermal: add R8A774C0 support thermal: rcar_thermal: add R8A774C0 support Geert Uytterhoeven (1): dt-bindings: thermal: rcar-gen3-thermal: All variants use 3 interrupts Julia Lawall (1): thermal: broadcom: use devm_thermal_zone_of_sensor_register Kunihiko Hayashi (1): thermal: uniphier: Convert to SPDX identifier Matthias Brugger (1): thermal: bcm2835: enable hwmon explicitly Miquel Raynal (4): thermal: armada: add overheat interrupt support MAINTAINERS: thermal: add entry for Marvell MVEBU thermal driver dt-bindings: ap806: document the thermal interrupt capabilities dt-bindings: cp110: document the thermal interrupt capabilities Srinivas Kandagatla (1): thermal: tsens: qcom: do not create duplicate regmap debugfs entries Thierry Reding (1): dt-bindings: thermal: tegra-bpmp: Add Tegra194 support Yangtao Li (2): thermal: tegra: soctherm: Change to use DEFINE_SHOW_ATTRIBUTE macro thermal/intel_powerclamp: Change to use DEFINE_SHOW_ATTRIBUTE macro Yoshihiro Kaneko (2): dt-bindings: thermal: rcar-thermal: add R8A77990 support thermal: rcar_thermal: add R8A77990 support YueHaibing (1): thermal: armada: Use PTR_ERR_OR_ZERO in armada_thermal_probe_legacy() .../arm/marvell/ap806-system-controller.txt| 7 + .../arm/marvell/cp110-system-controller.txt| 9 + .../thermal/nvidia,tegra186-bpmp-thermal.txt | 3 +- .../bindings/thermal/rcar-gen3-thermal.txt | 3 +- .../devicetree/bindings/thermal/rcar-thermal.txt | 6 +- MAINTAINERS| 5 + drivers/thermal/Kconfig| 2 +- drivers/thermal/armada_thermal.c | 280 - drivers/thermal/broadcom/bcm2835_thermal.c | 11 + drivers/thermal/broadcom/brcmstb_thermal.c | 24 +- drivers/thermal/imx_thermal.c | 52 ++-- drivers/thermal/intel_powerclamp.c | 14 +- drivers/thermal/qcom/tsens-common.c| 12 +- drivers/thermal/rcar_thermal.c | 8 + drivers/thermal/st/Makefile| 2 +- drivers/thermal/tegra/soctherm.c | 12 +- drivers/thermal/thermal-generic-adc.c | 12 +- drivers/thermal/thermal_hwmon.h| 4 +- drivers/thermal/uniphier_thermal.c | 13 +- .../dt-bindings/thermal/tegra194-bpmp-thermal.h| 15 ++ 20 files changed, 400 insertions(+), 94 deletions(-) create mode 100644 include/dt-bindings/thermal/tegra194-bpmp-thermal.h
Re: [PATCH v5 2/3] thermal: broadcom: Add Stingray thermal driver
On Tue, Oct 16, 2018 at 08:41:19PM +0530, Srinath Mannam wrote:
> From: Pramod Kumar
>
> Stingray SoC has six temperature sensor and those are
> configured, controlled and accessed to read temperature
> and update in DDR memory using m0 firmware.
> All six sensors has been given 4 bytes of memory in DDR
> to write temperature in millivolts.
>
> This thermal driver read temperature values from DDR
> because no direct access to sensors.
> Like this all temparature sensors are monitored and
> trips at critical temperature.
>
> If driver can't handle thermal runaways because of
> any unknown reason, then firmware in m0 Processor
> will handle.
>
> Signed-off-by: Pramod Kumar
> Signed-off-by: Srinath Mannam
> Reviewed-by: Ray Jui
> Reviewed-by: Scott Branden
> Reviewed-by: Vikram Prakash
> ---
> drivers/thermal/Kconfig | 3 +-
> drivers/thermal/broadcom/Kconfig | 9 +++
> drivers/thermal/broadcom/Makefile | 1 +
> drivers/thermal/broadcom/sr-thermal.c | 138
> ++
> 4 files changed, 150 insertions(+), 1 deletion(-)
> create mode 100644 drivers/thermal/broadcom/sr-thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 0e69edc..5f9f070 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -416,7 +416,8 @@ config MTK_THERMAL
> controller present in Mediatek SoCs
>
> menu "Broadcom thermal drivers"
> -depends on ARCH_BCM || ARCH_BRCMSTB || ARCH_BCM2835 || COMPILE_TEST
> +depends on ARCH_BCM || ARCH_BRCMSTB || ARCH_BCM2835 || ARCH_BCM_IPROC || \
> + COMPILE_TEST
> source "drivers/thermal/broadcom/Kconfig"
> endmenu
>
> diff --git a/drivers/thermal/broadcom/Kconfig
> b/drivers/thermal/broadcom/Kconfig
> index c106a15..dc9a9bd 100644
> --- a/drivers/thermal/broadcom/Kconfig
> +++ b/drivers/thermal/broadcom/Kconfig
> @@ -22,3 +22,12 @@ config BCM_NS_THERMAL
> BCM4708, BCM4709, BCM5301x, BCM95852X, etc). It contains DMU (Device
> Management Unit) block with a thermal sensor that allows checking CPU
> temperature.
> +
> +config BCM_SR_THERMAL
> + tristate "Stingray thermal driver"
> + depends on ARCH_BCM_IPROC || COMPILE_TEST
> + default ARCH_BCM_IPROC
> + help
> + Support for the Stingray family of SoCs. Its different blocks like
> + iHost, CRMU and NITRO has thermal sensor that allows checking its
> + temperature.
> diff --git a/drivers/thermal/broadcom/Makefile
> b/drivers/thermal/broadcom/Makefile
> index fae10ec..79df69e 100644
> --- a/drivers/thermal/broadcom/Makefile
> +++ b/drivers/thermal/broadcom/Makefile
> @@ -1,3 +1,4 @@
> obj-$(CONFIG_BCM2835_THERMAL)+= bcm2835_thermal.o
> obj-$(CONFIG_BRCMSTB_THERMAL)+= brcmstb_thermal.o
> obj-$(CONFIG_BCM_NS_THERMAL) += ns-thermal.o
> +obj-$(CONFIG_BCM_SR_THERMAL) += sr-thermal.o
> diff --git a/drivers/thermal/broadcom/sr-thermal.c
> b/drivers/thermal/broadcom/sr-thermal.c
> new file mode 100644
> index 000..f45e12e
> --- /dev/null
> +++ b/drivers/thermal/broadcom/sr-thermal.c
> @@ -0,0 +1,138 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2018 Broadcom
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/*
> + * In stingray thermal IO memory,
> + * Total Number of available TMONs MASK is at offset 0
> + * temperature registers BASE is at 4 byte offset.
> + * Each TMON temperature register size is 4.
> + */
> +#define SR_TMON_TEMP_BASE(id) ((id) * 0x4)
> +
> +#define SR_TMON_MAX_LIST6
> +
> +struct sr_tmon {
> + struct thermal_zone_device *tz;
> + unsigned int crit_temp;
> + unsigned int tmon_id;
> + struct sr_thermal *priv;
> +};
> +
> +struct sr_thermal {
> + void __iomem *regs;
> + unsigned int max_crit_temp;
> + struct sr_tmon tmon[SR_TMON_MAX_LIST];
> +};
> +
> +static int sr_get_temp(void *data, int *temp)
> +{
> + struct sr_tmon *tmon = data;
> + struct sr_thermal *sr_thermal = tmon->priv;
> +
> + *temp = readl(sr_thermal->regs + SR_TMON_TEMP_BASE(tmon->tmon_id));
> +
> + return 0;
> +}
> +
> +static const struct thermal_zone_of_device_ops sr_tz_ops = {
> + .get_temp = sr_get_temp,
> +};
> +
> +static int sr_thermal_probe(struct platform_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct sr_thermal *sr_thermal;
> + struct sr_tmon *tmon;
> + struct resource *res;
> + uint32_t sr_tmon_list = 0;
> + unsigned int i;
> + int ret;
> +
> + sr_thermal = devm_kzalloc(dev, sizeof(*sr_thermal), GFP_KERNEL);
> + if (!sr_thermal)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + sr_thermal->regs = (void __iomem *)devm_memremap(>dev, res->start,
> + resource_size(res),
> + MEMREMAP_WB);
> + if
Re: [PATCH v2 2/2] mmc: sdhci-omap: Workaround errata regarding SDR104/HS200 tuning failures (i929)
On Wed, Jan 02, 2019 at 10:29:31AM -0800, Olof Johansson wrote:
> Hi,
>
>
> On Wed, Dec 12, 2018 at 1:20 AM Ulf Hansson wrote:
> >
> > + Thermal maintainers
> >
> > On Tue, 11 Dec 2018 at 15:20, Faiz Abbas wrote:
> > >
> > > Errata i929 in certain OMAP5/DRA7XX/AM57XX silicon revisions
> > > (SPRZ426D - November 2014 - Revised February 2018 [1]) mentions
> > > unexpected tuning pattern errors. A small failure band may be present
> > > in the tuning range which may be missed by the current algorithm.
> > > Furthermore, the failure bands vary with temperature leading to
> > > different optimum tuning values for different temperatures.
> > >
> > > As suggested in the related Application Report (SPRACA9B - October 2017
> > > - Revised July 2018 [2]), tuning should be done in two stages.
> > > In stage 1, assign the optimum ratio in the maximum pass window for the
> > > current temperature. In stage 2, if the chosen value is close to the
> > > small failure band, move away from it in the appropriate direction.
> > >
> > > References:
> > > [1] http://www.ti.com/lit/pdf/sprz426
> > > [2] http://www.ti.com/lit/pdf/SPRACA9
> > >
> > > Signed-off-by: Faiz Abbas
> > > Acked-by: Adrian Hunter
> > > ---
> > > drivers/mmc/host/Kconfig | 2 +
> > > drivers/mmc/host/sdhci-omap.c | 90 ++-
> > > 2 files changed, 91 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> > > index 5fa580cec831..d8f984483ab0 100644
> > > --- a/drivers/mmc/host/Kconfig
> > > +++ b/drivers/mmc/host/Kconfig
> > > @@ -977,6 +977,8 @@ config MMC_SDHCI_XENON
> > > config MMC_SDHCI_OMAP
> > > tristate "TI SDHCI Controller Support"
> > > depends on MMC_SDHCI_PLTFM && OF
> > > + select THERMAL
> > > + select TI_SOC_THERMAL
> > > help
> > > This selects the Secure Digital Host Controller Interface
> > > (SDHCI)
> > > support present in TI's DRA7 SOCs. The controller supports
> > > diff --git a/drivers/mmc/host/sdhci-omap.c b/drivers/mmc/host/sdhci-omap.c
> > > index f588ab679cb0..b75c55011fcb 100644
> > > --- a/drivers/mmc/host/sdhci-omap.c
> > > +++ b/drivers/mmc/host/sdhci-omap.c
> > > @@ -27,6 +27,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include "sdhci-pltfm.h"
> > >
> > > @@ -286,15 +287,19 @@ static int sdhci_omap_execute_tuning(struct
> > > mmc_host *mmc, u32 opcode)
> > > struct sdhci_host *host = mmc_priv(mmc);
> > > struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> > > struct sdhci_omap_host *omap_host = sdhci_pltfm_priv(pltfm_host);
> > > + struct thermal_zone_device *thermal_dev;
> > > struct device *dev = omap_host->dev;
> > > struct mmc_ios *ios = >ios;
> > > u32 start_window = 0, max_window = 0;
> > > + bool single_point_failure = false;
> > > bool dcrc_was_enabled = false;
> > > u8 cur_match, prev_match = 0;
> > > u32 length = 0, max_len = 0;
> > > u32 phase_delay = 0;
> > > + int temperature;
> > > int ret = 0;
> > > u32 reg;
> > > + int i;
> > >
> > > /* clock tuning is not needed for upto 52MHz */
> > > if (ios->clock <= 5200)
> > > @@ -304,6 +309,16 @@ static int sdhci_omap_execute_tuning(struct mmc_host
> > > *mmc, u32 opcode)
> > > if (ios->timing == MMC_TIMING_UHS_SDR50 && !(reg & CAPA2_TSDR50))
> > > return 0;
> > >
> > > + thermal_dev = thermal_zone_get_zone_by_name("cpu_thermal");
> >
> > I couldn't find a corresponding call to a put function, like
> > "thermal_zone_put()" or whatever, which made me realize that the
> > thermal zone API is incomplete. Or depending on how you put it, it
> > lacks object reference counting, unless I am missing something.
> >
> > For example, what happens if the thermal zone becomes unregistered
> > between this point and when you call thermal_zone_get_temp() a couple
> > of line below. I assume it's a known problem, but just wanted to point
> > it out.
> >
Yes, there is no ref counting. Specially because the get zones usages
were too specific, and mostly used in application cases that module
would not really be removed. Though not a good excuse, still, not very
problematic. Now, if the API is getting other usages, then refcounting
may be necessary.
> > > + if (IS_ERR(thermal_dev)) {
> > > + dev_err(dev, "Unable to get thermal zone for tuning\n");
> > > + return PTR_ERR(thermal_dev);
> > > + }
> > > +
> > > + ret = thermal_zone_get_temp(thermal_dev, );
> > > + if (ret)
> > > + return ret;
> > > +
> >
> > [...]
> >
> > Anyway, I have applied this for next, thanks!
>
> This is throwing errors on builds of keystone_defconfig in next and mainline:
>
> http://arm-soc.lixom.net/buildlogs/next/next-20190102/buildall.arm.keystone_defconfig.log.passed
>
>
Re: [GIT PULL] Thermal-SoC management updates for v4.21-rc1
On Tue, Jan 01, 2019 at 03:32:50PM -0800, Linus Torvalds wrote: > On Tue, Jan 1, 2019 at 3:16 PM Eduardo Valentin wrote: > > > > > It doesn't even build cleanly. > > > > > > > Do you still have have a copy of the build error? > > A plain "make allmodconfig" shows a warning. I see. I am afraid I really did not catch this. I supposed you are referring to the warning like this: thermal_hwmon.h:29:1: warning: ‘thermal_remove_hwmon_sysfs’ defined but not used [-Wunused-function] I am sending out a patch for this on thermal_hwmon.h and will be resending the pull request once the CIs report back. > > And I refuse to add new warnings. Fair enough. I would not expect anything different. Thanks for reporting. > > Linus
Re: [GIT PULL] Thermal-SoC management updates for v4.21-rc1
On Tue, Jan 01, 2019 at 01:35:36PM -0800, Linus Torvalds wrote: > On Tue, Jan 1, 2019 at 8:05 AM Eduardo Valentin wrote: > > > > Please consider pulling from > > > > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal > > linus > > No. > > I pulled and immediately unpulled again. > hmm... ok I am double checking. > It doesn't even build cleanly. > Do you still have have a copy of the build error? The local tests I did were not enough to see this error, neither were the kernel CI builds. Only failed build was on something completely unrelated (ARC) to these changes: Full Build Summary: https://kernelci.org/build/evalenti/branch/for-kernelci/kernel/v4.20-rc5-42-g055ddb633a35/ > Linus
Re: [PATCH v5 0/3] Stingray thermal driver support
On Tue, Jan 01, 2019 at 10:04:39PM +0800, Zhang Rui wrote: > On 一, 2018-12-31 at 14:15 -0800, Florian Fainelli wrote: > > > > On 04/12/2018 19:17, Srinath Mannam wrote: > > > > > > Hi, > > > > > > Could you please provide your feedback to this patch series? > > Rui or Eduardo can we get either one of you to review the thermal > > driver > > parts of this patch series? Why do we constantly have to chase people > > to > > respond in this specific subsystem? > > > Eduardo, can you please take a look at this patch series? Yup, I will take a look. > > thanks, > rui > > > > > > > > > Regards, > > > Srinath. > > > On Thu, Nov 8, 2018 at 3:45 AM Florian Fainelli > > om> wrote: > > > > > > > > > > > > > > > > > > > > On 10/16/2018 8:11 AM, Srinath Mannam wrote: > > > > > > > > > > These patches adds the stingray thermal driver and its > > > > > corresponding DT nodes with documentation. > > > > Can we get feedback from the thermal maintains whether this is > > > > acceptable or not? > > > > > > > > > > > > > > > > > > > Changes from v4 > > > > > - Addressed Rob Herring comments on DT parameters and > > > > > thermal driver architecture. > > > > > - Removed brcm,max-crit-temp DT parameter > > > > > - Changed driver to thermal sensor registration model. > > > > > - Added trip DT properties. > > > > > > > > > > Changes from v3 > > > > > - Addressed Daniel lezcano comments. > > > > > - Elaborated commit description of thermal driver patch. > > > > > - Added brcm,max-crit-temp DT parameter. > > > > > > > > > > Changes from v2: > > > > > - All stingray TMON DT nodes are combine together into > > > > > single. > > > > > Temperature registers are combined into one mem resource. > > > > > brcm,tmon-mask parameter has available TMONs mask value. > > > > > - All available TMONs are initialized together in single > > > > > instance of driver probe call. > > > > > > > > > > Changes from v1: > > > > > - Fixed auto build sparce warning. > > > > > > > > > > Pramod Kumar (3): > > > > > dt-bindings: thermal: Add binding document for SR thermal > > > > > thermal: broadcom: Add Stingray thermal driver > > > > > arm64: dts: stingray: Add Stingray Thermal DT support. > > > > > > > > > > .../bindings/thermal/brcm,sr-thermal.txt | 105 > > > > > > > > > > .../arm64/boot/dts/broadcom/stingray/stingray.dtsi | 89 > > > > > + > > > > > drivers/thermal/Kconfig| 3 +- > > > > > drivers/thermal/broadcom/Kconfig | 9 ++ > > > > > drivers/thermal/broadcom/Makefile | 1 + > > > > > drivers/thermal/broadcom/sr-thermal.c | 138 > > > > > + > > > > > 6 files changed, 344 insertions(+), 1 deletion(-) > > > > > create mode 100644 > > > > > Documentation/devicetree/bindings/thermal/brcm,sr-thermal.txt > > > > > create mode 100644 drivers/thermal/broadcom/sr-thermal.c > > > > > > > > > -- > > > > Florian
[GIT PULL] Thermal-SoC management updates for v4.21-rc1
Hello Linus, Please consider pulling from git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal linus to receive Thermal-SoC Management updates for v4.21-rc1 with top-most 055ddb633a35845f106fb732a07c90862e0a43e5: thermal: generic-adc: Fix adc to temp interpolation (2018-12-25 14:44:45 -0800) on top of commit 0072a0c14d5b7cb72c611d396f143f5dcd73ebe2: Merge tag 'media/v4.20-4' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media (2018-12-03 11:29:20 -0800) Specifics: - Tegra DT binding documentation for Tegra194 - Armada now supports ap806 and cp110 - RCAR thermal now supports R8A774C0 and R8A77990 - Fixes on IMX, generic-ADC, ST, RCAR, Broadcom, Uniphier, QCOM, Tegra, PowerClamp, and Armada CI: Full Boot Summary: https://kernelci.org/boot/all/job/evalenti/branch/for-kernelci/kernel/v4.20-rc5-42-g055ddb633a35/ Full Build Summary: https://kernelci.org/build/evalenti/branch/for-kernelci/kernel/v4.20-rc5-42-g055ddb633a35/ BR, Eduardo Anson Huang (2): thermal: imx: fix for dependency on cpu-freq thermal: imx: save one condition block for normal case of nvmem initialization Arnd Bergmann (1): thermal: st: fix Makefile typo Bjorn Andersson (1): thermal: generic-adc: Fix adc to temp interpolation Fabrizio Castro (2): dt-bindings: thermal: rcar-thermal: add R8A774C0 support thermal: rcar_thermal: add R8A774C0 support Geert Uytterhoeven (1): dt-bindings: thermal: rcar-gen3-thermal: All variants use 3 interrupts Julia Lawall (1): thermal: broadcom: use devm_thermal_zone_of_sensor_register Kunihiko Hayashi (1): thermal: uniphier: Convert to SPDX identifier Matthias Brugger (1): thermal: bcm2835: enable hwmon explicitly Miquel Raynal (4): thermal: armada: add overheat interrupt support MAINTAINERS: thermal: add entry for Marvell MVEBU thermal driver dt-bindings: ap806: document the thermal interrupt capabilities dt-bindings: cp110: document the thermal interrupt capabilities Srinivas Kandagatla (1): thermal: tsens: qcom: do not create duplicate regmap debugfs entries Thierry Reding (1): dt-bindings: thermal: tegra-bpmp: Add Tegra194 support Yangtao Li (2): thermal: tegra: soctherm: Change to use DEFINE_SHOW_ATTRIBUTE macro thermal/intel_powerclamp: Change to use DEFINE_SHOW_ATTRIBUTE macro Yoshihiro Kaneko (2): dt-bindings: thermal: rcar-thermal: add R8A77990 support thermal: rcar_thermal: add R8A77990 support YueHaibing (1): thermal: armada: Use PTR_ERR_OR_ZERO in armada_thermal_probe_legacy() .../arm/marvell/ap806-system-controller.txt| 7 + .../arm/marvell/cp110-system-controller.txt| 9 + .../thermal/nvidia,tegra186-bpmp-thermal.txt | 3 +- .../bindings/thermal/rcar-gen3-thermal.txt | 3 +- .../devicetree/bindings/thermal/rcar-thermal.txt | 6 +- MAINTAINERS| 5 + drivers/thermal/Kconfig| 2 +- drivers/thermal/armada_thermal.c | 280 - drivers/thermal/broadcom/bcm2835_thermal.c | 11 + drivers/thermal/broadcom/brcmstb_thermal.c | 24 +- drivers/thermal/imx_thermal.c | 52 ++-- drivers/thermal/intel_powerclamp.c | 14 +- drivers/thermal/qcom/tsens-common.c| 12 +- drivers/thermal/rcar_thermal.c | 8 + drivers/thermal/st/Makefile| 2 +- drivers/thermal/tegra/soctherm.c | 12 +- drivers/thermal/thermal-generic-adc.c | 12 +- drivers/thermal/uniphier_thermal.c | 13 +- .../dt-bindings/thermal/tegra194-bpmp-thermal.h| 15 ++ 19 files changed, 398 insertions(+), 92 deletions(-) create mode 100644 include/dt-bindings/thermal/tegra194-bpmp-thermal.h
Re: [PATCH V5 2/4] thermal: imx_sc: add i.MX system controller thermal support
On Thu, Dec 20, 2018 at 09:08:32AM +, Anson Huang wrote:
> i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
> inside, the system controller is in charge of controlling power,
> clock and thermal sensors etc..
>
> This patch adds i.MX system controller thermal driver support,
> Linux kernel has to communicate with system controller via MU
> (message unit) IPC to get each thermal sensor's temperature,
> it supports multiple sensors which are passed from device tree,
> please see the binding doc for details.
>
> Signed-off-by: Anson Huang
> ---
> ChangeLog since V4:
> - Add driver dependency on IMX_SCU to avoid compile error when IMX_SCU is
> NOT selected;
> - Remove unnecessary of different errors handle for imx_scu_get_handle,
> already included in API.
> ---
> drivers/thermal/Kconfig | 11 +++
> drivers/thermal/Makefile | 1 +
> drivers/thermal/imx_sc_thermal.c | 200
> +++
> 3 files changed, 212 insertions(+)
> create mode 100644 drivers/thermal/imx_sc_thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index 0e69edc..8d4601d 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -222,6 +222,17 @@ config IMX_THERMAL
> cpufreq is used as the cooling device to throttle CPUs when the
> passive trip is crossed.
>
> +config IMX_SC_THERMAL
> + tristate "Temperature sensor driver for NXP i.MX SoCs with System
> Controller"
> + depends on (ARCH_MXC && IMX_SCU) || COMPILE_TEST
> + depends on OF
> + help
> + Support for Temperature Monitor (TEMPMON) found on NXP i.MX SoCs with
> + system controller inside, Linux kernel has to communicate with system
> + controller via MU (message unit) IPC to get temperature from thermal
> + sensor. It supports one critical trip point and one
> + passive trip point for each thermal sensor.
> +
> config MAX77620_THERMAL
> tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
> depends on MFD_MAX77620
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index 610344e..1b13f6a 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -41,6 +41,7 @@ obj-$(CONFIG_DB8500_THERMAL)+= db8500_thermal.o
> obj-$(CONFIG_ARMADA_THERMAL) += armada_thermal.o
> obj-$(CONFIG_TANGO_THERMAL) += tango_thermal.o
> obj-$(CONFIG_IMX_THERMAL)+= imx_thermal.o
> +obj-$(CONFIG_IMX_SC_THERMAL) += imx_sc_thermal.o
> obj-$(CONFIG_MAX77620_THERMAL) += max77620_thermal.o
> obj-$(CONFIG_QORIQ_THERMAL) += qoriq_thermal.o
> obj-$(CONFIG_DA9062_THERMAL) += da9062-thermal.o
> diff --git a/drivers/thermal/imx_sc_thermal.c
> b/drivers/thermal/imx_sc_thermal.c
> new file mode 100644
> index 000..1030a31
> --- /dev/null
> +++ b/drivers/thermal/imx_sc_thermal.c
> @@ -0,0 +1,200 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright 2018 NXP.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "thermal_core.h"
> +
> +#define IMX_SC_MISC_FUNC_GET_TEMP13
> +#define IMX_SC_C_TEMP0
> +
> +static struct imx_sc_ipc *thermal_ipc_handle;
> +
> +struct imx_sc_sensor {
> + struct thermal_zone_device *tzd;
> + u32 resource_id;
> +};
> +
> +struct imx_sc_thermal_data {
> + struct imx_sc_sensor *sensor;
> +};
> +
> +struct req_get_temp {
> + u16 resource_id;
> + u8 type;
> +} __packed;
> +
> +struct resp_get_temp {
> + u16 celsius;
> + u8 tenths;
> +} __packed;
> +
> +struct imx_sc_msg_misc_get_temp {
> + struct imx_sc_rpc_msg hdr;
> + union {
> + struct req_get_temp req;
> + struct resp_get_temp resp;
> + } data;
> +} __packed;
> +
> +static int imx_sc_thermal_get_temp(void *data, int *temp)
> +{
> + struct imx_sc_msg_misc_get_temp msg;
> + struct imx_sc_rpc_msg *hdr =
> + struct imx_sc_sensor *sensor = data;
> + int ret;
> +
> + msg.data.req.resource_id = sensor->resource_id;
> + msg.data.req.type = IMX_SC_C_TEMP;
> +
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_MISC;
> + hdr->func = IMX_SC_MISC_FUNC_GET_TEMP;
> + hdr->size = 2;
> +
> + ret = imx_scu_call_rpc(thermal_ipc_handle, , true);
> + if (ret) {
> + pr_err("read temp sensor %d failed, ret %d\n",
> + sensor->resource_id, ret);
> + return ret;
> + }
> +
> + *temp = msg.data.resp.celsius * 1000 + msg.data.resp.tenths * 100;
> +
> + return 0;
> +}
> +
> +static const struct thermal_zone_of_device_ops imx_sc_thermal_ops = {
> + .get_temp = imx_sc_thermal_get_temp,
> +};
> +
> +static int imx_sc_thermal_register_sensor(struct platform_device *pdev,
> + struct imx_sc_sensor *sensor)
> +{
> + struct thermal_zone_device *tzd;
> +
> + tzd =
Re: [PATCH v6 3/4] thermal: tegra: parse sensor id before sensor register
On Wed, Dec 19, 2018 at 11:00:10AM +0800, Wei Ni wrote:
>
>
> On 19/12/2018 9:24 AM, Eduardo Valentin wrote:
> > On Fri, Dec 14, 2018 at 05:49:52PM +0800, Wei Ni wrote:
> >> Since different platforms may not support all 4
> >> sensors, so the sensor registration may be failed.
> >> Add codes to parse dt to find sensor id which
> >> need to be registered. So that the registration
> >> can be successful on all platform.
> >>
> >> Signed-off-by: Wei Ni
> >> ---
> >> drivers/thermal/tegra/soctherm.c | 45
> >> ++--
> >> 1 file changed, 43 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/thermal/tegra/soctherm.c
> >> b/drivers/thermal/tegra/soctherm.c
> >> index fd2703c0cfc5..6bee31cd4621 100644
> >> --- a/drivers/thermal/tegra/soctherm.c
> >> +++ b/drivers/thermal/tegra/soctherm.c
> >> @@ -1224,6 +1224,41 @@ static void soctherm_init(struct platform_device
> >> *pdev)
> >>tegra_soctherm_throttle(>dev);
> >> }
> >>
> >> +static bool tegra_soctherm_find_sensor_id(unsigned int sensor_id)
> >> +{
> >> + bool ret = false;
> >> + struct of_phandle_args sensor_specs;
> >> + struct device_node *np, *sensor_np;
> >> +
> >> + np = of_find_node_by_name(NULL, "thermal-zones");
> >> + if (!np)
> >> + return ret;
> >> +
> >> + for_each_available_child_of_node(np, sensor_np) {
> >> + if (of_parse_phandle_with_args(sensor_np, "thermal-sensors",
> >> + "#thermal-sensor-cells",
> >> + 0, _specs))
> >> + continue;
> >> +
> >> + if (sensor_specs.args_count != 1) {
> >> + WARN(sensor_specs.args_count != 1,
> >> + "%s: wrong cells in sensor specifier %d\n",
> >> + sensor_specs.np->name, sensor_specs.args_count);
> >> + continue;
> >> + }
> >> +
> >> + if (sensor_specs.args[0] == sensor_id) {
> >> + of_node_put(sensor_np);
> >> + ret = true;
> >> + break;
> >> + }
> >> + }
> >> +
> >> + of_node_put(np);
> >> +
> >> + return ret;
> >> +}
> >
> > So, I am still failing to see why this is really needed.
> >
> > Why can't you simply resolve this with different compatibles?
> > If the sensor is not present or disabled, the compatible is not, well,
> > compatible anymore.
>
> This driver can support three Tegra chip t124, t132 and t210. And we
> also support some platforms for every chips. As the description in the
> commit, different platforms may not support all 4 sensors, so I
> upstreamed this patch.
ok.. Which means, all platforms need to have a proper DT that describes
the correct amount of sensors.
> If we use different compatibles, I think we can't resolve it simply,
> because we also need to add codes to configure which platform support
> which sensors, and may add more in the future. If use this patch, we
There is a very common way of solving this, you can pass .data and grab
after calling of_node_match(), just like the tegra soc thermal driver
already does.
> doesn't need to do any more in the future.
Well, if the patch is needed to add support for different versions of
your sensor block, then there is no reason why not patching.
> Actually in my original change, I just ignore the registration failure
> to fix this issue, it will not affect loading driver, but as Daniel's
> comment, it's not better to ignore, so I followed his comment to refer
It is not good to ignore. The correct thing to do here is for tegra to
have correct DT entries for each sensor block version, to correctly
represent the amount of sensors present in the RTL, then you reflect
that in device driver using compatible. This way you wont need to ignore
failures, and you will support the correct amount of sensors for each
block version.
> the QORIQ thermal driver to get the sensor id.
>
I am not sure that is a good example to follow.
> Thanks.
> Wei.
>
> >
> >> +
> >> static const struct of_device_id tegra_soctherm_of_match[] = {
> >> #ifdef CONFIG_ARCH_TEGRA_124_SOC
> >>{
> >> @@ -1365,13 +1400,16 @@ static int tegra_soctherm_probe(struct
> >> platform_device *pdev)
> >>
Re: [PATCH v6 3/4] thermal: tegra: parse sensor id before sensor register
On Fri, Dec 14, 2018 at 05:49:52PM +0800, Wei Ni wrote:
> Since different platforms may not support all 4
> sensors, so the sensor registration may be failed.
> Add codes to parse dt to find sensor id which
> need to be registered. So that the registration
> can be successful on all platform.
>
> Signed-off-by: Wei Ni
> ---
> drivers/thermal/tegra/soctherm.c | 45
> ++--
> 1 file changed, 43 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/thermal/tegra/soctherm.c
> b/drivers/thermal/tegra/soctherm.c
> index fd2703c0cfc5..6bee31cd4621 100644
> --- a/drivers/thermal/tegra/soctherm.c
> +++ b/drivers/thermal/tegra/soctherm.c
> @@ -1224,6 +1224,41 @@ static void soctherm_init(struct platform_device *pdev)
> tegra_soctherm_throttle(>dev);
> }
>
> +static bool tegra_soctherm_find_sensor_id(unsigned int sensor_id)
> +{
> + bool ret = false;
> + struct of_phandle_args sensor_specs;
> + struct device_node *np, *sensor_np;
> +
> + np = of_find_node_by_name(NULL, "thermal-zones");
> + if (!np)
> + return ret;
> +
> + for_each_available_child_of_node(np, sensor_np) {
> + if (of_parse_phandle_with_args(sensor_np, "thermal-sensors",
> + "#thermal-sensor-cells",
> + 0, _specs))
> + continue;
> +
> + if (sensor_specs.args_count != 1) {
> + WARN(sensor_specs.args_count != 1,
> + "%s: wrong cells in sensor specifier %d\n",
> + sensor_specs.np->name, sensor_specs.args_count);
> + continue;
> + }
> +
> + if (sensor_specs.args[0] == sensor_id) {
> + of_node_put(sensor_np);
> + ret = true;
> + break;
> + }
> + }
> +
> + of_node_put(np);
> +
> + return ret;
> +}
So, I am still failing to see why this is really needed.
Why can't you simply resolve this with different compatibles?
If the sensor is not present or disabled, the compatible is not, well,
compatible anymore.
> +
> static const struct of_device_id tegra_soctherm_of_match[] = {
> #ifdef CONFIG_ARCH_TEGRA_124_SOC
> {
> @@ -1365,13 +1400,16 @@ static int tegra_soctherm_probe(struct
> platform_device *pdev)
> zone->sg = soc->ttgs[i];
> zone->ts = tegra;
>
> + if (!tegra_soctherm_find_sensor_id(soc->ttgs[i]->id))
> + continue;
> +
> z = devm_thermal_zone_of_sensor_register(>dev,
>soc->ttgs[i]->id, zone,
>_of_thermal_ops);
> if (IS_ERR(z)) {
> err = PTR_ERR(z);
> - dev_err(>dev, "failed to register sensor: %d\n",
> - err);
> + dev_err(>dev, "failed to register sensor %s:
> %d\n",
> + soc->ttgs[i]->name, err);
> goto disable_clocks;
> }
>
> @@ -1434,6 +1472,9 @@ static int __maybe_unused soctherm_resume(struct device
> *dev)
> struct thermal_zone_device *tz;
>
> tz = tegra->thermctl_tzs[soc->ttgs[i]->id];
> + if (!tz)
> + continue;
> +
> err = tegra_soctherm_set_hwtrips(dev, soc->ttgs[i], tz);
> if (err) {
> dev_err(>dev,
> --
> 2.7.4
>
Re: [PATCH v6 0/4] Fixes for Tegra soctherm
On Tue, Dec 18, 2018 at 11:35:54AM +0800, Zhang Rui wrote: > On 五, 2018-12-14 at 17:54 +0800, Wei Ni wrote: > > Hi Rui, > > I moved get_trend() patch https://lkml.org/lkml/2018/11/20/643 in > > this > > serial. > > Since no more comments on these patches, will you take them? > > > I think Eduardo will take care of this patch series. Yes, I will take a look on this series. But, please, next time you send a series of patches on thermal, copy the linux...@vger.kernel.org mailing list. This way we can track your patches on patchwork. > > thanks, > rui > > Thanks. > > Wei. > > > > On 14/12/2018 5:49 PM, Wei Ni wrote: > > > > > > This series fixed some issues for Tegra soctherm, > > > and add get_trend(). > > > > > > Main changes from v5: > > > 1. Move the get_trend() patch https://lkml.org/lkml/2018/11/20/643 > > > into this serial. > > > > > > Main changes from v4: > > > 1. fixed for the parsing sensor id. > > > 2. keep warning for missing critical trips. > > > > > > Main changes from v3: > > > 1. updated codes for parsing sensor id, per Thierry's comments > > > > > > Main changes from v2: > > > 1. add codes to parse sensor id to avoid registration > > > failure. > > > > > > Main changes from v1: > > > 1. Acked by Thierry Reding for the patch > > > "thermal: tegra: fix memory allocation". > > > 2. Print out the sensor name when register failed. > > > 2. Remove patch "thermal: tegra: fix coverity defect" > > > > > > Wei Ni (4): > > > thermal: tegra: remove unnecessary warnings > > > thermal: tegra: fix memory allocation > > > thermal: tegra: parse sensor id before sensor register > > > thermal: tegra: add get_trend ops > > > > > > drivers/thermal/tegra/soctherm.c | 85 > > > +--- > > > 1 file changed, 80 insertions(+), 5 deletions(-) > > >
Re: [PATCH 3/3] arm64: tegra: p2972: Enable the CPU, GPU and AUX thermal zones
On Fri, Nov 23, 2018 at 01:18:39PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> Enable these thermal zones to be able to monitor their temperatures and
> control the fan to cool down the system if necessary.
>
> Signed-off-by: Thierry Reding
Acked-by: Eduardo Valentin
As mentioned, I already added patch 1.
> ---
> .../boot/dts/nvidia/tegra194-p2972-.dts | 91 ++-
> 1 file changed, 90 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
> b/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
> index cbae8e8b1281..e29f8f6117c8 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
> +++ b/arch/arm64/boot/dts/nvidia/tegra194-p2972-.dts
> @@ -43,8 +43,97 @@
> };
> };
>
> - fan {
> + fan: fan {
> compatible = "pwm-fan";
> pwms = < 0 45334>;
> +
> + cooling-levels = <0 64 128 255>;
> + cooling-min-state = <0>;
> + cooling-max-state = <3>;
> + #cooling-cells = <2>;
> + };
> +
> + thermal-zones {
> + cpu {
> + polling-delay = <0>;
> + polling-delay-passive = <500>;
> + status = "okay";
> +
> + trips {
> + cpu_trip_critical: critical {
> + temperature = <96500>;
> + hysteresis = <0>;
> + type = "critical";
> + };
> +
> + cpu_trip_hot: hot {
> + temperature = <7>;
> + hysteresis = <2000>;
> + type = "hot";
> + };
> +
> + cpu_trip_active: active {
> + temperature = <5>;
> + hysteresis = <2000>;
> + type = "active";
> + };
> +
> + cpu_trip_passive: passive {
> + temperature = <3>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> + };
> +
> + cooling-maps {
> + cpu-critical {
> + cooling-device = < 3 3>;
> + trip = <_trip_critical>;
> + };
> +
> + cpu-hot {
> + cooling-device = < 2 2>;
> + trip = <_trip_hot>;
> + };
> +
> + cpu-active {
> + cooling-device = < 1 1>;
> + trip = <_trip_active>;
> + };
> +
> + cpu-passive {
> + cooling-device = < 0 0>;
> + trip = <_trip_passive>;
> + };
> + };
> + };
> +
> + gpu {
> + polling-delay = <0>;
> + polling-delay-passive = <500>;
> + status = "okay";
> +
> + trips {
> + gpu_alert0: critical {
> + temperature = <99000>;
> + hysteresis = <0>;
> + type = "critical";
> + };
> + };
> + };
> +
> + aux {
> + polling-delay = <0>;
> + polling-delay-passive = <500>;
> + status = "okay";
> +
> + trips {
> + aux_alert0: critical {
> + temperature = <9>;
> + hysteresis = <0>;
> + type = "critical";
> + };
> + };
> + };
> };
> };
Re: [PATCH 2/3] arm64: tegra: Add thermal zones on Tegra194
On Fri, Nov 23, 2018 at 01:18:38PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> The NVIDIA Tegra194 SoC defines six thermal zones. Define all of them in
> device tree.
>
> Signed-off-by: Thierry Reding
Acked-by: Eduardo Valentin
The patch 1 I added in my -linus branch.
> ---
> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 39
> 1 file changed, 39 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> index cbba7395a286..39169f6b6166 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
> @@ -5,6 +5,7 @@
> #include
> #include
> #include
> +#include
>
> / {
> compatible = "nvidia,tegra194";
> @@ -938,6 +939,44 @@
> mbox-names = "rx", "tx";
> };
>
> + thermal-zones {
> + cpu {
> + thermal-sensors = <&{/bpmp/thermal}
> +TEGRA194_BPMP_THERMAL_ZONE_CPU>;
> + status = "disabled";
> + };
> +
> + gpu {
> + thermal-sensors = <&{/bpmp/thermal}
> +TEGRA194_BPMP_THERMAL_ZONE_GPU>;
> + status = "disabled";
> + };
> +
> + aux {
> + thermal-sensors = <&{/bpmp/thermal}
> +TEGRA194_BPMP_THERMAL_ZONE_AUX>;
> + status = "disabled";
> + };
> +
> + pllx {
> + thermal-sensors = <&{/bpmp/thermal}
> +TEGRA194_BPMP_THERMAL_ZONE_PLLX>;
> + status = "disabled";
> + };
> +
> + ao {
> + thermal-sensors = <&{/bpmp/thermal}
> +TEGRA194_BPMP_THERMAL_ZONE_AO>;
> + status = "disabled";
> + };
> +
> + tj {
> + thermal-sensors = <&{/bpmp/thermal}
> +TEGRA194_BPMP_THERMAL_ZONE_TJ_MAX>;
> + status = "disabled";
> + };
> + };
> +
> timer {
> compatible = "arm,armv8-timer";
> interrupts =
Re: [PATCH] thermal: stm32: read factory settings inside stm_thermal_prepare
On Thu, Dec 06, 2018 at 01:23:32PM +, David HERNANDEZ SANCHEZ wrote:
> Calling stm_thermal_read_factory_settings before clocking
> internal peripheral causes bad register values and makes
> temperature computation wrong.
>
> Calling stm_thermal_read_factory_settings inside
> stm_thermal_prepare fixes this problem as internal
> peripheral is well clocked at this stage.
>
> Signed-off-by: David Hernandez Sanchez
> Fixes: 1d693155 ("thermal: add stm32 thermal driver")
Please append patch version in the title next time to help tracking it.
>
> diff --git a/drivers/thermal/st/stm_thermal.c
> b/drivers/thermal/st/stm_thermal.c
> index 47623da..daa1257 100644
> --- a/drivers/thermal/st/stm_thermal.c
> +++ b/drivers/thermal/st/stm_thermal.c
> @@ -532,6 +532,10 @@ static int stm_thermal_prepare(struct stm_thermal_sensor
> *sensor)
> if (ret)
> return ret;
>
> + ret = stm_thermal_read_factory_settings(sensor);
> + if (ret)
> + goto thermal_unprepare;
> +
> ret = stm_thermal_calibration(sensor);
> if (ret)
> goto thermal_unprepare;
> @@ -636,10 +640,6 @@ static int stm_thermal_probe(struct platform_device
> *pdev)
> /* Populate sensor */
> sensor->base = base;
>
> - ret = stm_thermal_read_factory_settings(sensor);
> - if (ret)
> - return ret;
> -
> sensor->clk = devm_clk_get(>dev, "pclk");
> if (IS_ERR(sensor->clk)) {
> dev_err(>dev, "%s: failed to fetch PCLK clock\n",
> --
> 2.7.4
[GIT PULL] Thermal-SoC management fixes for v4.20-rc7
Hello Linus, Consider pulling the following changes since commit 40e020c129cfc991e8ab4736d2665351ffd1468d: Linux 4.20-rc6 (2018-12-09 15:31:00 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes for you to fetch changes up to 99c47fcd4daa2b9a1348872ba49226dcdc58cb40: thermal: stm32: Fix stm_thermal_read_factory_settings (2018-12-10 20:15:28 -0800) Specifics: - Fixes on STM and HISI thermal drivers BR, Eduardo Daniel Lezcano (2): thermal/drivers/hisi: Fix wrong platform_get_irq_byname() thermal/drivers/hisi: Fix number of sensors on hi3660 David HERNANDEZ SANCHEZ (2): thermal: stm32: read factory settings inside stm_thermal_prepare thermal: stm32: Fix stm_thermal_read_factory_settings drivers/thermal/hisi_thermal.c | 4 ++-- drivers/thermal/st/stm_thermal.c | 12 ++-- 2 files changed, 8 insertions(+), 8 deletions(-)
[GIT PULL] Thermal-SoC management fixes for v4.20-rc6
Hello Linus, Consider pulling the following patches containing fixes on thermal soc. The following changes since commit 0072a0c14d5b7cb72c611d396f143f5dcd73ebe2: Merge tag 'media/v4.20-4' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media (2018-12-03 11:29:20 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes for you to fetch changes up to 1aea7aee805e3d1288f9f1fa4484964b51664960: thermal: broadcom: constify thermal_zone_of_device_ops structure (2018-12-05 06:47:46 -0800) Specifics: - Fixes on armada and broadcom thermal drivers. BR, Eduardo Julia Lawall (2): thermal: armada: constify thermal_zone_of_device_ops structure thermal: broadcom: constify thermal_zone_of_device_ops structure Russell King (2): thermal: armada: fix legacy validity test sense thermal: armada: fix legacy resource fixup Stefan Wahren (1): thermal: bcm2835: Switch to SPDX identifier drivers/thermal/armada_thermal.c | 28 +--- drivers/thermal/broadcom/bcm2835_thermal.c | 11 +-- drivers/thermal/broadcom/brcmstb_thermal.c | 2 +- 3 files changed, 15 insertions(+), 26 deletions(-)
[GIT PULL] Thermal-SoC management fixes for v4.20-rc6
Hello Linus, Consider pulling the following patches containing fixes on thermal soc. The following changes since commit 0072a0c14d5b7cb72c611d396f143f5dcd73ebe2: Merge tag 'media/v4.20-4' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media (2018-12-03 11:29:20 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal fixes for you to fetch changes up to 1aea7aee805e3d1288f9f1fa4484964b51664960: thermal: broadcom: constify thermal_zone_of_device_ops structure (2018-12-05 06:47:46 -0800) Specifics: - Fixes on armada and broadcom thermal drivers. BR, Eduardo Julia Lawall (2): thermal: armada: constify thermal_zone_of_device_ops structure thermal: broadcom: constify thermal_zone_of_device_ops structure Russell King (2): thermal: armada: fix legacy validity test sense thermal: armada: fix legacy resource fixup Stefan Wahren (1): thermal: bcm2835: Switch to SPDX identifier drivers/thermal/armada_thermal.c | 28 +--- drivers/thermal/broadcom/bcm2835_thermal.c | 11 +-- drivers/thermal/broadcom/brcmstb_thermal.c | 2 +- 3 files changed, 15 insertions(+), 26 deletions(-)
Re: [PATCH v3 2/4] drivers: thermal: tsens: Add generic support for TSENS v1 IP
On Tue, Dec 04, 2018 at 04:54:21PM +0530, Amit Kucheria wrote:
> On Thu, Nov 29, 2018 at 10:26 PM Eduardo Valentin wrote:
> >
> > On Tue, Nov 27, 2018 at 09:59:05PM +0530, Amit Kucheria wrote:
>
>
>
> > > + qfprom_cdata = (u32 *)qfprom_read(tmdev->dev, "calib");
> > > + if (IS_ERR(qfprom_cdata))
> > > + return PTR_ERR(qfprom_cdata);
> > > +
> > > + mode = (qfprom_cdata[4] & CAL_SEL_MASK) >> CAL_SEL_SHIFT;
> > > + dev_dbg(tmdev->dev, "calibration mode is %d\n", mode);
> > > +
> > > + switch (mode) {
> > > + case TWO_PT_CALIB:
> > > + base1 = (qfprom_cdata[4] & BASE1_MASK) >> BASE1_SHIFT;
> > > + p2[0] = (qfprom_cdata[0] & S0_P2_MASK) >> S0_P2_SHIFT;
> > > + p2[1] = (qfprom_cdata[0] & S1_P2_MASK) >> S1_P2_SHIFT;
> > > + /* This value is split over two registers, 2 bits and 4
> > > bits */
> > > + lsb = (qfprom_cdata[0] & S2_P2_MASK_1_0) >>
> > > S2_P2_SHIFT_1_0;
> > > + msb = (qfprom_cdata[1] & S2_P2_MASK_5_2) >>
> > > S2_P2_SHIFT_5_2;
> > > + p2[2] = msb << 2 | lsb;
> > > + p2[3] = (qfprom_cdata[1] & S3_P2_MASK) >> S3_P2_SHIFT;
> > > + p2[4] = (qfprom_cdata[1] & S4_P2_MASK) >> S4_P2_SHIFT;
> > > + p2[5] = (qfprom_cdata[2] & S5_P2_MASK) >> S5_P2_SHIFT;
> > > + p2[6] = (qfprom_cdata[2] & S6_P2_MASK) >> S6_P2_SHIFT;
> > > + /* This value is split over two registers, 2 bits and 4
> > > bits */
> > > + lsb = (qfprom_cdata[2] & S7_P2_MASK_1_0) >>
> > > S7_P2_SHIFT_1_0;
> > > + msb = (qfprom_cdata[3] & S7_P2_MASK_5_2) >>
> > > S7_P2_SHIFT_5_2;
> > > + p2[7] = msb << 2 | lsb;
> > > + p2[8] = (qfprom_cdata[3] & S8_P2_MASK) >> S8_P2_SHIFT;
> > > + p2[9] = (qfprom_cdata[3] & S9_P2_MASK) >> S9_P2_SHIFT;
> > > + for (i = 0; i < tmdev->num_sensors; i++)
> > > + p2[i] = ((base1 + p2[i]) << 2);
> > > + /* Fall through */
> > > + case ONE_PT_CALIB2:
> > > + base0 = (qfprom_cdata[4] & BASE0_MASK) >> BASE0_SHIFT;
> > > + p1[0] = (qfprom_cdata[0] & S0_P1_MASK) >> S0_P1_SHIFT;
> > > + p1[1] = (qfprom_cdata[0] & S1_P1_MASK) >> S1_P1_SHIFT;
> > > + p1[2] = (qfprom_cdata[0] & S2_P1_MASK) >> S2_P1_SHIFT;
> > > + p1[3] = (qfprom_cdata[1] & S3_P1_MASK) >> S3_P1_SHIFT;
> > > + p1[4] = (qfprom_cdata[1] & S4_P1_MASK) >> S4_P1_SHIFT;
> > > + p1[5] = (qfprom_cdata[2] & S5_P1_MASK) >> S5_P1_SHIFT;
> > > + p1[6] = (qfprom_cdata[2] & S6_P1_MASK) >> S6_P1_SHIFT;
> > > + p1[7] = (qfprom_cdata[2] & S7_P1_MASK) >> S7_P1_SHIFT;
> > > + p1[8] = (qfprom_cdata[3] & S8_P1_MASK) >> S8_P1_SHIFT;
> > > + p1[9] = (qfprom_cdata[3] & S9_P1_MASK) >> S9_P1_SHIFT;
> > > + for (i = 0; i < tmdev->num_sensors; i++)
> > > + p1[i] = (((base0) + p1[i]) << 2);
> > > + break;
> > > + default:
> > > + for (i = 0; i < tmdev->num_sensors; i++) {
> > > + p1[i] = 500;
> > > + p2[i] = 780;
> > ... Wouldn't be nice to know what 500 or 780 stands for here?
>
> Indeed, however I haven't found a suitable explanations in the
> downstream trees or documentation yet. tsens-8974.c and tsens-8916.c
> seem to have similar magic numbers.
>
Well, it does not need to be exactly like it is in downstream, does it?
:-)
> > Why these defaults? Do we expect to have further patches to keep
> > updating these?
>
> No we don't expect them to change. I wish I had a better answer, but
> honestly I don't. I'll keep looking for a explanation to replace these
> magic numbers.
>
Yeah, I see, the problem that I have is that these are slope and
offsets, and these constants change from chip version/rev, essentially
due to sensor location, process, etc, so hardcoding in the probe seams
to be asking for future patching.
> > > + }
> > > + break;
> > > +
Re: [PATCH v3 2/4] drivers: thermal: tsens: Add generic support for TSENS v1 IP
On Tue, Dec 04, 2018 at 04:54:21PM +0530, Amit Kucheria wrote:
> On Thu, Nov 29, 2018 at 10:26 PM Eduardo Valentin wrote:
> >
> > On Tue, Nov 27, 2018 at 09:59:05PM +0530, Amit Kucheria wrote:
>
>
>
> > > + qfprom_cdata = (u32 *)qfprom_read(tmdev->dev, "calib");
> > > + if (IS_ERR(qfprom_cdata))
> > > + return PTR_ERR(qfprom_cdata);
> > > +
> > > + mode = (qfprom_cdata[4] & CAL_SEL_MASK) >> CAL_SEL_SHIFT;
> > > + dev_dbg(tmdev->dev, "calibration mode is %d\n", mode);
> > > +
> > > + switch (mode) {
> > > + case TWO_PT_CALIB:
> > > + base1 = (qfprom_cdata[4] & BASE1_MASK) >> BASE1_SHIFT;
> > > + p2[0] = (qfprom_cdata[0] & S0_P2_MASK) >> S0_P2_SHIFT;
> > > + p2[1] = (qfprom_cdata[0] & S1_P2_MASK) >> S1_P2_SHIFT;
> > > + /* This value is split over two registers, 2 bits and 4
> > > bits */
> > > + lsb = (qfprom_cdata[0] & S2_P2_MASK_1_0) >>
> > > S2_P2_SHIFT_1_0;
> > > + msb = (qfprom_cdata[1] & S2_P2_MASK_5_2) >>
> > > S2_P2_SHIFT_5_2;
> > > + p2[2] = msb << 2 | lsb;
> > > + p2[3] = (qfprom_cdata[1] & S3_P2_MASK) >> S3_P2_SHIFT;
> > > + p2[4] = (qfprom_cdata[1] & S4_P2_MASK) >> S4_P2_SHIFT;
> > > + p2[5] = (qfprom_cdata[2] & S5_P2_MASK) >> S5_P2_SHIFT;
> > > + p2[6] = (qfprom_cdata[2] & S6_P2_MASK) >> S6_P2_SHIFT;
> > > + /* This value is split over two registers, 2 bits and 4
> > > bits */
> > > + lsb = (qfprom_cdata[2] & S7_P2_MASK_1_0) >>
> > > S7_P2_SHIFT_1_0;
> > > + msb = (qfprom_cdata[3] & S7_P2_MASK_5_2) >>
> > > S7_P2_SHIFT_5_2;
> > > + p2[7] = msb << 2 | lsb;
> > > + p2[8] = (qfprom_cdata[3] & S8_P2_MASK) >> S8_P2_SHIFT;
> > > + p2[9] = (qfprom_cdata[3] & S9_P2_MASK) >> S9_P2_SHIFT;
> > > + for (i = 0; i < tmdev->num_sensors; i++)
> > > + p2[i] = ((base1 + p2[i]) << 2);
> > > + /* Fall through */
> > > + case ONE_PT_CALIB2:
> > > + base0 = (qfprom_cdata[4] & BASE0_MASK) >> BASE0_SHIFT;
> > > + p1[0] = (qfprom_cdata[0] & S0_P1_MASK) >> S0_P1_SHIFT;
> > > + p1[1] = (qfprom_cdata[0] & S1_P1_MASK) >> S1_P1_SHIFT;
> > > + p1[2] = (qfprom_cdata[0] & S2_P1_MASK) >> S2_P1_SHIFT;
> > > + p1[3] = (qfprom_cdata[1] & S3_P1_MASK) >> S3_P1_SHIFT;
> > > + p1[4] = (qfprom_cdata[1] & S4_P1_MASK) >> S4_P1_SHIFT;
> > > + p1[5] = (qfprom_cdata[2] & S5_P1_MASK) >> S5_P1_SHIFT;
> > > + p1[6] = (qfprom_cdata[2] & S6_P1_MASK) >> S6_P1_SHIFT;
> > > + p1[7] = (qfprom_cdata[2] & S7_P1_MASK) >> S7_P1_SHIFT;
> > > + p1[8] = (qfprom_cdata[3] & S8_P1_MASK) >> S8_P1_SHIFT;
> > > + p1[9] = (qfprom_cdata[3] & S9_P1_MASK) >> S9_P1_SHIFT;
> > > + for (i = 0; i < tmdev->num_sensors; i++)
> > > + p1[i] = (((base0) + p1[i]) << 2);
> > > + break;
> > > + default:
> > > + for (i = 0; i < tmdev->num_sensors; i++) {
> > > + p1[i] = 500;
> > > + p2[i] = 780;
> > ... Wouldn't be nice to know what 500 or 780 stands for here?
>
> Indeed, however I haven't found a suitable explanations in the
> downstream trees or documentation yet. tsens-8974.c and tsens-8916.c
> seem to have similar magic numbers.
>
Well, it does not need to be exactly like it is in downstream, does it?
:-)
> > Why these defaults? Do we expect to have further patches to keep
> > updating these?
>
> No we don't expect them to change. I wish I had a better answer, but
> honestly I don't. I'll keep looking for a explanation to replace these
> magic numbers.
>
Yeah, I see, the problem that I have is that these are slope and
offsets, and these constants change from chip version/rev, essentially
due to sensor location, process, etc, so hardcoding in the probe seams
to be asking for future patching.
> > > + }
> > > + break;
> > > +
Re: [PATCH v3 4/4] arm64: dts: qcom: qcs404: Add thermal zones for each sensor
On Tue, Dec 04, 2018 at 04:56:15PM +0530, Amit Kucheria wrote:
> On Thu, Nov 29, 2018 at 10:27 PM Eduardo Valentin wrote:
> >
> > On Tue, Nov 27, 2018 at 09:59:07PM +0530, Amit Kucheria wrote:
> > > qcs404 has 10 sensors connected to the single TSENS IP. Define a thermal
> > > zone for each of those sensors to expose the temperature of each zone.
> > >
> > > Signed-off-by: Amit Kucheria
> > > Reviewed-by: Vinod Koul
> > > Tested-by: Vinod Koul
> > > ---
> > > arch/arm64/boot/dts/qcom/qcs404.dtsi | 206 +++
> > > 1 file changed, 206 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > > b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > > index 57d14d8f0c90..cbc3fd378893 100644
> > > --- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > > @@ -30,6 +30,7 @@
> > > reg = <0x100>;
> > > enable-method = "psci";
> > > next-level-cache = <_0>;
> > > + #cooling-cells= <2>;
> > > };
> > >
> > > CPU1: cpu@101 {
> > > @@ -38,6 +39,7 @@
> > > reg = <0x101>;
> > > enable-method = "psci";
> > > next-level-cache = <_0>;
> > > + #cooling-cells= <2>;
> > > };
> > >
> > > CPU2: cpu@102 {
> > > @@ -46,6 +48,7 @@
> > > reg = <0x102>;
> > > enable-method = "psci";
> > > next-level-cache = <_0>;
> > > + #cooling-cells= <2>;
> > > };
> > >
> > > CPU3: cpu@103 {
> > > @@ -54,6 +57,7 @@
> > > reg = <0x103>;
> > > enable-method = "psci";
> > > next-level-cache = <_0>;
> > > + #cooling-cells= <2>;
> > > };
> > >
> > > L2_0: l2-cache {
> > > @@ -507,4 +511,206 @@
> > > #interrupt-cells = <2>;
> > > };
> > > };
> > > +
> > > + thermal-zones {
> > > + aoss-thermal {
> > > + polling-delay-passive = <250>;
> > > + polling-delay = <1000>;
> > > +
> > > + thermal-sensors = < 0>;
> > > +
> > > + trips {
> > > + aoss_alert: trip0 {
> > > + temperature = <75000>;
> > > + hysteresis = <2000>;
> > > + type = "passive";
> >
> >
> > A passive trip and yet no cooling map associate to it..
>
> Oops, was waiting for cpufreq to be enabled on the platform. I'll get
> rid of the trips for now.
Well, the expectation is to have a fully defined thermal zone. Without
trips or cooling maps they are not complete.
>
> >
> > > + };
> > > + aoss_crit: trip1 {
> > > + temperature = <95000>;
> > > + hysteresis = <2000>;
> > > + type = "critical";
> > > + };
> > > + };
> > > + };
> > > +
> > > + dsp-thermal {
> > > + polling-delay-passive = <250>;
> > > + polling-delay = <1000>;
> > > +
> > > + thermal-sensors = < 1>;
> > > +
> > > + trips {
> > > + dsp_alert: trip0 {
> > > + temperature = <75000>;
> > > + hysteresis = <2000>;
> > > + type = "passive";
> > > + };
> > > + dsp_crit: trip1 {
> > > +
Re: [PATCH v3 4/4] arm64: dts: qcom: qcs404: Add thermal zones for each sensor
On Tue, Dec 04, 2018 at 04:56:15PM +0530, Amit Kucheria wrote:
> On Thu, Nov 29, 2018 at 10:27 PM Eduardo Valentin wrote:
> >
> > On Tue, Nov 27, 2018 at 09:59:07PM +0530, Amit Kucheria wrote:
> > > qcs404 has 10 sensors connected to the single TSENS IP. Define a thermal
> > > zone for each of those sensors to expose the temperature of each zone.
> > >
> > > Signed-off-by: Amit Kucheria
> > > Reviewed-by: Vinod Koul
> > > Tested-by: Vinod Koul
> > > ---
> > > arch/arm64/boot/dts/qcom/qcs404.dtsi | 206 +++
> > > 1 file changed, 206 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > > b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > > index 57d14d8f0c90..cbc3fd378893 100644
> > > --- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
> > > @@ -30,6 +30,7 @@
> > > reg = <0x100>;
> > > enable-method = "psci";
> > > next-level-cache = <_0>;
> > > + #cooling-cells= <2>;
> > > };
> > >
> > > CPU1: cpu@101 {
> > > @@ -38,6 +39,7 @@
> > > reg = <0x101>;
> > > enable-method = "psci";
> > > next-level-cache = <_0>;
> > > + #cooling-cells= <2>;
> > > };
> > >
> > > CPU2: cpu@102 {
> > > @@ -46,6 +48,7 @@
> > > reg = <0x102>;
> > > enable-method = "psci";
> > > next-level-cache = <_0>;
> > > + #cooling-cells= <2>;
> > > };
> > >
> > > CPU3: cpu@103 {
> > > @@ -54,6 +57,7 @@
> > > reg = <0x103>;
> > > enable-method = "psci";
> > > next-level-cache = <_0>;
> > > + #cooling-cells= <2>;
> > > };
> > >
> > > L2_0: l2-cache {
> > > @@ -507,4 +511,206 @@
> > > #interrupt-cells = <2>;
> > > };
> > > };
> > > +
> > > + thermal-zones {
> > > + aoss-thermal {
> > > + polling-delay-passive = <250>;
> > > + polling-delay = <1000>;
> > > +
> > > + thermal-sensors = < 0>;
> > > +
> > > + trips {
> > > + aoss_alert: trip0 {
> > > + temperature = <75000>;
> > > + hysteresis = <2000>;
> > > + type = "passive";
> >
> >
> > A passive trip and yet no cooling map associate to it..
>
> Oops, was waiting for cpufreq to be enabled on the platform. I'll get
> rid of the trips for now.
Well, the expectation is to have a fully defined thermal zone. Without
trips or cooling maps they are not complete.
>
> >
> > > + };
> > > + aoss_crit: trip1 {
> > > + temperature = <95000>;
> > > + hysteresis = <2000>;
> > > + type = "critical";
> > > + };
> > > + };
> > > + };
> > > +
> > > + dsp-thermal {
> > > + polling-delay-passive = <250>;
> > > + polling-delay = <1000>;
> > > +
> > > + thermal-sensors = < 1>;
> > > +
> > > + trips {
> > > + dsp_alert: trip0 {
> > > + temperature = <75000>;
> > > + hysteresis = <2000>;
> > > + type = "passive";
> > > + };
> > > + dsp_crit: trip1 {
> > > +
Re: [PATCH] thermal/drivers/hisi: Fix bad initialization
On Thu, Nov 29, 2018 at 07:26:56PM +0100, Daniel Lezcano wrote:
> Without this patch, the thermal driver on hi6220 and hi3660 is broken.
>
> That is due because part of the posted patchset was merged but a small
> change in the DT was dropped.
>
> The hi6220 and hi3660 do not have an interrupt name in the DT, so
> finding interrupt by name fails.
>
> In addition, the hi3660 only defines one thermal zone in the DT and we
> are trying to register two sensors assuming we have two thermal zones
> in the DT.
>
> Fix this by adding a couple of line of code to add back compatibility
> with older DT and change the sensors number to 1 for the hi3660.
Is this a case of adding dt versioning for those nodes?
>
> Fixes: 2cffaeff083f (thermal/drivers/hisi: Use platform_get_irq_byname)
> Signed-off-by: Daniel Lezcano
> ---
> drivers/thermal/hisi_thermal.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index c4111a9..3ab0e63 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -424,7 +424,7 @@ static int hi3660_thermal_probe(struct hisi_thermal_data
> *data)
> struct platform_device *pdev = data->pdev;
> struct device *dev = >dev;
>
> - data->nr_sensors = 2;
> + data->nr_sensors = 1;
For bisectability (heh.. is that even a word?), would you please send
one fix per patch?
>
> data->sensor = devm_kzalloc(dev, sizeof(*data->sensor) *
> data->nr_sensors, GFP_KERNEL);
> @@ -590,8 +590,13 @@ static int hisi_thermal_probe(struct platform_device
> *pdev)
> }
>
> ret = platform_get_irq_byname(pdev, sensor->irq_name);
> - if (ret < 0)
> - return ret;
> + if (ret <= 0) {
Maybe a simple < is enough? reading it seams awkward. From a glance, I
dont think platform_get_irq* ever returns 0.
> + ret = platform_get_irq(pdev, 0);
> + if (ret <= 0) {
Same here.
> + dev_err(dev, "Failed get interrupt: %d\n", ret);
> + return ret;
> + }
> + }
>
> ret = devm_request_threaded_irq(dev, ret, NULL,
> hisi_thermal_alarm_irq_thread,
> --
> 2.7.4
>
Re: [PATCH] thermal/drivers/hisi: Fix bad initialization
On Thu, Nov 29, 2018 at 07:26:56PM +0100, Daniel Lezcano wrote:
> Without this patch, the thermal driver on hi6220 and hi3660 is broken.
>
> That is due because part of the posted patchset was merged but a small
> change in the DT was dropped.
>
> The hi6220 and hi3660 do not have an interrupt name in the DT, so
> finding interrupt by name fails.
>
> In addition, the hi3660 only defines one thermal zone in the DT and we
> are trying to register two sensors assuming we have two thermal zones
> in the DT.
>
> Fix this by adding a couple of line of code to add back compatibility
> with older DT and change the sensors number to 1 for the hi3660.
Is this a case of adding dt versioning for those nodes?
>
> Fixes: 2cffaeff083f (thermal/drivers/hisi: Use platform_get_irq_byname)
> Signed-off-by: Daniel Lezcano
> ---
> drivers/thermal/hisi_thermal.c | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/thermal/hisi_thermal.c b/drivers/thermal/hisi_thermal.c
> index c4111a9..3ab0e63 100644
> --- a/drivers/thermal/hisi_thermal.c
> +++ b/drivers/thermal/hisi_thermal.c
> @@ -424,7 +424,7 @@ static int hi3660_thermal_probe(struct hisi_thermal_data
> *data)
> struct platform_device *pdev = data->pdev;
> struct device *dev = >dev;
>
> - data->nr_sensors = 2;
> + data->nr_sensors = 1;
For bisectability (heh.. is that even a word?), would you please send
one fix per patch?
>
> data->sensor = devm_kzalloc(dev, sizeof(*data->sensor) *
> data->nr_sensors, GFP_KERNEL);
> @@ -590,8 +590,13 @@ static int hisi_thermal_probe(struct platform_device
> *pdev)
> }
>
> ret = platform_get_irq_byname(pdev, sensor->irq_name);
> - if (ret < 0)
> - return ret;
> + if (ret <= 0) {
Maybe a simple < is enough? reading it seams awkward. From a glance, I
dont think platform_get_irq* ever returns 0.
> + ret = platform_get_irq(pdev, 0);
> + if (ret <= 0) {
Same here.
> + dev_err(dev, "Failed get interrupt: %d\n", ret);
> + return ret;
> + }
> + }
>
> ret = devm_request_threaded_irq(dev, ret, NULL,
> hisi_thermal_alarm_irq_thread,
> --
> 2.7.4
>
Re: [PATCH v3] thermal: qoriq: add multiple sensors support
On Wed, Nov 21, 2018 at 10:41:36AM +0100, Daniel Lezcano wrote: > On 21/11/2018 10:16, Andy Tang wrote: > > Hi Daniel, > > > > Thanks for your explanation. The problem is these two trees are not synced > > well. > > Let's take our driver(qoriq_thermal.c) for example. > > > > Git log on Rui's tree next branch: > > 2dfef65 thermal: qoriq: Switch to SPDX identifier > > 1a893a5 thermal: qoriq: Simplify the 'site' variable assignment > > f1506a6 thermal: qoriq: Use devm_thermal_zone_of_sensor_register() > > c30d5d5 thermal: qoriq: constify thermal_zone_of_device_ops structures > > 0e77488 thermal: qoriq: remove useless call for of_thermal_get_trip_points() > > 4352844 thermal: qoriq: Add thermal management support > > > > Git log on linux-soc-thermal tree branch next: > > 6017e2a thermal: qoriq: add i.mx8mq support > > 9b96566 thermal: Convert to using %pOFn instead of device_node.name > > c30d5d5 thermal: qoriq: constify thermal_zone_of_device_ops structures > > 0e77488 thermal: qoriq: remove useless call for of_thermal_get_trip_points() > > 4352844 thermal: qoriq: Add thermal management support > > > > You can see that the first 2-3 commits on these two tress are different. > > > > The strange thing is they seems sync well on Linus' tree: > > 0ef7791 Merge branch 'linus' of > > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal > > 6017e2a thermal: qoriq: add i.mx8mq support > > 9b96566 thermal: Convert to using %pOFn instead of device_node.name > > 2dfef65 thermal: qoriq: Switch to SPDX identifier > > 1a893a5 thermal: qoriq: Simplify the 'site' variable assignment > > f1506a6 thermal: qoriq: Use devm_thermal_zone_of_sensor_register() > > c30d5d5 thermal: qoriq: constify thermal_zone_of_device_ops structures > > 0e77488 thermal: qoriq: remove useless call for of_thermal_get_trip_points() > > 4352844 thermal: qoriq: Add thermal management support > > > > Currently my patch was created based on Run's tree, probably I should > > rebase it to soc tree. > > But whichever tree I use, it can't be merged to Linus' tree without > > conflict. > > > > Something I missed? > > No. > > Eduardo, Rui, > > why not create a 'thermal' group ala 'tip' group with a single tree and > two branches: > > thermal/next > thermal/fixes > > - Rui takes the core changes. > - Eduardo takes the SoC changes. > > - Both commit to thermal/next > - Both commit to thermal/fixes > - Both merge thermal/fixes into thermal/core as often as possible. > > That will help to have a more up to date branch, simplify the patch > submission path and reduce the latency for the merge windows. > > If you need help, I can take care of applying the fixes only and merge > them to thermal/next. > > That is how the tip subsystem works, Peter Ziljstra, Ingo Molnar, Thomas > Gleixner, have all permissions to commit in the tip tree but they take > care of their subsystems. If one is away for vacations or whatever, > someone else can take over during the absence. > Yeah, that is a setup people have been following. It does not necessarily mean it will work for all cases though. I believe regardless of process and tree setup what we are lacking here is a documentation of how things are being done. As I mentioned, I will work on writing something up to document at least what we have today before any change in process gets in place. > > > > > >> -Original Message- > >> From: Daniel Lezcano > >> Sent: 2018年11月21日 16:44 > >> To: Andy Tang ; rui.zh...@intel.com; > >> edubez...@gmail.com > >> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org > >> Subject: Re: [PATCH v3] thermal: qoriq: add multiple sensors support > >> > >> On 21/11/2018 02:34, Andy Tang wrote: > >>> Hi all, > >>> > >>> Do you have any comments on this patch? > >>> > >>> I found for our thermal driver(qoriq_thermal.c) there are different > >> between the following two git trees: > >>> git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git > >>> branch: next > >>> > >> git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.gi > >> t. > >>> branch: next > >>> > >>> Could you please clarify which git tree/branch should I use? > >> > >> SoC changes are submitted against linux-soc-thermal.git. > >> > >> Generic thermal framework are sent against Zhang Rui's tree but it > >> happens sometimes Eduardo pick them also when the changes are related > >> to SoC behavior. > >> > >> However, I agree that can be confusing :) > >> > >> Eduardo, Rui, > >> > >> how about to add a section in the maintainer handbook for the thermal to > >> clarify the expectations and the flow? > >> > -Original Message- > From: Andy Tang > Sent: 2018年11月14日 15:29 > To: rui.zh...@intel.com; daniel.lezc...@linaro.org > Cc: edubez...@gmail.com; linux...@vger.kernel.org; > linux-kernel@vger.kernel.org > Subject: RE: [PATCH v3] thermal: qoriq: add multiple sensors support > > PING. > > BR,
Re: [PATCH v3] thermal: qoriq: add multiple sensors support
On Wed, Nov 21, 2018 at 10:41:36AM +0100, Daniel Lezcano wrote: > On 21/11/2018 10:16, Andy Tang wrote: > > Hi Daniel, > > > > Thanks for your explanation. The problem is these two trees are not synced > > well. > > Let's take our driver(qoriq_thermal.c) for example. > > > > Git log on Rui's tree next branch: > > 2dfef65 thermal: qoriq: Switch to SPDX identifier > > 1a893a5 thermal: qoriq: Simplify the 'site' variable assignment > > f1506a6 thermal: qoriq: Use devm_thermal_zone_of_sensor_register() > > c30d5d5 thermal: qoriq: constify thermal_zone_of_device_ops structures > > 0e77488 thermal: qoriq: remove useless call for of_thermal_get_trip_points() > > 4352844 thermal: qoriq: Add thermal management support > > > > Git log on linux-soc-thermal tree branch next: > > 6017e2a thermal: qoriq: add i.mx8mq support > > 9b96566 thermal: Convert to using %pOFn instead of device_node.name > > c30d5d5 thermal: qoriq: constify thermal_zone_of_device_ops structures > > 0e77488 thermal: qoriq: remove useless call for of_thermal_get_trip_points() > > 4352844 thermal: qoriq: Add thermal management support > > > > You can see that the first 2-3 commits on these two tress are different. > > > > The strange thing is they seems sync well on Linus' tree: > > 0ef7791 Merge branch 'linus' of > > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal > > 6017e2a thermal: qoriq: add i.mx8mq support > > 9b96566 thermal: Convert to using %pOFn instead of device_node.name > > 2dfef65 thermal: qoriq: Switch to SPDX identifier > > 1a893a5 thermal: qoriq: Simplify the 'site' variable assignment > > f1506a6 thermal: qoriq: Use devm_thermal_zone_of_sensor_register() > > c30d5d5 thermal: qoriq: constify thermal_zone_of_device_ops structures > > 0e77488 thermal: qoriq: remove useless call for of_thermal_get_trip_points() > > 4352844 thermal: qoriq: Add thermal management support > > > > Currently my patch was created based on Run's tree, probably I should > > rebase it to soc tree. > > But whichever tree I use, it can't be merged to Linus' tree without > > conflict. > > > > Something I missed? > > No. > > Eduardo, Rui, > > why not create a 'thermal' group ala 'tip' group with a single tree and > two branches: > > thermal/next > thermal/fixes > > - Rui takes the core changes. > - Eduardo takes the SoC changes. > > - Both commit to thermal/next > - Both commit to thermal/fixes > - Both merge thermal/fixes into thermal/core as often as possible. > > That will help to have a more up to date branch, simplify the patch > submission path and reduce the latency for the merge windows. > > If you need help, I can take care of applying the fixes only and merge > them to thermal/next. > > That is how the tip subsystem works, Peter Ziljstra, Ingo Molnar, Thomas > Gleixner, have all permissions to commit in the tip tree but they take > care of their subsystems. If one is away for vacations or whatever, > someone else can take over during the absence. > Yeah, that is a setup people have been following. It does not necessarily mean it will work for all cases though. I believe regardless of process and tree setup what we are lacking here is a documentation of how things are being done. As I mentioned, I will work on writing something up to document at least what we have today before any change in process gets in place. > > > > > >> -Original Message- > >> From: Daniel Lezcano > >> Sent: 2018年11月21日 16:44 > >> To: Andy Tang ; rui.zh...@intel.com; > >> edubez...@gmail.com > >> Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org > >> Subject: Re: [PATCH v3] thermal: qoriq: add multiple sensors support > >> > >> On 21/11/2018 02:34, Andy Tang wrote: > >>> Hi all, > >>> > >>> Do you have any comments on this patch? > >>> > >>> I found for our thermal driver(qoriq_thermal.c) there are different > >> between the following two git trees: > >>> git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git > >>> branch: next > >>> > >> git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.gi > >> t. > >>> branch: next > >>> > >>> Could you please clarify which git tree/branch should I use? > >> > >> SoC changes are submitted against linux-soc-thermal.git. > >> > >> Generic thermal framework are sent against Zhang Rui's tree but it > >> happens sometimes Eduardo pick them also when the changes are related > >> to SoC behavior. > >> > >> However, I agree that can be confusing :) > >> > >> Eduardo, Rui, > >> > >> how about to add a section in the maintainer handbook for the thermal to > >> clarify the expectations and the flow? > >> > -Original Message- > From: Andy Tang > Sent: 2018年11月14日 15:29 > To: rui.zh...@intel.com; daniel.lezc...@linaro.org > Cc: edubez...@gmail.com; linux...@vger.kernel.org; > linux-kernel@vger.kernel.org > Subject: RE: [PATCH v3] thermal: qoriq: add multiple sensors support > > PING. > > BR,
Re: [PATCH v3] thermal: qoriq: add multiple sensors support
On Wed, Nov 21, 2018 at 09:16:08AM +, Andy Tang wrote: > Hi Daniel, > > Thanks for your explanation. The problem is these two trees are not synced > well. > Let's take our driver(qoriq_thermal.c) for example. > > Git log on Rui's tree next branch: > 2dfef65 thermal: qoriq: Switch to SPDX identifier > 1a893a5 thermal: qoriq: Simplify the 'site' variable assignment > f1506a6 thermal: qoriq: Use devm_thermal_zone_of_sensor_register() > c30d5d5 thermal: qoriq: constify thermal_zone_of_device_ops structures > 0e77488 thermal: qoriq: remove useless call for of_thermal_get_trip_points() > 4352844 thermal: qoriq: Add thermal management support > > Git log on linux-soc-thermal tree branch next: > 6017e2a thermal: qoriq: add i.mx8mq support > 9b96566 thermal: Convert to using %pOFn instead of device_node.name > c30d5d5 thermal: qoriq: constify thermal_zone_of_device_ops structures > 0e77488 thermal: qoriq: remove useless call for of_thermal_get_trip_points() > 4352844 thermal: qoriq: Add thermal management support > > You can see that the first 2-3 commits on these two tress are different. > > The strange thing is they seems sync well on Linus' tree: > 0ef7791 Merge branch 'linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal > 6017e2a thermal: qoriq: add i.mx8mq support > 9b96566 thermal: Convert to using %pOFn instead of device_node.name > 2dfef65 thermal: qoriq: Switch to SPDX identifier > 1a893a5 thermal: qoriq: Simplify the 'site' variable assignment > f1506a6 thermal: qoriq: Use devm_thermal_zone_of_sensor_register() > c30d5d5 thermal: qoriq: constify thermal_zone_of_device_ops structures > 0e77488 thermal: qoriq: remove useless call for of_thermal_get_trip_points() > 4352844 thermal: qoriq: Add thermal management support > > Currently my patch was created based on Run's tree, probably I should rebase > it to soc tree. > But whichever tree I use, it can't be merged to Linus' tree without conflict. I agree that trees out of sync does not help. However the idea was to have then separate, since couple of merge windows ago. But I believe the issue here is that we do not have some sort of cookbook describing the subsystem process. I will work on describing it and sending a patch to have it documented. > > Something I missed? > > BR, > Andy > > -Original Message- > > From: Daniel Lezcano > > Sent: 2018年11月21日 16:44 > > To: Andy Tang ; rui.zh...@intel.com; > > edubez...@gmail.com > > Cc: linux...@vger.kernel.org; linux-kernel@vger.kernel.org > > Subject: Re: [PATCH v3] thermal: qoriq: add multiple sensors support > > > > On 21/11/2018 02:34, Andy Tang wrote: > > > Hi all, > > > > > > Do you have any comments on this patch? > > > > > > I found for our thermal driver(qoriq_thermal.c) there are different > > between the following two git trees: > > > git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git > > > branch: next > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.gi > > t. > > > branch: next > > > > > > Could you please clarify which git tree/branch should I use? > > > > SoC changes are submitted against linux-soc-thermal.git. > > > > Generic thermal framework are sent against Zhang Rui's tree but it > > happens sometimes Eduardo pick them also when the changes are related > > to SoC behavior. > > > > However, I agree that can be confusing :) > > > > Eduardo, Rui, > > > > how about to add a section in the maintainer handbook for the thermal to > > clarify the expectations and the flow? > > > > >> -Original Message- > > >> From: Andy Tang > > >> Sent: 2018年11月14日 15:29 > > >> To: rui.zh...@intel.com; daniel.lezc...@linaro.org > > >> Cc: edubez...@gmail.com; linux...@vger.kernel.org; > > >> linux-kernel@vger.kernel.org > > >> Subject: RE: [PATCH v3] thermal: qoriq: add multiple sensors support > > >> > > >> PING. > > >> > > >> BR, > > >> Andy > > >> > > >>> -Original Message- > > >>> From: andy.t...@nxp.com > > >>> Sent: 2018年10月30日 9:00 > > >>> To: rui.zh...@intel.com; daniel.lezc...@linaro.org > > >>> Cc: edubez...@gmail.com; linux...@vger.kernel.org; > > >>> linux-kernel@vger.kernel.org; Andy Tang > > >>> Subject: [PATCH v3] thermal: qoriq: add multiple sensors support > > >>> > > >>> From: Yuantian Tang > > >>> > > >>> The QorIQ Layerscape SoC has several thermal sensors but the > > current > > >>> driver only supports one. > > >>> > > >>> Massage the code to be sensor oriented and allow the support for > > >>> multiple sensors. > > >>> > > >>> Signed-off-by: Yuantian Tang > > >>> Reviewed-by: Daniel Lezcano > > >>> --- > > >>> v3: > > >>> - add Reviewed-by > > >>> v2: > > >>> - update the commit message > > >>> - refine the qoriq_tmu_register_tmu_zone() > > >>> > > >>> drivers/thermal/qoriq_thermal.c | 100 > > >>> ++- > > >>> 1 files changed, 46 insertions(+), 54 deletions(-) > > >>> > > >>> diff --git a/drivers/thermal/qoriq_thermal.c
