From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
To: Neil Armstrong <neil.armstrong@linaro.org>,
Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>,
Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>,
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>
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
Subject: Re: [PATCH 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI D-PHY driver
Date: Tue, 22 Jul 2025 11:37:15 +0100 [thread overview]
Message-ID: <7e1073da-6773-489e-80f5-97409f013acc@linaro.org> (raw)
In-Reply-To: <84eea632-02d8-4b7f-a4ca-36ce7159a170@linaro.org>
On 22/07/2025 10:59, Neil Armstrong wrote:
> On 22/07/2025 11:08, Bryan O'Donoghue wrote:
>> On 22/07/2025 09:32, Neil Armstrong wrote:
>>> The whole key point here is the combo mode, as I understood the combo
>>> mode feature
>>> makes the PHY lanes available as 2 separate streams, like if you got
>>> 2 "controllers"
>>> attached to the same PHY. So in fact, the PHY should have a single
>>> node, but 2 PHY
>>> interfaces in combo mode.
>>>
>>> This makes all this controller/phy model very complex to handle and
>>> add a lot of
>>> logic in the camss side. Moving the "csiphy" as an independent media
>>> device that
>>> can declare up to 2 endpoints in combo mode makes things much
>>> simpler, and allows
>>> us to attach each "csiphy" stream to any "controller" side of camss.
>>
>> I think there should be a generic extension to PHY/linux-media to
>> support that instead of something Qualcomm specific.
>
> Can you point out what's missing ? AFAIK it's more a matter of proper
> representation of all
> the CAMSS components with a proper ports/endpoint graph design that
> adding new kernel APIs.
Perhaps I'm not understanding the pushback.
Vlad's design puts the CSIPHY nodes under CAMSS and doesn't use the
upstream PHY API, which if I've understood right is done to facilitate
multiple sensors on the same CSIPHY.
If the kernel APIs or standard representations of CSIPHYs in the
upstream kernel are insufficent to facilitate this model, then I think
that change should be done separately so that all of the existing
upstream stuff can benefit.
CAMSS should have a standard PHY interface. That's what this series
provides.
If multiple sensors on the CSIPHY can't fit into that standard model,
then we need a series to rectify.
I've given an example of how two sensors could be routed to one CSIPHY
in DT. Another possibility is virtual channels.
I don't know if your sensors support VCs, have you explored that ?
If the message is "we need a custom PHY interface in CAMSS for multiple
sensors" then I think in fact what that points to additional work that
needs to be done in CAMSS and perhaps in the kernel linux-media and PHY
layer to facilitate.
Like I say I'm happy to help you guys do that, ship me some hardware.
---
bod
next prev parent reply other threads:[~2025-07-22 10:37 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-10 16:16 [PATCH 0/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver Bryan O'Donoghue
2025-07-10 16:16 ` [PATCH 1/2] dt-bindings: phy: qcom: Add MIPI CSI2 C-PHY/DPHY Combo schema Bryan O'Donoghue
2025-07-10 23:08 ` Rob Herring
2025-07-14 14:13 ` Vladimir Zapolskiy
2025-07-14 14:42 ` Bryan O'Donoghue
2025-07-15 6:40 ` Vladimir Zapolskiy
2025-07-15 8:52 ` Bryan O'Donoghue
2025-07-10 16:16 ` [PATCH 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI D-PHY driver Bryan O'Donoghue
2025-07-10 17:08 ` Konrad Dybcio
2025-07-11 9:14 ` Bryan O'Donoghue
2025-07-11 11:29 ` Konrad Dybcio
2025-07-14 14:16 ` Vladimir Zapolskiy
2025-07-14 14:43 ` Bryan O'Donoghue
2025-07-14 14:58 ` Vladimir Zapolskiy
2025-07-14 15:17 ` Bryan O'Donoghue
2025-07-14 15:26 ` Konrad Dybcio
2025-07-14 15:30 ` Vladimir Zapolskiy
2025-07-15 0:13 ` Bryan O'Donoghue
2025-07-15 6:35 ` Vladimir Zapolskiy
2025-07-15 9:01 ` Konrad Dybcio
2025-07-15 9:20 ` Vladimir Zapolskiy
2025-07-15 9:33 ` Konrad Dybcio
2025-07-21 15:46 ` neil.armstrong
2025-07-21 16:16 ` Bryan O'Donoghue
2025-07-21 16:22 ` Bryan O'Donoghue
2025-07-21 16:29 ` Bryan O'Donoghue
2025-07-22 8:32 ` Neil Armstrong
2025-07-22 9:08 ` Bryan O'Donoghue
2025-07-22 9:59 ` Neil Armstrong
2025-07-22 10:37 ` Bryan O'Donoghue [this message]
2025-08-12 13:39 ` neil.armstrong
2025-08-12 15:05 ` Bryan O'Donoghue
2025-08-12 16:08 ` Neil Armstrong
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=7e1073da-6773-489e-80f5-97409f013acc@linaro.org \
--to=bryan.odonoghue@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kishon@kernel.org \
--cc=konrad.dybcio@oss.qualcomm.com \
--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
all inboxes | Powered by JetHome®