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 37244FF8860 for ; Mon, 27 Apr 2026 17:36:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type: Content-Transfer-Encoding:MIME-Version:References:In-Reply-To:Message-ID:Date :Subject:Cc:To:From:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=UmdZibbd/+Riw2ttNnhE20ZsNtrexm4/ybN5Xvwgvow=; b=V+MhYbx7Dgi9gHBSIMHCflKcrI cnB9Mn48WAjOhORX0ZABXqgMjYvkEOrMwEx1Gxy/SbWCR0gbfbTSiTFIKEdBSjT/luBmVZJieIKwI bOSgkOU9s/WpywEzIOmBRjc+fKop72aCckIuoCpw/8ic0HTb4zT26eKj2JylkptVbYwn06F9ZxZQm ZToB20GN8iSLuSIrbig5Wj5gWdc8VYGtwXq89+OQdAb9vUm0E+I+5YG/scw1N2rJXM2LWsbwoRXmm 1w8ouNjsHRgv7m9QgWOs0X/m6hWXBqPrXObSR1Z99k5/6JYgnMFUcStkbGfIev8x5gNKWNwkH+SNQ 2J7QGdMg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1wHPsB-0000000HThy-0TRb; Mon, 27 Apr 2026 17:35:55 +0000 Received: from sender4-pp-f112.zoho.com ([136.143.188.112]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1wHPs8-0000000HTgW-1In2; Mon, 27 Apr 2026 17:35:54 +0000 ARC-Seal: i=1; a=rsa-sha256; t=1777311340; cv=none; d=zohomail.com; s=zohoarc; b=AD31+MNPTHWPoTYCQMpX7n3R0Er4g3R9tw0h41WKv3hmOvvgViSemwhfzgvt0V/Xr18hI/13AuZ0oc0jPRO1vaW8c/KDAqRL2r30pWhwGATOtKWmuq12DKZQQTOg1LqmiiHzVlG6YN2u+grPU4bwOqHmSMG/tOYf69jDCalMJLw= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1777311340; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:MIME-Version:Message-ID:References:Subject:Subject:To:To:Message-Id:Reply-To; bh=UmdZibbd/+Riw2ttNnhE20ZsNtrexm4/ybN5Xvwgvow=; b=LXggAq9qe3W+IUdyL2SssQt6RWKdrnslU1yGMFBo6D1XXM6lNMqddmD0wdndgrl7EWNOY6exIK0HAQ6yvlpkbRDJCviTPe9oD481ycqCzL3J9zoN6jg2Deoji6iwl5sUZScIEeeKqVMnoeHYRZ/tLdLuJClButw5EBNT31hnOHE= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=collabora.com; spf=pass smtp.mailfrom=nicolas.frattaroli@collabora.com; dmarc=pass header.from= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1777311340; s=zohomail; d=collabora.com; i=nicolas.frattaroli@collabora.com; h=From:From:To:To:Cc:Cc:Subject:Subject:Date:Date:Message-ID:In-Reply-To:References:MIME-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Reply-To; bh=UmdZibbd/+Riw2ttNnhE20ZsNtrexm4/ybN5Xvwgvow=; b=Zk7ogawB1ZqlMX1b33i7nQ48RAsz7BPFAlhFSMtpmi8D4JtbDjXDFb4ZwdMH1rlr lehBH8gAk6rM/QAG7ZaQYWhFns4VQdtZ3tGA53rooZDa9H+oXX7voL4Z8XxCgCBA45i s9i7M6LHzBfPYjGKSjicMwGrYclXUYxOUUbKXPDc= Received: by mx.zohomail.com with SMTPS id 1777311337704981.5046370792685; Mon, 27 Apr 2026 10:35:37 -0700 (PDT) From: Nicolas Frattaroli To: Uwe =?UTF-8?B?S2xlaW5lLUvDtm5pZw==?= , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Heiko Stuebner , Lee Jones , William Breathitt Gray , Damon Ding Cc: kernel@collabora.com, Jonas Karlman , Alexey Charkov , linux-rockchip@lists.infradead.org, linux-pwm@vger.kernel.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org Subject: Re: [PATCH v5 4/6] counter: Add rockchip-pwm-capture driver Date: Mon, 27 Apr 2026 19:35:32 +0200 Message-ID: In-Reply-To: <91eed9a4-4dc3-4846-baf3-e9cef53be79b@rock-chips.com> References: <20260420-rk3576-pwm-v5-0-ae7cfbbe5427@collabora.com> <20260420-rk3576-pwm-v5-4-ae7cfbbe5427@collabora.com> <91eed9a4-4dc3-4846-baf3-e9cef53be79b@rock-chips.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="utf-8" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20260427_103553_195040_331082D1 X-CRM114-Status: GOOD ( 39.22 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Damon, On Sunday, 26 April 2026 12:55:20 Central European Summer Time Damon Ding wrote: > Hi Nicolas, > > On 4/20/2026 9:52 PM, Nicolas Frattaroli wrote: > > Among many other things, Rockchip's new PWMv4 IP in the RK3576 supports > > PWM capture functionality. > > > > Add a basic driver for this that works to expose HPC/LPC counts and > > state change events to userspace through the counter framework. It's > > quite basic, but works well enough to demonstrate the device function > > exclusion stuff that mfpwm does, in order to eventually support all the > > functions of this device in drivers within their appropriate subsystems, > > without them interfering with each other. > > > > Signed-off-by: Nicolas Frattaroli > > --- > > MAINTAINERS | 1 + > > drivers/counter/Kconfig | 11 ++ > > drivers/counter/Makefile | 1 + > > drivers/counter/rockchip-pwm-capture.c | 307 +++++++++++++++++++++++++++++++++ > > 4 files changed, 320 insertions(+) > > > > For functional validation, I connected PWM0/PWM1 (continuous output) > to PWM2 (capture input) pairwise. > > I enabled the counter via: > /sys/bus/counter/devices/counter0/count0/enable > > Then I verified the functionality by reading the count values from: > /sys/bus/counter/devices/counter0/count0/count > /sys/bus/counter/devices/counter0/count1/count > > Tested-by: Damon Ding Thanks for testing! To make sure a bug on the pwm output driver won't be cancelled out by an equivalent bug in the counter driver, I did my counter driver testing by using an RK3588 as the source of the PWM signal, with the two boards sharing a common ground. Maybe I should get a proper function generator. :) > BTW: Is there any user-space test tool similar to libpwm for the > counter subsystem? I've tried looking for this as well, and couldn't find anything. If it exists then adding a mention of it to generic-counter.rst would be in order I think. > > ...... > > diff --git a/drivers/counter/rockchip-pwm-capture.c b/drivers/counter/rockchip-pwm-capture.c > > new file mode 100644 > > index 000000000000..09a92f2bc409 > > --- /dev/null > > +++ b/drivers/counter/rockchip-pwm-capture.c > > @@ -0,0 +1,307 @@ > > +// SPDX-License-Identifier: GPL-2.0-or-later > > +/* > > + * Copyright (c) 2025 Collabora Ltd. > > + * > > + * A counter driver for the Pulse-Width-Modulation (PWM) hardware found on > > + * Rockchip SoCs such as the RK3576, internally referred to as "PWM v4". It > > + * allows for measuring the high cycles and low cycles of a PWM signal through > > + * the generic counter framework, while guaranteeing exclusive use over the > > + * MFPWM device while the counter is enabled. > > + * > > + * Authors: > > + * Nicolas Frattaroli > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#define RKPWMC_INT_MASK (PWMV4_INT_LPC | PWMV4_INT_HPC) > > + > > +struct rockchip_pwm_capture { > > + struct rockchip_mfpwm_func *pwmf; > > + struct counter_device *counter; > > +}; > > + > > +static struct counter_signal rkpwmc_signals[] = { > > + { > > + .id = 0, > > + .name = "PWM Clock" > > + }, > > +}; > > + > > +static const enum counter_synapse_action rkpwmc_hpc_lpc_actions[] = { > > + COUNTER_SYNAPSE_ACTION_BOTH_EDGES, > > + COUNTER_SYNAPSE_ACTION_NONE, > > +}; > > For the capture function, it uses the PWM's reference clock (dclk) as > the time base to measure how many reference cycles the high and low > levels of the input waveform last respectively. > > I find it a bit strange to set COUNTER_SYNAPSE_ACTION_BOTH_EDGES for > counting. If we treat the input waveform as a sequence of square waves > sampled by dclk cycles, it feels like we should count on a single edge > (rising edge only) rather than both edges. > Yeah, that's a good point. I think I've been struggling to wrap my head around what the signal is and what the synapse should trigger on because the signal isn't something exposed in this case. Your explanation makes sense, and perhaps I should rename rkpwmc_hpc_lpc_actions as well. Currently it makes it seem like HPC and LPC are the signal, when actually the waveform is the signal, HPC and LPC are the counts, and the synapse is a sample every dclk spotting a transition if I understand this correctly. > > + > > +static struct counter_synapse rkpwmc_pwm_synapses[] = { > > + { > > + .actions_list = rkpwmc_hpc_lpc_actions, > > + .num_actions = ARRAY_SIZE(rkpwmc_hpc_lpc_actions), > > + .signal = &rkpwmc_signals[0] > > + }, > > +}; > > + > > Best regards, > Damon > Kind regards, Nicolas Frattaroli