From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DC4AB29D280 for ; Wed, 10 Dec 2025 22:05:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765404338; cv=none; b=TQCgjqFNERVehtJTgUFSPDPrLTNw5dzRVjygvSi4J+e2e7PWb5sOIGkV5ELe90d/49BlgEJM9OCj+adDgPB/Z3cHZt/niPRCTJTChvabNSY8+8C8UfU/JoDSG0tghsRBpU+uWLa/OA2qq3GUOHxtBsl+DT8HYo35nWbntPF1UJM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765404338; c=relaxed/simple; bh=afgIP1WZS5HbqRBspQa2oUUooNIXpXxeQSniqBBD/sY=; h=Message-ID:Date:MIME-Version:Subject:From:To:Cc:References: In-Reply-To:Content-Type; b=GKF5aUBbO5z+Mcp1V85/6YoumMz8BmQPP4EPEnNoVnf9F7qk+rjcMSLmxlSTGDHtz58HgPxcWIUYce23AevuRElm9XTgYV/c3eanKUJV/PCSxXKHj/06O4mvDUgDc8/6urCnLjtdWf9oMZDOY+FhRPT8rEpX7GkbK442dsC7NgY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org; spf=pass smtp.mailfrom=linaro.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b=JRvvkcwQ; arc=none smtp.client-ip=209.85.210.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linaro.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="JRvvkcwQ" Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-7aae5f2633dso303716b3a.3 for ; Wed, 10 Dec 2025 14:05:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1765404335; x=1766009135; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :reply-to:cc:to:from:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=j+3Fp0e7+CAe2qx3ZAGyWsh59Da2Z8lZFYYhFOen7e8=; b=JRvvkcwQu194nX+k2c2eWlCdHxsFMCtuwltHvER0Rh8/RodaYEaeTq85wpUHn7kyPE 1daCfqqwMGGldqzEnCM2nhwkJUjnPvxwyKCBo0Z+xyJD5bpcFn/BT2NVZWi22hS++AXV uF8jbZnv74GWyB+bL56SBd/AIGdizqfdM7sX32OnE1lElCv2CExjNE6Z9P/XjaUxZRDt VQoQ7HV2/xx/5k5zLKEJ6XPmNF6dPwdDO0xf+7AKQWpY267UyKn6kZ/Bfsb9SX7/kIzP 7kpbv8/Lzhqrqp0HOvCykTe9vJfcKf0rbZpwvFfPfJRYWQEHSF9QaG0RXCsdYbL04Jiz E3wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765404335; x=1766009135; h=content-transfer-encoding:in-reply-to:content-language:references :reply-to: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=j+3Fp0e7+CAe2qx3ZAGyWsh59Da2Z8lZFYYhFOen7e8=; b=b5mSXubPb2fICCxnNuur+EAXGeZnDnLNApq2Ee13whdqIVTPalONu03gscpPXp1Dw+ Q/ZPjWoyvyDRB+u1nmO+9kx+98vQ6yDWrj/OCQb3I14WxI3N/ab/fNTcWxi6pPGhhpKy +9YdYSa6JBjWyq9/VJBP+yoHC7iVCkehR3Xi4sWSJcIyrcocwMnvNwY8mjPiwXBW4PbU ThnK+vxwXclC9SKE2GThp6jbIjOk0lpNFzeC89Nx3NrPQb7LGt7rksynadA+WlRrTc0w 9paLWM/APUbLndOegLhejoMluPrmh+4kP5CuUDUhZHGHFi3qN8/SRzoeipMmgSccYYDk o7Kw== X-Forwarded-Encrypted: i=1; AJvYcCX/bLWrLwUOqTCDspA4UkpDK+c2yNdcgklIk/CuDvZ8v3VIH7VzpEQ2/ls03PxPgnlBrPM5GzpvJQOmkJo=@vger.kernel.org X-Gm-Message-State: AOJu0YxJzePQ4xDmDgpuoZB2MZiZcLQLKpE411+WG1QwJWeQg3JrjLN7 hR1l8aqPDYmlr4FJ1LcDmLTIF3d1trFwK9V4HaH0rb8HD6z3FYxkIbMoB3Q0Q5u/Z/E= X-Gm-Gg: AY/fxX72axVPYouMcYZYq6A40nlf7cKHJNLaqXmwQb+5OFrivGYC9oODJqZV3Na8RVg jAyJyUSPR2WRZXj0weTJDPdTdYwGEUNNP+mv1pu+ZcuKgn0oTa9uKtJKM/mlsyi/sdrobVZFABN WJYSfAHBGBQuVE3M3+d23AwS/5yI65SwbK2PGorgKiojyBbyuFSW45cUPjC4p0VJSENlekDSX5/ ihSMdo33vD/YYc70L/udXAa7p05MX7Zr5eX6UgH+MjzVNH81vLCr8xm+WXJdf7GMHnKuanELEjg QVGNg7EZJcWUTNB9pKsM2JknyOncjnjc0VqaYakaHXBOZCHK0jYOIkeZiKKCixiHYFbivgSFWx0 AyQB1YpznEUAtiRQQK7yjJEPhq63SR8uiqcBzksbbOlRu6iLjDFfG44MKXfqrUUq7TllQa2VUG1 cohHKPDtbveuc+XjA2gV60JAg0+0r0A+vHutZeEIswS2ovIg06pCgr7Qd68Gk= X-Google-Smtp-Source: AGHT+IF3KUPFrL4bHbOPu1WT1G49RqczR26kcOyX6K5VmloGDfvztYKpxQz7JT9Y1I3PBOjTJ7628Q== X-Received: by 2002:a05:6a00:4fd3:b0:7b8:3549:85f9 with SMTP id d2e1a72fcca58-7f22e58a573mr3528819b3a.30.1765404334727; Wed, 10 Dec 2025 14:05:34 -0800 (PST) Received: from [10.237.118.45] (M106185144161.v4.enabler.ne.jp. [106.185.144.161]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-7f4c2772a51sm481675b3a.17.2025.12.10.14.05.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 Dec 2025 14:05:34 -0800 (PST) Message-ID: Date: Wed, 10 Dec 2025 22:05:17 +0000 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 v9 1/5] media: dt-bindings: Add CAMSS device for Kaanapali From: Bryan O'Donoghue To: Vijay Kumar Tumati , Dmitry Baryshkov Cc: Hangxiang Ma , Loic Poulain , Robert Foss , Andi Shyti , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Todor Tomov , Vladimir Zapolskiy , Mauro Carvalho Chehab , linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, Krzysztof Kozlowski Reply-To: Bryan O'Donoghue References: <20251208-add-support-for-camss-on-kaanapali-v9-0-3fcd31258415@oss.qualcomm.com> <20251208-add-support-for-camss-on-kaanapali-v9-1-3fcd31258415@oss.qualcomm.com> <458a7841-e422-4cad-83de-f5b5c1b683a6@oss.qualcomm.com> <2e38b9f3-8a35-4a27-82d3-c1d4996a1684@oss.qualcomm.com> <9ecf4783-e1a2-430b-a889-997689bafe45@oss.qualcomm.com> <1c9db550-677e-4fdc-8929-89c21deecf17@linaro.org> Content-Language: en-US In-Reply-To: <1c9db550-677e-4fdc-8929-89c21deecf17@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 10/12/2025 21:45, Bryan O'Donoghue wrote: > On 10/12/2025 19:36, Vijay Kumar Tumati wrote: >> >> On 12/10/2025 11:25 AM, Dmitry Baryshkov wrote: >>> On Wed, Dec 10, 2025 at 09:50:51AM -0800, Vijay Kumar Tumati wrote: >>>> On 12/8/2025 3:21 PM, Vijay Kumar Tumati wrote: >>>>> On 12/8/2025 2:48 PM, Dmitry Baryshkov wrote: >>>>>> On Mon, Dec 08, 2025 at 01:03:06PM -0800, Vijay Kumar Tumati wrote: >>>>>>> On 12/8/2025 11:53 AM, Dmitry Baryshkov wrote: >>>>>>>>> +  interconnects: >>>>>>>>> +    maxItems: 4 >>>>>>>>> + >>>>>>>>> +  interconnect-names: >>>>>>>>> +    items: >>>>>>>>> +      - const: ahb >>>>>>>>> +      - const: hf_mnoc >>>>>>>>> +      - const: sf_icp_mnoc >>>>>>>>> +      - const: sf_mnoc >>>>>>>> You know... Failure to look around is a sin. What are the names of >>>>>>>> interconnects used by other devices? What do they actually describe? >>>>>>>> >>>>>>>> This is an absolute NAK. >>>>>>> Please feel free to correct me here but, a couple things. >>>>>>> >>>>>>> 1. This is consistent with >>>>>>> Documentation/devicetree/bindings/media/qcom,qcm2290-camss.yaml. no? >>>>>> I see that nobody noticed an issue with Agatti, Lemans and Monaco >>>>>> bindings (Krzysztof?) >>>>>> >>>>>> Usually interconnect names describe the blocks that are connected. >>>>>> Here >>>>>> are the top results of a quick git grep of interconnect names through >>>>>> arch/arm64/dts/qcom: >>>>>> >>>>>>       729 "qup-core", >>>>>>       717 "qup-config", >>>>>>       457 "qup-memory", >>>>>>        41 "usb-ddr", >>>>>>        41 "apps-usb", >>>>>>        39 "pcie-mem", >>>>>>        39 "cpu-pcie", >>>>>>        28 "sdhc-ddr", >>>>>>        28 "cpu-sdhc", >>>>>>        28 "cpu-cfg", >>>>>>        24 "mdp0-mem", >>>>>>        17 "memory", >>>>>>        14 "ufs-ddr", >>>>>>        14 "mdp1-mem", >>>>>>        14 "cpu-ufs", >>>>>>        13 "video-mem", >>>>>>        13 "gfx-mem", >>>>>> >>>>>> I hope this gives you a pointer on how to name the interconnects. >>>>>> >>>>>>> 2. If you are referring to some other targets that use, "cam_" >>>>>>> prefix, we >>>>>>> may not need that , isn't it? If we look at these interconnects >>>>>>> from camera >>>>>>> side, as you advised for other things like this? >>>>>> See above. >>>>> I see, so the names cam-cfg, cam-hf-mem, cam-sf-mem, cam-sf-icp-mem >>>>> should be ok? >>>>> >>>>> Or the other option, go exactly like >>>>> Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml. >>>>> >>>>> What would you advise? >>>>> >>>> To keep it consistent with the previous generations and still >>>> represent the >>>> block name, we will go ahead with the style in qcom,sc8280xp- >>>> camss.yaml. If >>>> anyone has any concerns, please do let us know. >>> Krzysztof, Bryan, your opinion? My preference would be to start using >>> sensible names, but I wouldn't enforce that. >>> >>>>>>>>> + >>>>>>>>> +  iommus: >>>>>>>>> +    items: >>>>>>>>> +      - description: VFE non-protected stream >>>>>>>>> +      - description: ICP0 shared stream >>>>>>>>> +      - description: ICP1 shared stream >>>>>>>>> +      - description: IPE CDM non-protected stream >>>>>>>>> +      - description: IPE non-protected stream >>>>>>>>> +      - description: JPEG non-protected stream >>>>>>>>> +      - description: OFE CDM non-protected stream >>>>>>>>> +      - description: OFE non-protected stream >>>>>>>>> +      - description: VFE / VFE Lite CDM non-protected stream >>>>>>>> This will map all IOMMUs to the same domain. Are you sure that >>>>>>>> this is >>>>>>>> what we want? Or do we wait for iommu-maps to be fixed? >>>> Yes, when it is available, we can start using iommu-maps to create >>>> separate >>>> context banks. >>> It would be necessary to justify removing items from the list. Wouldn't >>> it be better to map only necessary SIDs now and add other later once we >>> have iommu-maps? >> I will let Bryan take the call on this. He was the one who wanted all >> the SIDs in the bindings. Hi @Bryan, if you can kindly share your >> thoughts on this and the interconnect naming, we will go ahead and push >> rev 10 for this. I believe we have taken care of other things. Thank you. >>> > > Since when are we delaying patches for future patches that may land never ? > > I'm fine with whatever clock name changes you can agree with Krzysztof > but it seems a bit ironic to me to be given feedback to "align with > previous dts" to then have the result be further change. > > I'd like a bit of stability and consistency TBH. > > --- > bod > My feedback is - Include the full list of SIDs - Stick to previous clock and interconnect names Your other alternative is to suspend Kaanapali CAMSS unless/until iommu-map is landed. As I say though "change your patch until my other patch is landed" is the opposite of how things are supposed to be done. I recommend you focus on your own series. If iommu-map gets merged first, adapt. If not, don't delay your work to accommodate stuff that is up in the air which for all you know may never land or may take six more months. --- bod