Message-ID: <023038d4-2258-4b2d-a3f9-b817ef0173bc@kernel.org>
Date: Wed, 2 Jul 2025 15:59:35 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
 Vikash Garodia <quic_vgarodia@...cinc.com>,
 Dikshita Agarwal <quic_dikshita@...cinc.com>,
 Abhinav Kumar <abhinav.kumar@...ux.dev>,
 Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
 Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>
Cc: linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
 devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 1/5] media: dt-bindings: add non-pixel property in iris
 schema

On 02/07/2025 15:11, Konrad Dybcio wrote:
> On 7/2/25 1:46 PM, Krzysztof Kozlowski wrote:
>> On 02/07/2025 13:32, Vikash Garodia wrote:
>>>
>>> On 7/2/2025 4:43 PM, Krzysztof Kozlowski wrote:
>>>> On 27/06/2025 17:48, Vikash Garodia wrote:
>>>>> Existing definition limits the IOVA to an addressable range of 4GiB, and
>>>>> even within that range, some of the space is used by IO registers,
>>>>> thereby limiting the available IOVA to even lesser. Video hardware is
>>>>> designed to emit different stream-ID for pixel and non-pixel buffers,
>>>>> thereby introduce a non-pixel sub node to handle non-pixel stream-ID.
>>>>>
>>>>> With this, both iris and non-pixel device can have IOVA range of 0-4GiB
>>>>> individually. Certain video usecases like higher video concurrency needs
>>>>> IOVA higher than 4GiB.
>>>>>
>>>>> Add reference to the reserve-memory schema, which defines reserved IOVA
> 
> [...]
> 
>>>>>    dma-coherent: true
>>>>>  
>>>>> +  non-pixel:
>>>>
>>>> Why EXISTING hardware grows?
>>> Same here, the commit describes the limitation of existing design and also
>>> explains the need for having the non-pixel device. Its not that the hardware is
>>> growing here, rather the hardware stream-IDs are utilized differently to get
>>> higher device addressable range.
>>
>> You are not doing this for a new device. There is no new device here at
>> all. Nowhere here is a new device.
>>
>> Changes for a new device COME TOGETHER with the new device.
>>
>> What you are doing here is changing existing hardware without any
>> explanation why.
> 
> This is bindings getting a reality check.. this goes as far back as Venus
> existed (msm8974/2012)

This won't fly. This is a new binding after long reviews and
discussions, why Qualcomm does not want to extend existing Venus but
needs completely new Iris. Well, if you get completely new Iris, you
cannot use argument of "legacy". We insisted on growing existing
solution, but choice of abandoning it and coming with a new one means
you were supposed to do it right since there is no legacy.

> 
> We unfortunately have to expect a number of similar updates for all
> multimedia peripherals (GPU/Camera/Display etc.), as certain mappings
> must be done through certain SIDs (which are deemed 'secure') and some
> hardware has general addressing limitations that may have been causing
> silent issues all along
> 
Isn't all this commit msg here about non-pixel stuff just not really
describing the real problem at all? This commit msg is very vague and
silent on actual use cases and actual firmware, so even multiple
readings of commit msg did not help me. Stephan Gerhold now nicely
summarized what was never told in commit msg - there is a gap in address
space which is reserved for firmware and no allocations can be done from
that?

Also commit msg says "Existing definition limits the IOVA to an
addressable range of 4GiB, and" but I do not see such definition in the
binding at all. So what does it refer to?



Best regards,
Krzysztof

Powered by blists - more mailing lists