Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <60402ff3-db73-5fc0-bc2a-942d664085ec@linaro.org>
Date:   Mon, 11 Apr 2022 14:52:26 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.7.0
Subject: Re: [PATCH 1/3] dt-bindings: input: Add bindings for Awinic AW8695
 haptics
Content-Language: en-US
To:     Luca Weiss <luca.weiss@fairphone.com>, linux-input@vger.kernel.org
Cc:     ~postmarketos/upstreaming@lists.sr.ht, phone-devel@vger.kernel.org,
        Dmitry Torokhov <dmitry.torokhov@gmail.com>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzk+dt@kernel.org>,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20220408115311.237039-1-luca.weiss@fairphone.com>
 <1a45984a-752b-6bad-0320-f0946d83f2b9@linaro.org>
 <CJ79EIW9Z89J.YZTZ6AU91TGE@otso>
From:   Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
In-Reply-To: <CJ79EIW9Z89J.YZTZ6AU91TGE@otso>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 11/04/2022 10:15, Luca Weiss wrote:

(...)

>>> +  awinic,f0-detection-play-time:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>> +    description: Drive waveform play times in the first period in the f0 detection
>>
>> Use standard unit suffixes for known units (e.g. time).
> 
> While the datasheet doesn't mention any time unit, the value is used to
> calculate the f0_trace_ms variable (which is milliseconds) but the
> result also depends on the awinic,f0-preset value, so it's not a raw
> time value.

I see, ok.

> 
>>
>>> +
>>> +  awinic,f0-detection-wait-time:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>> +    description: Waveform wait times in the f0 detection
>>
>> Ditto.
>>
>>> +
>>> +  awinic,f0-detection-repeat:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>> +    description: Repeat times in the f0 detection
>>> +
>>> +  awinic,f0-detection-trace:
>>> +    $ref: /schemas/types.yaml#/definitions/uint32
>>> +    description: Drive waveform play times in the second period and later in the f0 detection
>>> +
>>> +  awinic,boost-debug:
>>> +    $ref: /schemas/types.yaml#/definitions/uint8-array
>>> +    minItems: 3
>>> +    maxItems: 3
>>> +    description: Values for BSTDBG1-3 registers
>>
>> Do not encode device programming model (registers) into the binding. You
>> need to define it as a property related to hardware itself, not its
>> registers (e.g. boost value in mV).
> 
> Unfortunately I couldn't figure the meaning for this and the two values
> below.
> 
> The datasheet doesn't mention these registers at all and the downstream
> driver doesn't do anything meaningful with them (other than setting them)
> nor has any comment to indicate what they do.
> In the datasheet there's only BSTDBG4 mentioned where bits [5:1] mean
> PVDD output voltage setting so for these registers it could really be
> anthing :(
> 
> Maybe someone with more knowledge about LRAs might be able to decipher
> what tset and r_spare is at least? I unfortunately didn't manage.

Do you have to define them in such case in DT? Maybe it should be part
of driver?

Best regards,
Krzysztof