From: b.brezillon@overkiz.com (boris brezillon)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH alt 4/4] pinctrl: at91: rework debounce configuration
Date: Mon, 16 Sep 2013 19:18:37 +0200 [thread overview]
Message-ID: <52373D6D.4010109@overkiz.com> (raw)
In-Reply-To: <523734B2.6050208@wwwdotorg.org>
Hello Stephen,
On 16/09/2013 18:41, Stephen Warren wrote:
> 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).
Actually it does: this patch removes the debounce time setting option from
the pin config description. The only thing you can do is enable or
disable the
debounce filter.
The atmel,default-debounce-div property is not part of the pin group (or
pin state)
node, it is a global property you define for the whole pinctrl
controller (pinctrl node
property):
pinctrl {
atmel,default-debounce-div=<100 /* PIOA div <=> ~3 ms */
50 /* PIOB
div */
...>;
function {
group {
atmel,pins=<...>;
};
};
};
I can get the debounce time option in a separate property (as you're
suggesting):
pinctrl {
function {
group {
atmel,debounce=<1000>; /* debounce in usec */
atmel,pins=<...>;
};
};
};
but it won't solve the primary issue, that is all the pin on a given
bank (PIOA1 PIOA2, ...)
share the same debounce time.
Please tell me if I misunderstood your suggestion.
Best Regards,
Boris
WARNING: multiple messages have this Message-ID (diff)
From: boris brezillon <b.brezillon@overkiz.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org,
Ian Campbell <ian.campbell@citrix.com>,
Pawel Moll <pawel.moll@arm.com>,
linux-doc@vger.kernel.org,
Richard Genoud <richard.genoud@gmail.com>,
Jiri Kosina <jkosina@suse.cz>,
Linus Walleij <linus.walleij@linaro.org>,
Nicolas Ferre <nicolas.ferre@atmel.com>,
linux-kernel@vger.kernel.org,
Rob Herring <rob.herring@calxeda.com>,
Rob Landley <rob@landley.net>,
Grant Likely <grant.likely@linaro.org>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC PATCH alt 4/4] pinctrl: at91: rework debounce configuration
Date: Mon, 16 Sep 2013 19:18:37 +0200 [thread overview]
Message-ID: <52373D6D.4010109@overkiz.com> (raw)
In-Reply-To: <523734B2.6050208@wwwdotorg.org>
Hello Stephen,
On 16/09/2013 18:41, Stephen Warren wrote:
> 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).
Actually it does: this patch removes the debounce time setting option from
the pin config description. The only thing you can do is enable or
disable the
debounce filter.
The atmel,default-debounce-div property is not part of the pin group (or
pin state)
node, it is a global property you define for the whole pinctrl
controller (pinctrl node
property):
pinctrl {
atmel,default-debounce-div=<100 /* PIOA div <=> ~3 ms */
50 /* PIOB
div */
...>;
function {
group {
atmel,pins=<...>;
};
};
};
I can get the debounce time option in a separate property (as you're
suggesting):
pinctrl {
function {
group {
atmel,debounce=<1000>; /* debounce in usec */
atmel,pins=<...>;
};
};
};
but it won't solve the primary issue, that is all the pin on a given
bank (PIOA1 PIOA2, ...)
share the same debounce time.
Please tell me if I misunderstood your suggestion.
Best Regards,
Boris
WARNING: multiple messages have this Message-ID (diff)
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>,
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 19:18:37 +0200 [thread overview]
Message-ID: <52373D6D.4010109@overkiz.com> (raw)
In-Reply-To: <523734B2.6050208@wwwdotorg.org>
Hello Stephen,
On 16/09/2013 18:41, Stephen Warren wrote:
> 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).
Actually it does: this patch removes the debounce time setting option from
the pin config description. The only thing you can do is enable or
disable the
debounce filter.
The atmel,default-debounce-div property is not part of the pin group (or
pin state)
node, it is a global property you define for the whole pinctrl
controller (pinctrl node
property):
pinctrl {
atmel,default-debounce-div=<100 /* PIOA div <=> ~3 ms */
50 /* PIOB
div */
...>;
function {
group {
atmel,pins=<...>;
};
};
};
I can get the debounce time option in a separate property (as you're
suggesting):
pinctrl {
function {
group {
atmel,debounce=<1000>; /* debounce in usec */
atmel,pins=<...>;
};
};
};
but it won't solve the primary issue, that is all the pin on a given
bank (PIOA1 PIOA2, ...)
share the same debounce time.
Please tell me if I misunderstood your suggestion.
Best Regards,
Boris
next prev parent reply other threads:[~2013-09-16 17:18 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
2013-09-16 16:41 ` Stephen Warren
2013-09-16 16:41 ` Stephen Warren
2013-09-16 17:18 ` boris brezillon [this message]
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=52373D6D.4010109@overkiz.com \
--to=b.brezillon@overkiz.com \
--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.