* [PATCH 1/3] dt-bindings: media: qcom,milos-iris: Add Milos video codec
From: Alexander Koskovich @ 2026-04-06 10:19 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: Luca Weiss, linux-media, linux-arm-msm, devicetree, linux-kernel,
Alexander Koskovich
In-Reply-To: <20260406-milos-iris-v1-0-17ed0167ba6f@pm.me>
Add binding for Qualcomm Milos Iris video codec.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
---
.../devicetree/bindings/media/qcom,milos-iris.yaml | 166 +++++++++++++++++++++
1 file changed, 166 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/qcom,milos-iris.yaml b/Documentation/devicetree/bindings/media/qcom,milos-iris.yaml
new file mode 100644
index 000000000000..36f49590d7b8
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,milos-iris.yaml
@@ -0,0 +1,166 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,milos-iris.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Milos SoC Iris video encoder and decoder
+
+maintainers:
+ - Alexander Koskovich <akoskovich@pm.me>
+
+description:
+ The Iris video processing unit on Qualcomm Milos SoC is a video encode and
+ decode accelerator.
+
+properties:
+ compatible:
+ enum:
+ - qcom,milos-iris
+
+ clocks:
+ maxItems: 3
+
+ clock-names:
+ items:
+ - const: iface
+ - const: core
+ - const: vcodec0_core
+
+ dma-coherent: true
+
+ interconnects:
+ maxItems: 2
+
+ interconnect-names:
+ items:
+ - const: cpu-cfg
+ - const: video-mem
+
+ iommus:
+ maxItems: 2
+
+ operating-points-v2: true
+ opp-table:
+ type: object
+
+ power-domains:
+ maxItems: 4
+
+ power-domain-names:
+ items:
+ - const: venus
+ - const: vcodec0
+ - const: cx
+ - const: mx
+
+ resets:
+ maxItems: 2
+
+ reset-names:
+ items:
+ - const: bus
+ - const: core
+
+required:
+ - compatible
+ - dma-coherent
+ - interconnects
+ - interconnect-names
+ - iommus
+ - power-domain-names
+ - resets
+ - reset-names
+
+allOf:
+ - $ref: qcom,venus-common.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,milos-gcc.h>
+ #include <dt-bindings/clock/qcom,milos-videocc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interconnect/qcom,icc.h>
+ #include <dt-bindings/interconnect/qcom,milos-rpmh.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/power/qcom,rpmhpd.h>
+
+ video-codec@aa00000 {
+ compatible = "qcom,milos-iris";
+ reg = <0x0aa00000 0xf0000>;
+
+ clocks = <&gcc GCC_VIDEO_AXI0_CLK>,
+ <&videocc VIDEO_CC_MVS0C_CLK>,
+ <&videocc VIDEO_CC_MVS0_CLK>;
+ clock-names = "iface",
+ "core",
+ "vcodec0_core";
+
+ dma-coherent;
+ iommus = <&apps_smmu 0x1960 0>,
+ <&apps_smmu 0x1967 0>;
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
+ &cnoc_cfg SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
+ <&mmss_noc MASTER_VIDEO QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "cpu-cfg",
+ "video-mem";
+
+ interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>;
+
+ operating-points-v2 = <&iris_opp_table>;
+
+ memory-region = <&video_mem>;
+
+ power-domains = <&videocc VIDEO_CC_MVS0C_GDSC>,
+ <&videocc VIDEO_CC_MVS0_GDSC>,
+ <&rpmhpd RPMHPD_CX>,
+ <&rpmhpd RPMHPD_MX>;
+ power-domain-names = "venus",
+ "vcodec0",
+ "cx",
+ "mx";
+
+ resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>,
+ <&videocc VIDEO_CC_MVS0C_CLK_ARES>;
+ reset-names = "bus",
+ "core";
+
+ iris_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-240000000 {
+ opp-hz = /bits/ 64 <240000000>;
+ required-opps = <&rpmhpd_opp_low_svs>,
+ <&rpmhpd_opp_low_svs>;
+ };
+
+ opp-338000000 {
+ opp-hz = /bits/ 64 <338000000>;
+ required-opps = <&rpmhpd_opp_svs>,
+ <&rpmhpd_opp_svs>;
+ };
+
+ opp-366000000 {
+ opp-hz = /bits/ 64 <366000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>,
+ <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-444000000 {
+ opp-hz = /bits/ 64 <444000000>;
+ required-opps = <&rpmhpd_opp_nom>,
+ <&rpmhpd_opp_nom>;
+ };
+
+ opp-552000000 {
+ opp-hz = /bits/ 64 <552000000>;
+ required-opps = <&rpmhpd_opp_turbo>,
+ <&rpmhpd_opp_turbo>;
+ };
+ };
+ };
--
2.53.0
^ permalink raw reply related
* [PATCH 0/3] Add support for the Iris codec on Milos
From: Alexander Koskovich @ 2026-04-06 10:19 UTC (permalink / raw)
To: Vikash Garodia, Dikshita Agarwal, Abhinav Kumar,
Bryan O'Donoghue, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: Luca Weiss, linux-media, linux-arm-msm, devicetree, linux-kernel,
Alexander Koskovich
This series adds the bindings, nodes and platform data for the Milos platform
for the Iris video codec, allowing Milos to use hardware‑accelerated video
encoding and decoding.
Ran v4l2-compliance and some fluster tests, though a concerning amount of them
failed. Attaching v4l2-compliance output and the full fluster results below.
~ # v4l2-compliance -d /dev/video0
v4l2-compliance 1.32.0, 64 bits, 64-bit time_t
Compliance test for iris_driver device /dev/video0:
Driver Info:
Driver name : iris_driver
Card type : Iris Decoder
Bus info : platform:aa00000.video-codec
Driver version : 7.0.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Detected Stateful Decoder
Required ioctls:
test VIDIOC_QUERYCAP: OK
test invalid ioctls: OK
Allow for multiple opens:
test second /dev/video0 open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 10 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK
test Composing: OK
test Scaling: OK (Not Supported)
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test CREATE_BUFS maximum buffers: OK
test VIDIOC_REMOVE_BUFS: OK
test VIDIOC_EXPBUF: OK
test Requests: OK (Not Supported)
test blocking wait: OK
Total for iris_driver device /dev/video0: 48, Succeeded: 48, Failed: 0, Warnings: 0
~ # v4l2-compliance -d /dev/video1
v4l2-compliance 1.32.0, 64 bits, 64-bit time_t
Compliance test for iris_driver device /dev/video1:
Driver Info:
Driver name : iris_driver
Card type : Iris Encoder
Bus info : platform:aa00000.video-codec
Driver version : 7.0.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Detected Stateful Encoder
Required ioctls:
test VIDIOC_QUERYCAP: OK
test invalid ioctls: OK
Allow for multiple opens:
test second /dev/video1 open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 43 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK
test Composing: OK (Not Supported)
test Scaling: OK (Not Supported)
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test CREATE_BUFS maximum buffers: OK
test VIDIOC_REMOVE_BUFS: OK
test VIDIOC_EXPBUF: OK
test Requests: OK (Not Supported)
test blocking wait: OK
Total for iris_driver device /dev/video1: 48, Succeeded: 48, Failed: 0, Warnings: 0
-------------------------------
H264:
|Test|FFmpeg-H.264-v4l2m2m|
|-|-|
|TOTAL|36/135|
|TOTAL TIME|23.574s|
|-|-|
|AUD_MW_E|Pass|
|BA1_FT_C|Fail|
|BA1_Sony_D|Pass|
|BA2_Sony_F|Pass|
|BA3_SVA_C|Error|
|BA_MW_D|Fail|
|BAMQ1_JVC_C|Fail|
|BAMQ2_JVC_C|Fail|
|BANM_MW_D|Fail|
|BASQP1_Sony_C|Fail|
|CABA1_Sony_D|Fail|
|CABA1_SVA_B|Pass|
|CABA2_Sony_E|Pass|
|CABA2_SVA_B|Pass|
|CABA3_Sony_C|Fail|
|CABA3_SVA_B|Pass|
|CABA3_TOSHIBA_E|Fail|
|cabac_mot_fld0_full|Fail|
|cabac_mot_frm0_full|Pass|
|cabac_mot_mbaff0_full|Fail|
|cabac_mot_picaff0_full|Fail|
|CABACI3_Sony_B|Pass|
|CABAST3_Sony_E|Pass|
|CABASTBR3_Sony_B|Pass|
|CABREF3_Sand_D|Fail|
|CACQP3_Sony_D|Pass|
|CAFI1_SVA_C|Fail|
|CAMA1_Sony_C|Fail|
|CAMA1_TOSHIBA_B|Fail|
|cama1_vtc_c|Fail|
|cama2_vtc_b|Fail|
|CAMA3_Sand_E|Fail|
|cama3_vtc_b|Fail|
|CAMACI3_Sony_C|Fail|
|CAMANL1_TOSHIBA_B|Fail|
|CAMANL2_TOSHIBA_B|Fail|
|CAMANL3_Sand_E|Fail|
|CAMASL3_Sony_B|Fail|
|CAMP_MOT_MBAFF_L30|Fail|
|CAMP_MOT_MBAFF_L31|Fail|
|CANL1_Sony_E|Pass|
|CANL1_SVA_B|Pass|
|CANL1_TOSHIBA_G|Fail|
|CANL2_Sony_E|Fail|
|CANL2_SVA_B|Fail|
|CANL3_Sony_C|Fail|
|CANL3_SVA_B|Fail|
|CANL4_SVA_B|Fail|
|CANLMA2_Sony_C|Fail|
|CANLMA3_Sony_C|Fail|
|CAPA1_TOSHIBA_B|Fail|
|CAPAMA3_Sand_F|Fail|
|CAPCM1_Sand_E|Pass|
|CAPCMNL1_Sand_E|Fail|
|CAPM3_Sony_D|Fail|
|CAQP1_Sony_B|Pass|
|cavlc_mot_fld0_full_B|Fail|
|cavlc_mot_frm0_full_B|Pass|
|cavlc_mot_mbaff0_full_B|Fail|
|cavlc_mot_picaff0_full_B|Fail|
|CAWP1_TOSHIBA_E|Pass|
|CAWP5_TOSHIBA_E|Pass|
|CI1_FT_B|Pass|
|CI_MW_D|Pass|
|CVBS3_Sony_C|Pass|
|CVCANLMA2_Sony_C|Fail|
|CVFC1_Sony_C|Fail|
|CVFI1_Sony_D|Fail|
|CVFI1_SVA_C|Fail|
|CVFI2_Sony_H|Fail|
|CVFI2_SVA_C|Fail|
|CVMA1_Sony_D|Fail|
|CVMA1_TOSHIBA_B|Fail|
|CVMANL1_TOSHIBA_B|Fail|
|CVMANL2_TOSHIBA_B|Fail|
|CVMAPAQP3_Sony_E|Fail|
|CVMAQP2_Sony_G|Fail|
|CVMAQP3_Sony_D|Fail|
|CVMP_MOT_FLD_L30_B|Fail|
|CVMP_MOT_FRM_L31_B|Fail|
|CVNLFI1_Sony_C|Fail|
|CVNLFI2_Sony_H|Fail|
|CVPA1_TOSHIBA_B|Fail|
|CVPCMNL1_SVA_C|Fail|
|CVPCMNL2_SVA_C|Pass|
|CVSE2_Sony_B|Fail|
|CVSE3_Sony_H|Pass|
|CVSEFDFT3_Sony_E|Fail|
|CVWP1_TOSHIBA_E|Fail|
|CVWP2_TOSHIBA_E|Pass|
|CVWP3_TOSHIBA_E|Pass|
|CVWP5_TOSHIBA_E|Fail|
|FI1_Sony_E|Fail|
|FM1_BT_B|Error|
|FM1_FT_E|Error|
|FM2_SVA_C|Error|
|HCBP1_HHI_A|Pass|
|HCBP2_HHI_A|Fail|
|HCMP1_HHI_A|Fail|
|LS_SVA_D|Fail|
|MIDR_MW_D|Fail|
|MPS_MW_A|Pass|
|MR1_BT_A|Pass|
|MR1_MW_A|Fail|
|MR2_MW_A|Fail|
|MR2_TANDBERG_E|Pass|
|MR3_TANDBERG_B|Fail|
|MR4_TANDBERG_C|Fail|
|MR5_TANDBERG_C|Fail|
|MR6_BT_B|Error|
|MR7_BT_B|Error|
|MR8_BT_B|Error|
|MR9_BT_B|Fail|
|MV1_BRCM_D|Pass|
|NL1_Sony_D|Fail|
|NL2_Sony_H|Pass|
|NL3_SVA_E|Fail|
|NLMQ1_JVC_C|Fail|
|NLMQ2_JVC_C|Pass|
|NRF_MW_E|Fail|
|Sharp_MP_Field_1_B|Fail|
|Sharp_MP_Field_2_B|Fail|
|Sharp_MP_Field_3_B|Fail|
|Sharp_MP_PAFF_1r2|Fail|
|Sharp_MP_PAFF_2r|Fail|
|SL1_SVA_B|Pass|
|SP1_BT_A|Error|
|sp2_bt_b|Error|
|SVA_BA1_B|Pass|
|SVA_BA2_D|Pass|
|SVA_Base_B|Fail|
|SVA_CL1_E|Fail|
|SVA_FM1_E|Fail|
|SVA_NL1_B|Fail|
|SVA_NL2_E|Fail|
|-|-|
|Test|FFmpeg-H.264-v4l2m2m|
|TOTAL|36/135|
|TOTAL TIME|23.574s|
|-|-|
|Profile|FFmpeg-H.264-v4l2m2m|
|CONSTRAINED_BASELINE|12/33|
|BASELINE|1/7|
|EXTENDED|0/6|
|MAIN|23/89|
|TOTALS|FFmpeg-H.264-v4l2m2m|
|-|-|
|TOTAL|36/135|
|TOTAL TIME|23.574s|
|-|-|
|Profile|FFmpeg-H.264-v4l2m2m|
|BASELINE|1/7|
|CONSTRAINED_BASELINE|12/33|
|EXTENDED|0/6|
|MAIN|23/89|
|-|-|
-------------------------------
|Test|FFmpeg-H.265-v4l2m2m|
|-|-|
|TOTAL|109/147|
|TOTAL TIME|38.547s|
|-|-|
|AMP_A_Samsung_7|Pass|
|AMP_B_Samsung_7|Pass|
|AMP_D_Hisilicon_3|Pass|
|AMP_E_Hisilicon_3|Pass|
|AMP_F_Hisilicon_3|Pass|
|AMVP_A_MTK_4|Pass|
|AMVP_B_MTK_4|Fail|
|AMVP_C_Samsung_7|Pass|
|BUMPING_A_ericsson_1|Fail|
|CAINIT_A_SHARP_4|Pass|
|CAINIT_B_SHARP_4|Pass|
|CAINIT_C_SHARP_3|Pass|
|CAINIT_D_SHARP_3|Pass|
|CAINIT_E_SHARP_3|Pass|
|CAINIT_F_SHARP_3|Pass|
|CAINIT_G_SHARP_3|Pass|
|CAINIT_H_SHARP_3|Pass|
|CIP_A_Panasonic_3|Pass|
|cip_B_NEC_3|Pass|
|CIP_C_Panasonic_2|Pass|
|CONFWIN_A_Sony_1|Fail|
|DBLK_A_MAIN10_VIXS_4|Fail|
|DBLK_A_SONY_3|Pass|
|DBLK_B_SONY_3|Pass|
|DBLK_C_SONY_3|Pass|
|DBLK_D_VIXS_2|Pass|
|DBLK_E_VIXS_2|Pass|
|DBLK_F_VIXS_2|Pass|
|DBLK_G_VIXS_2|Pass|
|DELTAQP_A_BRCM_4|Pass|
|DELTAQP_B_SONY_3|Pass|
|DELTAQP_C_SONY_3|Pass|
|DSLICE_A_HHI_5|Pass|
|DSLICE_B_HHI_5|Pass|
|DSLICE_C_HHI_5|Pass|
|ENTP_A_QUALCOMM_1|Pass|
|ENTP_B_Qualcomm_1|Pass|
|ENTP_C_Qualcomm_1|Pass|
|EXT_A_ericsson_4|Pass|
|FILLER_A_Sony_1|Pass|
|HRD_A_Fujitsu_3|Pass|
|INITQP_A_Sony_1|Pass|
|INITQP_B_Main10_Sony_1|Fail|
|ipcm_A_NEC_3|Fail|
|ipcm_B_NEC_3|Pass|
|ipcm_C_NEC_3|Pass|
|ipcm_D_NEC_3|Pass|
|ipcm_E_NEC_2|Pass|
|IPRED_A_docomo_2|Pass|
|IPRED_B_Nokia_3|Pass|
|IPRED_C_Mitsubishi_3|Pass|
|LS_A_Orange_2|Pass|
|LS_B_Orange_4|Pass|
|LTRPSPS_A_Qualcomm_1|Fail|
|MAXBINS_A_TI_5|Pass|
|MAXBINS_B_TI_5|Pass|
|MAXBINS_C_TI_5|Pass|
|MERGE_A_TI_3|Pass|
|MERGE_B_TI_3|Pass|
|MERGE_C_TI_3|Fail|
|MERGE_D_TI_3|Fail|
|MERGE_E_TI_3|Pass|
|MERGE_F_MTK_4|Pass|
|MERGE_G_HHI_4|Pass|
|MVCLIP_A_qualcomm_3|Fail|
|MVDL1ZERO_A_docomo_4|Pass|
|MVEDGE_A_qualcomm_3|Fail|
|NoOutPrior_A_Qualcomm_1|Fail|
|NoOutPrior_B_Qualcomm_1|Fail|
|NUT_A_ericsson_5|Fail|
|OPFLAG_A_Qualcomm_1|Pass|
|OPFLAG_B_Qualcomm_1|Fail|
|OPFLAG_C_Qualcomm_1|Fail|
|PICSIZE_A_Bossen_1|Error|
|PICSIZE_B_Bossen_1|Error|
|PICSIZE_C_Bossen_1|Error|
|PICSIZE_D_Bossen_1|Error|
|PMERGE_A_TI_3|Pass|
|PMERGE_B_TI_3|Pass|
|PMERGE_C_TI_3|Pass|
|PMERGE_D_TI_3|Pass|
|PMERGE_E_TI_3|Pass|
|POC_A_Bossen_3|Pass|
|PPS_A_qualcomm_7|Pass|
|PS_B_VIDYO_3|Pass|
|RAP_A_docomo_6|Fail|
|RAP_B_Bossen_2|Fail|
|RPLM_A_qualcomm_4|Pass|
|RPLM_B_qualcomm_4|Pass|
|RPS_A_docomo_5|Pass|
|RPS_B_qualcomm_5|Pass|
|RPS_C_ericsson_5|Pass|
|RPS_D_ericsson_6|Pass|
|RPS_E_qualcomm_5|Pass|
|RPS_F_docomo_2|Pass|
|RQT_A_HHI_4|Pass|
|RQT_B_HHI_4|Pass|
|RQT_C_HHI_4|Pass|
|RQT_D_HHI_4|Pass|
|RQT_E_HHI_4|Pass|
|RQT_F_HHI_4|Pass|
|RQT_G_HHI_4|Pass|
|SAO_A_MediaTek_4|Fail|
|SAO_B_MediaTek_5|Pass|
|SAO_C_Samsung_5|Pass|
|SAO_D_Samsung_5|Pass|
|SAO_E_Canon_4|Pass|
|SAO_F_Canon_3|Pass|
|SAO_G_Canon_3|Pass|
|SAO_H_Parabola_1|Pass|
|SAODBLK_A_MainConcept_4|Pass|
|SAODBLK_B_MainConcept_4|Pass|
|SDH_A_Orange_4|Pass|
|SLICES_A_Rovi_3|Pass|
|SLIST_A_Sony_5|Pass|
|SLIST_B_Sony_9|Pass|
|SLIST_C_Sony_4|Pass|
|SLIST_D_Sony_9|Pass|
|SLPPLP_A_VIDYO_2|Pass|
|STRUCT_A_Samsung_7|Pass|
|STRUCT_B_Samsung_7|Pass|
|TILES_A_Cisco_2|Pass|
|TILES_B_Cisco_1|Pass|
|TMVP_A_MS_3|Pass|
|TSCL_A_VIDYO_5|Fail|
|TSCL_B_VIDYO_4|Pass|
|TSKIP_A_MS_3|Pass|
|TSUNEQBD_A_MAIN10_Technicolor_2|Error|
|TUSIZE_A_Samsung_1|Pass|
|VPSID_A_VIDYO_2|Pass|
|VPSSPSPPS_A_MainConcept_1|Fail|
|WP_A_MAIN10_Toshiba_3|Fail|
|WP_A_Toshiba_3|Pass|
|WP_B_Toshiba_3|Pass|
|WP_MAIN10_B_Toshiba_3|Fail|
|WPP_A_ericsson_MAIN10_2|Fail|
|WPP_A_ericsson_MAIN_2|Pass|
|WPP_B_ericsson_MAIN10_2|Fail|
|WPP_B_ericsson_MAIN_2|Fail|
|WPP_C_ericsson_MAIN10_2|Fail|
|WPP_C_ericsson_MAIN_2|Fail|
|WPP_D_ericsson_MAIN10_2|Error|
|WPP_D_ericsson_MAIN_2|Error|
|WPP_E_ericsson_MAIN10_2|Fail|
|WPP_E_ericsson_MAIN_2|Fail|
|WPP_F_ericsson_MAIN10_2|Fail|
|WPP_F_ericsson_MAIN_2|Pass|
|-|-|
|Test|FFmpeg-H.265-v4l2m2m|
|TOTAL|109/147|
|TOTAL TIME|38.547s|
|-|-|
|Profile|FFmpeg-H.265-v4l2m2m|
|MAIN|108/135|
|MAIN_10|0/11|
|MAIN_STILL_PICTURE|1/1|
|TOTALS|FFmpeg-H.265-v4l2m2m|
|-|-|
|TOTAL|109/147|
|TOTAL TIME|38.547s|
|-|-|
|Profile|FFmpeg-H.265-v4l2m2m|
|MAIN|108/135|
|MAIN_10|0/11|
|MAIN_STILL_PICTURE|1/1|
|-|-|
-------------------------------
|Test|FFmpeg-VP9-v4l2m2m|
|-|-|
|TOTAL|111/305|
|TOTAL TIME|77.260s|
|-|-|
|vp90-2-00-quantizer-00.webm|Pass|
|vp90-2-00-quantizer-01.webm|Pass|
|vp90-2-00-quantizer-02.webm|Pass|
|vp90-2-00-quantizer-03.webm|Fail|
|vp90-2-00-quantizer-04.webm|Fail|
|vp90-2-00-quantizer-05.webm|Pass|
|vp90-2-00-quantizer-06.webm|Pass|
|vp90-2-00-quantizer-07.webm|Pass|
|vp90-2-00-quantizer-08.webm|Fail|
|vp90-2-00-quantizer-09.webm|Pass|
|vp90-2-00-quantizer-10.webm|Pass|
|vp90-2-00-quantizer-11.webm|Pass|
|vp90-2-00-quantizer-12.webm|Pass|
|vp90-2-00-quantizer-13.webm|Pass|
|vp90-2-00-quantizer-14.webm|Pass|
|vp90-2-00-quantizer-15.webm|Pass|
|vp90-2-00-quantizer-16.webm|Fail|
|vp90-2-00-quantizer-17.webm|Pass|
|vp90-2-00-quantizer-18.webm|Pass|
|vp90-2-00-quantizer-19.webm|Pass|
|vp90-2-00-quantizer-20.webm|Pass|
|vp90-2-00-quantizer-21.webm|Pass|
|vp90-2-00-quantizer-22.webm|Pass|
|vp90-2-00-quantizer-23.webm|Pass|
|vp90-2-00-quantizer-24.webm|Pass|
|vp90-2-00-quantizer-25.webm|Fail|
|vp90-2-00-quantizer-26.webm|Fail|
|vp90-2-00-quantizer-27.webm|Pass|
|vp90-2-00-quantizer-28.webm|Pass|
|vp90-2-00-quantizer-29.webm|Fail|
|vp90-2-00-quantizer-30.webm|Pass|
|vp90-2-00-quantizer-31.webm|Pass|
|vp90-2-00-quantizer-32.webm|Fail|
|vp90-2-00-quantizer-33.webm|Pass|
|vp90-2-00-quantizer-34.webm|Pass|
|vp90-2-00-quantizer-35.webm|Pass|
|vp90-2-00-quantizer-36.webm|Pass|
|vp90-2-00-quantizer-37.webm|Pass|
|vp90-2-00-quantizer-38.webm|Pass|
|vp90-2-00-quantizer-39.webm|Pass|
|vp90-2-00-quantizer-40.webm|Pass|
|vp90-2-00-quantizer-41.webm|Pass|
|vp90-2-00-quantizer-42.webm|Pass|
|vp90-2-00-quantizer-43.webm|Pass|
|vp90-2-00-quantizer-44.webm|Fail|
|vp90-2-00-quantizer-45.webm|Pass|
|vp90-2-00-quantizer-46.webm|Pass|
|vp90-2-00-quantizer-47.webm|Pass|
|vp90-2-00-quantizer-48.webm|Pass|
|vp90-2-00-quantizer-49.webm|Pass|
|vp90-2-00-quantizer-50.webm|Fail|
|vp90-2-00-quantizer-51.webm|Pass|
|vp90-2-00-quantizer-52.webm|Pass|
|vp90-2-00-quantizer-53.webm|Pass|
|vp90-2-00-quantizer-54.webm|Pass|
|vp90-2-00-quantizer-55.webm|Pass|
|vp90-2-00-quantizer-56.webm|Pass|
|vp90-2-00-quantizer-57.webm|Pass|
|vp90-2-00-quantizer-58.webm|Pass|
|vp90-2-00-quantizer-59.webm|Fail|
|vp90-2-00-quantizer-60.webm|Pass|
|vp90-2-00-quantizer-61.webm|Pass|
|vp90-2-00-quantizer-62.webm|Pass|
|vp90-2-00-quantizer-63.webm|Fail|
|vp90-2-01-sharpness-1.webm|Pass|
|vp90-2-01-sharpness-2.webm|Pass|
|vp90-2-01-sharpness-3.webm|Pass|
|vp90-2-01-sharpness-4.webm|Pass|
|vp90-2-01-sharpness-5.webm|Pass|
|vp90-2-01-sharpness-6.webm|Pass|
|vp90-2-01-sharpness-7.webm|Pass|
|vp90-2-02-size-08x08.webm|Error|
|vp90-2-02-size-08x10.webm|Error|
|vp90-2-02-size-08x16.webm|Error|
|vp90-2-02-size-08x18.webm|Error|
|vp90-2-02-size-08x32.webm|Error|
|vp90-2-02-size-08x34.webm|Error|
|vp90-2-02-size-08x64.webm|Error|
|vp90-2-02-size-08x66.webm|Error|
|vp90-2-02-size-10x08.webm|Error|
|vp90-2-02-size-10x10.webm|Error|
|vp90-2-02-size-10x16.webm|Error|
|vp90-2-02-size-10x18.webm|Error|
|vp90-2-02-size-10x32.webm|Error|
|vp90-2-02-size-10x34.webm|Error|
|vp90-2-02-size-10x64.webm|Error|
|vp90-2-02-size-10x66.webm|Error|
|vp90-2-02-size-130x132.webm|Fail|
|vp90-2-02-size-132x130.webm|Pass|
|vp90-2-02-size-132x132.webm|Pass|
|vp90-2-02-size-16x08.webm|Error|
|vp90-2-02-size-16x10.webm|Error|
|vp90-2-02-size-16x16.webm|Error|
|vp90-2-02-size-16x18.webm|Error|
|vp90-2-02-size-16x32.webm|Error|
|vp90-2-02-size-16x34.webm|Error|
|vp90-2-02-size-16x64.webm|Error|
|vp90-2-02-size-16x66.webm|Error|
|vp90-2-02-size-178x180.webm|Fail|
|vp90-2-02-size-180x178.webm|Pass|
|vp90-2-02-size-180x180.webm|Fail|
|vp90-2-02-size-18x08.webm|Error|
|vp90-2-02-size-18x10.webm|Error|
|vp90-2-02-size-18x16.webm|Error|
|vp90-2-02-size-18x18.webm|Error|
|vp90-2-02-size-18x32.webm|Error|
|vp90-2-02-size-18x34.webm|Error|
|vp90-2-02-size-18x64.webm|Error|
|vp90-2-02-size-18x66.webm|Error|
|vp90-2-02-size-32x08.webm|Error|
|vp90-2-02-size-32x10.webm|Error|
|vp90-2-02-size-32x16.webm|Error|
|vp90-2-02-size-32x18.webm|Error|
|vp90-2-02-size-32x32.webm|Error|
|vp90-2-02-size-32x34.webm|Error|
|vp90-2-02-size-32x64.webm|Error|
|vp90-2-02-size-32x66.webm|Error|
|vp90-2-02-size-34x08.webm|Error|
|vp90-2-02-size-34x10.webm|Error|
|vp90-2-02-size-34x16.webm|Error|
|vp90-2-02-size-34x18.webm|Error|
|vp90-2-02-size-34x32.webm|Error|
|vp90-2-02-size-34x34.webm|Error|
|vp90-2-02-size-34x64.webm|Error|
|vp90-2-02-size-34x66.webm|Error|
|vp90-2-02-size-64x08.webm|Error|
|vp90-2-02-size-64x10.webm|Error|
|vp90-2-02-size-64x16.webm|Error|
|vp90-2-02-size-64x18.webm|Error|
|vp90-2-02-size-64x32.webm|Error|
|vp90-2-02-size-64x34.webm|Error|
|vp90-2-02-size-64x64.webm|Error|
|vp90-2-02-size-64x66.webm|Error|
|vp90-2-02-size-66x08.webm|Error|
|vp90-2-02-size-66x10.webm|Error|
|vp90-2-02-size-66x16.webm|Error|
|vp90-2-02-size-66x18.webm|Error|
|vp90-2-02-size-66x32.webm|Error|
|vp90-2-02-size-66x34.webm|Error|
|vp90-2-02-size-66x64.webm|Error|
|vp90-2-02-size-66x66.webm|Error|
|vp90-2-02-size-lf-1920x1080.webm|Fail|
|vp90-2-03-deltaq.webm|Fail|
|vp90-2-03-size-196x196.webm|Pass|
|vp90-2-03-size-196x198.webm|Pass|
|vp90-2-03-size-196x200.webm|Pass|
|vp90-2-03-size-196x202.webm|Pass|
|vp90-2-03-size-196x208.webm|Fail|
|vp90-2-03-size-196x210.webm|Fail|
|vp90-2-03-size-196x224.webm|Pass|
|vp90-2-03-size-196x226.webm|Fail|
|vp90-2-03-size-198x196.webm|Fail|
|vp90-2-03-size-198x198.webm|Pass|
|vp90-2-03-size-198x200.webm|Pass|
|vp90-2-03-size-198x202.webm|Pass|
|vp90-2-03-size-198x208.webm|Pass|
|vp90-2-03-size-198x210.webm|Fail|
|vp90-2-03-size-198x224.webm|Pass|
|vp90-2-03-size-198x226.webm|Fail|
|vp90-2-03-size-200x196.webm|Fail|
|vp90-2-03-size-200x198.webm|Fail|
|vp90-2-03-size-200x200.webm|Fail|
|vp90-2-03-size-200x202.webm|Pass|
|vp90-2-03-size-200x208.webm|Fail|
|vp90-2-03-size-200x210.webm|Fail|
|vp90-2-03-size-200x224.webm|Pass|
|vp90-2-03-size-200x226.webm|Fail|
|vp90-2-03-size-202x196.webm|Fail|
|vp90-2-03-size-202x198.webm|Fail|
|vp90-2-03-size-202x200.webm|Fail|
|vp90-2-03-size-202x202.webm|Fail|
|vp90-2-03-size-202x208.webm|Pass|
|vp90-2-03-size-202x210.webm|Fail|
|vp90-2-03-size-202x224.webm|Fail|
|vp90-2-03-size-202x226.webm|Pass|
|vp90-2-03-size-208x196.webm|Pass|
|vp90-2-03-size-208x198.webm|Pass|
|vp90-2-03-size-208x200.webm|Pass|
|vp90-2-03-size-208x202.webm|Pass|
|vp90-2-03-size-208x208.webm|Pass|
|vp90-2-03-size-208x210.webm|Pass|
|vp90-2-03-size-208x224.webm|Pass|
|vp90-2-03-size-208x226.webm|Pass|
|vp90-2-03-size-210x196.webm|Pass|
|vp90-2-03-size-210x198.webm|Pass|
|vp90-2-03-size-210x200.webm|Fail|
|vp90-2-03-size-210x202.webm|Pass|
|vp90-2-03-size-210x208.webm|Pass|
|vp90-2-03-size-210x210.webm|Fail|
|vp90-2-03-size-210x224.webm|Pass|
|vp90-2-03-size-210x226.webm|Fail|
|vp90-2-03-size-224x196.webm|Fail|
|vp90-2-03-size-224x198.webm|Pass|
|vp90-2-03-size-224x200.webm|Pass|
|vp90-2-03-size-224x202.webm|Fail|
|vp90-2-03-size-224x208.webm|Pass|
|vp90-2-03-size-224x210.webm|Fail|
|vp90-2-03-size-224x224.webm|Pass|
|vp90-2-03-size-224x226.webm|Pass|
|vp90-2-03-size-226x196.webm|Pass|
|vp90-2-03-size-226x198.webm|Fail|
|vp90-2-03-size-226x200.webm|Fail|
|vp90-2-03-size-226x202.webm|Fail|
|vp90-2-03-size-226x208.webm|Pass|
|vp90-2-03-size-226x210.webm|Pass|
|vp90-2-03-size-226x224.webm|Fail|
|vp90-2-03-size-226x226.webm|Fail|
|vp90-2-03-size-352x288.webm|Pass|
|vp90-2-05-resize.ivf|Fail|
|vp90-2-06-bilinear.webm|Pass|
|vp90-2-07-frame_parallel-1.webm|Pass|
|vp90-2-07-frame_parallel.webm|Fail|
|vp90-2-08-tile_1x2_frame_parallel.webm|Fail|
|vp90-2-08-tile_1x2.webm|Fail|
|vp90-2-08-tile_1x4_frame_parallel.webm|Fail|
|vp90-2-08-tile_1x4.webm|Fail|
|vp90-2-08-tile_1x8_frame_parallel.webm|Pass|
|vp90-2-08-tile_1x8.webm|Pass|
|vp90-2-08-tile-4x1.webm|Pass|
|vp90-2-08-tile-4x4.webm|Pass|
|vp90-2-09-aq2.webm|Fail|
|vp90-2-09-lf_deltas.webm|Fail|
|vp90-2-09-subpixel-00.ivf|Fail|
|vp90-2-10-show-existing-frame2.webm|Fail|
|vp90-2-10-show-existing-frame.webm|Fail|
|vp90-2-11-size-351x287.webm|Fail|
|vp90-2-11-size-351x288.webm|Fail|
|vp90-2-11-size-352x287.webm|Fail|
|vp90-2-12-droppable_1.ivf|Pass|
|vp90-2-12-droppable_2.ivf|Pass|
|vp90-2-12-droppable_3.ivf|Pass|
|vp90-2-14-resize-10frames-fp-tiles-1-2-4-8.webm|Timeout|
|vp90-2-14-resize-10frames-fp-tiles-1-2.webm|Timeout|
|vp90-2-14-resize-10frames-fp-tiles-1-4.webm|Fail|
|vp90-2-14-resize-10frames-fp-tiles-1-8.webm|Fail|
|vp90-2-14-resize-10frames-fp-tiles-2-1.webm|Timeout|
|vp90-2-14-resize-10frames-fp-tiles-2-4.webm|Timeout|
|vp90-2-14-resize-10frames-fp-tiles-2-8.webm|Timeout|
|vp90-2-14-resize-10frames-fp-tiles-4-1.webm|Timeout|
|vp90-2-14-resize-10frames-fp-tiles-4-2.webm|Timeout|
|vp90-2-14-resize-10frames-fp-tiles-4-8.webm|Timeout|
|vp90-2-14-resize-10frames-fp-tiles-8-1.webm|Timeout|
|vp90-2-14-resize-10frames-fp-tiles-8-2.webm|Timeout|
|vp90-2-14-resize-10frames-fp-tiles-8-4-2-1.webm|Timeout|
|vp90-2-14-resize-10frames-fp-tiles-8-4.webm|Timeout|
|vp90-2-14-resize-fp-tiles-1-16.webm|Fail|
|vp90-2-14-resize-fp-tiles-1-2-4-8-16.webm|Timeout|
|vp90-2-14-resize-fp-tiles-1-2.webm|Fail|
|vp90-2-14-resize-fp-tiles-1-4.webm|Timeout|
|vp90-2-14-resize-fp-tiles-16-1.webm|Error|
|vp90-2-14-resize-fp-tiles-16-2.webm|Error|
|vp90-2-14-resize-fp-tiles-16-4.webm|Error|
|vp90-2-14-resize-fp-tiles-16-8-4-2-1.webm|Error|
|vp90-2-14-resize-fp-tiles-16-8.webm|Error|
|vp90-2-14-resize-fp-tiles-1-8.webm|Fail|
|vp90-2-14-resize-fp-tiles-2-16.webm|Error|
|vp90-2-14-resize-fp-tiles-2-1.webm|Fail|
|vp90-2-14-resize-fp-tiles-2-4.webm|Fail|
|vp90-2-14-resize-fp-tiles-2-8.webm|Timeout|
|vp90-2-14-resize-fp-tiles-4-16.webm|Error|
|vp90-2-14-resize-fp-tiles-4-1.webm|Timeout|
|vp90-2-14-resize-fp-tiles-4-2.webm|Timeout|
|vp90-2-14-resize-fp-tiles-4-8.webm|Fail|
|vp90-2-14-resize-fp-tiles-8-16.webm|Error|
|vp90-2-14-resize-fp-tiles-8-1.webm|Timeout|
|vp90-2-14-resize-fp-tiles-8-2.webm|Timeout|
|vp90-2-14-resize-fp-tiles-8-4.webm|Timeout|
|vp90-2-15-segkey_adpq.webm|Fail|
|vp90-2-15-segkey.webm|Pass|
|vp90-2-16-intra-only.webm|Fail|
|vp90-2-17-show-existing-frame.webm|Pass|
|vp90-2-18-resize.ivf|Fail|
|vp90-2-19-skip-01.webm|Fail|
|vp90-2-19-skip-02.webm|Fail|
|vp90-2-19-skip.webm|Pass|
|vp90-2-20-big_superframe-01.webm|Fail|
|vp90-2-20-big_superframe-02.webm|Fail|
|vp90-2-21-resize_inter_1280x720_5_1-2.webm|Timeout|
|vp90-2-21-resize_inter_1280x720_5_3-4.webm|Timeout|
|vp90-2-21-resize_inter_1280x720_7_1-2.webm|Fail|
|vp90-2-21-resize_inter_1280x720_7_3-4.webm|Timeout|
|vp90-2-21-resize_inter_1920x1080_5_1-2.webm|Timeout|
|vp90-2-21-resize_inter_1920x1080_5_3-4.webm|Timeout|
|vp90-2-21-resize_inter_1920x1080_7_1-2.webm|Timeout|
|vp90-2-21-resize_inter_1920x1080_7_3-4.webm|Timeout|
|vp90-2-21-resize_inter_320x180_5_1-2.webm|Fail|
|vp90-2-21-resize_inter_320x180_5_3-4.webm|Fail|
|vp90-2-21-resize_inter_320x180_7_1-2.webm|Fail|
|vp90-2-21-resize_inter_320x180_7_3-4.webm|Fail|
|vp90-2-21-resize_inter_320x240_5_1-2.webm|Timeout|
|vp90-2-21-resize_inter_320x240_5_3-4.webm|Fail|
|vp90-2-21-resize_inter_320x240_7_1-2.webm|Fail|
|vp90-2-21-resize_inter_320x240_7_3-4.webm|Timeout|
|vp90-2-21-resize_inter_640x360_5_1-2.webm|Fail|
|vp90-2-21-resize_inter_640x360_5_3-4.webm|Timeout|
|vp90-2-21-resize_inter_640x360_7_1-2.webm|Fail|
|vp90-2-21-resize_inter_640x360_7_3-4.webm|Fail|
|vp90-2-21-resize_inter_640x480_5_1-2.webm|Timeout|
|vp90-2-21-resize_inter_640x480_5_3-4.webm|Fail|
|vp90-2-21-resize_inter_640x480_7_1-2.webm|Timeout|
|vp90-2-21-resize_inter_640x480_7_3-4.webm|Timeout|
|vp90-2-22-svc_1280x720_1.webm|Pass|
|vp90-2-22-svc_1280x720_3.ivf|Timeout|
|vp91-2-04-yuv422.webm|Error|
|vp91-2-04-yuv444.webm|Error|
|-|-|
|Test|FFmpeg-VP9-v4l2m2m|
|TOTAL|111/305|
|TOTAL TIME|77.260s|
|TOTALS|FFmpeg-VP9-v4l2m2m|
|-|-|
|TOTAL|111/305|
|TOTAL TIME|77.260s|
|-|-|
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
---
Alexander Koskovich (3):
dt-bindings: media: qcom,milos-iris: Add Milos video codec
media: iris: Add support for Milos (VPU v2.0)
arm64: dts: qcom: milos: Add Iris VPU v2.0
.../devicetree/bindings/media/qcom,milos-iris.yaml | 166 ++++++
arch/arm64/boot/dts/qcom/milos.dtsi | 85 +++
.../platform/qcom/iris/iris_platform_common.h | 1 +
.../media/platform/qcom/iris/iris_platform_gen2.c | 106 ++++
.../media/platform/qcom/iris/iris_platform_milos.h | 655 +++++++++++++++++++++
drivers/media/platform/qcom/iris/iris_probe.c | 4 +
6 files changed, 1017 insertions(+)
---
base-commit: 591cd656a1bf5ea94a222af5ef2ee76df029c1d2
change-id: 20260406-milos-iris-d1a854e4cb75
Best regards,
--
Alexander Koskovich <akoskovich@pm.me>
^ permalink raw reply
* [PATCH v3 2/2] hwmon:(pmbus/xdp720) Add support for efuse xdp720
From: ASHISH YADAV @ 2026-04-06 10:16 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel, Ashish Yadav
In-Reply-To: <20260406101647.109667-1-Ashish.Yadav@infineon.com>
From: Ashish Yadav <ashish.yadav@infineon.com>
Add the pmbus driver for Infineon XDP720 Digital eFuse Controller.
Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com>
---
XDP720 Digital eFuse Controller provides accurate system telemetry
(V, I, P, T) and reports analog current at the IMON pin for post-processing.
The Current and Power measurement depends on the RIMON and GIMON values.
Please look into data sheet sections 5.4.2 and 5.4.4 for more details:
https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp720-001-datasheet-en.pdf
The GIMON (microA/A) depends on the 10th bit of TELEMETRY_AVG PMBUS Register.
The value of RIMON (kohm) can be provided by the user through device tree using
infineon,rimon-micro-ohms property.
---
drivers/hwmon/pmbus/Kconfig | 9 +++
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/xdp720.c | 128 +++++++++++++++++++++++++++++++++++
3 files changed, 138 insertions(+)
create mode 100644 drivers/hwmon/pmbus/xdp720.c
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index fc1273abe357..c419e3ecce90 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -702,6 +702,15 @@ config SENSORS_XDP710
This driver can also be built as a module. If so, the module will
be called xdp710.
+config SENSORS_XDP720
+ tristate "Infineon XDP720 family"
+ help
+ If you say yes here you get hardware monitoring support for Infineon
+ XDP720.
+
+ This driver can also be built as a module. If so, the module will
+ be called xdp720.
+
config SENSORS_XDPE152
tristate "Infineon XDPE152 family"
help
diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
index d6c86924f887..1cac7ccae79f 100644
--- a/drivers/hwmon/pmbus/Makefile
+++ b/drivers/hwmon/pmbus/Makefile
@@ -68,6 +68,7 @@ obj-$(CONFIG_SENSORS_TPS546D24) += tps546d24.o
obj-$(CONFIG_SENSORS_UCD9000) += ucd9000.o
obj-$(CONFIG_SENSORS_UCD9200) += ucd9200.o
obj-$(CONFIG_SENSORS_XDP710) += xdp710.o
+obj-$(CONFIG_SENSORS_XDP720) += xdp720.o
obj-$(CONFIG_SENSORS_XDPE122) += xdpe12284.o
obj-$(CONFIG_SENSORS_XDPE152) += xdpe152c4.o
obj-$(CONFIG_SENSORS_ZL6100) += zl6100.o
diff --git a/drivers/hwmon/pmbus/xdp720.c b/drivers/hwmon/pmbus/xdp720.c
new file mode 100644
index 000000000000..8729a771f216
--- /dev/null
+++ b/drivers/hwmon/pmbus/xdp720.c
@@ -0,0 +1,128 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Hardware monitoring driver for Infineon XDP720 Digital eFuse Controller
+ *
+ * Copyright (c) 2026 Infineon Technologies. All rights reserved.
+ */
+
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/of_device.h>
+#include <linux/bitops.h>
+#include <linux/math64.h>
+#include "pmbus.h"
+
+/*
+ * The IMON resistor required to generate the system overcurrent protection.
+ * Arbitrary default Rimon value: 2k Ohm
+ */
+#define XDP720_DEFAULT_RIMON 2000000000 /* 2k ohm */
+#define XDP720_TELEMETRY_AVG 0xE9
+
+static struct pmbus_driver_info xdp720_info = {
+ .pages = 1,
+ .format[PSC_VOLTAGE_IN] = direct,
+ .format[PSC_VOLTAGE_OUT] = direct,
+ .format[PSC_CURRENT_OUT] = direct,
+ .format[PSC_POWER] = direct,
+ .format[PSC_TEMPERATURE] = direct,
+
+ .m[PSC_VOLTAGE_IN] = 4653,
+ .b[PSC_VOLTAGE_IN] = 0,
+ .R[PSC_VOLTAGE_IN] = -2,
+ .m[PSC_VOLTAGE_OUT] = 4653,
+ .b[PSC_VOLTAGE_OUT] = 0,
+ .R[PSC_VOLTAGE_OUT] = -2,
+ /*
+ * Current and Power measurement depends on the RIMON (kOhm) and
+ * GIMON(microA/A) values.
+ */
+ .m[PSC_CURRENT_OUT] = 24668,
+ .b[PSC_CURRENT_OUT] = 0,
+ .R[PSC_CURRENT_OUT] = -4,
+ .m[PSC_POWER] = 4486,
+ .b[PSC_POWER] = 0,
+ .R[PSC_POWER] = -1,
+ .m[PSC_TEMPERATURE] = 54,
+ .b[PSC_TEMPERATURE] = 22521,
+ .R[PSC_TEMPERATURE] = -1,
+
+ .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_VOUT | PMBUS_HAVE_PIN |
+ PMBUS_HAVE_TEMP | PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_INPUT |
+ PMBUS_HAVE_STATUS_TEMP,
+};
+
+static int xdp720_probe(struct i2c_client *client)
+{
+ struct pmbus_driver_info *info;
+ int ret;
+ u32 rimon;
+ int gimon;
+
+ info = devm_kmemdup(&client->dev, &xdp720_info, sizeof(*info),
+ GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+
+ ret = devm_regulator_get_enable(&client->dev, "vdd-vin");
+ if (ret)
+ return dev_err_probe(&client->dev, ret,
+ "failed to enable vdd-vin supply\n");
+
+ ret = i2c_smbus_read_word_data(client, XDP720_TELEMETRY_AVG);
+ if (ret < 0) {
+ dev_err(&client->dev, "Can't get TELEMETRY_AVG\n");
+ return ret;
+ }
+
+ ret >>= 10; /* 10th bit of TELEMETRY_AVG REG for GIMON Value */
+ ret &= GENMASK(0, 0);
+ if (ret == 1)
+ gimon = 18200; /* output gain 18.2 microA/A */
+ else
+ gimon = 9100; /* output gain 9.1 microA/A */
+
+ if (of_property_read_u32(client->dev.of_node,
+ "infineon,rimon-micro-ohms", &rimon))
+ rimon = XDP720_DEFAULT_RIMON; /* Default if not set via DT */
+ if (rimon == 0)
+ return -EINVAL;
+
+ /* Adapt the current and power scale for each instance */
+ info->m[PSC_CURRENT_OUT] = DIV64_U64_ROUND_CLOSEST((u64)
+ info->m[PSC_CURRENT_OUT] * rimon * gimon, 1000000000000ULL);
+ info->m[PSC_POWER] = DIV64_U64_ROUND_CLOSEST((u64)
+ info->m[PSC_POWER] * rimon * gimon, 1000000000000000ULL);
+
+ return pmbus_do_probe(client, info);
+}
+
+static const struct of_device_id xdp720_of_match[] = {
+ { .compatible = "infineon,xdp720" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, xdp720_of_match);
+
+static const struct i2c_device_id xdp720_id[] = {
+ { "xdp720" },
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, xdp720_id);
+
+static struct i2c_driver xdp720_driver = {
+ .driver = {
+ .name = "xdp720",
+ .of_match_table = xdp720_of_match,
+ },
+ .probe = xdp720_probe,
+ .id_table = xdp720_id,
+};
+
+module_i2c_driver(xdp720_driver);
+
+MODULE_AUTHOR("Ashish Yadav <ashish.yadav@infineon.com>");
+MODULE_DESCRIPTION("PMBus driver for Infineon XDP720 Digital eFuse Controller");
+MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("PMBUS");
--
2.39.5
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: hwmon/pmbus: Add Infineon XDP720
From: ASHISH YADAV @ 2026-04-06 10:16 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel, Ashish Yadav
In-Reply-To: <20260406101647.109667-1-Ashish.Yadav@infineon.com>
From: Ashish Yadav <ashish.yadav@infineon.com>
Add documentation for the device tree binding of the XDP720 eFuse.
This patch introduces a YAML schema describing the required and optional
properties for the XDP720 eFuse device node. It includes details on the
compatible string, register mapping,supply and rimon-micro-ohms(RIMON).
Signed-off-by: Ashish Yadav <ashish.yadav@infineon.com>
---
.../bindings/hwmon/pmbus/infineon,xdp720.yaml | 59 +++++++++++++++++++
1 file changed, 59 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
new file mode 100644
index 000000000000..72bc3a5e7139
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
@@ -0,0 +1,59 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+
+$id: http://devicetree.org/schemas/hwmon/pmbus/infineon,xdp720.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Infineon XDP720 Digital eFuse Controller
+
+maintainers:
+ - Ashish Yadav <ashish.yadav@infineon.com>
+
+description: |
+ The XDP720 is an eFuse with integrated current sensor and digital
+ controller. It provides accurate system telemetry (V, I, P, T) and
+ reports analog current at the IMON pin for post-processing.
+
+ Datasheet:
+ https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp720-001-datasheet-en.pdf
+
+properties:
+ compatible:
+ enum:
+ - infineon,xdp720
+
+ reg:
+ maxItems: 1
+
+ infineon,rimon-micro-ohms:
+ description:
+ The value of the RIMON resistor, in micro ohms, required to enable
+ the system overcurrent protection.
+
+ vdd-vin-supply:
+ description:
+ Supply for the VDD_VIN pin (pin 9), the IC controller power supply.
+ Typically connected to the input bus (VIN) through a 100 ohm / 100 nF
+ RC filter.
+
+required:
+ - compatible
+ - reg
+ - vdd-vin-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hwmon@11 {
+ compatible = "infineon,xdp720";
+ reg = <0x11>;
+ vdd-vin-supply = <&vdd_vin>;
+ infineon,rimon-micro-ohms = <1098000000>; /* 1.098k ohm */
+ };
+ };
--
2.39.5
^ permalink raw reply related
* [PATCH v3 0/2] Add support for Infineon Digital eFuse XDP720
From: ASHISH YADAV @ 2026-04-06 10:16 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel, Ashish Yadav
From: Ashish Yadav <ashish.yadav@infineon.com>
Hi,
These patches add support for Infineon Digital eFuse XDP720.
XDP720 provides accurate system telemetry (V, I, P, T) and
reports analog current at the IMON pin for post-processing.
The Current and Power measurement depends on the RIMON and GIMON values.
Please look into data sheet sections 5.4.2 and 5.4.4 for more details:
https://www.infineon.com/assets/row/public/documents/24/49/infineon-xdp720-001-datasheet-en.pdf
With Best Regards,
Ashish Yadav
---
Changes in v3:
- Link to v2:
https://lore.kernel.org/all/20260401104550.115715-1-Ashish.Yadav@infineon.com/
- Fix commit msg, added missing supply info in devicetree binding document.
https://lore.kernel.org/all/20260402-enlightened-analytic-leopard-ddc512@quoll/
- Fix .m[PSC_POWER] value issue.The divisor value is 10^15 rather than 10^12.
https://lore.kernel.org/all/258dd77a-a8d9-4540-a32a-91a3f13c6ed5@roeck-us.net/
Changes in v2:
- Link to v1:
https://lore.kernel.org/all/20260330102345.37065-1-Ashish.Yadav@infineon.com/
- Fix make dt_binding_check issue:
https://patchwork.kernel.org/project/devicetree/patch/20260330102345.37065-2-Ashish.Yadav@infineon.com/
- Address reviews comments for infineon,xdp720.yaml, Kconfig, Makefile and xpe720.c:
https://sashiko.dev/#/patchset/20260330102345.37065-1-Ashish.Yadav%40infineon.com
It includes fixing of extra space, non-ASCII characters and use spaces
instead of tabs.
The xpe720.c driver file update with DIV64_U64_ROUND_CLOSEST() and
MODULE_DEVICE_TABLE() as suggested in review comments.
Ashish Yadav (2):
dt-bindings: hwmon/pmbus: Add Infineon XDP720
hwmon:(pmbus/xdp720) Add support for efuse xdp720
.../bindings/hwmon/pmbus/infineon,xdp720.yaml | 59 ++++++++
drivers/hwmon/pmbus/Kconfig | 9 ++
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/xdp720.c | 128 ++++++++++++++++++
4 files changed, 197 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/infineon,xdp720.yaml
create mode 100644 drivers/hwmon/pmbus/xdp720.c
--
2.39.5
^ permalink raw reply
* Re: [PATCH v2] ASoC: codecs: wcd937x: Add conditional regulator control for wcd937x
From: Karthik S @ 2026-04-06 9:58 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Liam Girdwood, Mark Brown, Conor Dooley, Krzysztof Kozlowski,
linux-kernel, Takashi Iwai, linux-sound, linux-arm-msm,
Srinivas Kandagatla, devicetree, Jaroslav Kysela
In-Reply-To: <177511857667.2917822.6371182180784837499.robh@kernel.org>
Hi Rob,
Yes, I was able to run the script as you suggested and find the error
indicated. To address the error I have removed 'type' from the
dt-binding property "qcom,always-on-supply".
Thanks and Regards,
Karthik S
On 4/2/2026 1:59 PM, Rob Herring (Arm) wrote:
> My bot found errors running 'make dt_binding_check' on your patch:
>
> yamllint warnings/errors:
>
> dtschema/dtc warnings/errors:
> /builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/sound/qcom,wcd937x.yaml: properties:qcom,always-on-supply: 'type' is not one of ['description', 'deprecated']
> from schema $id:http://devicetree.org/meta-schemas/core.yaml
>
> doc reference errors (make refcheckdocs):
>
> Seehttps://patchwork.kernel.org/project/devicetree/
> patch/20260402072256.2811085-1-karthik.s@oss.qualcomm.com
>
> The base for the series is generally the latest rc1. A different dependency
> should be noted in*this* patch.
>
> If you already ran 'make dt_binding_check' and didn't see the above
> error(s), then make sure 'yamllint' is installed and dt-schema is up to
> date:
>
> pip3 install dtschema --upgrade
>
> Please check and re-submit after running the above command yourself. Note
> that DT_SCHEMA_FILES can be set to your schema file to speed up checking
> your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v2] ASoC: codecs: wcd937x: Add conditional regulator control for wcd937x
From: Karthik S @ 2026-04-06 9:52 UTC (permalink / raw)
To: Krzysztof Kozlowski, Srinivas Kandagatla, Liam Girdwood,
Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jaroslav Kysela, Takashi Iwai
Cc: linux-sound, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <ee23daf4-8181-4ab0-bd21-b2ea636168f7@kernel.org>
Hi Krzysztof,
Sorry, I won't repeat this again. will take care in future.
Thanks and Regards,
Karthik S
On 4/2/2026 1:00 PM, Krzysztof Kozlowski wrote:
> I gave you review within 5 minutes and you send exactly the same after.
> Without any changelog or explanations or response.
^ permalink raw reply
* Re: [PATCH v4 01/11] dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk
From: Harshal Dev @ 2026-04-06 9:45 UTC (permalink / raw)
To: Krzysztof Kozlowski, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Abel Vesa, Manivannan Sadhasivam, cros-qcom-dts-watchers,
Eric Biggers, Dmitry Baryshkov, Jingyi Wang, Tengfei Fan,
Bartosz Golaszewski, David Wronek, Luca Weiss, Neil Armstrong,
Melody Olvera, Alexander Koskovich
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Konrad Dybcio,
Kuldeep Singh, Krzysztof Kozlowski
In-Reply-To: <5d4e0b57-e5f6-4c2f-918b-7a23e50ea6ad@oss.qualcomm.com>
On 4/6/2026 2:50 PM, Harshal Dev wrote:
>
>
> On 4/6/2026 2:07 PM, Krzysztof Kozlowski wrote:
>> On 23/03/2026 10:17, Harshal Dev wrote:
>>> The DT bindings for inline-crypto engine do not specify the UFS_PHY_GDSC
>>> power-domain and iface clock. Without enabling the iface clock and the
>>> associated power-domain the ICE hardware cannot function correctly and
>>> leads to unclocked hardware accesses being observed during probe.
>>>
>>> Fix the DT bindings for inline-crypto engine to require the UFS_PHY_GDSC
>>> power-domain and iface clock for new devices (Eliza and Milos) introduced
>>> in the current release (7.0) with yet-to-stabilize ABI, while preserving
>>> backward compatibility for older devices.
>>>
>>> Fixes: 618195a7ac3df ("dt-bindings: crypto: qcom,inline-crypto-engine: Document the Eliza ICE")
>>> Fixes: 85faec1e85555 ("dt-bindings: crypto: qcom,inline-crypto-engine: document the Milos ICE")
>>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>>> ---
>>> .../bindings/crypto/qcom,inline-crypto-engine.yaml | 35 +++++++++++++++++++++-
>>> 1 file changed, 34 insertions(+), 1 deletion(-)
>>
>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>
>
> Thank you for the review Krzysztof. I believe since we are targeting current RC fix, I need
> to send a patch for adding the clock and power-domain for Milos and Eliza DT as well to
> conform to the binding since both changes defining the ICE node for them are already picked
> up by Bjorn:
> https://lore.kernel.org/all/177432155637.28714.2511351512032518031.b4-ty@kernel.org/
> https://lore.kernel.org/all/whoikp5tdu34gujfjqpopbhywzj6dvcxebywtwufip6jxdwp2s@oepb2y36a2hw/
>
> Is it fine if I spin a v5 of this patch adding the DT changes for Eliza and Milos? I don't
> think sending a separate patch series for updating these two DT makes sense given the RC
> will close shortly.
>
> I'll send a v5 today itself, hopefully Abel and Luca can review.
Whoops, I can see that Eliza and Milos support is planned for 7.1. I mistakenly thought
their support is already merged for 7.0. Apologies. This commit can be picked up for
7.0 RC to fix the binding. I'll send a separate patch which fixes the Eliza and Milos
DT sources targeting 7.1 RC.
Regards,
Harshal
>
> Regards,
> Harshal
>
>> Best regards,
>> Krzysztof
>
^ permalink raw reply
* RE: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: Sabau, Radu bogdan @ 2026-04-06 9:34 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <1d0d41c8-7867-4459-a91a-a2c6774b1885@baylibre.com>
> -----Original Message-----
> From: David Lechner <dlechner@baylibre.com>
> Sent: Saturday, April 4, 2026 6:34 PM
...
> >
> > Add driver documentation under Documentation/iio/ad4691.rst covering
> > operating modes, oversampling, reference voltage, SPI offload paths,
> > and buffer data layout; register in MAINTAINERS and index.rst
>
> Documentation should be separate patch. It covers more than just SPI
> offload.
>
Noted. Thanks for this.
> >
> > Kconfig gains a dependency on IIO_BUFFER_DMAENGINE.
> >
> > Signed-off-by: Radu Sabau <radu.sabau@analog.com>
> > ---
...
> > +Selected when a ``pwms`` property is present in the device tree. The PWM
> drives
> > +the CNV pin independently of SPI at the configured conversion rate, and a
> GP
> > +pin (identified by ``interrupt-names``) asserts DATA_READY at end-of-burst
> to
> > +signal that the AVG_IN result registers are ready to be read.
> > +
> > +The IRQ handler stops the PWM, fires the IIO trigger, and the trigger
> handler
>
> If we stop the PWM after an IRQ, then we don't get a consistent sample rate.
> Ideally, we would leave the PWM running and just pick a rate slow enough
> that
> there is plenty of time to read the data. Otherwise, this mode doesn't seem
> particularly useful.
Should there also be a condition when setting the sampling frequency, that will
protect from setting too fast sample rates?
>
> > +reads all active ``AVG_IN(n)`` registers in a single optimised SPI message and
> > +pushes the scan to the buffer.
> > +
> > +The buffer sampling frequency (i.e. the PWM rate) is controlled by the
> > +``sampling_frequency`` attribute on the IIO buffer. Valid values span from
> the
> > +chip's minimum oscillator rate up to its maximum conversion rate
> > +(500 kSPS for AD4691/AD4693, 1 MSPS for AD4692/AD4694).
>
> Valid, but not usable without SPI offload.
The PWM is also be used with triggered-buffer in CNV Burst Mode.
>
> > +
> > +Autonomous Mode (idle / single-shot)
> > +-------------------------------------
> > +
...
> > +
> > +Manual offload
> > +--------------
> > +
> > +Used when no ``pwms`` property is present and SPI offload is available.
> > +
> > +A periodic SPI offload trigger controls the conversion rate. On each trigger
> > +period, the SPI engine executes an N+1 transfer message (same pipelined
> scheme
>
> How does this work with oversampling?
As per previous versions discussions, Manual Mode doesn't support oversampling,
since the chip only transfers the raw unfiltered 16-bit data without register interaction
in this mode.
>
> > +as software Manual Mode) and streams the data directly to the IIO DMA
> buffer.
...
> > +IIO DMA buffer:
> > +
> > +* **CNV Burst offload**: the SPI engine reads AVG_IN registers with a 2-
> byte
> > + address phase followed by a 2-byte data phase; the 16-bit result lands in
> > + the lower half of the 32-bit word (``shift=0``).
> > +* **Manual offload**: each 32-bit SPI word carries the channel byte in the
> > + first byte; the 16-bit result is returned in the upper half of the 32-bit
>
> I would expect the "first" byte to be in the "upper half" of the 32-bits as
> well. This layout could be explained better.
>
> Also, since extra data has to be read in this mode, does this affect the max
> conversion rate?
This is bad documentation on my part. "channel byte" isn't used anymore,
this is previous version behaviour. Right now, only 16-bits worth of actual
channel data are used.
>
> > + word (``shift=16``).
> > +
> > +The ``in_voltageN_type`` sysfs attribute reflects the active scan type.
> > +
> > +
> > +Unimplemented features
> > +======================
> > +
> > +* GPIO controller functionality of the GP pins
> > +* Clamp status and overrange events
> > +* Raw accumulator (ACC_IN) and accumulator status registers
> > +* ADC_BUSY and overrun status interrupts
^ permalink raw reply
* RE: [PATCH v6 3/4] iio: adc: ad4691: add triggered buffer support
From: Sabau, Radu bogdan @ 2026-04-06 9:22 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <e38e5b97-e90f-4613-a15e-6c3d08cd77f7@baylibre.com>
> -----Original Message-----
> From: David Lechner <dlechner@baylibre.com>
> Sent: Saturday, April 4, 2026 6:12 PM
...
> > +
> > +/*
> > + * Valid ACC_DEPTH values where the effective divisor equals the count.
> > + * From Table 13: ACC_DEPTH = 2^N yields right-shift = N, divisor = 2^N.
> > + */
> > +static const int ad4691_oversampling_ratios[] = { 1, 2, 4, 8, 16, 32 };
>
> It would be nice to add oversampling in a separate commit as that is a
> separate feature.
Do you think this would be suitable after the offload commit?
>
> Oversampling also affects sampling frequency. When there isn't oversampling,
> sample rate == conversion rate. However, with oversampling, sample rate ==
> conversion rate / oversampling ratio (because each sample involves #OSR
> conversions).
>
> So more code will be required to make IIO_CHAN_INFO_SAMP_FREQ
> attributes
> (both read/write_raw and read_avail) adjust the values based on the current
> oversampling ratio.
I agree with this, the sampling frequency differs when oversampling is used.
Will add that in the next version.
>
> > +
> > static const struct ad4691_chip_info ad4691_chip_info = {
> > .channels = ad4691_channels,
...
> > +
> > + st->scan_msg.spi = spi;
>
> This isn't how the SPI framework is intended to be used. We should
> have st->spi = spi in probe instead.
You are right. The spi pointer was removed from struct in earlier versions
since the message wasn't pre-prepared back then, though now it is needed.
>
> > +
> > + ret = spi_optimize_message(spi, &st->scan_msg);
> > + if (ret) {
...
> > +};
> > +
> > +static irqreturn_t ad4691_irq(int irq, void *private)
> > +{
> > + struct iio_dev *indio_dev = private;
> > + struct ad4691_state *st = iio_priv(indio_dev);
> > +
> > + /*
> > + * GPx has asserted: stop conversions before reading so the
>
> Does this happen per-channel or only once per complete sequence?
>
This one happens per complete sequence.
^ permalink raw reply
* Re: [PATCH v4 01/11] dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk
From: Harshal Dev @ 2026-04-06 9:20 UTC (permalink / raw)
To: Krzysztof Kozlowski, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Abel Vesa, Manivannan Sadhasivam, cros-qcom-dts-watchers,
Eric Biggers, Dmitry Baryshkov, Jingyi Wang, Tengfei Fan,
Bartosz Golaszewski, David Wronek, Luca Weiss, Neil Armstrong,
Melody Olvera, Alexander Koskovich
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Konrad Dybcio,
Kuldeep Singh, Krzysztof Kozlowski
In-Reply-To: <30327e35-6d32-4aac-a55d-134ed5271603@kernel.org>
On 4/6/2026 2:07 PM, Krzysztof Kozlowski wrote:
> On 23/03/2026 10:17, Harshal Dev wrote:
>> The DT bindings for inline-crypto engine do not specify the UFS_PHY_GDSC
>> power-domain and iface clock. Without enabling the iface clock and the
>> associated power-domain the ICE hardware cannot function correctly and
>> leads to unclocked hardware accesses being observed during probe.
>>
>> Fix the DT bindings for inline-crypto engine to require the UFS_PHY_GDSC
>> power-domain and iface clock for new devices (Eliza and Milos) introduced
>> in the current release (7.0) with yet-to-stabilize ABI, while preserving
>> backward compatibility for older devices.
>>
>> Fixes: 618195a7ac3df ("dt-bindings: crypto: qcom,inline-crypto-engine: Document the Eliza ICE")
>> Fixes: 85faec1e85555 ("dt-bindings: crypto: qcom,inline-crypto-engine: document the Milos ICE")
>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>> ---
>> .../bindings/crypto/qcom,inline-crypto-engine.yaml | 35 +++++++++++++++++++++-
>> 1 file changed, 34 insertions(+), 1 deletion(-)
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
Thank you for the review Krzysztof. I believe since we are targeting current RC fix, I need
to send a patch for adding the clock and power-domain for Milos and Eliza DT as well to
conform to the binding since both changes defining the ICE node for them are already picked
up by Bjorn:
https://lore.kernel.org/all/177432155637.28714.2511351512032518031.b4-ty@kernel.org/
https://lore.kernel.org/all/whoikp5tdu34gujfjqpopbhywzj6dvcxebywtwufip6jxdwp2s@oepb2y36a2hw/
Is it fine if I spin a v5 of this patch adding the DT changes for Eliza and Milos? I don't
think sending a separate patch series for updating these two DT makes sense given the RC
will close shortly.
I'll send a v5 today itself, hopefully Abel and Luca can review.
Regards,
Harshal
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [net-next,PATCH v5 3/3] net: phy: realtek: Add property to enable SSC
From: Aleksander Jan Bajkowski @ 2026-04-06 9:06 UTC (permalink / raw)
To: Marek Vasut, netdev
Cc: David S. Miller, Andrew Lunn, Conor Dooley, Eric Dumazet,
Florian Fainelli, Heiner Kallweit, Ivan Galkin, Jakub Kicinski,
Krzysztof Kozlowski, Michael Klein, Paolo Abeni, Rob Herring,
Russell King, Vladimir Oltean, devicetree
In-Reply-To: <22564dd5-c2b5-46ec-b083-6239a3ff5a2f@mailbox.org>
Hi Marek,
On 05/04/2026 23:59, Marek Vasut wrote:
> On 4/5/26 10:23 PM, Aleksander Jan Bajkowski wrote:
>
> Hi,
>
>>> +static int rtl8211f_config_clkout_ssc(struct phy_device *phydev)
>>> +{
>>> + struct rtl821x_priv *priv = phydev->priv;
>>> + struct device *dev = &phydev->mdio.dev;
>>> + int ret;
>>> +
>>> + /* The value is preserved if the device tree property is absent */
>>> + if (!priv->enable_clkout_ssc)
>>> + return 0;
>>> +
>>> + /* RTL8211FVD has PHYCR2 register, but configuration of CLKOUT SSC
>>> + * is not currently supported by this driver due to different bit
>>> + * layout.
>>> + */
>>> + if (phydev->drv->phy_id == RTL_8211FVD_PHYID)
>>> + return 0;
>>> +
>>> + /* Unnamed registers from EMI improvement parameters
>>> application note 1.2 */
>>> + ret = phy_write_paged(phydev, 0xd09, 0x10, 0xcf00);
>>> + if (ret < 0) {
>>> + dev_err(dev, "CLKOUT SSC initialization failed: %pe\n",
>>> ERR_PTR(ret));
>>> + return ret;
>>> + }
>>> +
>>> + ret = phy_write(phydev, RTL8211F_SSC_CLKOUT, 0x38c3);
>>
>> Only registers 0x10–0x17 require paged operations. The remaining
>> registers
>> are mapped directly into the PHY address space. This is mentioned in
>> commit
>> 650e55f224a575cdb18c984b95036109519502d1. Paged and direct access return
>> the same results. With this in mind, I believe that
>> RTL8211F_SSC_CLKOUT is
>> an alias for RTL8211F_PHYCR2 and is described on page 45 of the
>> datasheet[1].
>>
>> 1. RTL8211F(I)-CG/RTL8211FD(I)-CG Datasheet
> This is a good point indeed, I think I can simply set PHYCR2 bits
> 7,12,13 to enable the CLKOUT SSC ?
Sounds correct.
Regards,
Aleksander
^ permalink raw reply
* Re: [PATCH v4 0/2] Introduce TLMM driver for Qualcomm IPQ5210 SoC
From: Kathiravan Thirumoorthy @ 2026-04-06 9:04 UTC (permalink / raw)
To: Linus Walleij
Cc: Bjorn Andersson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-gpio, devicetree, linux-kernel,
Krzysztof Kozlowski, Konrad Dybcio
In-Reply-To: <CAD++jLkwGT2SxQrax5FFF2x6CznQF_03N_FC6-2n7OAiNH3Xng@mail.gmail.com>
On 3/30/2026 2:11 PM, Linus Walleij wrote:
> On Mon, Mar 30, 2026 at 6:51 AM Kathiravan Thirumoorthy
> <kathiravan.thirumoorthy@oss.qualcomm.com> wrote:
>
>> The IPQ5210 is Qualcomm's SoC for Routers, Gateways and Access Points.
>> Add the pinctrl support for the same.
>>
>> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> Patches applied!
Linus, I don't see these patches in linux-next or in linux-pinctrl tree.
Do I miss something here?
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: crypto: qcom-qce: Document the Milos crypto engine
From: Kuldeep Singh @ 2026-04-06 8:59 UTC (permalink / raw)
To: Alexander Koskovich, Thara Gopinath, Herbert Xu, David S. Miller,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: linux-crypto, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260405-milos-qce-v1-1-6996fb0b8a9c@pm.me>
On 4/6/2026 7:40 AM, Alexander Koskovich wrote:
> Document the crypto engine on the Milos platform.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: crypto: qcom-qce: Document the Milos crypto engine
From: Krzysztof Kozlowski @ 2026-04-06 8:45 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Thara Gopinath, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-crypto, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260405-milos-qce-v1-1-6996fb0b8a9c@pm.me>
On Mon, Apr 06, 2026 at 02:10:07AM +0000, Alexander Koskovich wrote:
> Document the crypto engine on the Milos platform.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> Documentation/devicetree/bindings/crypto/qcom-qce.yaml | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] dt-bindings: rtc: moxa,moxart-rtc: convert to YAML
From: Krzysztof Kozlowski @ 2026-04-06 8:44 UTC (permalink / raw)
To: Avi Radinsky
Cc: alexandre.belloni, robh, krzk+dt, conor+dt, linux-rtc, devicetree,
linux-kernel
In-Reply-To: <CAK=E+3BLMV35g1hC2=aQ57yKxgw1y8qR8ufpHQdKcx4MdT9ioA@mail.gmail.com>
On Sun, Apr 05, 2026 at 09:31:36PM -0400, Avi Radinsky wrote:
> Convert the MOXA ART Real Time Clock text binding to YAML schema.
>
Same comments as for other try.
Also, do not duplicate work.
I don't find hopping on this entire GSoC program, while doing duplicated
and uncoordinated work with same issues, helpful.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: ti,tas2552: Add sound-dai-cells
From: Krzysztof Kozlowski @ 2026-04-06 8:41 UTC (permalink / raw)
To: Marek Vasut
Cc: devicetree, Baojun Xu, Conor Dooley, Kevin Lu,
Krzysztof Kozlowski, Liam Girdwood, Mark Brown, Rob Herring,
Shenghao Ding, linux-kernel, linux-sound
In-Reply-To: <20260405234502.154227-1-marex@nabladev.com>
On Mon, Apr 06, 2026 at 01:44:35AM +0200, Marek Vasut wrote:
> Add missing sound-sai-cells for this codec into schema.
> At the same time, drop trailing spaces from description.
>
> Fixes: 506e0825a4c9 ("ASoC: dt-bindings: Convert ti,tas2552 to DT schema")
> Signed-off-by: Marek Vasut <marex@nabladev.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 01/11] dt-bindings: crypto: qcom,ice: Fix missing power-domain and iface clk
From: Krzysztof Kozlowski @ 2026-04-06 8:37 UTC (permalink / raw)
To: Harshal Dev, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Abel Vesa, Manivannan Sadhasivam, cros-qcom-dts-watchers,
Eric Biggers, Dmitry Baryshkov, Jingyi Wang, Tengfei Fan,
Bartosz Golaszewski, David Wronek, Luca Weiss, Neil Armstrong,
Melody Olvera, Alexander Koskovich
Cc: Brian Masney, Neeraj Soni, Gaurav Kashyap, linux-arm-msm,
linux-crypto, devicetree, linux-kernel, Konrad Dybcio,
Kuldeep Singh, Krzysztof Kozlowski
In-Reply-To: <20260323-qcom_ice_power_and_clk_vote-v4-1-e36044bbdfe9@oss.qualcomm.com>
On 23/03/2026 10:17, Harshal Dev wrote:
> The DT bindings for inline-crypto engine do not specify the UFS_PHY_GDSC
> power-domain and iface clock. Without enabling the iface clock and the
> associated power-domain the ICE hardware cannot function correctly and
> leads to unclocked hardware accesses being observed during probe.
>
> Fix the DT bindings for inline-crypto engine to require the UFS_PHY_GDSC
> power-domain and iface clock for new devices (Eliza and Milos) introduced
> in the current release (7.0) with yet-to-stabilize ABI, while preserving
> backward compatibility for older devices.
>
> Fixes: 618195a7ac3df ("dt-bindings: crypto: qcom,inline-crypto-engine: Document the Eliza ICE")
> Fixes: 85faec1e85555 ("dt-bindings: crypto: qcom,inline-crypto-engine: document the Milos ICE")
> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
> ---
> .../bindings/crypto/qcom,inline-crypto-engine.yaml | 35 +++++++++++++++++++++-
> 1 file changed, 34 insertions(+), 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] drm: bridge: ti-sn65dsi83: Add support for dual-link LVDS video mode
From: tessolveupstream @ 2026-04-06 8:35 UTC (permalink / raw)
To: Luca Ceresoli, andrzej.hajda, neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, maarten.lankhorst,
mripard, tzimmermann, airlied, simona, robh, krzk+dt, conor+dt,
marex, valentin, philippe.schenker, dri-devel, linux-kernel,
devicetree
In-Reply-To: <DH5S3RB2XZ31.3C994FZK5U4OV@bootlin.com>
On 18-03-2026 14:22, Luca Ceresoli wrote:
> Hello Sudarshan,
>
> On Wed Mar 18, 2026 at 6:53 AM CET, tessolveupstream wrote:
>>>> + if (ctx->dual_link_video_mode) {
>>>> + regmap_write(ctx->regmap, REG_RC_LVDS_PLL, 0x05);
>>>> + regmap_write(ctx->regmap, REG_RC_PLL_EN, 0x00);
>>>> + regmap_write(ctx->regmap, REG_DSI_CLK, 0x53);
>>>> + regmap_write(ctx->regmap, REG_LVDS_FMT, 0x6f);
>>>> + regmap_write(ctx->regmap, REG_LVDS_VCOM, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_LOW, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_VERTICAL_DISPLAY_SIZE_HIGH, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_HSYNC_PULSE_WIDTH_LOW, 0x10);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_HORIZONTAL_BACK_PORCH, 0x28);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_VERTICAL_BACK_PORCH, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_HORIZONTAL_FRONT_PORCH, 0x00);
>>>> + regmap_write(ctx->regmap,
>>>> + REG_VID_CHA_VERTICAL_FRONT_PORCH, 0x00);
>>>> + }
>>>
>>> I guess these hard-coded values are sepcific to your panel. They must
>>> instead be computed based on the timings in order to work for every panel.
>>>
>>
>> The hard-coded values were initially derived from the TI DSI Tuner output
>> during our bring-up testing. TI had also mentioned that when PATGEN is
>> enabled with dual-LVDS output on the SN65DSI84, the horizontal timings
>> must be divided by 2. They also noted that the current driver does not
>> appear to divide the horizontal timings when PATGEN is enabled in
>> dual-LVDS mode.
>>
>> Based on that suggestion, we had tried adjusting the horizontal timing
>> registers accordingly to match the tuner output.
>> Could you please advise how these register values are expected to be
>> derived from the mode timings so that they work correctly for different
>> panels?
>
> Well, the principle is quite simple:
>
> 1. the panel docs tell you which timings the panel needs, e.g. HBP must be
> 10 clock cycles
>
> 2. your panel description in dts or implementation in a panel driver will
> then be written accordingly
>
> 3. the ti-sn65dsi83 driver will receive a struct drm_display_mode* with
> these values
>
> 4. based on those values it sets the registers so the SN65DSI84 uses the
> timings required by the panel (with a bit of math if needed):
>
> regmap_write(ctx->regmap, REG_VID_CHA_HORIZONTAL_BACK_PORCH,
> mode->htotal - mode->hsync_end);
>
> Same for all other timings.
>
> Ti is more complicated if more cases need to be handled, such as dual-LVDS,
> and the chip documentation is vague about what must be done in those cases.
>
> I suggested next steps to move forward in reply to the cover letter.
>
Thank you so much for your suggestion.
>>>> @@ -965,9 +1001,15 @@ static int sn65dsi83_host_attach(struct sn65dsi83 *ctx)
>>>>
>>>> dsi->lanes = dsi_lanes;
>>>> dsi->format = MIPI_DSI_FMT_RGB888;
>>>> - dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
>>>> - MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
>>>> - MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
>>>> + if (ctx->dual_link_video_mode)
>>>> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO;
>>>> + else
>>>> + dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
>>>> + MIPI_DSI_MODE_VIDEO_BURST |
>>>> + MIPI_DSI_MODE_VIDEO_NO_HFP |
>>>> + MIPI_DSI_MODE_VIDEO_NO_HBP |
>>>> + MIPI_DSI_MODE_VIDEO_NO_HSA |
>>>> + MIPI_DSI_MODE_NO_EOT_PACKET;
>>>
>>> There is no explanation about this, can you elaborate on why?
>>>
>>> I'm working on bringing up a dual-LVDS panel on a board with the SN65DSI84,
>>> and the removing MIPI_DSI_MODE_VIDEO_BURST seems to help, but I still have
>>> no idea why. Should you have any info, maybe from TI, it would be very
>>> interesting.
>>>
>>
>> During our earlier bring-up, TI mentioned that one possible reason for the DSI
>> REFCLK not behaving as expected could be that the DSI output is configured in
>> burst mode instead of non-burst mode. In burst mode the DSI clock may not be
>> continuous, whereas non-burst mode provides a more predictable DSI clock.
>
> Uhm, this is a bit vague. They basically said "burst can be more
> problematic than continuous", which is obvious, and "try disabling burst
> and see whether it helps" with no explanation on why one works and not the
> other. Shoudl you have more info from them you'd be welcome to share it. In
> particular, is disabling burst mode specifically related to dual-LVDS, or
> just a way to (try to) get rid of some problems without a clear
> understanding?
>
> On my side I also have a dual-LVDS panel connected to a SN65DSI84, which
> works only by disabling burst mode. I haven't tried upstreaming it because
> I don't have an explanation of why it fixes the panel and so I have no idea
> how to teach the driver when it should disable burst mode.
>
> Additionally inyour patch you remove many other flags. Any explanation from
> those?
>
Thanks for your inputs.
I wanted to share a quick observation from our side. With your suggested 3
patches (links below), the panel started working after simplifying the
dsi-> mode_flags:
https://lore.kernel.org/all/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-1-2e15f5a9a6a0@bootlin.com/
https://lore.kernel.org/all/20260226-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v1-2-2e15f5a9a6a0@bootlin.com/
https://lore.kernel.org/lkml/20260309-ti-sn65dsi83-dual-lvds-fixes-and-test-pattern-v2-1-e6aaa7e1d181@bootlin.com/
Earlier configuration:
MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
MIPI_DSI_MODE_VIDEO_NO_HFP | MIPI_DSI_MODE_VIDEO_NO_HBP |
MIPI_DSI_MODE_VIDEO_NO_HSA | MIPI_DSI_MODE_NO_EOT_PACKET;
Working configuration:
MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_NO_HSA |
MIPI_DSI_MODE_NO_EOT_PACKET;
From our testing, removing MIPI_DSI_MODE_VIDEO_BURST along with the NO_HFP/NO_HBP
flags results in stable LVDS output in dual-link mode.
Could you please suggest how you would prefer to handle this change for
upstreaming?
> Best regards,
> Luca
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* [PATCH v1 9/9] ARM: tegra: tf600t: Invert accelerometer calibration matrix
From: Svyatoslav Ryhel @ 2026-04-06 8:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Svyatoslav Ryhel, Ion Agorria,
Jonas Schwöbel
Cc: devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260406083404.31359-1-clamor95@gmail.com>
IMU calibration matrix used in the device tree is inverted when testing on
the device which results in wrong screen orientation. Invert it to match
the matrix dumped from the device.
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts b/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
index 0bebea0cb8c4..5c634b0f3f46 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
@@ -1091,9 +1091,9 @@ imu@69 {
vdd-supply = <&vdd_3v3_sys>;
vddio-supply = <&vdd_1v8_vio>;
- mount-matrix = "0", "-1", "0",
- "-1", "0", "0",
- "0", "0", "-1";
+ mount-matrix = "0", "1", "0",
+ "1", "0", "0",
+ "0", "0", "1";
/* External I2C interface */
i2c-gate {
--
2.51.0
^ permalink raw reply related
* [PATCH v1 8/9] ARM: tegra: tf600t: Drop backlight regulator
From: Svyatoslav Ryhel @ 2026-04-06 8:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Svyatoslav Ryhel, Ion Agorria,
Jonas Schwöbel
Cc: devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260406083404.31359-1-clamor95@gmail.com>
Drop dedicated backlight regulator since the GPIO used in it is actually
SFIO controlling backlight and setting it as GPIO causes backlight to
freeze at maximum level.
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts | 13 +------------
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts b/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
index 8b68bfef8dee..0bebea0cb8c4 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
@@ -2192,7 +2192,7 @@ backlight: backlight {
compatible = "pwm-backlight";
enable-gpios = <&gpio TEGRA_GPIO(H, 2) GPIO_ACTIVE_HIGH>;
- power-supply = <&vdd_5v0_bl>;
+ power-supply = <&vdd_5v0_sys>;
pwms = <&pwm 0 71428>;
brightness-levels = <1 255>;
@@ -2422,17 +2422,6 @@ vdd_3v3_als: regulator-als {
vin-supply = <&vdd_3v3_sys>;
};
- vdd_5v0_bl: regulator-bl {
- compatible = "regulator-fixed";
- regulator-name = "vdd_5v0_bl";
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- regulator-boot-on;
- gpio = <&gpio TEGRA_GPIO(H, 0) GPIO_ACTIVE_HIGH>;
- enable-active-high;
- vin-supply = <&vdd_5v0_bat>;
- };
-
vdd_panel: regulator-panel {
compatible = "regulator-fixed";
regulator-name = "vdd_panel";
--
2.51.0
^ permalink raw reply related
* [PATCH v1 7/9] ARM: tegra: tf600t: Configure panel
From: Svyatoslav Ryhel @ 2026-04-06 8:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Svyatoslav Ryhel, Ion Agorria,
Jonas Schwöbel
Cc: devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260406083404.31359-1-clamor95@gmail.com>
Configure DSI panel used in ASUS VivoTab TF600T.
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com>
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../boot/dts/nvidia/tegra30-asus-tf600t.dts | 62 ++++++++++++++++++-
1 file changed, 60 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts b/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
index 9296e7970ce4..8b68bfef8dee 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-tf600t.dts
@@ -23,6 +23,7 @@ aliases {
rtc0 = &pmic;
rtc1 = "/rtc@7000e000";
+ display0 = &lcd;
display1 = &hdmi;
serial1 = &uartc; /* Bluetooth */
@@ -55,6 +56,37 @@ linux,cma@80000000 {
};
host1x@50000000 {
+ vi@54080000 {
+ status = "okay";
+
+ csi@800 {
+ status = "okay";
+
+ avdd-dsi-csi-supply = <&avdd_dsi_csi>;
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ vi_ppa_input: endpoint {
+ /* Link to the rear camera */
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ vi_ppb_input: endpoint {
+ /* Link to the front camera */
+ };
+ };
+ };
+ };
+
hdmi: hdmi@54280000 {
status = "okay";
@@ -68,6 +100,22 @@ hdmi_out: endpoint {
};
};
};
+
+ lcd: dsi@54300000 {
+ status = "okay";
+
+ avdd-dsi-csi-supply = <&avdd_dsi_csi>;
+
+ panel@0 {
+ compatible = "hydis,hv101hd1";
+ reg = <0>;
+
+ vdd-supply = <&vdd_panel>;
+ vio-supply = <&vio_panel>;
+
+ backlight = <&backlight>;
+ };
+ };
};
vde@6001a000 {
@@ -1123,11 +1171,10 @@ pmic-sleep-hog {
};
regulators {
- vdd_lcd: vdd1 {
+ vio_panel: vdd1 {
regulator-name = "vddio_ddr_1v2";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
- regulator-always-on;
regulator-boot-on;
ti,regulator-ext-sleep-control = <8>;
};
@@ -2386,6 +2433,17 @@ vdd_5v0_bl: regulator-bl {
vin-supply = <&vdd_5v0_bat>;
};
+ vdd_panel: regulator-panel {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_panel";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ gpio = <&gpio TEGRA_GPIO(L, 4) GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <&vdd_3v3_sys>;
+ };
+
hdmi_5v0_sys: regulator-hdmi {
compatible = "regulator-fixed";
regulator-name = "hdmi_5v0_sys";
--
2.51.0
^ permalink raw reply related
* [PATCH v1 6/9] ARM: tegra: transformers: Add connector node for common trees
From: Svyatoslav Ryhel @ 2026-04-06 8:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Svyatoslav Ryhel, Ion Agorria,
Jonas Schwöbel
Cc: devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260406083404.31359-1-clamor95@gmail.com>
All ASUS Transformers have micro-HDMI connector directly available. After
Tegra HDMI got bridge/connector support, we should use connector framework
for proper HW description.
Tested-by: Andreas Westman Dorcsak <hedmoo@yahoo.com> # ASUS TF T30
Tested-by: Robert Eckelmann <longnoserob@gmail.com> # ASUS TF101 T20
Tested-by: Svyatoslav Ryhel <clamor95@gmail.com> # ASUS TF201 T30
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../tegra20-asus-transformer-common.dtsi | 22 ++++++++++++++++---
.../tegra30-asus-transformer-common.dtsi | 21 ++++++++++++++++--
2 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra20-asus-transformer-common.dtsi b/arch/arm/boot/dts/nvidia/tegra20-asus-transformer-common.dtsi
index 73c7ee378865..fe05cfd2312f 100644
--- a/arch/arm/boot/dts/nvidia/tegra20-asus-transformer-common.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra20-asus-transformer-common.dtsi
@@ -79,9 +79,11 @@ hdmi@54280000 {
pll-supply = <&hdmi_pll_reg>;
hdmi-supply = <&vdd_hdmi_en>;
- nvidia,ddc-i2c-bus = <&hdmi_ddc>;
- nvidia,hpd-gpio = <&gpio TEGRA_GPIO(N, 7)
- GPIO_ACTIVE_HIGH>;
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
};
};
@@ -1029,6 +1031,20 @@ key-volume-up {
};
};
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "d";
+
+ hpd-gpios = <&gpio TEGRA_GPIO(N, 7) GPIO_ACTIVE_HIGH>;
+ ddc-i2c-bus = <&hdmi_ddc>;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+ };
+
i2cmux {
compatible = "i2c-mux-pinctrl";
#address-cells = <1>;
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
index d4a7bae51830..76db928b53bc 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
@@ -166,8 +166,11 @@ hdmi: hdmi@54280000 {
pll-supply = <&vdd_1v8_vio>;
vdd-supply = <&vdd_3v3_sys>;
- nvidia,hpd-gpio = <&gpio TEGRA_GPIO(N, 7) GPIO_ACTIVE_HIGH>;
- nvidia,ddc-i2c-bus = <&hdmi_ddc>;
+ port {
+ hdmi_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
};
};
@@ -1701,6 +1704,20 @@ key-volume-up {
};
};
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "d";
+
+ hpd-gpios = <&gpio TEGRA_GPIO(N, 7) GPIO_ACTIVE_HIGH>;
+ ddc-i2c-bus = <&hdmi_ddc>;
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+ };
+
vdd_5v0_bat: regulator-bat {
compatible = "regulator-fixed";
regulator-name = "vdd_ac_bat";
--
2.51.0
^ permalink raw reply related
* [PATCH v1 5/9] ARM: tegra: transformer: Add support for front camera
From: Svyatoslav Ryhel @ 2026-04-06 8:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Svyatoslav Ryhel, Ion Agorria,
Jonas Schwöbel
Cc: devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260406083404.31359-1-clamor95@gmail.com>
Add front camera video path. Aptina MI1040 camera is used on all supported
ASUS Transformers, but only TF201 and TF700T will work since on
TF300T/TG/TL front camera is linked through an additional ISP.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../tegra30-asus-transformer-common.dtsi | 138 +++++++++++++++++-
1 file changed, 137 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
index 0e06136042a9..d4a7bae51830 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
@@ -2,6 +2,7 @@
#include <dt-bindings/input/gpio-keys.h>
#include <dt-bindings/input/input.h>
+#include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/thermal/thermal.h>
#include "tegra30.dtsi"
@@ -73,6 +74,91 @@ trustzone@bfe00000 {
};
host1x@50000000 {
+ vi@54080000 {
+ status = "okay";
+
+ csi@800 {
+ status = "okay";
+
+ avdd-dsi-csi-supply = <&avdd_dsi_csi>;
+
+ /* CSI-A */
+ channel@0 {
+ reg = <0>;
+
+ nvidia,mipi-calibrate = <&csi 0>; /* CSIA pad */
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ csia_input: endpoint {
+ data-lanes = <1 2>;
+ /* Add rear camera */
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ csia_output: endpoint {
+ remote-endpoint = <&vi_ppa_input>;
+ };
+ };
+ };
+
+ /* CSI-B */
+ channel@1 {
+ reg = <1>;
+
+ nvidia,mipi-calibrate = <&csi 1>; /* CSIB pad */
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ csib_input: endpoint {
+ data-lanes = <3>;
+ remote-endpoint = <&front_camera_output>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ csib_output: endpoint {
+ remote-endpoint = <&vi_ppb_input>;
+ };
+ };
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ vi_ppa_input: endpoint {
+ remote-endpoint = <&csia_output>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ vi_ppb_input: endpoint {
+ remote-endpoint = <&csib_output>;
+ };
+ };
+ };
+ };
+
hdmi: hdmi@54280000 {
status = "okay";
@@ -1173,6 +1259,36 @@ light-sensor@1c {
vdd-supply = <&vdd_3v3_sys>;
};
+ /* Aptina 1/6" HD SOC (MI1040) */
+ front-camera@48 {
+ compatible = "aptina,mi1040";
+ reg = <0x48>;
+
+ clocks = <&tegra_car TEGRA30_CLK_CSUS>;
+
+ reset-gpios = <&gpio TEGRA_GPIO(O, 0) GPIO_ACTIVE_LOW>;
+
+ vddio-supply = <&vdd_1v8_cam>;
+ vdd-supply = <&vdd_1v8_cam>;
+ vaa-supply = <&avdd_2v85_fcam>;
+
+ orientation = <0>; /* Front camera */
+
+ assigned-clocks = <&tegra_car TEGRA30_CLK_VI_SENSOR>,
+ <&tegra_car TEGRA30_CLK_CSUS>;
+ assigned-clock-rates = <24000000>;
+ assigned-clock-parents = <&tegra_car TEGRA30_CLK_PLL_P>,
+ <&tegra_car TEGRA30_CLK_VI_SENSOR>;
+
+ port {
+ front_camera_output: endpoint {
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ link-frequencies = /bits/ 64 <384000000>;
+ remote-endpoint = <&csib_input>;
+ };
+ };
+ };
+
gyroscope@68 {
compatible = "invensense,mpu3050";
reg = <0x68>;
@@ -1310,7 +1426,7 @@ ldo4 {
/* LDO5 is not used by Transformers */
- ldo6 {
+ avdd_dsi_csi: ldo6 {
regulator-name = "avdd_dsi_csi,pwrdet_mipi";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
@@ -1685,6 +1801,26 @@ hdmi_5v0_sys: regulator-hdmi {
vin-supply = <&vdd_5v0_sys>;
};
+ vdd_1v8_cam: regulator-viocam {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_1v8_cam";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ gpio = <&gpio TEGRA_GPIO(BB, 4) GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <&vdd_1v8_vio>;
+ };
+
+ avdd_2v85_fcam: regulator-avcam-front {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_2v85_fcam";
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <2850000>;
+ gpio = <&gpio TEGRA_GPIO(S, 0) GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <&vdd_3v3_sys>;
+ };
+
sound {
nvidia,i2s-controller = <&tegra_i2s1>;
--
2.51.0
^ permalink raw reply related
* [PATCH v1 4/9] ARM: tegra: grouper: Add support for front camera
From: Svyatoslav Ryhel @ 2026-04-06 8:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Svyatoslav Ryhel, Ion Agorria,
Jonas Schwöbel
Cc: devicetree, linux-tegra, linux-kernel
In-Reply-To: <20260406083404.31359-1-clamor95@gmail.com>
Add front camera video path.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../tegra30-asus-nexus7-grouper-common.dtsi | 128 ++++++++++++++++++
...egra30-asus-nexus7-grouper-maxim-pmic.dtsi | 4 +-
.../tegra30-asus-nexus7-grouper-ti-pmic.dtsi | 4 +-
3 files changed, 132 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
index 15f53babdc21..892d718294dd 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
@@ -2,6 +2,7 @@
#include <dt-bindings/input/gpio-keys.h>
#include <dt-bindings/input/input.h>
+#include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/power/summit,smb347-charger.h>
#include <dt-bindings/thermal/thermal.h>
@@ -84,6 +85,93 @@ init-mode-hog {
};
};
+ host1x@50000000 {
+ vi@54080000 {
+ status = "okay";
+
+ csi@800 {
+ status = "okay";
+
+ avdd-dsi-csi-supply = <&avdd_dsi_csi>;
+
+ /* CSI-A */
+ channel@0 {
+ reg = <0>;
+
+ nvidia,mipi-calibrate = <&csi 0>; /* CSIA pad */
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ csia_input: endpoint {
+ data-lanes = <1 2>;
+ /* No rear camera */
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ csia_output: endpoint {
+ remote-endpoint = <&vi_ppa_input>;
+ };
+ };
+ };
+
+ /* CSI-B */
+ channel@1 {
+ reg = <1>;
+
+ nvidia,mipi-calibrate = <&csi 1>; /* CSIB pad */
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ csib_input: endpoint {
+ data-lanes = <3>;
+ remote-endpoint = <&front_camera_output>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ csib_output: endpoint {
+ remote-endpoint = <&vi_ppb_input>;
+ };
+ };
+ };
+ };
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ vi_ppa_input: endpoint {
+ remote-endpoint = <&csia_output>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ vi_ppb_input: endpoint {
+ remote-endpoint = <&csib_output>;
+ };
+ };
+ };
+ };
+ };
+
pinmux@70000868 {
pinctrl-names = "default";
pinctrl-0 = <&state_default>;
@@ -890,6 +978,36 @@ light-sensor@1c {
vdd-supply = <&vdd_3v3_sys>;
};
+ /* Aptina 1/6" HD SOC (MI1040) */
+ front-camera@48 {
+ compatible = "aptina,mi1040";
+ reg = <0x48>;
+
+ clocks = <&tegra_car TEGRA30_CLK_CSUS>;
+
+ reset-gpios = <&gpio TEGRA_GPIO(O, 0) GPIO_ACTIVE_LOW>;
+
+ vddio-supply = <&avdd_cam1>;
+ vdd-supply = <&vddio_cam>;
+ vaa-supply = <&avdd_cam1>;
+
+ orientation = <0>; /* Front camera */
+
+ assigned-clocks = <&tegra_car TEGRA30_CLK_VI_SENSOR>,
+ <&tegra_car TEGRA30_CLK_CSUS>;
+ assigned-clock-rates = <24000000>;
+ assigned-clock-parents = <&tegra_car TEGRA30_CLK_PLL_P>,
+ <&tegra_car TEGRA30_CLK_VI_SENSOR>;
+
+ port {
+ front_camera_output: endpoint {
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ link-frequencies = /bits/ 64 <384000000>;
+ remote-endpoint = <&csib_input>;
+ };
+ };
+ };
+
accelerometer@68 {
compatible = "invensense,mpu6050";
reg = <0x68>;
@@ -1203,6 +1321,16 @@ vcc_3v3_ts: regulator-ts {
vin-supply = <&vdd_5v0_sys>;
};
+ avdd_cam1: regulator-vcam1 {
+ compatible = "regulator-fixed";
+ regulator-name = "avdd_cam1";
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <2850000>;
+ gpio = <&gpio TEGRA_GPIO(R, 6) GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ vin-supply = <&vdd_5v0_sys>;
+ };
+
sound {
compatible = "nvidia,tegra-audio-rt5640-grouper",
"nvidia,tegra-audio-rt5640";
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-maxim-pmic.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-maxim-pmic.dtsi
index 694c7fe37eb8..4bd98935031b 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-maxim-pmic.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-maxim-pmic.dtsi
@@ -135,7 +135,7 @@ ldo4 {
regulator-boot-on;
};
- ldo5 {
+ vddio_cam: ldo5 {
regulator-name = "vdd_camera";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
@@ -149,7 +149,7 @@ ldo6 {
regulator-boot-on;
};
- ldo7 {
+ avdd_dsi_csi: ldo7 {
regulator-name = "avdd_dsi_csi";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-ti-pmic.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-ti-pmic.dtsi
index ee4a3f482769..8fe3c62c9052 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-ti-pmic.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-ti-pmic.dtsi
@@ -92,13 +92,13 @@ ldo4 {
regulator-always-on;
};
- ldo5 {
+ vddio_cam: ldo5 {
regulator-name = "vddio_sdmmc,avdd_vdac";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
};
- ldo6 {
+ avdd_dsi_csi: ldo6 {
regulator-name = "avdd_dsi_csi,pwrdet_mipi";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
--
2.51.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox