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 45DB4C433FE for ; Mon, 17 Oct 2022 12:54:34 +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=nt/feI/MO4Dh7Q3e3b9CBztFNktuxyJoyVAvxLo+P2M=; b=oUF1M1/9jdtIW+T4gw4jf/81i4 coM3/uypD15r3aVc/h7b7POdI9cbIC6kSiZERNdUfSGXp1lAd3YI8c2HSmoQ/7hZrKHX+91x2BRn+ Q0l31GzxfAGBsV7ARjOHNtJmlEzgrnMSfWKEwcD/0iD5KLjVCpNsHoy6kyaTtiZj6T+WzpvUeu8CI PjlMRfyuYbTI9sz/cQU7iJK7kV+zhvlcXAMt+omfgwYbFCC9eTG6cr2xDaw33oJSztPudaEotVDRa AYWJ/Jtdg1JTIUXLSuTr7ppWTZdkXnmsTaFaI+DLgBgNH460cFZPG0FZUDmFQIARa2ZHRy7BxKBWw 7n6yO3NA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1okPcW-00BpQX-3l; Mon, 17 Oct 2022 12:53:28 +0000 Received: from mail-oa1-x34.google.com ([2001:4860:4864:20::34]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1okPcS-00BpLr-UV for linux-arm-kernel@lists.infradead.org; Mon, 17 Oct 2022 12:53:26 +0000 Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-136b5dd6655so13124721fac.3 for ; Mon, 17 Oct 2022 05:53:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; 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=4F0B10iYi/PAmKuXgFf/stv8m99ECrYKKtefF1hT5os=; b=eo2JUGl2hPoZu5dBni4n3mNMdmOxwRHFvIZ7NPZY3bH306icrrtwwF+sfHJwedZ9iQ LE5wP1zJq8bo1Vd6aCHC/DvVOyVRl6qXZGIUAyBo2TzHowFOUOWyujFOA+51NjPYWTLq p6rxuFtOE8fOYGUMN0s9uPoBEsgVk6Q5AT1YCfbiIV2qJdDvimCo4nysoO2cSjrzijdQ uMdq+S0sjZmKZpHIW+tw8K/jXhYhubfJIUHT8qxGpjC3wk7dg0kVjZcf4bTDbhWKfOfD RlbGH6TUHZBJDJYC4fJu7yQVJkaerlTL6/gpw4IidQVkRXkzrfyr0gx7vsqS+HrzXKme CRBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=4F0B10iYi/PAmKuXgFf/stv8m99ECrYKKtefF1hT5os=; b=hV79t+O2WSsCuCqreHUy7JoRxwQA8JgXqnb1lAqhBc8mLYlx546XlLmrun4006Tto4 CyHFtszF98YguXAP0HmlQOesK1p5oASrD2poadawUdCRKKEXezgaBQttOJJHOxixw4Gl laRGaG1uW1BnK0sN4oASQ8KxSXlxSnX1XDftFCfjRx+s/+ISLuxxy0l80Yw2YAc78OpK jlExMT0Hsfo1BxNJz9qqYbHtlhgZ68tFTvYGJDj/JRFOnif/YkhJd8cykaosDKJPXFto yIQPO3NjP6kD2EYIQyEgW3UTiUeq+J2cFuym+27vOYLMmLecDRSR77SXMI0Qr0NsVlGI 0/dg== X-Gm-Message-State: ACrzQf2RNaNXLpmGF0RgB407eue/ed8ZSOcdzjdVlbMTh29dxBQP36z9 nS8k6Xip7tblRe8L0sf5i7sEzw== X-Google-Smtp-Source: AMsMyM6djjkZEiLuZYR1fI5LcYTxnMzuOWyu7y08HSUl00ijIcJn5B4YtbIYEIlGWdzCV3nYXtA9FQ== X-Received: by 2002:a05:6870:d591:b0:131:690d:eee1 with SMTP id u17-20020a056870d59100b00131690deee1mr5643510oao.16.1666011201948; Mon, 17 Oct 2022 05:53:21 -0700 (PDT) Received: from fedora (69-109-179-158.lightspeed.dybhfl.sbcglobal.net. [69.109.179.158]) by smtp.gmail.com with ESMTPSA id j5-20020a544805000000b00342ded07a75sm4241933oij.18.2022.10.17.05.53.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 17 Oct 2022 05:53:20 -0700 (PDT) Date: Mon, 17 Oct 2022 08:53:18 -0400 From: William Breathitt Gray To: Kamel Bouhara Cc: linux-arm-kernel@lists.infradead.org, linux-iio@vger.kernel.org Subject: Re: Handling Signal1 in microchip-tcb-capture Message-ID: References: MIME-Version: 1.0 In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221017_055325_016617_4404FBAB X-CRM114-Status: GOOD ( 26.85 ) 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="===============7039057017788691275==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============7039057017788691275== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="TCvW1xSFv1qkcvL+" Content-Disposition: inline --TCvW1xSFv1qkcvL+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Oct 17, 2022 at 11:59:37AM +0200, Kamel Bouhara wrote: > On Sat, Oct 15, 2022 at 09:52:27AM -0400, William Breathitt Gray wrote: > > I was looking over the microchip-tcb-capture driver recently and noticed > > that the code doesn't seem to account for Signal1. In particular, it > > appears that mchp_tc_count_signal_read() and mchp_tc_count_action_read() > > don't check the Signal id at all and just assume they are handling > > Signal0. This creates a situation where the information returned for the > > Signal1 sysfs attributes are just duplicated reports of Signal0. > > > > What exactly is the relationship of Signal0 ("Channel A") and Signal1 > > ("Channel B"); is SignalB only relevant when the counter device is > > configured for quadrature mode? >=20 > Indeed both signals are required when in quadrature mode, where the > signal0 is representing the speed and signal1 the revolution or number > of rotation. >=20 > We have described all availables modes in details in the following blog p= ost: https://bootlin.com/blog/timer-counters-linux-microchip/ >=20 > Regards, > Kamel Thank you for the link, the block diagram helps illustrate how the signals correlate to the TCB channels. Let me check if I understand correctly. In microchip-tcb-capture.c, mchp_tc_count_signals[0] is TIOA0 while mchp_tc_count_signals[1] is TIOB0? In quadrature mode, are TIOA and TIOB the two phases of a quadrature encoder? You mentioned one signal is speed while the other is the number of rotations; does this mean one signal serves as the position incrementation from a rotary wheel while the other signal is the index (z-phase) indicate for each full rotation? In particular, I'm having trouble understanding mchp_tc_count_signal_read(). I suspect it is unintentionally always returning the signal status for TIOA:: regmap_read(priv->regmap, ATMEL_TC_REG(priv->channel[0], SR), &sr); =20 if (priv->trig_inverted) sigstatus =3D (sr & ATMEL_TC_MTIOB); else sigstatus =3D (sr & ATMEL_TC_MTIOA); =20 *lvl =3D sigstatus ? COUNTER_SIGNAL_LEVEL_HIGH : COUNTER_SIGNAL_LEVEL_L= OW; Here we read the status register for channel 0, select between TIOA and TIOB based on priv->trig_inverted, and then return the signal level. I don't see priv->trig_inverted referenced anywhere else so it appears that priv->trig_inverted will always be 0, thus resulting in mchp_tc_count_signal_read() always returning the TIOA status. I think the intended behavior is to return the status of the selected signal:: if (signal->id =3D=3D 1) sigstatus =3D (sr & ATMEL_TC_MTIOB); else sigstatus =3D (sr & ATMEL_TC_MTIOA); As for mchp_tc_count_action_read(), we have a similar problem: no distinction is made for the Synapse requested. The channel mode register for channel 0 is read and then masked against ATMEL_TC_ETRGEDG to determine the action mode. It appears that this code is always assuming the Synapse for TIOA is requested, but the Synapse for TIOB could be passed. You can determine which corresponding Signal you have by checking synapse->signal->id before deciding what action mode to return. To clarify, in COUNTER_FUNCTION_INCREASE mode, does the Count value increment based on the edge of TIOA and not TIOB? In COUNTER_FUNCTION_QUADRATURE_X4 mode, does the Count value increment based on both edges of TIOA and TIOB serving as quadrature encoding phase A and B signals? The fixes for this issue are trivial enough that I can submit a patch for them later, but I want to make sure I'm understanding the nature of these signals correctly before I do so. Thanks, William Breathitt Gray --TCvW1xSFv1qkcvL+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQSNN83d4NIlKPjon7a1SFbKvhIjKwUCY01QPgAKCRC1SFbKvhIj Kwy9AQDaqMYkC6xjsgKVdlnkA9ANd48JCEvS59uSWOc2NeHIjQD/eF5scHW7K3Tv qAZtfsXw7R8kZeIDbsoOGxeVvMo8gQ0= =4A+E -----END PGP SIGNATURE----- --TCvW1xSFv1qkcvL+-- --===============7039057017788691275== 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 --===============7039057017788691275==--