From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Branden Subject: Re: [PATCH v5 2/2] thermal: add brcmstb AVS TMON driver Date: Tue, 26 Sep 2017 15:17:40 -0700 Message-ID: <5245cf8e-d35f-c1fd-b7ea-e3a58c468688@broadcom.com> References: <20170926212800.4879-1-code@mmayer.net> <20170926212800.4879-3-code@mmayer.net> <4cb98266-6936-7668-fc88-199ac907b437@broadcom.com> <9bdd9959-da47-9adb-e550-31bf06254310@broadcom.com> <9587b134-9727-d7cb-7a46-6df5ee4a0494@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <9587b134-9727-d7cb-7a46-6df5ee4a0494@gmail.com> Sender: linux-pm-owner@vger.kernel.org To: Florian Fainelli , Markus Mayer Cc: Zhang Rui , Eduardo Valentin , Rob Herring , Mark Rutland , Doug Berger , Brian Norris , Gregory Fong , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= , Broadcom Kernel List , Power Management List , Device Tree List , ARM Kernel List , Linux Kernel Mailing List , Markus Mayer List-Id: devicetree@vger.kernel.org On 17-09-26 03:14 PM, Florian Fainelli wrote: > On 09/26/2017 03:08 PM, Scott Branden wrote: >> >> On 17-09-26 02:38 PM, Markus Mayer wrote: >>> On 26 September 2017 at 14:32, Scott Branden >>> wrote: >>>> Hi Markus, >>>> >>>> >>>> On 17-09-26 02:27 PM, Markus Mayer wrote: >>>>> From: Brian Norris >>>>> >>>>> The AVS TMON core provides temperature readings, a pair of configurable >>>>> high- and low-temperature threshold interrupts, and an emergency >>>>> over-temperature chip reset. The driver utilizes the first two to >>>>> provide temperature readings and high-temperature notifications to >>>>> applications. The over-temperature reset is not exposed to >>>>> applications; this reset threshold is critical to the system and should >>>>> be set with care within the bootloader. >>>>> >>>>> Applications may choose to utilize the notification mechanism, the >>>>> temperature reading mechanism (e.g., through polling), or both. >>>>> >>>>> Signed-off-by: Brian Norris >>>>> Signed-off-by: Doug Berger >>>>> Signed-off-by: Markus Mayer >>>>> --- >>>>> drivers/thermal/Kconfig | 2 +- >>>>> drivers/thermal/broadcom/Kconfig | 7 + >>>>> drivers/thermal/broadcom/Makefile | 1 + >>>>> drivers/thermal/broadcom/brcmstb_thermal.c | 387 >>>>> +++++++++++++++++++++++++++++ >>>>> 4 files changed, 396 insertions(+), 1 deletion(-) >>>>> create mode 100644 drivers/thermal/broadcom/brcmstb_thermal.c >>>>> >>>>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig >>>>> index 07002df..96774a7 100644 >>>>> --- a/drivers/thermal/Kconfig >>>>> +++ b/drivers/thermal/Kconfig >>>>> @@ -408,7 +408,7 @@ config MTK_THERMAL >>>>> controller present in Mediatek SoCs >>>>> menu "Broadcom thermal drivers" >>>>> -depends on ARCH_BCM || COMPILE_TEST >>>>> +depends on ARCH_BCM || ARCH_BRCMSTB || COMPILE_TEST >>>> No need for this additional depends. ARCH_BCM is always defined before >>>> ARCH_BRCMSTB can be selected. >>> ARCH_BCM does not exist in arch/arm64/configs/defconfig. ARCH_BRCMSTB >>> does. So, we do need both or the driver won't be built on ARM64. >>> (After internal discussions we went with that approach rather than >>> defining ARCH_BCM on ARM64.) >> Got it. Looking at our internal iproc tree I see we've done exactly the >> same with ARCH_BCM_IPROC needing to be added. We haven't upstreamed >> the thermal driver needing it yet. >> >> Perhaps we should add ARCH_BCM to ARM64.... > If it is just added to satisfy dependencies, I don't see much value in > doing that. It does make sense in the ARM v7 multiplatform context, but > outside of that, not so sur. OK - we'll just continue to add ARCH_BCM_IPROC || ARCH_BRCMSTB everywhere as needed.