[PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support

[PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support

[Fenglin Wu]

Add support for vibrator module inside Qualcomm PMI632, PM7250B, PM7325B
PMICs.

Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
---
 Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
index c8832cd0d7da..481163105d24 100644
--- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
+++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
@@ -15,6 +15,9 @@ properties:
       - qcom,pm8058-vib
       - qcom,pm8916-vib
       - qcom,pm8921-vib
+      - qcom,pmi632-vib
+      - qcom,pm7250b-vib
+      - qcom,pm7325b-vib
 
   reg:
     maxItems: 1
-- 
2.25.1

Re: [PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support

[Krzysztof Kozlowski]

On 18/07/2023 08:26, Fenglin Wu wrote:
> Add support for vibrator module inside Qualcomm PMI632, PM7250B, PM7325B
> PMICs.
> 
> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
> ---

I don't see changelog. No changes then?

>  Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
> index c8832cd0d7da..481163105d24 100644
> --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
> +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
> @@ -15,6 +15,9 @@ properties:
>        - qcom,pm8058-vib
>        - qcom,pm8916-vib
>        - qcom,pm8921-vib
> +      - qcom,pmi632-vib
> +      - qcom,pm7250b-vib
> +      - qcom,pm7325b-vib

Not much improved. With missing changelog, it seems you ignored the
feedback.


Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support

[Fenglin Wu]

On 7/18/2023 2:33 PM, Krzysztof Kozlowski wrote:
> On 18/07/2023 08:26, Fenglin Wu wrote:
>> Add support for vibrator module inside Qualcomm PMI632, PM7250B, PM7325B
>> PMICs.
>>
>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>> ---
> 
> I don't see changelog. No changes then?
> 
Sorry, I updated the change log in the cover letter which didn't seems 
to be sent to a wider audience, I will resend it by adding more 
receivers in the to list

Fenglin
>>   Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>> index c8832cd0d7da..481163105d24 100644
>> --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>> +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>> @@ -15,6 +15,9 @@ properties:
>>         - qcom,pm8058-vib
>>         - qcom,pm8916-vib
>>         - qcom,pm8921-vib
>> +      - qcom,pmi632-vib
>> +      - qcom,pm7250b-vib
>> +      - qcom,pm7325b-vib
> 
> Not much improved. With missing changelog, it seems you ignored the
> feedback.
> 
> 
> Best regards,
> Krzysztof
> 

Re: [PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support

[Fenglin Wu]

On 7/18/2023 2:38 PM, Fenglin Wu wrote:
> 
> 
> On 7/18/2023 2:33 PM, Krzysztof Kozlowski wrote:
>> On 18/07/2023 08:26, Fenglin Wu wrote:
>>> Add support for vibrator module inside Qualcomm PMI632, PM7250B, PM7325B
>>> PMICs.
>>>
>>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>>> ---
>>
>> I don't see changelog. No changes then?
>>
> Sorry, I updated the change log in the cover letter which didn't seems 
> to be sent to a wider audience, I will resend it by adding more 
> receivers in the to list
> 
> Fenglin

Just FYI,the change log was updated in the cover letter here: 
https://lore.kernel.org/linux-arm-msm/20230718062639.2339589-1-quic_fenglinw@quicinc.com/T/#m3819b50503ef19e0933a10bf797351a4af35537f

Also the commit text and the driver change were also updated accordingly 
to address your review comment by removing 'pm7550ba-vib' compatible string.

Since the changes are receiving review comments, I will not resend it. I 
will add a larger to-list when pushing the next patchset.

>>>   Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git 
>>> a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml 
>>> b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>>> index c8832cd0d7da..481163105d24 100644
>>> --- a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>>> +++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.yaml
>>> @@ -15,6 +15,9 @@ properties:
>>>         - qcom,pm8058-vib
>>>         - qcom,pm8916-vib
>>>         - qcom,pm8921-vib
>>> +      - qcom,pmi632-vib
>>> +      - qcom,pm7250b-vib
>>> +      - qcom,pm7325b-vib
>>
>> Not much improved. With missing changelog, it seems you ignored the
>> feedback.
>>
>>
>> Best regards,
>> Krzysztof
>>

Re: [PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support

[Krzysztof Kozlowski]

On 18/07/2023 09:06, Fenglin Wu wrote:
> 
> 
> On 7/18/2023 2:38 PM, Fenglin Wu wrote:
>>
>>
>> On 7/18/2023 2:33 PM, Krzysztof Kozlowski wrote:
>>> On 18/07/2023 08:26, Fenglin Wu wrote:
>>>> Add support for vibrator module inside Qualcomm PMI632, PM7250B, PM7325B
>>>> PMICs.
>>>>
>>>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>>>> ---
>>>
>>> I don't see changelog. No changes then?
>>>
>> Sorry, I updated the change log in the cover letter which didn't seems 
>> to be sent to a wider audience, I will resend it by adding more 
>> receivers in the to list
>>
>> Fenglin
> 
> Just FYI,the change log was updated in the cover letter here: 
> https://lore.kernel.org/linux-arm-msm/20230718062639.2339589-1-quic_fenglinw@quicinc.com/T/#m3819b50503ef19e0933a10bf797351a4af35537f
> 
> Also the commit text and the driver change were also updated accordingly 
> to address your review comment by removing 'pm7550ba-vib' compatible string.

Removing compatible was never my feedback. Did you read:
https://elixir.bootlin.com/linux/v6.1-rc1/source/Documentation/devicetree/bindings/writing-bindings.rst#L42
?

Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support

[Fenglin Wu]

On 7/18/2023 3:20 PM, Krzysztof Kozlowski wrote:
> On 18/07/2023 09:06, Fenglin Wu wrote:
>>
>>
>> On 7/18/2023 2:38 PM, Fenglin Wu wrote:
>>>
>>>
>>> On 7/18/2023 2:33 PM, Krzysztof Kozlowski wrote:
>>>> On 18/07/2023 08:26, Fenglin Wu wrote:
>>>>> Add support for vibrator module inside Qualcomm PMI632, PM7250B, PM7325B
>>>>> PMICs.
>>>>>
>>>>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>>>>> ---
>>>>
>>>> I don't see changelog. No changes then?
>>>>
>>> Sorry, I updated the change log in the cover letter which didn't seems
>>> to be sent to a wider audience, I will resend it by adding more
>>> receivers in the to list
>>>
>>> Fenglin
>>
>> Just FYI,the change log was updated in the cover letter here:
>> https://lore.kernel.org/linux-arm-msm/20230718062639.2339589-1-quic_fenglinw@quicinc.com/T/#m3819b50503ef19e0933a10bf797351a4af35537f
>>
>> Also the commit text and the driver change were also updated accordingly
>> to address your review comment by removing 'pm7550ba-vib' compatible string.
> 
> Removing compatible was never my feedback. Did you read:
> https://elixir.bootlin.com/linux/v6.1-rc1/source/Documentation/devicetree/bindings/writing-bindings.rst#L42
> ?
> 
Okay, so do you want me to add 'pm7550ba-vib' as a fallback compatible 
like this?

  properties:
    compatible:
-    enum:
-      - qcom,pm8058-vib
-      - qcom,pm8916-vib
-      - qcom,pm8921-vib
-      - qcom,pmi632-vib
-      - qcom,pm7250b-vib
-      - qcom,pm7325b-vib
+    oneOf:
+      - enum:
+          - qcom,pm8058-vib
+          - qcom,pm8916-vib
+          - qcom,pm8921-vib
+          - qcom,pmi632-vib
+          - qcom,pm7250b-vib
+          - qcom,pm7325b-vib
+      - items:
+          - enum:
+              - qcom,pm7550ba-vib
+          - const: qcom,pm7325b-vib



> Best regards,
> Krzysztof
> 

Re: [PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support

[Krzysztof Kozlowski]

On 18/07/2023 09:59, Fenglin Wu wrote:

>>> Just FYI,the change log was updated in the cover letter here:
>>> https://lore.kernel.org/linux-arm-msm/20230718062639.2339589-1-quic_fenglinw@quicinc.com/T/#m3819b50503ef19e0933a10bf797351a4af35537f
>>>
>>> Also the commit text and the driver change were also updated accordingly
>>> to address your review comment by removing 'pm7550ba-vib' compatible string.
>>
>> Removing compatible was never my feedback. Did you read:
>> https://elixir.bootlin.com/linux/v6.1-rc1/source/Documentation/devicetree/bindings/writing-bindings.rst#L42
>> ?
>>
> Okay, so do you want me to add 'pm7550ba-vib' as a fallback compatible 
> like this?
> 
>   properties:
>     compatible:
> -    enum:
> -      - qcom,pm8058-vib
> -      - qcom,pm8916-vib
> -      - qcom,pm8921-vib
> -      - qcom,pmi632-vib
> -      - qcom,pm7250b-vib
> -      - qcom,pm7325b-vib
> +    oneOf:
> +      - enum:
> +          - qcom,pm8058-vib
> +          - qcom,pm8916-vib
> +          - qcom,pm8921-vib
> +          - qcom,pmi632-vib
> +          - qcom,pm7250b-vib
> +          - qcom,pm7325b-vib
> +      - items:
> +          - enum:
> +              - qcom,pm7550ba-vib
> +          - const: qcom,pm7325b-vib
> 

Yes

Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support

[Krzysztof Kozlowski]

On 18/07/2023 10:02, Krzysztof Kozlowski wrote:
> On 18/07/2023 09:59, Fenglin Wu wrote:
> 
>>>> Just FYI,the change log was updated in the cover letter here:
>>>> https://lore.kernel.org/linux-arm-msm/20230718062639.2339589-1-quic_fenglinw@quicinc.com/T/#m3819b50503ef19e0933a10bf797351a4af35537f
>>>>
>>>> Also the commit text and the driver change were also updated accordingly
>>>> to address your review comment by removing 'pm7550ba-vib' compatible string.
>>>
>>> Removing compatible was never my feedback. Did you read:
>>> https://elixir.bootlin.com/linux/v6.1-rc1/source/Documentation/devicetree/bindings/writing-bindings.rst#L42
>>> ?
>>>
>> Okay, so do you want me to add 'pm7550ba-vib' as a fallback compatible 
>> like this?
>>
>>   properties:
>>     compatible:
>> -    enum:
>> -      - qcom,pm8058-vib
>> -      - qcom,pm8916-vib
>> -      - qcom,pm8921-vib
>> -      - qcom,pmi632-vib
>> -      - qcom,pm7250b-vib
>> -      - qcom,pm7325b-vib
>> +    oneOf:
>> +      - enum:
>> +          - qcom,pm8058-vib
>> +          - qcom,pm8916-vib
>> +          - qcom,pm8921-vib
>> +          - qcom,pmi632-vib
>> +          - qcom,pm7250b-vib
>> +          - qcom,pm7325b-vib
>> +      - items:
>> +          - enum:
>> +              - qcom,pm7550ba-vib
>> +          - const: qcom,pm7325b-vib
>>
> 
> Yes

I wonder why this approved change turned out to something incorrect in
your v3 patch...

Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support

[Fenglin Wu]

On 7/27/2023 3:10 PM, Krzysztof Kozlowski wrote:
> On 18/07/2023 10:02, Krzysztof Kozlowski wrote:
>> On 18/07/2023 09:59, Fenglin Wu wrote:
>>
>>>>> Just FYI,the change log was updated in the cover letter here:
>>>>> https://lore.kernel.org/linux-arm-msm/20230718062639.2339589-1-quic_fenglinw@quicinc.com/T/#m3819b50503ef19e0933a10bf797351a4af35537f
>>>>>
>>>>> Also the commit text and the driver change were also updated accordingly
>>>>> to address your review comment by removing 'pm7550ba-vib' compatible string.
>>>>
>>>> Removing compatible was never my feedback. Did you read:
>>>> https://elixir.bootlin.com/linux/v6.1-rc1/source/Documentation/devicetree/bindings/writing-bindings.rst#L42
>>>> ?
>>>>
>>> Okay, so do you want me to add 'pm7550ba-vib' as a fallback compatible
>>> like this?
>>>
>>>    properties:
>>>      compatible:
>>> -    enum:
>>> -      - qcom,pm8058-vib
>>> -      - qcom,pm8916-vib
>>> -      - qcom,pm8921-vib
>>> -      - qcom,pmi632-vib
>>> -      - qcom,pm7250b-vib
>>> -      - qcom,pm7325b-vib
>>> +    oneOf:
>>> +      - enum:
>>> +          - qcom,pm8058-vib
>>> +          - qcom,pm8916-vib
>>> +          - qcom,pm8921-vib
>>> +          - qcom,pmi632-vib
>>> +          - qcom,pm7250b-vib
>>> +          - qcom,pm7325b-vib
>>> +      - items:
>>> +          - enum:
>>> +              - qcom,pm7550ba-vib
>>> +          - const: qcom,pm7325b-vib
>>>
>>
>> Yes
> 
> I wonder why this approved change turned out to something incorrect in
> your v3 patch...
> 
Since I got review comments in the driver change and I was told to 
refactor the driver before adding new HW support. I added the HW type 
logic in the driver and I was thinking it might be good to add some 
generic compatible strings to match with the HW type introduced in the 
driver change.

Anyway, I will update it to what you suggested in next patch.

> Best regards,
> Krzysztof
> 

Re: [PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support

[Krzysztof Kozlowski]

On 27/07/2023 09:54, Fenglin Wu wrote:
>>>> +          - enum:
>>>> +              - qcom,pm7550ba-vib
>>>> +          - const: qcom,pm7325b-vib
>>>>
>>>
>>> Yes
>>
>> I wonder why this approved change turned out to something incorrect in
>> your v3 patch...
>>
> Since I got review comments in the driver change and I was told to 
> refactor the driver before adding new HW support. I added the HW type 
> logic in the driver and I was thinking it might be good to add some 
> generic compatible strings to match with the HW type introduced in the 
> driver change.
> 
> Anyway, I will update it to what you suggested in next patch.

Drivers are not really related to bindings, so whatever HW type you add
in driver, is not a reason to change bindings. Reason to change bindings
could be for example: because hardware is like that.

Best regards,
Krzysztof

Re: [PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support

[Fenglin Wu]

On 7/27/2023 4:29 PM, Krzysztof Kozlowski wrote:
> On 27/07/2023 09:54, Fenglin Wu wrote:
>>>>> +          - enum:
>>>>> +              - qcom,pm7550ba-vib
>>>>> +          - const: qcom,pm7325b-vib
>>>>>
>>>>
>>>> Yes
>>>
>>> I wonder why this approved change turned out to something incorrect in
>>> your v3 patch...
>>>
>> Since I got review comments in the driver change and I was told to
>> refactor the driver before adding new HW support. I added the HW type
>> logic in the driver and I was thinking it might be good to add some
>> generic compatible strings to match with the HW type introduced in the
>> driver change.
>>
>> Anyway, I will update it to what you suggested in next patch.
> 
> Drivers are not really related to bindings, so whatever HW type you add
> in driver, is not a reason to change bindings. Reason to change bindings
> could be for example: because hardware is like that.
> 
Understood.

Sorry, I forgot to mention, in v3, I added the 'reg' value to the 
register offset and no longer hard code the 16-bit register address, 
that makes the vibrators inside PMI632/PM7250B/PM7325B/PM7550BA all 
compatible, and that was another motivation of adding a generic 
compatible string and make the others as the fallback.

This will be still the case in v4, I might keep it similar in v3 but 
just drop "qcom,spmi-vib-gen1"

> Best regards,
> Krzysztof
> 

Re: [PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support

[Konrad Dybcio]

On 18.07.2023 08:38, Fenglin Wu wrote:
> 
> 
> On 7/18/2023 2:33 PM, Krzysztof Kozlowski wrote:
>> On 18/07/2023 08:26, Fenglin Wu wrote:
>>> Add support for vibrator module inside Qualcomm PMI632, PM7250B, PM7325B
>>> PMICs.
>>>
>>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>>> ---
>>
>> I don't see changelog. No changes then?
>>
> Sorry, I updated the change log in the cover letter which didn't seems to be sent to a wider audience, I will resend it by adding more receivers in the to list
Please consider using the b4 tool which takes care of all that

https://b4.docs.kernel.org/en/latest/index.html

Konrad

Re: [PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support

[Fenglin Wu]

On 7/18/2023 6:51 PM, Konrad Dybcio wrote:
> On 18.07.2023 08:38, Fenglin Wu wrote:
>>
>>
>> On 7/18/2023 2:33 PM, Krzysztof Kozlowski wrote:
>>> On 18/07/2023 08:26, Fenglin Wu wrote:
>>>> Add support for vibrator module inside Qualcomm PMI632, PM7250B, PM7325B
>>>> PMICs.
>>>>
>>>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>>>> ---
>>>
>>> I don't see changelog. No changes then?
>>>
>> Sorry, I updated the change log in the cover letter which didn't seems to be sent to a wider audience, I will resend it by adding more receivers in the to list
> Please consider using the b4 tool which takes care of all that
> 
> https://b4.docs.kernel.org/en/latest/index.html
> 
Thanks Konrad, I will check and update at my side.

> Konrad

[PATCH v2 2/2] Input: pm8xxx-vib - Add support for more PMICs

[Fenglin Wu]

Add support for vibrator module inside PMI632, PM7250B, PM7325B.
It is very similar to vibrator inside PM8xxx but just the drive
amplitude is controlled through 2 bytes registers.

Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
---
 drivers/input/misc/pm8xxx-vibrator.c | 48 ++++++++++++++++++++++++++++
 1 file changed, 48 insertions(+)

diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
index 04cb87efd799..213fdfd47c7f 100644
--- a/drivers/input/misc/pm8xxx-vibrator.c
+++ b/drivers/input/misc/pm8xxx-vibrator.c
@@ -25,6 +25,9 @@ struct pm8xxx_regs {
 	unsigned int drv_addr;
 	unsigned int drv_mask;
 	unsigned int drv_shift;
+	unsigned int drv_addr2;
+	unsigned int drv_mask2;
+	unsigned int drv_shift2;
 	unsigned int drv_en_manual_mask;
 };
 
@@ -44,6 +47,42 @@ static struct pm8xxx_regs pm8916_regs = {
 	.drv_en_manual_mask = 0,
 };
 
+static struct pm8xxx_regs pmi632_regs = {
+	.enable_addr = 0x5746,
+	.enable_mask = BIT(7),
+	.drv_addr = 0x5740,
+	.drv_mask = 0xff,
+	.drv_shift = 0,
+	.drv_addr2 = 0x5741,
+	.drv_mask2 = 0x0f,
+	.drv_shift2 = 8,
+	.drv_en_manual_mask = 0,
+};
+
+static struct pm8xxx_regs pm7250b_regs = {
+	.enable_addr = 0x5346,
+	.enable_mask = BIT(7),
+	.drv_addr = 0x5340,
+	.drv_mask = 0xff,
+	.drv_shift = 0,
+	.drv_addr2 = 0x5341,
+	.drv_mask2 = 0x0f,
+	.drv_shift2 = 8,
+	.drv_en_manual_mask = 0,
+};
+
+static struct pm8xxx_regs pm7325b_regs = {
+	.enable_addr = 0xdf46,
+	.enable_mask = BIT(7),
+	.drv_addr = 0xdf40,
+	.drv_mask = 0xff,
+	.drv_shift = 0,
+	.drv_addr2 = 0xdf41,
+	.drv_mask2 = 0x0f,
+	.drv_shift2 = 8,
+	.drv_en_manual_mask = 0,
+};
+
 /**
  * struct pm8xxx_vib - structure to hold vibrator data
  * @vib_input_dev: input device supporting force feedback
@@ -87,6 +126,12 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
 		return rc;
 
 	vib->reg_vib_drv = val;
+	if (regs->drv_addr2 != 0 && on) {
+		val = (vib->level << regs->drv_shift2) & regs->drv_mask2;
+		rc = regmap_write(vib->regmap, regs->drv_addr2, val);
+		if (rc < 0)
+			return rc;
+	}
 
 	if (regs->enable_mask)
 		rc = regmap_update_bits(vib->regmap, regs->enable_addr,
@@ -242,6 +287,9 @@ static const struct of_device_id pm8xxx_vib_id_table[] = {
 	{ .compatible = "qcom,pm8058-vib", .data = &pm8058_regs },
 	{ .compatible = "qcom,pm8921-vib", .data = &pm8058_regs },
 	{ .compatible = "qcom,pm8916-vib", .data = &pm8916_regs },
+	{ .compatible = "qcom,pmi632-vib", .data = &pmi632_regs },
+	{ .compatible = "qcom,pm7250b-vib", .data = &pm7250b_regs },
+	{ .compatible = "qcom,pm7325b-vib", .data = &pm7325b_regs },
 	{ }
 };
 MODULE_DEVICE_TABLE(of, pm8xxx_vib_id_table);
-- 
2.25.1

Re: [PATCH v2 2/2] Input: pm8xxx-vib - Add support for more PMICs

[Dmitry Baryshkov]

On Tue, 18 Jul 2023 at 09:27, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
>
> Add support for vibrator module inside PMI632, PM7250B, PM7325B.
> It is very similar to vibrator inside PM8xxx but just the drive
> amplitude is controlled through 2 bytes registers.
>
> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
> ---
>  drivers/input/misc/pm8xxx-vibrator.c | 48 ++++++++++++++++++++++++++++
>  1 file changed, 48 insertions(+)
>
> diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
> index 04cb87efd799..213fdfd47c7f 100644
> --- a/drivers/input/misc/pm8xxx-vibrator.c
> +++ b/drivers/input/misc/pm8xxx-vibrator.c
> @@ -25,6 +25,9 @@ struct pm8xxx_regs {
>         unsigned int drv_addr;
>         unsigned int drv_mask;
>         unsigned int drv_shift;
> +       unsigned int drv_addr2;
> +       unsigned int drv_mask2;
> +       unsigned int drv_shift2;
>         unsigned int drv_en_manual_mask;
>  };
>
> @@ -44,6 +47,42 @@ static struct pm8xxx_regs pm8916_regs = {
>         .drv_en_manual_mask = 0,
>  };
>
> +static struct pm8xxx_regs pmi632_regs = {
> +       .enable_addr = 0x5746,
> +       .enable_mask = BIT(7),
> +       .drv_addr = 0x5740,
> +       .drv_mask = 0xff,
> +       .drv_shift = 0,
> +       .drv_addr2 = 0x5741,
> +       .drv_mask2 = 0x0f,
> +       .drv_shift2 = 8,

I see that you are just expanding what was done for SSBI PMICs and
later expanded to support pm8916. However it might be better to drop
the hardcoded .drv_addr (and drv_addr2) and read address from DT
instead.

> +       .drv_en_manual_mask = 0,
> +};
> +
> +static struct pm8xxx_regs pm7250b_regs = {
> +       .enable_addr = 0x5346,
> +       .enable_mask = BIT(7),
> +       .drv_addr = 0x5340,
> +       .drv_mask = 0xff,
> +       .drv_shift = 0,
> +       .drv_addr2 = 0x5341,
> +       .drv_mask2 = 0x0f,
> +       .drv_shift2 = 8,
> +       .drv_en_manual_mask = 0,
> +};
> +
> +static struct pm8xxx_regs pm7325b_regs = {
> +       .enable_addr = 0xdf46,
> +       .enable_mask = BIT(7),
> +       .drv_addr = 0xdf40,
> +       .drv_mask = 0xff,
> +       .drv_shift = 0,
> +       .drv_addr2 = 0xdf41,
> +       .drv_mask2 = 0x0f,
> +       .drv_shift2 = 8,
> +       .drv_en_manual_mask = 0,
> +};
> +
>  /**
>   * struct pm8xxx_vib - structure to hold vibrator data
>   * @vib_input_dev: input device supporting force feedback
> @@ -87,6 +126,12 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
>                 return rc;
>
>         vib->reg_vib_drv = val;
> +       if (regs->drv_addr2 != 0 && on) {
> +               val = (vib->level << regs->drv_shift2) & regs->drv_mask2;
> +               rc = regmap_write(vib->regmap, regs->drv_addr2, val);
> +               if (rc < 0)
> +                       return rc;
> +       }
>
>         if (regs->enable_mask)
>                 rc = regmap_update_bits(vib->regmap, regs->enable_addr,
> @@ -242,6 +287,9 @@ static const struct of_device_id pm8xxx_vib_id_table[] = {
>         { .compatible = "qcom,pm8058-vib", .data = &pm8058_regs },
>         { .compatible = "qcom,pm8921-vib", .data = &pm8058_regs },
>         { .compatible = "qcom,pm8916-vib", .data = &pm8916_regs },
> +       { .compatible = "qcom,pmi632-vib", .data = &pmi632_regs },
> +       { .compatible = "qcom,pm7250b-vib", .data = &pm7250b_regs },
> +       { .compatible = "qcom,pm7325b-vib", .data = &pm7325b_regs },
>         { }
>  };
>  MODULE_DEVICE_TABLE(of, pm8xxx_vib_id_table);
> --
> 2.25.1
>


-- 
With best wishes
Dmitry

Re: [PATCH v2 2/2] Input: pm8xxx-vib - Add support for more PMICs

[Fenglin Wu]

On 7/18/2023 2:44 PM, Dmitry Baryshkov wrote:
> On Tue, 18 Jul 2023 at 09:27, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
>>
>> Add support for vibrator module inside PMI632, PM7250B, PM7325B.
>> It is very similar to vibrator inside PM8xxx but just the drive
>> amplitude is controlled through 2 bytes registers.
>>
>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>> ---
>>   drivers/input/misc/pm8xxx-vibrator.c | 48 ++++++++++++++++++++++++++++
>>   1 file changed, 48 insertions(+)
>>
>> diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
>> index 04cb87efd799..213fdfd47c7f 100644
>> --- a/drivers/input/misc/pm8xxx-vibrator.c
>> +++ b/drivers/input/misc/pm8xxx-vibrator.c
>> @@ -25,6 +25,9 @@ struct pm8xxx_regs {
>>          unsigned int drv_addr;
>>          unsigned int drv_mask;
>>          unsigned int drv_shift;
>> +       unsigned int drv_addr2;
>> +       unsigned int drv_mask2;
>> +       unsigned int drv_shift2;
>>          unsigned int drv_en_manual_mask;
>>   };
>>
>> @@ -44,6 +47,42 @@ static struct pm8xxx_regs pm8916_regs = {
>>          .drv_en_manual_mask = 0,
>>   };
>>
>> +static struct pm8xxx_regs pmi632_regs = {
>> +       .enable_addr = 0x5746,
>> +       .enable_mask = BIT(7),
>> +       .drv_addr = 0x5740,
>> +       .drv_mask = 0xff,
>> +       .drv_shift = 0,
>> +       .drv_addr2 = 0x5741,
>> +       .drv_mask2 = 0x0f,
>> +       .drv_shift2 = 8,
> 
> I see that you are just expanding what was done for SSBI PMICs and
> later expanded to support pm8916. However it might be better to drop
> the hardcoded .drv_addr (and drv_addr2) and read address from DT
> instead.
> 

Right, this is the simplest change without updating the code logic too 
much. If we decided to read .drv_addr and .drv_add2 from DT, we will 
have to read .enable_addr along with all other mask/shift for each 
register address from DT as well because they are not consistent from 
target to target. I don't know how would you suggest to add the DT 
properties for all of them, but if we end up to add a property for each 
of them, it won't be cleaner than hard-coding them.


>> +       .drv_en_manual_mask = 0,
>> +};
>> +
>> +static struct pm8xxx_regs pm7250b_regs = {
>> +       .enable_addr = 0x5346,
>> +       .enable_mask = BIT(7),
>> +       .drv_addr = 0x5340,
>> +       .drv_mask = 0xff,
>> +       .drv_shift = 0,
>> +       .drv_addr2 = 0x5341,
>> +       .drv_mask2 = 0x0f,
>> +       .drv_shift2 = 8,
>> +       .drv_en_manual_mask = 0,
>> +};
>> +
>> +static struct pm8xxx_regs pm7325b_regs = {
>> +       .enable_addr = 0xdf46,
>> +       .enable_mask = BIT(7),
>> +       .drv_addr = 0xdf40,
>> +       .drv_mask = 0xff,
>> +       .drv_shift = 0,
>> +       .drv_addr2 = 0xdf41,
>> +       .drv_mask2 = 0x0f,
>> +       .drv_shift2 = 8,
>> +       .drv_en_manual_mask = 0,
>> +};
>> +
>>   /**
>>    * struct pm8xxx_vib - structure to hold vibrator data
>>    * @vib_input_dev: input device supporting force feedback
>> @@ -87,6 +126,12 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
>>                  return rc;
>>
>>          vib->reg_vib_drv = val;
>> +       if (regs->drv_addr2 != 0 && on) {
>> +               val = (vib->level << regs->drv_shift2) & regs->drv_mask2;
>> +               rc = regmap_write(vib->regmap, regs->drv_addr2, val);
>> +               if (rc < 0)
>> +                       return rc;
>> +       }
>>
>>          if (regs->enable_mask)
>>                  rc = regmap_update_bits(vib->regmap, regs->enable_addr,
>> @@ -242,6 +287,9 @@ static const struct of_device_id pm8xxx_vib_id_table[] = {
>>          { .compatible = "qcom,pm8058-vib", .data = &pm8058_regs },
>>          { .compatible = "qcom,pm8921-vib", .data = &pm8058_regs },
>>          { .compatible = "qcom,pm8916-vib", .data = &pm8916_regs },
>> +       { .compatible = "qcom,pmi632-vib", .data = &pmi632_regs },
>> +       { .compatible = "qcom,pm7250b-vib", .data = &pm7250b_regs },
>> +       { .compatible = "qcom,pm7325b-vib", .data = &pm7325b_regs },
>>          { }
>>   };
>>   MODULE_DEVICE_TABLE(of, pm8xxx_vib_id_table);
>> --
>> 2.25.1
>>
> 
> 

Re: [PATCH v2 2/2] Input: pm8xxx-vib - Add support for more PMICs

[Dmitry Baryshkov]

On Tue, 18 Jul 2023 at 09:58, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
>
>
>
> On 7/18/2023 2:44 PM, Dmitry Baryshkov wrote:
> > On Tue, 18 Jul 2023 at 09:27, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
> >>
> >> Add support for vibrator module inside PMI632, PM7250B, PM7325B.
> >> It is very similar to vibrator inside PM8xxx but just the drive
> >> amplitude is controlled through 2 bytes registers.
> >>
> >> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
> >> ---
> >>   drivers/input/misc/pm8xxx-vibrator.c | 48 ++++++++++++++++++++++++++++
> >>   1 file changed, 48 insertions(+)
> >>
> >> diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
> >> index 04cb87efd799..213fdfd47c7f 100644
> >> --- a/drivers/input/misc/pm8xxx-vibrator.c
> >> +++ b/drivers/input/misc/pm8xxx-vibrator.c
> >> @@ -25,6 +25,9 @@ struct pm8xxx_regs {
> >>          unsigned int drv_addr;
> >>          unsigned int drv_mask;
> >>          unsigned int drv_shift;
> >> +       unsigned int drv_addr2;
> >> +       unsigned int drv_mask2;
> >> +       unsigned int drv_shift2;
> >>          unsigned int drv_en_manual_mask;
> >>   };
> >>
> >> @@ -44,6 +47,42 @@ static struct pm8xxx_regs pm8916_regs = {
> >>          .drv_en_manual_mask = 0,
> >>   };
> >>
> >> +static struct pm8xxx_regs pmi632_regs = {
> >> +       .enable_addr = 0x5746,
> >> +       .enable_mask = BIT(7),
> >> +       .drv_addr = 0x5740,
> >> +       .drv_mask = 0xff,
> >> +       .drv_shift = 0,
> >> +       .drv_addr2 = 0x5741,
> >> +       .drv_mask2 = 0x0f,
> >> +       .drv_shift2 = 8,
> >
> > I see that you are just expanding what was done for SSBI PMICs and
> > later expanded to support pm8916. However it might be better to drop
> > the hardcoded .drv_addr (and drv_addr2) and read address from DT
> > instead.
> >
>
> Right, this is the simplest change without updating the code logic too
> much. If we decided to read .drv_addr and .drv_add2 from DT, we will
> have to read .enable_addr along with all other mask/shift for each
> register address from DT as well because they are not consistent from
> target to target. I don't know how would you suggest to add the DT
> properties for all of them, but if we end up to add a property for each
> of them, it won't be cleaner than hard-coding them.

No, we (correctly) have device compatibles for that. The issue with
hardcoding register addresses is that it adds extra issues here.

If I understand correctly, we have several 'generation':
- SSBI PMIC, shifted 5-bit mask, en_manual_mask, no enable_register.
- older SPMI PMIC, 5 bit drv_mask, 0 en_manual_mask, enable register at +6
- new SPMI PMIC, 12 bit drv_mask, 0 en_manual_mask, enable register at +6

For the last generation you are adding three independent entries,
while the block looks the same. If you remove drv_addr (and get it
from reg property), it would allow us to keep only the functional data
in struct pm8xxxx_regs (masks / shifts).

>
>
> >> +       .drv_en_manual_mask = 0,
> >> +};
> >> +
> >> +static struct pm8xxx_regs pm7250b_regs = {
> >> +       .enable_addr = 0x5346,
> >> +       .enable_mask = BIT(7),
> >> +       .drv_addr = 0x5340,
> >> +       .drv_mask = 0xff,
> >> +       .drv_shift = 0,
> >> +       .drv_addr2 = 0x5341,
> >> +       .drv_mask2 = 0x0f,
> >> +       .drv_shift2 = 8,
> >> +       .drv_en_manual_mask = 0,
> >> +};
> >> +
> >> +static struct pm8xxx_regs pm7325b_regs = {
> >> +       .enable_addr = 0xdf46,
> >> +       .enable_mask = BIT(7),
> >> +       .drv_addr = 0xdf40,
> >> +       .drv_mask = 0xff,
> >> +       .drv_shift = 0,
> >> +       .drv_addr2 = 0xdf41,
> >> +       .drv_mask2 = 0x0f,
> >> +       .drv_shift2 = 8,
> >> +       .drv_en_manual_mask = 0,
> >> +};
> >> +
> >>   /**
> >>    * struct pm8xxx_vib - structure to hold vibrator data
> >>    * @vib_input_dev: input device supporting force feedback
> >> @@ -87,6 +126,12 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
> >>                  return rc;
> >>
> >>          vib->reg_vib_drv = val;
> >> +       if (regs->drv_addr2 != 0 && on) {
> >> +               val = (vib->level << regs->drv_shift2) & regs->drv_mask2;
> >> +               rc = regmap_write(vib->regmap, regs->drv_addr2, val);
> >> +               if (rc < 0)
> >> +                       return rc;
> >> +       }
> >>
> >>          if (regs->enable_mask)
> >>                  rc = regmap_update_bits(vib->regmap, regs->enable_addr,
> >> @@ -242,6 +287,9 @@ static const struct of_device_id pm8xxx_vib_id_table[] = {
> >>          { .compatible = "qcom,pm8058-vib", .data = &pm8058_regs },
> >>          { .compatible = "qcom,pm8921-vib", .data = &pm8058_regs },
> >>          { .compatible = "qcom,pm8916-vib", .data = &pm8916_regs },
> >> +       { .compatible = "qcom,pmi632-vib", .data = &pmi632_regs },
> >> +       { .compatible = "qcom,pm7250b-vib", .data = &pm7250b_regs },
> >> +       { .compatible = "qcom,pm7325b-vib", .data = &pm7325b_regs },
> >>          { }
> >>   };
> >>   MODULE_DEVICE_TABLE(of, pm8xxx_vib_id_table);
> >> --
> >> 2.25.1
> >>
> >
> >



-- 
With best wishes
Dmitry

Re: [PATCH v2 2/2] Input: pm8xxx-vib - Add support for more PMICs

[Fenglin Wu]

On 7/18/2023 5:41 PM, Dmitry Baryshkov wrote:
> On Tue, 18 Jul 2023 at 09:58, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
>>
>>
>>
>> On 7/18/2023 2:44 PM, Dmitry Baryshkov wrote:
>>> On Tue, 18 Jul 2023 at 09:27, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
>>>>
>>>> Add support for vibrator module inside PMI632, PM7250B, PM7325B.
>>>> It is very similar to vibrator inside PM8xxx but just the drive
>>>> amplitude is controlled through 2 bytes registers.
>>>>
>>>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>>>> ---
>>>>    drivers/input/misc/pm8xxx-vibrator.c | 48 ++++++++++++++++++++++++++++
>>>>    1 file changed, 48 insertions(+)
>>>>
>>>> diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
>>>> index 04cb87efd799..213fdfd47c7f 100644
>>>> --- a/drivers/input/misc/pm8xxx-vibrator.c
>>>> +++ b/drivers/input/misc/pm8xxx-vibrator.c
>>>> @@ -25,6 +25,9 @@ struct pm8xxx_regs {
>>>>           unsigned int drv_addr;
>>>>           unsigned int drv_mask;
>>>>           unsigned int drv_shift;
>>>> +       unsigned int drv_addr2;
>>>> +       unsigned int drv_mask2;
>>>> +       unsigned int drv_shift2;
>>>>           unsigned int drv_en_manual_mask;
>>>>    };
>>>>
>>>> @@ -44,6 +47,42 @@ static struct pm8xxx_regs pm8916_regs = {
>>>>           .drv_en_manual_mask = 0,
>>>>    };
>>>>
>>>> +static struct pm8xxx_regs pmi632_regs = {
>>>> +       .enable_addr = 0x5746,
>>>> +       .enable_mask = BIT(7),
>>>> +       .drv_addr = 0x5740,
>>>> +       .drv_mask = 0xff,
>>>> +       .drv_shift = 0,
>>>> +       .drv_addr2 = 0x5741,
>>>> +       .drv_mask2 = 0x0f,
>>>> +       .drv_shift2 = 8,
>>>
>>> I see that you are just expanding what was done for SSBI PMICs and
>>> later expanded to support pm8916. However it might be better to drop
>>> the hardcoded .drv_addr (and drv_addr2) and read address from DT
>>> instead.
>>>
>>
>> Right, this is the simplest change without updating the code logic too
>> much. If we decided to read .drv_addr and .drv_add2 from DT, we will
>> have to read .enable_addr along with all other mask/shift for each
>> register address from DT as well because they are not consistent from
>> target to target. I don't know how would you suggest to add the DT
>> properties for all of them, but if we end up to add a property for each
>> of them, it won't be cleaner than hard-coding them.
> 
> No, we (correctly) have device compatibles for that. The issue with
> hardcoding register addresses is that it adds extra issues here.
> 
> If I understand correctly, we have several 'generation':
> - SSBI PMIC, shifted 5-bit mask, en_manual_mask, no enable_register.
> - older SPMI PMIC, 5 bit drv_mask, 0 en_manual_mask, enable register at +6
> - new SPMI PMIC, 12 bit drv_mask, 0 en_manual_mask, enable register at +6
> 
> For the last generation you are adding three independent entries,
> while the block looks the same. If you remove drv_addr (and get it
> from reg property), it would allow us to keep only the functional data
> in struct pm8xxxx_regs (masks / shifts).
> 

Okay, let me know if I understood it correctly, this is what you are 
suggesting:

   - hard code the mask/shifts and still keep them in struct pm8xxx_regs,
     combine the drv_mask2 to the upper byte of the drv_mask, so we will
     have following data structure for the 3rd generation vibrator

     static struct pm8xxx_regs pm7250b_regs = {
         .enable_addr = 0x5346,
         .enable_mask = BIT(7),
         .drv_mask = 0xfff,
         .drv_shift = 0,
         .drv_en_manual_mask = 0,
     };


   - move the drv_addr/drv_addr2 into DT, read them from 'reg' property.
     Because of 'mfd/qcom,spmi-pmic.yaml' has defined the 'address-cells'
     as 1 and the 'size-cells' as 0 for qcom spmi devices, we couldn't
     specify the address size to 2 even the drv_addr for the 3rd
     generation vibrator is 2 adjacent bytes. So we will end of having
     following DT scheme:

       For the 2nd generation which only has drv_addr
	vibrator@c041 {
              compatible = "qcom,pm8916-vib";
              reg = <0xc041>;  /* drv_addr */
              ...
	};

       For the 3rd generation which has both drv_addr and drv_addr2
         vibrator@5340 {
              compatible = "qcom,pm7250b-vib";
	     reg = <0x5340>,  /* drv_addr */
		   <0x5341>;  /* drv_addr2 */
	     ...
	};

Not sure how do you feel, I actually don't see too much benefit than 
hard-coding them in the driver.
We will end up having code to check how many u32 value in the 'reg' and 
only assign it to drv_addr2 when the 2nd is available, also when 
programming drv_addr2 register, the driver will always assume the mask 
is in the upper byte of the drv_mask and the shift to the drive level is 
8 (this seems hacky to me and it was my biggest concern while I made 
this change, and it led me to defining drv_shift2/drv_mask2 along with 
drv_addr2).



>>
>>
>>>> +       .drv_en_manual_mask = 0,
>>>> +};
>>>> +
>>>> +static struct pm8xxx_regs pm7250b_regs = {
>>>> +       .enable_addr = 0x5346,
>>>> +       .enable_mask = BIT(7),
>>>> +       .drv_addr = 0x5340,
>>>> +       .drv_mask = 0xff,
>>>> +       .drv_shift = 0,
>>>> +       .drv_addr2 = 0x5341,
>>>> +       .drv_mask2 = 0x0f,
>>>> +       .drv_shift2 = 8,
>>>> +       .drv_en_manual_mask = 0,
>>>> +};
>>>> +
>>>> +static struct pm8xxx_regs pm7325b_regs = {
>>>> +       .enable_addr = 0xdf46,
>>>> +       .enable_mask = BIT(7),
>>>> +       .drv_addr = 0xdf40,
>>>> +       .drv_mask = 0xff,
>>>> +       .drv_shift = 0,
>>>> +       .drv_addr2 = 0xdf41,
>>>> +       .drv_mask2 = 0x0f,
>>>> +       .drv_shift2 = 8,
>>>> +       .drv_en_manual_mask = 0,
>>>> +};
>>>> +
>>>>    /**
>>>>     * struct pm8xxx_vib - structure to hold vibrator data
>>>>     * @vib_input_dev: input device supporting force feedback
>>>> @@ -87,6 +126,12 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
>>>>                   return rc;
>>>>
>>>>           vib->reg_vib_drv = val;
>>>> +       if (regs->drv_addr2 != 0 && on) {
>>>> +               val = (vib->level << regs->drv_shift2) & regs->drv_mask2;
>>>> +               rc = regmap_write(vib->regmap, regs->drv_addr2, val);
>>>> +               if (rc < 0)
>>>> +                       return rc;
>>>> +       }
>>>>
>>>>           if (regs->enable_mask)
>>>>                   rc = regmap_update_bits(vib->regmap, regs->enable_addr,
>>>> @@ -242,6 +287,9 @@ static const struct of_device_id pm8xxx_vib_id_table[] = {
>>>>           { .compatible = "qcom,pm8058-vib", .data = &pm8058_regs },
>>>>           { .compatible = "qcom,pm8921-vib", .data = &pm8058_regs },
>>>>           { .compatible = "qcom,pm8916-vib", .data = &pm8916_regs },
>>>> +       { .compatible = "qcom,pmi632-vib", .data = &pmi632_regs },
>>>> +       { .compatible = "qcom,pm7250b-vib", .data = &pm7250b_regs },
>>>> +       { .compatible = "qcom,pm7325b-vib", .data = &pm7325b_regs },
>>>>           { }
>>>>    };
>>>>    MODULE_DEVICE_TABLE(of, pm8xxx_vib_id_table);
>>>> --
>>>> 2.25.1
>>>>
>>>
>>>
> 
> 
> 

Re: [PATCH v2 2/2] Input: pm8xxx-vib - Add support for more PMICs

[Dmitry Baryshkov]

On Tue, 18 Jul 2023 at 13:55, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
>
>
>
> On 7/18/2023 5:41 PM, Dmitry Baryshkov wrote:
> > On Tue, 18 Jul 2023 at 09:58, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
> >>
> >>
> >>
> >> On 7/18/2023 2:44 PM, Dmitry Baryshkov wrote:
> >>> On Tue, 18 Jul 2023 at 09:27, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
> >>>>
> >>>> Add support for vibrator module inside PMI632, PM7250B, PM7325B.
> >>>> It is very similar to vibrator inside PM8xxx but just the drive
> >>>> amplitude is controlled through 2 bytes registers.
> >>>>
> >>>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
> >>>> ---
> >>>>    drivers/input/misc/pm8xxx-vibrator.c | 48 ++++++++++++++++++++++++++++
> >>>>    1 file changed, 48 insertions(+)
> >>>>
> >>>> diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
> >>>> index 04cb87efd799..213fdfd47c7f 100644
> >>>> --- a/drivers/input/misc/pm8xxx-vibrator.c
> >>>> +++ b/drivers/input/misc/pm8xxx-vibrator.c
> >>>> @@ -25,6 +25,9 @@ struct pm8xxx_regs {
> >>>>           unsigned int drv_addr;
> >>>>           unsigned int drv_mask;
> >>>>           unsigned int drv_shift;
> >>>> +       unsigned int drv_addr2;
> >>>> +       unsigned int drv_mask2;
> >>>> +       unsigned int drv_shift2;
> >>>>           unsigned int drv_en_manual_mask;
> >>>>    };
> >>>>
> >>>> @@ -44,6 +47,42 @@ static struct pm8xxx_regs pm8916_regs = {
> >>>>           .drv_en_manual_mask = 0,
> >>>>    };
> >>>>
> >>>> +static struct pm8xxx_regs pmi632_regs = {
> >>>> +       .enable_addr = 0x5746,
> >>>> +       .enable_mask = BIT(7),
> >>>> +       .drv_addr = 0x5740,
> >>>> +       .drv_mask = 0xff,
> >>>> +       .drv_shift = 0,
> >>>> +       .drv_addr2 = 0x5741,
> >>>> +       .drv_mask2 = 0x0f,
> >>>> +       .drv_shift2 = 8,
> >>>
> >>> I see that you are just expanding what was done for SSBI PMICs and
> >>> later expanded to support pm8916. However it might be better to drop
> >>> the hardcoded .drv_addr (and drv_addr2) and read address from DT
> >>> instead.
> >>>
> >>
> >> Right, this is the simplest change without updating the code logic too
> >> much. If we decided to read .drv_addr and .drv_add2 from DT, we will
> >> have to read .enable_addr along with all other mask/shift for each
> >> register address from DT as well because they are not consistent from
> >> target to target. I don't know how would you suggest to add the DT
> >> properties for all of them, but if we end up to add a property for each
> >> of them, it won't be cleaner than hard-coding them.
> >
> > No, we (correctly) have device compatibles for that. The issue with
> > hardcoding register addresses is that it adds extra issues here.
> >
> > If I understand correctly, we have several 'generation':
> > - SSBI PMIC, shifted 5-bit mask, en_manual_mask, no enable_register.
> > - older SPMI PMIC, 5 bit drv_mask, 0 en_manual_mask, enable register at +6
> > - new SPMI PMIC, 12 bit drv_mask, 0 en_manual_mask, enable register at +6
> >
> > For the last generation you are adding three independent entries,
> > while the block looks the same. If you remove drv_addr (and get it
> > from reg property), it would allow us to keep only the functional data
> > in struct pm8xxxx_regs (masks / shifts).
> >
>
> Okay, let me know if I understood it correctly, this is what you are
> suggesting:
>
>    - hard code the mask/shifts and still keep them in struct pm8xxx_regs,
>      combine the drv_mask2 to the upper byte of the drv_mask, so we will
>      have following data structure for the 3rd generation vibrator
>
>      static struct pm8xxx_regs pm7250b_regs = {
>          .enable_addr = 0x5346,
>          .enable_mask = BIT(7),
>          .drv_mask = 0xfff,
>          .drv_shift = 0,
>          .drv_en_manual_mask = 0,
>      };
>
>
>    - move the drv_addr/drv_addr2 into DT, read them from 'reg' property.
>      Because of 'mfd/qcom,spmi-pmic.yaml' has defined the 'address-cells'
>      as 1 and the 'size-cells' as 0 for qcom spmi devices, we couldn't
>      specify the address size to 2 even the drv_addr for the 3rd
>      generation vibrator is 2 adjacent bytes. So we will end of having
>      following DT scheme:
>
>        For the 2nd generation which only has drv_addr
>         vibrator@c041 {
>               compatible = "qcom,pm8916-vib";
>               reg = <0xc041>;  /* drv_addr */

No. This is <0xc000>.

>               ...
>         };
>
>        For the 3rd generation which has both drv_addr and drv_addr2
>          vibrator@5340 {
>               compatible = "qcom,pm7250b-vib";
>              reg = <0x5340>,  /* drv_addr */
>                    <0x5341>;  /* drv_addr2 */
>              ...
>         };
>
> Not sure how do you feel, I actually don't see too much benefit than
> hard-coding them in the driver.
> We will end up having code to check how many u32 value in the 'reg' and
> only assign it to drv_addr2 when the 2nd is available, also when
> programming drv_addr2 register, the driver will always assume the mask
> is in the upper byte of the drv_mask and the shift to the drive level is
> 8 (this seems hacky to me and it was my biggest concern while I made
> this change, and it led me to defining drv_shift2/drv_mask2 along with
> drv_addr2).

We only need drv_addr2 if drv_mask has more than 8 bits. So you don't
have to specify it in the DT. It is always equal to base_reg + 0x41.
The same way drv_addr is always equal to base_reg + 0x40 for all
SPMI-based PMIC vibrator devices.

>
>
>
> >>
> >>
> >>>> +       .drv_en_manual_mask = 0,
> >>>> +};
> >>>> +
> >>>> +static struct pm8xxx_regs pm7250b_regs = {
> >>>> +       .enable_addr = 0x5346,
> >>>> +       .enable_mask = BIT(7),
> >>>> +       .drv_addr = 0x5340,
> >>>> +       .drv_mask = 0xff,
> >>>> +       .drv_shift = 0,
> >>>> +       .drv_addr2 = 0x5341,
> >>>> +       .drv_mask2 = 0x0f,
> >>>> +       .drv_shift2 = 8,
> >>>> +       .drv_en_manual_mask = 0,
> >>>> +};
> >>>> +
> >>>> +static struct pm8xxx_regs pm7325b_regs = {
> >>>> +       .enable_addr = 0xdf46,
> >>>> +       .enable_mask = BIT(7),
> >>>> +       .drv_addr = 0xdf40,
> >>>> +       .drv_mask = 0xff,
> >>>> +       .drv_shift = 0,
> >>>> +       .drv_addr2 = 0xdf41,
> >>>> +       .drv_mask2 = 0x0f,
> >>>> +       .drv_shift2 = 8,
> >>>> +       .drv_en_manual_mask = 0,
> >>>> +};
> >>>> +
> >>>>    /**
> >>>>     * struct pm8xxx_vib - structure to hold vibrator data
> >>>>     * @vib_input_dev: input device supporting force feedback
> >>>> @@ -87,6 +126,12 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
> >>>>                   return rc;
> >>>>
> >>>>           vib->reg_vib_drv = val;
> >>>> +       if (regs->drv_addr2 != 0 && on) {
> >>>> +               val = (vib->level << regs->drv_shift2) & regs->drv_mask2;
> >>>> +               rc = regmap_write(vib->regmap, regs->drv_addr2, val);
> >>>> +               if (rc < 0)
> >>>> +                       return rc;
> >>>> +       }
> >>>>
> >>>>           if (regs->enable_mask)
> >>>>                   rc = regmap_update_bits(vib->regmap, regs->enable_addr,
> >>>> @@ -242,6 +287,9 @@ static const struct of_device_id pm8xxx_vib_id_table[] = {
> >>>>           { .compatible = "qcom,pm8058-vib", .data = &pm8058_regs },
> >>>>           { .compatible = "qcom,pm8921-vib", .data = &pm8058_regs },
> >>>>           { .compatible = "qcom,pm8916-vib", .data = &pm8916_regs },
> >>>> +       { .compatible = "qcom,pmi632-vib", .data = &pmi632_regs },
> >>>> +       { .compatible = "qcom,pm7250b-vib", .data = &pm7250b_regs },
> >>>> +       { .compatible = "qcom,pm7325b-vib", .data = &pm7325b_regs },
> >>>>           { }
> >>>>    };
> >>>>    MODULE_DEVICE_TABLE(of, pm8xxx_vib_id_table);
> >>>> --
> >>>> 2.25.1
> >>>>
> >>>
> >>>
> >
> >
> >



-- 
With best wishes
Dmitry

Re: [PATCH v2 2/2] Input: pm8xxx-vib - Add support for more PMICs

[Fenglin Wu]

On 7/18/2023 7:04 PM, Dmitry Baryshkov wrote:
> On Tue, 18 Jul 2023 at 13:55, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
>>
>>
>>
>> On 7/18/2023 5:41 PM, Dmitry Baryshkov wrote:
>>> On Tue, 18 Jul 2023 at 09:58, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
>>>>
>>>>
>>>>
>>>> On 7/18/2023 2:44 PM, Dmitry Baryshkov wrote:
>>>>> On Tue, 18 Jul 2023 at 09:27, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
>>>>>>
>>>>>> Add support for vibrator module inside PMI632, PM7250B, PM7325B.
>>>>>> It is very similar to vibrator inside PM8xxx but just the drive
>>>>>> amplitude is controlled through 2 bytes registers.
>>>>>>
>>>>>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>>>>>> ---
>>>>>>     drivers/input/misc/pm8xxx-vibrator.c | 48 ++++++++++++++++++++++++++++
>>>>>>     1 file changed, 48 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
>>>>>> index 04cb87efd799..213fdfd47c7f 100644
>>>>>> --- a/drivers/input/misc/pm8xxx-vibrator.c
>>>>>> +++ b/drivers/input/misc/pm8xxx-vibrator.c
>>>>>> @@ -25,6 +25,9 @@ struct pm8xxx_regs {
>>>>>>            unsigned int drv_addr;
>>>>>>            unsigned int drv_mask;
>>>>>>            unsigned int drv_shift;
>>>>>> +       unsigned int drv_addr2;
>>>>>> +       unsigned int drv_mask2;
>>>>>> +       unsigned int drv_shift2;
>>>>>>            unsigned int drv_en_manual_mask;
>>>>>>     };
>>>>>>
>>>>>> @@ -44,6 +47,42 @@ static struct pm8xxx_regs pm8916_regs = {
>>>>>>            .drv_en_manual_mask = 0,
>>>>>>     };
>>>>>>
>>>>>> +static struct pm8xxx_regs pmi632_regs = {
>>>>>> +       .enable_addr = 0x5746,
>>>>>> +       .enable_mask = BIT(7),
>>>>>> +       .drv_addr = 0x5740,
>>>>>> +       .drv_mask = 0xff,
>>>>>> +       .drv_shift = 0,
>>>>>> +       .drv_addr2 = 0x5741,
>>>>>> +       .drv_mask2 = 0x0f,
>>>>>> +       .drv_shift2 = 8,
>>>>>
>>>>> I see that you are just expanding what was done for SSBI PMICs and
>>>>> later expanded to support pm8916. However it might be better to drop
>>>>> the hardcoded .drv_addr (and drv_addr2) and read address from DT
>>>>> instead.
>>>>>
>>>>
>>>> Right, this is the simplest change without updating the code logic too
>>>> much. If we decided to read .drv_addr and .drv_add2 from DT, we will
>>>> have to read .enable_addr along with all other mask/shift for each
>>>> register address from DT as well because they are not consistent from
>>>> target to target. I don't know how would you suggest to add the DT
>>>> properties for all of them, but if we end up to add a property for each
>>>> of them, it won't be cleaner than hard-coding them.
>>>
>>> No, we (correctly) have device compatibles for that. The issue with
>>> hardcoding register addresses is that it adds extra issues here.
>>>
>>> If I understand correctly, we have several 'generation':
>>> - SSBI PMIC, shifted 5-bit mask, en_manual_mask, no enable_register.
>>> - older SPMI PMIC, 5 bit drv_mask, 0 en_manual_mask, enable register at +6
>>> - new SPMI PMIC, 12 bit drv_mask, 0 en_manual_mask, enable register at +6
>>>
>>> For the last generation you are adding three independent entries,
>>> while the block looks the same. If you remove drv_addr (and get it
>>> from reg property), it would allow us to keep only the functional data
>>> in struct pm8xxxx_regs (masks / shifts).
>>>
>>
>> Okay, let me know if I understood it correctly, this is what you are
>> suggesting:
>>
>>     - hard code the mask/shifts and still keep them in struct pm8xxx_regs,
>>       combine the drv_mask2 to the upper byte of the drv_mask, so we will
>>       have following data structure for the 3rd generation vibrator
>>
>>       static struct pm8xxx_regs pm7250b_regs = {
>>           .enable_addr = 0x5346,
>>           .enable_mask = BIT(7),
>>           .drv_mask = 0xfff,
>>           .drv_shift = 0,
>>           .drv_en_manual_mask = 0,
>>       };
>>
>>
>>     - move the drv_addr/drv_addr2 into DT, read them from 'reg' property.
>>       Because of 'mfd/qcom,spmi-pmic.yaml' has defined the 'address-cells'
>>       as 1 and the 'size-cells' as 0 for qcom spmi devices, we couldn't
>>       specify the address size to 2 even the drv_addr for the 3rd
>>       generation vibrator is 2 adjacent bytes. So we will end of having
>>       following DT scheme:
>>
>>         For the 2nd generation which only has drv_addr
>>          vibrator@c041 {
>>                compatible = "qcom,pm8916-vib";
>>                reg = <0xc041>;  /* drv_addr */
> 
> No. This is <0xc000>.
> 
>>                ...
>>          };
>>
>>         For the 3rd generation which has both drv_addr and drv_addr2
>>           vibrator@5340 {
>>                compatible = "qcom,pm7250b-vib";
>>               reg = <0x5340>,  /* drv_addr */
>>                     <0x5341>;  /* drv_addr2 */
>>               ...
>>          };
>>
>> Not sure how do you feel, I actually don't see too much benefit than
>> hard-coding them in the driver.
>> We will end up having code to check how many u32 value in the 'reg' and
>> only assign it to drv_addr2 when the 2nd is available, also when
>> programming drv_addr2 register, the driver will always assume the mask
>> is in the upper byte of the drv_mask and the shift to the drive level is
>> 8 (this seems hacky to me and it was my biggest concern while I made
>> this change, and it led me to defining drv_shift2/drv_mask2 along with
>> drv_addr2).
> 
> We only need drv_addr2 if drv_mask has more than 8 bits. So you don't
> have to specify it in the DT. It is always equal to base_reg + 0x41.
> The same way drv_addr is always equal to base_reg + 0x40 for all
> SPMI-based PMIC vibrator devices.
> 

Thanks. I got it now, I agree this will be beneficial for the case that 
different PMICs have the same vibrator module but with different 
register base address. I am going to change it to this way, let me know 
if this is what you thought:

@@ -25,6 +29,9 @@ struct pm8xxx_regs {
         unsigned int drv_addr;
         unsigned int drv_mask;
         unsigned int drv_shift;
+       unsigned int drv_addr2;
+       unsigned int drv_mask2;
+       unsigned int drv_shift2;
         unsigned int drv_en_manual_mask;
  };

+static struct pm8xxx_regs spmi_vib_regs = {
+       .enable_mask = BIT(7),
+       .drv_mask = 0xff,
+       .drv_shift = 0,
+       .drv_mask2 = 0xf,
+       .drv_shift2 = 8,
+       .drv_en_manual_mask = 0,
+};
+

+#define SPMI_VIB_VSET_LB_REG   0x40
+#define SPMI_VIB_VSET_UP_REG   0x41
+#define SPMI_VIB_EN_CTL_REG    0x46
+

         regs = of_device_get_match_data(&pdev->dev);

+       if (regs->drv_addr == 0) {
+               rc = fwnode_property_read_u32(pdev->dev.fwnode,
+                               "reg", &reg_base);
+               if (rc < 0)
+                       return rc;
+
+               regs->enable_addr = reg_base + SPMI_VIB_EN_CTL_REG;
+               regs->drv_addr = reg_base + SPMI_VIB_VSET_LB_REG;
+               regs->drv_addr2 = reg_base + SPMI_VIB_VSET_UP_REG;
+       }
+


@@ -242,6 +277,7 @@ static const struct of_device_id 
pm8xxx_vib_id_table[] = {
         { .compatible = "qcom,pm8058-vib", .data = &pm8058_regs },
         { .compatible = "qcom,pm8921-vib", .data = &pm8058_regs },
         { .compatible = "qcom,pm8916-vib", .data = &pm8916_regs },
+       ( .compabitle = "qcom,spmi-vib", .data = &spmi_vib_regs },
         { }


>>
>>
>>
>>>>
>>>>
>>>>>> +       .drv_en_manual_mask = 0,
>>>>>> +};
>>>>>> +
>>>>>> +static struct pm8xxx_regs pm7250b_regs = {
>>>>>> +       .enable_addr = 0x5346,
>>>>>> +       .enable_mask = BIT(7),
>>>>>> +       .drv_addr = 0x5340,
>>>>>> +       .drv_mask = 0xff,
>>>>>> +       .drv_shift = 0,
>>>>>> +       .drv_addr2 = 0x5341,
>>>>>> +       .drv_mask2 = 0x0f,
>>>>>> +       .drv_shift2 = 8,
>>>>>> +       .drv_en_manual_mask = 0,
>>>>>> +};
>>>>>> +
>>>>>> +static struct pm8xxx_regs pm7325b_regs = {
>>>>>> +       .enable_addr = 0xdf46,
>>>>>> +       .enable_mask = BIT(7),
>>>>>> +       .drv_addr = 0xdf40,
>>>>>> +       .drv_mask = 0xff,
>>>>>> +       .drv_shift = 0,
>>>>>> +       .drv_addr2 = 0xdf41,
>>>>>> +       .drv_mask2 = 0x0f,
>>>>>> +       .drv_shift2 = 8,
>>>>>> +       .drv_en_manual_mask = 0,
>>>>>> +};
>>>>>> +
>>>>>>     /**
>>>>>>      * struct pm8xxx_vib - structure to hold vibrator data
>>>>>>      * @vib_input_dev: input device supporting force feedback
>>>>>> @@ -87,6 +126,12 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
>>>>>>                    return rc;
>>>>>>
>>>>>>            vib->reg_vib_drv = val;
>>>>>> +       if (regs->drv_addr2 != 0 && on) {
>>>>>> +               val = (vib->level << regs->drv_shift2) & regs->drv_mask2;
>>>>>> +               rc = regmap_write(vib->regmap, regs->drv_addr2, val);
>>>>>> +               if (rc < 0)
>>>>>> +                       return rc;
>>>>>> +       }
>>>>>>
>>>>>>            if (regs->enable_mask)
>>>>>>                    rc = regmap_update_bits(vib->regmap, regs->enable_addr,
>>>>>> @@ -242,6 +287,9 @@ static const struct of_device_id pm8xxx_vib_id_table[] = {
>>>>>>            { .compatible = "qcom,pm8058-vib", .data = &pm8058_regs },
>>>>>>            { .compatible = "qcom,pm8921-vib", .data = &pm8058_regs },
>>>>>>            { .compatible = "qcom,pm8916-vib", .data = &pm8916_regs },
>>>>>> +       { .compatible = "qcom,pmi632-vib", .data = &pmi632_regs },
>>>>>> +       { .compatible = "qcom,pm7250b-vib", .data = &pm7250b_regs },
>>>>>> +       { .compatible = "qcom,pm7325b-vib", .data = &pm7325b_regs },
>>>>>>            { }
>>>>>>     };
>>>>>>     MODULE_DEVICE_TABLE(of, pm8xxx_vib_id_table);
>>>>>> --
>>>>>> 2.25.1
>>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
> 
> 
> 

Re: [PATCH v2 2/2] Input: pm8xxx-vib - Add support for more PMICs

[Dmitry Baryshkov]

On Wed, 19 Jul 2023 at 07:09, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
>
>
>
> On 7/18/2023 7:04 PM, Dmitry Baryshkov wrote:
> > On Tue, 18 Jul 2023 at 13:55, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
> >>
> >>
> >>
> >> On 7/18/2023 5:41 PM, Dmitry Baryshkov wrote:
> >>> On Tue, 18 Jul 2023 at 09:58, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 7/18/2023 2:44 PM, Dmitry Baryshkov wrote:
> >>>>> On Tue, 18 Jul 2023 at 09:27, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
> >>>>>>
> >>>>>> Add support for vibrator module inside PMI632, PM7250B, PM7325B.
> >>>>>> It is very similar to vibrator inside PM8xxx but just the drive
> >>>>>> amplitude is controlled through 2 bytes registers.
> >>>>>>
> >>>>>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
> >>>>>> ---
> >>>>>>     drivers/input/misc/pm8xxx-vibrator.c | 48 ++++++++++++++++++++++++++++
> >>>>>>     1 file changed, 48 insertions(+)
> >>>>>>
> >>>>>> diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
> >>>>>> index 04cb87efd799..213fdfd47c7f 100644
> >>>>>> --- a/drivers/input/misc/pm8xxx-vibrator.c
> >>>>>> +++ b/drivers/input/misc/pm8xxx-vibrator.c
> >>>>>> @@ -25,6 +25,9 @@ struct pm8xxx_regs {
> >>>>>>            unsigned int drv_addr;
> >>>>>>            unsigned int drv_mask;
> >>>>>>            unsigned int drv_shift;
> >>>>>> +       unsigned int drv_addr2;

Unused

> >>>>>> +       unsigned int drv_mask2;
> >>>>>> +       unsigned int drv_shift2;
> >>>>>>            unsigned int drv_en_manual_mask;
> >>>>>>     };
> >>>>>>
> >>>>>> @@ -44,6 +47,42 @@ static struct pm8xxx_regs pm8916_regs = {
> >>>>>>            .drv_en_manual_mask = 0,
> >>>>>>     };
> >>>>>>
> >>>>>> +static struct pm8xxx_regs pmi632_regs = {
> >>>>>> +       .enable_addr = 0x5746,
> >>>>>> +       .enable_mask = BIT(7),
> >>>>>> +       .drv_addr = 0x5740,
> >>>>>> +       .drv_mask = 0xff,
> >>>>>> +       .drv_shift = 0,
> >>>>>> +       .drv_addr2 = 0x5741,
> >>>>>> +       .drv_mask2 = 0x0f,
> >>>>>> +       .drv_shift2 = 8,
> >>>>>
> >>>>> I see that you are just expanding what was done for SSBI PMICs and
> >>>>> later expanded to support pm8916. However it might be better to drop
> >>>>> the hardcoded .drv_addr (and drv_addr2) and read address from DT
> >>>>> instead.
> >>>>>
> >>>>
> >>>> Right, this is the simplest change without updating the code logic too
> >>>> much. If we decided to read .drv_addr and .drv_add2 from DT, we will
> >>>> have to read .enable_addr along with all other mask/shift for each
> >>>> register address from DT as well because they are not consistent from
> >>>> target to target. I don't know how would you suggest to add the DT
> >>>> properties for all of them, but if we end up to add a property for each
> >>>> of them, it won't be cleaner than hard-coding them.
> >>>
> >>> No, we (correctly) have device compatibles for that. The issue with
> >>> hardcoding register addresses is that it adds extra issues here.
> >>>
> >>> If I understand correctly, we have several 'generation':
> >>> - SSBI PMIC, shifted 5-bit mask, en_manual_mask, no enable_register.
> >>> - older SPMI PMIC, 5 bit drv_mask, 0 en_manual_mask, enable register at +6
> >>> - new SPMI PMIC, 12 bit drv_mask, 0 en_manual_mask, enable register at +6
> >>>
> >>> For the last generation you are adding three independent entries,
> >>> while the block looks the same. If you remove drv_addr (and get it
> >>> from reg property), it would allow us to keep only the functional data
> >>> in struct pm8xxxx_regs (masks / shifts).
> >>>
> >>
> >> Okay, let me know if I understood it correctly, this is what you are
> >> suggesting:
> >>
> >>     - hard code the mask/shifts and still keep them in struct pm8xxx_regs,
> >>       combine the drv_mask2 to the upper byte of the drv_mask, so we will
> >>       have following data structure for the 3rd generation vibrator
> >>
> >>       static struct pm8xxx_regs pm7250b_regs = {
> >>           .enable_addr = 0x5346,
> >>           .enable_mask = BIT(7),
> >>           .drv_mask = 0xfff,
> >>           .drv_shift = 0,
> >>           .drv_en_manual_mask = 0,
> >>       };
> >>
> >>
> >>     - move the drv_addr/drv_addr2 into DT, read them from 'reg' property.
> >>       Because of 'mfd/qcom,spmi-pmic.yaml' has defined the 'address-cells'
> >>       as 1 and the 'size-cells' as 0 for qcom spmi devices, we couldn't
> >>       specify the address size to 2 even the drv_addr for the 3rd
> >>       generation vibrator is 2 adjacent bytes. So we will end of having
> >>       following DT scheme:
> >>
> >>         For the 2nd generation which only has drv_addr
> >>          vibrator@c041 {
> >>                compatible = "qcom,pm8916-vib";
> >>                reg = <0xc041>;  /* drv_addr */
> >
> > No. This is <0xc000>.
> >
> >>                ...
> >>          };
> >>
> >>         For the 3rd generation which has both drv_addr and drv_addr2
> >>           vibrator@5340 {
> >>                compatible = "qcom,pm7250b-vib";
> >>               reg = <0x5340>,  /* drv_addr */
> >>                     <0x5341>;  /* drv_addr2 */
> >>               ...
> >>          };
> >>
> >> Not sure how do you feel, I actually don't see too much benefit than
> >> hard-coding them in the driver.
> >> We will end up having code to check how many u32 value in the 'reg' and
> >> only assign it to drv_addr2 when the 2nd is available, also when
> >> programming drv_addr2 register, the driver will always assume the mask
> >> is in the upper byte of the drv_mask and the shift to the drive level is
> >> 8 (this seems hacky to me and it was my biggest concern while I made
> >> this change, and it led me to defining drv_shift2/drv_mask2 along with
> >> drv_addr2).
> >
> > We only need drv_addr2 if drv_mask has more than 8 bits. So you don't
> > have to specify it in the DT. It is always equal to base_reg + 0x41.
> > The same way drv_addr is always equal to base_reg + 0x40 for all
> > SPMI-based PMIC vibrator devices.
> >
>
> Thanks. I got it now, I agree this will be beneficial for the case that
> different PMICs have the same vibrator module but with different
> register base address. I am going to change it to this way, let me know
> if this is what you thought:
>
> @@ -25,6 +29,9 @@ struct pm8xxx_regs {
>          unsigned int drv_addr;
>          unsigned int drv_mask;
>          unsigned int drv_shift;
> +       unsigned int drv_addr2;
> +       unsigned int drv_mask2;
> +       unsigned int drv_shift2;
>          unsigned int drv_en_manual_mask;
>   };
>
> +static struct pm8xxx_regs spmi_vib_regs = {
> +       .enable_mask = BIT(7),
> +       .drv_mask = 0xff,
> +       .drv_shift = 0,
> +       .drv_mask2 = 0xf,
> +       .drv_shift2 = 8,
> +       .drv_en_manual_mask = 0,
> +};

Ideally the static data should be const. I'd suggest moving
drv_addr/drv_addr2 to struct pm8xxx_vib.

> +
>
> +#define SPMI_VIB_VSET_LB_REG   0x40
> +#define SPMI_VIB_VSET_UP_REG   0x41
> +#define SPMI_VIB_EN_CTL_REG    0x46
> +
>
>          regs = of_device_get_match_data(&pdev->dev);
>
> +       if (regs->drv_addr == 0) {
> +               rc = fwnode_property_read_u32(pdev->dev.fwnode,
> +                               "reg", &reg_base);
> +               if (rc < 0)
> +                       return rc;
> +
> +               regs->enable_addr = reg_base + SPMI_VIB_EN_CTL_REG;
> +               regs->drv_addr = reg_base + SPMI_VIB_VSET_LB_REG;
> +               regs->drv_addr2 = reg_base + SPMI_VIB_VSET_UP_REG;

Yes, this looks good (except s/regs->/vib->/). Moreover this also
applies to pm8916. I'd suggest splitting this into two patches: first,
refactor pm8916 support to use reg, then add support for new devices.

> +       }
> +
>
>
> @@ -242,6 +277,7 @@ static const struct of_device_id
> pm8xxx_vib_id_table[] = {
>          { .compatible = "qcom,pm8058-vib", .data = &pm8058_regs },
>          { .compatible = "qcom,pm8921-vib", .data = &pm8058_regs },
>          { .compatible = "qcom,pm8916-vib", .data = &pm8916_regs },
> +       ( .compabitle = "qcom,spmi-vib", .data = &spmi_vib_regs },
>          { }
>
>
> >>
> >>
> >>
> >>>>
> >>>>
> >>>>>> +       .drv_en_manual_mask = 0,
> >>>>>> +};
> >>>>>> +
> >>>>>> +static struct pm8xxx_regs pm7250b_regs = {
> >>>>>> +       .enable_addr = 0x5346,
> >>>>>> +       .enable_mask = BIT(7),
> >>>>>> +       .drv_addr = 0x5340,
> >>>>>> +       .drv_mask = 0xff,
> >>>>>> +       .drv_shift = 0,
> >>>>>> +       .drv_addr2 = 0x5341,
> >>>>>> +       .drv_mask2 = 0x0f,
> >>>>>> +       .drv_shift2 = 8,
> >>>>>> +       .drv_en_manual_mask = 0,
> >>>>>> +};
> >>>>>> +
> >>>>>> +static struct pm8xxx_regs pm7325b_regs = {
> >>>>>> +       .enable_addr = 0xdf46,
> >>>>>> +       .enable_mask = BIT(7),
> >>>>>> +       .drv_addr = 0xdf40,
> >>>>>> +       .drv_mask = 0xff,
> >>>>>> +       .drv_shift = 0,
> >>>>>> +       .drv_addr2 = 0xdf41,
> >>>>>> +       .drv_mask2 = 0x0f,
> >>>>>> +       .drv_shift2 = 8,
> >>>>>> +       .drv_en_manual_mask = 0,
> >>>>>> +};
> >>>>>> +
> >>>>>>     /**
> >>>>>>      * struct pm8xxx_vib - structure to hold vibrator data
> >>>>>>      * @vib_input_dev: input device supporting force feedback
> >>>>>> @@ -87,6 +126,12 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
> >>>>>>                    return rc;
> >>>>>>
> >>>>>>            vib->reg_vib_drv = val;
> >>>>>> +       if (regs->drv_addr2 != 0 && on) {
> >>>>>> +               val = (vib->level << regs->drv_shift2) & regs->drv_mask2;
> >>>>>> +               rc = regmap_write(vib->regmap, regs->drv_addr2, val);
> >>>>>> +               if (rc < 0)
> >>>>>> +                       return rc;
> >>>>>> +       }
> >>>>>>
> >>>>>>            if (regs->enable_mask)
> >>>>>>                    rc = regmap_update_bits(vib->regmap, regs->enable_addr,
> >>>>>> @@ -242,6 +287,9 @@ static const struct of_device_id pm8xxx_vib_id_table[] = {
> >>>>>>            { .compatible = "qcom,pm8058-vib", .data = &pm8058_regs },
> >>>>>>            { .compatible = "qcom,pm8921-vib", .data = &pm8058_regs },
> >>>>>>            { .compatible = "qcom,pm8916-vib", .data = &pm8916_regs },
> >>>>>> +       { .compatible = "qcom,pmi632-vib", .data = &pmi632_regs },
> >>>>>> +       { .compatible = "qcom,pm7250b-vib", .data = &pm7250b_regs },
> >>>>>> +       { .compatible = "qcom,pm7325b-vib", .data = &pm7325b_regs },
> >>>>>>            { }
> >>>>>>     };
> >>>>>>     MODULE_DEVICE_TABLE(of, pm8xxx_vib_id_table);
> >>>>>> --
> >>>>>> 2.25.1
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >
> >
> >



-- 
With best wishes
Dmitry

Re: [PATCH v2 2/2] Input: pm8xxx-vib - Add support for more PMICs

[Fenglin Wu]

On 7/19/2023 4:02 PM, Dmitry Baryshkov wrote:
> On Wed, 19 Jul 2023 at 07:09, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
>>
>>
>>
>> On 7/18/2023 7:04 PM, Dmitry Baryshkov wrote:
>>> On Tue, 18 Jul 2023 at 13:55, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
>>>>
>>>>
>>>>
>>>> On 7/18/2023 5:41 PM, Dmitry Baryshkov wrote:
>>>>> On Tue, 18 Jul 2023 at 09:58, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/18/2023 2:44 PM, Dmitry Baryshkov wrote:
>>>>>>> On Tue, 18 Jul 2023 at 09:27, Fenglin Wu <quic_fenglinw@quicinc.com> wrote:
>>>>>>>>
>>>>>>>> Add support for vibrator module inside PMI632, PM7250B, PM7325B.
>>>>>>>> It is very similar to vibrator inside PM8xxx but just the drive
>>>>>>>> amplitude is controlled through 2 bytes registers.
>>>>>>>>
>>>>>>>> Signed-off-by: Fenglin Wu <quic_fenglinw@quicinc.com>
>>>>>>>> ---
>>>>>>>>      drivers/input/misc/pm8xxx-vibrator.c | 48 ++++++++++++++++++++++++++++
>>>>>>>>      1 file changed, 48 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/input/misc/pm8xxx-vibrator.c b/drivers/input/misc/pm8xxx-vibrator.c
>>>>>>>> index 04cb87efd799..213fdfd47c7f 100644
>>>>>>>> --- a/drivers/input/misc/pm8xxx-vibrator.c
>>>>>>>> +++ b/drivers/input/misc/pm8xxx-vibrator.c
>>>>>>>> @@ -25,6 +25,9 @@ struct pm8xxx_regs {
>>>>>>>>             unsigned int drv_addr;
>>>>>>>>             unsigned int drv_mask;
>>>>>>>>             unsigned int drv_shift;
>>>>>>>> +       unsigned int drv_addr2;
> 
> Unused
> 
>>>>>>>> +       unsigned int drv_mask2;
>>>>>>>> +       unsigned int drv_shift2;
>>>>>>>>             unsigned int drv_en_manual_mask;
>>>>>>>>      };
>>>>>>>>
>>>>>>>> @@ -44,6 +47,42 @@ static struct pm8xxx_regs pm8916_regs = {
>>>>>>>>             .drv_en_manual_mask = 0,
>>>>>>>>      };
>>>>>>>>
>>>>>>>> +static struct pm8xxx_regs pmi632_regs = {
>>>>>>>> +       .enable_addr = 0x5746,
>>>>>>>> +       .enable_mask = BIT(7),
>>>>>>>> +       .drv_addr = 0x5740,
>>>>>>>> +       .drv_mask = 0xff,
>>>>>>>> +       .drv_shift = 0,
>>>>>>>> +       .drv_addr2 = 0x5741,
>>>>>>>> +       .drv_mask2 = 0x0f,
>>>>>>>> +       .drv_shift2 = 8,
>>>>>>>
>>>>>>> I see that you are just expanding what was done for SSBI PMICs and
>>>>>>> later expanded to support pm8916. However it might be better to drop
>>>>>>> the hardcoded .drv_addr (and drv_addr2) and read address from DT
>>>>>>> instead.
>>>>>>>
>>>>>>
>>>>>> Right, this is the simplest change without updating the code logic too
>>>>>> much. If we decided to read .drv_addr and .drv_add2 from DT, we will
>>>>>> have to read .enable_addr along with all other mask/shift for each
>>>>>> register address from DT as well because they are not consistent from
>>>>>> target to target. I don't know how would you suggest to add the DT
>>>>>> properties for all of them, but if we end up to add a property for each
>>>>>> of them, it won't be cleaner than hard-coding them.
>>>>>
>>>>> No, we (correctly) have device compatibles for that. The issue with
>>>>> hardcoding register addresses is that it adds extra issues here.
>>>>>
>>>>> If I understand correctly, we have several 'generation':
>>>>> - SSBI PMIC, shifted 5-bit mask, en_manual_mask, no enable_register.
>>>>> - older SPMI PMIC, 5 bit drv_mask, 0 en_manual_mask, enable register at +6
>>>>> - new SPMI PMIC, 12 bit drv_mask, 0 en_manual_mask, enable register at +6
>>>>>
>>>>> For the last generation you are adding three independent entries,
>>>>> while the block looks the same. If you remove drv_addr (and get it
>>>>> from reg property), it would allow us to keep only the functional data
>>>>> in struct pm8xxxx_regs (masks / shifts).
>>>>>
>>>>
>>>> Okay, let me know if I understood it correctly, this is what you are
>>>> suggesting:
>>>>
>>>>      - hard code the mask/shifts and still keep them in struct pm8xxx_regs,
>>>>        combine the drv_mask2 to the upper byte of the drv_mask, so we will
>>>>        have following data structure for the 3rd generation vibrator
>>>>
>>>>        static struct pm8xxx_regs pm7250b_regs = {
>>>>            .enable_addr = 0x5346,
>>>>            .enable_mask = BIT(7),
>>>>            .drv_mask = 0xfff,
>>>>            .drv_shift = 0,
>>>>            .drv_en_manual_mask = 0,
>>>>        };
>>>>
>>>>
>>>>      - move the drv_addr/drv_addr2 into DT, read them from 'reg' property.
>>>>        Because of 'mfd/qcom,spmi-pmic.yaml' has defined the 'address-cells'
>>>>        as 1 and the 'size-cells' as 0 for qcom spmi devices, we couldn't
>>>>        specify the address size to 2 even the drv_addr for the 3rd
>>>>        generation vibrator is 2 adjacent bytes. So we will end of having
>>>>        following DT scheme:
>>>>
>>>>          For the 2nd generation which only has drv_addr
>>>>           vibrator@c041 {
>>>>                 compatible = "qcom,pm8916-vib";
>>>>                 reg = <0xc041>;  /* drv_addr */
>>>
>>> No. This is <0xc000>.
>>>
>>>>                 ...
>>>>           };
>>>>
>>>>          For the 3rd generation which has both drv_addr and drv_addr2
>>>>            vibrator@5340 {
>>>>                 compatible = "qcom,pm7250b-vib";
>>>>                reg = <0x5340>,  /* drv_addr */
>>>>                      <0x5341>;  /* drv_addr2 */
>>>>                ...
>>>>           };
>>>>
>>>> Not sure how do you feel, I actually don't see too much benefit than
>>>> hard-coding them in the driver.
>>>> We will end up having code to check how many u32 value in the 'reg' and
>>>> only assign it to drv_addr2 when the 2nd is available, also when
>>>> programming drv_addr2 register, the driver will always assume the mask
>>>> is in the upper byte of the drv_mask and the shift to the drive level is
>>>> 8 (this seems hacky to me and it was my biggest concern while I made
>>>> this change, and it led me to defining drv_shift2/drv_mask2 along with
>>>> drv_addr2).
>>>
>>> We only need drv_addr2 if drv_mask has more than 8 bits. So you don't
>>> have to specify it in the DT. It is always equal to base_reg + 0x41.
>>> The same way drv_addr is always equal to base_reg + 0x40 for all
>>> SPMI-based PMIC vibrator devices.
>>>
>>
>> Thanks. I got it now, I agree this will be beneficial for the case that
>> different PMICs have the same vibrator module but with different
>> register base address. I am going to change it to this way, let me know
>> if this is what you thought:
>>
>> @@ -25,6 +29,9 @@ struct pm8xxx_regs {
>>           unsigned int drv_addr;
>>           unsigned int drv_mask;
>>           unsigned int drv_shift;
>> +       unsigned int drv_addr2;
>> +       unsigned int drv_mask2;
>> +       unsigned int drv_shift2;
>>           unsigned int drv_en_manual_mask;
>>    };
>>
>> +static struct pm8xxx_regs spmi_vib_regs = {
>> +       .enable_mask = BIT(7),
>> +       .drv_mask = 0xff,
>> +       .drv_shift = 0,
>> +       .drv_mask2 = 0xf,
>> +       .drv_shift2 = 8,
>> +       .drv_en_manual_mask = 0,
>> +};
> 
> Ideally the static data should be const. I'd suggest moving
> drv_addr/drv_addr2 to struct pm8xxx_vib.
> 
>> +
>>
>> +#define SPMI_VIB_VSET_LB_REG   0x40
>> +#define SPMI_VIB_VSET_UP_REG   0x41
>> +#define SPMI_VIB_EN_CTL_REG    0x46
>> +
>>
>>           regs = of_device_get_match_data(&pdev->dev);
>>
>> +       if (regs->drv_addr == 0) {
>> +               rc = fwnode_property_read_u32(pdev->dev.fwnode,
>> +                               "reg", &reg_base);
>> +               if (rc < 0)
>> +                       return rc;
>> +
>> +               regs->enable_addr = reg_base + SPMI_VIB_EN_CTL_REG;
>> +               regs->drv_addr = reg_base + SPMI_VIB_VSET_LB_REG;
>> +               regs->drv_addr2 = reg_base + SPMI_VIB_VSET_UP_REG;
> 
> Yes, this looks good (except s/regs->/vib->/). Moreover this also
> applies to pm8916. I'd suggest splitting this into two patches: first,
> refactor pm8916 support to use reg, then add support for new devices.

Thanks. I will refactor this, test it, and send it out. The only problem 
  is I don't have a pm8916 device with me, but I guess the change should 
be straightforward and I will rely on the test result on my PM7550BA 
device which has the vibrator with the latest generation.

> 
>> +       }
>> +
>>
>>
>> @@ -242,6 +277,7 @@ static const struct of_device_id
>> pm8xxx_vib_id_table[] = {
>>           { .compatible = "qcom,pm8058-vib", .data = &pm8058_regs },
>>           { .compatible = "qcom,pm8921-vib", .data = &pm8058_regs },
>>           { .compatible = "qcom,pm8916-vib", .data = &pm8916_regs },
>> +       ( .compabitle = "qcom,spmi-vib", .data = &spmi_vib_regs },
>>           { }
>>
>>
>>>>
>>>>
>>>>
>>>>>>
>>>>>>
>>>>>>>> +       .drv_en_manual_mask = 0,
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +static struct pm8xxx_regs pm7250b_regs = {
>>>>>>>> +       .enable_addr = 0x5346,
>>>>>>>> +       .enable_mask = BIT(7),
>>>>>>>> +       .drv_addr = 0x5340,
>>>>>>>> +       .drv_mask = 0xff,
>>>>>>>> +       .drv_shift = 0,
>>>>>>>> +       .drv_addr2 = 0x5341,
>>>>>>>> +       .drv_mask2 = 0x0f,
>>>>>>>> +       .drv_shift2 = 8,
>>>>>>>> +       .drv_en_manual_mask = 0,
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +static struct pm8xxx_regs pm7325b_regs = {
>>>>>>>> +       .enable_addr = 0xdf46,
>>>>>>>> +       .enable_mask = BIT(7),
>>>>>>>> +       .drv_addr = 0xdf40,
>>>>>>>> +       .drv_mask = 0xff,
>>>>>>>> +       .drv_shift = 0,
>>>>>>>> +       .drv_addr2 = 0xdf41,
>>>>>>>> +       .drv_mask2 = 0x0f,
>>>>>>>> +       .drv_shift2 = 8,
>>>>>>>> +       .drv_en_manual_mask = 0,
>>>>>>>> +};
>>>>>>>> +
>>>>>>>>      /**
>>>>>>>>       * struct pm8xxx_vib - structure to hold vibrator data
>>>>>>>>       * @vib_input_dev: input device supporting force feedback
>>>>>>>> @@ -87,6 +126,12 @@ static int pm8xxx_vib_set(struct pm8xxx_vib *vib, bool on)
>>>>>>>>                     return rc;
>>>>>>>>
>>>>>>>>             vib->reg_vib_drv = val;
>>>>>>>> +       if (regs->drv_addr2 != 0 && on) {
>>>>>>>> +               val = (vib->level << regs->drv_shift2) & regs->drv_mask2;
>>>>>>>> +               rc = regmap_write(vib->regmap, regs->drv_addr2, val);
>>>>>>>> +               if (rc < 0)
>>>>>>>> +                       return rc;
>>>>>>>> +       }
>>>>>>>>
>>>>>>>>             if (regs->enable_mask)
>>>>>>>>                     rc = regmap_update_bits(vib->regmap, regs->enable_addr,
>>>>>>>> @@ -242,6 +287,9 @@ static const struct of_device_id pm8xxx_vib_id_table[] = {
>>>>>>>>             { .compatible = "qcom,pm8058-vib", .data = &pm8058_regs },
>>>>>>>>             { .compatible = "qcom,pm8921-vib", .data = &pm8058_regs },
>>>>>>>>             { .compatible = "qcom,pm8916-vib", .data = &pm8916_regs },
>>>>>>>> +       { .compatible = "qcom,pmi632-vib", .data = &pmi632_regs },
>>>>>>>> +       { .compatible = "qcom,pm7250b-vib", .data = &pm7250b_regs },
>>>>>>>> +       { .compatible = "qcom,pm7325b-vib", .data = &pm7325b_regs },
>>>>>>>>             { }
>>>>>>>>      };
>>>>>>>>      MODULE_DEVICE_TABLE(of, pm8xxx_vib_id_table);
>>>>>>>> --
>>>>>>>> 2.25.1
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
> 
> 
>