From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.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 41C133DEFE6 for ; Thu, 4 Jun 2026 08:46:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.167.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780562778; cv=none; b=HkbB6mJsk0NAOh6OmdfCpULi+K0QfEK9u8Ko6q5XBaA3cK+ulyBHt0HLv0BMk+Nf00uCdS9VI2Zt5S0e5+kA77soq7ZKKdiJ2iAGz0uKfrpoEdY2xNFw06jytMVO0xn8JDVMMGjcCOXG4rDB+tejBd0ocXaGunBiKtX44mlBPuY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780562778; c=relaxed/simple; bh=DKBAaG/N5R4rrztzGTcNqmxNSYvmbc4YOW44ZQWDhZg=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=bEODKf29socC529tcWxXRayfneABkWFfZ+O9O5pHGahLdboSWq+MJdsHZICA7qke1FuDQ2Tb1JDkQEuBJmSDplRbR1HnNTxd7yEKXM7Wfcsq41/c15ofRk5J4K93KjabfmZE9yNQx50zoiqKocMOrH0IAbtvqVnnt2FTTpzjPZY= 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=TrGhWNKe; arc=none smtp.client-ip=209.85.167.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="TrGhWNKe" Received: by mail-lf1-f54.google.com with SMTP id 2adb3069b0e04-5aa68daa847so11459e87.2 for ; Thu, 04 Jun 2026 01:46:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1780562776; x=1781167576; 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=ysCy4i0ZuZGHTLV0NNKNvTSVjrjWNaqQ7rMKNBVAW0s=; b=TrGhWNKesFMoOF8eV2aRD6QPSe1hm37sPWKH58MN2wL4Rmi+DbKnafC1zFjBDFHVWu DsNfED04TBlgLFeQypnahib8eiuR4MSfTKMv/jrXfO8ZiNZwt90wlL0Vddcr0m7Bub1g kKbSmtBVFVT0yfwKWZGYakYf+2F0IicrJmB9SUhK8g6JDEfSfDsyZ/qniDdyqpiSWBUK P5fU8kjwYG9IRTklbFraqBMqPccMRVlxWCx2inALca4ceIzwHTJJHnN6ikvrtezk8Uxi mpsRp8GMqKIEvw42y7o2CeDoxk13g5Hh3sICBkzR35g9UaFLBZ9/syaz9mXsiYCAscVI ZmoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780562776; x=1781167576; 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=ysCy4i0ZuZGHTLV0NNKNvTSVjrjWNaqQ7rMKNBVAW0s=; b=X7PW4IywzR5jbHGsP3oruKb50FF1WWFLk/eykBg1KLgeexVk9PsphpT82lF/T0qpHA 7ZTrKfMoGiWq0CQAga3QZ2Gnp0i66WKugb4wnyq7VDLLg9nxB4836dmbfLNzYIQ02hxl lb3OWCahy2Z1ZxrnCQQ7oTIAv2dZXq4IKBbOdbk+0u1iqCqZ04iZjSY+clxUC2EHCl2H +ATxdwd0825JO9QYKEsaBOJ33C437GQGa4TQ8zAcMtE4E13J6Gp8arFUTKAbqgQmbmAl sG/kQ9X4D3gXwHDOGyogYGNvSTBJli6wlkwdKds0B/fnF0Oyll/D9UqE3Mh3I+BsnSzo Md/w== X-Forwarded-Encrypted: i=1; AFNElJ98NKtP0HNiVBcrWGo1aT43GL2vtftw+8UrkQ/u1ykC6uub9LGM59FIz0Zr76DcthI8TESFwVVXFjTtGXY=@vger.kernel.org X-Gm-Message-State: AOJu0YyX3PXfsqlGtKLCZs0+33RO/MTX9HxImSbTcD6riGLolXX8srEa a8BKU+1DS7ZWHgbqMXM0CZ8xZOxTkX0bKDD1tJHq9oPd+H2lnCovgmGrAVNgXu0Envc= X-Gm-Gg: Acq92OEH6CSwwL0YBQjqXm0itr6OPeBWkAqMy5CimoKs0UxDyNYqPxlNiLdlFXLCnGp 2GYom5LVml/cwzKUhliYvU8iOGffAgNxzQL1Bzfij5yCrDJTylOpydi+ilfJxaQKeezU71AKM/v dICLfEdssH1gtu8P5SZ49fkIbEcKhnDz+SNc9TZs0wlK9F/e7drQitVV5X1L/lxk68XhuBNfJ0q yl1ymjU4LdOkd/XSzSerjxK+ak0Rx5vtXVOZtFw73bS2D66TSdaZXILRsQ6seg+jGuILyu65/s1 r7L+wn4jg6jOhlz4a43NCA4XM8aNu76C99upI8nqD+3v5C3PoEdD8R4p3L6M0XOx3alYFRUz+Yv IhPiGXRkVzw1gVRaU1G6OtD5iICpKmL2+cg7wsMrb8STpgPFzi3vy1/Avq1LfS7lAz7HuuI9Yly fJxjaZc/MHfdN3ljsLVHHa0d3x1WUKwgHMUwUaEYnGM9bJ5LGbLeaFh0QHfDiccY+GRAktd1sIN PTXrlZZtQj9tK6M X-Received: by 2002:a05:6512:24d8:10b0:5a8:7317:540b with SMTP id 2adb3069b0e04-5aa81f36e3dmr159818e87.7.1780562775465; Thu, 04 Jun 2026 01:46:15 -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 2adb3069b0e04-5aa7b99c74esm1075006e87.81.2026.06.04.01.46.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Jun 2026 01:46:14 -0700 (PDT) Message-ID: <1b107aca-a857-4e58-a763-39c82af67747@linaro.org> Date: Thu, 4 Jun 2026 11:46:14 +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> From: Vladimir Zapolskiy In-Reply-To: <83c12dc5-fcb4-4089-9917-9f0fcc4f940d@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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. > 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. > 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. > 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