From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) (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 06238253F11 for ; Mon, 20 Oct 2025 10:56:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760957771; cv=none; b=Si7vvLZQ6gxnIDa/rotMHNX4NhmoaEPkeu0nFYaZ87fTckg2Luf+cNNC3tDN2xNH0TNHI1H/pyc4jzZeNB8PggDy43iQmQPH1RX8TPvPU1Wl/xsQgLGjoL1dH8R/sgizLnIVk9TTUJfePv0wL6qzUhIn1zfNjtW4RotAcsu1L5Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1760957771; c=relaxed/simple; bh=IydQHlopurRsMIlFXXQnBsVqX59j3tYYZ9wp3B4KoGw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qYEeDxUC9CdoJD5OU2eQkAFJ3JoUA47EDVEYEPE8wZLibwGts0fEhC641c3Y2k7nujiK3E9n7CkpTOOLTjNBU33tRBfr4nC9QUyB+2S+F98HRg8D83VM8pM5Vl6DHU2F9ureZR240TGNDm4Wek5aoJY4tb9550vnfQSAfxc8btM= 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=uBhbmlaS; arc=none smtp.client-ip=209.85.221.54 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="uBhbmlaS" Received: by mail-wr1-f54.google.com with SMTP id ffacd0b85a97d-42701b29a7eso1886652f8f.0 for ; Mon, 20 Oct 2025 03:56:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1760957767; x=1761562567; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=O50PUVrDxE9ib0IbMfL05smlWaDICzzt8kT2K5/ErZQ=; b=uBhbmlaSfddAoMrlIpZt99EKU4O+QzROEHKWlEWVOhpxCcHpRkv8nGt+Y5c6WPzV4O Ol1gyPNixSQGIIbgldDyhQcmbCTP1shIv9qiScdknkmRQ217UZGu6jTtMJoORQ0XKzoD T+5xbOh8wSiGQutwtzoEABqZYK8C2/MbM57QU7+lmbf7sHUAR6Mw6SEWV7dE78JpYlsq 8XQqm+3k2JV6XqGP9uS8wmlKDgBAIApSOziEQ8np6CfKWrIBJ1L94zj+gddnFf2WxKim qT5konw3qIMntlha4nYJMt1ei7UWkhFmRhJf7RnKwAR8lcQT3OPy4O1Qml8FtGi4FFme Pa2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760957767; x=1761562567; h=content-transfer-encoding:in-reply-to:content-language:from :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=O50PUVrDxE9ib0IbMfL05smlWaDICzzt8kT2K5/ErZQ=; b=WF8PO1209feTMKkKYxUdNzuD1bhpnYPPwzGBA2BbEzi8B5STW0DuOz2cM3MfSTQxVD DdRNavFRXd3WsxnjYqogSKCteHc26hVHWKXaix7cMYVR4O7D29vVX7ZCCa9kltskd8aC CL9U2q+XJM/xTw92rzP/FBPqjRrHKLtwbzDuQPeEyXjFJ10OutlchXdrB4GRZgKC+u5c sJUF/RoU/hLJblWpsF/xtm4lf2F1+nS01LLRWgCoXXSsHjpkBOrsDPLUFW3S2ZO0kWXe MXTk0zFvnp3uRmG3idGP2ZZZ3mfDMLXJLQNlofuu+ajH4LJNBa4+wiw/6Lm6b0e15LLo EHrw== X-Forwarded-Encrypted: i=1; AJvYcCXwmZr7rljd0jDFYZLQdG2XnlIyngXRVuuOMyCeh6/eSZJZz2YgrkFxFP5s2KAkBs1cIb2xz2gbNmCOBmnS@vger.kernel.org X-Gm-Message-State: AOJu0YzUBMtPxa0AIxtkf/U+PejcsuzxZmnZ/FpTHYZbxfMSzw+yhloU OlU3cDYfVbYVAahxqFEHvSYBGrCMAFCL2CVGF/lq0R2PwDfSj7IPvlrKIWyrlomJVs0= X-Gm-Gg: ASbGncsrXfZAuaun2HQuLFilBJ/umG2rU8FVCp4XYJOiywJ29boLMytG0A62Sbqjevf bKNAvd4qlGQUIJXGtW62XKkjOIay6cYLHoFxJCDoBDsgJdMG7iru8FRuhpvW6WbnQBO3KYWt3nJ dzA8aE/6UdsDhCbWdGja9dP9Gkn+D8BQs8Fb4Ov/R0SF+u4VnsGnuzFZRof/Hxe97YiprH3icUf I4ycSS/Ny95C7HT363Bnu9G6fajZjOIZ9GSZ2OicSJosMqbS53Jq6bkqWcH8+Niboe5yoBQHJZY iGt8RjUBtN4TQ2iqdBWAa8d9+tAeTb/9ut/In8gbuXwz1JrNgNZCCbybj+265awhYZPITpGFv5p cs7w/yDaz86AJy/OX727EAqCRa0jeL0drl0dmDqENeU4a/qp49PEbfEfJNnSOOFPZFvEp/5ghsI mNzcFzg5NoQzRu1ja0JT7WXow94eoEh19Mg95X7E0eD8U= X-Google-Smtp-Source: AGHT+IEnxRa9WBYZ/xihOvJBRUTwTryLwgmhlm6XUxYYKxvIXYWvfiDdFtfoAj1aZpKnj7X7vI055g== X-Received: by 2002:a5d:588b:0:b0:427:1ae:abc7 with SMTP id ffacd0b85a97d-42701aeaffemr10842435f8f.2.1760957767322; Mon, 20 Oct 2025 03:56:07 -0700 (PDT) Received: from [192.168.0.163] (188-141-3-146.dynamic.upc.ie. [188.141.3.146]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-427f00ce06bsm14495252f8f.45.2025.10.20.03.56.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Oct 2025 03:56:06 -0700 (PDT) Message-ID: Date: Mon, 20 Oct 2025 11:56:05 +0100 Precedence: bulk X-Mailing-List: linux-arm-msm@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 2/6] dt-bindings: media: camss: Add qcom,kaanapali-camss binding To: Krzysztof Kozlowski , Loic Poulain Cc: Hangxiang Ma , Jingyi Wang , Robert Foss , Andi Shyti , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Bryan O'Donoghue , Todor Tomov , Vladimir Zapolskiy , Mauro Carvalho Chehab , linux-i2c@vger.kernel.org, linux-arm-msm@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-media@vger.kernel.org, aiqun.yu@oss.qualcomm.com, tingwei.zhang@oss.qualcomm.com, trilok.soni@oss.qualcomm.com, yijie.yang@oss.qualcomm.com References: <20250924-knp-cam-v1-0-b72d6deea054@oss.qualcomm.com> <20250924-knp-cam-v1-2-b72d6deea054@oss.qualcomm.com> <7140b8a8-1380-4859-84a3-681b3f1ce505@kernel.org> From: Bryan O'Donoghue Content-Language: en-US In-Reply-To: <7140b8a8-1380-4859-84a3-681b3f1ce505@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 20/10/2025 11:16, Krzysztof Kozlowski wrote: > On 16/10/2025 12:43, Krzysztof Kozlowski wrote: >> On 16/10/2025 10:47, Loic Poulain wrote: >>> On Thu, Oct 16, 2025 at 7:52 AM Krzysztof Kozlowski wrote: >>>> >>>> On 15/10/2025 05:21, Hangxiang Ma wrote: >>>>>>> + - const: csiphy4 >>>>>>> + - const: csiphy5 >>>>>>> + - const: vfe0 >>>>>>> + - const: vfe1 >>>>>>> + - const: vfe2 >>>>>>> + - const: vfe_lite0 >>>>>>> + - const: vfe_lite1 >>>>>> Wouldn't it make sense to simplify this and have different camss nodes >>>>>> for the 'main' and 'lite' paths? >>>>>> >>>>>> [...] >>>>> No such plan till now. Other series may take this into consideration. >>>> >>>> We don't care much about your plan. You are expected to send correct >>>> hardware description. >>> >>> To be fair, other platforms like sc8280xp-camss already have the >>> all-in big camss node. >>> Point is that if Lite and Main blocks are distinct enough we could >>> have two simpler nodes. >>> Would it make things any better from a dts and camss perspective? >>> >>> camss: isp@9253000 { >>> compatible = "qcom,kaanapali-camss"; >>> [...] >>> } >>> >>> camss-lite:ips@9273000 { >>> compatible = "qcom,kaanapali-lite-camss"; >>> [...] >>> } >>> >>> That approach would create two distinct CAMSS instances and separate >>> media pipelines. >>> However, it may not work with the current implementation, as the CSI >>> PHYs would need to be shared between them. >>> >>> I guess this should be part of the broader discussion around >>> splitting/busifying CAMSS. >> >> And this discussion CAN happen now, stopping this camss and any future >> camss till we conclude the discussion. Whatever internal plans of that >> teams are, rejecting technical discussion based on "no plans for that" >> is a really bad argument, only stalling this patchset and raising eyebrows. > > > To be clear, I expect Loic's comment to be fully and technically > addressed, not with "no plan for that". > > This blocks this patchset and any new versions. > > Best regards, > Krzysztof I think we should stick with the existing bindings. There is no "lite" ISP there are so-called lite blocks within the CAMSS block. It makes sense to split out the PHYs from this block as they have their own power-rails but, if you look at the block diagrams for this IP there is no specific ISP lite, there are merely blocks within the camera called lite. It might be nice to structure things like this arch/arm64/boot/dts/rockchip/rk356x-base.dtsi with each component separated out into its own node with its own compat string but, I'd have a hard time justifying changing up the bindings we already have for that reason - aside from anything else - all of those components in CAMSS live inside of the TITAN_TOP_GDSC which is the power-domain for the whole camera system. So not meaning to answer for Hangxiang but, I think the compelling logic here is to stick to and extend the existing bindings. So in fact I have no problem with the bindings as submitted - not including the regular fixups these types of submissions entail. --- bod