[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <e1a6e75a-2a5d-44a2-8bbc-140eb86d1806@linaro.org>
Date: Fri, 4 Jul 2025 09:23:06 +0100
From: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
To: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
Krzysztof Kozlowski <krzk@...nel.org>,
Vikash Garodia <quic_vgarodia@...cinc.com>,
Dikshita Agarwal <quic_dikshita@...cinc.com>,
Abhinav Kumar <abhinav.kumar@...ux.dev>,
Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, linux-media@...r.kernel.org,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 0/5] Introduce "non-pixel" sub node within iris video
node
On 03/07/2025 22:23, Dmitry Baryshkov wrote:
>> I still give my RB for the series.
>>
>> To me the only question is should it be applied to sm8550 or to new SoCs
>> from now on, sa8775p, x1e and derivatives.
> I think we need to apply it to_all_ SoCs, maybe starting from MSM8x26
> and MSM8x16. Likewise, we need to think bout secure buffers usecase. And
> once we do that, we will realize that it also changes the ABI for all
> SoCs that support either Venus or Iris.
I think a dts change is a non-starter as its an ABI break.
So if ABI break is out and reworking future dts to allow for a new
device is out, then some API change is needed to allow the driver to
stop the kernel automatically setting up the IOMMUs, create the new
device as a platform device not dependent on DT change and have the
probe() of the relevant drivers setup their own IOMMU extents based on -
probably indexes we have in the driver configuration parameters.
---
bod
Powered by blists - more mailing lists