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 75281492519 for ; Wed, 3 Jun 2026 21:35:36 +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=1780522538; cv=none; b=W4mZB+ypn6iVlV/O/3gA+upGtgSxKEHYJd7q0tS/QXPtxE6qUJ8/u7rkFJ2O1mTBPzbOSQ4ZpQ+g0R6A7VmQC9eznGDrexsmgVeG24fUKSPPylaEl7Kii0Kswr3hj+bF888gCM0FTIxzghs5PEpViXoaaFlct+07UUKvMHBPrYY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780522538; c=relaxed/simple; bh=exSk+9J78HDuJF7Dbo1z1M/mRgCuBOiUJFPKAgCtz+s=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=SP/hW+042LWeeMdhCbdKy2dx4UomKQ4gNF/G5IaTPBR7BssdeRHQ6ib51MFDVGZ6JjzJycIwp+AO6zahEXU15RQuKSDzL2QhraoMuGNsmBhR/2NcPHtVmCYRPpxzg1rxi3aHfRFT0W3u8d7Wl9qwPAJTQHT0dI4BmKDKkmwtsHU= 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=Dc2Iz7ls; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b=eRBauPZi; 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="Dc2Iz7ls"; dkim=pass (2048-bit key) header.d=oss.qualcomm.com header.i=@oss.qualcomm.com header.b="eRBauPZi" 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 653GLd8i2368080 for ; Wed, 3 Jun 2026 21:35:35 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= 3bBEMzSGNgMdGqu8MXBr/wtyw/loxl9YsdbeJqCtDZQ=; b=Dc2Iz7lsWhNPa6kD IXcmoKg8DbMmeTZC+9cuSlV2C+g4bVQjJsYLiOJHFDsfHGXiqvR9G+79EZtYLYnK hZcIEXt3hYz+mrFT7kwkrfRDDdApNeTPyufLyq0Z4wOfW50lFNUdMGVDiI4gZVDo 9haYANz3GLIJ58oEkqvwdfQgd6sxk41r/rtefGqKxS7sbqj1ZCSU4kvPSV1nFnII +MewdVwRe0apeQlOLJlk/YT8hXMjmmj8uadC+3+EN+oDDnoFaabyDsCzFRRS4g/e syd6RndN/kMKf7N1RnOAQzt55H6sD7VvJmwXNDcoo9rdw/5sgDq0QlByMJEwxwy4 TUNc1A== Received: from mail-dy1-f200.google.com (mail-dy1-f200.google.com [74.125.82.200]) by mx0a-0031df01.pphosted.com (PPS) with ESMTPS id 4ejj3gjsxv-1 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT) for ; Wed, 03 Jun 2026 21:35:35 +0000 (GMT) Received: by mail-dy1-f200.google.com with SMTP id 5a478bee46e88-304dd917645so6311879eec.1 for ; Wed, 03 Jun 2026 14:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oss.qualcomm.com; s=google; t=1780522534; x=1781127334; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=3bBEMzSGNgMdGqu8MXBr/wtyw/loxl9YsdbeJqCtDZQ=; b=eRBauPZiHINDSyEZ+aauy0U3C1vm/vX8i8x6z3Xqs0xSCqrRtBqF8qRN1j/S3VE3gK E2MykQx2v45nhzBVWj+g9s+OJKTk7YEa00+0IE6dwN+5T9t8ljPWRpxjzujvYE2lF0aS mPWClyrbs1EnAwzbnC7CaG/lK60pREJ1gA3cb5T3uRg8BZhLRqVayigMc1SMLi537X2c cVKHEhFgGrFVS/WcaSPG+E0ojtm4EgS97J30I+oHxKCSyW2V9BWeG2PdSUTwVntg+aSB nH0Dxqfw+nnwQ5EoYHcNXOw2VwlJ7lAfrXUlDK79zJRxEcnC3syBguyegacCapm/vjwz Okrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780522534; x=1781127334; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to: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=3bBEMzSGNgMdGqu8MXBr/wtyw/loxl9YsdbeJqCtDZQ=; b=sUKRV9lSDB/2NtAv3+cfzHl7LElFX+LwGunNYxsIf2UqaqMMhw7tV2oCUVwms+IdDW wnS0MjFS08raxZZadC4cCLnW5cr17jWIwpytdHhjD3/s0JlH65oDaesXrHDJJtcHmJlk VoHUwcqI0iJm+qb5eM2KHphuxZcFHnVrmbQUfDgPG93mCb44BVhQf+FFqaer9r/YMGU/ OpZoNyC7KXf4E3uhJceW3RcH/DoiTrV/TAZYMhziGDnbz1scNvhoc4w0Aa0N44G0xk4R uUhXzpkrtjL0ga1H+c6+boAwhYqimAbVJ9BwrewuEY2RJVhZNuJWZtx75D+9qXH6BBKx 2OVA== X-Forwarded-Encrypted: i=1; AFNElJ8X6ipYJHPHe2F2Odxt8bs1mNpCMgA/Nu8UBvBPbCiQ8LJC6Jh6GoP6rGJXHUk2iV8yqfKHPPZvSxqDZ3Y=@vger.kernel.org X-Gm-Message-State: AOJu0YyRKD4TSr8yqkc3C1u9Vibcuhi1AsL0a1HMuKp2zG16v2MqoaFm dtdvy6s5rmIHSxc2vjLtOcfxPAll9KHi05TFsC8ieN8DyVtFbmsSSA6bmKI7gfYohR+6eK0DFVD BxaX+BRHSzkCzZ/Ag4VwotoAeuYfGS2UuTsdK4MAtMUztGpIKubE5DHdjOfnXZCRXcrY= X-Gm-Gg: Acq92OFvK1ZILOAnEJR4hEwk2HkSF2h8KgJeRsHtU+qKi5bkHuL9iZEdjrMEamNqsEG UnPNYJvKE+su5Dqdp5enTnM4foIKswZnNUE3qftn5agSE4qCUu8jJjbo0FbTO2BmbyQPDQMjlw4 3ew4QORURZ3TKyCJxIac024vx5Nq3er5cYX5nNdrNgwCmbt+Pkyeb0/limJw2YtYHQQ1BcqodnN qf/DgiKoh2WaJRYzslXjSB1A4TD0d5acI2U1jWIl0jicb6d6FA/G+C4jegYJAqPvd2QPpP/6q6z fR1dErGNSVlguz+ff/eUu8+ViU/B/DNFoUOsWDZoRVr18Vwr6aQdglX/ZLN44kzYzoIwltmhF7z GFtGDmPo4l9JIzN/J4UiR3cVCIyDYlgaZ2+zdRCSTqBkgennNbNwFMMpvj6oLSVh1Cl25WqITvf iY5/JP8u5k4cE= X-Received: by 2002:a05:7300:3721:b0:2ef:8b72:1b9 with SMTP id 5a478bee46e88-3074f840efamr3197866eec.0.1780522534137; Wed, 03 Jun 2026 14:35:34 -0700 (PDT) X-Received: by 2002:a05:7300:3721:b0:2ef:8b72:1b9 with SMTP id 5a478bee46e88-3074f840efamr3197846eec.0.1780522533475; Wed, 03 Jun 2026 14:35:33 -0700 (PDT) Received: from [10.62.37.26] (i-global254.qualcomm.com. [199.106.103.254]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-3074db85f60sm4720946eec.8.2026.06.03.14.35.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 03 Jun 2026 14:35:33 -0700 (PDT) Message-ID: Date: Wed, 3 Jun 2026 14:35:32 -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 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> <514cf213-5778-45e1-8d70-d3fe27991fcc@oss.qualcomm.com> Content-Language: en-US From: Vijay Kumar Tumati In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Proofpoint-Spam-Details-Enc: AW1haW4tMjYwNjAzMDIxMCBTYWx0ZWRfX20apuMSonjkP lMm/2aZ2RxsjWp9LbfjAzq8rUKBFgoBeyVknf/cOuZoBGuykNE/hBqKyTp/4MXeW9SPfqu83+yr umpmG5GkFyGxZ6TeuVjd2GdheHws/j9jl93nxwRnFKXhofLifuiLlAvggiTWCdFLD6+DxF8TtDT nIXR6dXmozVVXW7cYM0XEJl5ZNVJEmec0hgYSz0epOI3hS0t1a7bCIxDZOnYsXrV3+4o9ey/p/y Ra0i9sBEeGm90fhQWjoJ5gyTaFUUbCI5YgpYztDmFq4CKvyOqCnhFaffO6wZjdNStCsdoy3eqxW VfwQBZ/xZUu8YqvUpDaZnpqEKsoOND2uskLMTuncHwu2mPKwBbrOx06OpYlO4MrSTsMBR9TW4p0 xDbNvjsmEp0laNzKyTxWoq+Dae3NHhNsFakUwCGlL278NSG76rdI4o6C4HSjZ6DlDDGONha8uiJ +b6pWV91NvLGfxMZ/6g== X-Proofpoint-GUID: 2AKxObCk5lgHzZ8bPd_gMh13McE4BRVW X-Proofpoint-ORIG-GUID: 2AKxObCk5lgHzZ8bPd_gMh13McE4BRVW X-Authority-Analysis: v=2.4 cv=UvhT8ewB c=1 sm=1 tr=0 ts=6a209e27 cx=c_pps a=PfFC4Oe2JQzmKTvty2cRDw==: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=VwQbUJbxAAAA:8 a=EUspDBNiAAAA:8 a=KKAkSRfTAAAA:8 a=Z2SiELE1jzycM0wTYZQA:9 a=3ZKOabzyN94A:10 a=QEXdDO2ut3YA:10 a=6Ab_bkdmUrQuMsNx7PHu: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_06,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-2606030210 On 6/3/2026 1:52 PM, Bryan O'Donoghue wrote: > On 03/06/2026 21:24, Vijay Kumar Tumati wrote: >> >> >> 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 binding mandates it with an if / else structure > >> >>>>>> 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.> > > Hmm do you mean the GDSC which I omitted form the example and shouldn't > have TITAN_TOP_GDSC or do you mean MMCX, MXC and MXA are required ? > > I don't believe the clock definitions say that. Also not what you said > in the previous cycle. > > I'd be obliged if you could be precise and clear since as you know the > PHY as a separate thing is important to release new SoC additions. I said the same thing in the past as well, Bryan. https://lore.kernel.org/all/5705b48a-fc24-4c5f-aa6d-40952f0070d9@oss.qualcomm.com/ I would expect 3 voltage rails for each PHY and a TOP GDSC, so a total of 4 power domains. Perhaps, you don't have the access to IPCAT but I can confirm that, on X1E80100 platform, the parent of cam_cc_csiphy0_clk (and other PHYs) is cam_cc_cphy_rx_clk_src and that depends on mxc, mxa and mm for core voltage. And cam_cc_csiphy0_clk (and other PHYs) itself is controlled by the GDSC TITAN_TOP.>>>>>> + >>>>>> +  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?>>>> + > > Yes the DTSI has TITAN_TOP_GDSC I haven't updated the YAML to capture that. > > So it should be > > top > mmcx > mx Ack.> > With obviously on mmcx and mx scalable. We established that CSIPHY4 had > MXA whereas the other CSIPHYs had MXC in v5 or v4 - can you be clear if > you agreeing with that still or saying something different. Per my > memory of reading the docs, there was nothing in the clock tree to > indicate both MXA and MXC were required for all PHYs. > >>>>>> +        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? > > Yes the dtsi has it, the example does not. I had pushback from others > about the example being too complex - you can't please all of the people > all of the time. > > I will drop the full table @ v9 Ok. I noticed that you are setting the rate for the timer clk explicitly using 'clk_set_rate'. May be the best way is to control the rate of both the clocks with the OPP table itself, with core clk as your anchor that is calculated based on the data rate.> >>>> + required-opps = >>> <&rpmhpd_opp_low_svs_d1>, >>>>>> +                            <&rpmhpd_opp_low_svs_d1>; >>> Same here, it should 3 power domains set.>>> +        }; > > Two power domains scaled, one set at least I hope that's what you mean > i.e. add the GDSC, already in my code I just didn't add it here as I > should have. > > - GDSC enabled > - MMCX scaled > - MX scaled > > When MX points to MXA the scaling is a NOP @ rpmhpd_opp_low_svs_d1. > > Agreed ? Like I clarified in the first comment, I would expect all of mcx, mxa and mm to be set by OPP table.>>>>>> + >>>>>> +        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. >>> >> > Thanks, Vijay.