Add devicetree parameters to control the insertion, release and press
debounce times.
Signed-off-by: Astrid Rost <[email protected]>
---
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:
--
2.20.1
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 <[email protected]>
> ---
> 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.
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
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: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