From: Fenglin Wu <quic_fenglinw@quicinc.com>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: <linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
"Andy Gross" <agross@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
"Konrad Dybcio" <konrad.dybcio@linaro.org>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
<linux-input@vger.kernel.org>, <quic_collinsd@quicinc.com>,
<quic_subbaram@quicinc.com>, <quic_kamalw@quicinc.com>,
<jestar@qti.qualcomm.com>, <quic_huliu@quicinc.com>
Subject: Re: [PATCH v2 2/2] Input: pm8xxx-vib - Add support for more PMICs
Date: Wed, 19 Jul 2023 16:24:05 +0800 [thread overview]
Message-ID: <89e5a091-b775-35cf-bfc6-c48abf185b26@quicinc.com> (raw)
In-Reply-To: <CAA8EJpoeFwu7P7jEqhmwttAeF4VAhaCSaKP4XrUQz1YVsg9zvw@mail.gmail.com>
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", ®_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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
prev parent reply other threads:[~2023-07-19 8:24 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-18 6:26 [PATCH v2 0/2] Add support for vibrator in multiple PMICs Fenglin Wu
2023-07-18 6:26 ` [PATCH v2 1/2] dt-bindings: input: qcom,pm8xxx-vib: add more PMIC support Fenglin Wu
2023-07-18 6:33 ` Krzysztof Kozlowski
2023-07-18 6:38 ` Fenglin Wu
2023-07-18 7:06 ` Fenglin Wu
2023-07-18 7:20 ` Krzysztof Kozlowski
2023-07-18 7:59 ` Fenglin Wu
2023-07-18 8:02 ` Krzysztof Kozlowski
2023-07-27 7:10 ` Krzysztof Kozlowski
2023-07-27 7:54 ` Fenglin Wu
2023-07-27 8:29 ` Krzysztof Kozlowski
2023-07-27 10:51 ` Fenglin Wu
2023-07-18 10:51 ` Konrad Dybcio
2023-07-18 10:56 ` Fenglin Wu
2023-07-18 6:26 ` [PATCH v2 2/2] Input: pm8xxx-vib - Add support for more PMICs Fenglin Wu
2023-07-18 6:44 ` Dmitry Baryshkov
2023-07-18 6:58 ` Fenglin Wu
2023-07-18 9:41 ` Dmitry Baryshkov
2023-07-18 10:55 ` Fenglin Wu
2023-07-18 11:04 ` Dmitry Baryshkov
2023-07-19 4:09 ` Fenglin Wu
2023-07-19 8:02 ` Dmitry Baryshkov
2023-07-19 8:24 ` Fenglin Wu [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=89e5a091-b775-35cf-bfc6-c48abf185b26@quicinc.com \
--to=quic_fenglinw@quicinc.com \
--cc=agross@kernel.org \
--cc=andersson@kernel.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=dmitry.torokhov@gmail.com \
--cc=jestar@qti.qualcomm.com \
--cc=konrad.dybcio@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_collinsd@quicinc.com \
--cc=quic_huliu@quicinc.com \
--cc=quic_kamalw@quicinc.com \
--cc=quic_subbaram@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®