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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4EE18C433DB for ; Mon, 11 Jan 2021 04:25:32 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 13DB3224D3 for ; Mon, 11 Jan 2021 04:25:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726599AbhAKEZQ (ORCPT ); Sun, 10 Jan 2021 23:25:16 -0500 Received: from so254-31.mailgun.net ([198.61.254.31]:52084 "EHLO so254-31.mailgun.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726029AbhAKEZP (ORCPT ); Sun, 10 Jan 2021 23:25:15 -0500 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=mg.codeaurora.org; q=dns/txt; s=smtp; t=1610339091; h=Message-ID: References: In-Reply-To: Subject: Cc: To: From: Date: Content-Transfer-Encoding: Content-Type: MIME-Version: Sender; bh=YjLVjY//RNNWhBt038pBhnPhk7W2XO47G1a0lqsYg4I=; b=xWQQ6/6nICUxjdb2RVJvYYPN/hMNuOVA92j3AePlgYj/8252+7Gv82ldN6jtOyTYPGRxd1Q2 fzpD6a3orCUlxg4F1cBx7GpXeFdEl+7a/XC5p+L/jOMUpFsX6Rl2gySuUossqQ0Yxg75M1Qv Cg3FNofb/oJVuT8UFLqWqAra3E0= X-Mailgun-Sending-Ip: 198.61.254.31 X-Mailgun-Sid: WyI0MWYwYSIsICJsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnIiwgImJlOWU0YSJd Received: from smtp.codeaurora.org (ec2-35-166-182-171.us-west-2.compute.amazonaws.com [35.166.182.171]) by smtp-out-n04.prod.us-east-1.postgun.com with SMTP id 5ffbd2eec88af06107b8d304 (version=TLS1.2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); Mon, 11 Jan 2021 04:24:14 GMT Sender: saiprakash.ranjan=codeaurora.org@mg.codeaurora.org Received: by smtp.codeaurora.org (Postfix, from userid 1001) id DDC15C433CA; Mon, 11 Jan 2021 04:24:13 +0000 (UTC) Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: saiprakash.ranjan) by smtp.codeaurora.org (Postfix) with ESMTPSA id A8D5CC433C6; Mon, 11 Jan 2021 04:24:12 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 11 Jan 2021 09:54:12 +0530 From: Sai Prakash Ranjan To: Rob Clark Cc: Konrad Dybcio , Sean Paul , Jordan Crouse , Jonathan , David Airlie , linux-arm-msm , Sharat Masetty , martin.botka@somainline.org, Akhil P Oommen , dri-devel , Bjorn Andersson , Shawn Guo , marijn.suijten@somainline.org, ~postmarketos/upstreaming@lists.sr.ht, Daniel Vetter , angelogioacchino.delregno@somainline.org, Dave Airlie , phone-devel@vger.kernel.org, freedreno , Linux Kernel Mailing List Subject: Re: [Freedreno] [PATCH] drm/msm: Only enable A6xx LLCC code on A6xx In-Reply-To: References: <20210108122601.14993-1-saiprakash.ranjan@codeaurora.org> <43c8779bc5f03be2e8072c6484dfcabb@codeaurora.org> Message-ID: <73609df52188588bf7d023e16a706a7a@codeaurora.org> X-Sender: saiprakash.ranjan@codeaurora.org User-Agent: Roundcube Webmail/1.3.9 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Rob, On 2021-01-08 22:16, Rob Clark wrote: > On Fri, Jan 8, 2021 at 6:05 AM Sai Prakash Ranjan > wrote: >> >> On 2021-01-08 19:09, Konrad Dybcio wrote: >> >> Konrad, can you please test this below change without your change? >> > >> > This brings no difference, a BUG still happens. We're still calling >> > to_a6xx_gpu on ANY device that's probed! Too bad it won't turn my A330 >> > into an A640.. >> > >> > Also, relying on disabling LLCC in the config is out of question as it >> > makes the arm32 kernel not compile with DRM/MSM and it just removes >> > the functionality on devices with a6xx.. (unless somebody removes the >> > dependency on it, which in my opinion is even worse and will cause >> > more problems for developers!). >> > >> >> Disabling LLCC is not the suggestion, I was under the impression that >> was the cause here for the smmu bug. Anyways, the check for llc slice >> in case llcc is disabled is not correct as well. I will send a patch >> for >> that as well. >> >> > The bigger question is how and why did that piece of code ever make it >> > to adreno_gpu.c and not a6xx_gpu.c? >> > >> >> My mistake, I will move it. > > Thanks, since we don't have kernel-CI coverage for gpu, and there > probably isn't one person who has all the different devices supported > (or enough hours in the day to test them all), it is probably > better/safer to keep things in the backend code that is specific to a > given generation. > Agreed, I will post this change soon and will introduce some feature check as well because we will need it for iommu prot flag as per discussion here - https://lore.kernel.org/lkml/20210108181830.GA5457@willie-the-truck/ >> > To solve it in a cleaner way I propose to move it to an a6xx-specific >> > file, or if it's going to be used with next-gen GPUs, perhaps manage >> > calling of this code via an adreno quirk/feature in adreno_device.c. >> > Now that I think about it, A5xx GPMU en/disable could probably managed >> > like that, instead of using tons of if-statements for each GPU model >> > that has it.. >> > >> > While we're at it, do ALL (and I truly do mean ALL, including the >> > low-end ones, this will be important later on) A6xx GPUs make use of >> > that feature? >> > >> >> I do not have a list of all A6XX GPUs with me currently, but from what >> I know, A618, A630, A640, A650 has the support. >> > > From the PoV of bringing up new a6xx, we should probably consider that > some of them may not *yet* have LLCC enabled. I have an 8cx laptop > and once I find time to get the display working, the next step would > be bringing up a680.. and I'd probably like to start without LLCC.. > Right, once I move the LLCC code to a6xx specific address space creation, without LLCC slices for GPU specified in qcom llcc driver, we will not be using it. Thanks, Sai -- QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation