From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-oa1-f45.google.com (mail-oa1-f45.google.com [209.85.160.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 147871F426B for ; Tue, 21 Jan 2025 17:45:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737481519; cv=none; b=dvEG8QzSclsucYnKHOshcxGr0eKVGbTMbTI1HJz10Hp29KaLmo+IldmZUuLDP/P05FbT1g2OivvDvnC7Izdu08YzVoTA99SQJC6Td0sfPGsS4nURc5PPTYRwl8plmpbD2k0h9/my7PMq8ymwvJ7rUSahrLRvDpu4biGUhp59vAs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737481519; c=relaxed/simple; bh=qW7lgtx1NXRyO4nNtRrfa7jbD7BqM70uxiOODd0SynA=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=NW+2FSUEjx4iRtUStnMsGXKUCvQwAvyaoUqzTievKtpF/GpW58Tk8X7H8TPxVpWJUYP8ljHjvpa4py/4YgVTwjXiU9d/XUNeEctdIcHW+c0tFMCo+ybruvQXa0IjJZbBoZvkWbMeSLH8WbBHN4qv339TTlv10xhvCX786Ts25gI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com; spf=pass smtp.mailfrom=baylibre.com; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b=CymvppVl; arc=none smtp.client-ip=209.85.160.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=baylibre.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=baylibre.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=baylibre-com.20230601.gappssmtp.com header.i=@baylibre-com.20230601.gappssmtp.com header.b="CymvppVl" Received: by mail-oa1-f45.google.com with SMTP id 586e51a60fabf-29e5c0c46c3so3569471fac.3 for ; Tue, 21 Jan 2025 09:45:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20230601.gappssmtp.com; s=20230601; t=1737481516; x=1738086316; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=gFPlf0fcfXdm2Ps7qwcaDy5IkXbtJsI7nT9CQInAONs=; b=CymvppVl5emQT76QCxCzWetZbKBBAzRbefAySQPf5fJSFniRhXAN4J8C5hmFcdg2Uy NyiTepyMpqpxKmzVf8nmhcSlWI+2bFch/yGt8V6RedSnepVGt8Pr4PAmWeCWfZiP97zN 3LEa6SZLy/qkwCk4DX6iAMm18Mr+YvML7UdLjY2eSXoMgwlrCYWgB4yDWpBAjzPfAqXN yDmWQBC8aP3gEh1Ytbma1U49nsf7o9fef4pN9UaNqA52HtLwnUP0SsAncxUpuexNeOpZ 0jEvpvWE1obqQEIChMwxR1uYV+vPuUj7LDa+8in28RGmrUaaZqSw3VmQpSi3aJILDPWA 3ckA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737481516; x=1738086316; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=gFPlf0fcfXdm2Ps7qwcaDy5IkXbtJsI7nT9CQInAONs=; b=XeWGaJ2hqTfuORTGg1hun3H+OzGRNrb8PprAh5I58rQiHOrz8DWIrAwubmqM9cIMpQ 5oz1Qf9qQZgQCuqYAveHuou6Ao5Hptvj3Z9mm+REsK2xneBvkyuzKjrbXq1a5PsXVfX2 3ICeKtoC2Gvq7VM+BKgpjjKO85bMaAIrNBGAib0FzDGULqrSlWA4D+c4UeB7e1Kod4TP yZSaiMtGthoIqCvnppF5EbyN4ggF/msgW2Ijb98depnsR84yGvJ/EQPq75++aBlZNW7M mF1Mg7EFiysBitCg1sqc8m3fZoXhOj0zwmnjxWFAwrI+pionfwRC3l1R8/4B31N6w1Z8 0Z3Q== X-Forwarded-Encrypted: i=1; AJvYcCWf9n2qw8b5nOwcF9pITe9DzHcy1C9AV7rpj9ldtLGIpRwAXLucOuRznyGnLYHbDu9u8So1fom9WsaW5vk=@vger.kernel.org X-Gm-Message-State: AOJu0YwtOUKjPPLk0FdNiImxjJL0CYN5ZHgWQYKSiRumR3qqO0YY3R2Z ii00o+VKnoBxqWy+Afo1qp3nXORGyrAj7zszmD1IUAch2WJ2bC1YU7Fqgk/O14E= X-Gm-Gg: ASbGncu1FGk0o3MqmD+x04sleq/PF2ExixtIK5h7oOS/As8uLHd/sWjQnUrYp8He6vY jmm747MBpHJDgrvdVjo2gIpW21y7xmfvWHpV+OTziOn/aPB+yF+PQhY0ltoFq2+v0jzY37lprJE vbwxZW5Z2adtAmzFoJYDLDQIBTQ9QCO6M71bCCDqLzRhVUEes9gxEK0S1NV6ExAsr1At0M5kgbs //x4/HxXl56CbtO0JnAPm1SgQcHNhK/8i1Sq9oZe23XJlHG+9jjZYHyLJlzQmDcMels2YkEPmgZ 5UVHjrzW4KNjJg9IiazQ97ZQvtbcBdo= X-Google-Smtp-Source: AGHT+IEgfdprwgucyNPXv304ky4DmwpyYonBJIkMSm1CRqaY5wyRbrLL3xmGRG3yr6mliYkwxF1ugg== X-Received: by 2002:a05:6871:a4c7:b0:29e:6814:19d with SMTP id 586e51a60fabf-2b1c0a0b434mr10780536fac.9.1737481516103; Tue, 21 Jan 2025 09:45:16 -0800 (PST) Received: from [192.168.0.142] (ip98-183-112-25.ok.ok.cox.net. [98.183.112.25]) by smtp.gmail.com with ESMTPSA id 586e51a60fabf-2b1b8c8ac66sm3806278fac.8.2025.01.21.09.45.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Jan 2025 09:45:15 -0800 (PST) Message-ID: Date: Tue, 21 Jan 2025 11:45:14 -0600 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [Q] Frequency & duty cycle measurement? To: =?UTF-8?B?Q3PDs2vDoXMgQmVuY2U=?= , linux-iio@vger.kernel.org, "linux-kernel@vger.kernel.org" , linux-arm-kernel@lists.infradead.org, timestamp@lists.linux.dev Cc: William Breathitt Gray , Jonathan Cameron , Lars-Peter Clausen , Daniel Lezcano , Thomas Gleixner , Dipen Patel References: From: David Lechner Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 1/21/25 9:19 AM, Csókás Bence wrote: > Hi all, > > we want to measure the frequency and duty cycle of a signal (relating to power consumption) using a hardware timer in our SoC (Microchip SAMA5D2). The hardware is capable of taking a snapshot of the timer value into another dedicated register pair (RA, RB) on the rising/falling edges, and a small `devmem`-based userspace utility was created as a working PoC. Now we want to move to a "proper" kernelspace solution. > > However, none of the existing drivers seem to be able to do this; the closest was `drivers/counter/microchip-tcb-capture.c`, but that only seems to count one type of edge (rising/falling), and cannot give us the time between them, which would be needed for duty cycle calculation. The only other driver I could find was `drivers/clocksource/timer-atmel-tcb.c`, which again seems incapable of such measurements. Therefore, a new module will probably be needed; the question then becomes: which API to implement. > > As `microchip-tcb-capture.c` uses the Generic Counter Interface, that was obviously a first stop. However, from what I could see, you can only represent (1) the number of times an edge has been encountered, and (2) rotary encodings (quadrature and direction-step decoders); and not the time between edges. You might find some interesting reading at [1]. A few years ago, I started adding support for an "edge capture unit" and timer on the TI EQEP quadrature encoder driver in the counter subsystem. I never found time to keep working on that to get it merged, but I've actually been looking at it again just last week. It sounds quite similar, but I didn't consider the possibility of looking at the duty cycle, only the rate. [1]: https://lore.kernel.org/linux-iio/20211017013343.3385923-1-david@lechnology.com/ > > IIO_ALTVOLTAGE and IIO_CHAN_INFO_FREQUENCY/_PHASE also seemed promising (although the lack of IIO_CHAN_INFO_DUTY_CYCLE already posed a problem), until I saw that all current drivers are frequency *generators*, and not measurers, the latter seems to be completely unimplemented. A similar case came up somewhat recently [2] where it was suggested to add IIO_FREQUENCY to be able to measure a clock frequency [3]. [2]: https://lore.kernel.org/linux-iio/20240624173105.909554-1-jbrunet@baylibre.com/ [3]: https://lore.kernel.org/linux-iio/20240629204025.683b1b69@jic23-huawei/ > > The only other contender I could find was the Hardware Timestamping Engine (HTE), but again, it's not clear whether (1) the API is even capable of relaying duty cycle information to userspace and (2) if it is, how would one go about implementing it. > > It is also entirely possible I missed a driver or API that could handle this better, if so, please don't keep it to yourselves. In the PWM subsystem, there is pwm_capture() which allows measuring period and duty cycle, so could be exactly what you are looking for. > > So, how could one go about implementing such a driver? > > Bence > >