All of lore.kernel.org
 help / color / mirror / Atom feed
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH alt 4/4] pinctrl: at91: rework debounce configuration
Date: Mon, 16 Sep 2013 10:41:22 -0600	[thread overview]
Message-ID: <523734B2.6050208@wwwdotorg.org> (raw)
In-Reply-To: <52340B68.5020505@overkiz.com>

On 09/14/2013 01:08 AM, boris brezillon wrote:
> Hello Stephen,
> 
> Le 14/09/2013 00:40, Stephen Warren a ?crit :
>> On 09/13/2013 01:53 AM, Boris BREZILLON wrote:
>>> AT91 SoCs do not support per pin debounce time configuration.
>>> Instead you have to configure a debounce time which will be used for all
>>> pins of a given bank (PIOA, PIOB, ...).
...
>>>   Required properties for pin configuration node:
...
>>> -DEBOUNCE_VAL    (0x3fff << 17): debounce val.
>>
>> This change would break the DT ABI since it removes a feature that's
>> already present.
...
>> I suppose it's still up to the Atmel maintainers to decide whether this
>> is appropriate, or whether the impact to out-of-tree DT files would be
>> problematic.
>>
>> Assuming the DT ABI can be broken, I think I'd prefer to do so, rather
>> than take "non-alt" patch 4/4, since a per-pin DEBOUNCE_VAL clearly
>> doesn't correctly model the HW, assuming the patch description is
>> correct. I don't think arguments re: the generic pinconf debounce
>> property hold; if the Linux-specific/internal generic property doesn't
>> apply, the DT binding should not be bent to adjust to it, but should
>> rather still represent the HW itself.
> 
> What about the last point in my list: "reconfigure debounce after
> startup" ?
> 
> Here is an example that may be problematic:
> 
> Let's say you have one device using multiple configuration of pins
> ("default", "xxx", "yyy").
> The "default" config needs a particular debounce time on a given pin and
> the "xxx" and "yyy"
> configs need different debounce time on the same pin.
> 
> How would you solve this with this patch approach ?

Each state has a different pin configuration node, and hence can specify
a different debounce value. This patch has no impact on that (it just
changes whether the state-specific node specifies the debounce value in
a single standalone property, or encodes it into each entry in the pins
property, all within the same node).

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: boris brezillon <b.brezillon-ZNYIgs0QAGpBDgjK7y7TUQ@public.gmane.org>
Cc: Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
	Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>,
	Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>,
	Ian Campbell
	<ian.campbell-Sxgqhf6Nn4DQT0dZR+AlfA@public.gmane.org>,
	Rob Landley <rob-VoJi6FS/r0vR7s880joybQ@public.gmane.org>,
	Jean-Christophe Plagniol-Villard
	<plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>,
	Linus Walleij
	<linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Grant Likely
	<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Nicolas Ferre
	<nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>,
	Richard Genoud
	<richard.genoud-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Jiri Kosina <jkosina-AlSwsSmVLrQ@public.gmane.org>,
	devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-doc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [RFC PATCH alt 4/4] pinctrl: at91: rework debounce configuration
Date: Mon, 16 Sep 2013 10:41:22 -0600	[thread overview]
Message-ID: <523734B2.6050208@wwwdotorg.org> (raw)
In-Reply-To: <52340B68.5020505-ZNYIgs0QAGpBDgjK7y7TUQ@public.gmane.org>

On 09/14/2013 01:08 AM, boris brezillon wrote:
> Hello Stephen,
> 
> Le 14/09/2013 00:40, Stephen Warren a écrit :
>> On 09/13/2013 01:53 AM, Boris BREZILLON wrote:
>>> AT91 SoCs do not support per pin debounce time configuration.
>>> Instead you have to configure a debounce time which will be used for all
>>> pins of a given bank (PIOA, PIOB, ...).
...
>>>   Required properties for pin configuration node:
...
>>> -DEBOUNCE_VAL    (0x3fff << 17): debounce val.
>>
>> This change would break the DT ABI since it removes a feature that's
>> already present.
...
>> I suppose it's still up to the Atmel maintainers to decide whether this
>> is appropriate, or whether the impact to out-of-tree DT files would be
>> problematic.
>>
>> Assuming the DT ABI can be broken, I think I'd prefer to do so, rather
>> than take "non-alt" patch 4/4, since a per-pin DEBOUNCE_VAL clearly
>> doesn't correctly model the HW, assuming the patch description is
>> correct. I don't think arguments re: the generic pinconf debounce
>> property hold; if the Linux-specific/internal generic property doesn't
>> apply, the DT binding should not be bent to adjust to it, but should
>> rather still represent the HW itself.
> 
> What about the last point in my list: "reconfigure debounce after
> startup" ?
> 
> Here is an example that may be problematic:
> 
> Let's say you have one device using multiple configuration of pins
> ("default", "xxx", "yyy").
> The "default" config needs a particular debounce time on a given pin and
> the "xxx" and "yyy"
> configs need different debounce time on the same pin.
> 
> How would you solve this with this patch approach ?

Each state has a different pin configuration node, and hence can specify
a different debounce value. This patch has no impact on that (it just
changes whether the state-specific node specifies the debounce value in
a single standalone property, or encodes it into each entry in the pins
property, all within the same node).
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: boris brezillon <b.brezillon@overkiz.com>
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>,
	Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Grant Likely <grant.likely@linaro.org>,
	Nicolas Ferre <nicolas.ferre@atmel.com>,
	Richard Genoud <richard.genoud@gmail.com>,
	Jiri Kosina <jkosina@suse.cz>,
	devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH alt 4/4] pinctrl: at91: rework debounce configuration
Date: Mon, 16 Sep 2013 10:41:22 -0600	[thread overview]
Message-ID: <523734B2.6050208@wwwdotorg.org> (raw)
In-Reply-To: <52340B68.5020505@overkiz.com>

On 09/14/2013 01:08 AM, boris brezillon wrote:
> Hello Stephen,
> 
> Le 14/09/2013 00:40, Stephen Warren a écrit :
>> On 09/13/2013 01:53 AM, Boris BREZILLON wrote:
>>> AT91 SoCs do not support per pin debounce time configuration.
>>> Instead you have to configure a debounce time which will be used for all
>>> pins of a given bank (PIOA, PIOB, ...).
...
>>>   Required properties for pin configuration node:
...
>>> -DEBOUNCE_VAL    (0x3fff << 17): debounce val.
>>
>> This change would break the DT ABI since it removes a feature that's
>> already present.
...
>> I suppose it's still up to the Atmel maintainers to decide whether this
>> is appropriate, or whether the impact to out-of-tree DT files would be
>> problematic.
>>
>> Assuming the DT ABI can be broken, I think I'd prefer to do so, rather
>> than take "non-alt" patch 4/4, since a per-pin DEBOUNCE_VAL clearly
>> doesn't correctly model the HW, assuming the patch description is
>> correct. I don't think arguments re: the generic pinconf debounce
>> property hold; if the Linux-specific/internal generic property doesn't
>> apply, the DT binding should not be bent to adjust to it, but should
>> rather still represent the HW itself.
> 
> What about the last point in my list: "reconfigure debounce after
> startup" ?
> 
> Here is an example that may be problematic:
> 
> Let's say you have one device using multiple configuration of pins
> ("default", "xxx", "yyy").
> The "default" config needs a particular debounce time on a given pin and
> the "xxx" and "yyy"
> configs need different debounce time on the same pin.
> 
> How would you solve this with this patch approach ?

Each state has a different pin configuration node, and hence can specify
a different debounce value. This patch has no impact on that (it just
changes whether the state-specific node specifies the debounce value in
a single standalone property, or encodes it into each entry in the pins
property, all within the same node).

  reply	other threads:[~2013-09-16 16:41 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-13  7:43 [RFC PATCH 0/4] pinctrl: at91: various fixes Boris BREZILLON
2013-09-13  7:43 ` Boris BREZILLON
2013-09-13  7:43 ` Boris BREZILLON
2013-09-13  7:45 ` [RFC PATCH 1/4] pinctrl: at91: fix typos Boris BREZILLON
2013-09-13  7:45   ` Boris BREZILLON
2013-09-14 16:45   ` Jean-Christophe PLAGNIOL-VILLARD
2013-09-14 16:45     ` Jean-Christophe PLAGNIOL-VILLARD
2013-09-14 16:45     ` Jean-Christophe PLAGNIOL-VILLARD
2013-09-27 12:10   ` Linus Walleij
2013-09-27 12:10     ` Linus Walleij
2013-09-27 12:10     ` Linus Walleij
2013-09-13  7:47 ` [RFC PATCH 2/4] pinctrl: at91: fix sam9x5 debounce/deglitch functions Boris BREZILLON
2013-09-13  7:47   ` Boris BREZILLON
2013-09-14 16:49   ` Jean-Christophe PLAGNIOL-VILLARD
2013-09-14 16:49     ` Jean-Christophe PLAGNIOL-VILLARD
2013-09-14 16:49     ` Jean-Christophe PLAGNIOL-VILLARD
2013-09-27 12:12   ` Linus Walleij
2013-09-27 12:12     ` Linus Walleij
2013-09-13  7:49 ` [RFC PATCH 3/4] pinctrl: at91: improve pinconf_set/get function robustness Boris BREZILLON
2013-09-13  7:49   ` Boris BREZILLON
2013-09-14 16:55   ` Jean-Christophe PLAGNIOL-VILLARD
2013-09-14 16:55     ` Jean-Christophe PLAGNIOL-VILLARD
2013-09-14 16:55     ` Jean-Christophe PLAGNIOL-VILLARD
2013-09-13  7:51 ` [RFC PATCH 4/4] pinctrl: at91: check for debounce time conflicts Boris BREZILLON
2013-09-13  7:51   ` Boris BREZILLON
2013-09-13  7:51   ` Boris BREZILLON
2013-09-13  7:53 ` [RFC PATCH alt 4/4] pinctrl: at91: rework debounce configuration Boris BREZILLON
2013-09-13  7:53   ` Boris BREZILLON
2013-09-13  7:53   ` Boris BREZILLON
2013-09-13 22:40   ` Stephen Warren
2013-09-13 22:40     ` Stephen Warren
2013-09-13 22:40     ` Stephen Warren
2013-09-14  7:08     ` boris brezillon
2013-09-14  7:08       ` boris brezillon
2013-09-16 16:41       ` Stephen Warren [this message]
2013-09-16 16:41         ` Stephen Warren
2013-09-16 16:41         ` Stephen Warren
2013-09-16 17:18         ` boris brezillon
2013-09-16 17:18           ` boris brezillon
2013-09-16 17:18           ` boris brezillon
2013-09-16 18:14           ` Stephen Warren
2013-09-16 18:14             ` Stephen Warren
2013-09-14 16:31     ` Jean-Christophe PLAGNIOL-VILLARD
2013-09-14 16:31       ` Jean-Christophe PLAGNIOL-VILLARD
2013-09-14 16:37   ` Jean-Christophe PLAGNIOL-VILLARD
2013-09-14 16:37     ` Jean-Christophe PLAGNIOL-VILLARD
2013-09-15  6:21     ` boris brezillon
2013-09-15  6:21       ` 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=523734B2.6050208@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.