From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CCC25C61DA3 for ; Fri, 3 Mar 2023 23:53:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229815AbjCCXw7 (ORCPT ); Fri, 3 Mar 2023 18:52:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56782 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229797AbjCCXwy (ORCPT ); Fri, 3 Mar 2023 18:52:54 -0500 Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 220E41FC0 for ; Fri, 3 Mar 2023 15:52:51 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id cw28so16687715edb.5 for ; Fri, 03 Mar 2023 15:52:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ds56s+08kdYvDMmH+33NMO0RlnG4QzULUhWsLzSvP4Q=; b=aT9YjIUpnXvrBXw15F7ekj0rJ1qxLOitv11dwxC+CTR2Np2hl4g+NviFNczwSDUbb3 2PeAAOKONtU2ZzEW4x9EOCvPkGyDe5b7C9ibJQPXBJZvTs6cITfhLiPqoUFPBIX7AUxX LPWlXNpDebS7Y8cA/dEKg+bajpJWsyVX8i82XymLa6g8ohgpdyb/GCLsbojVOSbIFXi3 ebGu6WEAnMYRLJh4UHMD5WAGfK2MJKP9wKkSU58iDkaSzSCHW78mEU0BGWqg+VU+i2u3 qqtWU8VnJfNeCQRjADXYBHlIp2TmUUfKGK9k5QpHPgx7HwFhnN+KIM5ebtI+YSVMiio7 9HrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ds56s+08kdYvDMmH+33NMO0RlnG4QzULUhWsLzSvP4Q=; b=pzVybAZ+3oWBDmOruNX4FAl+RFAcsucS/FiFFtbqBtLM4V/wC9q9GX2bjal7yU9ZYX huAdG+uzEFel38cy6gP51ZkSK5NeEYx82GXQD2TkUktIndFC1PzP3ReaRhQX+oVr8nI1 v8guC1WKfvD6XLKmCUrNy1mZWiFTtwYvk9gfVkybSHs51B601SDCo3iUBaj9UouKUDYD 65HnU0JtLlcXuP0N9nlkX9v07A/xgPyv/0iOLnKARVnuVNZo4cfZfI8GoKkjSehXrxyz HA/s1seOD6rlliL9Ca7mHcQAId29MbR9wvwC5sxGfAF+7wMsI9lLStWrTTun5BEHAn6Z GX+Q== X-Gm-Message-State: AO0yUKVLox1Uy7bPt5iyvOIrcJbfKo54XeYChcLCAHLmw4IkL6OlOCeU OCTMdRgqovR7Cmdt1o9BiC+cww== X-Google-Smtp-Source: AK7set8Csku+IygSuZ94X43z6Yl9CT+uKiMOenYBeJySofzD5UzJFd3hGZHsrLwydnh1U+fiFp1coA== X-Received: by 2002:a17:907:1905:b0:8a6:e075:e364 with SMTP id ll5-20020a170907190500b008a6e075e364mr3286199ejc.26.1677887569559; Fri, 03 Mar 2023 15:52:49 -0800 (PST) Received: from [10.203.3.194] ([185.202.34.81]) by smtp.gmail.com with ESMTPSA id ch10-20020a170906c2ca00b008cf8c6f5c43sm1454194ejb.83.2023.03.03.15.52.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 03 Mar 2023 15:52:49 -0800 (PST) Message-ID: Date: Sat, 4 Mar 2023 01:52:48 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH 4/4] cpufreq: qcom-nvmem: make qcom_cpufreq_get_msm_id() return the SoC ID Content-Language: en-GB To: Konrad Dybcio , Robert Marko Cc: 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 References: <20230121112947.53433-1-robimarko@gmail.com> <20230121112947.53433-4-robimarko@gmail.com> <2a7a43f1-a13d-f094-5167-de74d5092d91@linaro.org> <2faac9b8-03b9-340f-d43f-317624d4d5bb@linaro.org> From: Dmitry Baryshkov In-Reply-To: <2faac9b8-03b9-340f-d43f-317624d4d5bb@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On 03/03/2023 22:46, Konrad Dybcio wrote: > > > On 3.03.2023 19:38, Robert Marko wrote: >> On Sat, 18 Feb 2023 at 21:40, Konrad Dybcio wrote: >>> >>> >>> >>> On 18.02.2023 21:36, Dmitry Baryshkov wrote: >>>> On Sat, 18 Feb 2023 at 16:43, Konrad Dybcio 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 >>>>>> --- >>>>>> 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 >>>>>> >>>>>> -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 >> >> Nice catch. >> >> >>>>> >>>>> And please export this function from socinfo, it'll come in >>>>> useful for other drivers! >> >> I intentionally did not do that as socinfo is currently fully optional >> and I dont really like >> the idea of making it required for anything using SMEM. > "anything using SMEM"? As in the drivers, or SoCs? > If the former, I don't see how exporting a function from within > socid and using it here would make it required for other drivers. > If the latter, we're talking non-qcom SoCs. SMEM has been with > us forever. > > > I'm planning to reuse this for Adreno speedbin matching. It's one > of those blocks that don't have a revision and/or bin reigster > within themselves. I have mixed feelings towards this. And anyway it might be better to add get_msm_id() function to SCM driver, rather than parsing the data here. -- With best wishes Dmitry