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 2A3C8C433EF for ; Tue, 3 May 2022 21:39:14 +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:Message-ID:References:In-Reply-To:Subject:Cc:To:From :Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=o0evxtfeDBoi3gEiR76vtoC34vK5/M9qxsgz6ZiwFpU=; b=1uDIPuize1uOyvrovNinQZKveD YO21l8ifI0ZzXPfNDLW/ngQ4WGCQ5oZRqmSRn7mh5JAdx0B+cooUG3d1f0RHq1qnUfERnQoTcSLq8 bi1OHNFNjxHjwUR6y4VX4h1F98zE25V64T9+1BsArTuJmLzh2t7X7HA1Ml/uXtBvl76rmbBE5S0rv eGejO6uyY74OVz4Ii5nk7mkr7WkXd2pJu6lazt0RA+xzJG+mwb1yP5IU9NRacdIhlLHTp+AJxGTOW u8Twi7SdGTo/jg7T3hV98DksfZlZRuYWD72FtKUOnFrqK5pxIvyj0Y2/MQ1nlZTCS8/iPyWvR434+ jysUa+Ug==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nm0Da-007odY-M5; Tue, 03 May 2022 21:38:02 +0000 Received: from skyrocket.fabmicro.ru ([217.116.57.130]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nm0DV-007oay-8u for linux-arm-kernel@lists.infradead.org; Tue, 03 May 2022 21:38:01 +0000 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 243LbWgS088440; Tue, 3 May 2022 21:37:32 GMT (envelope-from rz@fabmicro.ru) MIME-Version: 1.0 Date: Wed, 04 May 2022 02:37:32 +0500 From: Ruslan Zalata To: Maxime Ripard Cc: Guenter Roeck , Icenowy Zheng , 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: <20220503161446.tl3qoqqnkzq2f3hn@houat> References: <20220428210906.29527-1-rz@fabmicro.ru> <20220502110010.q7vvdkdpaiz5acjl@houat> <7433B295-D896-4BF8-87DF-87EB89D7A550@aosc.io> <20220502112112.3ne7zy4b6gggxzoo@houat> <4aabfd63-18e2-65c5-d1c2-d7600afc1c40@roeck-us.net> <97e3af18e947492b1ac968c058ba509f@fabmicro.ru> <20220503161446.tl3qoqqnkzq2f3hn@houat> User-Agent: Roundcube Webmail/1.4.3 Message-ID: <18ded45dcd670edcc9eb9811e7c7c034@fabmicro.ru> X-Sender: rz@fabmicro.ru Organization: Fabmicro, LLC. X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220503_143757_763707_B820017C X-CRM114-Status: GOOD ( 21.83 ) 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 Hi Maxime, > At the hardware level, I'd assume you would either use the LRADC as an > actual ADC, or use it to drive buttons, right? Yes, exactly. > So I don't think a new device tree binding is such a deal breaker since > you have to describe it differently anyway. ... > Since that would be a completely different use-case, the IIO driver > doesn't have to support input right away, it can be done later if > needed. > > And you could have the two drivers compiled at the same time. As I got you right, you propose do add new bindings, say "allwinner,sun4i-a10-lradc-hwmon" and "allwinner,sun8i-a83t-lradc-hwmon" for new driver, which will allow two drivers (hwmon and keyboard) be compiled and loaded at same time, only that one listed in DT will be instantiated. If two are listed at same time, one of the calls to devm_request_irq() will return with an error preventing second driver to be probed (some error message would be necessary to let user know what's going on). If this is ok, I will implement it. I think moving this driver to IIO framework is overkill. We use LRADC to monitor battery temp and state (voltage) and that's what HWMON was made for. It's simple, easy and elegant. IIO, on the other hand, is for data acquisition and is much more complex beast. Can we stay with HWMON, please ? :) I looked through the code for a number of iio/adc drivers and I could see that all of them initiate ADC conversion inside read(), then wait for completion and return single sample. For me this very flawed approach because a) much more overhead/load on the system, b) initiating conversion may (and will) take more time than a single consequent conversion, c) samples will be read in irregular periods of time, hence acquired data will not be consistent for any further processing (like FFT). So, this whole IIO framework is no way better than HWMON, yet more complex. At least for ADCs. :-) A better approach for an IIO/ADC driver would be to implement some serialization mechanism to let reads go in sync with updates (IRQs), with buffering, guaranteeing no same sample is read twice and no sample is lost. The read() would return next available sample from buffer with nearly zero overhead or sleep till data is available. And the best way is to extend IIO framework to support ring buffers mechanism like the one proposed by Analog Devices, but that's a way different story. Link: https://events.static.linuxfound.org/sites/events/files/slides/iio_high_speed.pdf Regards, Ruslan. Fabmicro, LLC. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel