public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: boris brezillon <b.brezillon@overkiz.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Rob Herring <rob.herring@calxeda.com>,
	Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ian.campbell@citrix.com>,
	Rob Landley <rob@landley.net>,
	Russell King <linux@arm.linux.org.uk>,
	Linus Walleij <linus.walleij@linaro.org>,
	Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
	Jiri Kosina <jkosina@suse.cz>,
	Masanari Iida <standby24x7@gmail.com>,
	Nicolas Ferre <nicolas.ferre@atmel.com>,
	Richard Genoud <richard.genoud@gmail.com>,
	Heiko Stuebner <heiko@sntech.de>,
	James Hogan <james.hogan@imgtec.com>,
	devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
Date: Tue, 27 Aug 2013 08:16:49 +0200	[thread overview]
Message-ID: <521C4451.1060908@overkiz.com> (raw)
In-Reply-To: <521C2347.4080702@wwwdotorg.org>

On 27/08/2013 05:55, Stephen Warren wrote:
> On 08/26/2013 11:01 AM, boris brezillon wrote:
>> Hello Stephen,
>>
>> On 26/08/2013 18:50, Stephen Warren wrote:
>>> On 08/24/2013 03:35 PM, Boris BREZILLON wrote:
>>>> Add a new parameter to support deglitch filter configuration.
>>>> A deglitch filter works like a debounce filter but with a smaller
>>>> delay (nanoseconds).
>>> Why not use the existing debounce property, just with a small delay
>>> specified. It seems like that's exactly what the property is for?
>> That's one of the question I asked in my cover letter :-)
>>
>> Indeed the at91 deglitch filter delay is not configurable and is statically
>> assigned to half a master clk cycle (if master clk = 133MHz -> 8 ns).
>> The debounce property argument is currently expressed in usecs.
>>
>> This will result in always selecting the debounce filter (which is also
>> available on at91 SoCs) over the deglitch filter.
>>
>> Could we add a flag in the deglitch argument to specify the delay unit
>> (nsecs or usecs) ?
> If the value is hard-coded in HW, why not use non-zero (or 1) to enable
> and zero to disable?

Indeed at91 pins support both deglitch and debounce filter and I have to 
choose
between the two given the argument value (in usec).

Here's what I can do:

if (arg >= 1/2 * slowclock)    /* debounce case */
     /* choose debounce filter and configure the delay
         according to the given argument value */
else                                          /* deglitch case */
     /* choose deglitch filter */


Slow clock is running at 32KHz which gives a 30 usec clock cycle.

>
> (this kind of thing is why I'm not convinced that generic pinconf works
> so well... What if we need psecs in the future?)

Should I keep the at91 native pinconf binding and add the missing flags 
to this binding
(OUTPUT configuration flags) ?

This was another question I asked in my cover letter: wether or not the 
generic pinconf
binding should be used.


  reply	other threads:[~2013-08-27  6:26 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-24 21:32 [RFC PATCH 0/3] pinctrl: at91: add support for generic pinconf Boris BREZILLON
2013-08-24 21:35 ` [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter Boris BREZILLON
2013-08-26 16:50   ` Stephen Warren
2013-08-26 17:01     ` boris brezillon
2013-08-27  3:55       ` Stephen Warren
2013-08-27  6:16         ` boris brezillon [this message]
2013-08-27  7:42           ` Nicolas Ferre
2013-08-27  8:28             ` boris brezillon
2013-08-27 21:33             ` Stephen Warren
2013-08-28 13:22               ` Linus Walleij
2013-08-28 13:13             ` Linus Walleij
2013-08-24 21:37 ` [RFC PATCH 2/3] pinctrl: at91: add support for generic pinconf Boris BREZILLON
2013-08-26 16:53   ` Stephen Warren
2013-08-26 17:17     ` boris brezillon
2013-08-27  3:57       ` Stephen Warren
2013-08-27  6:40         ` boris brezillon
2013-08-27 21:35           ` Stephen Warren
2013-08-26 17:53   ` Jean-Christophe PLAGNIOL-VILLARD
2013-08-26 18:45     ` boris brezillon
2013-08-26 19:18       ` Jean-Christophe PLAGNIOL-VILLARD
2013-08-26 19:48         ` boris brezillon
2013-08-27  7:51         ` Nicolas Ferre
2013-08-27  3:54       ` Stephen Warren
2013-08-27  6:04         ` boris brezillon
2013-08-27 21:30           ` Stephen Warren
2013-08-24 21:40 ` [RFC PATCH 3/3] ARM: at91/dt: move sama5 to " Boris BREZILLON
2013-08-28 12:28   ` Linus Walleij
2013-08-28 12:52     ` boris brezillon
2013-08-24 21:43 ` [RFC PATCH 0/3] pinctrl: at91: add support for " boris brezillon

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=521C4451.1060908@overkiz.com \
    --to=b.brezillon@overkiz.com \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=ian.campbell@citrix.com \
    --cc=james.hogan@imgtec.com \
    --cc=jkosina@suse.cz \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=nicolas.ferre@atmel.com \
    --cc=pawel.moll@arm.com \
    --cc=plagnioj@jcrosoft.com \
    --cc=richard.genoud@gmail.com \
    --cc=rob.herring@calxeda.com \
    --cc=rob@landley.net \
    --cc=standby24x7@gmail.com \
    --cc=swarren@wwwdotorg.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