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 E7A97C3DA6E for ; Mon, 8 Jan 2024 22:10:13 +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: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=RDVH+lUXTG8dy65Ljylxntrl4GAwQPR1YDm/YPEGR8A=; b=DY7UTtfBMXij8EFLIKj9LdD8tc +vaEubIZ/tsBNRttalnSoTmCfOLGLiIKdQJAcklP2OHZp8rQq+spN7h/5MPQX9VbwsdigoHCbFWbU lOAcGLXxV6+QdkbL2YKq3xpV5cHMI31+D34J/frx94Mn4gQ40s2r9q1hH6rgaiAyp8qrXRdZBcMr0 0v5Y3FXkgtzVS3Genw0GtrrSYewmE7kx0I6dWgFFkxCXbL/gvJI5ZAZUAGIYaQmb7fwV1n+2UViJi u+/FZ97LSU/tUyaWRuI1KNGiNvfpfVn1o+A/h8/FsauzQkawW5BZyCIB6c4tW/wXWRjKS8+ZJDnC8 bCAC+oeQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rMxoW-006Kbn-0N; Mon, 08 Jan 2024 22:09:44 +0000 Received: from mail-vk1-xa2f.google.com ([2607:f8b0:4864:20::a2f]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rMxoS-006KbB-1t for linux-arm-kernel@lists.infradead.org; Mon, 08 Jan 2024 22:09:42 +0000 Received: by mail-vk1-xa2f.google.com with SMTP id 71dfb90a1353d-4b72e63821eso1901218e0c.1 for ; Mon, 08 Jan 2024 14:09:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1704751779; x=1705356579; darn=lists.infradead.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=zPwL0VIADWvObusNS4Aap9j3lSZsmdqtr+hhZskgl0M=; b=MQMhLoyhH3TjiluMijdBYTNVfP5ccFChPk6s7wVboILh1jdXs+coTULvB6p6CyQ0cn DaSyVzxi7hhoVQymzTPb91WyccYRUha7NCR7yiKEGPrSIMr+GT7WktUhwMKkbFXyXnWx 8+/uVQF8ZCO0sEBXdWnOCCb0MnlZYb0reP5bmv1MBuBxqfKyQnnZJoWOUbbaJdUG372z jUZiftWlZBdWXYbWzpiqFVXUJd7gnOMFLoAgPuWta8Yx81wv2iAAljlBqiHtucZy9DMb 1kDWZDDnSW88bm8+BBtHRdGWwSbB/TiU+Hu00MWMHvhHeGdR0MRQEgZVX52Jz4qYPHdn px0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704751779; x=1705356579; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=zPwL0VIADWvObusNS4Aap9j3lSZsmdqtr+hhZskgl0M=; b=gLTxZvYUvsQFWpionBY1RBfzqv+CHd9SRX0L+HutSPvIJpeUwajo3pwkqgBdX9wuKs VMGKQPDd2OltllumspQu8LUu54WG5yaEAqibc9D0crRSdHTasUHg65tfejwhufMT9OCm 1fJf/8Pc6fneGVcQXJNeEwoBdnEvLpBgbxBfS0zYQAhi/yvuppJpmhzzbBHj1o+jILjs YFtBmy1/+h4MOGH40dZVzDMeq6IpGtjLlPXJyP4uFO1M5h7sZw8fuWRYgxj5tKrc9178 1tyJnOH/nw0WTgGLb5+jSyVFUgk5pnuOJUxunrnAazbi3Xt8+5uVmjhaBbmm+U7vlLkr Wwjw== X-Gm-Message-State: AOJu0YxaJe22dPaomX255fFtGkfKt1PTLx3bR7Bg1iwdHR1sKbSIlIcD BEeC2VSPL5PpEf9UN6G5UYE121pQZEd1AQ== X-Google-Smtp-Source: AGHT+IE6hTwFu+QRXDhnPkTMqdy0XSYmsMHuM7fSO/yZXKcRDQzPFDoRFNo79VfhiJlWDzMOLsuoMw== X-Received: by 2002:a05:6122:10e4:b0:4b6:c780:ac90 with SMTP id m4-20020a05612210e400b004b6c780ac90mr334731vko.0.1704751778736; Mon, 08 Jan 2024 14:09:38 -0800 (PST) Received: from ubuntu-server-vm-macos (072-189-067-006.res.spectrum.com. [72.189.67.6]) by smtp.gmail.com with ESMTPSA id em8-20020a056122380800b004b6d2b7109esm81131vkb.46.2024.01.08.14.07.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jan 2024 14:08:07 -0800 (PST) Date: Mon, 8 Jan 2024 22:07:09 +0000 From: William Breathitt Gray To: Fabrice Gasnier Cc: lee@kernel.org, alexandre.torgue@foss.st.com, linux-iio@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 10/10] counter: stm32-timer-cnt: add support for capture events Message-ID: References: <20231220145726.640627-1-fabrice.gasnier@foss.st.com> <20231220145726.640627-11-fabrice.gasnier@foss.st.com> MIME-Version: 1.0 In-Reply-To: <20231220145726.640627-11-fabrice.gasnier@foss.st.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240108_140940_671950_7624087D X-CRM114-Status: GOOD ( 26.50 ) 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-Type: multipart/mixed; boundary="===============2365184428903787772==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============2365184428903787772== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WiW47Lt2gdjHTFQC" Content-Disposition: inline --WiW47Lt2gdjHTFQC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 20, 2023 at 03:57:26PM +0100, Fabrice Gasnier wrote: > + /* > + * configure channel in input capture mode, map channel 1 on TI1, chann= el2 on TI2... > + * Select both edges / non-inverted to trigger a capture. > + */ I suggest defining a new local variable 'cc' to point to stm32_cc[ch]. I think that's make the code look nicer here to avoid all the array index syntax every time you access stm32_cc[ch]. > + if (enable) { > + /* first clear possibly latched capture flag upon enabling */ > + regmap_read(priv->regmap, TIM_CCER, &ccer); > + if (!(ccer & stm32_cc[ch].ccer_bits)) { Try regmap_test_bits() here instead of using regmap_read(). > + sr =3D ~TIM_SR_CC_IF(ch); > + regmap_write(priv->regmap, TIM_SR, sr); Eliminate 'sr' by regmap_write(priv->regmap, TIM_SR, ~TIM_SR_CC_IF(ch)). > @@ -366,6 +460,12 @@ static int stm32_count_events_configure(struct count= er_device *counter) > regmap_write(priv->regmap, TIM_SR, (u32)~TIM_SR_UIF); > dier |=3D TIM_DIER_UIE; > break; > + case COUNTER_EVENT_CAPTURE: > + ret =3D stm32_count_capture_configure(counter, event_node->channel, t= rue); > + if (ret) > + return ret; > + dier |=3D TIM_DIER_CC_IE(event_node->channel); Ah, now I understand why the previous patch OR'd TIM_DIER_UIE to dier. Apologies for the noise. > @@ -374,6 +474,15 @@ static int stm32_count_events_configure(struct count= er_device *counter) > =20 > regmap_write(priv->regmap, TIM_DIER, dier); > =20 > + /* check for disabled capture events */ > + for (i =3D 0 ; i < priv->nchannels; i++) { > + if (!(dier & TIM_DIER_CC_IE(i))) { > + ret =3D stm32_count_capture_configure(counter, i, false); > + if (ret) > + return ret; > + } Would for_each_clear_bitrange() in linux/find.h work for this loop? > @@ -504,7 +620,7 @@ static irqreturn_t stm32_timer_cnt_isr(int irq, void = *ptr) > * Some status bits in SR don't match with the enable bits in DIER. Onl= y take care of > * the possibly enabled bits in DIER (that matches in between SR and DI= ER). > */ > - dier &=3D TIM_DIER_UIE; > + dier &=3D (TIM_DIER_UIE | TIM_DIER_CC1IE | TIM_DIER_CC2IE | TIM_DIER_CC= 3IE | TIM_DIER_CC4IE); Again, sorry for the noise on the previous patch; this makes sense now. > @@ -515,6 +631,15 @@ static irqreturn_t stm32_timer_cnt_isr(int irq, void= *ptr) > clr &=3D ~TIM_SR_UIF; > } > =20 > + /* Check capture events */ > + for (i =3D 0 ; i < priv->nchannels; i++) { > + if (sr & TIM_SR_CC_IF(i)) { Would for_each_set_bitrange() in linux/find.h work for this loop? > + counter_push_event(counter, COUNTER_EVENT_CAPTURE, i); > + clr &=3D ~TIM_SR_CC_IF(i); Perhaps u32p_replace_bits(&clr, 0, TIM_SR_CC_IF(i)) is clearer here. > @@ -627,8 +752,11 @@ static int stm32_timer_cnt_probe(struct platform_dev= ice *pdev) > } > } else { > for (i =3D 0; i < priv->nr_irqs; i++) { > - /* Only take care of update IRQ for overflow events */ > - if (i !=3D STM32_TIMERS_IRQ_UP) > + /* > + * Only take care of update IRQ for overflow events, and cc for > + * capture events. > + */ > + if (i !=3D STM32_TIMERS_IRQ_UP && i !=3D STM32_TIMERS_IRQ_CC) > continue; Okay, I see now why you have this check. This should be fine as it'll makes adding support in the future for the other IRQs a less invasive change. William Breathitt Gray --WiW47Lt2gdjHTFQC Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQSNN83d4NIlKPjon7a1SFbKvhIjKwUCZZxyDQAKCRC1SFbKvhIj Ky5wAP4gGBh3+vNrHgCFcl/2xnX9onULDns/GxDSAl/SYUHaxQD/UlBRNYjuTlpn mQy4bZaGfms5hT09QoJcBuaniegpLQg= =2KS6 -----END PGP SIGNATURE----- --WiW47Lt2gdjHTFQC-- --===============2365184428903787772== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============2365184428903787772==--