mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
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: Tue, 18 Jul 2023 18:55:13 +0800	[thread overview]
Message-ID: <501bc7d0-1f97-1c53-a7f8-701ab9dfdf8e@quicinc.com> (raw)
In-Reply-To: <CAA8EJpr--XZnFJX96etagAa0uT0yNBcgZTfFDuu8gH2C5sgoCg@mail.gmail.com>



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
>>>>
>>>
>>>
> 
> 
> 

  reply	other threads:[~2023-07-18 10:55 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 [this message]
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

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=501bc7d0-1f97-1c53-a7f8-701ab9dfdf8e@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®