RE: [PATCH] Revert "venus: firmware: Correct non-pix start and end addresses"

[Vikash Garodia]

Hi Javier,

>-----Original Message-----
>From: Javier Martinez Canillas <javierm@xxxxxxxxxx>
>Sent: Friday, February 10, 2023 1:45 PM
>To: Vikash Garodia <vgarodia@xxxxxxxxxxxxxxxx>; linux-
>kernel@xxxxxxxxxxxxxxx; mka@xxxxxxxxxxxx
>Cc: Albert Esteve <aesteve@xxxxxxxxxx>; stanimir.varbanov@xxxxxxxxxx; Enric
>Balletbo i Serra <eballetb@xxxxxxxxxx>; Andy Gross <agross@xxxxxxxxxx>;
>Bjorn Andersson <andersson@xxxxxxxxxx>; Konrad Dybcio
><konrad.dybcio@xxxxxxxxxx>; Mauro Carvalho Chehab <mchehab@xxxxxxxxxx>;
>Stanimir Varbanov <stanimir.k.varbanov@xxxxxxxxx>; Vikash Garodia (QUIC)
><quic_vgarodia@xxxxxxxxxxx>; linux-arm-msm@xxxxxxxxxxxxxxx; linux-
>media@xxxxxxxxxxxxxxx; Fritz Koenig <frkoenig@xxxxxxxxxx>; Dikshita Agarwal
>(QUIC) <quic_dikshita@xxxxxxxxxxx>; Rajeshwar Kurapaty (QUIC)
><quic_rkurapat@xxxxxxxxxxx>
>Subject: Re: [PATCH] Revert "venus: firmware: Correct non-pix start and end
>addresses"
>
>WARNING: This email originated from outside of Qualcomm. Please be wary of
>any links or attachments, and do not enable macros.
>
>On 2/8/23 10:06, Javier Martinez Canillas wrote:
>> Hello Vikash,
>>
>> On 2/7/23 17:40, Vikash Garodia wrote:
>>> Hi Javier and Matthias,
>>> Can we try the attached patch if that fixes the suspend issue for sc7180 and
>sc7280 ?
>>>
>>
>> I tested your attached patch on an SC7180 machine (HP X2 Chromebook)
>> and as Matthias mentioned, it still causes the driver's probe to fail:
>>
>> [ 2119.063779] qcom-venus aa00000.video-codec: non legacy binding [
>> 2119.085695] platform video-firmware.0: Adding to iommu group 11 [
>> 2119.156302] arm-smmu 15000000.iommu: Unhandled context fault:
>> fsr=0x402, iova=0x000000b0, fsynr=0x61, cbfrsynra=0xc40, cb=7 [
>> 2119.259382] qcom-venus aa00000.video-codec: failed to reset venus
>> core [ 2119.267782] platform video-firmware.0: Removing from iommu
>> group 11 [ 2119.275052] qcom-venus: probe of aa00000.video-codec
>> failed with error -110
>>
>
>So what should we do about this folks? Since not allowing the driver to probe on
>at least SC7180 is a quite serious regression, can we revert for now until a proper
>fix is figured out?

I am able to repro this issue on sc7180 and discussing with firmware team on the cause
of reset failure. The original patch was raised for fixing rare SMMU faults during warm
boot of video hardware. Hence looking to understand the regressing part before we
proceed to revert.

>--
>Best regards,
>
>Javier Martinez Canillas
>Core Platforms
>Red Hat