linux-kernel - Re: [Freedreno] [PATCH] drm/msm: Only enable A6xx LLCC code on A6xx

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 linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <73609df52188588bf7d023e16a706a7a@codeaurora.org>
Date:   Mon, 11 Jan 2021 09:54:12 +0530
From:   Sai Prakash Ranjan <saiprakash.ranjan@...eaurora.org>
To:     Rob Clark <robdclark@...il.com>
Cc:     Konrad Dybcio <konrad.dybcio@...ainline.org>,
        Sean Paul <sean@...rly.run>,
        Jordan Crouse <jcrouse@...eaurora.org>,
        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

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.

Thanks,
Sai

-- 
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member
of Code Aurora Forum, hosted by The Linux Foundation