Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp247669iob; Mon, 2 May 2022 18:27:43 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy63gtFlow2K28Agbq1luuyN1S58Os9GuCDY8flwNFC16AeVf5DRqpubHWYVCIgNjT1umHG X-Received: by 2002:a17:90a:3d02:b0:1ca:7f92:1bf1 with SMTP id h2-20020a17090a3d0200b001ca7f921bf1mr2124587pjc.177.1651541262940; Mon, 02 May 2022 18:27:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651541262; cv=none; d=google.com; s=arc-20160816; b=CvK/eMZLX16colEAEe/QlHBJ3LzKteYDaX4NQHGV8SHJ5JPWAlnNLPGD1bwShaQIN0 AuykMKvzQf9UDgmkDF4FswLGRBbFlbh4zsgNf+GeRiWZxnJcj/01bQXbY52ZS25R20xU VX9Id7fzmS7R+NpfvsgWswojB7oq+XfXfYzZqMNBp09Oz0VwJkkPWdNGPL5JF4Br33p3 gtK4u20BnQmCChsQfQ+CuyLz9NPZw1aCwfaya4GlBnOFEsxgPQd9p6hZznFzdkVz1kcp Bo9F2dItKe3EQRqZM6e2/0ZdiJUZK1Iu99KzXquD/lpkvy62cqihIagGChiexpc6ODFy d11w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:organization :message-id:user-agent:references:in-reply-to:subject:cc:to:from :date:mime-version; bh=amU2HSVqedjqPA4Q6TXo8PiI89vcKIGztbQQ9QULvik=; b=XNG4Ng0XlWK4scc6P8EinDxJTd6Iq1Ramd5yHM8Qi4O6QXf3uWfnsCHBthYJo/qg1z 7t8s+V+f4xoWe3X2NpZLu/0nxT1hs7kmXYUDCz4ZWd7iufuYoB0mO4WyEFTQBCjUKuyW CH1L5+SXhk192pywHG8WUSros/HWYvRu56gtnIXMVkgzCJxeQeVr95z3GY7lw9TiyixH xqw781hK0wTWgY7tVyb9c3y89swoIrbLX3qOBQ7NvNEVjgPiLXfilDJLPF2CIytk5pDF mxVBlNLOk2kC4FJQ8wW0e3eSza2ny9qAsAmJOBOSNnwaqrD/m8E2LL7Et8BWHQ2b3m+X xTcQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id w11-20020a056a0014cb00b0050e0bc7c701si762169pfu.148.2022.05.02.18.27.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 02 May 2022 18:27:42 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id E166936E30; Mon, 2 May 2022 18:06:32 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229818AbiEBXvh (ORCPT + 99 others); Mon, 2 May 2022 19:51:37 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52380 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230113AbiEBXv1 (ORCPT ); Mon, 2 May 2022 19:51:27 -0400 Received: from skyrocket.fabmicro.ru (skyrocket.fabmicro.ru [217.116.57.130]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF6943056D for ; Mon, 2 May 2022 16:47:55 -0700 (PDT) Received: from mail.fabmicro.ru (skyrocket.fabmicro.ru [217.116.57.130]) by skyrocket.fabmicro.ru (8.14.9/8.14.9) with ESMTP id 242Nl6QG033711; Mon, 2 May 2022 23:47:06 GMT (envelope-from rz@fabmicro.ru) MIME-Version: 1.0 Date: Tue, 03 May 2022 04:47:06 +0500 From: Ruslan Zalata To: Guenter Roeck 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 Subject: Re: [PATCH v2] hwmon: (sun4i-lradc) Add driver for LRADC found on Allwinner A13/A20 SoC In-Reply-To: <59e91f45-7263-eb41-4b47-db217af54910@roeck-us.net> References: <20220428210906.29527-1-rz@fabmicro.ru> <59e91f45-7263-eb41-4b47-db217af54910@roeck-us.net> User-Agent: Roundcube Webmail/1.4.3 Message-ID: X-Sender: rz@fabmicro.ru Organization: Fabmicro, LLC. Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RDNS_NONE, SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Guenter, I'm sorry to disappoint you, but continuous mode for LRADC works only for key presses (significant voltage change), it does not work for raw data. Here's an excerpt from the manual that supports my discovery (punctuation and grammar preserved): > The LRADC have three mode, Normal Mode态Single Mode and Continue Mode. > Normal mode is that the LRADC will > report the result data of each convert all the time when the key is > down. Single Mode is that the LRADC > will only report the first convert result data when the key is down. > Continue Mode is that the LRADC will > report one of 8*(N+1) (N is program can set) sample convert result data > when key is down. In other words, all three modes require key down event (voltage change) and IRQ is the only way to get continuous raw data updates from LRADC. I've experimented quite a lot with this for past few days, there are no changes to values in ADC data regs except in DATA IRQ mode. Regarding variant structure. Vref is not the only difference between different implementations of LRADC in different Allwinner SoCs. For example, A83T has only one channel LRADC instead of two channels in A10/A13/A20. Some other SoCs may have even more differences. I introduced hwmon_chip_info structure into variant to encapsulate such differences in one place. Patch version 3 will follow. Thank you. --- Regards, Ruslan. Fabmicro, LLC. On 2022-04-29 11:03, Guenter Roeck wrote: > 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