[PATCH] dt-bindings: sound: ts3a227e: add control of debounce times
Add devicetree parameters to control the insertion, release and press debounce times.
Signed-off-by: Astrid Rost astrid.rost@axis.com --- Documentation/devicetree/bindings/sound/ts3a227e.txt | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/ts3a227e.txt b/Documentation/devicetree/bindings/sound/ts3a227e.txt index 21ab45bc7e8f..a4aa4154c54c 100644 --- a/Documentation/devicetree/bindings/sound/ts3a227e.txt +++ b/Documentation/devicetree/bindings/sound/ts3a227e.txt @@ -17,6 +17,15 @@ Optional properies: Select 0/1/2/3/4/5/6/7 to specify MICBIAS voltage 2.1V/2.2V/2.3V/2.4V/2.5V/2.6V/2.7V/2.8V Default value is "1" (2.2V). + - ti,debounce-release: key release debounce (datasheet section 9.6.7). + Select 0/1 to specify the release debounce time 0ms/20ms + Default value is "1" (20 ms). + - ti,debounce-press: key press debounce (datasheet section 9.6.7). + Select 0/1/2/3 to specify the press debounce time 2ms/40ms/80ms/120ms + Default value is "2" (80 ms). + - ti,debounce-insertion: headset insertion debounce (datasheet section 9.6.5). + Select 0/1/2/3/4/5/6/7 to specify the insertion debounce time 2ms/30ms/60ms/90ms/120ms/150ms/1s/2s + Default value is "3" (90 ms).
Examples:
On 07/09/2022 15:58, Astrid Rost wrote:
Add devicetree parameters to control the insertion, release and press debounce times.
Signed-off-by: Astrid Rost astrid.rost@axis.com
Documentation/devicetree/bindings/sound/ts3a227e.txt | 9 +++++++++ 1 file changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/ts3a227e.txt b/Documentation/devicetree/bindings/sound/ts3a227e.txt index 21ab45bc7e8f..a4aa4154c54c 100644 --- a/Documentation/devicetree/bindings/sound/ts3a227e.txt +++ b/Documentation/devicetree/bindings/sound/ts3a227e.txt @@ -17,6 +17,15 @@ Optional properies: Select 0/1/2/3/4/5/6/7 to specify MICBIAS voltage 2.1V/2.2V/2.3V/2.4V/2.5V/2.6V/2.7V/2.8V Default value is "1" (2.2V).
- ti,debounce-release: key release debounce (datasheet section 9.6.7).
Use standard property units "-ms".
Anyway new properties cannot be accepted. This has to be converted to DT schema (YAML).
Best regards, Krzysztof
On Thu, Sep 08, 2022 at 02:20:42PM +0200, Krzysztof Kozlowski wrote:
Anyway new properties cannot be accepted. This has to be converted to DT schema (YAML).
Doing a whole binding conversion feels like a bit of a steep requirement when people are just adding a simple property, it's a lot of stop energy to figure out the tooling, do the conversion and deal with all the bikeshedding that the tools don't catch. It's definitely nice if people want to look at that, for more complex binding changes it gets more reasonable but for trivial properties it's disproportionate.
Hello,
Use standard property units "-ms".
I made it in exactly the same way as it is done for the "ti,micbias:".
- ti,micbias: Intended MICBIAS voltage (datasheet section 9.6.7). Select 0/1/2/3/4/5/6/7 to specify MICBIAS voltage 2.1V/2.2V/2.3V/2.4V/2.5V/2.6V/2.7V/2.8V Default value is "1" (2.2V).
?> Anyway new properties cannot be accepted. This has to be converted to DT ?> schema (YAML).
Doing a whole binding conversion feels like a bit of a steep requirement when people are just adding a simple property, it's a lot of stop energy to figure out the tooling, do the conversion and deal with all the bikeshedding that the tools don't catch. It's definitely nice if people want to look at that, for more complex binding changes it gets more reasonable but for trivial properties it's disproportionate.
Thanks, I am not really sure how yaml works. But I can have a look.
Astrid
On 09/09/2022 09:16, Astrid Rost wrote:
Hello,
Use standard property units "-ms".
I made it in exactly the same way as it is done for the "ti,micbias:".
- ti,micbias: Intended MICBIAS voltage (datasheet section 9.6.7). Select 0/1/2/3/4/5/6/7 to specify MICBIAS voltage 2.1V/2.2V/2.3V/2.4V/2.5V/2.6V/2.7V/2.8V Default value is "1" (2.2V).
That's not correct way. Logical units should be encoded in logical units, e.g. microvolt. This makes the binding re-usable, extendable (imagine new device from the family where these values map to something else!) and also the easiest to read.
?> Anyway new properties cannot be accepted. This has to be converted to DT ?> schema (YAML).
Doing a whole binding conversion feels like a bit of a steep requirement when people are just adding a simple property, it's a lot of stop energy to figure out the tooling, do the conversion and deal with all the bikeshedding that the tools don't catch. It's definitely nice if people want to look at that, for more complex binding changes it gets more reasonable but for trivial properties it's disproportionate.
Thanks, I am not really sure how yaml works. But I can have a look.
Documentation/devicetree/bindings/writing-schema.rst (and example-schema in the same place)
Best regards, Krzysztof
On 08/09/2022 16:35, Mark Brown wrote:
On Thu, Sep 08, 2022 at 02:20:42PM +0200, Krzysztof Kozlowski wrote:
Anyway new properties cannot be accepted. This has to be converted to DT schema (YAML).
Doing a whole binding conversion feels like a bit of a steep requirement when people are just adding a simple property, it's a lot of stop energy to figure out the tooling, do the conversion and deal with all the bikeshedding that the tools don't catch. It's definitely nice if people want to look at that, for more complex binding changes it gets more reasonable but for trivial properties it's disproportionate.
It's more than one property here and many patch submitters are using this reason as well. In an effect few bindings TXT grew from 5 to 10 properties in one year and still no conversion to YAML.
I understand your concerns however I have stronger motivation to do the conversion is stronger for me, than for accepting new features.
Best regards, Krzysztof
On 09/09/2022 09:23, Krzysztof Kozlowski wrote:
On 08/09/2022 16:35, Mark Brown wrote:
On Thu, Sep 08, 2022 at 02:20:42PM +0200, Krzysztof Kozlowski wrote:
Anyway new properties cannot be accepted. This has to be converted to DT schema (YAML).
Doing a whole binding conversion feels like a bit of a steep requirement when people are just adding a simple property, it's a lot of stop energy to figure out the tooling, do the conversion and deal with all the bikeshedding that the tools don't catch. It's definitely nice if people want to look at that, for more complex binding changes it gets more reasonable but for trivial properties it's disproportionate.
It's more than one property here and many patch submitters are using this reason as well. In an effect few bindings TXT grew from 5 to 10 properties in one year and still no conversion to YAML.
I understand your concerns however I have stronger motivation to do the conversion is stronger for me, than for accepting new features.
Eh, that was still during drinking coffee, so it barely reminds English sentences. Let me try one more time:
It's more than one property and many other patch submitters were using this reason as well. As a result, few TXT bindings grew from 5 to 10 properties within one year and there was still no conversion to YAML.
I understand your concerns however I have stronger motivation to do the conversion, than for accepting new features.
Best regards, Krzysztof
On Fri, Sep 09, 2022 at 10:21:30AM +0200, Krzysztof Kozlowski wrote:
It's more than one property and many other patch submitters were using this reason as well. As a result, few TXT bindings grew from 5 to 10 properties within one year and there was still no conversion to YAML.
I understand your concerns however I have stronger motivation to do the conversion, than for accepting new features.
For me the metric is proportionality - the amount of extra effort we're forcing people to go through should bear some relationship to the change they're trying to make. We can't very well complain that people don't upstream things if when they try to do so they have to jump through some tangentially related hoops relating to the existing code in order to get anything done. We can and should *ask* people to do additional cleanups or whatever but creating requirements that dramatically expand the scope of work someone's having to do are a lot of stop energy.
Hello,
It's more than one property and many other patch submitters were using this reason as well. As a result, few TXT bindings grew from 5 to 10 properties within one year and there was still no conversion to YAML.
I understand your concerns however I have stronger motivation to do the conversion, than for accepting new features.
I agree, I will do the conversion.
Astrid
Hello,
I did the conversion from txt to YAML. It requests me to add as a maintainer?
Dylan was the original Author.
Astrid
On 13/09/2022 09:16, Astrid Rost wrote:
Hello,
I did the conversion from txt to YAML. It requests me to add as a maintainer?
Dylan was the original Author.
The maintainer of the bindings should be a person caring about them and about the hardware. Usually it is a person with some access to the device or to its datasheet (but it's not a requirement). Feel free to add yourself and/or Daniel and/or any current maintainer of the driver (but not subsystem maintainer).
Best regards, Krzysztof
participants (4)
-
Astrid Rost -
Astrid Rost -
Krzysztof Kozlowski -
Mark Brown