linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: William Breathitt Gray <vilhelm.gray@gmail.com>
To: Fabrice Gasnier <fabrice.gasnier@st.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
	benjamin.gaignard@st.com,
	"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v6 3/9] docs: Add Generic Counter interface documentation
Date: Fri, 25 May 2018 09:00:04 -0400	[thread overview]
Message-ID: <20180525130004.GA3751@sophia> (raw)
In-Reply-To: <cd045792-8ed2-8d83-231a-661975ffc7c5@st.com>

On Fri, May 25, 2018 at 11:26:11AM +0200, Fabrice Gasnier wrote:
>On 05/22/2018 07:08 PM, Jonathan Cameron wrote:
>>>>> +* Quadrature x2 Rising:
>>>>> +  Rising edges on either quadrature pair signals updates the respective
>>>>> +  count. Quadrature encoding determines the direction.  
>>>> This one I've never met.  Really? There are devices who do this form
>>>> of crazy? It gives really uneven counting and I'm failing to see when
>>>> it would ever make sense...  References for these odd corner cases
>>>> would be good.
>>>>
>>>>
>>>> __|---|____|-----|____
>>>> ____|----|____|-----|____
>>>>
>>>> 001122222223334444444  
>>> That's the same reaction I had when I discovered this -- in fact the
>>> STM32 LP Timer is the first time I've come across such a quadrature
>>> mode. I'm not sure of the use case for this mode, because positioning
>>> wouldn't be precise as you've pointed out. Perhaps Fabrice or Benjamin
>>> can probe the ST guys responsible for this design choice to figure out
>>> the rationale.
>> Hmm.  My inclination would be to not support it unless someone can up
>> with a meaningful use.  We are adding ABI (be it not much) for a case
>> that to us makes no sense.
>
>Hi Jonathan, William,
>
>Sorry for the late reply. To follow your advise, we can probably drop
>this for now. I think simple counter, or quadrature x4 will be mostly
>used for now. As you pointed out, there's not much ABI for x2
>rising/falling cases. It will not be a big deal to add it later if needed.
>
>I can help to update (remove & test) this in LP-Timer counter driver if
>you wish.
>
>Please let me know,
>
>Thanks,
>Fabrice

All right, let's postpone the COUNT_FUNCTION_QUADRATURE_X2_RISING and
COUNT_FUNCTION_QUADRATURE_X2_FALLING modes for now. Fabrice, send me
over an update patch removing these modes from the LP-Timer counter
driver and I'll squash it in with the next patchset revision.

I'll keep the rest of the quadrature modes the same as they are used in
the other counter drivers as well (with the remaining "Quadrature x1 B"
staying to complete the pattern) and I've seen real world use cases for
each:

    * COUNT_FUNCTION_QUADRATURE_X1_A
    * COUNT_FUNCTION_QUADRATURE_X1_B
    * COUNT_FUNCTION_QUADRATURE_X2_A
    * COUNT_FUNCTION_QUADRATURE_X2_B

Adding support in the future for "Quadrature x2 Rising" and "Quadrature
x2 Falling" will be trivial, so really the main requirement in order to
bring these modes back is to provide reasonable use cases for them. My
suspicion is that there was some rationale for these Quadrature x2 modes
in the STM32 LP-Timer -- afterall, why else would the engineers go
through the trouble of designing and implementing it -- but until that
use case is clear, it's best to wait on changing the Generic Counter ABI
lest we end up with an interface that is never used in the real world.

William Breathitt Gray

>
>> 
>> Looks rather like the sort of thing that is a side effect of the
>> implementation rather than deliberate.
>> 
>>> I'm leaving in these modes for now, as they do exist in the STM32 LP
>>> Timer, but it does make me curious what the intentions for them were
>>> (perhaps use cases outside of traditional quadrature encoder
>>> positioning).
>>>
>> Sure if there is a usecase then fair enough.
>> 
>> Jonathan
>> 
>> 

  reply	other threads:[~2018-05-25 13:00 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-16 17:50 [PATCH v6 0/9] Introduce the Counter subsystem William Breathitt Gray
2018-05-16 17:50 ` [PATCH v6 1/9] counter: Introduce the Generic Counter interface William Breathitt Gray
2018-05-20 15:06   ` Jonathan Cameron
2018-05-21 13:06     ` William Breathitt Gray
2018-05-16 17:50 ` [PATCH v6 2/9] counter: Documentation: Add Generic Counter sysfs documentation William Breathitt Gray
2018-05-20 15:12   ` Jonathan Cameron
2018-05-16 17:51 ` [PATCH v6 3/9] docs: Add Generic Counter interface documentation William Breathitt Gray
2018-05-19 15:30   ` kbuild test robot
2018-05-20 15:31   ` Jonathan Cameron
2018-05-21 13:47     ` William Breathitt Gray
2018-05-22 17:08       ` Jonathan Cameron
2018-05-25  9:26         ` Fabrice Gasnier
2018-05-25 13:00           ` William Breathitt Gray [this message]
2018-05-16 17:51 ` [PATCH v6 4/9] counter: 104-quad-8: Add Generic Counter interface support William Breathitt Gray
2018-05-19 13:16   ` kbuild test robot
2018-05-19 13:55     ` William Breathitt Gray
2018-05-19 13:16   ` [RFC PATCH] counter: 104-quad-8: quad8_ops can be static kbuild test robot
2018-05-20 15:42   ` [PATCH v6 4/9] counter: 104-quad-8: Add Generic Counter interface support Jonathan Cameron
2018-05-21 13:51     ` William Breathitt Gray
2018-05-16 17:51 ` [PATCH v6 5/9] counter: 104-quad-8: Documentation: Add Generic Counter sysfs documentation William Breathitt Gray
2018-05-16 17:51 ` [PATCH v6 6/9] dt-bindings: counter: Document stm32 quadrature encoder William Breathitt Gray
2018-05-17 16:23   ` Rob Herring
2018-05-17 18:07     ` William Breathitt Gray
2018-05-17 18:59     ` Benjamin Gaignard
2018-05-18 16:28       ` Rob Herring
2018-05-20 15:47         ` Jonathan Cameron
2018-06-04 13:03         ` Benjamin Gaignard
2018-05-16 17:52 ` [PATCH v6 7/9] counter: Add STM32 Timer " William Breathitt Gray
2018-05-16 17:52 ` [PATCH v6 8/9] counter: stm32-lptimer: add counter device William Breathitt Gray
2018-05-18 16:34   ` Rob Herring
2018-05-16 17:52 ` [PATCH v6 9/9] iio: counter: Remove IIO counter subdirectory William Breathitt Gray
2018-05-20 15:53   ` Jonathan Cameron
2018-05-21 13:58     ` William Breathitt Gray
2018-05-22 10:44       ` Jonathan Cameron

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180525130004.GA3751@sophia \
    --to=vilhelm.gray@gmail.com \
    --cc=benjamin.gaignard@st.com \
    --cc=devicetree@vger.kernel.org \
    --cc=fabrice.gasnier@st.com \
    --cc=jic23@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).