Received: by 10.223.164.221 with SMTP id h29csp1867343wrb; Thu, 2 Nov 2017 02:06:08 -0700 (PDT) X-Google-Smtp-Source: ABhQp+QgQT0kdDXHfAw8fmyoDIwy6gnRtu9llhpErdzycibFQSRhjKKtrbItCil2om+QG143eSg+ X-Received: by 10.101.67.73 with SMTP id k9mr2816602pgq.188.1509613568383; Thu, 02 Nov 2017 02:06:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1509613568; cv=none; d=google.com; s=arc-20160816; b=NjctTLgYmrZcwzILxvYvICyopvt/D2WTTNU5Xamms4PQTOLsDwZxNLa0GJXkI4/MzY 65uHkdYzpxE1HUraUKnAl0c8S+UMXMQv45POWlaqCUz06zY62mTlKdS8ev503nQxlosY FlH6Z5F5kvARf1Ft+KJ+C0DDSVY1Atdkxnwf5JxZ4Khy3thCLGz1zltXQqcqUelfDNla yj/KDUnpHqE8+moOYb/3VI4mMOv1E30+txcurso2ZolVilxAQoHF+BWHbv5lowiGEf10 GlndZecMtAmV9vkrk19x9WChP3Gt6eJ/ccsWFen6CF12W0gJvNv8uFa7tc/P/YFNg+DG Ipsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:cms-type :content-transfer-encoding:content-language:in-reply-to:user-agent :date:message-id:cc:to:subject:from:mime-version:dkim-signature :dkim-filter:arc-authentication-results; bh=N2oOY3+/iDx/RkPCCAA8S+qX0+ACUizCEdlDpsjCrtQ=; b=1C6UDfaOR0BsvzvdQMNxT/VSHdYeTGN2EhZJKhecOwcEN2PJMOmBpx2WvEdAqkWfNn m84Yd8YvTDRXKKEFeJzIIHKu6xfvC+thaaTgVrrklxVqsojGVoPgtIe736cF/XQMdiYT JFz8zy9PIWaXiti5Ukpd8z84BScRDSRW/IfcW/da8oP4tktkT3gdVoP4Fnf/iztDwPPZ UUpZ9fltQauOyzFGCLBfLjYa9n+aZLk9iAq6mhB89V+Nrj8J49U4VK9l5tKtbkvYYwTj it9jamtft1BNBPcR9KUxgy2+55clEkJVF29oZXJIXhh+xyV7Nccg8Fo5v2mLQAZC4v7G WbHw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@samsung.com header.s=mail20170921 header.b=jg0br1dG; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=samsung.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i187si3249431pfe.137.2017.11.02.02.05.53; Thu, 02 Nov 2017 02:06:08 -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=@samsung.com header.s=mail20170921 header.b=jg0br1dG; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=samsung.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755375AbdKBJEJ (ORCPT + 99 others); Thu, 2 Nov 2017 05:04:09 -0400 Received: from mailout1.w1.samsung.com ([210.118.77.11]:35838 "EHLO mailout1.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750883AbdKBJEG (ORCPT ); Thu, 2 Nov 2017 05:04:06 -0400 Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20171102090404euoutp01d4f0321c085bcc1af054112e5e480ff5~zOW3Zlk7g2895228952euoutp01d; Thu, 2 Nov 2017 09:04:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20171102090404euoutp01d4f0321c085bcc1af054112e5e480ff5~zOW3Zlk7g2895228952euoutp01d DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1509613444; bh=N2oOY3+/iDx/RkPCCAA8S+qX0+ACUizCEdlDpsjCrtQ=; h=From:Subject:To:Cc:Date:In-reply-to:References:From; b=jg0br1dGdQNj+jdadKlj7hZI4oDIf30bU2zaN/kSTc2pGVDfDo0K9qqvU+LcsOBd8 etuJMqyQi2kcK5F2V2lqzBGqdVeXYQWuUHJus65SObntWF6K9dRkwXF/zw8Mw4FXKH 9rafXWuwwOWLQPPBexu69UrFc/t6AcBRW1CnX32Y= Received: from eusmges1.samsung.com (unknown [203.254.199.239]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20171102090403eucas1p172c6167de6198e63af308675a04ea145~zOW2z_kDN1857018570eucas1p17; Thu, 2 Nov 2017 09:04:03 +0000 (GMT) Received: from eucas1p2.samsung.com ( [182.198.249.207]) by eusmges1.samsung.com (EUCPMTA) with SMTP id 30.99.12576.38FDAF95; Thu, 2 Nov 2017 09:04:03 +0000 (GMT) Received: from eusmgms1.samsung.com (unknown [182.198.249.179]) by eucas1p1.samsung.com (KnoxPortal) with ESMTP id 20171102090402eucas1p1b22b8ab9d540269a773824ebf91f8ea0~zOW2L8daf1854318543eucas1p1N; Thu, 2 Nov 2017 09:04:02 +0000 (GMT) X-AuditID: cbfec7ef-f79ee6d000003120-88-59fadf83fed3 Received: from eusync2.samsung.com ( [203.254.199.212]) by eusmgms1.samsung.com (EUCPMTA) with SMTP id FC.1A.18832.28FDAF95; Thu, 2 Nov 2017 09:04:02 +0000 (GMT) MIME-version: 1.0 Content-type: text/plain; charset="utf-8"; format="flowed" Received: from [106.120.51.25] by eusync2.samsung.com (Oracle Communications Messaging Server 7.0.5.31.0 64bit (built May 5 2014)) with ESMTPA id <0OYS00GDA96QAKA0@eusync2.samsung.com>; Thu, 02 Nov 2017 09:04:02 +0000 (GMT) From: Maciej Purski Subject: Re: [2/3] iio: adc: ina2xx: Adhere to documented ABI, use Ohm instead of uOhm To: Stefan Bruens Cc: linux-iio@vger.kernel.org, Peter Meerwald-Stadler , linux-kernel@vger.kernel.org, "Andrew F . Davis" , Javier Martinez Canillas , Lars-Peter Clausen , Jonathan Cameron , Hartmut Knaack Message-id: <678f7605-3fc8-cc28-cb16-45381d75bad7@samsung.com> Date: Thu, 02 Nov 2017 10:04:01 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 In-reply-to: <2075928.pSFUuclJ1z@pebbles.site> Content-language: en-US Content-transfer-encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsWy7djP87rN939FGnxcx2Xx/tREdos3b9cw WTxoWsVksev/G2aLJZPns1rMO/KOxeLyrjlsFr93HWO3aDw1h9WB0+PDxziPTas62TyWvDnE 6rGl/y67x/nmI4we5++9ZfM4fmM7k8fnTXIBHFFcNimpOZllqUX6dglcGSvOdbEXbFOq+Ptn A1MD43HpLkZODgkBE4lj/7+xQthiEhfurWfrYuTiEBJYxigxZd9fRgjnM6PEkhsr2GE6Omb8 Y4Kr2t1zihEkwSsgKPFj8j0WEJtZwEri2b9WVoiiZ4wS27e/Yu5i5OBgE9CSWNMeD1IjLBAh cW/nbiaQsIiAgcTMc04g5cwCG5gkPnQvY4WYaSdx7+t2MJtFQFXi1IPJTCC2KFDvhU0/wWxO AT2JN7MXsUPsFZdobr0JdYO8xMErz1lAhkoI/GaT2PKhnw3iAxeJprlzob4Rlnh1fAuULSPR 2XGQCcKulrj4dRdUfY1E4+0NUDXWEp8nbWGGWMAnMWnbdLC/JAR4JTrahCBKPCSaGudBg9RR YlPfQ2gofmOUmPN0G+MERvlZSOE1Cym8ZiH5YRaSHxYwsqxiFEktLc5NTy021CtOzC0uzUvX S87P3cQITEyn/x1/v4PxaXPIIUYBDkYlHl4JrV+RQqyJZcWVuYcYJTiYlUR4X50ACvGmJFZW pRblxxeV5qQWH2KU5mBREue1jWqLFBJITyxJzU5NLUgtgskycXBKNTC2xNld37Z9iV/U0umx DE8NjHIPaR/IiL4/7/j+W6EVAc8YIg3l5r7dcc2tj2Mxn1BV8VmJvzKynDUr5XdMjdb0qDYq 9DeaJeI6deV8RtnzinKJd47t6kgqlsv30zoxr6O/Ocn+yMv+mNoGMY4Dn2Mn75vQPWFaksM0 95Bkl6i5zJcZtgUGxiixFGckGmoxFxUnAgBQrJ2RSAMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42I5/e/4Fd2m+78iDdrv6li8PzWR3eLN2zVM Fg+aVjFZ7Pr/htliyeT5rBbzjrxjsbi8aw6bxe9dx9gtGk/NYXXg9PjwMc5j06pONo8lbw6x emzpv8vucb75CKPH+Xtv2TyO39jO5PF5k1wARxSXTUpqTmZZapG+XQJXxopzXewF25Qq/v7Z wNTAeFy6i5GTQ0LARKJjxj8mCFtM4sK99WxdjFwcQgJLGCXeb9jJCJLgFRCU+DH5HguIzSxg JvHl5WFWiKJnjBKdO+ezdzFycLAJaEmsaY8HqREWiJDY//E1C0hYRMBAYuY5J5ByZoENTBIr HzZBLfjGKHFt5S0miAV2Eve+bmcFsVkEVCVOPZjMBNIsCjRow0Z+kDCngJ7Em9mL2CFuEJdo br0JdY+8xMErz1kmMArOQnLqLCSnzkLSMgtJywJGllWMIqmlxbnpucWGesWJucWleel6yfm5 mxiBMbTt2M/NOxgvbQw+xCjAwajEw3tA/VekEGtiWXFl7iFGCQ5mJRHeVyeAQrwpiZVVqUX5 8UWlOanFhxilOViUxHl796yOFBJITyxJzU5NLUgtgskycXBKNTAKLLIovLQpLHHi3mUds6Qz fJQzNvD9cWyaqM8+SXZ2eVig7JyDllteTHf7fMu7cvneS495Fqc45s4pcpa7uGldlXHK1LS1 pt1LYzQsP7adObpZJTLHk9+6+3wjQ0bS1IiCvz0W/QH5Ivevv5PKTzRonrr1Xf+ZzinPrv3a 6td0h3HP0bCD7ZOVWIozEg21mIuKEwGZy4CxnQIAAA== X-CMS-MailID: 20171102090402eucas1p1b22b8ab9d540269a773824ebf91f8ea0 X-Msg-Generator: CA CMS-TYPE: 201P X-CMS-RootMailID: 20171009092944eucas1p18b2e66a4a07db309551a7e945c2611ec X-RootMTR: 20171009092944eucas1p18b2e66a4a07db309551a7e945c2611ec References: <7ee955b2-a58f-45e0-985d-1f7508d41ae7@rwthex-w2-a.rwth-ad.de> <6144c719-5310-7358-bd57-f778ab481788@samsung.com> <2075928.pSFUuclJ1z@pebbles.site> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/14/2017 08:27 PM, Stefan Bruens wrote: > On Montag, 9. Oktober 2017 11:29:43 CEST Maciej Purski wrote: >> On 10/01/2017 09:48 PM, Stefan BrĂ¼ns wrote: >>> According to the ABI documentation, the shunt resistor value should be >>> specificied in Ohm. As this is also used/documented for the MAX9611, >>> use the same for the INA2xx driver. >>> >>> This poses an ABI break for anyone actually altering the shunt value >>> through the sysfs interface, it does not alter the default value nor >>> a value set from the devicetree. >>> >>> Minor change: Fix comment, 1mA is 10^-3A. >> >> I have just a minor issue. There could be an inconsistency with units as in >> my patch I make current_lsb adjustable and I need it to be in uA (it used >> to be hardcoded as 1 mA so to achieve better precision we need smaller >> units). So in order to keep calibration register properly scaled, I convert >> uOhms to mOhms on each set_calibration(). So if both my changes and your >> changes were applied, on each shunt_resistore_store we would be performing >> multiplication by 10^6 and then in set_calibration() division by 10^3 which >> seems odd to me. >> >> I guess we could keep it as shunt_resistor_ohms instead of >> shunt_resistor_uohm. We could avoid performing division on each >> shunt_resistor_show() and perform multiplication by 10^3 only once in >> set_calibration() on each >> shunt_resistore_store(). We could then change the default value and perform >> division only on probing, when reading the shunt_resistance from device >> tree. >> >> There are many other options. It's not a major issue so maybe we could leave >> it as it is or you could suggest some changes in my patch. > > Sorry it took me so long to answer ... > > The current fixed current_lsb of 1mA is indeed a bad choice for everything but > a shunt resistor value of 10mOhm, as it truncates the current value. So what > is a *good* choice? > > One important point is the current register is merely more than a convenience > register. At least for the INA219/220, it provides nothing not achievable in > software, and for the INA226 family it only has added value if the current is > varying faster than the readout frequency and the averaging is used. > > The precision of the current register is limited by the precision of the shunt > voltage register, and may be reduced by the applied scaling/calibration > factor. > > The precision of the shunt voltage register is fixed at 10uV (INA219) resp. > 2.5uV (INA226). Changing conversion time (both) and PGA (219) affects the > noise and offset, but the lsb value is still fixed. > > If one wants to carry over the shunt voltage register precision into the > current register, its important no (or hardly any) truncation happens. The > terms therefor are given in the manual, formulas 8.5.1 (4) resp 7.5.1 (3): > > INA219: current = shunt_voltage * cal_register / 4096 > INA226: current = shunt_voltage * cal_register / 2048 > > So any cal value smaller than 4096 (2048) will introduce truncation errors, > larger values may introduce overflows, if the full input range is used. Now, > would it not be wise to always use 4096 (2048) for the calibration value? > > The raw values from the IIO subsystem are meaningless without their > accompanying scale factor. Instead of changing the calibration value, why not > just change the reported scale factor? > > More opinions are very welcome. > > Kind regards, > > Stefan > Thanks for the reply. I agree that cal_register set to 4096 (2048) allows us to eliminate truncaction error. However according to your suggestion, if we made cal_reg a fixed value, then current_lsb and r_shunt should be also a fixed value, as they are related according to formula 8.5 (1) cal_register = 0.00512 / (current_lsb * r_shunt) Therefore, changing the scale value wouldn't affect the calib_reg value, so it wouldn't give the user any information on the actual current_lsb of the device. The real value is calculated like this by the user: processed_value = raw_value * scale I think that even after changing the scale value processed_value is expected to be approximately the same. Maybe I'm wrong or I didn't precisely understand what you have suggested. I hope that someone will also comment on that. Best regards, Maciej From 1581258545709207478@xxx Sat Oct 14 18:27:42 +0000 2017 X-GM-THRID: 1580086010895794021 X-Gmail-Labels: Inbox,Category Forums