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
next prev parent 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