From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 26E08C433F5 for ; Fri, 29 Apr 2022 06:05:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:Subject:References:Cc:To:From: MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=LfPZbLCOArk2YdKDYKujzTzm94Y5JPTpodJe6mWmMwY=; b=wW5rPpC1wzFpti Qyp5HFIhaffsXZkQw/zAsKnhANZCWX+T82/IjRompdMMRT5v0ygGfqpUK4EhRcRvNXi1pJ6ZK/aTK FurqeSIljWgKILsjYwKua5RugK3g3R+IcaoxpGKPsUaCKS2ZFemOTO+iU50kkLCEjF1YqNIlB+hwz RIr819IcipSPUdBTBhpbvLrNB00GM9bBxeN8tOHD/dOTJCbewQ9pg5RPbK8VpYThJs420+HS8+jiZ Y+FUvUhS+82oDlSrwKvQbGUT0URgHxu7yC9XG/0Din+cF1YmcxUhJ+8TxQdiGyKcx4QPedbjtEOqm 0x2tcrZPWwtK+zVZvZZw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nkJja-009fNP-0l; Fri, 29 Apr 2022 06:04:06 +0000 Received: from mail-oi1-x22e.google.com ([2607:f8b0:4864:20::22e]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nkJjX-009fMr-Bt for linux-arm-kernel@lists.infradead.org; Fri, 29 Apr 2022 06:04:04 +0000 Received: by mail-oi1-x22e.google.com with SMTP id e4so7607048oif.2 for ; Thu, 28 Apr 2022 23:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:message-id:date:mime-version:user-agent:content-language :from:to:cc:references:subject:in-reply-to:content-transfer-encoding; bh=X/KcFNZhAHoZ1H6Tr4WvcjaMczJznMSErZBotqKY3jk=; b=PxhNjBOw2ylbQzoWSUcKoIuVMYGb/l6sxtEDteNu6AO+5YMtyA256PNa3JlRIRzM+L ijSIySGeJpUHMeXZTKHsagxc/ujgW+UfOit8Xhfp0WtlPe/tGMEsbntzX149xTm+Ewic njMJr3IjP6E8YT38D97JampAL4qtJ7h7T36pulJNSiy9qSxN10NFsKStjF3H/oHT33QK E/RoWon0gJ6V5OC1x6Ukk7545Tn3PzgVRsSC7Q/gedvTBhSbDewSG9jdr+f6ndDW4HAG 8O6LZm2d5LwL7k1kwdzVrSVIt7fWf+QpJ2iyi0OeYDSc9rT25u5SSLRKE1O3FEguyZ02 zqJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:message-id:date:mime-version:user-agent :content-language:from:to:cc:references:subject:in-reply-to :content-transfer-encoding; bh=X/KcFNZhAHoZ1H6Tr4WvcjaMczJznMSErZBotqKY3jk=; b=cfeLAoRr7QRtLVw+VbkLeucWLMgIVfDpL6fTAJ0XUz87yTNsqPHguKKbiKf7yh2fUI Exd2OTGecOYAUabP9O/zLMm8Wplrsm+xF66x2186Ssdxgk1xZWkKvS7Lk5AEm2BQ+Z/Q 6FQb4c5XUKCnVPYvtWskiXiHVf6UGCO/F62YqzEEaYJTeqmWce0kRflS3SuLub3KxJcx Rw2YZ1Y3tzq10eQ/xZMBFSF8YY1uaWU5g6zzxXcbdVXBiViRkxOTFR9TDIkeG5JuHEyz vggqcBKJHiX8r47OeCD5sfG4NzvGlA4jy0Ip1Rbexp+1BTtC9nAZr8NHpO8es3GHluzN yIKw== X-Gm-Message-State: AOAM530VrZVeWigPDzBiqlvUQM5bFFPGzr/gHXzyHO/rjonFZxePOmSB fnxp6vyMkZsK/eerH5DAWPE= X-Google-Smtp-Source: ABdhPJwnRWg5pq2rb86Qc8RTFC94blcskTiFA5sttrDQRIupMO1KOk3leXNWAUY1RnkOtxc0Psq7lQ== X-Received: by 2002:a05:6808:1912:b0:325:74c4:35e3 with SMTP id bf18-20020a056808191200b0032574c435e3mr788022oib.61.1651212241626; Thu, 28 Apr 2022 23:04:01 -0700 (PDT) Received: from ?IPV6:2600:1700:e321:62f0:329c:23ff:fee3:9d7c? ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id a8-20020a4ad5c8000000b0035eb4e5a6c6sm429034oot.28.2022.04.28.23.03.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Apr 2022 23:04:00 -0700 (PDT) Message-ID: <59e91f45-7263-eb41-4b47-db217af54910@roeck-us.net> Date: Thu, 28 Apr 2022 23:03:58 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US From: Guenter Roeck To: Ruslan Zalata Cc: Jean Delvare , Chen-Yu Tsai , Jernej Skrabec , Samuel Holland , linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev References: <20220428210906.29527-1-rz@fabmicro.ru> Subject: Re: [PATCH v2] hwmon: (sun4i-lradc) Add driver for LRADC found on Allwinner A13/A20 SoC In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220428_230403_476923_F0EDC93C X-CRM114-Status: GOOD ( 28.25 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 4/28/22 22:32, Guenter Roeck wrote: > On 4/28/22 17:28, Ruslan Zalata wrote: >> Thank you Guenter for your valuable time. >> >> I have added update_interval option (it's in ms units, right?) and fixed all other issues you pointed to. Will test it on real hardware and send third version of the patch for review. >> >> Regarding IRQ. Alternatively the driver would need to sit and poll conversion ready bit in a loop which might cause a much worse load on system, is not it ? Anyway, the real problem with this piece of hardware is that there's no "conversion ready bit" provided, the only way to know data ready status is to receive an interrupt. >> > > Not necessarily. The data does not have to be "current", after all, > if the hardware is able to continuously convert. If not, the question > is how long a conversion takes. If it doesn't take too long, it would > be better to initiate a conversion and then wait for the completion. > >> I think it still needs a semaphore/seqlock to synchronize conversions and reads. I.e. two consequent reads should not return same old value. Although it's not an issue in my case, but could be a problem for others. >> > Why ? That happens for almost all hwmon devices. They will all report > the most recent conversion value. Some of them can take seconds > to complete a new conversion, so the reported value is always "old" > for a given defition of old (ie any time smaller than a conversion > interval). > > Sigh. Looks like I'll have to dig up the documentation and read about > the ADC myself. > I did, for both A13 and A20. The ADC supports continuous mode. That means it can be configured accordingly, and reading the ADC value just returns the most recent conversion value. There is absolutely no need to keep reading the conversion values using interrupts. Also, +struct lradc_variant { + u32 bits; + u32 resolution; + u32 vref; +}; is unnecessary because the values are the same for both supported chips. That means that defines can and should be used. Yes, I can see that A83T uses a different voltage, but even that doesn't need a structure - the voltage can be set in struct sun4i_lradc_data if/when needed, and the resolution and number of bits is still the same. Guenter _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel