lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 11 Jan 2021 09:11:15 -0700 From: Jordan Crouse <jcrouse@...eaurora.org> To: Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org> Cc: Rob Clark <robdclark@...il.com>, Konrad Dybcio <konrad.dybcio@...ainline.org>, Sean Paul <sean@...rly.run>, Jonathan <jonathan@...ek.ca>, David Airlie <airlied@...ux.ie>, linux-arm-msm <linux-arm-msm@...r.kernel.org>, Sharat Masetty <smasetty@...eaurora.org>, martin.botka@...ainline.org, Akhil P Oommen <akhilpo@...eaurora.org>, dri-devel <dri-devel@...ts.freedesktop.org>, Bjorn Andersson <bjorn.andersson@...aro.org>, Shawn Guo <shawn.guo@...aro.org>, marijn.suijten@...ainline.org, ~postmarketos/upstreaming@...ts.sr.ht, Daniel Vetter <daniel@...ll.ch>, angelogioacchino.delregno@...ainline.org, Dave Airlie <airlied@...hat.com>, phone-devel@...r.kernel.org, freedreno <freedreno@...ts.freedesktop.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [Freedreno] [PATCH] drm/msm: Only enable A6xx LLCC code on A6xx On Mon, Jan 11, 2021 at 09:54:12AM +0530, Sai Prakash Ranjan wrote: > Hi Rob, > > On 2021-01-08 22:16, Rob Clark wrote: > >On Fri, Jan 8, 2021 at 6:05 AM Sai Prakash Ranjan > ><saiprakash.ranjan@...eaurora.org> 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. Right. The problem here was that we were assuming an a6xx container in generic code. Testing the existence of LLCC or not is a different problem but it is my understanding that if we set the attribute without LLCC enabled it just gets ignored. Is that correct Sai? Jordan > Thanks, > Sai > > -- > QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member > of Code Aurora Forum, hosted by The Linux Foundation -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
Powered by blists - more mailing lists