From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f46.google.com (mail-ej1-f46.google.com [209.85.218.46]) (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 92B3B3B1EF9 for ; Thu, 4 Jun 2026 11:04:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780571046; cv=none; b=HgQxDUhE8uKpmWOzE2HbRmcAXYc7B0w+jmahKYrjZLmlyBbtOK2OvMaXvYWK6XTKoZ/jvOi8nos3aKff6zecUeJct6jMISVgLBVnZOAI2Q/EDWJhOedH+uouaH17gh94i/umTPqN9GIdYLxz3ZFPg55U9AZo1BOAENwgPcO4W2Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780571046; c=relaxed/simple; bh=B/gjocXEAZZGmLbh3FhqexUI+meJYXHmU7OgkVbES/w=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=afXGSgaGOcCLkW0zj7CQOtzeI1aHUP8ViUeFPHBgVtEr0CuAcndFFMdPBUFhmpMosfIzvEs/oyoXiDVybiy9ek3XpQBylKWdDYMA6DSLNx5w1yc2LFFcqSUsOhzp1ZxZv/OcFt+L2nwnV7w9+feJXYgo+QlXlU17zNcXTcKFZ78= 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=DTspu87a; arc=none smtp.client-ip=209.85.218.46 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="DTspu87a" Received: by mail-ej1-f46.google.com with SMTP id a640c23a62f3a-bec449cf976so73880066b.2 for ; Thu, 04 Jun 2026 04:04:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1780571043; x=1781175843; 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=qrF+chW03A8IR47Oi/Ih5ziYJf7j0S60VPCDD4Eshmo=; b=DTspu87azbMkQuxkfIWza06Jqreuyx+qk+wSzim94G4A67q7Cf+AB30XvZRwMxRi3o Vf13fylRYcGUFjz0hRk1AxyzSXWlgNc/WXdbn5s5VypxhbE7/8Nk6j6SPdTX0FCUryk+ 9Kqx34igt6f6WOxqL8koibzHEqUMSbKXtAK/ptuH0oXvWoTgDjs7sCC7ujItlF7WozfT JjkUFbKeh9oRSCFtLi2SepRRJfIOsswM3FK5DtycUm4XBAa3z8oPA955J4anZk5+wpxS gFNnndebqRTdIhAFrGhiu2tZ7fR00wHe3/Y1dvj6mUrd7+k31jhcTILmNz+2K4ILV8ww iJgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780571043; x=1781175843; h=content-transfer-encoding:in-reply-to:content-language: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=qrF+chW03A8IR47Oi/Ih5ziYJf7j0S60VPCDD4Eshmo=; b=Lzbd7L7p22+D0Cb4PQvX94EksScG1UO+YElC1I6aABVkIB2Z4cU4AI2ymPgLU+3MEs aQQs1hVh5M9R4k+Ofy5eEwhH8gNb9fql5lzo0QdXFJfFZKMZCrt0MkE43JYQNyvZTEpw VJEz7ITlqlvdkAoFhakjiPiyf11F8W4obeGuSHRNLhKQIQyi/HUmXCAaVrfABBkqJKV2 mHCYsntmtnsbj3X+xwN3KNzxeLZ1xV4zCzlR9dklFl4SobmzUJbYpPbazWhfFNvsqCVu wquOpDA/Pg+HMzNUtbldQDG9H5U5zFwotBvATb8+LW29hIsEjjogyvQ8Q5xy7GwQc/Xt XAZQ== X-Forwarded-Encrypted: i=1; AFNElJ+NwJaDOH46JnsEj/56tXSsnG39qbfTf3vm64a7LXjz1JBH4oQMQzY6MGocixIuJVlalGsNb7CAYO9vFWM=@vger.kernel.org X-Gm-Message-State: AOJu0YwN5cLaFrSwr7qqAO4yDIdTn3ZXt962irGmsqBLMWhpji4dDusK EjBLGyf4i2DjS6xJk/7I6Bopg38V+z6Mbw+d5d6WB2qlYY6PqGymtUkpDiutvfeiKjjMp/jWw8Z z3R2l14s= X-Gm-Gg: Acq92OH22JgUKVxzYthLC9bQGc/08OKUGja68z5WfUTzmSUiuQY6pNSubUe7jw4wiDT rUZhUVU8LAridklownD+ctzZdUfdTuhTcxgHmdvoZwxscYCHpYdU20dGS9BCOHCQXR4ZjU7FOSL FpYp3R2Fva0o6haI34/dP3pUE8Hqku9RwfXqQXGRqGE8XxacSfntrfXP/ozuFrhOYyKjLU/s4AJ bQFolYJcUCGQ4AdbJlIzdTmp5sDFE3tg7M770/bmMbc2BIivqYc6xLCX1Jdu0aQSXaHLct1lO3w u74WHbNe4xqnCG9BNhBL/gVNSmCWqJs7GNKqyhLy/n8RHHzOIZ1PXhj2VqlAfuicq30GZ3e344f ihf0xzsJo96QbDc67yuPC5vTgieWzmXJ2JHFghUIxxIffMLB57KYP5eeY9vZEwnYb0qtE+DPKxr oRN3ufah4g++Oyb6nf3XqfFHv+sSrfPOhfHCWlpGdppOAq/48= X-Received: by 2002:a17:907:6092:b0:bd2:bd3:1ef8 with SMTP id a640c23a62f3a-bf0ab021c93mr446755866b.35.1780571041852; Thu, 04 Jun 2026 04:04:01 -0700 (PDT) Received: from [192.168.0.101] ([109.76.175.228]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-bf05228a16csm287937966b.28.2026.06.04.04.04.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 Jun 2026 04:04:01 -0700 (PDT) Message-ID: <139130d0-1f59-49aa-b174-9e1860eb8465@linaro.org> Date: Thu, 4 Jun 2026 12:04:00 +0100 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: Vladimir Zapolskiy , 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> <9ab0d8f4-e1b6-415b-976b-721ab7a29194@linaro.org> From: Bryan O'Donoghue Content-Language: en-US In-Reply-To: <9ab0d8f4-e1b6-415b-976b-721ab7a29194@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 04/06/2026 10:20, Vladimir Zapolskiy wrote: > 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. Completely not a discussion about software. DT needs to represent hardware. Its a different mindset. I don't think we are going to resolve this debating the same thing again. My position is the CSIPHY should list the set of power-domain dependencies it has. The PDs don't come from any other thing in the CAMSS block so the producer/consumer model is CSIPHY to CAMCC and CSIPHY to RPMPD respectively. I'll just ask @Rob, @Krzysztof or @Conor to offer up their opinion as DT maintainers and work from there. --- bod