Received: by 10.213.65.68 with SMTP id h4csp840422imn; Wed, 28 Mar 2018 13:56:57 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+MKep8+E8LWPpBuctuGR+EWgurfHaDx/i9ZO7tQB28o7q8pfrIPx8LyT6D9V/JGVPXcBH7 X-Received: by 2002:a17:902:b10c:: with SMTP id q12-v6mr5220492plr.399.1522270617176; Wed, 28 Mar 2018 13:56:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522270617; cv=none; d=google.com; s=arc-20160816; b=gHvJd2w//vQjSybOVpTjNdbaQqeOTLiYAUqbhjVdIHrPR6D6uPfZ2nvEv3vf5plM/w 7gLALJoe2A3l6nf7CRuAYhMo+T/nVXErjJqLzWkXwdxlNK/8TBdmWsG/d9LvzrUOqCh0 jAQtleha+lqwEJMiXvgh4ynqgtwdpn2AFiGinkXwvreWosV4GWWIPodFudedfsPendD5 aqQAXeBotE2kXftT1VOHYvhu2/ZNf++Pw88iyhPKTKos0d4F4+oAltkZrPaJPrWoZvNs FyIukwzzoHugb1tpKJs6w01ONQ/JXK2KvGRpHX2bGVDLiH2eKipD3twmw1c1ag0iOiLy KV+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=SIOC4I1q0hC/VffXem2RxkLKkYAgM5AzEMHYV9QswnU=; b=nAPWklYf+M7sbUxj0x/FJ3EvcueL7Iv9wLmmbLqD3svtOmLgx7rOTn2VB9Ywtql1t/ YRVqQOuWX6yg8CCEilo4sL0syL9tkFDul2oLil62Toh1xHC9zm9ggk9hCMPJA/H1C/+L Qk76B6Y2t3KAjGaKXRW86KraxC1g8S1C8gk56RC577s54+ln0eZUznpZ74nQ+6I6oFFS DCdvvvObVUs7sG0kEptCIiXZIfln9ePHcbiG95XOjGOcRBpL6dfMK6r/v5bgLp+9CvQ8 1ZIyVejwqM5DplecPda2f8QehHt9cvujSlSHftCFuSIz3jRt/57ZIFX3USLQQSC4rNSn cWMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gateworks-com.20150623.gappssmtp.com header.s=20150623 header.b=L+sgAenV; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c3-v6si4326961pld.545.2018.03.28.13.56.43; Wed, 28 Mar 2018 13:56:57 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gateworks-com.20150623.gappssmtp.com header.s=20150623 header.b=L+sgAenV; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753305AbeC1Ux7 (ORCPT + 99 others); Wed, 28 Mar 2018 16:53:59 -0400 Received: from mail-wr0-f195.google.com ([209.85.128.195]:42527 "EHLO mail-wr0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753228AbeC1Ux4 (ORCPT ); Wed, 28 Mar 2018 16:53:56 -0400 Received: by mail-wr0-f195.google.com with SMTP id s18so3468157wrg.9 for ; Wed, 28 Mar 2018 13:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gateworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SIOC4I1q0hC/VffXem2RxkLKkYAgM5AzEMHYV9QswnU=; b=L+sgAenVdCC36B9IDqVrh13nEoWOWn5TH8xUzqI9xC8YUV5TOk/WwAngMHn7rzXX0O T8iJ4jBGx0OaOLax+ABZgd/7E0AmSzd1WewWLd+LHrOuaM9wOUpU8RyMEn7na+X08vXD c8kI5rygEYByssogo7XQlUc3UglL0J24T53ZBG5vKLZOqwRuae0ErSwWJt3K6ebLKBxi ZoH8sucDzEt+hRr43zUGzqetTViTzXw2AS0w6cXS8QaiM/snemSmHXf5ZiPT7jOtrL7M 90Dc8/ghn3YtymcUC0TnpUSyeQsusCQ13l8XHnvUbZjGb/PR0pL1/4sZfkwZ27GA1Uib 6BzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SIOC4I1q0hC/VffXem2RxkLKkYAgM5AzEMHYV9QswnU=; b=F6Ji3I6ysgoU9MbUUTNlX1m00yNpMDuzM6FkA1Jm7sChVwAs10Nm79QSkbmMZ07OTk JaGMGJKUp+MV6geRUM/HWwZstiPbr0yhT3bS0bz6gM6whFnw5lGhzyexsi6T+n8F3LHO Z5jk666/2FvewugLCbJ7U4yFaohR9QyuNLCumgyKXcRcKkDIeENqtKxIG0oBPikVBfHc PopXHwLGlGtanGFi4X3p3gErdDtXI6r0DcXsDUm8zHpTXXZG3kbul8UKCrJb6MN/0g42 zOdk1O+n+3vUdust80uorMqN+2V66sNMYkbO7uty1z7Ci+zHpAmJ8pAniPdmOMmhQIT/ 7Cgg== X-Gm-Message-State: AElRT7GtTZCPtI96r1Dc5D7lhoromgU50t/GBLRv+b+2cjEQAxH7AuU3 hkvBO8F2L0+mPPFDrJjzp6uBv5E630CzxSoNB4YTkg== X-Received: by 10.223.129.199 with SMTP id 65mr4187452wra.159.1522270434504; Wed, 28 Mar 2018 13:53:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.6.66 with HTTP; Wed, 28 Mar 2018 13:53:53 -0700 (PDT) In-Reply-To: <20180328202321.GA21664@roeck-us.net> References: <1522250043-8065-1-git-send-email-tharvey@gateworks.com> <1522250043-8065-2-git-send-email-tharvey@gateworks.com> <20180328162416.GB25325@roeck-us.net> <20180328202321.GA21664@roeck-us.net> From: Tim Harvey Date: Wed, 28 Mar 2018 13:53:53 -0700 Message-ID: Subject: Re: [PATCH v3 1/4] dt-bindings: mfd: Add Gateworks System Controller bindings To: Guenter Roeck Cc: Lee Jones , Rob Herring , Mark Rutland , Mark Brown , Dmitry Torokhov , Wim Van Sebroeck , linux-kernel@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-hwmon@vger.kernel.org, linux-input@vger.kernel.org, linux-watchdog@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 28, 2018 at 1:23 PM, Guenter Roeck wrote: > On Wed, Mar 28, 2018 at 12:17:34PM -0700, Tim Harvey wrote: >> On Wed, Mar 28, 2018 at 9:24 AM, Guenter Roeck wrote: >> > On Wed, Mar 28, 2018 at 08:14:00AM -0700, Tim Harvey wrote: >> >> This patch adds documentation of device-tree bindings for the >> >> Gateworks System Controller (GSC). >> >> >> >> Signed-off-by: Tim Harvey >> >> --- >> >> v3: >> >> - replaced _ with - >> >> - remove input bindings >> >> - added full description of hwmon >> >> - fix unit address of hwmon child nodes >> >> >> >> --- >> >> .../devicetree/bindings/mfd/gateworks-gsc.txt | 135 +++++++++++++++++++++ >> >> 1 file changed, 135 insertions(+) >> >> create mode 100644 Documentation/devicetree/bindings/mfd/gateworks-gsc.txt >> >> >> >> diff --git a/Documentation/devicetree/bindings/mfd/gateworks-gsc.txt b/Documentation/devicetree/bindings/mfd/gateworks-gsc.txt >> >> new file mode 100644 >> >> index 0000000..8f530ed >> >> --- /dev/null >> >> +++ b/Documentation/devicetree/bindings/mfd/gateworks-gsc.txt >> >> @@ -0,0 +1,135 @@ >> >> +Gateworks System Controller multi-function device >> >> + >> >> +The GSC is a Multifunction I2C slave device with the following submodules: >> >> +- WDT >> >> +- GPIO >> >> +- Pushbutton controller >> >> +- HWMON >> >> + >> >> +Required properties: >> >> +- compatible : Must be "gw,gsc" >> >> +- reg: I2C address of the device >> >> +- interrupts: interrupt triggered by GSC_IRQ# signal >> >> +- interrupt-parent: Interrupt controller GSC is connected to >> >> +- #interrupt-cells: should be <1>, index of the interrupt within the >> >> + controller, in accordance with the "one cell" variant of >> >> + >> >> + >> >> +Optional nodes: >> >> +* watchdog: >> >> +The GSC provides a Watchdog monitor which can power cycle the board's >> >> +primary power supply on most board models when tripped. >> >> + >> >> +Required watchdog properties: >> >> +- compatible: must be "gw,gsc-watchdog" >> >> + >> >> +* hwmon: >> >> +The GSC provides a set of Analog to Digitcal Converter (ADC) pins used for >> >> +temperature and/or voltage monitoring. >> >> + >> >> +Required hwmon properties: >> >> +- compatible: must be "gw,gsc-hwmon" >> >> + >> > >> > "hwmon" is a very Linux specific term. It might make sense to find a more >> > generic term. >> >> The 'hwmon' driver supports child nodes that fall into the following category: >> - temperature sensor (GSC internal temperature sensor - i2c registers >> returns value in C*10) >> - voltage rails (two types here; cooked: i2c registers return >> pre-scaled value in mV), raw: i2c registers return a raw ADC value >> that must be scaled based on ADC internal ref voltage and resolution >> and adjusted for a voltage divider to convert to mV >> - fan setpoints (I'll explain these below) >> >> I called the node 'gw,gsc-hwmon' because the driver fits into the >> 'hwmon' API. Isn't that appropriate here for the driver compatible >> string? >> > > Devicetree properties are supposed to be OS independent. > >> > >> >> +Optional hwmon properties: >> >> +- gw,reference-voltage: ADC reference voltage (mV) used in scaling raw ADCs >> > >> > AFAIK devicetree likes to specify voltages in uV. >> >> There are currently plenty of dt props specified in mV (grep -r mV >> Documentation/devicetree/bindings/). >> > > "But so many others are speeding, why do I get a ticket ?" > > Please discuss with Rob. Yes - hoping for feedback on mV vs uV as well as naming of hwmon mfd child node. > >> > >> >> +- gw,resolution: ADC resolution (ie 4096) used in scaling raw ADCs >> >> + >> > >> > 4096 what ? >> >> reference-voltage and resolution are used to scale the values from the >> nodes that report a raw ADC value: >> >> V = Vadc * (reference-voltage / resolution) >> >> I can provide that in bits if it makes more sense? I can also hard > > Yes, I think that would make more sense, and please describe what it means. > >> code both the resolution and the vref in the hwmon driver and remove >> it from dt as currently the only GSC that uses raw ADC values is 12bit >> with 2.5V ref. >> > > That would be even better. > >> > >> >> +Each hwmon child node defines an ADC input on the chip which the GSC may >> >> +report cooked values (ie temperature sensor based on thermister), raw values, >> >> +(ie voltage rail with a pre-scaling resistor divider), or a fan controller >> >> +setpoint. >> >> + >> >> +Required hwmon child properties: >> >> +- type: one of the following ADC types: >> >> + "gw,hwmon-temperature" - reports temperature in C*10 >> >> + "gw,hwmon-voltage" - reports a pre-scaled voltage value >> >> + "gw,hwmon-voltage-raw" - reports a raw ADC that is scaled with >> >> + vreference, resolution, and optional resistor divider >> >> + "gw,hwmon-fan" - a fan temperature setpoint in C*10 >> > >> > What is a "fan temperature setpoint" ? >> > >> >> The GSC supports a fan controller which drives a PWM signal to vary >> the speed of a fan based on the GSC internal temperature sensor. The >> FAN controller has 6 setpoints each having a fixed PWM duty-cycle but >> the temperature at which those setpoints kick in can be varies via >> registers at the 0x29 slave address (same slave address as the >> temperature sensor and voltage inputs which is why I have it in the >> hwmon driver): >> >> fan0_point - 50% PWM (default 300) >> fan1_point - 60% PWM (default 330) >> fan2_point - 70% PWM (default 360) >> fan3_point - 80% PWM (default 390) >> fan4_point - 90% PWM (default 420) >> fan5_point - 100% PWM (default 450) >> >> The values are C/10 thus if the internal GSC temp sensor is below 30C >> the fan output will be 0% duty cycle and if it hits 30C it will go to >> 50% until it hits 60% at 33C etc. >> > Please do not define your own scaling factors. pwm values are 0..255, > and temperatures are in milli-degrees C. > >> That is the hardware implementation that I'm trying to abstract and >> define here. You pointed out the fact that the fan*_input ABI is >> read-only fan PWM and I see that now. What do you suggest I use for > > No, it isn't. It is the fan speed in RPM. > >> this feature I'm trying to implement driver support for? >> > > pwm[1-*]_auto_point[1-*]_pwm > pwm[1-*]_auto_point[1-*]_temp > pwm[1-*]_auto_point[1-*]_temp_hyst > > may be relevant. From the context, something like > > pwm1_auto_point1_pwm read-only, set to 128 > pwm1_auto_point1_temp 30000 > pwm1_auto_point2_pwm read-only, set to 153 > pwm1_auto_point2_temp 33000 > pwm1_auto_point3_pwm read-only, set to 179 > pwm1_auto_point3_temp 36000 > pwm1_auto_point4_pwm read-only, set to 204 > pwm1_auto_point4_temp 39000 > pwm1_auto_point5_pwm read-only, set to 230 > pwm1_auto_point5_temp 42000 > pwm1_auto_point6_pwm read-only, set to 255 > pwm1_auto_point6_temp 45000 > > might make sense. I like that idea! The details of the setpoints do not need to be in the dts at all. I will need to add a single property to signify that the board has a fan controller as some don't. Thanks, Tim