From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752738AbdDCNVx convert rfc822-to-8bit (ORCPT ); Mon, 3 Apr 2017 09:21:53 -0400 Received: from mail1.bemta3.messagelabs.com ([195.245.230.164]:46888 "EHLO mail1.bemta3.messagelabs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751732AbdDCNVt (ORCPT ); Mon, 3 Apr 2017 09:21:49 -0400 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkk+JIrShJLcpLzFFi42KJ27nUWDfC51G EQedJQYupD5+wWcw/co7V4vCiF4wW869cY7W4//Uoo8W3Kx1MFjc/fWO1uLxrDpvF594jjBY3 1u1jt3iy8AyTxcKmFnaLpdcvMlm07j0CFHvYx2Zxa8YLVgcBjzXz1jB67Jx1l93j2mYxj8V7X jJ5bFrVyeZx59oeNo+d3xvYPT5vkgvgiGLNzEvKr0hgzVg/ZRNzwSvJipP35rM2MHaIdjFycg gJLGGUWNBuCmKzCRhKzHvznhHEFhHwkXi46gF7FyMXB7PAHRaJ3UfmgCWEBeIlnp/8B1WUIHH /214mCNtK4s3W76xdjBwcLAIqEn/m5oOYvAIBEud32IGMERI4ySixt+0fG0g5p4C1xJRft8Fs RgFZiS+Nq5lBbGYBcYlbT+aDjZQQEJBYsuc8M4QtKvHy8T9WCFteYu2vJ1Bxe4nX996xQNj6E o8eP2KEsA0lVk07ABU3l1h5oZ0dYr6OxILdn9ggbG2JZQtfg83hFRCUODnzCcsERvFZSM6Yha RlFpKWWUhaFjCyrGLUKE4tKkst0jUy1ksqykzPKMlNzMzRNTQw1stNLS5OTE/NSUwq1kvOz93 ECEwa9QwMjDsY+/b6HWKU5GBSEuX9oPAoQogvKT+lMiOxOCO+qDQntfgQowwHh5IEr6U3UE6w KDU9tSItMweYvmDSEhw8SiK8XCBp3uKCxNzizHSI1ClGRSlx3iiQhABIIqM0D64NljIvMcpKC fMyMjAwCPEUpBblZpagyr9iFOdgVBLmjQaZwpOZVwI3/RXQYiagxU/uPARZXJKIkJJqYNydnz yb5/n+P0XNwjZ/Zl/9cHVJd6JsSmCUTlO240sZG16W+8kVSu5O63h2Mxg7d6et9TVNq9JS7du guvzxwuWvDaOEHINmq7esN7hfVj7/i/TaKUWaCQv2GG5yj7hlJSGxWXDyvtltd4+33Gmafn2D 04Pwg393iPW8Dzx+4G2C7IMNj9qftimxFGckGmoxFxUnAgDi/lqAlAMAAA== X-Env-Sender: stwiss.opensource@diasemi.com X-Msg-Ref: server-13.tower-39.messagelabs.com!1491225686!87057745!1 X-Originating-IP: [94.185.165.51] X-StarScan-Received: X-StarScan-Version: 9.2.3; banners=-,-,- X-VirusChecked: Checked From: Steve Twiss To: Eduardo Valentin , Lee Jones CC: LINUX-KERNEL , LINUX-PM , Zhang Rui , DEVICETREE , Dmitry Torokhov , Guenter Roeck , LINUX-INPUT , LINUX-WATCHDOG , Liam Girdwood , "Lukasz Luba" , Mark Brown , Mark Rutland , Rob Herring , Support Opensource , Wim Van Sebroeck Subject: RE: [PATCH V7 6/7] thermal: da9062/61: Thermal junction temperature monitoring driver Thread-Topic: [PATCH V7 6/7] thermal: da9062/61: Thermal junction temperature monitoring driver Thread-Index: AQHSp9MgSoFz+eOe5UCfAojmTMt8QKGw5HoAgAKZzEA= Date: Mon, 3 Apr 2017 13:21:19 +0000 Message-ID: <6ED8E3B22081A4459DAC7699F3695FB7018CD6B0A2@SW-EX-MBX02.diasemi.com> References: <2c1ee249b6746ae3914041a4fc106c89a561f7de.1490712213.git.stwiss.opensource@diasemi.com> <20170401195916.GF28514@localhost.localdomain> In-Reply-To: <20170401195916.GF28514@localhost.localdomain> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.26.77] x-kse-attachmentfiltering-interceptor-info: protection disabled x-kse-serverinfo: sw-ex-cashub02.diasemi.com, 9 x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean, bases: 03/04/2017 09:54:00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01 April 2017 @20:59, Eduardo Valentin wrote: > Subject: Re: [PATCH V7 6/7] thermal: da9062/61: Thermal junction temperature monitoring driver > > On Tue, Mar 28, 2017 at 03:43:33PM +0100, Steve Twiss wrote: > > From: Steve Twiss > > > > Add junction temperature monitoring supervisor device driver, compatible > > with the DA9062 and DA9061 PMICs. A MODULE_DEVICE_TABLE() macro is added. > > > > If the PMIC's internal junction temperature rises above T_WARN (125 degC) > > an interrupt is issued. This T_WARN level is defined as the > > THERMAL_TRIP_HOT trip-wire inside the device driver. > > > > The thermal triggering mechanism is interrupt based and happens when the > > temperature rises above a given threshold level. The component cannot > > return an exact temperature, it only has knowledge if the temperature is > > above or below a given threshold value. A status bit must be polled to > > detect when the temperature falls below that threshold level again. A > > kernel work queue is configured to repeatedly poll and detect when the > > temperature falls below this trip-wire, between 1 and 10 second intervals > > (defaulting at 3 seconds). > > > > This scheme is provided as an example. It would be expected that any > > final implementation will also include a notify() function and any of these > > settings could be altered to match the application where appropriate. > > > > When over-temperature is reached, the interrupt from the DA9061/2 will be > > repeatedly triggered. The IRQ is therefore disabled when the first > > over-temperature event happens and the status bit is polled using a > > work-queue until it becomes false. > > > > This strategy is designed to allow the periodic transmission of uevents > > (HOT trip point) as the first level of temperature supervision method. It > > is intended for non-invasive temperature control, where the necessary > > measures for cooling the system down are left to the host software. Once > > the temperature falls again, the IRQ is re-enabled so a new critical > > over-temperature event can be detected. > > > > Reviewed-by: Lukasz Luba > > Signed-off-by: Steve Twiss > > I have had a look on the history of this driver on its previous > versions, and I do not think I have any other point to request on it. Thank you. > Obviously, I still need to state that I do not like its oddness as it is > not really benefiting much of the thermal control implemented on the > thermal subsystem. Agreed. But, it should be useful in the case of an over-temperature in the system PMIC when the OS needs to be notified to bring core temperature under control. > What is the plan for this series? Am I expected to get this driver > through thermal tree ? Or is this series going into a one shot? > > If option 1 is the expected, would the driver need to get its > mfd parent merged first? Other components such as the ONKEY and Watchdog have not required the MFD to be merged first. I don't see any strong dependency for the MFD to exist with this thermal component. I'm not sure how much Lee is waiting for Acks to exist before proceeding with the MFD. I have TO:'d Lee Jones, for this case. Regards, Steve From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from mail1.bemta3.messagelabs.com ([195.245.230.164]:46888 "EHLO mail1.bemta3.messagelabs.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751732AbdDCNVt (ORCPT ); Mon, 3 Apr 2017 09:21:49 -0400 From: Steve Twiss To: Eduardo Valentin , Lee Jones CC: LINUX-KERNEL , LINUX-PM , Zhang Rui , DEVICETREE , Dmitry Torokhov , Guenter Roeck , LINUX-INPUT , LINUX-WATCHDOG , Liam Girdwood , "Lukasz Luba" , Mark Brown , Mark Rutland , Rob Herring , Support Opensource , Wim Van Sebroeck Subject: RE: [PATCH V7 6/7] thermal: da9062/61: Thermal junction temperature monitoring driver Date: Mon, 3 Apr 2017 13:21:19 +0000 Message-ID: <6ED8E3B22081A4459DAC7699F3695FB7018CD6B0A2@SW-EX-MBX02.diasemi.com> References: <2c1ee249b6746ae3914041a4fc106c89a561f7de.1490712213.git.stwiss.opensource@diasemi.com> <20170401195916.GF28514@localhost.localdomain> In-Reply-To: <20170401195916.GF28514@localhost.localdomain> Content-Language: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Sender: linux-watchdog-owner@vger.kernel.org List-Id: linux-watchdog@vger.kernel.org Content-Transfer-Encoding: quoted-printable On 01 April 2017 @20:59, Eduardo Valentin wrote: > Subject: Re: [PATCH V7 6/7] thermal: da9062/61: Thermal junction temper= ature monitoring driver >=20 > On Tue, Mar 28, 2017 at 03:43:33PM +0100, Steve Twiss wrote: > > From: Steve Twiss > > > > Add junction temperature monitoring supervisor device driver, compati= ble > > with the DA9062 and DA9061 PMICs. A MODULE_DEVICE_TABLE() macro is ad= ded. > > > > If the PMIC's internal junction temperature rises above T_WARN (125 d= egC) > > an interrupt is issued. This T_WARN level is defined as the > > THERMAL_TRIP_HOT trip-wire inside the device driver. > > > > The thermal triggering mechanism is interrupt based and happens when = the > > temperature rises above a given threshold level. The component cannot > > return an exact temperature, it only has knowledge if the temperature= is > > above or below a given threshold value. A status bit must be polled t= o > > detect when the temperature falls below that threshold level again. A > > kernel work queue is configured to repeatedly poll and detect when th= e > > temperature falls below this trip-wire, between 1 and 10 second inter= vals > > (defaulting at 3 seconds). > > > > This scheme is provided as an example. It would be expected that any > > final implementation will also include a notify() function and any of= these > > settings could be altered to match the application where appropriate. > > > > When over-temperature is reached, the interrupt from the DA9061/2 wil= l be > > repeatedly triggered. The IRQ is therefore disabled when the first > > over-temperature event happens and the status bit is polled using a > > work-queue until it becomes false. > > > > This strategy is designed to allow the periodic transmission of ueven= ts > > (HOT trip point) as the first level of temperature supervision method= . It > > is intended for non-invasive temperature control, where the necessary > > measures for cooling the system down are left to the host software. O= nce > > the temperature falls again, the IRQ is re-enabled so a new critical > > over-temperature event can be detected. > > > > Reviewed-by: Lukasz Luba > > Signed-off-by: Steve Twiss >=20 > I have had a look on the history of this driver on its previous > versions, and I do not think I have any other point to request on it. Thank you. > Obviously, I still need to state that I do not like its oddness as it i= s > not really benefiting much of the thermal control implemented on the > thermal subsystem. Agreed. But, it should be useful in the case of an over-temperature in the system= PMIC=20 when the OS needs to be notified to bring core temperature under control. > What is the plan for this series? Am I expected to get this driver > through thermal tree ? Or is this series going into a one shot? >=20 > If option 1 is the expected, would the driver need to get its > mfd parent merged first? Other components such as the ONKEY and Watchdog have not required the MFD to be merged first. I don't see any strong dependency for the MFD to exis= t with this thermal component. I'm not sure how much Lee is waiting for Acks to exist before proceeding = with the MFD. I have TO:'d Lee Jones, for this case. Regards, Steve -- To unsubscribe from this list: send the line "unsubscribe linux-watchdog"= in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html