From: Richard Acayan <mailingradian@gmail.com>
To: Robert Foss <rfoss@kernel.org>, Todor Tomov <todor.too@gmail.com>,
"Bryan O'Donoghue" <bryan.odonoghue@linaro.org>,
Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Bjorn Andersson <andersson@kernel.org>,
Konrad Dybcio <konradybcio@kernel.org>,
linux-arm-msm@vger.kernel.org, linux-media@vger.kernel.org,
devicetree@vger.kernel.org
Cc: Richard Acayan <mailingradian@gmail.com>
Subject: [RFC PATCH 2/3] media: qcom: camss: allow endpoints with no remote
Date: Mon, 29 Dec 2025 21:27:58 -0500 [thread overview]
Message-ID: <20251230022759.9449-3-mailingradian@gmail.com> (raw)
In-Reply-To: <20251230022759.9449-1-mailingradian@gmail.com>
The camera subsystem is part of the Qualcomm platform, and common to
devices of the same platform (minus the devices that may omit it for
some reason). Different devices of the same SoC connect the camss to a
camera sensor with OF port and endpoint nodes. In the devicetree, the
SoC dtsi is responsible for defining the camera subsystem and ports,
while the device dts may connect some ports to a camera sensor and leave
others disconnected.
Currently, the camera subsystem separates SoC dtsi and device dts by
defining the ports in SoC, then using the top-level &camss label in the
device DTS to connect the ports. This is the standard, although still
disliked because a typo can cause the device DTS to define the
connection to the sensor in a newly created, unused node, with no
compile errors.
Another option that functions (the camera is exposed to userspace, even
though the approach is disliked), is defining and labelling the ports in
SoC so the device DTS can use the &camss_portX label to add an endpoint
and connect. This is disliked because an endpoint node is also labelled
in device DTS, so it adds clutter to the labelling.
The option used in SDM670 is to label an endpoint node, but also to
disable it. The device DTS can enable it to connect. This does not work
anymore.
When Vladimir clarified that the SDM670 camera subsystem isn't like DSI
because of the disabling, that gave a possible path forward. The option
used in DSI is to label an endpoint node in SoC and not to disable it,
but to leave it completely blank. Any endpoints that have no remote
endpoint (i.e. endpoints that are disconnected) are skipped. Skip the
endpoints with no remote node to allow an empty endpoint to be
pre-defined.
Cc: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Cc: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/e9dc1a6f-156b-40aa-9209-2010464d54ed@linaro.org
Link: https://lore.kernel.org/r/488281f6-5e5d-4864-8220-63e2a0b2d7f2@linaro.org
Link: https://lore.kernel.org/r/95704b74-52e7-4831-bc93-d4d7aa32736f@oss.qualcomm.com
Link: https://lore.kernel.org/r/79e2bb5b-9bca-4712-87bb-e0371b36bf50@linaro.org
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
drivers/media/platform/qcom/camss/camss.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index fcc2b2c3cba0..e9f0926ae92a 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -4092,9 +4092,8 @@ static int camss_of_parse_ports(struct camss *camss)
remote = of_graph_get_remote_port_parent(node);
if (!remote) {
- dev_err(dev, "Cannot get remote parent\n");
- ret = -EINVAL;
- goto err_cleanup;
+ dev_dbg(dev, "Skipping endpoint due to missing remote port\n");
+ continue;
}
csd = v4l2_async_nf_add_fwnode(&camss->notifier,
--
2.52.0
next prev parent reply other threads:[~2025-12-30 2:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-30 2:27 [RFC PATCH 0/3] media: qcom: camss: support for empty endpoint nodes Richard Acayan
2025-12-30 2:27 ` [RFC PATCH 1/3] dt-bindings: media: camss: sdm670: Make endpoint properties optional Richard Acayan
2025-12-30 7:30 ` Krzysztof Kozlowski
2025-12-30 2:27 ` Richard Acayan [this message]
2025-12-30 2:27 ` [RFC PATCH 3/3] arm64: dts: qcom: sdm670: remove status properties of camss endpoints Richard Acayan
2025-12-30 8:18 ` [RFC PATCH 0/3] media: qcom: camss: support for empty endpoint nodes Vladimir Zapolskiy
2025-12-31 3:02 ` Richard Acayan
2025-12-31 8:34 ` Vladimir Zapolskiy
2026-01-30 11:31 ` Konrad Dybcio
2025-12-30 9:40 ` Bryan O'Donoghue
2025-12-31 2:20 ` Richard Acayan
2025-12-31 3:08 ` Bryan O'Donoghue
2026-01-10 1:03 ` Richard Acayan
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=20251230022759.9449-3-mailingradian@gmail.com \
--to=mailingradian@gmail.com \
--cc=andersson@kernel.org \
--cc=bryan.odonoghue@linaro.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=rfoss@kernel.org \
--cc=robh@kernel.org \
--cc=todor.too@gmail.com \
--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