Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
On Tue, Aug 27, 2013 at 11:33 PM, Stephen Warren wrote: > On 08/27/2013 01:42 AM, Nicolas Ferre wrote: >> The question is: how much this "generic" pinconf is... well... generic! > > This is why I don't really like the concept of generic pinconf; it ends > up being more: whoever defines something first imposes their SoCs' > viewpoint on that feature/property, and then everything else is declared > non-generic. I do not see it that way. For pinconf what we're dealing with is a very small community of electrical engineers that produce the cell libraries for the pads of these ASICs, and connect some of the control lines to software-controlled registers and sometimes hard-code their characteristics. Or a mix. They are all learning from each other and reproducing the design patterns of other engineers, much in the same way as software engineers do. That is why everyone is implementing some things like pull-up/pull-down/drive strength/schmitt-trigger etc. We already have 7 drivers using GENERIC_PINCONF without any ontological conflicts like this so even if the rest of the world end up not using it we have already saved a few thousand lines of code by not reimplementing this (including DT bindings and parsing code) over and over again for each. And given that pinctrl-single is one of these, I do hope and think that the ACPI people are taking notice and in their case, since standardized ACPI tables must describe all systems out there, a top-down ten commandments type of pin config is necessary for their specs. (My interpretation though.) Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
On Tue, Aug 27, 2013 at 9:42 AM, Nicolas Ferre wrote: > On 27/08/2013 08:16, boris brezillon : > Deglitch and > Debounce filters are different features in at91 (even if they pursuit the > same goal). So I do prefer to let the user choose which feature is preferred > for his application and add a different flag. Electrically speaking debounce and deglitch are totally different things. Debounce is for, well debouncing. To even out the effect of pressing a button which due to mechanical characteristics create a sharp series of spikes like that: _ _ _| |_| |_ I highly suspect that "deglitch" is either: - A one-spike version of the above (in which case a custom config may be warranted) or - What we usually call schmitt-trigger, i.e. handling of analog swing-in. Can you describe exactly what the two features do, in electrical terms? > The question is: how much this "generic" pinconf is... well... generic! And > it is not a answer I can give. The generic configs are defined from electrical use-cases that appear in practice and also have the character of appearing in similar implementations in I/O cells of several vendors, to the point that from a software perspective they are identical. > On the other hand, if the "generic" is not going to overcome the native > pinctrl, I do not feel like switching to this at the cost of changing the > whole dtsi/dts entries that we already have. The question we ask in this case is whether the electrical construction is so fantastically unique and ingenious that no other ASIC pad implementer sitting in his chamber working on I/O cells would possibly ever come up with the same concept. If that is true, then it warrants its own, custom binding. If you ask some other randong cell implementer whether this is something they would do, and they say "yeah I have that in the next version of my cell library" then it is generic, because we will see the same thing in other systems as time moves on. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
On Tue, Aug 27, 2013 at 9:42 AM, Nicolas Ferre nicolas.fe...@atmel.com wrote: On 27/08/2013 08:16, boris brezillon : Deglitch and Debounce filters are different features in at91 (even if they pursuit the same goal). So I do prefer to let the user choose which feature is preferred for his application and add a different flag. Electrically speaking debounce and deglitch are totally different things. Debounce is for, well debouncing. To even out the effect of pressing a button which due to mechanical characteristics create a sharp series of spikes like that: _ _ _| |_| |_ I highly suspect that deglitch is either: - A one-spike version of the above (in which case a custom config may be warranted) or - What we usually call schmitt-trigger, i.e. handling of analog swing-in. Can you describe exactly what the two features do, in electrical terms? The question is: how much this generic pinconf is... well... generic! And it is not a answer I can give. The generic configs are defined from electrical use-cases that appear in practice and also have the character of appearing in similar implementations in I/O cells of several vendors, to the point that from a software perspective they are identical. On the other hand, if the generic is not going to overcome the native pinctrl, I do not feel like switching to this at the cost of changing the whole dtsi/dts entries that we already have. The question we ask in this case is whether the electrical construction is so fantastically unique and ingenious that no other ASIC pad implementer sitting in his chamber working on I/O cells would possibly ever come up with the same concept. If that is true, then it warrants its own, custom binding. If you ask some other randong cell implementer whether this is something they would do, and they say yeah I have that in the next version of my cell library then it is generic, because we will see the same thing in other systems as time moves on. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
On Tue, Aug 27, 2013 at 11:33 PM, Stephen Warren swar...@wwwdotorg.org wrote: On 08/27/2013 01:42 AM, Nicolas Ferre wrote: The question is: how much this generic pinconf is... well... generic! This is why I don't really like the concept of generic pinconf; it ends up being more: whoever defines something first imposes their SoCs' viewpoint on that feature/property, and then everything else is declared non-generic. I do not see it that way. For pinconf what we're dealing with is a very small community of electrical engineers that produce the cell libraries for the pads of these ASICs, and connect some of the control lines to software-controlled registers and sometimes hard-code their characteristics. Or a mix. They are all learning from each other and reproducing the design patterns of other engineers, much in the same way as software engineers do. That is why everyone is implementing some things like pull-up/pull-down/drive strength/schmitt-trigger etc. We already have 7 drivers using GENERIC_PINCONF without any ontological conflicts like this so even if the rest of the world end up not using it we have already saved a few thousand lines of code by not reimplementing this (including DT bindings and parsing code) over and over again for each. And given that pinctrl-single is one of these, I do hope and think that the ACPI people are taking notice and in their case, since standardized ACPI tables must describe all systems out there, a top-down ten commandments type of pin config is necessary for their specs. (My interpretation though.) Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
On 08/27/2013 01:42 AM, Nicolas Ferre wrote: > On 27/08/2013 08:16, boris brezillon : >> 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. > > I am not in favor for this kind of complicated heuristic. Deglitch and > Debounce filters are different features in at91 (even if they pursuit > the same goal). So I do prefer to let the user choose which feature is > preferred for his application and add a different flag. > > >>> (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. > > The question is: how much this "generic" pinconf is... well... generic! This is why I don't really like the concept of generic pinconf; it ends up being more: whoever defines something first imposes their SoCs' viewpoint on that feature/property, and then everything else is declared non-generic. In many cases, I think bindings will need to add SoC-specific properties beyond generic pinconf (or perhaps only use SoC-specific properties and ignore generic pinconf). In the case of deglitch here, perhaps that's the best answer. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
On 27/08/2013 09:42, Nicolas Ferre wrote: On 27/08/2013 08:16, boris brezillon : 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. I am not in favor for this kind of complicated heuristic. Deglitch and Debounce filters are different features in at91 (even if they pursuit the same goal). So I do prefer to let the user choose which feature is preferred for his application and add a different flag. (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. The question is: how much this "generic" pinconf is... well... generic! And it is not a answer I can give. On the other hand, if the "generic" is not going to overcome the native pinctrl, I do not feel like switching to this at the cost of changing the whole dtsi/dts entries that we already have. So, it is more to Linus and Stephen to give us clues about this... Okay. I'll propose a new patch series adding native support for OUTPUT configuration of at91 pins (add OUTPUT_HIGH/LOW), and put this series in stand-by until a clear decision is made about generic pinconf. Thanks, Best Regards, Boris Bye, -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
On 27/08/2013 08:16, boris brezillon : 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. I am not in favor for this kind of complicated heuristic. Deglitch and Debounce filters are different features in at91 (even if they pursuit the same goal). So I do prefer to let the user choose which feature is preferred for his application and add a different flag. (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. The question is: how much this "generic" pinconf is... well... generic! And it is not a answer I can give. On the other hand, if the "generic" is not going to overcome the native pinctrl, I do not feel like switching to this at the cost of changing the whole dtsi/dts entries that we already have. So, it is more to Linus and Stephen to give us clues about this... Bye, -- Nicolas Ferre -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
On 27/08/2013 08:16, boris brezillon : 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. I am not in favor for this kind of complicated heuristic. Deglitch and Debounce filters are different features in at91 (even if they pursuit the same goal). So I do prefer to let the user choose which feature is preferred for his application and add a different flag. (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. The question is: how much this generic pinconf is... well... generic! And it is not a answer I can give. On the other hand, if the generic is not going to overcome the native pinctrl, I do not feel like switching to this at the cost of changing the whole dtsi/dts entries that we already have. So, it is more to Linus and Stephen to give us clues about this... Bye, -- Nicolas Ferre -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
On 27/08/2013 09:42, Nicolas Ferre wrote: On 27/08/2013 08:16, boris brezillon : 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. I am not in favor for this kind of complicated heuristic. Deglitch and Debounce filters are different features in at91 (even if they pursuit the same goal). So I do prefer to let the user choose which feature is preferred for his application and add a different flag. (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. The question is: how much this generic pinconf is... well... generic! And it is not a answer I can give. On the other hand, if the generic is not going to overcome the native pinctrl, I do not feel like switching to this at the cost of changing the whole dtsi/dts entries that we already have. So, it is more to Linus and Stephen to give us clues about this... Okay. I'll propose a new patch series adding native support for OUTPUT configuration of at91 pins (add OUTPUT_HIGH/LOW), and put this series in stand-by until a clear decision is made about generic pinconf. Thanks, Best Regards, Boris Bye, -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
On 08/27/2013 01:42 AM, Nicolas Ferre wrote: On 27/08/2013 08:16, boris brezillon : 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. I am not in favor for this kind of complicated heuristic. Deglitch and Debounce filters are different features in at91 (even if they pursuit the same goal). So I do prefer to let the user choose which feature is preferred for his application and add a different flag. (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. The question is: how much this generic pinconf is... well... generic! This is why I don't really like the concept of generic pinconf; it ends up being more: whoever defines something first imposes their SoCs' viewpoint on that feature/property, and then everything else is declared non-generic. In many cases, I think bindings will need to add SoC-specific properties beyond generic pinconf (or perhaps only use SoC-specific properties and ignore generic pinconf). In the case of deglitch here, perhaps that's the best answer. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
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? (this kind of thing is why I'm not convinced that generic pinconf works so well... What if we need psecs in the future?) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
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) ? Best Regards, Boris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
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? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
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? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
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) ? Best Regards, Boris -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
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? (this kind of thing is why I'm not convinced that generic pinconf works so well... What if we need psecs in the future?) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
Add a new parameter to support deglitch filter configuration.
A deglitch filter works like a debounce filter but with a smaller
delay (nanoseconds).
Signed-off-by: Boris BREZILLON
---
.../bindings/pinctrl/pinctrl-bindings.txt |1 +
drivers/pinctrl/pinconf-generic.c |2 ++
include/linux/pinctrl/pinconf-generic.h|5 +
3 files changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
index 1958ca9..2f7613e 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
@@ -154,6 +154,7 @@ drive-strength - sink or source at most X mA
input-schmitt-enable - enable schmitt-trigger mode
input-schmitt-disable - disable schmitt-trigger mode
input-debounce - debounce mode with debound time X
+input-deglitch - deglitch mode
low-power-enable - enable low power mode
low-power-disable - disable low power mode
output-low - set the pin to output mode with low level
diff --git a/drivers/pinctrl/pinconf-generic.c
b/drivers/pinctrl/pinconf-generic.c
index 2c62225..f14a386 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -51,6 +51,7 @@ static struct pin_config_item conf_items[] = {
PCONFDUMP(PIN_CONFIG_INPUT_SCHMITT_ENABLE, "input schmitt enabled",
NULL),
PCONFDUMP(PIN_CONFIG_INPUT_SCHMITT, "input schmitt trigger", NULL),
PCONFDUMP(PIN_CONFIG_INPUT_DEBOUNCE, "input debounce", "usec"),
+ PCONFDUMP(PIN_CONFIG_INPUT_DEGLITCH, "input deglitch", NULL),
PCONFDUMP(PIN_CONFIG_POWER_SOURCE, "pin power source", "selector"),
PCONFDUMP(PIN_CONFIG_SLEW_RATE, "slew rate", NULL),
PCONFDUMP(PIN_CONFIG_LOW_POWER_MODE, "pin low power", "mode"),
@@ -163,6 +164,7 @@ static struct pinconf_generic_dt_params dt_params[] = {
{ "input-schmitt-enable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
{ "input-schmitt-disable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 0 },
{ "input-debounce", PIN_CONFIG_INPUT_DEBOUNCE, 0 },
+ { "input-deglitch", PIN_CONFIG_INPUT_DEGLITCH, 0 },
{ "low-power-enable", PIN_CONFIG_LOW_POWER_MODE, 1 },
{ "low-power-disable", PIN_CONFIG_LOW_POWER_MODE, 0 },
{ "output-low", PIN_CONFIG_OUTPUT, 0, },
diff --git a/include/linux/pinctrl/pinconf-generic.h
b/include/linux/pinctrl/pinconf-generic.h
index fb90ef5..aa06535 100644
--- a/include/linux/pinctrl/pinconf-generic.h
+++ b/include/linux/pinctrl/pinconf-generic.h
@@ -72,6 +72,10 @@
* which means it will wait for signals to settle when reading inputs. The
* argument gives the debounce time in usecs. Setting the
* argument to zero turns debouncing off.
+ * @PIN_CONFIG_INPUT_DEGLITCH: this will configure the pin to deglitch mode,
+ * which means it will wait for signals to settle when reading inputs. The
+ * If the argument != 0, deglitch mode is enabled. If it's 0, deglitch
+ * mode is disabled.
* @PIN_CONFIG_POWER_SOURCE: if the pin can select between different power
* supplies, the argument to this parameter (on a custom format) tells
* the driver which alternative power source to use.
@@ -102,6 +106,7 @@ enum pin_config_param {
PIN_CONFIG_INPUT_SCHMITT_ENABLE,
PIN_CONFIG_INPUT_SCHMITT,
PIN_CONFIG_INPUT_DEBOUNCE,
+ PIN_CONFIG_INPUT_DEGLITCH,
PIN_CONFIG_POWER_SOURCE,
PIN_CONFIG_SLEW_RATE,
PIN_CONFIG_LOW_POWER_MODE,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/3] pinctrl: add new generic pinconf config for deglitch filter
Add a new parameter to support deglitch filter configuration.
A deglitch filter works like a debounce filter but with a smaller
delay (nanoseconds).
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
---
.../bindings/pinctrl/pinctrl-bindings.txt |1 +
drivers/pinctrl/pinconf-generic.c |2 ++
include/linux/pinctrl/pinconf-generic.h|5 +
3 files changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
index 1958ca9..2f7613e 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
@@ -154,6 +154,7 @@ drive-strength - sink or source at most X mA
input-schmitt-enable - enable schmitt-trigger mode
input-schmitt-disable - disable schmitt-trigger mode
input-debounce - debounce mode with debound time X
+input-deglitch - deglitch mode
low-power-enable - enable low power mode
low-power-disable - disable low power mode
output-low - set the pin to output mode with low level
diff --git a/drivers/pinctrl/pinconf-generic.c
b/drivers/pinctrl/pinconf-generic.c
index 2c62225..f14a386 100644
--- a/drivers/pinctrl/pinconf-generic.c
+++ b/drivers/pinctrl/pinconf-generic.c
@@ -51,6 +51,7 @@ static struct pin_config_item conf_items[] = {
PCONFDUMP(PIN_CONFIG_INPUT_SCHMITT_ENABLE, input schmitt enabled,
NULL),
PCONFDUMP(PIN_CONFIG_INPUT_SCHMITT, input schmitt trigger, NULL),
PCONFDUMP(PIN_CONFIG_INPUT_DEBOUNCE, input debounce, usec),
+ PCONFDUMP(PIN_CONFIG_INPUT_DEGLITCH, input deglitch, NULL),
PCONFDUMP(PIN_CONFIG_POWER_SOURCE, pin power source, selector),
PCONFDUMP(PIN_CONFIG_SLEW_RATE, slew rate, NULL),
PCONFDUMP(PIN_CONFIG_LOW_POWER_MODE, pin low power, mode),
@@ -163,6 +164,7 @@ static struct pinconf_generic_dt_params dt_params[] = {
{ input-schmitt-enable, PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
{ input-schmitt-disable, PIN_CONFIG_INPUT_SCHMITT_ENABLE, 0 },
{ input-debounce, PIN_CONFIG_INPUT_DEBOUNCE, 0 },
+ { input-deglitch, PIN_CONFIG_INPUT_DEGLITCH, 0 },
{ low-power-enable, PIN_CONFIG_LOW_POWER_MODE, 1 },
{ low-power-disable, PIN_CONFIG_LOW_POWER_MODE, 0 },
{ output-low, PIN_CONFIG_OUTPUT, 0, },
diff --git a/include/linux/pinctrl/pinconf-generic.h
b/include/linux/pinctrl/pinconf-generic.h
index fb90ef5..aa06535 100644
--- a/include/linux/pinctrl/pinconf-generic.h
+++ b/include/linux/pinctrl/pinconf-generic.h
@@ -72,6 +72,10 @@
* which means it will wait for signals to settle when reading inputs. The
* argument gives the debounce time in usecs. Setting the
* argument to zero turns debouncing off.
+ * @PIN_CONFIG_INPUT_DEGLITCH: this will configure the pin to deglitch mode,
+ * which means it will wait for signals to settle when reading inputs. The
+ * If the argument != 0, deglitch mode is enabled. If it's 0, deglitch
+ * mode is disabled.
* @PIN_CONFIG_POWER_SOURCE: if the pin can select between different power
* supplies, the argument to this parameter (on a custom format) tells
* the driver which alternative power source to use.
@@ -102,6 +106,7 @@ enum pin_config_param {
PIN_CONFIG_INPUT_SCHMITT_ENABLE,
PIN_CONFIG_INPUT_SCHMITT,
PIN_CONFIG_INPUT_DEBOUNCE,
+ PIN_CONFIG_INPUT_DEGLITCH,
PIN_CONFIG_POWER_SOURCE,
PIN_CONFIG_SLEW_RATE,
PIN_CONFIG_LOW_POWER_MODE,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
