Message ID | 20250311-dtbinding-v1-0-5c807d33f7ae@quicinc.com |
---|---|
Headers | show |
Series | media: qcom: iris: add support for SA8775P | expand |
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 >
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
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
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
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
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,