From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mx0b-0031df01.pphosted.com (mx0b-0031df01.pphosted.com [205.220.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 48E6B37FF70 for ; Wed, 3 Jun 2026 20:24:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.180.131 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780518249; cv=none; b=Em5DP0weYIsFh+chvABcjUQcS7lKtfAje06V3fZWX46rM4zWCckN3dKklngLuTWOl0cmtMp3lup6OCZaGw3yYzviST93VbWvUvytnYDan8lCB+9izScJS3bJMuhJ9hZ8WjpvkZkqaXmzyf3RHJh0OlvE59CZl6PityJ++jDBnKg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780518249; c=relaxed/simple; bh=dgtu2Iep90AeJho7vMivN6OvXTJk+BhD2v7PAhpGkIg=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=jXCZlaR5mJ8ecL13Brv/MVhjDa8TLjtoHgmcR8VoFC84bWhQ2GWj4wVtqsAoTyzAf56eurzkQbkze5Mm19zrYTYxu9dd7ovDngSKwCsBFqS3Q9jZ2QOMUYWvmlnE5N/X3kTycaRW3kH0AUDoD2+Cp7CfDvYNUPHE06jHkfUrtX4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com; spf=pass smtp.mailfrom=oss.qualcomm.com; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b=ZgTwajg/; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=WiX5KYR6; arc=none smtp.client-ip=205.220.180.131 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=oss.qualcomm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=qualcomm.com header.i=@qualcomm.com header.b="ZgTwajg/"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="WiX5KYR6" Received: from pps.filterd (m0279868.ppops.net [127.0.0.1]) by mx0a-0031df01.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 653Gdp902368043 for ; Wed, 3 Jun 2026 20:24:05 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qualcomm.com; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to; s=qcppdkim1; bh= aWKiZt685wkb/zfGIBJDwQedq36r3+vpvu2k4QjMlOk=; b=ZgTwajg/k6/NXcl5 Jh7W5QBbjK2qrecULXUDS+r6jBiSw8aK7pDApPY1n4bvPmXEBslrlf5CRCZZt9+g 0tXjQuozplc4kDS+slqv0spJotxMuCA4vPY8XnnaWY1KNqy93lB/ii0rTgWaF+sT Lph3lvD/EfleSjNG+GNK9C1sjKxJwQqBpZHyflu7cbhPVuxeg2fiXGFDxdNK4RAz QCfQT2kQ/eG2CmvffyM349GQokYMOXhrqXRTaWH3rKCrksk8zdlGshnIDox05ZKM x/V4dtspwDrtvSW76kPSzdtWmQvfqwJTEUNXvsmIG3QO+MG5SbmDBrLyydMXpn9R 3rmFXw== Received: from mail-dy1-f197.google.com (mail-dy1-f197.google.com [74.125.82.197]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4ejj3gjjfp-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 03 Jun 2026 20:24:05 +0000 (GMT) Received: by mail-dy1-f197.google.com with SMTP id 5a478bee46e88-304e4636205so17032091eec.1 for ; Wed, 03 Jun 2026 13:24:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1780518244; x=1781123044; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id:from:to :cc:subject:date:message-id:reply-to; bh=aWKiZt685wkb/zfGIBJDwQedq36r3+vpvu2k4QjMlOk=; b=WiX5KYR6TKWj8pRDoBzzWa58RQCRuyIRp31v/Br1t+TZpnmFXsBi2TF6g/KcK3g7po gctMB2wLJ4V6BqSet22N/DT6A2PwvLNgNLZYY09Uhxalyoso76fHyIC5kQhP1P0Xarkz uBQ2WIqraq/R7E5kOJcghwiWge3/HeO801JQ52RAv2YieRWjGZ3D/89muzUBfNnPya4R 6cx9KbeOQ9fnD3JOKNRI+rWCz2eaxfOLfX7Vsm926nG4xOYFpbR4lHtlNLHz3YM983mt rWAnlBPm6EVAl9m7s6ADbMVKok7uVh6r0AFLa+IL6xw4BkXgtm4ABkN64QNDVkr9AHdx Z8GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780518244; x=1781123044; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:from:subject:user-agent:mime-version:date:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=aWKiZt685wkb/zfGIBJDwQedq36r3+vpvu2k4QjMlOk=; b=SP67UF8PbbguHYijCKJ//xbud/dxcRA2VZReWkPw0eaDUZYmxxN3dxq+YBm6Oz7aCs kUi6ZzauDBBgdv2MWjIBZiutKSG3M4TA+aJcxxMR+OhdBpsa8GZ/M1V3MUJw1ylIxziQ X2reficT/muOq5RM1ZPzcFSAHJAvbDnbg9HfTiLZtX77C6YqVzJceGKVhSUol1n0SqYU 0EA3lWaB19QcaqC1ftPkBhf4f98ED2MJQSlE08O+WQC1UCfo4SfWmRGrG1lVzzb03NAQ rlTb4iGvE6/xcm6MmRVMw+lb4RLdh7a3NKBrhxUBS1z7Ass9gA7RHEqWXpHpxFu3wAB5 LkrA== X-Forwarded-Encrypted: i=1; AFNElJ+84+qjWH7lfg+hkfKuC4M3tGn+WiijPH95efJq8hjZvEdS8dajQK+sYpvY+S6a22r/AkRMDGWXgSDyVDs=@vger.kernel.org X-Gm-Message-State: AOJu0YxBflXOYLnEojAfausjQ7sBRhJnQsZxP7BoGedn5suGPNbG14YK 7H/zeKtZFfAnpVMDPenIrTl4Lpfqm7EGXIIKIhFHNPf/l3UpRkduud2fOnCALGxR3dJA6qJakCQ 2Ks+BeZ8yhh2087umLALVWvYfGkoPDLJ/Qj+PzEySGM5mprnobNufsb0HwTJzGWQLbl0= X-Gm-Gg: Acq92OF9nZ/0XZ2Km+khZrszxTYWnVEgpKu6cZIDk/oTt/jh1+twX098TP1zleGaIVd VdP8isuKhmhFWXOeaN7TaE7CifviHIetw14M5SrCRBauE0DYCH27s35QPyBtTTgAuat7ASgbPbz I9CHga7tS5fcIAd0+PEuzzYXAhE5Y94x7EZFwZr4z8X+G//I+ebr9XH2hKGXC1Qn80xQzm9N8bC gp3dpsMh6DEzI9NI9Bgrx1od70tqb3cJipq1ldPqjHcGbWTTiHOHIbBYpltN7ycGWJ1b9765xwJ dJyJGw9FnrrrmIJgUwwp7ZGNtsKNkDZWf4ZkEFT03jmHmadA00OnP9NjCAb7qkkOw8ezot9Jz1n y/YmmyQTSxyOWEEuAtTWWxjsJw8HGy9x/FBdstaqCyAWXfBoletfX01K2HrjX2YUPMv0yqGjGBL r4bLPFiUmxOeU= X-Received: by 2002:a05:7300:2142:b0:304:630d:e4c4 with SMTP id 5a478bee46e88-3074fab7663mr2659616eec.10.1780518244104; Wed, 03 Jun 2026 13:24:04 -0700 (PDT) X-Received: by 2002:a05:7300:2142:b0:304:630d:e4c4 with SMTP id 5a478bee46e88-3074fab7663mr2659592eec.10.1780518243493; Wed, 03 Jun 2026 13:24:03 -0700 (PDT) Received: from [10.62.37.26] (i-global254.qualcomm.com. [199.106.103.254]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3074df3b234sm4306900eec.23.2026.06.03.13.24.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jun 2026 13:24:02 -0700 (PDT) Message-ID: <514cf213-5778-45e1-8d70-d3fe27991fcc@oss.qualcomm.com> Date: Wed, 3 Jun 2026 13:24:01 -0700 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema From: Vijay Kumar Tumati To: Bryan O'Donoghue , Vladimir Zapolskiy , Bryan O'Donoghue , Vinod Koul , Kishon Vijay Abraham I , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Neil Armstrong Cc: linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org, linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260523-x1e-csi2-phy-v8-0-a85668459521@linaro.org> <20260523-x1e-csi2-phy-v8-1-a85668459521@linaro.org> <478df3ed-d4ef-43aa-bb84-e2075798542b@kernel.org> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjAzMDE5OCBTYWx0ZWRfX5pOnlk1HJ8BU KTA+gN+4w8vtTTRJvpco1Do1umZN9rhnK9fhuRrghJMQvTYIcr1qagbVDch7ZY6wJI2BRVfx13W e086ubyDvB0vhnPTCPXHIagLDKfN6psGsZbpcF3uKtMxD8ZVZkKyS+14hHqcDJHauSEhTgK95Jt JOzBnNwh+wBZSyN8HiucQmlxmvI7LbzIxJ1zmFRxXtSMxUo4vIYm9LVy1AAiTapCwWeYQqktx6R 6hhwqeGn1cSnmvBpRnM4Hg4OfUeG2cek7p7XFAlModojQ7i7cpKfFdP4v7KHC2Wl59gIPFApeqk TLfwbaobkOBht26dzhzZwOE0U0OnX6QsHmfqPaWbb/bgZ2BFKmJ0AutlwsKaHIuSEvg6nLTVaGG VpKO6QBF1W8D8bMkMy5rKpw28Mf1zywvs7wf1mmESo9SLP8spxkSzZ72RTxDjV/wk/HzA3kgllJ JS4ovJv9WHpEK/sMerg== X-Proofpoint-GUID: a71Azxe_V56wAKTabovsGs0y4nJNoguN X-Proofpoint-ORIG-GUID: a71Azxe_V56wAKTabovsGs0y4nJNoguN X-Authority-Analysis: v=2.4 cv=UvhT8ewB c=1 sm=1 tr=0 ts=6a208d65 cx=c_pps a=Uww141gWH0fZj/3QKPojxA==:117 a=JYp8KDb2vCoCEuGobkYCKw==:17 a=IkcTkHD0fZMA:10 a=FelO9ux0wxsA:10 a=s4-Qcg_JpJYA:10 a=VkNPw1HP01LnGYTKEx00:22 a=u7WPNUs3qKkmUXheDGA7:22 a=ZpdpYltYx_vBUK5n70dp:22 a=gEfo2CItAAAA:8 a=KKAkSRfTAAAA:8 a=VwQbUJbxAAAA:8 a=Lt2A_MVf5n7MuNHE5loA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=PxkB5W3o20Ba91AHUih5:22 a=sptkURWiP4Gy88Gu7hUp:22 a=cvBusfyB2V15izCimMoJ:22 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1143,Hydra:6.1.125,FMLib:17.12.100.49 definitions=2026-06-03_05,2026-05-28_03,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 phishscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1015 suspectscore=0 spamscore=0 impostorscore=0 adultscore=0 bulkscore=0 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2605210000 definitions=main-2606030198 On 6/3/2026 1:16 PM, Vijay Kumar Tumati wrote: > Hi, > > On 6/2/2026 3:51 PM, Bryan O'Donoghue wrote: >> On 02/06/2026 22:59, Vladimir Zapolskiy wrote: >>> On 5/23/26 05:48, Bryan O'Donoghue wrote: >>>> Add a base schema initially compatible with x1e80100 to describe >>>> MIPI CSI2 >>>> PHY devices. >>>> >>>> The hardware can support both CPHY, DPHY and a special split-mode DPHY. >>>> >>>> The schema here defines three ports: >>>> >>>> port@0: >>>>       The first input port where a sensor is always required. >>>> >>>> port@1: >>>>       A second optional input port which if present implies DPHY >>>> split-mode. >>>> >>>> port@2: >>>>       A third always required output port which connects to the >>>> controller. >>>> >>> >>> This port numeration is imperfect, because port@0 and port@2 are >>> required, >>> while middle port@1 is optional. >>> >>> Like it was stated before a number of times, it seems natural to operate >>> with two ports, where input port may have two endpoints rather than 3 >>> ports, >>> also that approach solves the problem of a hole in the port numeration. >> >> Can you confirm this is what you are after ? >> >> port@0 { >>      #address-cells = <1>; >>      #size-cells = <0>; >> >>      endpoint@0 {              /* primary sensor */ >>          reg = <0>; >>          data-lanes = <0 1 2 3>; >>          remote-endpoint = <&sensor0_out>; >>      }; >> >>      endpoint@1 {              /* split-mode second sensor, optional */ >>          reg = <1>; >>          data-lanes = <0>; >>          remote-endpoint = <&sensor1_out>; >>      }; >> }; >> >> port@1 {                     /* output to CAMSS, was port@2 */ >>      endpoint { remote-endpoint = <&controller_in>; }; >> }; >> >> This works for me BTW. > Either way, do we need to document the constraint of using port@0 or > endpoint@0 'only' for the 4+1 or 2+1 mode and the other one is for the > 1+1 mode? Or is it implicit from this bindings for a developer?> >>>> The CSIPHY devices have their own pinouts on the SoC as well as >>>> their own >>>> individual voltage rails. >>>> >>>> The need to model voltage rails on a per-PHY basis leads us to define >>>> CSIPHY devices as individual nodes. >>>> >>>> Two nice outcomes in terms of schema and DT arise from this change. >>>> >>>> 1. The ability to define on a per-PHY basis voltage rails. >>>> 2. The ability to require those voltage. >>>> >>>> We have had a complete bodge upstream for this where a single set of >>>> voltage rail for all CSIPHYs has been buried inside of CAMSS. >>>> >>>> Much like the I2C bus which is dedicated to Camera sensors - the CCI >>>> bus in >>>> CAMSS parlance, the CSIPHY devices should be individually modelled. >>>> >>>> Signed-off-by: Bryan O'Donoghue >>>> --- >>>>    .../bindings/phy/qcom,x1e80100-csi2-phy.yaml       | 209 ++++++++ >>>> + ++++++++++++ >>>>    1 file changed, 209 insertions(+) >>>> >>>> diff --git a/Documentation/devicetree/bindings/phy/qcom,x1e80100- >>>> csi2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,x1e80100- >>>> csi2-phy.yaml >>>> new file mode 100644 >>>> index 0000000000000..270375f949880 >>>> --- /dev/null >>>> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml >>>> @@ -0,0 +1,209 @@ >>>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >>>> +%YAML 1.2 >>>> +--- >>>> +$id: http://devicetree.org/schemas/phy/qcom,x1e80100-csi2-phy.yaml# >>>> +$schema: http://devicetree.org/meta-schemas/core.yaml# >>>> + >>>> +title: Qualcomm CSI2 PHY >>>> + >>>> +maintainers: >>>> +  - Bryan O'Donoghue >>>> + >>>> +description: >>>> +  Qualcomm MIPI CSI2 C-PHY/D-PHY combination PHY. Connects MIPI >>>> CSI2 sensors >>>> +  to Qualcomm's Camera CSI Decoder. The PHY supports both C-PHY and >>>> D-PHY >>>> +  modes. >>>> + >>>> +properties: >>>> +  compatible: >>>> +    const: qcom,x1e80100-csi2-phy >>>> + >>>> +  reg: >>>> +    maxItems: 1 >>>> + >>>> +  "#phy-cells": >>>> +    const: 1 >>>> +    description: >>>> +      The single cell specifies the PHY operating mode. >>> >>> #phy-cells should be 0, because the PHY operating mode is well defined >>> by 'bus-type' property of an endpoint on the sensor side, the opposite >>> side of CAMSS/CSID as a CSIPHY "consumer" should not dictate the PHY >>> type. >> >> Rob said consumer but, I'm also not very bothered about that. bus-type >> is perfectly acceptable to me. >> >>>> + >>>> +  clocks: >>>> +    maxItems: 2 >>>> + >>>> +  clock-names: >>>> +    items: >>>> +      - const: core >>>> +      - const: timer >>>> + >>>> +  interrupts: >>>> +    maxItems: 1 >>>> + >>>> +  operating-points-v2: >>>> +    maxItems: 1 >>>> + >>>> +  power-domains: >>>> +    items: >>>> +      - description: MMCX voltage rail >>>> +      - description: MXC or MXA voltage rail >>> >>> Only "qcom,x1e80100-csi2-phy" device is supported so far, unlikely it's >>> the case that "MXC or MXA voltage rail" should be specified, it'd be >>> just one of two or both. >> >> Hmm. I'm not being clear here if this is your take, I will reword it >> to make it clearer this generation of PHY _must_ have either >> >> - MMCX and MXC >> or >> - MMCX and MXA > I am not sure of this, Bryan. If you look at the PHY core clock > separately, sure, that is correct. But all of them, on this platform as > well, share the RCG, which requires all 3 power domains. So > fundamentally, you need to enable all of those from each PHY. You can > make it constant 3 power domains.> >>>> + >>>> +  power-domain-names: >>>> +    items: >>>> +      - const: mmcx >>>> +      - const: mx >>>> + >>>> +  vdda-0p9-supply: >>>> +    description: Phandle to a 0.9V regulator supply to a PHY. >>>> + >>>> +  vdda-1p2-supply: >>>> +    description: Phandle to 1.2V regulator supply to a PHY. >>>> + >>>> +  ports: >>>> +    $ref: /schemas/graph.yaml#/properties/ports >>>> + >>>> +    properties: >>>> +      port@0: >>>> +        $ref: /schemas/graph.yaml#/$defs/port-base >>>> +        description: Sensor input. Always present. >>>> +        unevaluatedProperties: false >>>> + >>>> +        properties: >>>> +          endpoint: >>>> +            $ref: /schemas/media/video-interfaces.yaml# >>>> +            unevaluatedProperties: false >>>> +            properties: >>>> +              data-lanes: >>>> +                minItems: 1 >>>> +                maxItems: 4 >>>> +              clock-lanes: >>>> +                maxItems: 1 >>>> +              remote-endpoint: true >>>> +            required: >>>> +              - data-lanes >>>> +              - remote-endpoint >>>> + >>>> +      port@1: >>>> +        $ref: /schemas/graph.yaml#/$defs/port-base >>>> +        description: >>>> +          Second sensor input. When present, indicates DPHY split >>>> mode. >>>> +        unevaluatedProperties: false >>>> + >>>> +        properties: >>>> +          endpoint: >>>> +            $ref: /schemas/media/video-interfaces.yaml# >>>> +            unevaluatedProperties: false >>>> +            properties: >>>> +              data-lanes: >>>> +                maxItems: 1 >>>> +              clock-lanes: >>>> +                maxItems: 1 >>>> +              remote-endpoint: true >>>> +            required: >>>> +              - data-lanes >>>> +              - clock-lanes >>>> +              - remote-endpoint >>> >>> As it's stated above, it should be converted to a single port with two >>> endpoints, it'd be done in accordance to video-interfaces.yaml. >>> >>>> + >>>> +      port@2: >>>> +        $ref: /schemas/graph.yaml#/$defs/port-base >>>> +        description: Output to CAMSS controller. >>>> +        unevaluatedProperties: false >>>> + >>>> +        properties: >>>> +          endpoint: >>>> +            $ref: /schemas/graph.yaml#/$defs/endpoint-base >>>> +            unevaluatedProperties: false >>>> +            properties: >>>> +              remote-endpoint: true >>>> +            required: >>>> +              - remote-endpoint >>>> + >>>> +    required: >>>> +      - port@0 >>>> +      - port@2 >>>> + >>>> +required: >>>> +  - compatible >>>> +  - reg >>>> +  - "#phy-cells" >>>> +  - clocks >>>> +  - clock-names >>>> +  - interrupts >>>> +  - operating-points-v2 >>>> +  - power-domains >>>> +  - power-domain-names >>>> +  - vdda-0p9-supply >>>> +  - vdda-1p2-supply >>>> +  - ports >>>> + >>>> +additionalProperties: false >>>> + >>>> +examples: >>>> +  - | >>>> +    #include >>>> +    #include >>>> +    #include >>>> +    #include >>>> + >>>> +    csiphy4: csiphy@ace4000 { >>>> +        compatible = "qcom,x1e80100-csi2-phy"; >>>> +        reg = <0x0ace4000 0x2000>; >>>> +        #phy-cells = <1>; >>>> + >>>> +        clocks = <&camcc CAM_CC_CSIPHY0_CLK>, >>>> +                 <&camcc CAM_CC_CSI0PHYTIMER_CLK>; >>>> +        clock-names = "core", >>>> +                      "timer"; >>>> + >>>> +        operating-points-v2 = <&csiphy_opp_table>; >>>> + >>>> +        interrupts = ; >>>> + >>>> +        power-domains = <&rpmhpd RPMHPD_MMCX>, >>>> +                        <&rpmhpd RPMHPD_MX>; >>>> +        power-domain-names = "mmcx", >>>> +                             "mx"; Actually, one more thing, Why isn't TITAN TOP GDSC here?>>>> + >>>> +        vdda-0p9-supply = <&vreg_l2c_0p8>; >>>> +        vdda-1p2-supply = <&vreg_l1c_1p2>; >>>> + >>>> +        ports { >>>> +            #address-cells = <1>; >>>> +            #size-cells = <0>; >>>> + >>>> +            port@0 { >>>> +                reg = <0>; >>>> +                csiphy0_in_ep: endpoint { >>>> +                    data-lanes = <0 1>; >>>> +                    clock-lanes = <2>; >>>> +                    remote-endpoint = <&sensor_out>; >>>> +                }; >>>> +            }; >>>> + >>>> +            port@2 { >>>> +                reg = <2>; >>>> +                csiphy0_out_ep: endpoint { >>>> +                    remote-endpoint = <&controller_in>; >>>> +                }; >>>> +            }; >>>> +        }; >>>> +    }; >>>> + >>>> +    csiphy_opp_table: opp-table { >>>> +        compatible = "operating-points-v2"; >>>> + >>>> +        opp-300000000 { >>>> +            opp-hz = /bits/ 64 <300000000>; > I wonder why you would have only one clock here. You should be setting > the rate for both the core and timer, isn't it?>>> + required-opps = > <&rpmhpd_opp_low_svs_d1>, >>>> +                            <&rpmhpd_opp_low_svs_d1>; > Same here, it should 3 power domains set.>>> +        }; >>>> + >>>> +        opp-400000000 { >>>> +            opp-hz = /bits/ 64 <400000000>; >>>> +            required-opps = <&rpmhpd_opp_low_svs>, >>>> +                            <&rpmhpd_opp_low_svs_d1>; > Why is one at svs and the other at svs_d1? Shouldn't both be svs?>>> > +        }; >>>> + >>>> +        opp-480000000 { >>>> +            opp-hz = /bits/ 64 <480000000>; >>>> +            required-opps = <&rpmhpd_opp_low_svs>, >>>> +                            <&rpmhpd_opp_low_svs_d1>; > And here, both should be svs_l1?>>> +        }; >>>> +    }; >>>> >>> >>> -- >>> Best wishes, >>> Vladimir >> >> > Thanks, > Vijay. >