mbox series

[0/4] media: qcom: iris: add support for SA8775P

Message ID 20250311-dtbinding-v1-0-5c807d33f7ae@quicinc.com
Headers show
Series media: qcom: iris: add support for SA8775P | expand

Message

Vikash Garodia March 11, 2025, 12:03 p.m. UTC
Add support for video hardware acceleration on SA8775P platform. SA8775P 
is a similar video IP as that in SM8550, except the input to hardware 
being a collapsible MX.

Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
---
Vikash Garodia (4):
      dt-bindings: media: qcom,sm8550-iris: update power domain name
      dt-bindings: media: qcom,sm8550-iris: document SA8775p IRIS accelerator
      arm64: dts: qcom: sa8775p: add support for video node
      media: iris: add compatible string for sa8775p

 .../bindings/media/qcom,sm8550-iris.yaml           |  6 +-
 arch/arm64/boot/dts/qcom/sa8775p.dtsi              | 67 ++++++++++++++++++++++
 drivers/media/platform/qcom/iris/iris_probe.c      |  4 ++
 3 files changed, 75 insertions(+), 2 deletions(-)
---
base-commit: f2151613e040973c868d28c8b00885dfab69eb75
change-id: 20250310-dtbinding-8921bfc151e9

Best regards,

Comments

Dmitry Baryshkov March 11, 2025, 3:07 p.m. UTC | #1
On Tue, Mar 11, 2025 at 05:33:53PM +0530, Vikash Garodia wrote:
> Not all platforms has a collapsible mx, so use the more generic naming
> of mx in the binding.

I guess, it wasn't even tested...

> 
> Signed-off-by: Vikash Garodia <quic_vgarodia@quicinc.com>
> ---
>  Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> index e424ea84c211f473a799481fd5463a16580187ed..440a0d7cdfe19a1ccedefc207d96b26eed5d6630 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-iris.yaml
> @@ -28,7 +28,7 @@ properties:
>      items:
>        - const: venus
>        - const: vcodec0
> -      - const: mxc
> +      - const: mx
>        - const: mmcx
>  
>    clocks:
> 
> -- 
> 2.34.1
>
Konrad Dybcio March 11, 2025, 4:24 p.m. UTC | #2
On 3/11/25 4:11 PM, Vikash Garodia wrote:
> 
> On 3/11/2025 8:37 PM, Dmitry Baryshkov wrote:
>> On Tue, Mar 11, 2025 at 05:33:53PM +0530, Vikash Garodia wrote:
>>> Not all platforms has a collapsible mx, so use the more generic naming
>>> of mx in the binding.
>>
>> I guess, it wasn't even tested...
> Not sure what made you guess so, let me check why my binding checker did not
> catch the bot reported warning.

You probably checked the compiled DTBs (make dtbs_check / CHECK_DTBS=1), but you
also need to test the YAML (make dt_binding_check)

This change can't be accepted as-is, because there are already expectations
about the naming (and order) of the entries.

Because there's a difference, you would normally be expected to add a whole new
list, but maybe the dt-bindings maintainers will agree to Dmitry's solution of
adding a sneaky enum inside the list

Konrad
Krzysztof Kozlowski March 11, 2025, 5:33 p.m. UTC | #3
On 11/03/2025 13:03, Vikash Garodia wrote:
> Not all platforms has a collapsible mx, so use the more generic naming
> of mx in the binding.
> 

No, neither tested, nor justified. Read the file. How many platforms do
you have there? One. Out of this one platform you claim not all of them
have MX collapsible, so you want MX?

Best regards,
Krzysztof
Krzysztof Kozlowski March 12, 2025, 8:44 a.m. UTC | #4
On 11/03/2025 18:47, Vikash Garodia wrote:
> 
> On 3/11/2025 11:03 PM, Krzysztof Kozlowski wrote:
>> On 11/03/2025 13:03, Vikash Garodia wrote:
>>> Not all platforms has a collapsible mx, so use the more generic naming
>>> of mx in the binding.
>>>
>>
>> No, neither tested, nor justified. Read the file. How many platforms do
>> you have there? One. Out of this one platform you claim not all of them
>> have MX collapsible, so you want MX?
> Let say we have one which is non-collapsible, what should be the way in that
> case to use the bindings which differ only in the MX/MXC part ?


I don't care about imaginary things. Send patches for real hardware. How
does collapsibility of the domain change the real hardware interface?

Best regards,
Krzysztof
Vikash Garodia March 12, 2025, 12:55 p.m. UTC | #5
On 3/12/2025 2:14 PM, Krzysztof Kozlowski wrote:
> On 11/03/2025 18:47, Vikash Garodia wrote:
>>
>> On 3/11/2025 11:03 PM, Krzysztof Kozlowski wrote:
>>> On 11/03/2025 13:03, Vikash Garodia wrote:
>>>> Not all platforms has a collapsible mx, so use the more generic naming
>>>> of mx in the binding.
>>>>
>>>
>>> No, neither tested, nor justified. Read the file. How many platforms do
>>> you have there? One. Out of this one platform you claim not all of them
>>> have MX collapsible, so you want MX?
>> Let say we have one which is non-collapsible, what should be the way in that
>> case to use the bindings which differ only in the MX/MXC part ?
> 
> 
> I don't care about imaginary things. Send patches for real hardware. How
> does collapsibility of the domain change the real hardware interface?
It does not. I am now thinking to drop this patch altogether, and continue to
use MXC as defined in bindings, irrespective of connection to hardware as MX or
MXC. For ex SM8550/SA8775P have MXC, while QCS8300 have MX, but again, as you
mentioned, these difference just alters some property in DT, binding can remain
same.
Regards,
Vikash