All of lore.kernel.org
 help / color / mirror / Atom feed
From: Konrad Dybcio <konrad.dybcio@linaro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: Robert Marko <robimarko@gmail.com>,
	ilia.lin@kernel.org, agross@kernel.org, andersson@kernel.org,
	rafael@kernel.org, viresh.kumar@linaro.org,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 4/4] cpufreq: qcom-nvmem: make qcom_cpufreq_get_msm_id() return the SoC ID
Date: Sat, 18 Feb 2023 21:40:43 +0100	[thread overview]
Message-ID: <2a7a43f1-a13d-f094-5167-de74d5092d91@linaro.org> (raw)
In-Reply-To: <CAA8EJppwNVtUjB7fUZSCrZ88Ssbhmc4HD6oA2nV0uEx+vHBXUw@mail.gmail.com>



On 18.02.2023 21:36, Dmitry Baryshkov wrote:
> On Sat, 18 Feb 2023 at 16:43, Konrad Dybcio <konrad.dybcio@linaro.org> wrote:
>>
>>
>>
>> On 21.01.2023 12:29, Robert Marko wrote:
>>> Currently, qcom_cpufreq_get_msm_id() does not simply return the SoC ID
>>> after getting it via SMEM call but instead uses an enum to encode the
>>> matched SMEM ID to 2 variants of MSM8996 which are then used in
>>> qcom_cpufreq_kryo_name_version() to set the supported version.
>>>
>>> This prevents qcom_cpufreq_get_msm_id() from being universal and its doing
>>> more than its name suggests, so lets make it just return the SoC ID
>>> directly which allows matching directly on the SoC ID and removes the need
>>> for msm8996_version enum which simplifies the driver.
>>> It also allows reusing the qcom_cpufreq_get_msm_id() for new SoC-s.
>>>
>>> Signed-off-by: Robert Marko <robimarko@gmail.com>
>>> ---
>>>  drivers/cpufreq/qcom-cpufreq-nvmem.c | 44 ++++++++--------------------
>>>  1 file changed, 12 insertions(+), 32 deletions(-)
>>>
>>> diff --git a/drivers/cpufreq/qcom-cpufreq-nvmem.c b/drivers/cpufreq/qcom-cpufreq-nvmem.c
>>> index da55d2e1925a..9deaf9521d6d 100644
>>> --- a/drivers/cpufreq/qcom-cpufreq-nvmem.c
>>> +++ b/drivers/cpufreq/qcom-cpufreq-nvmem.c
>>> @@ -32,12 +32,6 @@
>>>
>>>  #include <dt-bindings/arm/qcom,ids.h>
>>>
>>> -enum _msm8996_version {
>>> -     MSM8996_V3,
>>> -     MSM8996_SG,
>>> -     NUM_OF_MSM8996_VERSIONS,
>>> -};
>>> -
>>>  struct qcom_cpufreq_drv;
>>>
>>>  struct qcom_cpufreq_match_data {
>>> @@ -134,30 +128,16 @@ static void get_krait_bin_format_b(struct device *cpu_dev,
>>>       dev_dbg(cpu_dev, "PVS version: %d\n", *pvs_ver);
>>>  }
>>>
>>> -static enum _msm8996_version qcom_cpufreq_get_msm_id(void)
>>> +static int qcom_cpufreq_get_msm_id(void)
>> This should be u32 as info->id is __le32
>>
>> And please export this function from socinfo, it'll come in
>> useful for other drivers!
> 
> How? In my opinion newer drivers should use compat strings rather than
> depending on the SoC ID. If we were not bound with the compatibility
> for msm8996pro device trees already using higher bits, we could have
> dropped this part too.
Adreno speedbin-to-fuse mapping could use SoC detection..

Konrad
> 

  reply	other threads:[~2023-02-18 20:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-21 11:29 [PATCH 1/4] soc: qcom: socinfo: move SMEM item struct and defines to a header Robert Marko
2023-01-21 11:29 ` [PATCH 2/4] cpufreq: qcom-nvmem: reuse socinfo SMEM item struct Robert Marko
2023-02-06 20:38   ` Bjorn Andersson
2023-02-07  4:15     ` Viresh Kumar
2023-01-21 11:29 ` [PATCH 3/4] cpufreq: qcom-nvmem: use SoC ID-s from bindings Robert Marko
2023-01-23 16:59   ` Konrad Dybcio
2023-02-06 20:40   ` Bjorn Andersson
2023-01-21 11:29 ` [PATCH 4/4] cpufreq: qcom-nvmem: make qcom_cpufreq_get_msm_id() return the SoC ID Robert Marko
2023-02-06 20:42   ` Bjorn Andersson
2023-02-18 14:43   ` Konrad Dybcio
2023-02-18 20:36     ` Dmitry Baryshkov
2023-02-18 20:40       ` Konrad Dybcio [this message]
2023-03-03 18:38         ` Robert Marko
2023-03-03 20:46           ` Konrad Dybcio
2023-03-03 21:38             ` Robert Marko
2023-03-03 21:40               ` Konrad Dybcio
2023-03-03 23:52             ` Dmitry Baryshkov
2023-01-21 11:33 ` [PATCH 1/4] soc: qcom: socinfo: move SMEM item struct and defines to a header Christophe JAILLET
2023-01-21 11:42   ` Robert Marko
2023-05-27  4:00 ` (subset) " Bjorn Andersson

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=2a7a43f1-a13d-f094-5167-de74d5092d91@linaro.org \
    --to=konrad.dybcio@linaro.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=ilia.lin@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=robimarko@gmail.com \
    --cc=viresh.kumar@linaro.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.