Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH 1/2] arm64: dts: qcom: sm8250: Disable Adreno and Venus by
 default
To:     Rob Clark <robdclark@gmail.com>
Cc:     ~postmarketos/upstreaming@lists.sr.ht,
        Martin Botka <martin.botka@somainline.org>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@somainline.org>,
        Marijn Suijten <marijn.suijten@somainline.org>,
        jamipkettunen@somainline.org, Andy Gross <agross@kernel.org>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Rob Herring <robh+dt@kernel.org>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
References: <20210611113514.27173-1-konrad.dybcio@somainline.org>
 <CAF6AEGv3UivqUKb8wkCgzpApORV=ucswOzUh7BQMWRiif5ZJdw@mail.gmail.com>
From:   Konrad Dybcio <konrad.dybcio@somainline.org>
Message-ID: <94bf5d73-6939-75dc-46da-ddb8d6ae017a@somainline.org>
Date:   Sat, 12 Jun 2021 21:39:23 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CAF6AEGv3UivqUKb8wkCgzpApORV=ucswOzUh7BQMWRiif5ZJdw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Precedence: bulk


On 11.06.2021 20:54, Rob Clark wrote:
> On Fri, Jun 11, 2021 at 4:35 AM Konrad Dybcio
> <konrad.dybcio@somainline.org> wrote:
>> Components that rely on proprietary (not to mention signed!) firmware should
>> not be enabled by default, as lack of the aforementioned firmware could cause
>> various issues, from random errors to straight-up failing to boot.
> I admit I probably don't test much without fw, but I think maybe
> *that* is the issue to solve instead.
>
> Taking a guess, I think the situation is that you have *some* of the
> fw (ie. the unsigned parts coming from linux-firmware) but not
> specifically the zap fw.  So adreno_zap_shader_load() returns -ENODEV,
> which is interpreted to mean "this is a platform that doesn't need zap
> to take GPU out of secure mode", and then things go boom when we try
> to write RBBM_SECVID_TRUST_CNTL ?

While we're not yet there to test that out on A6xx-equipped platforms,

my experience with lack ofAdreno firmware so far has been like so:


no ZAP, wrong ZAP address in the DT, bad ZAP - either a lockup or a reboot


no pm4/pfp - mostly a sane failing route with GPU just not activating after all,

yet still I can recall having some problems that I probably won't be able to

reproduce right now


no GMU fw - as stated before, can't really test properly just yet


Konrad