From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 152823F1659; Thu, 19 Mar 2026 16:56:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773939374; cv=none; b=cidSuD50Epp0OPuBiRo5l8qSCqjy/2OeS95PfIvyLz+a07/BTuZP3Zo9hKyUUbTCC3YIGDENkKqhGpYF/Uh3UR6HjupdV2/3aUDCJ0VUvXKtS4l1xSWygC1GXs5KRm3G3AxWChxLQyrpNlkAunmRLERfSBuIE2KtncH3EGU1PuQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773939374; c=relaxed/simple; bh=buYrNumzH/okacfb8t8YTg6twr52GbLA8hyuw2Qrde0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=M6aPlqTbge9HpIPY0dX3edqpUzvYbrQGoWwitdyAlBH5cmWc6vd7NVjhOZpqkaFCeZv+8CnVII2Knbb2LbzUAXJjmrQC0h/jfbMUrJVGQl7ARsmQrfDOCK6FjMKka6sjLWmT+0ew1tKMce3rN4znmkPK6Z2bKDsz7b4V/au7tLQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=VfxAbked; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="VfxAbked" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1545C19424; Thu, 19 Mar 2026 16:56:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773939373; bh=buYrNumzH/okacfb8t8YTg6twr52GbLA8hyuw2Qrde0=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=VfxAbkedya6W5dDpsCCpwpmqzNrQQwq+Jsd47RPrQBhpDQg5YKcZg3o6RQS7d5chf 0pZhvP2Kf9atcFnbXgfmOfakWJr2AgcWSZXtII5w6wS1sn3OrlzhgvgqHFHAakwhUE jLuGyXKwkdtQEuVFMCPzRKYB1pv8r9+IxZcmoraAeECHGHUEevPSs0l728rlx64hJ8 azh+bRjkRGst9R32RskjuPDo42tPB9fQJ0l6DgcUtHbL4wTgo7qLtQ/xvJ+epBOR2P uG0spqZ8z3ngmo+1mYHLOh7ngaDTuOe1FGf+iHY68yf8o5L3tBi+VVch6pMJ0Pg07b VmbqZRxYFqwLw== Message-ID: Date: Thu, 19 Mar 2026 16:56:28 +0000 Precedence: bulk X-Mailing-List: linux-media@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver To: Neil Armstrong , Vladimir Zapolskiy , Bryan O'Donoghue , Dmitry Baryshkov Cc: Vinod Koul , Kishon Vijay Abraham I , Rob Herring , Krzysztof Kozlowski , Conor Dooley , 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: <20260315-x1e-csi2-phy-v4-0-90c09203888d@linaro.org> <20260315-x1e-csi2-phy-v4-2-90c09203888d@linaro.org> <3f11de22-b729-4d06-b6c8-18e649e1979c@linaro.org> <80ddc2b4-d6f8-4e8d-a45e-69c05d100aa2@linaro.org> <16b10f17-ecd3-4cdd-ac3f-f64127d60ace@linaro.org> <26XTdUyQTB41Oc4D5HnMtSm_QpZRjlkljQRJVw-u1Zp3Ltn9s4LVU-LQkP6drdl3Z3GGssLCCbsVYPFEqssHcQ==@protonmail.internalid> <65e06b2e-eeb9-45af-97ac-4ae60f652361@linaro.org> <9578400d-30ac-4d8c-9295-ee4ec8af3b2c@kernel.org> <7eda931a-f30e-4e01-a130-996ec7f450d1@linaro.org> Content-Language: en-US From: Bryan O'Donoghue In-Reply-To: <7eda931a-f30e-4e01-a130-996ec7f450d1@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 19/03/2026 16:08, Neil Armstrong wrote: > On 3/19/26 16:18, Bryan O'Donoghue wrote: >> On 19/03/2026 14:56, Vladimir Zapolskiy wrote: >>>> There's no reason to remove that from CAMSS - it would be an ABI break >>>> in user-space anyway. >>> >>> If technically CAMSS CSIPHY could be excluded from the list of CAMSS >>> media >>> subdevices, then for the sake of simplification it should be done for >>> all >>> supported platforms in advance, such a change will be independent >>> from this >>> particular phy series, and vice versa, this CAMSS only driver change >>> will >>> prepare a ground for media-less CAMSS CSIPHY device drivers, hence it >>> shall >>> precede this particular CAMSS CSIPHY series. >>> >>> For backward compatibility with userspace a noop stub will be good >>> enough, >>> it's not an issue at all. >> >> The standalone PHY driver doesn't require removing the CSIPHY media >> entity from CAMSS. They serve different purposes and coexist - its >> important to have a NOP from user-space perspective for legacy and >> indeed for new implementations. >> >> How the PHY gets represented in the kernel is of zero interest to >> user-sapce. >> >> That said, stubbing out the media entity is independent work that can >> happen in any order and IMO is a separate debate. Whether or not >> CSIPHY init sequences live inside of a monolithic CAMSS driver or live >> inside off a discrete csiphy driver is not related to the media graph. >> >> Happy to have that debate - and if indicated, carefully apply patches >> separately. > > So what does this actually solves ? > > Neil Per-PHY voltage rails, per-PHY power domains and per-PHY OPP scaling. Using the PHY API instead of rolling our own, as well as separate nodes in the DT. We've been getting away with power-domains, opp scaling etc by sheer luck. The feedback from the list alone now addressed in this driver makes the conversion worthwhile. --- bod