From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (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 4C17F3F44C3 for ; Thu, 4 Jun 2026 09:20:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780564852; cv=none; b=OcJ555l86eco6dmFX1KtEAU2lwDE3B+KJRPaL4KLmTk/JMmX0/x3HlUJ9xOpVZ+IlXOkrQ6OSOyn5bolKR1IZiw51p5ER6lYhiTSxN/M6BuhtBGBuiD+jfxpClqQVMy4mB3LeNiOgG+w7PtJ9o0mEL93QGzSSnwcHIczZwh7PQY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780564852; c=relaxed/simple; bh=WCmb9+DZHNXcKsfaqnMvmzEYr12OVR4soMLhduJC3Es=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=ChKZokRWkdefmxj7ZERMqQsocc1z4e2o7CPFbsiy0hUQ5ZXrHuxil3VGZc35+3Q/Dk1zcQr/8+1MRgKBvN8kq5zScconTnpCdcJiMjz6WhOijZUjSdeUV46JJhGF7rjq1HYci6FBaGOvnOk0qszrKrGvRvWyUyMxrRRneKuKI5o= 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=f9WtFGKR; arc=none smtp.client-ip=209.85.208.173 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="f9WtFGKR" Received: by mail-lj1-f173.google.com with SMTP id 38308e7fff4ca-396709ba436so777121fa.2 for ; Thu, 04 Jun 2026 02:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1780564847; x=1781169647; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=mmJhxd6Spss8k56OkvnPH6btFz24l1uTr3gxaOR02sU=; b=f9WtFGKRkPuBnHZtizCUjJYzQaa3Nc7lgf4zXaBa3y2ewSm/pcdM0fit55u+mhYF9c CEao1AWAk4oSxOu0OAcDiFy6vafnMR0QKNtWNjrx+9lv1Jp+EgkfoWoXGsTn9HY5MY1T a/EJcMZlVUiY69YPwSLsBSxouoUjSgJSq7nWMtTk8riY48ObMVk8c6iwNZtCoVS87tp6 //jscplnHLdb1GwMRe8U1JIB8aYl4KRkxQXluOnQyIuR4X9Zos+Eytidq7PiT+k/R0l0 AZqgpOcEkp5BuF1nOtzmtXW8Qdrax/kNLwv7YDRQDGc2ak4TIO9Wy1ZMhx6vN2TddOYB o1pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780564847; x=1781169647; h=content-transfer-encoding:in-reply-to:from: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=mmJhxd6Spss8k56OkvnPH6btFz24l1uTr3gxaOR02sU=; b=BDRqZKeoK315/7BXEzUhushIBGcdUgorfgXaNXmJ5kID+9irryCRFssZqeTYjLjPsJ 8xqNCwBc79n/kz24AMChkpWQP5H32TO9V9uX548xnMRgzHACPbUmiccu4zjZYMRpfh7v KHjkAsIY5ZP3Gbf1LJJ2QeGXjufDSTgKdOmhgCg8TKOcXunu7bxpWVucd41z4mgDFVUo PBcjs2olAqn6HIleTQ+/NJUIDZrkn5nFI1raq3Gl9aBM6DCZf4NpCbUkkXDJNv1QbMTM +m0i1OJdhcNCKpiN9kXWScyREij25+SX9mvRXU7TrZqU3mB9wVCSZnA24VnILhwEDhqT SFpQ== X-Forwarded-Encrypted: i=1; AFNElJ/cEKJf/IPo4xHRqpOrHL5J+i4XzwCSpPetcNjve/O3O5g+Pmr9XE8n6rna0pCh4m93JQsavWu+KAD2o78=@vger.kernel.org X-Gm-Message-State: AOJu0YyQZT0HctDHZIV/F3QsXhKAan3E74SAlWXPz1nIgGly1QYI7JaW PsXFV+Kc9w5o6NvhMT7FlQ9hfRgyNIonRWr0/yVx/OOFYW5jHHDSTdKNWhKqrCh8OXc= X-Gm-Gg: Acq92OF36/ElHN5wnqLByYJ3fsLnT8ZKiPsBEqJu1mz+5fGtJqbsZaSamH1pFmVEcsV bbLF7HFKTcCRxUZg85jGZClf+9wFasTu+8g01A7pwMcV3bc+HRCbT/nVrTzNchlgSuMrFpKP4Fu 33C6w3wPzBtgtiqkh6tuO5ta9t1uG9V2+1FIi1oej6qCJMIyzMGdhFfcu90ueD7B9ycz/o6NRrC mdoyNxD7odN3U9jF3v73dRXo7W43UZQ70C7FaiePs3YdKwKTLR/93qJ2qkbJQ+pq3YvRbxxzNGD T6UeIH1cOYzSI140fFCk9C3Lj6Rph4gAMnn3r8cszT/idceUQT1YXGYGig5AsGqPWyGqnJ6aX9E MIt3L5jrpc9EV4Gx+z1kqE3k4iO5t/chKxGQgm5YiaYj7kJBuptBUsOqJMYEZSfQn/37wC1zA1o x00suRt/jfjq3dLj6RoV/dg1sasqLDgthUqGinVfw0MQT3zAfIDDOkdb045EPs/Ub4zlpSOWwWc QmaIEoiEuvAzhZAp3o/7J29uoo= X-Received: by 2002:a05:651c:2108:b0:393:c17d:9cfa with SMTP id 38308e7fff4ca-396bf225a0fmr2871101fa.5.1780564847147; Thu, 04 Jun 2026 02:20:47 -0700 (PDT) Received: from [192.168.1.100] (91-159-24-186.elisa-laajakaista.fi. [91.159.24.186]) by smtp.gmail.com with ESMTPSA id 38308e7fff4ca-396ac2d503fsm14959581fa.34.2026.06.04.02.20.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Jun 2026 02:20:46 -0700 (PDT) Message-ID: <9ab0d8f4-e1b6-415b-976b-721ab7a29194@linaro.org> Date: Thu, 4 Jun 2026 12:20:44 +0300 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 , Bryan O'Donoghue , Vijay Kumar Tumati , 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> <7JNJ4dUNz4ennJ5dkzhfLSuVo72JpfZAbprICPRqlRYnSzVDJw6x3h-1nESd_PK-3us9f1V3qOiLiywsTqP8vQ==@protonmail.internalid> <29e8491f-20e8-4082-8943-66bee7e3af1d@kernel.org> <5ca611b1-0663-4975-bd56-b1343851e5fd@linaro.org> <83c12dc5-fcb4-4089-9917-9f0fcc4f940d@linaro.org> <1b107aca-a857-4e58-a763-39c82af67747@linaro.org> <67b6f6ae-bfca-4afd-adfb-6ec1741105d8@linaro.org> From: Vladimir Zapolskiy In-Reply-To: <67b6f6ae-bfca-4afd-adfb-6ec1741105d8@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 6/4/26 12:06, Bryan O'Donoghue wrote: > On 04/06/2026 09:46, Vladimir Zapolskiy wrote: >> On 6/4/26 03:30, Bryan O'Donoghue wrote: >>> On 04/06/2026 01:07, Vladimir Zapolskiy wrote: >>>> On 6/4/26 00:18, Bryan O'Donoghue wrote: >>>>> On 03/06/2026 21:51, Vladimir Zapolskiy wrote: >>>>>>> Actually, one more thing, Why isn't TITAN TOP GDSC here?>>>> + >>>>>> If CSIPHYs are true subdevices under the umbrella CAMSS device and >>>>>> well >>>>>> described as subnodes, then likely none of power domains are needed >>>>>> to be >>>>>> repeatedly described in the children device nodes, since this >>>>>> information >>>>>> can be obtained from the parent device by the driver. >>>>>> >>>>>> Technically 'power-domains' property can be safely removed, I believe. >>>>> >>>>> The policy is to describe the power-domain dependency fully since DT >>>>> describes hardware not software architecture. >>>> >>>> It brings no contardiction to the statement I've given above, the needed >>>> power domans will be properly described in the parent device, and there >>>> is no >>>> sense to repeat the properties it again and again in every child >>>> subdevice. >>>> >>>>> Also for a very practical reason a sub-devices can probe/run >>>>> asynchronously of the parent device being active so in fact we do need >>>>> to describe the PDs fully. >>>> >>>> In opposite to the above this one is precisely a software centric >>>> argument, >>>> which should be excluded from the consideration, as well it's not a big >>>> deal to make a proper async initialization, removing excessive dt >>>> properties >>>> is worth it. >>>> >>> >>> Right look forget about that. >>> >>> - DT requires you to describe your hardware. You're not entitled to have >>>     some other device vote for a clock or a PD you rely on. >>> >> >> Above are two uncorrelated between each other sentences. >> >> A device ("consumer") can ask another device ("provider") to behave in >> one or another way, this is the only possible and thus natually selected >> system design, and nothing behind it was asked. There is no justification >> for the proposed flood of multiply repeated data, it's avoidable. > > CAMSS or rather the components of CAMSS modelled in the current node, > is/are not the provider of the GDSCs or the power-domains, it/they are > consumers themselves from CAMCC. Well, this is the argument about software, and software can be changed. > The producer/consumer model is CAMCC to components within the Camera > block. Some components depend on say MXA, MXC, some do not. Nothing in > CAMSS itself is a power-domain provider. >>>     That's exactly the type of downstream short cut we are trying to zap. >>> >>> - In our case we also need to vote on PDs individually when the PHY >>>     is active. >>> >>> In extremis say we are only running the TPG then we have no reason to >>> vote for CSIPHY specific rails or operating points in the parent device. >> >> So, TPG shall communicate with CAMSS, there is no CSIPHY in the equation. > > Right but it would be inappropriate to enable all of the PDs for all of > the components in the CAMSS block when we can do so more granularly. Whenever it is actually necessary, it should be possible to split PDs into generic/parent and subdevice specific groups, it's a part of software implementation. In some cases there might be no need to define any child side PDs, likely CSIPHY falls into this category. > If you drive the CSID with a TPG you shouldn't be voting for MXA or MXC > since these are PDs related to the CSIPHY only and TPG and CSIPHY do the > same thing from the CSID perspective - input data. > >> >>> We could make the parent power-domain argument for CAMSS and CCI but we >>> have TITAN_TOP_GDSC in CCI specifically because we have to model the >>> hardware - including the PDs for that device. >> >> CCI is not described as a child of CAMSS, here the situation is different. > > CCI probably _should_ be a child of CAMSS given the design we are going > for here. > > Leaving that aside it doesn't matter if a node appears as a child node > or a peer node - the DT should describe the hardware setup. If a node is child or a sibling is a hardware description, different hardware descriptions bring different dt properties, this is normal. > I can't imagine a patch that would remove a power-domain from a device > being accepted simply because the node being moved is expressed as a > child of another node. I strongly believe every dt binding describing actual hardware will find its way to be implemented in software in a proper way, it should be doable. >>> If tomorrow we put CCI as a sub-device of top-level CAMSS, that won't >>> negate the need to include that GDSC. >> >> Of course in this case a phandle to Titan GDSC will be marked as obsolete >> or unused for CCI, no problem here. >> -- Best wishes, Vladimir