public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
From: Bryan O'Donoghue <bod@kernel.org>
To: Neil Armstrong <neil.armstrong@linaro.org>,
	Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>,
	Bryan O'Donoghue <bod@kernel.org>,
	Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Cc: Vinod Koul <vkoul@kernel.org>,
	Kishon Vijay Abraham I <kishon@kernel.org>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	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
Subject: Re: [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
Date: Thu, 19 Mar 2026 16:56:28 +0000	[thread overview]
Message-ID: <a42f837c-4b90-4e0f-a98f-793fbd20a140@kernel.org> (raw)
In-Reply-To: <7eda931a-f30e-4e01-a130-996ec7f450d1@linaro.org>

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

  reply	other threads:[~2026-03-19 16:56 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-15 23:52 [PATCH v4 0/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver Bryan O'Donoghue
2026-03-15 23:52 ` [PATCH v4 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema Bryan O'Donoghue
2026-03-16  1:58   ` Vladimir Zapolskiy
2026-03-16  2:45     ` Dmitry Baryshkov
2026-03-16 10:49       ` Konrad Dybcio
2026-03-16 12:09         ` Bryan O'Donoghue
2026-03-16  7:42   ` Krzysztof Kozlowski
2026-03-16 21:31   ` Vijay Kumar Tumati
2026-03-17  5:26     ` Bryan O'Donoghue
2026-03-17 20:25       ` Vijay Kumar Tumati
2026-03-23 14:22         ` Konrad Dybcio
2026-03-23 14:29           ` Bryan O'Donoghue
2026-03-15 23:52 ` [PATCH v4 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver Bryan O'Donoghue
2026-03-16 10:12   ` Krzysztof Kozlowski
2026-03-16 12:04     ` Bryan O'Donoghue
2026-03-18 10:15   ` Neil Armstrong
2026-03-18 13:17     ` Bryan O'Donoghue
2026-03-18 15:07       ` Neil Armstrong
2026-03-18 15:27         ` Dmitry Baryshkov
2026-03-19 13:08           ` Vladimir Zapolskiy
2026-03-19 13:17             ` Bryan O'Donoghue
2026-03-19 14:05               ` Neil Armstrong
2026-03-19 15:06                 ` Bryan O'Donoghue
2026-03-19 14:56               ` Vladimir Zapolskiy
2026-03-19 15:18                 ` Bryan O'Donoghue
2026-03-19 16:08                   ` Neil Armstrong
2026-03-19 16:56                     ` Bryan O'Donoghue [this message]
2026-03-19 17:39                       ` Neil Armstrong
2026-03-20  0:37                   ` Vladimir Zapolskiy
2026-03-20  9:56                     ` Bryan O'Donoghue
2026-03-18 15:47         ` Bryan O'Donoghue
2026-03-22 16:44   ` kernel test robot
2026-03-22 23:31   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a42f837c-4b90-4e0f-a98f-793fbd20a140@kernel.org \
    --to=bod@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=dmitry.baryshkov@oss.qualcomm.com \
    --cc=kishon@kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=neil.armstrong@linaro.org \
    --cc=robh@kernel.org \
    --cc=vkoul@kernel.org \
    --cc=vladimir.zapolskiy@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox