On 12/13/24 13:34, Bryan O'Donoghue wrote:
On 13/12/2024 11:24, Luca Weiss wrote:
On Fri Dec 13, 2024 at 11:50 AM CET, Vladimir Zapolskiy wrote:
On 12/13/24 11:34, Krzysztof Kozlowski wrote:
On Mon, Dec 09, 2024 at 01:01:05PM +0100, Luca Weiss wrote:
The CSIPHY of Qualcomm SoCs support both D-PHY and C-PHY standards for
CSI-2, but not any others so restrict the bus-type property describing
this to the supported values.
The only exception here is MSM8916 which only supports D-PHY. C-PHY was
introduced with newer SoCs.
Do note, that currently the Linux driver only supports D-PHY.
Signed-off-by: Luca Weiss <luca.weiss@xxxxxxxxxxxxx>
---
.../bindings/media/qcom,msm8916-camss.yaml | 8 ++++++
.../bindings/media/qcom,msm8953-camss.yaml | 15 +++++++++++
.../bindings/media/qcom,msm8996-camss.yaml | 20 +++++++++++++++
.../bindings/media/qcom,sc8280xp-camss.yaml | 20 +++++++++++++++
.../bindings/media/qcom,sdm660-camss.yaml | 20 +++++++++++++++
.../bindings/media/qcom,sdm845-camss.yaml | 20 +++++++++++++++
.../bindings/media/qcom,sm8250-camss.yaml | 30 ++++++++++++++++++++++
7 files changed, 133 insertions(+)
diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml
index 9cc0a968a401836814560c1af3ee84d946500b4f..3de2a3d2b5b761106975aab65ff614b2ef579ef5 100644
--- a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml
+++ b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml
@@ -94,6 +94,10 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
required:
- data-lanes
@@ -113,6 +117,10 @@ properties:
minItems: 1
maxItems: 4
+ bus-type:
+ enum:
+ - 4 # MEDIA_BUS_TYPE_CSI2_DPHY
+
But is it really needed to specify the single supported bus-type?
I believe it is not, at least it's not ever done for other media devices
like sensors.
Through video-interfaces.yaml 'bus-type' is already allowed but not
restricted to the values that actually make any sense on such hardware,
so in my opinion this makes sense to have here.
This is additive not prescriptive.
New additions should include this bus-type number as we will need it
when we add CPHY support and the subsequently move to the PHY API for
CAMSS PHYs.
This particular reason is invalid IMO, since dtb changes are not relied on
drivers and shall be kept agnostic.
The open question is if it is really needed to specify non-variable
bus-type property. As I've said it's not done for other media devices,
so that's at least the established policy on practice.
--
Best wishes,
Vladimir
