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 283EBC61DA4 for ; Fri, 27 Jan 2023 14:23:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229511AbjA0OXc (ORCPT ); Fri, 27 Jan 2023 09:23:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36492 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231802AbjA0OX1 (ORCPT ); Fri, 27 Jan 2023 09:23:27 -0500 Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2598F783D8 for ; Fri, 27 Jan 2023 06:23:03 -0800 (PST) Received: by mail-ej1-x630.google.com with SMTP id v6so14145575ejg.6 for ; Fri, 27 Jan 2023 06:23:03 -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=1ldzFZEqDhcEGgVtJre8PmwCOxuUI7/pRZAmkiQNvpI=; b=EwdgZzNx2hEGN7vw25sw1Rjsq80EYXivvQ+6yLDcwdsEkmgc3BlP14ymg+4s8LcJRh //zchkSEHl7AFZjOUkCM9bmLfEcPxta8zrNxTe9gK5aIh6vv8Pko/E+gf3JH7LNz1/Y4 J3c7zYrEWsw5Xz39ld5GfaVqlzM2SM6tRaoQ7Ecmhtywfs8zRrMuKNklOfNyr6km9j0g bHs8sj+m1QPaWkFvv1zv9VmZSKpUeAkOm1DXmP4apsxmsGtwjk4ALSYU6qtSo76llPXq 1sI1eAO07mTTL8s+VgSY1nl6+8nPkkDyJlKNTfH7bxVVuXzC/3GNQZGJ+48Z+blxh6hz dz9Q== 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=1ldzFZEqDhcEGgVtJre8PmwCOxuUI7/pRZAmkiQNvpI=; b=xILUxFVFokRtsxCKA6+HDmwKAbfDQnmFJ8Y3E0K2xA09kR1FDJjB5KUHMpxtISrrwX 1xmK32fD7Y/coqqMwcUfWXB8BBhgvt+xzhNTegZuVC20tbgSLOcyZpBkXHhgdpkJ4gcu Aj7miyQVDvU5LUyEdOcFaMf90+ZLNZGcGNSE8JV1XbeFQZ5Ifd422+2zelL77VKlZzg5 vNSO9Ke0DbR11NrJhCJtUhmltWhgaqFhtXptqllExB2DwjkacIa7igDsk/NBsTPqZLFQ hzfw3fmgaVo6Xh8w7L5+9i78/Tozhu3vnOFOFSWHbPQiM2g87lq2y3x+eU0Iuk84GwS2 AkxQ== X-Gm-Message-State: AO0yUKUU0C6Iyq8p0JeZsuiL4UgbR1GOq9olU7BYqMZ7JjqxrrsNRzES PeTX/QFdcim3q75MGU09G+hHqw== X-Google-Smtp-Source: AK7set/pNDqvl32J5PrSB2nSJPU5Iq8uerNs8RxzmjCRiF9JfTAGwRSHw3gNaUtK5WntivT7LlZWrw== X-Received: by 2002:a17:906:d8b8:b0:878:b890:38bb with SMTP id qc24-20020a170906d8b800b00878b89038bbmr3013074ejb.67.1674829378159; Fri, 27 Jan 2023 06:22:58 -0800 (PST) Received: from [192.168.1.101] (abyl20.neoplus.adsl.tpnet.pl. [83.9.31.20]) by smtp.gmail.com with ESMTPSA id b2-20020a170906490200b0084d1b34973dsm2327844ejq.61.2023.01.27.06.22.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 27 Jan 2023 06:22:57 -0800 (PST) Message-ID: Date: Fri, 27 Jan 2023 15:22:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.0 Subject: Re: [PATCH 13/14] drm/msm/a6xx: Add A619_holi speedbin support Content-Language: en-US To: Dmitry Baryshkov , linux-arm-msm@vger.kernel.org, andersson@kernel.org, agross@kernel.org, krzysztof.kozlowski@linaro.org Cc: marijn.suijten@somainline.org, Rob Clark , Abhinav Kumar , Sean Paul , David Airlie , Daniel Vetter , Akhil P Oommen , Chia-I Wu , Douglas Anderson , dri-devel@lists.freedesktop.org, freedreno@lists.freedesktop.org, linux-kernel@vger.kernel.org References: <20230126151618.225127-1-konrad.dybcio@linaro.org> <20230126151618.225127-14-konrad.dybcio@linaro.org> From: Konrad Dybcio In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On 27.01.2023 15:19, Dmitry Baryshkov wrote: > On 26/01/2023 17:16, Konrad Dybcio wrote: >> A619_holi is implemented on at least two SoCs: SM4350 (holi) and SM6375 >> (blair). This is what seems to be a first occurrence of this happening, >> but it's easy to overcome by guarding the SoC-specific fuse values with >> of_machine_is_compatible(). Do just that to enable frequency limiting >> on these SoCs. >> >> Signed-off-by: Konrad Dybcio >> --- >>   drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 31 +++++++++++++++++++++++++++ >>   1 file changed, 31 insertions(+) >> >> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c >> index 452ba32699b2..89990bec897f 100644 >> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c >> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c >> @@ -2091,6 +2091,34 @@ static u32 a618_get_speed_bin(u32 fuse) >>       return UINT_MAX; >>   } >>   +static u32 a619_holi_get_speed_bin(u32 fuse) >> +{ >> +    /* >> +     * There are (at least) two SoCs implementing A619_holi: SM4350 (holi) >> +     * and SM6375 (blair). Limit the fuse matching to the corresponding >> +     * SoC to prevent bogus frequency setting (as improbable as it may be, >> +     * given unexpected fuse values are.. unexpected! But still possible.) >> +     */ >> + >> +    if (fuse == 0) >> +        return 0; >> + >> +    if (of_machine_is_compatible("qcom,sm4350")) { >> +        if (fuse == 138) >> +            return 1; >> +        else if (fuse == 92) >> +            return 2; >> +    } else if (of_machine_is_compatible("qcom,sm6375")) { >> +        if (fuse == 190) >> +            return 1; >> +        else if (fuse == 177) >> +            return 2; >> +    } else >> +        pr_warn("Unknown SoC implementing A619_holi!\n"); > > I think, we might be better to introduce "qcom,SoC-adreno" compat string instead, ignore it in the bindings I can hear Krzysztof hiring a hitman already.. and only care about it here. This might seem an overkill thinking from the single Adreno version. However this issue also affects other revisions. > > For example, for the A618 there are at least three platforms which use the same Adreno version: SC7180, SM7125 and SM7150. Only first one is supported (thus the speed_bin function is simple). However according to the vendor dts files all three platforms use different fuse values to specify the speed bin. Or we may switch to simply matching SoCs based on platform compatible, as it's really the SoC-specific and not GPU-specific. Konrad> >> + >> +    return UINT_MAX; >> +} >> + >>   static u32 a619_get_speed_bin(u32 fuse) >>   { >>       if (fuse == 0) >> @@ -2150,6 +2178,9 @@ static u32 fuse_to_supp_hw(struct device *dev, struct adreno_rev rev, u32 fuse) >>       if (adreno_cmp_rev(ADRENO_REV(6, 1, 8, ANY_ID), rev)) >>           val = a618_get_speed_bin(fuse); >>   +    else if (adreno_cmp_rev(ADRENO_REV(6, 1, 9, 1), rev)) >> +        val = a619_holi_get_speed_bin(fuse); >> + > > Are we sure that SM6350, the unholi A619 user, doesn't use patchid .1? (note I do not know a thing about Adreno patch ids and its usage between different platforms). > >>       else if (adreno_cmp_rev(ADRENO_REV(6, 1, 9, ANY_ID), rev)) >>           val = a619_get_speed_bin(fuse); >>   >