[RFC PATCH 0/3] media: qcom: camss: support for empty endpoint nodes

[RFC PATCH 0/3] media: qcom: camss: support for empty endpoint nodes

[Richard Acayan]

This series adds support for empty endpoint nodes. It is currently RFC
because it continues an ongoing discussion on how to selectively connect
some CAMSS ports to cameras and leave others disconnected.

The SDM670 patches are for a full example. If agreed on, this should
expand to SoCs that have CAMSS.

Example SoC dtsi:

	camss: isp@00000000 {
		...

		status = "disabled";

		ports {
			#address-cells = <1>;
			#size-cells = <0>;

			port@0 {
				reg = <0>;

				camss_endpoint0: endpoint {
				};
			};

			port@1 {
				reg = <1>;

				camss_endpoint1: endpoint {
				};
			};

			port@2 {
				reg = <2>;

				camss_endpoint2: endpoint {
				};
			};
		};
	};

Example device dts:

	&camss {
		status = "okay";
	};

	&camss_endpoint1 {
		clock-lanes = <7>;
		data-lanes = <0 1 2 3>;
		remote-endpoint = <&cam_front_endpoint>;
	};

	&cci_i2c1 {
		camera@1a {
			...

			port {
				cam_front_endpoint: endpoint {
					data-lanes = <1 2 3 4>;
					link-frequencies = /bits/ 64 <360000000>;
					remote-endpoint = <&camss_endpoint1>;
				};
			};
		};
	};

Richard Acayan (3):
  dt-bindings: media: camss: sdm670: Make endpoint properties optional
  media: qcom: camss: allow endpoints with no remote
  arm64: dts: qcom: sdm670: remove status properties of camss endpoints

 .../devicetree/bindings/media/qcom,sdm670-camss.yaml | 12 ------------
 arch/arm64/boot/dts/qcom/sdm670.dtsi                 |  3 ---
 drivers/media/platform/qcom/camss/camss.c            |  5 ++---
 3 files changed, 2 insertions(+), 18 deletions(-)

-- 
2.52.0

[RFC PATCH 1/3] dt-bindings: media: camss: sdm670: Make endpoint properties optional

[Richard Acayan]

Endpoints may be pre-defined with no connection to another endpoint. The
other properties can be omitted in this case, so make them optional to
support this.

Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
 .../devicetree/bindings/media/qcom,sdm670-camss.yaml | 12 ------------
 1 file changed, 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml
index 35c40fe22376..e4f09f8681fe 100644
--- a/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,sdm670-camss.yaml
@@ -123,10 +123,6 @@ properties:
                 minItems: 1
                 maxItems: 4
 
-            required:
-              - clock-lanes
-              - data-lanes
-
       port@1:
         $ref: /schemas/graph.yaml#/$defs/port-base
         unevaluatedProperties: false
@@ -146,10 +142,6 @@ properties:
                 minItems: 1
                 maxItems: 4
 
-            required:
-              - clock-lanes
-              - data-lanes
-
       port@2:
         $ref: /schemas/graph.yaml#/$defs/port-base
         unevaluatedProperties: false
@@ -169,10 +161,6 @@ properties:
                 minItems: 1
                 maxItems: 4
 
-            required:
-              - clock-lanes
-              - data-lanes
-
 required:
   - compatible
   - reg
-- 
2.52.0

Re: [RFC PATCH 1/3] dt-bindings: media: camss: sdm670: Make endpoint properties optional

[Krzysztof Kozlowski]

On 30/12/2025 03:27, Richard Acayan wrote:
> Endpoints may be pre-defined with no connection to another endpoint. The

Not really. You do not define incomplete nodes without any reason,

> other properties can be omitted in this case, so make them optional to
> support this.



Best regards,
Krzysztof

[RFC PATCH 2/3] media: qcom: camss: allow endpoints with no remote

[Richard Acayan]

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

[RFC PATCH 3/3] arm64: dts: qcom: sdm670: remove status properties of camss endpoints

[Richard Acayan]

These properties are unnecessary and can be removed. The endpoints are
disconnected, but this is implied by a missing remote-parent.

Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
 arch/arm64/boot/dts/qcom/sdm670.dtsi | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sdm670.dtsi b/arch/arm64/boot/dts/qcom/sdm670.dtsi
index b8a8dcbdfbe3..e841309221e2 100644
--- a/arch/arm64/boot/dts/qcom/sdm670.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm670.dtsi
@@ -1780,7 +1780,6 @@ port@0 {
 					reg = <0>;
 
 					camss_endpoint0: endpoint {
-						status = "disabled";
 					};
 				};
 
@@ -1788,7 +1787,6 @@ port@1 {
 					reg = <1>;
 
 					camss_endpoint1: endpoint {
-						status = "disabled";
 					};
 				};
 
@@ -1796,7 +1794,6 @@ port@2 {
 					reg = <2>;
 
 					camss_endpoint2: endpoint {
-						status = "disabled";
 					};
 				};
 			};
-- 
2.52.0

Re: [RFC PATCH 0/3] media: qcom: camss: support for empty endpoint nodes

[Vladimir Zapolskiy]

On 12/30/25 04:27, Richard Acayan wrote:
> This series adds support for empty endpoint nodes. It is currently RFC
> because it continues an ongoing discussion on how to selectively connect
> some CAMSS ports to cameras and leave others disconnected.
> 
> The SDM670 patches are for a full example. If agreed on, this should
> expand to SoCs that have CAMSS.
> 
> Example SoC dtsi:
> 
> 	camss: isp@00000000 {
> 		...
> 
> 		status = "disabled";
> 
> 		ports {
> 			#address-cells = <1>;
> 			#size-cells = <0>;
> 
> 			port@0 {
> 				reg = <0>;
> 
> 				camss_endpoint0: endpoint {
> 				};
> 			};

I do not see this device tree node layout as a valid one. A 'port' provides
an interface description (an option), and an 'endpoint' declares a connection
over a port (the accepted option).

 From dtschema/schemas/graph.yaml:

     Each port node contains an 'endpoint' subnode for each remote device port
     connected to this port.

This is violated in the example given by you above, when a remote device along
with its ports is just missing, thus there is no connection. A forced alternative
reading may (or will) break the legacy, so in this particular case you shall
start from making a change to the shared graph.yaml documentation, since it's
all not about CAMSS or even linux-media specifics.

-- 
Best wishes,
Vladimir

Re: [RFC PATCH 0/3] media: qcom: camss: support for empty endpoint nodes

[Richard Acayan]

On Tue, Dec 30, 2025 at 10:18:39AM +0200, Vladimir Zapolskiy wrote:
> On 12/30/25 04:27, Richard Acayan wrote:
> > This series adds support for empty endpoint nodes. It is currently RFC
> > because it continues an ongoing discussion on how to selectively connect
> > some CAMSS ports to cameras and leave others disconnected.
> > 
> > The SDM670 patches are for a full example. If agreed on, this should
> > expand to SoCs that have CAMSS.
> > 
> > Example SoC dtsi:
> > 
> > 	camss: isp@00000000 {
> > 		...
> > 
> > 		status = "disabled";
> > 
> > 		ports {
> > 			#address-cells = <1>;
> > 			#size-cells = <0>;
> > 
> > 			port@0 {
> > 				reg = <0>;
> > 
> > 				camss_endpoint0: endpoint {
> > 				};
> > 			};
> 
> I do not see this device tree node layout as a valid one. A 'port' provides
> an interface description (an option), and an 'endpoint' declares a connection
> over a port (the accepted option).
> 
> From dtschema/schemas/graph.yaml:
> 
>     Each port node contains an 'endpoint' subnode for each remote device port
>     connected to this port.
> 
> This is violated in the example given by you above, when a remote device along
> with its ports is just missing, thus there is no connection. A forced alternative
> reading may (or will) break the legacy, so in this particular case you shall
> start from making a change to the shared graph.yaml documentation, since it's
> all not about CAMSS or even linux-media specifics.

So, if endpoints MUST/SHALL (in IETF RFC 2119 terms) have a remote, then
would it be acceptable to label the ports instead, so a board DTS can
specify its own fully connected endpoint(s) under the port labels?

The labels to ports aren't looking as "excessive"[1] as they used to be.
Is the original review comment on port labels still relevant?

[1] https://lore.kernel.org/r/565d14e1-1478-4a60-8f70-a76a732cde97@linaro.org

Re: [RFC PATCH 0/3] media: qcom: camss: support for empty endpoint nodes

[Vladimir Zapolskiy]

On 12/31/25 05:02, Richard Acayan wrote:
> On Tue, Dec 30, 2025 at 10:18:39AM +0200, Vladimir Zapolskiy wrote:
>> On 12/30/25 04:27, Richard Acayan wrote:
>>> This series adds support for empty endpoint nodes. It is currently RFC
>>> because it continues an ongoing discussion on how to selectively connect
>>> some CAMSS ports to cameras and leave others disconnected.
>>>
>>> The SDM670 patches are for a full example. If agreed on, this should
>>> expand to SoCs that have CAMSS.
>>>
>>> Example SoC dtsi:
>>>
>>> 	camss: isp@00000000 {
>>> 		...
>>>
>>> 		status = "disabled";
>>>
>>> 		ports {
>>> 			#address-cells = <1>;
>>> 			#size-cells = <0>;
>>>
>>> 			port@0 {
>>> 				reg = <0>;
>>>
>>> 				camss_endpoint0: endpoint {
>>> 				};
>>> 			};
>>
>> I do not see this device tree node layout as a valid one. A 'port' provides
>> an interface description (an option), and an 'endpoint' declares a connection
>> over a port (the accepted option).
>>
>>  From dtschema/schemas/graph.yaml:
>>
>>      Each port node contains an 'endpoint' subnode for each remote device port
>>      connected to this port.
>>
>> This is violated in the example given by you above, when a remote device along
>> with its ports is just missing, thus there is no connection. A forced alternative
>> reading may (or will) break the legacy, so in this particular case you shall
>> start from making a change to the shared graph.yaml documentation, since it's
>> all not about CAMSS or even linux-media specifics.
> 
> So, if endpoints MUST/SHALL (in IETF RFC 2119 terms) have a remote, then
> would it be acceptable to label the ports instead, so a board DTS can
> specify its own fully connected endpoint(s) under the port labels?

It could be done. For the record, the solution is not to "label the ports
instead", but the preliminary added endpoints should be gone, and it implies
that the labels to the endpoints are gone also.

> 
> The labels to ports aren't looking as "excessive"[1] as they used to be.
> Is the original review comment on port labels still relevant?
> 
> [1] https://lore.kernel.org/r/565d14e1-1478-4a60-8f70-a76a732cde97@linaro.org

It's relevant with a modulus of 'likely', it's so secondary that I've issued
my RB at that time. You can write a proper dt graph layout without using dt
labels, and since it's expected that you touch &camss anyway to change its
'status' property value etc., you may add ports and endpoints under the same
labelled &camss device tree node at once. There is no rule to use some labels
no matter what, but technically you may introduce port labels and add endpoints
by a port label, this approach is practically found e.g. with Rockchip or
TI ISP device tree nodes.

-- 
Best wishes,
Vladimir

Re: [RFC PATCH 0/3] media: qcom: camss: support for empty endpoint nodes

[Konrad Dybcio]

On 12/31/25 9:34 AM, Vladimir Zapolskiy wrote:
> On 12/31/25 05:02, Richard Acayan wrote:
>> On Tue, Dec 30, 2025 at 10:18:39AM +0200, Vladimir Zapolskiy wrote:
>>> On 12/30/25 04:27, Richard Acayan wrote:
>>>> This series adds support for empty endpoint nodes. It is currently RFC
>>>> because it continues an ongoing discussion on how to selectively connect
>>>> some CAMSS ports to cameras and leave others disconnected.
>>>>
>>>> The SDM670 patches are for a full example. If agreed on, this should
>>>> expand to SoCs that have CAMSS.
>>>>
>>>> Example SoC dtsi:
>>>>
>>>>     camss: isp@00000000 {
>>>>         ...
>>>>
>>>>         status = "disabled";
>>>>
>>>>         ports {
>>>>             #address-cells = <1>;
>>>>             #size-cells = <0>;
>>>>
>>>>             port@0 {
>>>>                 reg = <0>;
>>>>
>>>>                 camss_endpoint0: endpoint {
>>>>                 };
>>>>             };
>>>
>>> I do not see this device tree node layout as a valid one. A 'port' provides
>>> an interface description (an option), and an 'endpoint' declares a connection
>>> over a port (the accepted option).
>>>
>>>  From dtschema/schemas/graph.yaml:
>>>
>>>      Each port node contains an 'endpoint' subnode for each remote device port
>>>      connected to this port.
>>>
>>> This is violated in the example given by you above, when a remote device along
>>> with its ports is just missing, thus there is no connection. A forced alternative
>>> reading may (or will) break the legacy, so in this particular case you shall
>>> start from making a change to the shared graph.yaml documentation, since it's
>>> all not about CAMSS or even linux-media specifics.
>>
>> So, if endpoints MUST/SHALL (in IETF RFC 2119 terms) have a remote, then
>> would it be acceptable to label the ports instead, so a board DTS can
>> specify its own fully connected endpoint(s) under the port labels?

I don't know if they MUST, but it IS convenient from the maintainer
perspective since it generally lets people make less mistakes and reduces
copypasta..

We've successfully used this ""model"" for Qualcomm display nodes, as well as
(both non-/Qualcomm) USB-C graphs

> It could be done. For the record, the solution is not to "label the ports
> instead", but the preliminary added endpoints should be gone, and it implies
> that the labels to the endpoints are gone also.
> 
>>
>> The labels to ports aren't looking as "excessive"[1] as they used to be.
>> Is the original review comment on port labels still relevant?
>>
>> [1] https://lore.kernel.org/r/565d14e1-1478-4a60-8f70-a76a732cde97@linaro.org
> 
> It's relevant with a modulus of 'likely', it's so secondary that I've issued
> my RB at that time. You can write a proper dt graph layout without using dt
> labels, and since it's expected that you touch &camss anyway to change its
> 'status' property value etc., you may add ports and endpoints under the same
> labelled &camss device tree node at once. There is no rule to use some labels
> no matter what, but technically you may introduce port labels and add endpoints
> by a port label, this approach is practically found e.g. with Rockchip or
> TI ISP device tree nodes.

Referring to nodes through labels is generally agreed to be the best-practice
given it's the only way that ensures at compile-time that the referenced node
actually exists.

At the end of the day, this is essentially syntax sugar. What we put in the
DT must be somehow interpretable by the OS, and it just so happens that this
doesn't really introduce much complexity while having the aforementioned
benefits

Konrad

Re: [RFC PATCH 0/3] media: qcom: camss: support for empty endpoint nodes

[Bryan O'Donoghue]

On 30/12/2025 02:27, Richard Acayan wrote:
> This series adds support for empty endpoint nodes. It is currently RFC
> because it continues an ongoing discussion on how to selectively connect
> some CAMSS ports to cameras and leave others disconnected.
> 
> The SDM670 patches are for a full example. If agreed on, this should
> expand to SoCs that have CAMSS.
> 
> Example SoC dtsi:
> 
> 	camss: isp@00000000 {
> 		...
> 
> 		status = "disabled";
> 
> 		ports {
> 			#address-cells = <1>;
> 			#size-cells = <0>;
> 
> 			port@0 {
> 				reg = <0>;
> 
> 				camss_endpoint0: endpoint {
> 				};
> 			};
> 
> 			port@1 {
> 				reg = <1>;
> 
> 				camss_endpoint1: endpoint {
> 				};
> 			};
> 
> 			port@2 {
> 				reg = <2>;
> 
> 				camss_endpoint2: endpoint {
> 				};
> 			};
> 		};
> 	};
> 
> Example device dts:
> 
> 	&camss {
> 		status = "okay";
> 	};
> 
> 	&camss_endpoint1 {
> 		clock-lanes = <7>;
> 		data-lanes = <0 1 2 3>;
> 		remote-endpoint = <&cam_front_endpoint>;
> 	};
> 
> 	&cci_i2c1 {
> 		camera@1a {
> 			...
> 
> 			port {
> 				cam_front_endpoint: endpoint {
> 					data-lanes = <1 2 3 4>;
> 					link-frequencies = /bits/ 64 <360000000>;
> 					remote-endpoint = <&camss_endpoint1>;
> 				};
> 			};
> 		};
> 	};
> 
> Richard Acayan (3):
>    dt-bindings: media: camss: sdm670: Make endpoint properties optional
>    media: qcom: camss: allow endpoints with no remote
>    arm64: dts: qcom: sdm670: remove status properties of camss endpoints
> 
>   .../devicetree/bindings/media/qcom,sdm670-camss.yaml | 12 ------------
>   arch/arm64/boot/dts/qcom/sdm670.dtsi                 |  3 ---
>   drivers/media/platform/qcom/camss/camss.c            |  5 ++---
>   3 files changed, 2 insertions(+), 18 deletions(-)
> 

I don't think I am 100% understanding what the intent of this series is, 
i.e. at a high level the problem you're aiming to solve.

Can you elaborate a bit ?

---
bod

Re: [RFC PATCH 0/3] media: qcom: camss: support for empty endpoint nodes

[Richard Acayan]

On Tue, Dec 30, 2025 at 09:40:14AM +0000, Bryan O'Donoghue wrote:
> On 30/12/2025 02:27, Richard Acayan wrote:
> > This series adds support for empty endpoint nodes. It is currently RFC
> > because it continues an ongoing discussion on how to selectively connect
> > some CAMSS ports to cameras and leave others disconnected.
> > 
> > The SDM670 patches are for a full example. If agreed on, this should
> > expand to SoCs that have CAMSS.
(snip)
> 
> I don't think I am 100% understanding what the intent of this series is,
> i.e. at a high level the problem you're aiming to solve.
> 
> Can you elaborate a bit ?

The point is to move the graph nodes entirely to the SoC devicetree so
the board doesn't have to redefine it. There is an explanation in patch 2,
but the next revision can try to cut some of the rambling and also
briefly explain in this cover.

Re: [RFC PATCH 0/3] media: qcom: camss: support for empty endpoint nodes

[Bryan O'Donoghue]

On 31/12/2025 02:20, Richard Acayan wrote:
> On Tue, Dec 30, 2025 at 09:40:14AM +0000, Bryan O'Donoghue wrote:
>> On 30/12/2025 02:27, Richard Acayan wrote:
>>> This series adds support for empty endpoint nodes. It is currently RFC
>>> because it continues an ongoing discussion on how to selectively connect
>>> some CAMSS ports to cameras and leave others disconnected.
>>>
>>> The SDM670 patches are for a full example. If agreed on, this should
>>> expand to SoCs that have CAMSS.
> (snip)
>>
>> I don't think I am 100% understanding what the intent of this series is,
>> i.e. at a high level the problem you're aiming to solve.
>>
>> Can you elaborate a bit ?
> 
> The point is to move the graph nodes entirely to the SoC devicetree so
> the board doesn't have to redefine it. There is an explanation in patch 2,
> but the next revision can try to cut some of the rambling and also
> briefly explain in this cover.

Yeah I think I understood that part but, the bit I don't get is why you 
want to do that.

i.e. what is the objective you want to achieve with it, is it just to 
make this structural change because you think it can be done or is there 
some other endpoint (pun intended) to the change ?

---
bod

Re: [RFC PATCH 0/3] media: qcom: camss: support for empty endpoint nodes

[Richard Acayan]

On Mon, Dec 29, 2025 at 09:27:56PM -0500, Richard Acayan wrote:
> This series adds support for empty endpoint nodes. It is currently RFC
> because it continues an ongoing discussion on how to selectively connect
> some CAMSS ports to cameras and leave others disconnected.
> 
> The SDM670 patches are for a full example. If agreed on, this should
> expand to SoCs that have CAMSS.

This series is abandoned now that it seems fine to add port labels. No
need for me to revisit this unless someone has an issue with the
proposed port labels in SDM670[1].

[1] https://lore.kernel.org/all/20260107043044.92485-4-mailingradian@gmail.com/