Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp6255197ybi; Wed, 29 May 2019 05:20:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqyWz4I0Kt3C4FqQ+EtaNyUUSmX80uAa34x05J/g+JaWmSzh0P9WP261B9wF1XAOz8nMoCGA X-Received: by 2002:a17:90a:9303:: with SMTP id p3mr11516091pjo.23.1559132437207; Wed, 29 May 2019 05:20:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1559132437; cv=none; d=google.com; s=arc-20160816; b=HUyycqG7IySYeG+C088y5JSMEW7Im7O+XOfeUpJRkyHkbEnXechvfqIKEH+JX0ZqhB eYE/ZXdqphUU9N0xHM6zQEzutkarib4yokNju7SYdb903caU/xnSXvn60lNhDPt5WUEm xaVEiqViqhSth73c+ssV5VYsGeJ+Qj0VhGXrECCDJGORNiKEwLH177zLRcs2gajpoQrb WpmMNJISy0MVC0/5/LNrj/KhKjCpbIgXASj1/zLr7yW87DMSsTCnkuSitoi9TMtvbRhX bpWZ9TwDKV6EgN05dCH0ohM+wS5DMn92kPxtZL8OasYH6t3AMHJp/pxILEg2WcqcWi1i Gfqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=mZGYAq4lrxI2qWiiWxL3lpOyDLunU7v+t9aRbr1rHp8=; b=BbdW8Oyx0nwITn2ZtSZcrjVNijMXS42Tfd00FJrHRTFP/2gDsy0mv2cTGI3iR3FDOX dG0/aqBFW+Qy9pXofm0e1mqoek8ypj80vnrCmTSVSlOZYBor9jJGOcxU8fTKm9iAt1pt m2NTnUT0WxLu2NWiGo4XFfFz6Ksvh1MQ5fiydGa4f5yd/ewHl2hPKJDE2PgLOTYuzUNJ 6bWjsuWE6/ynnbYGPYcNHFmkaec164kJtHVOfDsUy94jYPx/uOgTgMTbp1CIGoM3QQED wD9ODqoiQ2xksYcegELkMSta1M2bFKbSV3KD4qN11g8oLKtecG8np8s+mroacdfgXkPy cWyA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=CL6q6NMe; 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 cg12si19593272plb.19.2019.05.29.05.20.19; Wed, 29 May 2019 05:20:37 -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=fail header.i=@gmail.com header.s=20161025 header.b=CL6q6NMe; 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 S1726836AbfE2MRw (ORCPT + 99 others); Wed, 29 May 2019 08:17:52 -0400 Received: from mail-pl1-f195.google.com ([209.85.214.195]:45608 "EHLO mail-pl1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726018AbfE2MRw (ORCPT ); Wed, 29 May 2019 08:17:52 -0400 Received: by mail-pl1-f195.google.com with SMTP id x7so5695plr.12; Wed, 29 May 2019 05:17:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=mZGYAq4lrxI2qWiiWxL3lpOyDLunU7v+t9aRbr1rHp8=; b=CL6q6NMeOqQUjc9NkgirjFhLDh1c+E1+vli8m+xou8kg05LTROFN+N5zGYAuNfRMAI vRyFzf7S0YPaw/C1kp3FpZTkAGxAF0bVrb+mx7jDyiKhG46VQOZgWeIU0nyEAtF63GuD qMO+MiUZJ2Uw5Zdbf1Ausp7sM0lFl6DXFsBdjb+uSMmzzV57eDa0nkWmh2UNvEcZVKdx XVQrYp3A8PRvs1NNe73Aj0HXIAqZ+eq3Epw90/TxXH+MmHNN7oj6t2ehGzMX19498ZwG ILWSG3HKh8wvJLHhv0TQUWdeewmTQqonvyCOu5JAEMJpiMad/yseLCVpg5h27pgFsjsD qzIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=mZGYAq4lrxI2qWiiWxL3lpOyDLunU7v+t9aRbr1rHp8=; b=ZLWB+CXDsIh49zdqkqtFsstpjZFnN9iFRFk50te1FDKCiNwjBXxdiDiNLpMkiuwB5Y L8U5xETyKmeauDeBlZuDUtwwxwB/caAZIwf7Ul6hOe+70+D7/utL3OkMez+wdzGvtLKa tH5fQ0lcSmGuIeFd3jE8CP0zNCkRXN4mpvMVZ1EIV7wUo/0o4PzObCdbYZ93+llgWUPE 5pmOp5hZbE8FUAMUMfCxXFsBlHK6FAEIgBjBXze50vhbjFhjluXFzyIat1Z3qLXOKTlL 0BgQkJD9Ybx11cnSAVZxnM9OBeL9DtHon5Xyy1LNYI6aM7nWamCoeHbJctnBDz4kOsvS HRwA== X-Gm-Message-State: APjAAAWwRNw3Kty60NeZIoJiJKdE+CLh8xl38ShiKoyPyjYtBZWYFdbX LwzJWLJGJu6F36cP9SXSMVg= X-Received: by 2002:a17:902:20e2:: with SMTP id v31mr140817199plg.138.1559132271167; Wed, 29 May 2019 05:17:51 -0700 (PDT) Received: from server.roeck-us.net ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id c17sm18960538pfo.114.2019.05.29.05.17.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 29 May 2019 05:17:49 -0700 (PDT) Subject: Re: [PATCH] adm1275: support PMBUS_VIRT_*_SAMPLES To: "Adamski, Krzysztof (Nokia - PL/Wroclaw)" Cc: Jean Delvare , "linux-hwmon@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "Sverdlin, Alexander (Nokia - DE/Ulm)" References: <20190524124841.GA25728@localhost.localdomain> <20190528194652.GE24853@roeck-us.net> <20190529071027.GA6524@localhost.localdomain> From: Guenter Roeck Message-ID: Date: Wed, 29 May 2019 05:17:47 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190529071027.GA6524@localhost.localdomain> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/29/19 12:11 AM, Adamski, Krzysztof (Nokia - PL/Wroclaw) wrote: > On Tue, May 28, 2019 at 12:46:52PM -0700, Guenter Roeck wrote: >> On Fri, May 24, 2019 at 12:49:13PM +0000, Adamski, Krzysztof (Nokia - PL/Wroclaw) wrote: >>> The device supports setting the number of samples for averaging the >>> measurements. There are two separate settings - PWR_AVG for averaging >>> PIN and VI_AVG for averaging VIN/VAUX/IOUT, both being part of >>> PMON_CONFIG register. The values are stored as exponent of base 2 of the >>> actual number of samples that will be taken. >>> >>> Signed-off-by: Krzysztof Adamski >>> --- >>> drivers/hwmon/pmbus/adm1275.c | 68 ++++++++++++++++++++++++++++++++++- >>> 1 file changed, 67 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/hwmon/pmbus/adm1275.c b/drivers/hwmon/pmbus/adm1275.c >>> index f569372c9204..4efe1a9df563 100644 >>> --- a/drivers/hwmon/pmbus/adm1275.c >>> +++ b/drivers/hwmon/pmbus/adm1275.c >>> @@ -23,6 +23,8 @@ >>> #include >>> #include >>> #include >>> +#include >>> +#include >>> #include "pmbus.h" >>> >>> enum chips { adm1075, adm1272, adm1275, adm1276, adm1278, adm1293, adm1294 }; >>> @@ -78,6 +80,10 @@ enum chips { adm1075, adm1272, adm1275, adm1276, adm1278, adm1293, adm1294 }; >>> #define ADM1075_VAUX_OV_WARN BIT(7) >>> #define ADM1075_VAUX_UV_WARN BIT(6) >>> >>> +#define ADM1275_PWR_AVG_MASK GENMASK(13, 11) >>> +#define ADM1275_VI_AVG_MASK GENMASK(10, 8) >>> +#define ADM1275_SAMPLES_AVG_MAX 128 >>> + >>> struct adm1275_data { >>> int id; >>> bool have_oc_fault; >>> @@ -90,6 +96,7 @@ struct adm1275_data { >>> bool have_pin_max; >>> bool have_temp_max; >>> struct pmbus_driver_info info; >>> + struct mutex lock; >>> }; >>> >>> #define to_adm1275_data(x) container_of(x, struct adm1275_data, info) >>> @@ -164,6 +171,38 @@ static const struct coefficients adm1293_coefficients[] = { >>> [18] = { 7658, 0, -3 }, /* power, 21V, irange200 */ >>> }; >>> >>> +static inline int adm1275_read_pmon_config(struct i2c_client *client, u64 mask) >> >> Why is the mask passed through as u64 ? > > Good point. I used u64 as this is the type used by bitfield machinery > under the hood but I agree it doesn't make sense and is even confusing > to have this in the function prototype as we are using this to mask 16 > bit word anyways. I will fix that in v2. I am gonna have to cast the ret > to u16 when passing to FIELD_GET() to make sure the __BF_FIELD_CHECK is > not complaining (since it is signed right now), though. > Not sure I understand what you are talking about. FIELD_GET() uses typeof(). FIELD_GET() is used by other callers even with u8 and without any typecasts. Why would it be a problem here ? >> >>> +{ >>> + int ret; >>> + >>> + ret = i2c_smbus_read_word_data(client, ADM1275_PMON_CONFIG); >>> + if (ret < 0) >>> + return ret; >>> + >>> + return FIELD_GET(mask, ret); >>> +} >>> + >>> +static inline int adm1275_write_pmon_config(struct i2c_client *client, u64 mask, >>> + u16 word) >>> +{ >>> + const struct pmbus_driver_info *info = pmbus_get_driver_info(client); >>> + struct adm1275_data *data = to_adm1275_data(info); >>> + int ret; >>> + >>> + mutex_lock(&data->lock); >> >> Why is another lock on top of the lock provided by the pmbus core required ? >> > > Good point, I was considering if I should instead add mutex_lock on > update_lock in the pmbus_set_samples() function inside of pmbus_core.c > instead (as this function is missing it) but figured that not all > devices will need that (lm25066 didn't) so it might be a waste in most > cases. But this may be cleaner approach indeed. > > Is this what you mean or there is some other lock I missed? > pmbus_set_samples() should set the pmbus lock. That was missed when the function was added. >>> + ret = i2c_smbus_read_word_data(client, ADM1275_PMON_CONFIG); >>> + if (ret < 0) { >>> + mutex_unlock(&data->lock); >>> + return ret; >>> + } >>> + >>> + word = FIELD_PREP(mask, word) | (ret & ~mask); >>> + ret = i2c_smbus_write_word_data(client, ADM1275_PMON_CONFIG, word); >>> + mutex_unlock(&data->lock); >>> + >>> + return ret; >>> +} >>> + >>> static int adm1275_read_word_data(struct i2c_client *client, int page, int reg) >>> { >>> const struct pmbus_driver_info *info = pmbus_get_driver_info(client); >>> @@ -242,6 +281,19 @@ static int adm1275_read_word_data(struct i2c_client *client, int page, int reg) >>> if (!data->have_temp_max) >>> return -ENXIO; >>> break; >>> + case PMBUS_VIRT_POWER_SAMPLES: >>> + ret = adm1275_read_pmon_config(client, ADM1275_PWR_AVG_MASK); >>> + if (ret < 0) >>> + break; >>> + ret = 1 << ret; >> >> ret = BIT(ret); >> > > I intentionally used the "raw" left shift to make it more obvious this > is pow2 arithmetic operation and an direct inverse to the ilog2() used > on write counterpart. This is also consistent with what I used in > lm25066.c driver not long time ago. > > I don't have strong preference but this is my reasoning. So do you still > think it is better to use BIT() macro instead? > I don't think that is a good rationale, but I'll let it go. Guenter >>> + break; >>> + case PMBUS_VIRT_IN_SAMPLES: >>> + case PMBUS_VIRT_CURR_SAMPLES: >>> + ret = adm1275_read_pmon_config(client, ADM1275_VI_AVG_MASK); >>> + if (ret < 0) >>> + break; >>> + ret = 1 << ret; >> >> ret = BIT(ret); >> >>> + break; >>> default: >>> ret = -ENODATA; >>> break; >>> @@ -286,6 +338,17 @@ static int adm1275_write_word_data(struct i2c_client *client, int page, int reg, >>> case PMBUS_VIRT_RESET_TEMP_HISTORY: >>> ret = pmbus_write_word_data(client, 0, ADM1278_PEAK_TEMP, 0); >>> break; >>> + case PMBUS_VIRT_POWER_SAMPLES: >>> + word = clamp_val(word, 1, ADM1275_SAMPLES_AVG_MAX); >>> + ret = adm1275_write_pmon_config(client, ADM1275_PWR_AVG_MASK, >>> + ilog2(word)); >>> + break; >>> + case PMBUS_VIRT_IN_SAMPLES: >>> + case PMBUS_VIRT_CURR_SAMPLES: >>> + word = clamp_val(word, 1, ADM1275_SAMPLES_AVG_MAX); >>> + ret = adm1275_write_pmon_config(client, ADM1275_VI_AVG_MASK, >>> + ilog2(word)); >>> + break; >>> default: >>> ret = -ENODATA; >>> break; >>> @@ -422,6 +485,8 @@ static int adm1275_probe(struct i2c_client *client, >>> if (!data) >>> return -ENOMEM; >>> >>> + mutex_init(&data->lock); >>> + >>> if (of_property_read_u32(client->dev.of_node, >>> "shunt-resistor-micro-ohms", &shunt)) >>> shunt = 1000; /* 1 mOhm if not set via DT */ >>> @@ -439,7 +504,8 @@ static int adm1275_probe(struct i2c_client *client, >>> info->format[PSC_CURRENT_OUT] = direct; >>> info->format[PSC_POWER] = direct; >>> info->format[PSC_TEMPERATURE] = direct; >>> - info->func[0] = PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT; >>> + info->func[0] = PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT | >>> + PMBUS_HAVE_SAMPLES; >>> >>> info->read_word_data = adm1275_read_word_data; >>> info->read_byte_data = adm1275_read_byte_data; >>> -- >>> 2.20.1 >>> >