* [PATCH V3 00/13] media: qcom: camss: Add sm8550 support
@ 2024-07-09 16:06 Depeng Shao
2024-07-09 16:06 ` [PATCH 01/13] media: qcom: camss: csiphy-3ph: Fix trivial indentation fault in defines Depeng Shao
` (14 more replies)
0 siblings, 15 replies; 99+ messages in thread
From: Depeng Shao @ 2024-07-09 16:06 UTC (permalink / raw)
To: rfoss, todor.too, bryan.odonoghue, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, quic_depengs, linux-media, linux-arm-msm,
devicetree, linux-kernel, kernel
V3:
- Rebased the change based on below change which will be merged firstly.
"Move camss version related defs in to resources"
Link: https://lore.kernel.org/all/20240522154659.510-1-quic_grosikop@quicinc.com/
- Rebased the change based on Bryan's csiphy optimization change and add
these changes into this series, so that the new csiphy-3ph driver don't
need to add duplicate code. This has got Bryan's permission to add his
patches into this series.
- Refactor some changes based on the comments to move the random code to
patches where they are used.
- Remove the vfe780 irq function since it isn't doing the actual work.
- Add dt-binding for sm8550 camss driver.
Link to V2: https://lore.kernel.org/all/20240320141136.26827-1-quic_depengs@quicinc.com/
V2:
- Update some commit messages
Link to V1: https://lore.kernel.org/all/20240320134227.16587-1-quic_depengs@quicinc.com/
V1:
SM8550 is a Qualcomm flagship SoC. This series adds support to
bring up the CSIPHY, CSID, VFE/RDI interfaces in SM8550.
SM8550 provides
- 3 x VFE, 3 RDI per VFE
- 2 x VFE Lite, 4 RDI per VFE
- 3 x CSID
- 2 x CSID Lite
- 8 x CSI PHY
This series is rebased based on: "Move camss version related defs in to resources"
Link: https://lore.kernel.org/all/20240522154659.510-1-quic_grosikop@quicinc.com/
Bryan O'Donoghue (6):
media: qcom: camss: csiphy-3ph: Fix trivial indentation fault in
defines
media: qcom: camss: csiphy-3ph: Remove redundant PHY init sequence
control loop
media: qcom: camss: csiphy-3ph: Rename struct
media: qcom: camss: csiphy: Add an init callback to CSI PHY devices
media: qcom: camss: csiphy-3ph: Move CSIPHY variables to data field
inside csiphy struct
media: qcom: camss: csiphy-3ph: Use an offset variable to find common
control regs
Depeng Shao (7):
dt-bindings: media: camss: Add qcom,sm8550-camss binding
media: qcom: camss: csiphy-3ph: Add Gen2 v1.2 two-phase MIPI CSI-2
DPHY init
media: qcom: camss: Add CSID Gen3 support for SM8550
media: qcom: camss: Add support for VFE hardware version Titan 780
media: qcom: camss: Add notify interface in camss driver
media: qcom: camss: Add sm8550 support
media: qcom: camss: Add sm8550 resources
.../bindings/media/qcom,sm8550-camss.yaml | 545 ++++++++++++
drivers/media/platform/qcom/camss/Makefile | 2 +
.../platform/qcom/camss/camss-csid-gen3.c | 483 +++++++++++
.../platform/qcom/camss/camss-csid-gen3.h | 26 +
.../media/platform/qcom/camss/camss-csid.c | 21 +
.../media/platform/qcom/camss/camss-csid.h | 11 +
.../qcom/camss/camss-csiphy-2ph-1-0.c | 6 +
.../qcom/camss/camss-csiphy-3ph-1-0.c | 796 ++++++++++--------
.../media/platform/qcom/camss/camss-csiphy.c | 4 +
.../media/platform/qcom/camss/camss-csiphy.h | 2 +
.../media/platform/qcom/camss/camss-vfe-780.c | 429 ++++++++++
drivers/media/platform/qcom/camss/camss-vfe.c | 6 +
drivers/media/platform/qcom/camss/camss-vfe.h | 2 +
drivers/media/platform/qcom/camss/camss.c | 462 ++++++++++
drivers/media/platform/qcom/camss/camss.h | 10 +
15 files changed, 2467 insertions(+), 338 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml
create mode 100644 drivers/media/platform/qcom/camss/camss-csid-gen3.c
create mode 100644 drivers/media/platform/qcom/camss/camss-csid-gen3.h
create mode 100644 drivers/media/platform/qcom/camss/camss-vfe-780.c
base-commit: 0c52056d9f77508cb6d4d68d3fc91c6c08ec71af
prerequisite-patch-id: 74fabfbf51d650af74a1dc9f7e09fe03a1d85d93
prerequisite-patch-id: 3833c5eed2690679e5eca3551053e08350d2b070
prerequisite-patch-id: 0e433e0c5a9d2402da97c1a01194b1a9f6f7e6cb
prerequisite-patch-id: f876f5ed5605fcfebea7f1584888f494bfecd102
prerequisite-patch-id: 8bcb15b208a319a6e88ff4f9e5023097af92cc90
prerequisite-patch-id: dc4b5ddbbedd8773159694b3becad5c7dcbfcf77
prerequisite-patch-id: 75c1b00f4476ee6006041046ad5194b086db3358
prerequisite-patch-id: 0efc004cb8a844291ebe1f16ce192567f44218c7
--
2.34.1
^ permalink raw reply [flat|nested] 99+ messages in thread
* [PATCH 01/13] media: qcom: camss: csiphy-3ph: Fix trivial indentation fault in defines
2024-07-09 16:06 [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
@ 2024-07-09 16:06 ` Depeng Shao
2024-07-31 23:16 ` Vladimir Zapolskiy
2024-07-09 16:06 ` [PATCH 02/13] media: qcom: camss: csiphy-3ph: Remove redundant PHY init sequence control loop Depeng Shao
` (13 subsequent siblings)
14 siblings, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-07-09 16:06 UTC (permalink / raw)
To: rfoss, todor.too, bryan.odonoghue, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, quic_depengs, linux-media, linux-arm-msm,
devicetree, linux-kernel, kernel
From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Replace space with tab in define indentations.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
---
.../platform/qcom/camss/camss-csiphy-3ph-1-0.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
index df7e93a5a4f6..53892bdaaf58 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
@@ -48,13 +48,13 @@
#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_SHOW_REV_ID BIT(1)
#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(n) (0x8b0 + 0x4 * (n))
-#define CSIPHY_DEFAULT_PARAMS 0
-#define CSIPHY_LANE_ENABLE 1
-#define CSIPHY_SETTLE_CNT_LOWER_BYTE 2
-#define CSIPHY_SETTLE_CNT_HIGHER_BYTE 3
-#define CSIPHY_DNP_PARAMS 4
-#define CSIPHY_2PH_REGS 5
-#define CSIPHY_3PH_REGS 6
+#define CSIPHY_DEFAULT_PARAMS 0
+#define CSIPHY_LANE_ENABLE 1
+#define CSIPHY_SETTLE_CNT_LOWER_BYTE 2
+#define CSIPHY_SETTLE_CNT_HIGHER_BYTE 3
+#define CSIPHY_DNP_PARAMS 4
+#define CSIPHY_2PH_REGS 5
+#define CSIPHY_3PH_REGS 6
struct csiphy_reg_t {
s32 reg_addr;
--
2.34.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 02/13] media: qcom: camss: csiphy-3ph: Remove redundant PHY init sequence control loop
2024-07-09 16:06 [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
2024-07-09 16:06 ` [PATCH 01/13] media: qcom: camss: csiphy-3ph: Fix trivial indentation fault in defines Depeng Shao
@ 2024-07-09 16:06 ` Depeng Shao
2024-07-31 23:27 ` Vladimir Zapolskiy
2024-07-09 16:06 ` [PATCH 03/13] media: qcom: camss: csiphy-3ph: Rename struct Depeng Shao
` (12 subsequent siblings)
14 siblings, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-07-09 16:06 UTC (permalink / raw)
To: rfoss, todor.too, bryan.odonoghue, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, quic_depengs, linux-media, linux-arm-msm,
devicetree, linux-kernel, kernel
From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Adding a new CSIPHY init sequence using downstream as a reference prompted
me to look at why we are splitting up the init sequence into chunks.
Right now we declare CSI PHY init sequences as an array of five equally
sized writes with a hard-coded control loop to iterate through each of the
five indexes. One bug in this model is that if you don't have an even
number of writes, you can't init the PHY as you wish.
In downstream the original code has something of the character
phy_init_seq[MAX_LANES][MAX_PARAMS] which in upstream we have translated
into phy_init_seq[5][SOME_NUMBER_OF_EQUAL_WRITES];
What the code does is take a pointer to the first index of the
r = &phy_init_seq[0][0]; and then literally does write(r, value); r++;
The controlling loop that hard-codes '5' in-lieu of MAX_LANES does no
special sleep, fabric-coherence sync or even a printk() to justify its
existence. Our compilers are optimising all of this away anyway so lets
drop.
Reduce the array declaration down to one flat aggregate init and let the
code just step through. As a happy side-effect we can then also handle
odd-number writes as the number of elements in the init sequence will no
longer have to be evenly divisible.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
---
.../qcom/camss/camss-csiphy-3ph-1-0.c | 554 +++++++++---------
1 file changed, 261 insertions(+), 293 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
index 53892bdaaf58..39269ae31709 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
@@ -65,287 +65,257 @@ struct csiphy_reg_t {
/* GEN2 1.0 2PH */
static const struct
-csiphy_reg_t lane_regs_sdm845[5][14] = {
- {
- {0x0004, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x002C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0034, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x001C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0014, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0028, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x003C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0000, 0x91, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0008, 0x00, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
- {0x000c, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0010, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0038, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0060, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0064, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
- },
- {
- {0x0704, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x072C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0734, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x071C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0714, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0728, 0x04, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x073C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0700, 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0708, 0x14, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
- {0x070C, 0xA5, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0710, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0738, 0x1F, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0760, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0764, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
- },
- {
- {0x0204, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x022C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0234, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x021C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0214, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0228, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x023C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0200, 0x91, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0208, 0x00, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
- {0x020C, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0210, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0238, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0260, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0264, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
- },
- {
- {0x0404, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x042C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0434, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x041C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0414, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0428, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x043C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0400, 0x91, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0408, 0x00, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
- {0x040C, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0410, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0438, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0460, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0464, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
- },
- {
- {0x0604, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x062C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0634, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x061C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0614, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0628, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x063C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0600, 0x91, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0608, 0x00, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
- {0x060C, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0610, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0638, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0660, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0664, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
- },
+csiphy_reg_t lane_regs_sdm845[] = {
+ {0x0004, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x002C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0034, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x001C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0014, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0028, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x003C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0000, 0x91, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0008, 0x00, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x000c, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0010, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0038, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0060, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0064, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0704, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x072C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0734, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x071C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0714, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0728, 0x04, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x073C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0700, 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0708, 0x14, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x070C, 0xA5, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0710, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0738, 0x1F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0760, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0764, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0204, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x022C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0234, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x021C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0214, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0228, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x023C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0200, 0x91, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0208, 0x00, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x020C, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0210, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0238, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0260, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0264, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0404, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x042C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0434, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x041C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0414, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0428, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x043C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0400, 0x91, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0408, 0x00, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x040C, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0410, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0438, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0460, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0464, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0604, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x062C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0634, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x061C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0614, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0628, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x063C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0600, 0x91, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0608, 0x00, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x060C, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0610, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0638, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0660, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0664, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
};
/* GEN2 1.1 2PH */
static const struct
-csiphy_reg_t lane_regs_sc8280xp[5][14] = {
- {
- {0x0004, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x002C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0034, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x001C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0014, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0028, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x003C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0000, 0x90, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0008, 0x0E, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
- {0x000C, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0010, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0038, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0060, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0064, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
- },
- {
- {0x0704, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x072C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0734, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x071C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0714, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0728, 0x04, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x073C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0700, 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0708, 0x0E, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
- {0x070C, 0xA5, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0710, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0738, 0x1F, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0760, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0764, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
- },
- {
- {0x0204, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x022C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0234, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x021C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0214, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0228, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x023C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0200, 0x90, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0208, 0x0E, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
- {0x020C, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0210, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0238, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0260, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0264, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
- },
- {
- {0x0404, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x042C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0434, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x041C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0414, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0428, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x043C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0400, 0x90, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0408, 0x0E, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
- {0x040C, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0410, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0438, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0460, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0464, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
- },
- {
- {0x0604, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x062C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0634, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x061C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0614, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0628, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x063C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0600, 0x90, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0608, 0x0E, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
- {0x060C, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0610, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0638, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0660, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0664, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
- },
+csiphy_reg_t lane_regs_sc8280xp[] = {
+ {0x0004, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x002C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0034, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x001C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0014, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0028, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x003C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0000, 0x90, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0008, 0x0E, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x000C, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0010, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0038, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0060, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0064, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0704, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x072C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0734, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x071C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0714, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0728, 0x04, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x073C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0700, 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0708, 0x0E, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x070C, 0xA5, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0710, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0738, 0x1F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0760, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0764, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0204, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x022C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0234, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x021C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0214, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0228, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x023C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0200, 0x90, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0208, 0x0E, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x020C, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0210, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0238, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0260, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0264, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0404, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x042C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0434, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x041C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0414, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0428, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x043C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0400, 0x90, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0408, 0x0E, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x040C, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0410, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0438, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0460, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0464, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0604, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x062C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0634, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x061C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0614, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0628, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x063C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0600, 0x90, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0608, 0x0E, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x060C, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0610, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0638, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0660, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0664, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
};
/* GEN2 1.2.1 2PH */
static const struct
-csiphy_reg_t lane_regs_sm8250[5][20] = {
- {
- {0x0030, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0900, 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0908, 0x10, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0904, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0904, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0004, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x002C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0034, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0010, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x001C, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x003C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0008, 0x10, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
- {0x0000, 0x8D, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x000c, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0038, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0014, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0028, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0024, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0800, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0884, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- },
- {
- {0x0730, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0C80, 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0C88, 0x10, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0C84, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0C84, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0704, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x072C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0734, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0710, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x071C, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x073C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0708, 0x10, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
- {0x0700, 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x070c, 0xA5, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0738, 0x1F, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0714, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0728, 0x04, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0724, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0800, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0884, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- },
- {
- {0x0230, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0A00, 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0A08, 0x10, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0A04, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0A04, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0204, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x022C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0234, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0210, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x021C, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x023C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0208, 0x10, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
- {0x0200, 0x8D, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x020c, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0238, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0214, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0228, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0224, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0800, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0884, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- },
- {
- {0x0430, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0B00, 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0B08, 0x10, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0B04, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0B04, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0404, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x042C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0434, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0410, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x041C, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x043C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0408, 0x10, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
- {0x0400, 0x8D, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x040c, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0438, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0414, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0428, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0424, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0800, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0884, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- },
- {
- {0x0630, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0C00, 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0C08, 0x10, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0C04, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0C04, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0604, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x062C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0634, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0610, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x061C, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x063C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0608, 0x10, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
- {0x0600, 0x8D, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x060c, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0638, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0614, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0628, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0624, 0x00, 0x00, CSIPHY_DNP_PARAMS},
- {0x0800, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
- {0x0884, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
- },
+csiphy_reg_t lane_regs_sm8250[] = {
+ {0x0030, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0900, 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0908, 0x10, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0904, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0904, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0004, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x002C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0034, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0010, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x001C, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x003C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0008, 0x10, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0000, 0x8D, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x000c, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0038, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0014, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0028, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0024, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0800, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0884, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0730, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C80, 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C88, 0x10, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C84, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C84, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0704, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x072C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0734, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0710, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x071C, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x073C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0708, 0x10, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0700, 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x070c, 0xA5, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0738, 0x1F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0714, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0728, 0x04, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0724, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0800, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0884, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0230, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0A00, 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0A08, 0x10, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0A04, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0A04, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0204, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x022C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0234, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0210, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x021C, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x023C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0208, 0x10, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0200, 0x8D, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x020c, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0238, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0214, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0228, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0224, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0800, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0884, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0430, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0B00, 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0B08, 0x10, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0B04, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0B04, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0404, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x042C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0434, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0410, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x041C, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x043C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0408, 0x10, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0400, 0x8D, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x040c, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0438, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0414, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0428, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0424, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0800, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0884, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0630, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C00, 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C08, 0x10, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C04, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C04, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0604, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x062C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0634, 0x07, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0610, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x061C, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x063C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0608, 0x10, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0600, 0x8D, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x060c, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0638, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0614, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0628, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0624, 0x00, 0x00, CSIPHY_DNP_PARAMS},
+ {0x0800, 0x02, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0884, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
};
static void csiphy_hw_version_read(struct csiphy_device *csiphy,
@@ -501,41 +471,39 @@ static void csiphy_gen2_config_lanes(struct csiphy_device *csiphy,
u8 settle_cnt)
{
const struct csiphy_reg_t *r;
- int i, l, array_size;
+ int i, array_size;
u32 val;
switch (csiphy->camss->res->version) {
case CAMSS_845:
- r = &lane_regs_sdm845[0][0];
- array_size = ARRAY_SIZE(lane_regs_sdm845[0]);
+ r = &lane_regs_sdm845[0];
+ array_size = ARRAY_SIZE(lane_regs_sdm845);
break;
case CAMSS_8250:
- r = &lane_regs_sm8250[0][0];
- array_size = ARRAY_SIZE(lane_regs_sm8250[0]);
+ r = &lane_regs_sm8250[0];
+ array_size = ARRAY_SIZE(lane_regs_sm8250);
break;
case CAMSS_8280XP:
- r = &lane_regs_sc8280xp[0][0];
- array_size = ARRAY_SIZE(lane_regs_sc8280xp[0]);
+ r = &lane_regs_sc8280xp[0];
+ array_size = ARRAY_SIZE(lane_regs_sc8280xp);
break;
default:
WARN(1, "unknown cspi version\n");
return;
}
- for (l = 0; l < 5; l++) {
- for (i = 0; i < array_size; i++, r++) {
- switch (r->csiphy_param_type) {
- case CSIPHY_SETTLE_CNT_LOWER_BYTE:
- val = settle_cnt & 0xff;
- break;
- case CSIPHY_DNP_PARAMS:
- continue;
- default:
- val = r->reg_data;
- break;
- }
- writel_relaxed(val, csiphy->base + r->reg_addr);
+ for (i = 0; i < array_size; i++, r++) {
+ switch (r->csiphy_param_type) {
+ case CSIPHY_SETTLE_CNT_LOWER_BYTE:
+ val = settle_cnt & 0xff;
+ break;
+ case CSIPHY_DNP_PARAMS:
+ continue;
+ default:
+ val = r->reg_data;
+ break;
}
+ writel_relaxed(val, csiphy->base + r->reg_addr);
}
}
--
2.34.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 03/13] media: qcom: camss: csiphy-3ph: Rename struct
2024-07-09 16:06 [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
2024-07-09 16:06 ` [PATCH 01/13] media: qcom: camss: csiphy-3ph: Fix trivial indentation fault in defines Depeng Shao
2024-07-09 16:06 ` [PATCH 02/13] media: qcom: camss: csiphy-3ph: Remove redundant PHY init sequence control loop Depeng Shao
@ 2024-07-09 16:06 ` Depeng Shao
2024-07-31 23:28 ` Vladimir Zapolskiy
2024-07-09 16:06 ` [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices Depeng Shao
` (11 subsequent siblings)
14 siblings, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-07-09 16:06 UTC (permalink / raw)
To: rfoss, todor.too, bryan.odonoghue, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, quic_depengs, linux-media, linux-arm-msm,
devicetree, linux-kernel, kernel
From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
The existing structure captures the configuration of CSIPHY lane registers.
Rename to struct csiphy_lane_regs to reflect.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
---
.../media/platform/qcom/camss/camss-csiphy-3ph-1-0.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
index 39269ae31709..bc4834ee2dcc 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
@@ -56,7 +56,7 @@
#define CSIPHY_2PH_REGS 5
#define CSIPHY_3PH_REGS 6
-struct csiphy_reg_t {
+struct csiphy_lane_regs {
s32 reg_addr;
s32 reg_data;
s32 delay;
@@ -65,7 +65,7 @@ struct csiphy_reg_t {
/* GEN2 1.0 2PH */
static const struct
-csiphy_reg_t lane_regs_sdm845[] = {
+csiphy_lane_regs lane_regs_sdm845[] = {
{0x0004, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
{0x002C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
{0x0034, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
@@ -140,7 +140,7 @@ csiphy_reg_t lane_regs_sdm845[] = {
/* GEN2 1.1 2PH */
static const struct
-csiphy_reg_t lane_regs_sc8280xp[] = {
+csiphy_lane_regs lane_regs_sc8280xp[] = {
{0x0004, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
{0x002C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
{0x0034, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
@@ -215,7 +215,7 @@ csiphy_reg_t lane_regs_sc8280xp[] = {
/* GEN2 1.2.1 2PH */
static const struct
-csiphy_reg_t lane_regs_sm8250[] = {
+csiphy_lane_regs lane_regs_sm8250[] = {
{0x0030, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
{0x0900, 0x05, 0x00, CSIPHY_DEFAULT_PARAMS},
{0x0908, 0x10, 0x00, CSIPHY_DEFAULT_PARAMS},
@@ -470,7 +470,7 @@ static void csiphy_gen1_config_lanes(struct csiphy_device *csiphy,
static void csiphy_gen2_config_lanes(struct csiphy_device *csiphy,
u8 settle_cnt)
{
- const struct csiphy_reg_t *r;
+ const struct csiphy_lane_regs *r;
int i, array_size;
u32 val;
--
2.34.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices
2024-07-09 16:06 [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (2 preceding siblings ...)
2024-07-09 16:06 ` [PATCH 03/13] media: qcom: camss: csiphy-3ph: Rename struct Depeng Shao
@ 2024-07-09 16:06 ` Depeng Shao
2024-07-31 23:43 ` Vladimir Zapolskiy
2024-07-09 16:06 ` [PATCH 05/13] media: qcom: camss: csiphy-3ph: Move CSIPHY variables to data field inside csiphy struct Depeng Shao
` (10 subsequent siblings)
14 siblings, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-07-09 16:06 UTC (permalink / raw)
To: rfoss, todor.too, bryan.odonoghue, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, quic_depengs, linux-media, linux-arm-msm,
devicetree, linux-kernel, kernel
From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Add a nop callback to CSIPHY devices. Later patches will enumerate with
enabling code.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
---
drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c | 6 ++++++
drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c | 6 ++++++
drivers/media/platform/qcom/camss/camss-csiphy.c | 4 ++++
drivers/media/platform/qcom/camss/camss-csiphy.h | 1 +
4 files changed, 17 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c
index cd4a8c369234..9d67e7fa6366 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c
@@ -180,6 +180,11 @@ static irqreturn_t csiphy_isr(int irq, void *dev)
return IRQ_HANDLED;
}
+static int csiphy_init(struct csiphy_device *csiphy)
+{
+ return 0;
+}
+
const struct csiphy_hw_ops csiphy_ops_2ph_1_0 = {
.get_lane_mask = csiphy_get_lane_mask,
.hw_version_read = csiphy_hw_version_read,
@@ -187,4 +192,5 @@ const struct csiphy_hw_ops csiphy_ops_2ph_1_0 = {
.lanes_enable = csiphy_lanes_enable,
.lanes_disable = csiphy_lanes_disable,
.isr = csiphy_isr,
+ .init = csiphy_init,
};
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
index bc4834ee2dcc..b60c32a195df 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
@@ -581,6 +581,11 @@ static void csiphy_lanes_disable(struct csiphy_device *csiphy,
CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(6));
}
+static int csiphy_init(struct csiphy_device *csiphy)
+{
+ return 0;
+}
+
const struct csiphy_hw_ops csiphy_ops_3ph_1_0 = {
.get_lane_mask = csiphy_get_lane_mask,
.hw_version_read = csiphy_hw_version_read,
@@ -588,4 +593,5 @@ const struct csiphy_hw_ops csiphy_ops_3ph_1_0 = {
.lanes_enable = csiphy_lanes_enable,
.lanes_disable = csiphy_lanes_disable,
.isr = csiphy_isr,
+ .init = csiphy_init,
};
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c b/drivers/media/platform/qcom/camss/camss-csiphy.c
index 2f7361dfd461..ea5c7078ec8e 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
@@ -576,6 +576,10 @@ int msm_csiphy_subdev_init(struct camss *camss,
csiphy->cfg.combo_mode = 0;
csiphy->res = &res->csiphy;
+ ret = csiphy->res->hw_ops->init(csiphy);
+ if (ret)
+ return ret;
+
/* Memory */
csiphy->base = devm_platform_ioremap_resource_byname(pdev, res->reg[0]);
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.h b/drivers/media/platform/qcom/camss/camss-csiphy.h
index 47f0b6b09eba..bdf9a9c8bacc 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.h
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.h
@@ -71,6 +71,7 @@ struct csiphy_hw_ops {
void (*lanes_disable)(struct csiphy_device *csiphy,
struct csiphy_config *cfg);
irqreturn_t (*isr)(int irq, void *dev);
+ int (*init)(struct csiphy_device *csiphy);
};
struct csiphy_subdev_resources {
--
2.34.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 05/13] media: qcom: camss: csiphy-3ph: Move CSIPHY variables to data field inside csiphy struct
2024-07-09 16:06 [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (3 preceding siblings ...)
2024-07-09 16:06 ` [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices Depeng Shao
@ 2024-07-09 16:06 ` Depeng Shao
2024-07-31 23:55 ` Vladimir Zapolskiy
2024-07-09 16:06 ` [PATCH 06/13] media: qcom: camss: csiphy-3ph: Use an offset variable to find common control regs Depeng Shao
` (9 subsequent siblings)
14 siblings, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-07-09 16:06 UTC (permalink / raw)
To: rfoss, todor.too, bryan.odonoghue, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, quic_depengs, linux-media, linux-arm-msm,
devicetree, linux-kernel, kernel
From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
A .data field in the csiphy device structure allows us to extend out the
register layout of the three phase capable CSIPHY layer.
Move the existing lane configuration structure to an encapsulating
structure -> struct csiphy_device_regs which is derived from the .data
field populated at PHY init time, as opposed to calculated at lane
configuration.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
---
.../qcom/camss/camss-csiphy-3ph-1-0.c | 55 ++++++++++++-------
.../media/platform/qcom/camss/camss-csiphy.h | 1 +
2 files changed, 36 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
index b60c32a195df..93782ebfe0ea 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
@@ -63,6 +63,11 @@ struct csiphy_lane_regs {
u32 csiphy_param_type;
};
+struct csiphy_device_regs {
+ const struct csiphy_lane_regs *lane_regs;
+ int lane_array_size;
+};
+
/* GEN2 1.0 2PH */
static const struct
csiphy_lane_regs lane_regs_sdm845[] = {
@@ -470,28 +475,11 @@ static void csiphy_gen1_config_lanes(struct csiphy_device *csiphy,
static void csiphy_gen2_config_lanes(struct csiphy_device *csiphy,
u8 settle_cnt)
{
- const struct csiphy_lane_regs *r;
- int i, array_size;
+ struct csiphy_device_regs *csiphy_regs = csiphy->data;
+ const struct csiphy_lane_regs *r = csiphy_regs->lane_regs;
+ int i, array_size = csiphy_regs->lane_array_size;
u32 val;
- switch (csiphy->camss->res->version) {
- case CAMSS_845:
- r = &lane_regs_sdm845[0];
- array_size = ARRAY_SIZE(lane_regs_sdm845);
- break;
- case CAMSS_8250:
- r = &lane_regs_sm8250[0];
- array_size = ARRAY_SIZE(lane_regs_sm8250);
- break;
- case CAMSS_8280XP:
- r = &lane_regs_sc8280xp[0];
- array_size = ARRAY_SIZE(lane_regs_sc8280xp);
- break;
- default:
- WARN(1, "unknown cspi version\n");
- return;
- }
-
for (i = 0; i < array_size; i++, r++) {
switch (r->csiphy_param_type) {
case CSIPHY_SETTLE_CNT_LOWER_BYTE:
@@ -583,6 +571,33 @@ static void csiphy_lanes_disable(struct csiphy_device *csiphy,
static int csiphy_init(struct csiphy_device *csiphy)
{
+ struct device *dev = csiphy->camss->dev;
+ struct csiphy_device_regs *regs;
+
+ regs = devm_kmalloc(dev, sizeof(*regs), GFP_KERNEL);
+ if (!regs)
+ return -ENOMEM;
+
+ csiphy->data = regs;
+
+ switch (csiphy->camss->res->version) {
+ case CAMSS_845:
+ regs->lane_regs = &lane_regs_sdm845[0];
+ regs->lane_array_size = ARRAY_SIZE(lane_regs_sdm845);
+ break;
+ case CAMSS_8250:
+ regs->lane_regs = &lane_regs_sm8250[0];
+ regs->lane_array_size = ARRAY_SIZE(lane_regs_sm8250);
+ break;
+ case CAMSS_8280XP:
+ regs->lane_regs = &lane_regs_sc8280xp[0];
+ regs->lane_array_size = ARRAY_SIZE(lane_regs_sc8280xp);
+ break;
+ default:
+ WARN(1, "unknown csiphy version\n");
+ return -ENODEV;
+ }
+
return 0;
}
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.h b/drivers/media/platform/qcom/camss/camss-csiphy.h
index bdf9a9c8bacc..cac1f800b7d8 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy.h
+++ b/drivers/media/platform/qcom/camss/camss-csiphy.h
@@ -95,6 +95,7 @@ struct csiphy_device {
struct csiphy_config cfg;
struct v4l2_mbus_framefmt fmt[MSM_CSIPHY_PADS_NUM];
const struct csiphy_subdev_resources *res;
+ void *data;
};
struct camss_subdev_resources;
--
2.34.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 06/13] media: qcom: camss: csiphy-3ph: Use an offset variable to find common control regs
2024-07-09 16:06 [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (4 preceding siblings ...)
2024-07-09 16:06 ` [PATCH 05/13] media: qcom: camss: csiphy-3ph: Move CSIPHY variables to data field inside csiphy struct Depeng Shao
@ 2024-07-09 16:06 ` Depeng Shao
2024-07-09 16:06 ` [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding Depeng Shao
` (8 subsequent siblings)
14 siblings, 0 replies; 99+ messages in thread
From: Depeng Shao @ 2024-07-09 16:06 UTC (permalink / raw)
To: rfoss, todor.too, bryan.odonoghue, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, quic_depengs, linux-media, linux-arm-msm,
devicetree, linux-kernel, kernel
From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
New versions of the CSIPHY locate the control registers at offset 0x1000
not offset 0x800.
Provide a variable to base an offset from for the purposes of redirecting
the base offset for the new PHY regs layout.
The existing setup bases from 0x800, the new from 0x1000 with some of the
'EXT' registers dropped but the lower-order lane config regs at offset 0x00
and up the same as before.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
---
.../qcom/camss/camss-csiphy-3ph-1-0.c | 68 ++++++++++++-------
1 file changed, 44 insertions(+), 24 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
index 93782ebfe0ea..1219a25ec55b 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
@@ -42,11 +42,11 @@
#define CSIPHY_3PH_LNn_CSI_LANE_CTRL15(n) (0x03c + 0x100 * (n))
#define CSIPHY_3PH_LNn_CSI_LANE_CTRL15_SWI_SOT_SYMBOL 0xb8
-#define CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(n) (0x800 + 0x4 * (n))
+#define CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(offset, n) (offset + 0x4 * (n))
#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE BIT(7)
#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_COMMON_PWRDN_B BIT(0)
#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_SHOW_REV_ID BIT(1)
-#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(n) (0x8b0 + 0x4 * (n))
+#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(offset, n) ((offset + 0xb0) + 0x4 * (n))
#define CSIPHY_DEFAULT_PARAMS 0
#define CSIPHY_LANE_ENABLE 1
@@ -66,6 +66,7 @@ struct csiphy_lane_regs {
struct csiphy_device_regs {
const struct csiphy_lane_regs *lane_regs;
int lane_array_size;
+ u32 offset;
};
/* GEN2 1.0 2PH */
@@ -326,19 +327,20 @@ csiphy_lane_regs lane_regs_sm8250[] = {
static void csiphy_hw_version_read(struct csiphy_device *csiphy,
struct device *dev)
{
+ struct csiphy_device_regs *regs = csiphy->data;
u32 hw_version;
- writel(CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_SHOW_REV_ID,
- csiphy->base + CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(6));
+ writel(CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_SHOW_REV_ID, csiphy->base +
+ CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 6));
hw_version = readl_relaxed(csiphy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(12));
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, 12));
hw_version |= readl_relaxed(csiphy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(13)) << 8;
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, 13)) << 8;
hw_version |= readl_relaxed(csiphy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(14)) << 16;
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, 14)) << 16;
hw_version |= readl_relaxed(csiphy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(15)) << 24;
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, 15)) << 24;
dev_dbg(dev, "CSIPHY 3PH HW Version = 0x%08x\n", hw_version);
}
@@ -349,31 +351,39 @@ static void csiphy_hw_version_read(struct csiphy_device *csiphy,
*/
static void csiphy_reset(struct csiphy_device *csiphy)
{
- writel_relaxed(0x1, csiphy->base + CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(0));
+ struct csiphy_device_regs *regs = csiphy->data;
+
+ writel_relaxed(0x1, csiphy->base +
+ CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
usleep_range(5000, 8000);
- writel_relaxed(0x0, csiphy->base + CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(0));
+ writel_relaxed(0x0, csiphy->base +
+ CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
}
static irqreturn_t csiphy_isr(int irq, void *dev)
{
struct csiphy_device *csiphy = dev;
+ struct csiphy_device_regs *regs = csiphy->data;
int i;
for (i = 0; i < 11; i++) {
int c = i + 22;
u8 val = readl_relaxed(csiphy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(i));
+ CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(regs->offset, i));
writel_relaxed(val, csiphy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(c));
+ CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, c));
}
- writel_relaxed(0x1, csiphy->base + CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(10));
- writel_relaxed(0x0, csiphy->base + CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(10));
+ writel_relaxed(0x1, csiphy->base +
+ CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 10));
+ writel_relaxed(0x0, csiphy->base +
+ CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 10));
- for (i = 22; i < 33; i++)
+ for (i = 22; i < 33; i++) {
writel_relaxed(0x0, csiphy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(i));
+ CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, i));
+ }
return IRQ_HANDLED;
}
@@ -528,6 +538,7 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy,
s64 link_freq, u8 lane_mask)
{
struct csiphy_lanes_cfg *c = &cfg->csi2->lane_cfg;
+ struct csiphy_device_regs *regs = csiphy->data;
u8 settle_cnt;
u8 val;
int i;
@@ -538,16 +549,20 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy,
for (i = 0; i < c->num_data; i++)
val |= BIT(c->data[i].pos * 2);
- writel_relaxed(val, csiphy->base + CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(5));
+ writel_relaxed(val, csiphy->base +
+ CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 5));
val = CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_COMMON_PWRDN_B;
- writel_relaxed(val, csiphy->base + CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(6));
+ writel_relaxed(val, csiphy->base +
+ CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 6));
val = 0x02;
- writel_relaxed(val, csiphy->base + CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(7));
+ writel_relaxed(val, csiphy->base +
+ CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 7));
val = 0x00;
- writel_relaxed(val, csiphy->base + CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(0));
+ writel_relaxed(val, csiphy->base +
+ CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 0));
if (csiphy_is_gen2(csiphy->camss->res->version))
csiphy_gen2_config_lanes(csiphy, settle_cnt);
@@ -555,18 +570,22 @@ static void csiphy_lanes_enable(struct csiphy_device *csiphy,
csiphy_gen1_config_lanes(csiphy, cfg, settle_cnt);
/* IRQ_MASK registers - disable all interrupts */
- for (i = 11; i < 22; i++)
- writel_relaxed(0, csiphy->base + CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(i));
+ for (i = 11; i < 22; i++) {
+ writel_relaxed(0, csiphy->base +
+ CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, i));
+ }
}
static void csiphy_lanes_disable(struct csiphy_device *csiphy,
struct csiphy_config *cfg)
{
+ struct csiphy_device_regs *regs = csiphy->data;
+
writel_relaxed(0, csiphy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(5));
+ CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 5));
writel_relaxed(0, csiphy->base +
- CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(6));
+ CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(regs->offset, 6));
}
static int csiphy_init(struct csiphy_device *csiphy)
@@ -579,6 +598,7 @@ static int csiphy_init(struct csiphy_device *csiphy)
return -ENOMEM;
csiphy->data = regs;
+ regs->offset = 0x800;
switch (csiphy->camss->res->version) {
case CAMSS_845:
--
2.34.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-07-09 16:06 [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (5 preceding siblings ...)
2024-07-09 16:06 ` [PATCH 06/13] media: qcom: camss: csiphy-3ph: Use an offset variable to find common control regs Depeng Shao
@ 2024-07-09 16:06 ` Depeng Shao
2024-07-09 20:21 ` Rob Herring (Arm)
` (3 more replies)
2024-07-09 16:06 ` [PATCH 08/13] media: qcom: camss: csiphy-3ph: Add Gen2 v1.2 two-phase MIPI CSI-2 DPHY init Depeng Shao
` (7 subsequent siblings)
14 siblings, 4 replies; 99+ messages in thread
From: Depeng Shao @ 2024-07-09 16:06 UTC (permalink / raw)
To: rfoss, todor.too, bryan.odonoghue, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, quic_depengs, linux-media, linux-arm-msm,
devicetree, linux-kernel, kernel, Yongsheng Li
Add bindings for qcom,sm8550-camss in order to support the camera
subsystem for sm8550
Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
---
.../bindings/media/qcom,sm8550-camss.yaml | 545 ++++++++++++++++++
1 file changed, 545 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml
diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml
new file mode 100644
index 000000000000..d002b0ff119e
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml
@@ -0,0 +1,545 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,sm8550-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8550 Camera Subsystem (CAMSS)
+
+maintainers:
+ - Depeng Shao <quic_depengs@quicinc.com>
+
+description: |
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,sm8550-camss
+
+ clocks:
+ minItems: 47
+ maxItems: 47
+
+ clock-names:
+ items:
+ - const: cam_ahb_clk
+ - const: cam_hf_axi
+ - const: cam_sf_axi
+ - const: camnoc_axi
+ - const: camnoc_axi_src
+ - const: core_ahb
+ - const: cpas_ahb
+ - const: slow_ahb_src
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy1
+ - const: csiphy1_timer
+ - const: csiphy2
+ - const: csiphy2_timer
+ - const: csiphy3
+ - const: csiphy3_timer
+ - const: csiphy4
+ - const: csiphy4_timer
+ - const: csiphy5
+ - const: csiphy5_timer
+ - const: csiphy6
+ - const: csiphy6_timer
+ - const: csiphy7
+ - const: csiphy7_timer
+ - const: csid_src
+ - const: csid
+ - const: csiphy_rx
+ - const: vfe0_fast_ahb
+ - const: vfe0_src
+ - const: vfe0
+ - const: cpas_vfe0
+ - const: vfe1_fast_ahb
+ - const: vfe1_src
+ - const: vfe1
+ - const: cpas_vfe2
+ - const: vfe2_fast_ahb
+ - const: vfe2_src
+ - const: vfe2
+ - const: cpas_vfe1
+ - const: vfe_lite_ahb
+ - const: vfe_lite_csid_src
+ - const: vfe_lite
+ - const: vfe_lite_cphy_rx
+ - const: vfe_lite_csid
+ - const: cpas_ife_lite
+ - const: cpas_fast_ahb_clk
+ - const: fast_ahb_src
+
+ interrupts:
+ minItems: 18
+ maxItems: 18
+
+ interrupt-names:
+ items:
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: csiphy5
+ - const: csiphy6
+ - const: csiphy7
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ iommus:
+ maxItems: 1
+
+ interconnects:
+ minItems: 4
+ maxItems: 4
+
+ interconnect-names:
+ items:
+ - const: cam_ahb
+ - const: cam_hf_0_mnoc
+ - const: cam_sf_0_mnoc
+ - const: cam_sf_icp_mnoc
+
+ power-domains:
+ items:
+ - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: IFE2 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@2:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@3:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@4:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@5:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ reg:
+ minItems: 19
+ maxItems: 19
+
+ reg-names:
+ items:
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: csiphy5
+ - const: csiphy6
+ - const: csiphy7
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csid_top
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ vdda-phy-supply:
+ description:
+ Phandle to a regulator supply to PHY core block.
+
+ vdda-pll-supply:
+ description:
+ Phandle to 1.2V regulator supply to PHY refclk pll block.
+
+required:
+ - clock-names
+ - clocks
+ - compatible
+ - interconnects
+ - interconnect-names
+ - interrupts
+ - interrupt-names
+ - iommus
+ - power-domains
+ - reg
+ - reg-names
+ - vdda-phy-supply
+ - vdda-pll-supply
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,sm8550-camcc.h>
+ #include <dt-bindings/clock/qcom,sm8550-gcc.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/interconnect/qcom,sm8550-rpmh.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ camss: camss@ace4000 {
+ compatible = "qcom,sm8550-camss";
+
+ reg = <0 0x0ace4000 0 0x2000>,
+ <0 0x0ace6000 0 0x2000>,
+ <0 0x0ace8000 0 0x2000>,
+ <0 0x0acea000 0 0x2000>,
+ <0 0x0acec000 0 0x2000>,
+ <0 0x0acee000 0 0x2000>,
+ <0 0x0acf0000 0 0x2000>,
+ <0 0x0acf2000 0 0x2000>,
+ <0 0x0acb7000 0 0xd00>,
+ <0 0x0acb9000 0 0xd00>,
+ <0 0x0acbb000 0 0xd00>,
+ <0 0x0acca000 0 0xa00>,
+ <0 0x0acce000 0 0xa00>,
+ <0 0x0acb6000 0 0x1000>,
+ <0 0x0ac62000 0 0xf000>,
+ <0 0x0ac71000 0 0xf000>,
+ <0 0x0ac80000 0 0xf000>,
+ <0 0x0acca000 0 0x2800>,
+ <0 0x0acce000 0 0x2800>;
+ reg-names = "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "csiphy6",
+ "csiphy7",
+ "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csid_top",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ vdda-phy-supply = <&vreg_l1e_0p88>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+
+ interrupts = <GIC_SPI 477 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 278 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 277 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 431 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 688 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
+
+ interrupt-names = "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "csiphy6",
+ "csiphy7",
+ "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ power-domains = <&camcc CAM_CC_IFE_0_GDSC>,
+ <&camcc CAM_CC_IFE_1_GDSC>,
+ <&camcc CAM_CC_IFE_2_GDSC>,
+ <&camcc CAM_CC_TITAN_TOP_GDSC>;
+
+ clocks = <&gcc GCC_CAMERA_AHB_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&gcc GCC_CAMERA_SF_AXI_CLK>,
+ <&camcc CAM_CC_CAMNOC_AXI_CLK>,
+ <&camcc CAM_CC_CAMNOC_AXI_CLK_SRC>,
+ <&camcc CAM_CC_CORE_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_AHB_CLK>,
+ <&camcc CAM_CC_SLOW_AHB_CLK_SRC>,
+ <&camcc CAM_CC_CSIPHY0_CLK>,
+ <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY1_CLK>,
+ <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY2_CLK>,
+ <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY3_CLK>,
+ <&camcc CAM_CC_CSI3PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY4_CLK>,
+ <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY5_CLK>,
+ <&camcc CAM_CC_CSI5PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY6_CLK>,
+ <&camcc CAM_CC_CSI6PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY7_CLK>,
+ <&camcc CAM_CC_CSI7PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSID_CLK_SRC>,
+ <&camcc CAM_CC_CSID_CLK>,
+ <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_0_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_0_CLK_SRC>,
+ <&camcc CAM_CC_IFE_0_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_0_CLK>,
+ <&camcc CAM_CC_IFE_1_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_1_CLK_SRC>,
+ <&camcc CAM_CC_IFE_1_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_1_CLK>,
+ <&camcc CAM_CC_IFE_2_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_2_CLK_SRC>,
+ <&camcc CAM_CC_IFE_2_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_2_CLK>,
+ <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK_SRC>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_LITE_CLK>,
+ <&camcc CAM_CC_CPAS_FAST_AHB_CLK>,
+ <&camcc CAM_CC_FAST_AHB_CLK_SRC>;
+
+ clock-names = "cam_ahb_clk",
+ "cam_hf_axi",
+ "cam_sf_axi",
+ "camnoc_axi",
+ "camnoc_axi_src",
+ "core_ahb",
+ "cpas_ahb",
+ "slow_ahb_src",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "csiphy2",
+ "csiphy2_timer",
+ "csiphy3",
+ "csiphy3_timer",
+ "csiphy4",
+ "csiphy4_timer",
+ "csiphy5",
+ "csiphy5_timer",
+ "csiphy6",
+ "csiphy6_timer",
+ "csiphy7",
+ "csiphy7_timer",
+ "csid_src",
+ "csid",
+ "csiphy_rx",
+ "vfe0_fast_ahb",
+ "vfe0_src",
+ "vfe0",
+ "cpas_vfe0",
+ "vfe1_fast_ahb",
+ "vfe1_src",
+ "vfe1",
+ "cpas_vfe1",
+ "vfe2_fast_ahb",
+ "vfe2_src",
+ "vfe2",
+ "cpas_vfe2",
+ "vfe_lite_ahb",
+ "vfe_lite_csid_src",
+ "vfe_lite_csid",
+ "vfe_lite_cphy_rx",
+ "vfe_lite",
+ "cpas_ife_lite",
+ "cpas_fast_ahb_clk",
+ "fast_ahb_src";
+
+ iommus = <&apps_smmu 0x800 0x20>;
+
+ interconnects =
+ <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_CAMERA_CFG 0>,
+ <&mmss_noc MASTER_CAMNOC_HF 0 &mc_virt SLAVE_EBI1 0>,
+ <&mmss_noc MASTER_CAMNOC_SF 0 &mc_virt SLAVE_EBI1 0>,
+ <&mmss_noc MASTER_CAMNOC_ICP 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names =
+ "cam_ahb",
+ "cam_hf_0_mnoc",
+ "cam_sf_0_mnoc",
+ "cam_sf_icp_mnoc";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csiphy_ep0: endpoint@0 {
+ reg = <0>;
+ clock-lanes = <7>;
+ data-lanes = <0 1>;
+ remote-endpoint = <&sensor_ep>;
+ };
+ };
+ };
+ };
+ };
--
2.34.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 08/13] media: qcom: camss: csiphy-3ph: Add Gen2 v1.2 two-phase MIPI CSI-2 DPHY init
2024-07-09 16:06 [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (6 preceding siblings ...)
2024-07-09 16:06 ` [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding Depeng Shao
@ 2024-07-09 16:06 ` Depeng Shao
2024-07-10 11:09 ` Krzysztof Kozlowski
2024-07-10 11:13 ` Bryan O'Donoghue
2024-07-09 16:06 ` [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550 Depeng Shao
` (6 subsequent siblings)
14 siblings, 2 replies; 99+ messages in thread
From: Depeng Shao @ 2024-07-09 16:06 UTC (permalink / raw)
To: rfoss, todor.too, bryan.odonoghue, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, quic_depengs, linux-media, linux-arm-msm,
devicetree, linux-kernel, kernel
Add a PHY configuration sequence for the SM8550 which uses a Qualcomm
Gen 2 version 1.2 CSI-2 PHY.
The PHY can be configured as two phase or three phase in C-PHY or D-PHY
mode. This configuration supports two-phase D-PHY mode.
Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
---
.../qcom/camss/camss-csiphy-3ph-1-0.c | 105 ++++++++++++++++++
1 file changed, 105 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
index 1219a25ec55b..b6d5a27b94a6 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
@@ -324,6 +324,111 @@ csiphy_lane_regs lane_regs_sm8250[] = {
{0x0884, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
};
+/* GEN2 1.2 2PH */
+static const struct
+csiphy_lane_regs lane_regs_sm8550[] = {
+ {0x0E90, 0x0f, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E98, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E94, 0x07, 0x01, CSIPHY_DEFAULT_PARAMS},
+ {0x00A0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0090, 0x0f, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0098, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0094, 0x07, 0x01, CSIPHY_DEFAULT_PARAMS},
+ {0x0494, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x04A0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0490, 0x0f, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0498, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0494, 0x07, 0x01, CSIPHY_DEFAULT_PARAMS},
+ {0x0894, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x08A0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0890, 0x0f, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0898, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0894, 0x07, 0x01, CSIPHY_DEFAULT_PARAMS},
+ {0x0C94, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0CA0, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C90, 0x0f, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C98, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C94, 0x07, 0x01, CSIPHY_DEFAULT_PARAMS},
+ {0x0E30, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E28, 0x04, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E00, 0x80, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E0C, 0xFF, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E38, 0x1F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E2C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E34, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E1C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E14, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E3C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E04, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E20, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0E08, 0x10, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0E10, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0030, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0000, 0x8E, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0038, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x002C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0034, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x001C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0014, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x003C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0004, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0020, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0008, 0x10, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0010, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0430, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0400, 0x8E, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0438, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x042C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0434, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x041C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0414, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x043C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0404, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0420, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0408, 0x10, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0410, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0830, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0800, 0x8E, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0838, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x082C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0834, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x081C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0814, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x083C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0804, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0820, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0808, 0x10, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0810, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C30, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C00, 0x8E, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C38, 0xFE, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C2C, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C34, 0x0F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C1C, 0x0A, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C14, 0x60, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C3C, 0xB8, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C04, 0x0C, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C20, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C08, 0x10, 0x00, CSIPHY_SETTLE_CNT_LOWER_BYTE},
+ {0x0C10, 0x52, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0094, 0xD7, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x005C, 0x04, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0060, 0xBD, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0064, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0494, 0xD7, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x045C, 0x04, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0460, 0xBD, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0464, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0894, 0xD7, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x085C, 0x04, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0860, 0xBD, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0864, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C94, 0xD7, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C5C, 0x04, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C60, 0xBD, 0x00, CSIPHY_DEFAULT_PARAMS},
+ {0x0C64, 0x7F, 0x00, CSIPHY_DEFAULT_PARAMS},
+};
+
static void csiphy_hw_version_read(struct csiphy_device *csiphy,
struct device *dev)
{
--
2.34.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550
2024-07-09 16:06 [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (7 preceding siblings ...)
2024-07-09 16:06 ` [PATCH 08/13] media: qcom: camss: csiphy-3ph: Add Gen2 v1.2 two-phase MIPI CSI-2 DPHY init Depeng Shao
@ 2024-07-09 16:06 ` Depeng Shao
2024-07-10 11:20 ` Krzysztof Kozlowski
2024-07-10 11:28 ` Bryan O'Donoghue
2024-07-09 16:06 ` [PATCH 10/13] media: qcom: camss: Add support for VFE hardware version Titan 780 Depeng Shao
` (5 subsequent siblings)
14 siblings, 2 replies; 99+ messages in thread
From: Depeng Shao @ 2024-07-09 16:06 UTC (permalink / raw)
To: rfoss, todor.too, bryan.odonoghue, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, quic_depengs, linux-media, linux-arm-msm,
devicetree, linux-kernel, kernel, Yongsheng Li
The CSID in SM8550 is gen3, it has new register offset and new
functionality. The buf done irq,register update and reset are
moved to CSID gen3. And CSID gen3 has a new register block which
is named as CSID top, it controls the output of CSID, since the
CSID can connect to Sensor Front End (SFE) or original VFE, the
register in top block is used to control the HW connection.
Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
---
drivers/media/platform/qcom/camss/Makefile | 1 +
.../platform/qcom/camss/camss-csid-gen3.c | 445 ++++++++++++++++++
.../platform/qcom/camss/camss-csid-gen3.h | 26 +
.../media/platform/qcom/camss/camss-csid.h | 2 +
4 files changed, 474 insertions(+)
create mode 100644 drivers/media/platform/qcom/camss/camss-csid-gen3.c
create mode 100644 drivers/media/platform/qcom/camss/camss-csid-gen3.h
diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
index e636968a1126..c336e4c1a399 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -7,6 +7,7 @@ qcom-camss-objs += \
camss-csid-4-1.o \
camss-csid-4-7.o \
camss-csid-gen2.o \
+ camss-csid-gen3.o \
camss-csiphy-2ph-1-0.o \
camss-csiphy-3ph-1-0.o \
camss-csiphy.o \
diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
new file mode 100644
index 000000000000..17fd7c5499de
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
@@ -0,0 +1,445 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-csid-gen3.c
+ *
+ * Qualcomm MSM Camera Subsystem - CSID (CSI Decoder) Module
+ *
+ * Copyright (c) 2024 Qualcomm Technologies, Inc.
+ */
+#include <linux/completion.h>
+#include <linux/delay.h>
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/of.h>
+
+#include "camss.h"
+#include "camss-csid.h"
+#include "camss-csid-gen3.h"
+
+
+#define CSID_TOP_IO_PATH_CFG0(csid) (0x4 * (csid))
+#define OUTPUT_IFE_EN 0x100
+#define INTERNAL_CSID 1
+
+#define CSID_HW_VERSION 0x0
+#define HW_VERSION_STEPPING 0
+#define HW_VERSION_REVISION 16
+#define HW_VERSION_GENERATION 28
+
+#define CSID_RST_CFG 0xC
+#define RST_MODE 0
+#define RST_LOCATION 4
+
+#define CSID_RST_CMD 0x10
+#define SELECT_HW_RST 0
+#define SELECT_SW_RST 1
+#define SELECT_IRQ_RST 2
+
+#define CSID_CSI2_RX_IRQ_STATUS 0x9C
+#define CSID_CSI2_RX_IRQ_MASK 0xA0
+#define CSID_CSI2_RX_IRQ_CLEAR 0xA4
+#define CSID_CSI2_RX_IRQ_SET 0xA8
+
+#define CSID_CSI2_RDIN_IRQ_STATUS(rdi) (0xEC + 0x10 * (rdi))
+#define CSID_CSI2_RDIN_IRQ_MASK(rdi) (0xF0 + 0x10 * (rdi))
+#define CSID_CSI2_RDIN_INFO_FIFO_FULL 2
+#define CSID_CSI2_RDIN_INFO_CAMIF_EOF 3
+#define CSID_CSI2_RDIN_INFO_CAMIF_SOF 4
+#define CSID_CSI2_RDIN_INFO_INPUT_EOF 9
+#define CSID_CSI2_RDIN_INFO_INPUT_SOF 12
+#define CSID_CSI2_RDIN_ERROR_REC_FRAME_DROP 18
+#define CSID_CSI2_RDIN_ERROR_REC_OVERFLOW_IRQ 19
+#define CSID_CSI2_RDIN_ERROR_REC_CCIF_VIOLATION 20
+#define CSID_CSI2_RDIN_EPOCH0 21
+#define CSID_CSI2_RDIN_EPOCH1 22
+#define CSID_CSI2_RDIN_RUP_DONE 23
+#define CSID_CSI2_RDIN_CCIF_VIOLATION 29
+
+#define CSID_CSI2_RDIN_IRQ_CLEAR(rdi) (0xF4 + 0x10 * (rdi))
+#define CSID_CSI2_RDIN_IRQ_SET(rdi) (0xF8 + 0x10 * (rdi))
+
+#define CSID_TOP_IRQ_STATUS 0x7C
+#define TOP_IRQ_STATUS_RESET_DONE 0
+#define CSID_TOP_IRQ_MASK 0x80
+#define CSID_TOP_IRQ_CLEAR 0x84
+#define CSID_TOP_IRQ_SET 0x88
+#define CSID_IRQ_CMD 0x14
+#define IRQ_CMD_CLEAR 0
+#define IRQ_CMD_SET 4
+
+#define CSID_BUF_DONE_IRQ_STATUS 0x8C
+#define BUF_DONE_IRQ_STATUS_RDI_OFFSET (csid_is_lite(csid) ? 0x1 : 0xE)
+#define CSID_BUF_DONE_IRQ_MASK 0x90
+#define CSID_BUF_DONE_IRQ_CLEAR 0x94
+#define CSID_BUF_DONE_IRQ_SET 0x98
+
+#define CSID_CSI2_RX_CFG0 0x200
+#define CSI2_RX_CFG0_NUM_ACTIVE_LANES 0
+#define CSI2_RX_CFG0_DL0_INPUT_SEL 4
+#define CSI2_RX_CFG0_DL1_INPUT_SEL 8
+#define CSI2_RX_CFG0_DL2_INPUT_SEL 12
+#define CSI2_RX_CFG0_DL3_INPUT_SEL 16
+#define CSI2_RX_CFG0_PHY_NUM_SEL 20
+#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
+#define CSI2_RX_CFG0_PHY_TYPE_SEL 24
+#define CSI2_RX_CFG0_TPG_MUX_EN 27
+#define CSI2_RX_CFG0_TPG_NUM_SEL 28
+
+#define CSID_CSI2_RX_CFG1 0x204
+#define CSI2_RX_CFG1_PACKET_ECC_CORRECTION_EN 0
+#define CSI2_RX_CFG1_DE_SCRAMBLE_EN 1
+#define CSI2_RX_CFG1_VC_MODE 2
+#define CSI2_RX_CFG1_COMPLETE_STREAM_EN 4
+#define CSI2_RX_CFG1_COMPLETE_STREAM_FRAME_TIMING 5
+#define CSI2_RX_CFG1_MISR_EN 6
+#define CSI2_RX_CFG1_PHY_BIST_EN 7
+#define CSI2_RX_CFG1_EPD_MODE 8
+#define CSI2_RX_CFG1_EOTP_EN 9
+#define CSI2_RX_CFG1_DYN_SWITCH_EN 10
+#define CSI2_RX_CFG1_RUP_AUP_LATCH_DIS 11
+
+#define CSID_CSI2_RX_CAPTURE_CTRL 0x208
+#define CSI2_RX_CAPTURE_CTRL_LONG_PKT_CAPTURE_EN 0
+#define CSI2_RX_CAPTURE_CTRL_SHORT_PKT_CAPTURE_EN 1
+#define CSI2_RX_CAPTURE_CTRL_CPHY_PKT_CAPTURE_EN 3
+#define CSI2_RX_CAPTURE_CTRL_LONG_PKT_CAPTURE_DT 4
+#define CSI2_RX_CAPTURE_CTRL_LONG_PKT_CAPTURE_VC 10
+#define CSI2_RX_CAPTURE_CTRL_SHORT_PKT_CAPTURE_VC 15
+#define CSI2_RX_CAPTURE_CTRL_CPHY_PKT_CAPTURE_DT 20
+#define CSI2_RX_CAPTURE_CTRL_CPHY_PKT_CAPTURE_VC 26
+
+#define CSID_RDI_CFG0(rdi) (0x500 + 0x100 * (rdi))
+#define RDI_CFG0_VFR_EN 0
+#define RDI_CFG0_FRAME_ID_DEC_EN 1
+#define RDI_CFG0_RETIME_DIS 5
+#define RDI_CFG0_TIMESTAMP_EN 6
+#define RDI_CFG0_TIMESTAMP_STB_SEL 8
+#define RDI_CFG0_DECODE_FORMAT 12
+#define RDI_CFG0_DT 16
+#define RDI_CFG0_VC 22
+#define RDI_CFG0_DT_ID 27
+#define RDI_CFG0_EN 31
+
+#define CSID_RDI_CFG1(rdi) (0x510 + 0x100 * (rdi))
+#define RDI_CFG1_BYTE_CNTR_EN 2
+#define RDI_CFG1_DROP_H_EN 5
+#define RDI_CFG1_DROP_V_EN 6
+#define RDI_CFG1_CROP_H_EN 7
+#define RDI_CFG1_CROP_V_EN 8
+#define RDI_CFG1_MISR_EN 9
+#define RDI_CFG1_PIX_STORE 10
+#define RDI_CFG1_PLAIN_ALIGNMENT 11
+#define RDI_CFG1_PLAIN_FORMAT 12
+#define RDI_CFG1_EARLY_EOF_EN 14
+#define RDI_CFG1_PACKING_FORMAT 15
+
+#define CSID_RDI_CTRL(rdi) (0x504 + 0x100 * (rdi))
+#define RDI_CTRL_START_CMD 0
+#define RDI_CTRL_START_MODE 2
+
+#define CSID_RDI_EPOCH_IRQ_CFG(rdi) (0x52C + 0x100 * (rdi))
+
+#define CSID_RDI_FRM_DROP_PATTERN(rdi) (0x540 + 0x100 * (rdi))
+#define CSID_RDI_FRM_DROP_PERIOD(rdi) (0x544 + 0x100 * (rdi))
+#define CSID_RDI_IRQ_SUBSAMPLE_PATTERN(rdi) (0x548 + 0x100 * (rdi))
+#define CSID_RDI_IRQ_SUBSAMPLE_PERIOD(rdi) (0x54C + 0x100 * (rdi))
+#define CSID_RDI_RPP_PIX_DROP_PATTERN(rdi) (0x558 + 0x100 * (rdi))
+#define CSID_RDI_RPP_PIX_DROP_PERIOD(rdi) (0x55C + 0x100 * (rdi))
+#define CSID_RDI_RPP_LINE_DROP_PATTERN(rdi) (0x560 + 0x100 * (rdi))
+#define CSID_RDI_RPP_LINE_DROP_PERIOD(rdi) (0x564 + 0x100 * (rdi))
+
+#define CSID_RDI_RPP_HCROP(rdi) (0x550 + 0x100 * (rdi))
+#define CSID_RDI_RPP_VCROP(rdi) (0x554 + 0x100 * (rdi))
+
+#define CSID_RDI_ERROR_RECOVERY_CFG0(rdi) (0x514 + 0x100 * (rdi))
+
+#define CSID_REG_UPDATE_CMD 0x18
+static inline int reg_update_rdi(struct csid_device *csid, int n)
+{
+ return BIT(n + 4) + BIT(20 + n);
+}
+
+#define REG_UPDATE_RDI reg_update_rdi
+
+static void __csid_configure_rx(struct csid_device *csid,
+ struct csid_phy_config *phy, int vc)
+{
+ int val;
+
+ val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
+ val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
+ val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX) << CSI2_RX_CFG0_PHY_NUM_SEL;
+
+ writel_relaxed(val, csid->base + CSID_CSI2_RX_CFG0);
+
+ val = 1 << CSI2_RX_CFG1_PACKET_ECC_CORRECTION_EN;
+ if (vc > 3)
+ val |= 1 << CSI2_RX_CFG1_VC_MODE;
+ writel_relaxed(val, csid->base + CSID_CSI2_RX_CFG1);
+}
+
+static void __csid_ctrl_rdi(struct csid_device *csid, int enable, u8 rdi)
+{
+ int val;
+
+ if (enable)
+ val = 1 << RDI_CTRL_START_CMD;
+ else
+ val = 0 << RDI_CTRL_START_CMD;
+ writel_relaxed(val, csid->base + CSID_RDI_CTRL(rdi));
+}
+
+static void __csid_configure_top(struct csid_device *csid)
+{
+ u32 val;
+
+ /* CSID "top" is a new function in Titan780.
+ * CSID can connect to VFE & SFE(Sensor Front End).
+ * This connection is ontrolled by CSID "top".
+ * Only enable VFE path in current driver.
+ */
+ if (csid->top_base) {
+ val = OUTPUT_IFE_EN | INTERNAL_CSID;
+ writel_relaxed(val, csid->top_base + CSID_TOP_IO_PATH_CFG0(csid->id));
+ }
+}
+
+static void __csid_configure_rdi_stream(struct csid_device *csid, u8 enable, u8 vc)
+{
+ u32 val;
+ u8 lane_cnt = csid->phy.lane_cnt;
+ /* Source pads matching RDI channels on hardware. Pad 1 -> RDI0, Pad 2 -> RDI1, etc. */
+ struct v4l2_mbus_framefmt *input_format = &csid->fmt[MSM_CSID_PAD_FIRST_SRC + vc];
+ const struct csid_format_info *format = csid_get_fmt_entry(csid->res->formats->formats,
+ csid->res->formats->nformats,
+ input_format->code);
+
+ if (!lane_cnt)
+ lane_cnt = 4;
+
+ /*
+ * DT_ID is a two bit bitfield that is concatenated with
+ * the four least significant bits of the five bit VC
+ * bitfield to generate an internal CID value.
+ *
+ * CSID_RDI_CFG0(vc)
+ * DT_ID : 28:27
+ * VC : 26:22
+ * DT : 21:16
+ *
+ * CID : VC 3:0 << 2 | DT_ID 1:0
+ */
+ u8 dt_id = vc & 0x03;
+
+ val = 1 << RDI_CFG0_TIMESTAMP_EN;
+ val |= 2 << RDI_CFG0_TIMESTAMP_STB_SEL;
+ /* note: for non-RDI path, this should be format->decode_format */
+ val |= DECODE_FORMAT_PAYLOAD_ONLY << RDI_CFG0_DECODE_FORMAT;
+ val |= vc << RDI_CFG0_VC;
+ val |= format->data_type << RDI_CFG0_DT;
+ val |= dt_id << RDI_CFG0_DT_ID;
+
+ writel_relaxed(val, csid->base + CSID_RDI_CFG0(vc));
+
+ val = 1 << RDI_CFG1_PACKING_FORMAT;
+ val |= 1 << RDI_CFG1_PIX_STORE;
+ val |= 1 << RDI_CFG1_DROP_H_EN;
+ val |= 1 << RDI_CFG1_DROP_V_EN;
+ val |= 1 << RDI_CFG1_CROP_H_EN;
+ val |= 1 << RDI_CFG1_CROP_V_EN;
+ val |= RDI_CFG1_EARLY_EOF_EN;
+
+ writel_relaxed(val, csid->base + CSID_RDI_CFG1(vc));
+
+ val = 0;
+ writel_relaxed(val, csid->base + CSID_RDI_IRQ_SUBSAMPLE_PERIOD(vc));
+
+ val = 1;
+ writel_relaxed(val, csid->base + CSID_RDI_IRQ_SUBSAMPLE_PATTERN(vc));
+
+ val = 0;
+ writel_relaxed(val, csid->base + CSID_RDI_CTRL(vc));
+
+ val = readl_relaxed(csid->base + CSID_RDI_CFG0(vc));
+ val |= enable << RDI_CFG0_EN;
+ writel_relaxed(val, csid->base + CSID_RDI_CFG0(vc));
+}
+
+static void csid_configure_stream(struct csid_device *csid, u8 enable)
+{
+ u8 i;
+
+ /* Loop through all enabled VCs and configure stream for each */
+ for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS; i++)
+ if (csid->phy.en_vc & BIT(i)) {
+ /* Configure CSID "top" */
+ __csid_configure_top(csid);
+ __csid_configure_rdi_stream(csid, enable, i);
+ __csid_configure_rx(csid, &csid->phy, i);
+ __csid_ctrl_rdi(csid, enable, i);
+ }
+}
+
+static int csid_configure_testgen_pattern(struct csid_device *csid, s32 val)
+{
+ if (val > 0 && val <= csid->testgen.nmodes)
+ csid->testgen.mode = val;
+
+ return 0;
+}
+
+/*
+ * csid_hw_version - CSID hardware version query
+ * @csid: CSID device
+ *
+ * Return HW version or error
+ */
+static u32 csid_hw_version(struct csid_device *csid)
+{
+ u32 hw_version;
+ u32 hw_gen;
+ u32 hw_rev;
+ u32 hw_step;
+
+ hw_version = readl_relaxed(csid->base + CSID_HW_VERSION);
+ hw_gen = (hw_version >> HW_VERSION_GENERATION) & 0xF;
+ hw_rev = (hw_version >> HW_VERSION_REVISION) & 0xFFF;
+ hw_step = (hw_version >> HW_VERSION_STEPPING) & 0xFFFF;
+ dev_info(csid->camss->dev, "CSID HW Version = %u.%u.%u\n",
+ hw_gen, hw_rev, hw_step);
+
+ return hw_version;
+}
+
+/*
+ * csid_isr - CSID module interrupt service routine
+ * @irq: Interrupt line
+ * @dev: CSID device
+ *
+ * Return IRQ_HANDLED on success
+ */
+static irqreturn_t csid_isr(int irq, void *dev)
+{
+ struct csid_device *csid = dev;
+ u32 val, buf_done_val;
+ u8 reset_done;
+ int i;
+
+ val = readl_relaxed(csid->base + CSID_TOP_IRQ_STATUS);
+ writel_relaxed(val, csid->base + CSID_TOP_IRQ_CLEAR);
+ reset_done = val & BIT(TOP_IRQ_STATUS_RESET_DONE);
+
+ val = readl_relaxed(csid->base + CSID_CSI2_RX_IRQ_STATUS);
+ writel_relaxed(val, csid->base + CSID_CSI2_RX_IRQ_CLEAR);
+
+ buf_done_val = readl_relaxed(csid->base + CSID_BUF_DONE_IRQ_STATUS);
+ writel_relaxed(buf_done_val, csid->base + CSID_BUF_DONE_IRQ_CLEAR);
+
+ /* Read and clear IRQ status for each enabled RDI channel */
+ for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS; i++)
+ if (csid->phy.en_vc & BIT(i)) {
+ val = readl_relaxed(csid->base + CSID_CSI2_RDIN_IRQ_STATUS(i));
+ writel_relaxed(val, csid->base + CSID_CSI2_RDIN_IRQ_CLEAR(i));
+ }
+
+ val = 1 << IRQ_CMD_CLEAR;
+ writel_relaxed(val, csid->base + CSID_IRQ_CMD);
+
+ if (reset_done)
+ complete(&csid->reset_complete);
+
+ return IRQ_HANDLED;
+}
+
+/*
+ * csid_reset - Trigger reset on CSID module and wait to complete
+ * @csid: CSID device
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+static int csid_reset(struct csid_device *csid)
+{
+ unsigned long time;
+ u32 val;
+ int i;
+
+ reinit_completion(&csid->reset_complete);
+
+ writel_relaxed(1, csid->base + CSID_TOP_IRQ_CLEAR);
+ writel_relaxed(1, csid->base + CSID_IRQ_CMD);
+ writel_relaxed(1, csid->base + CSID_TOP_IRQ_MASK);
+
+ for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS; i++)
+ if (csid->phy.en_vc & BIT(i)) {
+ writel_relaxed(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
+ csid->base + CSID_BUF_DONE_IRQ_CLEAR);
+ writel_relaxed(0x1 << IRQ_CMD_CLEAR, csid->base + CSID_IRQ_CMD);
+ writel_relaxed(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
+ csid->base + CSID_BUF_DONE_IRQ_MASK);
+ }
+
+ /* preserve registers */
+ val = (0x1 << RST_LOCATION) | (0x1 << RST_MODE);
+ writel_relaxed(val, csid->base + CSID_RST_CFG);
+
+ val = (0x1 << SELECT_HW_RST) | (0x1 << SELECT_IRQ_RST);
+ writel_relaxed(val, csid->base + CSID_RST_CMD);
+
+ time = wait_for_completion_timeout(&csid->reset_complete,
+ msecs_to_jiffies(CSID_RESET_TIMEOUT_MS));
+ if (!time) {
+ dev_err(csid->camss->dev, "CSID reset timeout\n");
+ return -EIO;
+ }
+
+ return 0;
+}
+
+static u32 csid_src_pad_code(struct csid_device *csid, u32 sink_code,
+ unsigned int match_format_idx, u32 match_code)
+{
+ switch (sink_code) {
+ case MEDIA_BUS_FMT_SBGGR10_1X10:
+ {
+ u32 src_code[] = {
+ MEDIA_BUS_FMT_SBGGR10_1X10,
+ MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_LE,
+ };
+
+ return csid_find_code(src_code, ARRAY_SIZE(src_code),
+ match_format_idx, match_code);
+ }
+ case MEDIA_BUS_FMT_Y10_1X10:
+ {
+ u32 src_code[] = {
+ MEDIA_BUS_FMT_Y10_1X10,
+ MEDIA_BUS_FMT_Y10_2X8_PADHI_LE,
+ };
+
+ return csid_find_code(src_code, ARRAY_SIZE(src_code),
+ match_format_idx, match_code);
+ }
+ default:
+ if (match_format_idx > 0)
+ return 0;
+
+ return sink_code;
+ }
+}
+
+static void csid_subdev_init(struct csid_device *csid)
+{
+ csid->testgen.modes = csid_testgen_modes;
+ csid->testgen.nmodes = CSID_PAYLOAD_MODE_NUM_SUPPORTED_GEN2;
+}
+
+const struct csid_hw_ops csid_ops_gen3 = {
+ .configure_stream = csid_configure_stream,
+ .configure_testgen_pattern = csid_configure_testgen_pattern,
+ .hw_version = csid_hw_version,
+ .isr = csid_isr,
+ .reset = csid_reset,
+ .src_pad_code = csid_src_pad_code,
+ .subdev_init = csid_subdev_init,
+};
diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.h b/drivers/media/platform/qcom/camss/camss-csid-gen3.h
new file mode 100644
index 000000000000..2241b91fd09e
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.h
@@ -0,0 +1,26 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * camss-csid-gen3.h
+ *
+ * Qualcomm MSM Camera Subsystem - CSID (CSI Decoder) Module Generation 1
+ *
+ * Copyright (c) 2024 Qualcomm Technologies, Inc.
+ */
+#ifndef QC_MSM_CAMSS_CSID_GEN3_H
+#define QC_MSM_CAMSS_CSID_GEN3_H
+
+#define DECODE_FORMAT_UNCOMPRESSED_8_BIT 0x1
+#define DECODE_FORMAT_UNCOMPRESSED_10_BIT 0x2
+#define DECODE_FORMAT_UNCOMPRESSED_12_BIT 0x3
+#define DECODE_FORMAT_UNCOMPRESSED_14_BIT 0x4
+#define DECODE_FORMAT_UNCOMPRESSED_16_BIT 0x5
+#define DECODE_FORMAT_UNCOMPRESSED_20_BIT 0x6
+#define DECODE_FORMAT_UNCOMPRESSED_24_BIT 0x7
+#define DECODE_FORMAT_PAYLOAD_ONLY 0xf
+
+
+#define PLAIN_FORMAT_PLAIN8 0x0 /* supports DPCM, UNCOMPRESSED_6/8_BIT */
+#define PLAIN_FORMAT_PLAIN16 0x1 /* supports DPCM, UNCOMPRESSED_10/16_BIT */
+#define PLAIN_FORMAT_PLAIN32 0x2 /* supports UNCOMPRESSED_20_BIT */
+
+#endif /* QC_MSM_CAMSS_CSID_GEN3_H */
diff --git a/drivers/media/platform/qcom/camss/camss-csid.h b/drivers/media/platform/qcom/camss/camss-csid.h
index 8cdae98e4dca..ae5b6b0dc0ea 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.h
+++ b/drivers/media/platform/qcom/camss/camss-csid.h
@@ -167,7 +167,9 @@ struct csid_device {
struct v4l2_subdev subdev;
struct media_pad pads[MSM_CSID_PADS_NUM];
void __iomem *base;
+ void __iomem *top_base;
u32 irq;
+ u32 reg_update;
char irq_name[30];
struct camss_clock *clock;
int nclocks;
--
2.34.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 10/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-07-09 16:06 [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (8 preceding siblings ...)
2024-07-09 16:06 ` [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550 Depeng Shao
@ 2024-07-09 16:06 ` Depeng Shao
2024-07-10 11:22 ` Krzysztof Kozlowski
2024-07-10 11:47 ` Bryan O'Donoghue
2024-07-09 16:06 ` [PATCH 11/13] media: qcom: camss: Add notify interface in camss driver Depeng Shao
` (4 subsequent siblings)
14 siblings, 2 replies; 99+ messages in thread
From: Depeng Shao @ 2024-07-09 16:06 UTC (permalink / raw)
To: rfoss, todor.too, bryan.odonoghue, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, quic_depengs, linux-media, linux-arm-msm,
devicetree, linux-kernel, kernel, Yongsheng Li
Add support for VFE found on SM8550 (Titan 780). This implementation is
based on the titan 480 implementation. It supports the normal and lite
VFE.
Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
---
drivers/media/platform/qcom/camss/Makefile | 1 +
.../media/platform/qcom/camss/camss-vfe-780.c | 404 ++++++++++++++++++
2 files changed, 405 insertions(+)
create mode 100644 drivers/media/platform/qcom/camss/camss-vfe-780.c
diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
index c336e4c1a399..a83b7a8dcef7 100644
--- a/drivers/media/platform/qcom/camss/Makefile
+++ b/drivers/media/platform/qcom/camss/Makefile
@@ -17,6 +17,7 @@ qcom-camss-objs += \
camss-vfe-4-8.o \
camss-vfe-17x.o \
camss-vfe-480.o \
+ camss-vfe-780.o \
camss-vfe-gen1.o \
camss-vfe.o \
camss-video.o \
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-780.c b/drivers/media/platform/qcom/camss/camss-vfe-780.c
new file mode 100644
index 000000000000..abef2d5b9c2e
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-vfe-780.c
@@ -0,0 +1,404 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * camss-vfe-780.c
+ *
+ * Qualcomm MSM Camera Subsystem - VFE (Video Front End) Module v780 (SM8550)
+ *
+ * Copyright (c) 2024 Qualcomm Technologies, Inc.
+ */
+
+#include <linux/interrupt.h>
+#include <linux/io.h>
+#include <linux/iopoll.h>
+
+#include "camss.h"
+#include "camss-vfe.h"
+
+#define VFE_HW_VERSION (vfe_is_lite(vfe) ? 0x1000 : 0x0)
+
+#define VFE_IRQ_CMD (vfe_is_lite(vfe) ? 0x1038 : 0x30)
+#define IRQ_CMD_GLOBAL_CLEAR BIT(0)
+
+#define VFE_IRQ_MASK(n) ((vfe_is_lite(vfe) ? 0x1024 : 0x34) + (n) * 4)
+#define IRQ_MASK_0_BUS_TOP_IRQ (vfe_is_lite(vfe) ? BIT(0) | BIT(1) | BIT(2) : \
+ BIT(0) | BIT(4) | BIT(18))
+#define IRQ_MASK_1_BUS_TOP_IRQ(n) (vfe_is_lite(vfe) ? BIT(2 * n + 2) | BIT(2 * n + 3) : \
+ BIT(2 * n + 8) | BIT(2 * n + 9))
+#define VFE_IRQ_CLEAR(n) ((vfe_is_lite(vfe) ? 0x102C : 0x3C) + (n) * 4)
+#define VFE_IRQ_STATUS(n) ((vfe_is_lite(vfe) ? 0x101C : 0x44) + (n) * 4)
+
+#define BUS_REG_BASE (vfe_is_lite(vfe) ? 0x1200 : 0xC00)
+
+#define VFE_BUS_WM_CGC_OVERRIDE (BUS_REG_BASE + 0x08)
+#define WM_CGC_OVERRIDE_ALL (0x7FFFFFF)
+
+#define VFE_BUS_WM_TEST_BUS_CTRL (BUS_REG_BASE + 0xDC)
+
+#define VFE_BUS_WM_CFG(n) (BUS_REG_BASE + 0x200 + (n) * 0x100)
+#define WM_CFG_EN (0)
+#define WM_VIR_FRM_EN (1)
+#define WM_CFG_MODE (16)
+#define MODE_QCOM_PLAIN (0)
+#define MODE_MIPI_RAW (1)
+#define VFE_BUS_WM_IMAGE_ADDR(n) (BUS_REG_BASE + 0x204 + (n) * 0x100)
+#define VFE_BUS_WM_FRAME_INCR(n) (BUS_REG_BASE + 0x208 + (n) * 0x100)
+#define VFE_BUS_WM_IMAGE_CFG_0(n) (BUS_REG_BASE + 0x20c + (n) * 0x100)
+#define WM_IMAGE_CFG_0_DEFAULT_WIDTH (0xFFFF)
+#define VFE_BUS_WM_IMAGE_CFG_1(n) (BUS_REG_BASE + 0x210 + (n) * 0x100)
+#define VFE_BUS_WM_IMAGE_CFG_2(n) (BUS_REG_BASE + 0x214 + (n) * 0x100)
+#define WM_IMAGE_CFG_2_DEFAULT_STRIDE (0xFFFF)
+#define VFE_BUS_WM_PACKER_CFG(n) (BUS_REG_BASE + 0x218 + (n) * 0x100)
+#define VFE_BUS_WM_HEADER_ADDR(n) (BUS_REG_BASE + 0x220 + (n) * 0x100)
+#define VFE_BUS_WM_HEADER_INCR(n) (BUS_REG_BASE + 0x224 + (n) * 0x100)
+#define VFE_BUS_WM_HEADER_CFG(n) (BUS_REG_BASE + 0x228 + (n) * 0x100)
+
+#define VFE_BUS_WM_IRQ_SUBSAMPLE_PERIOD(n) (BUS_REG_BASE + 0x230 + (n) * 0x100)
+#define VFE_BUS_WM_IRQ_SUBSAMPLE_PATTERN(n) (BUS_REG_BASE + 0x234 + (n) * 0x100)
+#define VFE_BUS_WM_FRAMEDROP_PERIOD(n) (BUS_REG_BASE + 0x238 + (n) * 0x100)
+#define VFE_BUS_WM_FRAMEDROP_PATTERN(n) (BUS_REG_BASE + 0x23c + (n) * 0x100)
+
+#define VFE_BUS_WM_MMU_PREFETCH_CFG(n) (BUS_REG_BASE + 0x260 + (n) * 0x100)
+#define VFE_BUS_WM_MMU_PREFETCH_MAX_OFFSET(n) (BUS_REG_BASE + 0x264 + (n) * 0x100)
+#define VFE_BUS_WM_SYSTEM_CACHE_CFG(n) (BUS_REG_BASE + 0x268 + (n) * 0x100)
+
+/* for titan 780, each bus client is hardcoded to a specific path */
+#define RDI_WM(n) ((vfe_is_lite(vfe) ? 0x0 : 0x17) + (n))
+
+#define MAX_VFE_OUTPUT_LINES 4
+#define MAX_VFE_ACT_BUF 1
+
+static u32 vfe_hw_version(struct vfe_device *vfe)
+{
+ u32 hw_version = readl_relaxed(vfe->base + VFE_HW_VERSION);
+
+ u32 gen = (hw_version >> 28) & 0xF;
+ u32 rev = (hw_version >> 16) & 0xFFF;
+ u32 step = hw_version & 0xFFFF;
+
+ dev_info(vfe->camss->dev, "VFE HW Version = %u.%u.%u\n", gen, rev, step);
+
+ return hw_version;
+}
+
+static void vfe_wm_start(struct vfe_device *vfe, u8 wm, struct vfe_line *line)
+{
+ struct v4l2_pix_format_mplane *pix =
+ &line->video_out.active_fmt.fmt.pix_mp;
+
+ wm = RDI_WM(wm); /* map to actual WM used (from wm=RDI index) */
+
+ /* no clock gating at bus input */
+ writel_relaxed(0, vfe->base + VFE_BUS_WM_CGC_OVERRIDE);
+
+ writel_relaxed(0x0, vfe->base + VFE_BUS_WM_TEST_BUS_CTRL);
+
+ writel_relaxed(ALIGN(pix->plane_fmt[0].bytesperline, 16) * pix->height >> 8,
+ vfe->base + VFE_BUS_WM_FRAME_INCR(wm));
+ writel_relaxed((WM_IMAGE_CFG_0_DEFAULT_WIDTH & 0xFFFF),
+ vfe->base + VFE_BUS_WM_IMAGE_CFG_0(wm));
+ writel_relaxed(WM_IMAGE_CFG_2_DEFAULT_STRIDE,
+ vfe->base + VFE_BUS_WM_IMAGE_CFG_2(wm));
+ writel_relaxed(0, vfe->base + VFE_BUS_WM_PACKER_CFG(wm));
+
+ /* no dropped frames, one irq per frame */
+ writel_relaxed(0, vfe->base + VFE_BUS_WM_FRAMEDROP_PERIOD(wm));
+ writel_relaxed(1, vfe->base + VFE_BUS_WM_FRAMEDROP_PATTERN(wm));
+ writel_relaxed(0, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PERIOD(wm));
+ writel_relaxed(1, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PATTERN(wm));
+
+ writel_relaxed(1, vfe->base + VFE_BUS_WM_MMU_PREFETCH_CFG(wm));
+ writel_relaxed(0xFFFFFFFF, vfe->base + VFE_BUS_WM_MMU_PREFETCH_MAX_OFFSET(wm));
+
+ writel_relaxed(1 << WM_CFG_EN | MODE_MIPI_RAW << WM_CFG_MODE,
+ vfe->base + VFE_BUS_WM_CFG(wm));
+}
+
+static void vfe_wm_stop(struct vfe_device *vfe, u8 wm)
+{
+ wm = RDI_WM(wm); /* map to actual WM used (from wm=RDI index) */
+ writel_relaxed(0, vfe->base + VFE_BUS_WM_CFG(wm));
+}
+
+static void vfe_wm_update(struct vfe_device *vfe, u8 wm, u64 addr,
+ struct vfe_line *line)
+{
+ wm = RDI_WM(wm); /* map to actual WM used (from wm=RDI index) */
+ writel_relaxed((addr >> 8) & 0xFFFFFFFF, vfe->base + VFE_BUS_WM_IMAGE_ADDR(wm));
+
+ dev_dbg(vfe->camss->dev, "%s wm:%d, image buf addr:0x%llx\n",
+ __func__, wm, addr);
+}
+
+static void vfe_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id)
+{
+ /* TODO: Add register update support */
+}
+
+static inline void vfe_reg_update_clear(struct vfe_device *vfe,
+ enum vfe_line_id line_id)
+{
+ /* TODO: Add register update clear support */
+}
+
+/*
+ * vfe_isr - VFE module interrupt handler
+ * @irq: Interrupt line
+ * @dev: VFE device
+ *
+ * Return IRQ_HANDLED on success
+ */
+static irqreturn_t vfe_isr(int irq, void *dev)
+{
+ /* Buf Done has beem moved to CSID in Titan 780.
+ * Disable VFE related IRQ.
+ * Clear the contents of this function.
+ * Return IRQ_HANDLED.
+ */
+ return IRQ_HANDLED;
+}
+
+/*
+ * vfe_halt - Trigger halt on VFE module and wait to complete
+ * @vfe: VFE device
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+static int vfe_halt(struct vfe_device *vfe)
+{
+ /* rely on vfe_disable_output() to stop the VFE */
+ return 0;
+}
+
+static int vfe_get_output(struct vfe_line *line)
+{
+ struct vfe_device *vfe = to_vfe(line);
+ struct vfe_output *output;
+ unsigned long flags;
+
+ spin_lock_irqsave(&vfe->output_lock, flags);
+
+ output = &line->output;
+ if (output->state > VFE_OUTPUT_RESERVED) {
+ dev_err(vfe->camss->dev, "Output is running\n");
+ goto error;
+ }
+
+ output->wm_num = 1;
+
+ /* Correspondence between VFE line number and WM number.
+ * line 0 -> RDI 0, line 1 -> RDI1, line 2 -> RDI2, line 3 -> PIX/RDI3
+ * Note this 1:1 mapping will not work for PIX streams.
+ */
+ output->wm_idx[0] = line->id;
+ vfe->wm_output_map[line->id] = line->id;
+
+ output->drop_update_idx = 0;
+
+ spin_unlock_irqrestore(&vfe->output_lock, flags);
+
+ return 0;
+
+error:
+ spin_unlock_irqrestore(&vfe->output_lock, flags);
+ output->state = VFE_OUTPUT_OFF;
+
+ return -EINVAL;
+}
+
+static int vfe_enable_output(struct vfe_line *line)
+{
+ struct vfe_device *vfe = to_vfe(line);
+ struct vfe_output *output = &line->output;
+ unsigned long flags;
+ unsigned int i;
+
+ spin_lock_irqsave(&vfe->output_lock, flags);
+
+ vfe_reg_update_clear(vfe, line->id);
+
+ if (output->state > VFE_OUTPUT_RESERVED) {
+ dev_err(vfe->camss->dev, "Output is not in reserved state %d\n",
+ output->state);
+ spin_unlock_irqrestore(&vfe->output_lock, flags);
+ return -EINVAL;
+ }
+
+ WARN_ON(output->gen2.active_num);
+
+ output->state = VFE_OUTPUT_ON;
+
+ output->sequence = 0;
+
+ vfe_wm_start(vfe, output->wm_idx[0], line);
+
+ for (i = 0; i < MAX_VFE_ACT_BUF; i++) {
+ output->buf[i] = vfe_buf_get_pending(output);
+ if (!output->buf[i])
+ break;
+ output->gen2.active_num++;
+ vfe_wm_update(vfe, output->wm_idx[0], output->buf[i]->addr[0], line);
+
+ vfe_reg_update(vfe, line->id);
+ }
+
+ spin_unlock_irqrestore(&vfe->output_lock, flags);
+
+ return 0;
+}
+
+/*
+ * vfe_enable - Enable streaming on VFE line
+ * @line: VFE line
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+static int vfe_enable(struct vfe_line *line)
+{
+ struct vfe_device *vfe = to_vfe(line);
+ int ret;
+
+ mutex_lock(&vfe->stream_lock);
+
+ vfe->stream_count++;
+
+ mutex_unlock(&vfe->stream_lock);
+
+ ret = vfe_get_output(line);
+ if (ret < 0)
+ goto error_get_output;
+
+ ret = vfe_enable_output(line);
+ if (ret < 0)
+ goto error_enable_output;
+
+ vfe->was_streaming = 1;
+
+ return 0;
+
+error_enable_output:
+ vfe_put_output(line);
+
+error_get_output:
+ mutex_lock(&vfe->stream_lock);
+
+ vfe->stream_count--;
+
+ mutex_unlock(&vfe->stream_lock);
+
+ return ret;
+}
+
+/*
+ * vfe_buf_done - Process write master done interrupt
+ * @vfe: VFE Device
+ * @wm: Write master id
+ */
+static void vfe_buf_done(struct vfe_device *vfe, int wm)
+{
+ struct vfe_line *line = &vfe->line[vfe->wm_output_map[wm]];
+ struct camss_buffer *ready_buf;
+ struct vfe_output *output;
+ unsigned long flags;
+ u32 index;
+ u64 ts = ktime_get_ns();
+
+ spin_lock_irqsave(&vfe->output_lock, flags);
+
+ if (vfe->wm_output_map[wm] == VFE_LINE_NONE) {
+ dev_err_ratelimited(vfe->camss->dev,
+ "Received wm done for unmapped index\n");
+ goto out_unlock;
+ }
+ output = &vfe->line[vfe->wm_output_map[wm]].output;
+
+ ready_buf = output->buf[0];
+ if (!ready_buf) {
+ dev_err_ratelimited(vfe->camss->dev,
+ "Missing ready buf %d!\n", output->state);
+ goto out_unlock;
+ }
+
+ ready_buf->vb.vb2_buf.timestamp = ts;
+ ready_buf->vb.sequence = output->sequence++;
+
+ index = 0;
+ output->buf[0] = output->buf[1];
+ if (output->buf[0])
+ index = 1;
+
+ output->buf[index] = vfe_buf_get_pending(output);
+
+ if (output->buf[index]) {
+ vfe_wm_update(vfe, output->wm_idx[0], output->buf[index]->addr[0], line);
+ vfe_reg_update(vfe, line->id);
+ } else
+ output->gen2.active_num--;
+
+ spin_unlock_irqrestore(&vfe->output_lock, flags);
+
+ vb2_buffer_done(&ready_buf->vb.vb2_buf, VB2_BUF_STATE_DONE);
+
+ return;
+
+out_unlock:
+ spin_unlock_irqrestore(&vfe->output_lock, flags);
+}
+
+/*
+ * vfe_queue_buffer - Add empty buffer
+ * @vid: Video device structure
+ * @buf: Buffer to be enqueued
+ *
+ * Add an empty buffer - depending on the current number of buffers it will be
+ * put in pending buffer queue or directly given to the hardware to be filled.
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+static int vfe_queue_buffer(struct camss_video *vid,
+ struct camss_buffer *buf)
+{
+ struct vfe_line *line = container_of(vid, struct vfe_line, video_out);
+ struct vfe_device *vfe = to_vfe(line);
+ struct vfe_output *output;
+ unsigned long flags;
+
+ output = &line->output;
+
+ spin_lock_irqsave(&vfe->output_lock, flags);
+
+ if (output->state == VFE_OUTPUT_ON &&
+ output->gen2.active_num < MAX_VFE_ACT_BUF) {
+ output->buf[output->gen2.active_num++] = buf;
+ vfe_wm_update(vfe, output->wm_idx[0], buf->addr[0], line);
+ vfe_reg_update(vfe, line->id);
+ } else {
+ vfe_buf_add_pending(output, buf);
+ }
+
+ spin_unlock_irqrestore(&vfe->output_lock, flags);
+
+ return 0;
+}
+
+static const struct camss_video_ops vfe_video_ops_780 = {
+ .queue_buffer = vfe_queue_buffer,
+ .flush_buffers = vfe_flush_buffers,
+};
+
+static void vfe_subdev_init(struct device *dev, struct vfe_device *vfe)
+{
+ vfe->video_ops = vfe_video_ops_780;
+}
+
+const struct vfe_hw_ops vfe_ops_780 = {
+ .global_reset = NULL,
+ .hw_version = vfe_hw_version,
+ .isr = vfe_isr,
+ .pm_domain_off = vfe_pm_domain_off,
+ .pm_domain_on = vfe_pm_domain_on,
+ .subdev_init = vfe_subdev_init,
+ .vfe_disable = vfe_disable,
+ .vfe_enable = vfe_enable,
+ .vfe_halt = vfe_halt,
+ .vfe_wm_stop = vfe_wm_stop,
+};
--
2.34.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 11/13] media: qcom: camss: Add notify interface in camss driver
2024-07-09 16:06 [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (9 preceding siblings ...)
2024-07-09 16:06 ` [PATCH 10/13] media: qcom: camss: Add support for VFE hardware version Titan 780 Depeng Shao
@ 2024-07-09 16:06 ` Depeng Shao
2024-07-10 11:54 ` Bryan O'Donoghue
2024-07-09 16:06 ` [PATCH 12/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (3 subsequent siblings)
14 siblings, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-07-09 16:06 UTC (permalink / raw)
To: rfoss, todor.too, bryan.odonoghue, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, quic_depengs, linux-media, linux-arm-msm,
devicetree, linux-kernel, kernel
The main v4l2 process logic in camss vfe subdev driver, so the vfe driver
handles the buf done irq and register update configuration. But the buf
done irq and register update configuration have been moved CSID HW in
Titan 780 and other new platform, so vfe driver needs to call into CSID
driver to configure the register update. And CSID driver also needs to
call into vfe driver to notify of the buf done irq.
Adding this notify interface in camss structure to do the subdevs cross
communication to decouple CSID and VFE, the subdevs can add an interface
to process the message what is routed from other subdevices, then we can
process the cross communication easily.
Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
---
.../platform/qcom/camss/camss-csid-gen3.c | 38 +++++++++++++++
.../media/platform/qcom/camss/camss-csid.h | 8 ++++
.../media/platform/qcom/camss/camss-vfe-780.c | 29 +++++++++++-
drivers/media/platform/qcom/camss/camss-vfe.h | 1 +
drivers/media/platform/qcom/camss/camss.c | 47 +++++++++++++++++++
drivers/media/platform/qcom/camss/camss.h | 9 ++++
6 files changed, 130 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
index 17fd7c5499de..585054948255 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-gen3.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
@@ -312,6 +312,18 @@ static u32 csid_hw_version(struct csid_device *csid)
return hw_version;
}
+static void csid_reg_update(struct csid_device *csid, int port_id)
+{
+ csid->reg_update |= REG_UPDATE_RDI(csid, port_id);
+ writel_relaxed(csid->reg_update, csid->base + CSID_REG_UPDATE_CMD);
+}
+
+static inline void csid_reg_update_clear(struct csid_device *csid,
+ int port_id)
+{
+ csid->reg_update &= ~REG_UPDATE_RDI(csid, port_id);
+}
+
/*
* csid_isr - CSID module interrupt service routine
* @irq: Interrupt line
@@ -341,6 +353,14 @@ static irqreturn_t csid_isr(int irq, void *dev)
if (csid->phy.en_vc & BIT(i)) {
val = readl_relaxed(csid->base + CSID_CSI2_RDIN_IRQ_STATUS(i));
writel_relaxed(val, csid->base + CSID_CSI2_RDIN_IRQ_CLEAR(i));
+
+ if (buf_done_val & BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i)) {
+ /* For Titan 780, Buf Done IRQ® has been moved to CSID from VFE.
+ * Once CSID received Buf Done, need notify this event to VFE.
+ * Trigger VFE to handle Buf Done process.
+ */
+ csid->camss->notify(&csid->subdev, CAMSS_MSG_BUF_DONE, (void *)&i);
+ }
}
val = 1 << IRQ_CMD_CLEAR;
@@ -434,6 +454,23 @@ static void csid_subdev_init(struct csid_device *csid)
csid->testgen.nmodes = CSID_PAYLOAD_MODE_NUM_SUPPORTED_GEN2;
}
+static void csid_subdev_process_msg(struct csid_device *csid, unsigned int msg_type, void *arg)
+{
+ int msg_data = *(int *)arg;
+
+ switch (msg_type) {
+ case CAMSS_MSG_RUP:
+ csid_reg_update(csid, msg_data);
+ break;
+ case CAMSS_MSG_RUP_CLEAR:
+ csid_reg_update_clear(csid, msg_data);
+ break;
+ default:
+ dev_err(csid->camss->dev, "NOT Supported EVT Type\n");
+ break;
+ }
+}
+
const struct csid_hw_ops csid_ops_gen3 = {
.configure_stream = csid_configure_stream,
.configure_testgen_pattern = csid_configure_testgen_pattern,
@@ -442,4 +479,5 @@ const struct csid_hw_ops csid_ops_gen3 = {
.reset = csid_reset,
.src_pad_code = csid_src_pad_code,
.subdev_init = csid_subdev_init,
+ .process_msg = csid_subdev_process_msg,
};
diff --git a/drivers/media/platform/qcom/camss/camss-csid.h b/drivers/media/platform/qcom/camss/camss-csid.h
index ae5b6b0dc0ea..714a8db855fd 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.h
+++ b/drivers/media/platform/qcom/camss/camss-csid.h
@@ -152,6 +152,14 @@ struct csid_hw_ops {
* @csid: CSID device
*/
void (*subdev_init)(struct csid_device *csid);
+
+ /*
+ * process_msg - receive message from other sub device
+ * @csid: CSID device
+ * @evt_type: event type
+ * @arg: arguments
+ */
+ void (*process_msg)(struct csid_device *csid, unsigned int evt_type, void *arg);
};
struct csid_subdev_resources {
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-780.c b/drivers/media/platform/qcom/camss/camss-vfe-780.c
index abef2d5b9c2e..3279fe53b987 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-780.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-780.c
@@ -131,13 +131,23 @@ static void vfe_wm_update(struct vfe_device *vfe, u8 wm, u64 addr,
static void vfe_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id)
{
- /* TODO: Add register update support */
+ int port_id = line_id;
+
+ /* RUP(register update) registers has beem moved to CSID in Titan 780.
+ * Notify the event of trigger RUP.
+ */
+ vfe->camss->notify(&vfe->line[line_id].subdev, CAMSS_MSG_RUP, (void *)&port_id);
}
static inline void vfe_reg_update_clear(struct vfe_device *vfe,
enum vfe_line_id line_id)
{
- /* TODO: Add register update clear support */
+ int port_id = line_id;
+
+ /* RUP(register update) registers has beem moved to CSID in Titan 780.
+ * Notify the event of trigger RUP clear.
+ */
+ vfe->camss->notify(&vfe->line[line_id].subdev, CAMSS_MSG_RUP_CLEAR, (void *)&port_id);
}
/*
@@ -390,6 +400,20 @@ static void vfe_subdev_init(struct device *dev, struct vfe_device *vfe)
vfe->video_ops = vfe_video_ops_780;
}
+static void vfe_subdev_process_msg(struct vfe_device *vfe, unsigned int msg_type, void *arg)
+{
+ int port_id = *(int *)arg;
+
+ switch (msg_type) {
+ case CAMSS_MSG_BUF_DONE:
+ vfe_buf_done(vfe, port_id);
+ break;
+
+ default:
+ break;
+ }
+}
+
const struct vfe_hw_ops vfe_ops_780 = {
.global_reset = NULL,
.hw_version = vfe_hw_version,
@@ -401,4 +425,5 @@ const struct vfe_hw_ops vfe_ops_780 = {
.vfe_enable = vfe_enable,
.vfe_halt = vfe_halt,
.vfe_wm_stop = vfe_wm_stop,
+ .process_msg = vfe_subdev_process_msg,
};
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.h b/drivers/media/platform/qcom/camss/camss-vfe.h
index 10e2cc3c0b83..a8b09ce9941b 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.h
+++ b/drivers/media/platform/qcom/camss/camss-vfe.h
@@ -115,6 +115,7 @@ struct vfe_hw_ops {
int (*vfe_halt)(struct vfe_device *vfe);
void (*violation_read)(struct vfe_device *vfe);
void (*vfe_wm_stop)(struct vfe_device *vfe, u8 wm);
+ void (*process_msg)(struct vfe_device *vfe, unsigned int msg_type, void *arg);
};
struct vfe_isr_ops {
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 1f1f44f6fbb2..abeb0918e47d 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -2202,6 +2202,52 @@ static void camss_genpd_cleanup(struct camss *camss)
dev_pm_domain_detach(camss->genpd, true);
}
+static void camss_notify_msg(struct v4l2_subdev *sd,
+ unsigned int msg_type, void *arg)
+{
+ struct v4l2_device *v4l2_dev = sd->v4l2_dev;
+ struct camss *camss = to_camss(v4l2_dev);
+ struct vfe_device *vfe;
+ struct vfe_line *vfe_line;
+ struct csid_device *csid;
+ int evt_data = *(int *)arg;
+
+ switch (msg_type) {
+ case CAMSS_MSG_BUF_DONE:
+ csid = v4l2_get_subdevdata(sd);
+ vfe = &(camss->vfe[csid->id]);
+ if (vfe->res->hw_ops->process_msg)
+ vfe->res->hw_ops->process_msg(vfe,
+ CAMSS_MSG_BUF_DONE, (void *)&evt_data);
+ break;
+
+ case CAMSS_MSG_RUP:
+ vfe_line = v4l2_get_subdevdata(sd);
+ vfe = to_vfe(vfe_line);
+ csid = &(camss->csid[vfe->id]);
+
+ if (csid->res->hw_ops->process_msg)
+ csid->res->hw_ops->process_msg(csid,
+ CAMSS_MSG_RUP, (void *)&evt_data);
+ break;
+
+ case CAMSS_MSG_RUP_CLEAR:
+ vfe_line = v4l2_get_subdevdata(sd);
+ vfe = to_vfe(vfe_line);
+ csid = &(camss->csid[vfe->id]);
+
+ if (csid->res->hw_ops->process_msg)
+ csid->res->hw_ops->process_msg(csid,
+ CAMSS_MSG_RUP_CLEAR, (void *)&evt_data);
+
+ break;
+
+ default:
+ dev_err(camss->dev, "Not supported evt type\n");
+ break;
+ }
+}
+
/*
* camss_probe - Probe CAMSS platform device
* @pdev: Pointer to CAMSS platform device
@@ -2272,6 +2318,7 @@ static int camss_probe(struct platform_device *pdev)
media_device_init(&camss->media_dev);
camss->v4l2_dev.mdev = &camss->media_dev;
+ camss->notify = camss_notify_msg;
ret = v4l2_device_register(camss->dev, &camss->v4l2_dev);
if (ret < 0) {
dev_err(dev, "Failed to register V4L2 device: %d\n", ret);
diff --git a/drivers/media/platform/qcom/camss/camss.h b/drivers/media/platform/qcom/camss/camss.h
index 73c47c07fc30..65fcebd42c4b 100644
--- a/drivers/media/platform/qcom/camss/camss.h
+++ b/drivers/media/platform/qcom/camss/camss.h
@@ -86,6 +86,13 @@ enum icc_count {
ICC_SM8250_COUNT = 4,
};
+enum camss_notify_message {
+ CAMSS_MSG_BUF_DONE = 0,
+ CAMSS_MSG_RUP,
+ CAMSS_MSG_RUP_CLEAR,
+ CAMSS_MSG_MAX,
+};
+
struct camss_resources {
enum camss_version version;
const char *pd_name;
@@ -116,6 +123,8 @@ struct camss {
struct device_link *genpd_link;
struct icc_path *icc_path[ICC_SM8250_COUNT];
const struct camss_resources *res;
+ void (*notify)(struct v4l2_subdev *sd,
+ unsigned int notification, void *arg);
};
struct camss_camera_interface {
--
2.34.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 12/13] media: qcom: camss: Add sm8550 support
2024-07-09 16:06 [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (10 preceding siblings ...)
2024-07-09 16:06 ` [PATCH 11/13] media: qcom: camss: Add notify interface in camss driver Depeng Shao
@ 2024-07-09 16:06 ` Depeng Shao
2024-07-10 12:02 ` Bryan O'Donoghue
2024-07-09 16:06 ` [PATCH 13/13] media: qcom: camss: Add sm8550 resources Depeng Shao
` (2 subsequent siblings)
14 siblings, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-07-09 16:06 UTC (permalink / raw)
To: rfoss, todor.too, bryan.odonoghue, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, quic_depengs, linux-media, linux-arm-msm,
devicetree, linux-kernel, kernel
Add in functional logic throughout the code to support the SM8550.
Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
---
.../media/platform/qcom/camss/camss-csid.c | 21 +++++++++++++++++++
.../qcom/camss/camss-csiphy-3ph-1-0.c | 6 ++++++
drivers/media/platform/qcom/camss/camss-vfe.c | 6 ++++++
drivers/media/platform/qcom/camss/camss.h | 1 +
4 files changed, 34 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/camss-csid.c b/drivers/media/platform/qcom/camss/camss-csid.c
index 858db5d4ca75..90fba25db4c6 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.c
+++ b/drivers/media/platform/qcom/camss/camss-csid.c
@@ -1013,6 +1013,7 @@ int msm_csid_subdev_init(struct camss *camss, struct csid_device *csid,
{
struct device *dev = camss->dev;
struct platform_device *pdev = to_platform_device(dev);
+ struct resource *top_res;
int i, j;
int ret;
@@ -1040,6 +1041,26 @@ int msm_csid_subdev_init(struct camss *camss, struct csid_device *csid,
else
csid->base = csid->res->parent_dev_ops->get_base_address(camss, id)
+ VFE_480_CSID_OFFSET;
+ } else if (camss->res->version == CAMSS_8550) {
+ /* for titan 780, CSID lite registers are inside the VFE lite region,
+ * between the VFE "top" and "bus" registers. this requires
+ * VFE to be initialized before CSID
+ */
+ if (csid_is_lite(csid))
+ csid->base = csid->res->parent_dev_ops->get_base_address(camss, id);
+ else {
+ csid->base = devm_platform_ioremap_resource_byname(pdev, res->reg[0]);
+ /* CSID "top" is a new function in Titan780.
+ * CSID can connect to VFE & SFE(Sensor Front End).
+ * This connection is ontrolled by CSID "top" registers.
+ * CSID "top" registers at only one region.
+ */
+ top_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, res->reg[1]);
+ csid->top_base = ioremap(top_res->start, resource_size(top_res));
+ }
+
+ if (IS_ERR(csid->base))
+ return PTR_ERR(csid->base);
} else {
csid->base = devm_platform_ioremap_resource_byname(pdev, res->reg[0]);
if (IS_ERR(csid->base))
diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
index b6d5a27b94a6..53c46c2e5896 100644
--- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
+++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
@@ -631,6 +631,7 @@ static bool csiphy_is_gen2(u32 version)
case CAMSS_845:
case CAMSS_8250:
case CAMSS_8280XP:
+ case CAMSS_8550:
ret = true;
break;
}
@@ -718,6 +719,11 @@ static int csiphy_init(struct csiphy_device *csiphy)
regs->lane_regs = &lane_regs_sc8280xp[0];
regs->lane_array_size = ARRAY_SIZE(lane_regs_sc8280xp);
break;
+ case CAMSS_8550:
+ regs->lane_regs = &lane_regs_sm8550[0];
+ regs->lane_array_size = ARRAY_SIZE(lane_regs_sm8550);
+ regs->offset = 0x1000;
+ break;
default:
WARN(1, "unknown csiphy version\n");
return -ENODEV;
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
index 83c5a36d071f..479474c1cd95 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -338,6 +338,7 @@ static u32 vfe_src_pad_code(struct vfe_line *line, u32 sink_code,
case CAMSS_845:
case CAMSS_8250:
case CAMSS_8280XP:
+ case CAMSS_8550:
switch (sink_code) {
case MEDIA_BUS_FMT_YUYV8_1X16:
{
@@ -408,6 +409,10 @@ int vfe_reset(struct vfe_device *vfe)
reinit_completion(&vfe->reset_complete);
+ /* The reset has been moved to csid in 8550 */
+ if (vfe->camss->res->version == CAMSS_8550)
+ return 0;
+
vfe->res->hw_ops->global_reset(vfe);
time = wait_for_completion_timeout(&vfe->reset_complete,
@@ -1695,6 +1700,7 @@ static int vfe_bpl_align(struct vfe_device *vfe)
case CAMSS_845:
case CAMSS_8250:
case CAMSS_8280XP:
+ case CAMSS_8550:
ret = 16;
break;
default:
diff --git a/drivers/media/platform/qcom/camss/camss.h b/drivers/media/platform/qcom/camss/camss.h
index 65fcebd42c4b..feac83510a17 100644
--- a/drivers/media/platform/qcom/camss/camss.h
+++ b/drivers/media/platform/qcom/camss/camss.h
@@ -79,6 +79,7 @@ enum camss_version {
CAMSS_845,
CAMSS_8250,
CAMSS_8280XP,
+ CAMSS_8550,
};
enum icc_count {
--
2.34.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* [PATCH 13/13] media: qcom: camss: Add sm8550 resources
2024-07-09 16:06 [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (11 preceding siblings ...)
2024-07-09 16:06 ` [PATCH 12/13] media: qcom: camss: Add sm8550 support Depeng Shao
@ 2024-07-09 16:06 ` Depeng Shao
2024-07-10 11:08 ` [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Krzysztof Kozlowski
2024-08-24 17:05 ` Bryan O'Donoghue
14 siblings, 0 replies; 99+ messages in thread
From: Depeng Shao @ 2024-07-09 16:06 UTC (permalink / raw)
To: rfoss, todor.too, bryan.odonoghue, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, quic_depengs, linux-media, linux-arm-msm,
devicetree, linux-kernel, kernel, Yongsheng Li
Add sm8550 resources
- 3 x VFE, 3 RDI per VFE
- 2 x VFE Lite, 4 RDI per VFE
- 3 x CSID
- 2 x CSID Lite
- 8 x CSI PHY
Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
---
.../media/platform/qcom/camss/camss-csid.h | 1 +
drivers/media/platform/qcom/camss/camss-vfe.h | 1 +
drivers/media/platform/qcom/camss/camss.c | 415 ++++++++++++++++++
3 files changed, 417 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/camss-csid.h b/drivers/media/platform/qcom/camss/camss-csid.h
index 714a8db855fd..aaa51e47cf0c 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.h
+++ b/drivers/media/platform/qcom/camss/camss-csid.h
@@ -238,6 +238,7 @@ extern const struct csid_formats csid_formats_gen2;
extern const struct csid_hw_ops csid_ops_4_1;
extern const struct csid_hw_ops csid_ops_4_7;
extern const struct csid_hw_ops csid_ops_gen2;
+extern const struct csid_hw_ops csid_ops_gen3;
/*
* csid_is_lite - Check if CSID is CSID lite.
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.h b/drivers/media/platform/qcom/camss/camss-vfe.h
index a8b09ce9941b..6c2f394bbf55 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.h
+++ b/drivers/media/platform/qcom/camss/camss-vfe.h
@@ -239,6 +239,7 @@ extern const struct vfe_hw_ops vfe_ops_4_7;
extern const struct vfe_hw_ops vfe_ops_4_8;
extern const struct vfe_hw_ops vfe_ops_170;
extern const struct vfe_hw_ops vfe_ops_480;
+extern const struct vfe_hw_ops vfe_ops_780;
int vfe_get(struct vfe_device *vfe);
void vfe_put(struct vfe_device *vfe);
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index abeb0918e47d..730eecb05ef7 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -1480,6 +1480,406 @@ static const struct resources_icc icc_res_sc8280xp[] = {
},
};
+static const struct camss_subdev_resources csiphy_res_8550[] = {
+ /* CSIPHY0 */
+ {
+ .regulators = {},
+ .clock = {
+ "csiphy0",
+ "csiphy0_timer" },
+ .clock_rate = {
+ { 300000000, 400000000, 400000000, 400000000, 400000000 },
+ { 300000000, 400000000, 400000000, 400000000, 400000000 } },
+ .reg = { "csiphy0" },
+ .interrupt = { "csiphy0" },
+ .csiphy = {
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+ /* CSIPHY1 */
+ {
+ .regulators = {},
+ .clock = {
+ "csiphy1",
+ "csiphy1_timer" },
+ .clock_rate = {
+ { 300000000, 400000000, 400000000, 400000000, 400000000 },
+ { 300000000, 400000000, 400000000, 400000000, 400000000 } },
+ .reg = { "csiphy1" },
+ .interrupt = { "csiphy1" },
+ .csiphy = {
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+ /* CSIPHY2 */
+ {
+ .regulators = {},
+ .clock = {
+ "csiphy2",
+ "csiphy2_timer" },
+ .clock_rate = {
+ { 300000000, 400000000, 400000000, 400000000, 400000000 },
+ { 300000000, 400000000, 400000000, 400000000, 400000000 } },
+ .reg = { "csiphy2" },
+ .interrupt = { "csiphy2" },
+ .csiphy = {
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+ /* CSIPHY3 */
+ {
+ .regulators = {},
+ .clock = {
+ "csiphy3",
+ "csiphy3_timer" },
+ .clock_rate = {
+ { 300000000, 400000000, 400000000, 400000000, 400000000 },
+ { 300000000, 400000000, 400000000, 400000000, 400000000 } },
+ .reg = { "csiphy3" },
+ .interrupt = { "csiphy3" },
+ .csiphy = {
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+ /* CSIPHY4 */
+ {
+ .regulators = {},
+ .clock = {
+ "csiphy4",
+ "csiphy4_timer" },
+ .clock_rate = {
+ { 300000000, 400000000, 400000000, 400000000, 400000000 },
+ { 300000000, 400000000, 400000000, 400000000, 400000000 } },
+ .reg = { "csiphy4" },
+ .interrupt = { "csiphy4" },
+ .csiphy = {
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+ /* CSIPHY5 */
+ {
+ .regulators = {},
+ .clock = {
+ "csiphy5",
+ "csiphy5_timer" },
+ .clock_rate = {
+ { 300000000, 400000000, 400000000, 400000000, 400000000 },
+ { 300000000, 400000000, 400000000, 400000000, 400000000 } },
+ .reg = { "csiphy5" },
+ .interrupt = { "csiphy5" },
+ .csiphy = {
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+ /* CSIPHY6 */
+ {
+ .regulators = {},
+ .clock = {
+ "csiphy6",
+ "csiphy6_timer" },
+ .clock_rate = {
+ { 300000000, 400000000, 400000000, 400000000, 400000000 },
+ { 300000000, 400000000, 400000000, 400000000, 400000000 } },
+ .reg = { "csiphy6" },
+ .interrupt = { "csiphy6" },
+ .csiphy = {
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ },
+ /* CSIPHY7 */
+ {
+ .regulators = {},
+ .clock = {
+ "csiphy7",
+ "csiphy7_timer" },
+ .clock_rate = {
+ { 300000000, 400000000, 400000000, 400000000, 400000000 },
+ { 300000000, 400000000, 400000000, 400000000, 400000000 } },
+ .reg = { "csiphy7" },
+ .interrupt = { "csiphy7" },
+ .csiphy = {
+ .hw_ops = &csiphy_ops_3ph_1_0,
+ .formats = &csiphy_formats_sdm845
+ }
+ }
+};
+
+static const struct camss_subdev_resources csid_res_8550[] = {
+ /* CSID0 */
+ {
+ .regulators = { "vdda-phy", "vdda-pll" },
+ .clock = {
+ "csid",
+ "csiphy_rx" },
+ .clock_rate = {
+ { 400000000, 480000000, 480000000, 480000000, 480000000 },
+ { 400000000, 480000000, 480000000, 480000000, 480000000 } },
+ .reg = { "csid0", "csid_top" },
+ .interrupt = { "csid0" },
+ .csid = {
+ .is_lite = false,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen3,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID1 */
+ {
+ .regulators = { "vdda-phy", "vdda-pll" },
+ .clock = { "csid", "csiphy_rx" },
+ .clock_rate = {
+ { 400000000, 480000000, 480000000, 480000000, 480000000 },
+ { 400000000, 480000000, 480000000, 480000000, 480000000 } },
+ .reg = { "csid1", "csid_top" },
+ .interrupt = { "csid1" },
+ .csid = {
+ .is_lite = false,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen3,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID2 */
+ {
+ .regulators = { "vdda-phy", "vdda-pll" },
+ .clock = { "csid", "csiphy_rx" },
+ .clock_rate = {
+ { 400000000, 480000000, 480000000, 480000000, 480000000 },
+ { 400000000, 480000000, 480000000, 480000000, 480000000 } },
+ .reg = { "csid2", "csid_top" },
+ .interrupt = { "csid2" },
+ .csid = {
+ .is_lite = false,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen3,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID3 */
+ {
+ .regulators = { "vdda-phy", "vdda-pll" },
+ .clock = { "vfe_lite_csid",
+ "vfe_lite_cphy_rx" },
+ .clock_rate = {
+ { 400000000, 480000000, 480000000, 480000000, 480000000 },
+ { 400000000, 480000000, 480000000, 480000000, 480000000 } },
+ .reg = { "csid_lite0" },
+ .interrupt = { "csid_lite0" },
+ .csid = {
+ .is_lite = true,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen3,
+ .formats = &csid_formats_gen2
+ }
+ },
+ /* CSID4 */
+ {
+ .regulators = { "vdda-phy", "vdda-pll" },
+ .clock = { "vfe_lite_csid",
+ "vfe_lite_cphy_rx" },
+ .clock_rate = {
+ { 400000000, 480000000, 480000000, 480000000, 480000000 },
+ { 400000000, 480000000, 480000000, 480000000, 480000000 } },
+ .reg = { "csid_lite1" },
+ .interrupt = { "csid_lite1" },
+ .csid = {
+ .is_lite = true,
+ .parent_dev_ops = &vfe_parent_dev_ops,
+ .hw_ops = &csid_ops_gen3,
+ .formats = &csid_formats_gen2
+ }
+ }
+};
+
+static const struct camss_subdev_resources vfe_res_8550[] = {
+ /* VFE0 */
+ {
+ .regulators = {},
+ .clock = {
+ "cam_hf_axi",
+ "cpas_ahb",
+ "cpas_fast_ahb_clk",
+ "vfe0_fast_ahb",
+ "vfe0",
+ "cpas_vfe0",
+ "camnoc_axi"},
+ .clock_rate = {
+ { 0, 0, 0, 0, 0 },
+ { 0, 0, 0, 0, 80000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 },
+ { 466000000, 594000000, 675000000, 785000000, 785000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 }
+ },
+ .reg = { "vfe0" },
+ .interrupt = { "vfe0" },
+ .vfe = {
+ .line_num = 3,
+ .is_lite = false,
+ .has_pd = true,
+ .pd_name = "ife0",
+ .hw_ops = &vfe_ops_780,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE1 */
+ {
+ .regulators = {},
+ .clock = {
+ "cam_hf_axi",
+ "cpas_ahb",
+ "cpas_fast_ahb_clk",
+ "vfe1_fast_ahb",
+ "vfe1",
+ "cpas_vfe1",
+ "camnoc_axi"},
+ .clock_rate = {
+ { 0, 0, 0, 0, 0 },
+ { 0, 0, 0, 0, 80000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 },
+ { 466000000, 594000000, 675000000, 785000000, 785000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 }
+ },
+ .reg = { "vfe1" },
+ .interrupt = { "vfe1" },
+ .vfe = {
+ .line_num = 3,
+ .is_lite = false,
+ .has_pd = true,
+ .pd_name = "ife1",
+ .hw_ops = &vfe_ops_780,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE2 */
+ {
+ .regulators = {},
+ .clock = {
+ "cam_hf_axi",
+ "cpas_ahb",
+ "cpas_fast_ahb_clk",
+ "vfe2_fast_ahb",
+ "vfe2",
+ "cpas_vfe2",
+ "camnoc_axi"},
+ .clock_rate = {
+ { 0, 0, 0, 0, 0 },
+ { 0, 0, 0, 0, 80000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 },
+ { 466000000, 594000000, 675000000, 785000000, 785000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 }
+ },
+ .reg = { "vfe2" },
+ .interrupt = { "vfe2" },
+ .vfe = {
+ .line_num = 3,
+ .is_lite = false,
+ .has_pd = true,
+ .pd_name = "ife2",
+ .hw_ops = &vfe_ops_780,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE3 (lite) */
+ {
+ .regulators = {},
+ .clock = {
+ "cam_hf_axi",
+ "cpas_ahb",
+ "cpas_fast_ahb_clk",
+ "vfe_lite_ahb",
+ "vfe_lite",
+ "cpas_ife_lite",
+ "camnoc_axi"},
+ .clock_rate = {
+ { 0, 0, 0, 0, 0 },
+ { 0, 0, 0, 0, 80000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 },
+ { 400000000, 480000000, 480000000, 480000000, 480000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 }
+ },
+ .reg = { "vfe_lite0" },
+ .interrupt = { "vfe_lite0" },
+ .vfe = {
+ .line_num = 4,
+ .is_lite = true,
+ .hw_ops = &vfe_ops_780,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+ /* VFE4 (lite) */
+ {
+ .regulators = {},
+ .clock = {
+ "cam_hf_axi",
+ "cpas_ahb",
+ "cpas_fast_ahb_clk",
+ "vfe_lite_ahb",
+ "vfe_lite",
+ "cpas_ife_lite",
+ "camnoc_axi"},
+ .clock_rate = {
+ { 0, 0, 0, 0, 0 },
+ { 0, 0, 0, 0, 80000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 },
+ { 400000000, 480000000, 480000000, 480000000, 480000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 },
+ { 300000000, 300000000, 400000000, 400000000, 400000000 }
+ },
+ .reg = { "vfe_lite1" },
+ .interrupt = { "vfe_lite1" },
+ .vfe = {
+ .line_num = 4,
+ .is_lite = true,
+ .hw_ops = &vfe_ops_780,
+ .formats_rdi = &vfe_formats_rdi_845,
+ .formats_pix = &vfe_formats_pix_845
+ }
+ },
+};
+
+static const struct resources_icc icc_res_sm8550[] = {
+ {
+ .name = "cam_ahb",
+ .icc_bw_tbl.avg = 2097152,
+ .icc_bw_tbl.peak = 2097152,
+ },
+ {
+ .name = "cam_hf_0_mnoc",
+ .icc_bw_tbl.avg = 2097152,
+ .icc_bw_tbl.peak = 2097152,
+ },
+ {
+ .name = "cam_sf_0_mnoc",
+ .icc_bw_tbl.avg = 2097152,
+ .icc_bw_tbl.peak = 2097152,
+ },
+ {
+ .name = "cam_sf_icp_mnoc",
+ .icc_bw_tbl.avg = 2097152,
+ .icc_bw_tbl.peak = 2097152,
+ },
+};
+
/*
* camss_add_clock_margin - Add margin to clock frequency rate
* @rate: Clock frequency rate
@@ -2487,6 +2887,20 @@ static const struct camss_resources sc8280xp_resources = {
.link_entities = camss_link_entities
};
+static const struct camss_resources sm8550_resources = {
+ .version = CAMSS_8550,
+ .pd_name = "top",
+ .csiphy_res = csiphy_res_8550,
+ .csid_res = csid_res_8550,
+ .vfe_res = vfe_res_8550,
+ .icc_res = icc_res_sm8550,
+ .icc_path_num = ARRAY_SIZE(icc_res_sm8550),
+ .csiphy_num = ARRAY_SIZE(csiphy_res_8550),
+ .csid_num = ARRAY_SIZE(csid_res_8550),
+ .vfe_num = ARRAY_SIZE(vfe_res_8550),
+ .link_entities = camss_link_entities
+};
+
static const struct of_device_id camss_dt_match[] = {
{ .compatible = "qcom,msm8916-camss", .data = &msm8916_resources },
{ .compatible = "qcom,msm8996-camss", .data = &msm8996_resources },
@@ -2494,6 +2908,7 @@ static const struct of_device_id camss_dt_match[] = {
{ .compatible = "qcom,sdm845-camss", .data = &sdm845_resources },
{ .compatible = "qcom,sm8250-camss", .data = &sm8250_resources },
{ .compatible = "qcom,sc8280xp-camss", .data = &sc8280xp_resources },
+ { .compatible = "qcom,sm8550-camss", .data = &sm8550_resources },
{ }
};
--
2.34.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-07-09 16:06 ` [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding Depeng Shao
@ 2024-07-09 20:21 ` Rob Herring (Arm)
2024-07-10 9:37 ` Bryan O'Donoghue
` (2 subsequent siblings)
3 siblings, 0 replies; 99+ messages in thread
From: Rob Herring (Arm) @ 2024-07-09 20:21 UTC (permalink / raw)
To: Depeng Shao
Cc: rfoss, conor+dt, todor.too, bryan.odonoghue, mchehab,
Yongsheng Li, krzk+dt, linux-media, quic_eberman, devicetree,
linux-kernel, linux-arm-msm, kernel
On Tue, 09 Jul 2024 21:36:50 +0530, Depeng Shao wrote:
> Add bindings for qcom,sm8550-camss in order to support the camera
> subsystem for sm8550
>
> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> ---
> .../bindings/media/qcom,sm8550-camss.yaml | 545 ++++++++++++++++++
> 1 file changed, 545 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,sm8550-camss.example.dtb: camss@ace4000: clock-names:34: 'cpas_vfe2' was expected
from schema $id: http://devicetree.org/schemas/media/qcom,sm8550-camss.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,sm8550-camss.example.dtb: camss@ace4000: clock-names:38: 'cpas_vfe1' was expected
from schema $id: http://devicetree.org/schemas/media/qcom,sm8550-camss.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,sm8550-camss.example.dtb: camss@ace4000: clock-names:41: 'vfe_lite' was expected
from schema $id: http://devicetree.org/schemas/media/qcom,sm8550-camss.yaml#
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/media/qcom,sm8550-camss.example.dtb: camss@ace4000: clock-names:43: 'vfe_lite_csid' was expected
from schema $id: http://devicetree.org/schemas/media/qcom,sm8550-camss.yaml#
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20240709160656.31146-8-quic_depengs@quicinc.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-07-09 16:06 ` [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding Depeng Shao
2024-07-09 20:21 ` Rob Herring (Arm)
@ 2024-07-10 9:37 ` Bryan O'Donoghue
2024-07-10 10:59 ` Depeng Shao
2024-07-10 11:07 ` Krzysztof Kozlowski
2024-08-01 0:05 ` Vladimir Zapolskiy
3 siblings, 1 reply; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-07-10 9:37 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
On 09/07/2024 17:06, Depeng Shao wrote:
> Add bindings for qcom,sm8550-camss in order to support the camera
> subsystem for sm8550
>
> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> ---
Hey Depeng,
Thank you for your submission, looks good. I have a few comments below.
> + clock-names:
> + items:
> + - const: cam_ahb_clk
> + - const: cam_hf_axi
> + - const: cam_sf_axi
> + - const: camnoc_axi
> + - const: camnoc_axi_src
These "_src" clocks are almost certainly not necessary. The CAMCC should
have camnoc_axi_src as the parent clock of camnoc_axi, so you don't need
ot list the "_src" clock.
Please go through this list in your yaml, dts and .c code and remove.
There may be an exception where a _src clock is required but my
expectation is that all of those _src clocks can be removed.
> + power-domains:
> + items:
> + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
> + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller.
> + - description: IFE2 GDSC - Image Front End, Global Distributed Switch Controller.
> + - description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller.
Please name these power-domains in the next iteration of the series.
The dependency on the ordering of the power-domains is a bug which new
SoC submissions won't be replicating.
https://lore.kernel.org/linux-arm-msm/fcdb072d-6099-4423-b4b5-21e9052b82cc@linaro.org/
> +
> + interconnects =
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_CAMERA_CFG 0>,
> + <&mmss_noc MASTER_CAMNOC_HF 0 &mc_virt SLAVE_EBI1 0>,
> + <&mmss_noc MASTER_CAMNOC_SF 0 &mc_virt SLAVE_EBI1 0>,
> + <&mmss_noc MASTER_CAMNOC_ICP 0 &mc_virt SLAVE_EBI1 0>;
This tabbing looks weird, do none of the checking tools complain about it ?
See:
Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-07-10 9:37 ` Bryan O'Donoghue
@ 2024-07-10 10:59 ` Depeng Shao
0 siblings, 0 replies; 99+ messages in thread
From: Depeng Shao @ 2024-07-10 10:59 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
On 7/10/2024 5:37 PM, Bryan O'Donoghue wrote:
> On 09/07/2024 17:06, Depeng Shao wrote:
>> Add bindings for qcom,sm8550-camss in order to support the camera
>> subsystem for sm8550
>>
>> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
>> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
>> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
>> ---
>
> Hey Depeng,
>
> Thank you for your submission, looks good. I have a few comments below.
>
>> + clock-names:
>> + items:
>> + - const: cam_ahb_clk
>> + - const: cam_hf_axi
>> + - const: cam_sf_axi
>> + - const: camnoc_axi
>> + - const: camnoc_axi_src
>
> These "_src" clocks are almost certainly not necessary. The CAMCC should
> have camnoc_axi_src as the parent clock of camnoc_axi, so you don't need
> ot list the "_src" clock.
>
> Please go through this list in your yaml, dts and .c code and remove.
>
> There may be an exception where a _src clock is required but my
> expectation is that all of those _src clocks can be removed.
>
>
Hey Bryan,
Thanks for the reviewing. I will try to move all the _src clk and verify
again.
>> + power-domains:
>> + items:
>> + - description: IFE0 GDSC - Image Front End, Global Distributed
>> Switch Controller.
>> + - description: IFE1 GDSC - Image Front End, Global Distributed
>> Switch Controller.
>> + - description: IFE2 GDSC - Image Front End, Global Distributed
>> Switch Controller.
>> + - description: Titan GDSC - Titan ISP Block, Global Distributed
>> Switch Controller.
>
> Please name these power-domains in the next iteration of the series.
>
> The dependency on the ordering of the power-domains is a bug which new
> SoC submissions won't be replicating.
>
> https://lore.kernel.org/linux-arm-msm/fcdb072d-6099-4423-b4b5-21e9052b82cc@linaro.org/
>
Sure, will add this in new patch set.
power-domain-names = "ife0",
"ife1",
"ife2",
"top";
>> +
>> + interconnects =
>> + <&gem_noc MASTER_APPSS_PROC 0
>> &config_noc SLAVE_CAMERA_CFG 0>,
>> + <&mmss_noc MASTER_CAMNOC_HF 0
>> &mc_virt SLAVE_EBI1 0>,
>> + <&mmss_noc MASTER_CAMNOC_SF 0
>> &mc_virt SLAVE_EBI1 0>,
>> + <&mmss_noc MASTER_CAMNOC_ICP 0
>> &mc_virt SLAVE_EBI1 0>;
>
> This tabbing looks weird, do none of the checking tools complain about it ?
>
> See:
> Documentation/devicetree/bindings/media/qcom,sc8280xp-camss.yaml
>
Looks like no complain about this, but will update it.
> ---
> bod
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-07-09 16:06 ` [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding Depeng Shao
2024-07-09 20:21 ` Rob Herring (Arm)
2024-07-10 9:37 ` Bryan O'Donoghue
@ 2024-07-10 11:07 ` Krzysztof Kozlowski
2024-07-11 10:43 ` Depeng Shao
2024-08-01 0:05 ` Vladimir Zapolskiy
3 siblings, 1 reply; 99+ messages in thread
From: Krzysztof Kozlowski @ 2024-07-10 11:07 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
On 09/07/2024 18:06, Depeng Shao wrote:
> Add bindings for qcom,sm8550-camss in order to support the camera
> subsystem for sm8550
>
> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> ---
> .../bindings/media/qcom,sm8550-camss.yaml | 545 ++++++++++++++++++
> 1 file changed, 545 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml
> new file mode 100644
> index 000000000000..d002b0ff119e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml
> @@ -0,0 +1,545 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/qcom,sm8550-camss.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm SM8550 Camera Subsystem (CAMSS)
> +
> +maintainers:
> + - Depeng Shao <quic_depengs@quicinc.com>
> +
> +description: |
Do not need '|' unless you need to preserve formatting.
This wasn't tested so I am not going to perform full review.
Look at "Re: [PATCH 1/6] media: dt-bindings: media: camss: Add
qcom,sc7280-camss binding" - all comments apply.
...
> +
> +required:
> + - clock-names
> + - clocks
> + - compatible
Keep the same order as in "properties:'.
> + - interconnects
> + - interconnect-names
> + - interrupts
> + - interrupt-names
> + - iommus
> + - power-domains
> + - reg
> + - reg-names
> + - vdda-phy-supply
> + - vdda-pll-supply
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/qcom,sm8550-camcc.h>
> + #include <dt-bindings/clock/qcom,sm8550-gcc.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/power/qcom-rpmpd.h>
> + #include <dt-bindings/clock/qcom,rpmh.h>
> + #include <dt-bindings/interconnect/qcom,sm8550-rpmh.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + camss: camss@ace4000 {
> + compatible = "qcom,sm8550-camss";
> +
> + reg = <0 0x0ace4000 0 0x2000>,
> + <0 0x0ace6000 0 0x2000>,
> + <0 0x0ace8000 0 0x2000>,
> + <0 0x0acea000 0 0x2000>,
> + <0 0x0acec000 0 0x2000>,
> + <0 0x0acee000 0 0x2000>,
> + <0 0x0acf0000 0 0x2000>,
> + <0 0x0acf2000 0 0x2000>,
> + <0 0x0acb7000 0 0xd00>,
> + <0 0x0acb9000 0 0xd00>,
> + <0 0x0acbb000 0 0xd00>,
> + <0 0x0acca000 0 0xa00>,
> + <0 0x0acce000 0 0xa00>,
> + <0 0x0acb6000 0 0x1000>,
> + <0 0x0ac62000 0 0xf000>,
> + <0 0x0ac71000 0 0xf000>,
> + <0 0x0ac80000 0 0xf000>,
> + <0 0x0acca000 0 0x2800>,
> + <0 0x0acce000 0 0x2800>;
> + reg-names = "csiphy0",
> + "csiphy1",
> + "csiphy2",
> + "csiphy3",
These (and many others further) looks misaligned.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH V3 00/13] media: qcom: camss: Add sm8550 support
2024-07-09 16:06 [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (12 preceding siblings ...)
2024-07-09 16:06 ` [PATCH 13/13] media: qcom: camss: Add sm8550 resources Depeng Shao
@ 2024-07-10 11:08 ` Krzysztof Kozlowski
2024-07-10 11:27 ` Depeng Shao
2024-08-24 17:05 ` Bryan O'Donoghue
14 siblings, 1 reply; 99+ messages in thread
From: Krzysztof Kozlowski @ 2024-07-10 11:08 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
On 09/07/2024 18:06, Depeng Shao wrote:
> V3:
> - Rebased the change based on below change which will be merged firstly.
> "Move camss version related defs in to resources"
> Link: https://lore.kernel.org/all/20240522154659.510-1-quic_grosikop@quicinc.com/
> - Rebased the change based on Bryan's csiphy optimization change and add
> these changes into this series, so that the new csiphy-3ph driver don't
> need to add duplicate code. This has got Bryan's permission to add his
> patches into this series.
> - Refactor some changes based on the comments to move the random code to
> patches where they are used.
> - Remove the vfe780 irq function since it isn't doing the actual work.
> - Add dt-binding for sm8550 camss driver.
> Link to V2: https://lore.kernel.org/all/20240320141136.26827-1-quic_depengs@quicinc.com/
I asked for reference to upstream DTS - where can I find the DTS patches?
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 08/13] media: qcom: camss: csiphy-3ph: Add Gen2 v1.2 two-phase MIPI CSI-2 DPHY init
2024-07-09 16:06 ` [PATCH 08/13] media: qcom: camss: csiphy-3ph: Add Gen2 v1.2 two-phase MIPI CSI-2 DPHY init Depeng Shao
@ 2024-07-10 11:09 ` Krzysztof Kozlowski
2024-07-10 13:14 ` Depeng Shao
2024-07-10 11:13 ` Bryan O'Donoghue
1 sibling, 1 reply; 99+ messages in thread
From: Krzysztof Kozlowski @ 2024-07-10 11:09 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
On 09/07/2024 18:06, Depeng Shao wrote:
> Add a PHY configuration sequence for the SM8550 which uses a Qualcomm
> Gen 2 version 1.2 CSI-2 PHY.
>
> The PHY can be configured as two phase or three phase in C-PHY or D-PHY
> mode. This configuration supports two-phase D-PHY mode.
>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> ---
> .../qcom/camss/camss-csiphy-3ph-1-0.c | 105 ++++++++++++++++++
> 1 file changed, 105 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> index 1219a25ec55b..b6d5a27b94a6 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> @@ -324,6 +324,111 @@ csiphy_lane_regs lane_regs_sm8250[] = {
> {0x0884, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
> };
>
> +/* GEN2 1.2 2PH */
> +static const struct
> +csiphy_lane_regs lane_regs_sm8550[] = {
This should sparkle warnings.
There is no user of it. You must organize your patches in logical junks.
Adding piece of structure without users is not a logical chunk.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 08/13] media: qcom: camss: csiphy-3ph: Add Gen2 v1.2 two-phase MIPI CSI-2 DPHY init
2024-07-09 16:06 ` [PATCH 08/13] media: qcom: camss: csiphy-3ph: Add Gen2 v1.2 two-phase MIPI CSI-2 DPHY init Depeng Shao
2024-07-10 11:09 ` Krzysztof Kozlowski
@ 2024-07-10 11:13 ` Bryan O'Donoghue
2024-07-10 13:33 ` Depeng Shao
1 sibling, 1 reply; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-07-10 11:13 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
On 09/07/2024 17:06, Depeng Shao wrote:
>
> +/* GEN2 1.2 2PH */
> +static const struct
> +csiphy_lane_regs lane_regs_sm8550[] = {
> + {0x0E90, 0x0f, 0x00, CSIPHY_DEFAULT_PARAMS},
> + {0x0E98, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
Definitely not DPHY 1.2 init sequence.
Could you update to something like /* GEN2 2.x - two phase 5 Gbps DPHY
mode 4 lanes */
Since the PHY can be in DPHY or CPHY mode at different data-rates it
would be nice to call out the exact mode we are upstreaming here.
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550
2024-07-09 16:06 ` [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550 Depeng Shao
@ 2024-07-10 11:20 ` Krzysztof Kozlowski
2024-07-11 11:08 ` Depeng Shao
2024-07-10 11:28 ` Bryan O'Donoghue
1 sibling, 1 reply; 99+ messages in thread
From: Krzysztof Kozlowski @ 2024-07-10 11:20 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
On 09/07/2024 18:06, Depeng Shao wrote:
> The CSID in SM8550 is gen3, it has new register offset and new
> functionality. The buf done irq,register update and reset are
> moved to CSID gen3. And CSID gen3 has a new register block which
> is named as CSID top, it controls the output of CSID, since the
> CSID can connect to Sensor Front End (SFE) or original VFE, the
> register in top block is used to control the HW connection.
>
> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> ---
> drivers/media/platform/qcom/camss/Makefile | 1 +
> .../platform/qcom/camss/camss-csid-gen3.c | 445 ++++++++++++++++++
> .../platform/qcom/camss/camss-csid-gen3.h | 26 +
> .../media/platform/qcom/camss/camss-csid.h | 2 +
> 4 files changed, 474 insertions(+)
> create mode 100644 drivers/media/platform/qcom/camss/camss-csid-gen3.c
> create mode 100644 drivers/media/platform/qcom/camss/camss-csid-gen3.h
>
> diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
> index e636968a1126..c336e4c1a399 100644
> --- a/drivers/media/platform/qcom/camss/Makefile
> +++ b/drivers/media/platform/qcom/camss/Makefile
> @@ -7,6 +7,7 @@ qcom-camss-objs += \
> camss-csid-4-1.o \
> camss-csid-4-7.o \
> camss-csid-gen2.o \
> + camss-csid-gen3.o \
> camss-csiphy-2ph-1-0.o \
> camss-csiphy-3ph-1-0.o \
> camss-csiphy.o \
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
> new file mode 100644
> index 000000000000..17fd7c5499de
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
> @@ -0,0 +1,445 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * camss-csid-gen3.c
> + *
> + * Qualcomm MSM Camera Subsystem - CSID (CSI Decoder) Module
> + *
> + * Copyright (c) 2024 Qualcomm Technologies, Inc.
> + */
> +#include <linux/completion.h>
> +#include <linux/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +
> +#include "camss.h"
> +#include "camss-csid.h"
> +#include "camss-csid-gen3.h"
> +
> +
> +#define CSID_TOP_IO_PATH_CFG0(csid) (0x4 * (csid))
> +#define OUTPUT_IFE_EN 0x100
> +#define INTERNAL_CSID 1
> +
> +#define CSID_HW_VERSION 0x0
> +#define HW_VERSION_STEPPING 0
> +#define HW_VERSION_REVISION 16
> +#define HW_VERSION_GENERATION 28
> +
> +#define CSID_RST_CFG 0xC
> +#define RST_MODE 0
> +#define RST_LOCATION 4
> +
> +#define CSID_RST_CMD 0x10
> +#define SELECT_HW_RST 0
> +#define SELECT_SW_RST 1
> +#define SELECT_IRQ_RST 2
> +
> +#define CSID_CSI2_RX_IRQ_STATUS 0x9C
> +#define CSID_CSI2_RX_IRQ_MASK 0xA0
> +#define CSID_CSI2_RX_IRQ_CLEAR 0xA4
> +#define CSID_CSI2_RX_IRQ_SET 0xA8
> +
> +#define CSID_CSI2_RDIN_IRQ_STATUS(rdi) (0xEC + 0x10 * (rdi))
> +#define CSID_CSI2_RDIN_IRQ_MASK(rdi) (0xF0 + 0x10 * (rdi))
> +#define CSID_CSI2_RDIN_INFO_FIFO_FULL 2
That's a random set of indentations.
> +#define CSID_CSI2_RDIN_INFO_CAMIF_EOF 3
> +#define CSID_CSI2_RDIN_INFO_CAMIF_SOF 4
> +#define CSID_CSI2_RDIN_INFO_INPUT_EOF 9
> +#define CSID_CSI2_RDIN_INFO_INPUT_SOF 12
...
> +
> + writel_relaxed(val, csid->base + CSID_RDI_CFG0(vc));
> +
> + val = 1 << RDI_CFG1_PACKING_FORMAT;
> + val |= 1 << RDI_CFG1_PIX_STORE;
> + val |= 1 << RDI_CFG1_DROP_H_EN;
> + val |= 1 << RDI_CFG1_DROP_V_EN;
> + val |= 1 << RDI_CFG1_CROP_H_EN;
> + val |= 1 << RDI_CFG1_CROP_V_EN;
> + val |= RDI_CFG1_EARLY_EOF_EN;
> +
> + writel_relaxed(val, csid->base + CSID_RDI_CFG1(vc));
> +
> + val = 0;
> + writel_relaxed(val, csid->base + CSID_RDI_IRQ_SUBSAMPLE_PERIOD(vc));
> +
> + val = 1;
> + writel_relaxed(val, csid->base + CSID_RDI_IRQ_SUBSAMPLE_PATTERN(vc));
> +
> + val = 0;
> + writel_relaxed(val, csid->base + CSID_RDI_CTRL(vc));
> +
> + val = readl_relaxed(csid->base + CSID_RDI_CFG0(vc));
> + val |= enable << RDI_CFG0_EN;
> + writel_relaxed(val, csid->base + CSID_RDI_CFG0(vc));
> +}
> +
such patterns and...
> + */
> +static int csid_reset(struct csid_device *csid)
> +{
> + unsigned long time;
> + u32 val;
> + int i;
> +
> + reinit_completion(&csid->reset_complete);
> +
> + writel_relaxed(1, csid->base + CSID_TOP_IRQ_CLEAR);
> + writel_relaxed(1, csid->base + CSID_IRQ_CMD);
> + writel_relaxed(1, csid->base + CSID_TOP_IRQ_MASK);
> +
> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS; i++)
> + if (csid->phy.en_vc & BIT(i)) {
> + writel_relaxed(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
> + csid->base + CSID_BUF_DONE_IRQ_CLEAR);
> + writel_relaxed(0x1 << IRQ_CMD_CLEAR, csid->base + CSID_IRQ_CMD);
> + writel_relaxed(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
> + csid->base + CSID_BUF_DONE_IRQ_MASK);
> + }
> +
> + /* preserve registers */
> + val = (0x1 << RST_LOCATION) | (0x1 << RST_MODE);
> + writel_relaxed(val, csid->base + CSID_RST_CFG);
... here - using everywhere relaxed here is odd and looks racy. These
looks like some strict sequences.
> +
> + val = (0x1 << SELECT_HW_RST) | (0x1 << SELECT_IRQ_RST);
> + writel_relaxed(val, csid->base + CSID_RST_CMD);
> +
> + time = wait_for_completion_timeout(&csid->reset_complete,
> + msecs_to_jiffies(CSID_RESET_TIMEOUT_MS));
> + if (!time) {
> + dev_err(csid->camss->dev, "CSID reset timeout\n");
> + return -EIO;
> + }
> +
> +
> +static void csid_subdev_init(struct csid_device *csid)
> +{
> + csid->testgen.modes = csid_testgen_modes;
> + csid->testgen.nmodes = CSID_PAYLOAD_MODE_NUM_SUPPORTED_GEN2;
> +}
> +
> +const struct csid_hw_ops csid_ops_gen3 = {
Isn't there a warning here?
> + .configure_stream = csid_configure_stream,
> + .configure_testgen_pattern = csid_configure_testgen_pattern,
> + .hw_version = csid_hw_version,
> + .isr = csid_isr,
> + .reset = csid_reset,
> + .src_pad_code = csid_src_pad_code,
> + .subdev_init = csid_subdev_init,
> +};
Your patchset does not apply at all. Tried v6.9, v6.10, next. I see some
dependency above, but that means no one can test it and no one can apply it.
Fix the warnings, I cannot verify it but I am sure you have them.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 10/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-07-09 16:06 ` [PATCH 10/13] media: qcom: camss: Add support for VFE hardware version Titan 780 Depeng Shao
@ 2024-07-10 11:22 ` Krzysztof Kozlowski
2024-07-10 11:47 ` Bryan O'Donoghue
1 sibling, 0 replies; 99+ messages in thread
From: Krzysztof Kozlowski @ 2024-07-10 11:22 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
On 09/07/2024 18:06, Depeng Shao wrote:
> Add support for VFE found on SM8550 (Titan 780). This implementation is
> based on the titan 480 implementation. It supports the normal and lite
> VFE.
>
> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> ---
...
> +
> +static const struct camss_video_ops vfe_video_ops_780 = {
> + .queue_buffer = vfe_queue_buffer,
> + .flush_buffers = vfe_flush_buffers,
> +};
> +
> +static void vfe_subdev_init(struct device *dev, struct vfe_device *vfe)
> +{
> + vfe->video_ops = vfe_video_ops_780;
> +}
> +
> +const struct vfe_hw_ops vfe_ops_780 = {
I guess another warning...
> + .global_reset = NULL,
> + .hw_version = vfe_hw_version,
> + .isr = vfe_isr,
> + .pm_domain_off = vfe_pm_domain_off,
> + .pm_domain_on = vfe_pm_domain_on,
> + .subdev_init = vfe_subdev_init,
> + .vfe_disable = vfe_disable,
> + .vfe_enable = vfe_enable,
> + .vfe_halt = vfe_halt,
> + .vfe_wm_stop = vfe_wm_stop,
> +};
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH V3 00/13] media: qcom: camss: Add sm8550 support
2024-07-10 11:08 ` [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Krzysztof Kozlowski
@ 2024-07-10 11:27 ` Depeng Shao
2024-07-10 12:30 ` Krzysztof Kozlowski
0 siblings, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-07-10 11:27 UTC (permalink / raw)
To: Krzysztof Kozlowski, rfoss, todor.too, bryan.odonoghue, mchehab,
robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
On 7/10/2024 7:08 PM, Krzysztof Kozlowski wrote:
> On 09/07/2024 18:06, Depeng Shao wrote:
>> V3:
>> - Rebased the change based on below change which will be merged firstly.
>> "Move camss version related defs in to resources"
>> Link: https://lore.kernel.org/all/20240522154659.510-1-quic_grosikop@quicinc.com/
>> - Rebased the change based on Bryan's csiphy optimization change and add
>> these changes into this series, so that the new csiphy-3ph driver don't
>> need to add duplicate code. This has got Bryan's permission to add his
>> patches into this series.
>> - Refactor some changes based on the comments to move the random code to
>> patches where they are used.
>> - Remove the vfe780 irq function since it isn't doing the actual work.
>> - Add dt-binding for sm8550 camss driver.
>> Link to V2: https://lore.kernel.org/all/20240320141136.26827-1-quic_depengs@quicinc.com/
>
> I asked for reference to upstream DTS - where can I find the DTS patches?
>
> Best regards,
> Krzysztof
>
Hi Krzysztof,
Sorry for that, I thought add the dt-binding is also fine, since I saw
other patches also do like this. Will add add the DTS in next patch set.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550
2024-07-09 16:06 ` [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550 Depeng Shao
2024-07-10 11:20 ` Krzysztof Kozlowski
@ 2024-07-10 11:28 ` Bryan O'Donoghue
2024-07-11 15:33 ` Depeng Shao
1 sibling, 1 reply; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-07-10 11:28 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
On 09/07/2024 17:06, Depeng Shao wrote:
> The CSID in SM8550 is gen3, it has new register offset and new
> functionality. The buf done irq,register update and reset are
> moved to CSID gen3. And CSID gen3 has a new register block which
> is named as CSID top, it controls the output of CSID, since the
> CSID can connect to Sensor Front End (SFE) or original VFE, the
> register in top block is used to control the HW connection.
>
> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> ---
> drivers/media/platform/qcom/camss/Makefile | 1 +
> .../platform/qcom/camss/camss-csid-gen3.c | 445 ++++++++++++++++++
> .../platform/qcom/camss/camss-csid-gen3.h | 26 +
> .../media/platform/qcom/camss/camss-csid.h | 2 +
> 4 files changed, 474 insertions(+)
> create mode 100644 drivers/media/platform/qcom/camss/camss-csid-gen3.c
> create mode 100644 drivers/media/platform/qcom/camss/camss-csid-gen3.h
>
> diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
> index e636968a1126..c336e4c1a399 100644
> --- a/drivers/media/platform/qcom/camss/Makefile
> +++ b/drivers/media/platform/qcom/camss/Makefile
> @@ -7,6 +7,7 @@ qcom-camss-objs += \
> camss-csid-4-1.o \
> camss-csid-4-7.o \
> camss-csid-gen2.o \
> + camss-csid-gen3.o \
> camss-csiphy-2ph-1-0.o \
> camss-csiphy-3ph-1-0.o \
> camss-csiphy.o \
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
> new file mode 100644
> index 000000000000..17fd7c5499de
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
> @@ -0,0 +1,445 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * camss-csid-gen3.c
> + *
> + * Qualcomm MSM Camera Subsystem - CSID (CSI Decoder) Module
> + *
> + * Copyright (c) 2024 Qualcomm Technologies, Inc.
> + */
> +#include <linux/completion.h>
> +#include <linux/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +
> +#include "camss.h"
> +#include "camss-csid.h"
> +#include "camss-csid-gen3.h"
> +
> +
> +#define CSID_TOP_IO_PATH_CFG0(csid) (0x4 * (csid))
> +#define OUTPUT_IFE_EN 0x100
> +#define INTERNAL_CSID 1
> +
> +#define CSID_HW_VERSION 0x0
> +#define HW_VERSION_STEPPING 0
> +#define HW_VERSION_REVISION 16
> +#define HW_VERSION_GENERATION 28
> +
> +#define CSID_RST_CFG 0xC
> +#define RST_MODE 0
> +#define RST_LOCATION 4
> +
> +#define CSID_RST_CMD 0x10
> +#define SELECT_HW_RST 0
> +#define SELECT_SW_RST 1
> +#define SELECT_IRQ_RST 2
> +
> +#define CSID_CSI2_RX_IRQ_STATUS 0x9C
> +#define CSID_CSI2_RX_IRQ_MASK 0xA0
> +#define CSID_CSI2_RX_IRQ_CLEAR 0xA4
> +#define CSID_CSI2_RX_IRQ_SET 0xA8
> +
> +#define CSID_CSI2_RDIN_IRQ_STATUS(rdi) (0xEC + 0x10 * (rdi))
> +#define CSID_CSI2_RDIN_IRQ_MASK(rdi) (0xF0 + 0x10 * (rdi))
> +#define CSID_CSI2_RDIN_INFO_FIFO_FULL 2
> +#define CSID_CSI2_RDIN_INFO_CAMIF_EOF 3
> +#define CSID_CSI2_RDIN_INFO_CAMIF_SOF 4
> +#define CSID_CSI2_RDIN_INFO_INPUT_EOF 9
> +#define CSID_CSI2_RDIN_INFO_INPUT_SOF 12
> +#define CSID_CSI2_RDIN_ERROR_REC_FRAME_DROP 18
> +#define CSID_CSI2_RDIN_ERROR_REC_OVERFLOW_IRQ 19
> +#define CSID_CSI2_RDIN_ERROR_REC_CCIF_VIOLATION 20
> +#define CSID_CSI2_RDIN_EPOCH0 21
> +#define CSID_CSI2_RDIN_EPOCH1 22
> +#define CSID_CSI2_RDIN_RUP_DONE 23
> +#define CSID_CSI2_RDIN_CCIF_VIOLATION 29
> +
> +#define CSID_CSI2_RDIN_IRQ_CLEAR(rdi) (0xF4 + 0x10 * (rdi))
> +#define CSID_CSI2_RDIN_IRQ_SET(rdi) (0xF8 + 0x10 * (rdi))
> +
> +#define CSID_TOP_IRQ_STATUS 0x7C
> +#define TOP_IRQ_STATUS_RESET_DONE 0
> +#define CSID_TOP_IRQ_MASK 0x80
> +#define CSID_TOP_IRQ_CLEAR 0x84
> +#define CSID_TOP_IRQ_SET 0x88
> +#define CSID_IRQ_CMD 0x14
> +#define IRQ_CMD_CLEAR 0
> +#define IRQ_CMD_SET 4
> +
> +#define CSID_BUF_DONE_IRQ_STATUS 0x8C
> +#define BUF_DONE_IRQ_STATUS_RDI_OFFSET (csid_is_lite(csid) ? 0x1 : 0xE)
> +#define CSID_BUF_DONE_IRQ_MASK 0x90
> +#define CSID_BUF_DONE_IRQ_CLEAR 0x94
> +#define CSID_BUF_DONE_IRQ_SET 0x98
> +
> +#define CSID_CSI2_RX_CFG0 0x200
> +#define CSI2_RX_CFG0_NUM_ACTIVE_LANES 0
> +#define CSI2_RX_CFG0_DL0_INPUT_SEL 4
> +#define CSI2_RX_CFG0_DL1_INPUT_SEL 8
> +#define CSI2_RX_CFG0_DL2_INPUT_SEL 12
> +#define CSI2_RX_CFG0_DL3_INPUT_SEL 16
> +#define CSI2_RX_CFG0_PHY_NUM_SEL 20
> +#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
> +#define CSI2_RX_CFG0_PHY_TYPE_SEL 24
> +#define CSI2_RX_CFG0_TPG_MUX_EN 27
> +#define CSI2_RX_CFG0_TPG_NUM_SEL 28
> +
> +#define CSID_CSI2_RX_CFG1 0x204
> +#define CSI2_RX_CFG1_PACKET_ECC_CORRECTION_EN 0
> +#define CSI2_RX_CFG1_DE_SCRAMBLE_EN 1
> +#define CSI2_RX_CFG1_VC_MODE 2
> +#define CSI2_RX_CFG1_COMPLETE_STREAM_EN 4
> +#define CSI2_RX_CFG1_COMPLETE_STREAM_FRAME_TIMING 5
> +#define CSI2_RX_CFG1_MISR_EN 6
> +#define CSI2_RX_CFG1_PHY_BIST_EN 7
> +#define CSI2_RX_CFG1_EPD_MODE 8
> +#define CSI2_RX_CFG1_EOTP_EN 9
> +#define CSI2_RX_CFG1_DYN_SWITCH_EN 10
> +#define CSI2_RX_CFG1_RUP_AUP_LATCH_DIS 11
> +
> +#define CSID_CSI2_RX_CAPTURE_CTRL 0x208
> +#define CSI2_RX_CAPTURE_CTRL_LONG_PKT_CAPTURE_EN 0
> +#define CSI2_RX_CAPTURE_CTRL_SHORT_PKT_CAPTURE_EN 1
> +#define CSI2_RX_CAPTURE_CTRL_CPHY_PKT_CAPTURE_EN 3
> +#define CSI2_RX_CAPTURE_CTRL_LONG_PKT_CAPTURE_DT 4
> +#define CSI2_RX_CAPTURE_CTRL_LONG_PKT_CAPTURE_VC 10
> +#define CSI2_RX_CAPTURE_CTRL_SHORT_PKT_CAPTURE_VC 15
> +#define CSI2_RX_CAPTURE_CTRL_CPHY_PKT_CAPTURE_DT 20
> +#define CSI2_RX_CAPTURE_CTRL_CPHY_PKT_CAPTURE_VC 26
> +
> +#define CSID_RDI_CFG0(rdi) (0x500 + 0x100 * (rdi))
> +#define RDI_CFG0_VFR_EN 0
> +#define RDI_CFG0_FRAME_ID_DEC_EN 1
> +#define RDI_CFG0_RETIME_DIS 5
> +#define RDI_CFG0_TIMESTAMP_EN 6
> +#define RDI_CFG0_TIMESTAMP_STB_SEL 8
> +#define RDI_CFG0_DECODE_FORMAT 12
> +#define RDI_CFG0_DT 16
> +#define RDI_CFG0_VC 22
> +#define RDI_CFG0_DT_ID 27
> +#define RDI_CFG0_EN 31
> +
> +#define CSID_RDI_CFG1(rdi) (0x510 + 0x100 * (rdi))
> +#define RDI_CFG1_BYTE_CNTR_EN 2
> +#define RDI_CFG1_DROP_H_EN 5
> +#define RDI_CFG1_DROP_V_EN 6
> +#define RDI_CFG1_CROP_H_EN 7
> +#define RDI_CFG1_CROP_V_EN 8
> +#define RDI_CFG1_MISR_EN 9
> +#define RDI_CFG1_PIX_STORE 10
> +#define RDI_CFG1_PLAIN_ALIGNMENT 11
> +#define RDI_CFG1_PLAIN_FORMAT 12
> +#define RDI_CFG1_EARLY_EOF_EN 14
> +#define RDI_CFG1_PACKING_FORMAT 15
> +
> +#define CSID_RDI_CTRL(rdi) (0x504 + 0x100 * (rdi))
> +#define RDI_CTRL_START_CMD 0
> +#define RDI_CTRL_START_MODE 2
> +
> +#define CSID_RDI_EPOCH_IRQ_CFG(rdi) (0x52C + 0x100 * (rdi))
> +
> +#define CSID_RDI_FRM_DROP_PATTERN(rdi) (0x540 + 0x100 * (rdi))
> +#define CSID_RDI_FRM_DROP_PERIOD(rdi) (0x544 + 0x100 * (rdi))
> +#define CSID_RDI_IRQ_SUBSAMPLE_PATTERN(rdi) (0x548 + 0x100 * (rdi))
> +#define CSID_RDI_IRQ_SUBSAMPLE_PERIOD(rdi) (0x54C + 0x100 * (rdi))
> +#define CSID_RDI_RPP_PIX_DROP_PATTERN(rdi) (0x558 + 0x100 * (rdi))
> +#define CSID_RDI_RPP_PIX_DROP_PERIOD(rdi) (0x55C + 0x100 * (rdi))
> +#define CSID_RDI_RPP_LINE_DROP_PATTERN(rdi) (0x560 + 0x100 * (rdi))
> +#define CSID_RDI_RPP_LINE_DROP_PERIOD(rdi) (0x564 + 0x100 * (rdi))
> +
> +#define CSID_RDI_RPP_HCROP(rdi) (0x550 + 0x100 * (rdi))
> +#define CSID_RDI_RPP_VCROP(rdi) (0x554 + 0x100 * (rdi))
> +
> +#define CSID_RDI_ERROR_RECOVERY_CFG0(rdi) (0x514 + 0x100 * (rdi))
> +
> +#define CSID_REG_UPDATE_CMD 0x18
> +static inline int reg_update_rdi(struct csid_device *csid, int n)
> +{
> + return BIT(n + 4) + BIT(20 + n);
> +}
> +
> +#define REG_UPDATE_RDI reg_update_rdi
> +
> +static void __csid_configure_rx(struct csid_device *csid,
> + struct csid_phy_config *phy, int vc)
> +{
> + int val;
> +
> + val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
> + val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
> + val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX) << CSI2_RX_CFG0_PHY_NUM_SEL;
> +
> + writel_relaxed(val, csid->base + CSID_CSI2_RX_CFG0);
> +
> + val = 1 << CSI2_RX_CFG1_PACKET_ECC_CORRECTION_EN;
> + if (vc > 3)
> + val |= 1 << CSI2_RX_CFG1_VC_MODE;
I realise downstream does these shifts but, I think in upstream we
should just define a BIT(x)
#define CSI2_RX_CFG1_VC_MODE BIT(2)
val |= CSI2_RX_CFG1_VC_MODE;
> + writel_relaxed(val, csid->base + CSID_CSI2_RX_CFG1);
> +}
> +
> +static void __csid_ctrl_rdi(struct csid_device *csid, int enable, u8 rdi)
> +{
> + int val;
> +
> + if (enable)
> + val = 1 << RDI_CTRL_START_CMD;
> + else
> + val = 0 << RDI_CTRL_START_CMD;
Here is an example of how the bit shifting is weird
(0 << anything) is still zero
> + writel_relaxed(val, csid->base + CSID_RDI_CTRL(rdi));
> +}
> +
> +static void __csid_configure_top(struct csid_device *csid)
> +{
> + u32 val;
> +
> + /* CSID "top" is a new function in Titan780.
> + * CSID can connect to VFE & SFE(Sensor Front End).
> + * This connection is ontrolled by CSID "top".
> + * Only enable VFE path in current driver.
> + */
> + if (csid->top_base) {
When is csid->top_base NULL ?
Its required in your yaml.
> + val = OUTPUT_IFE_EN | INTERNAL_CSID;
> + writel_relaxed(val, csid->top_base + CSID_TOP_IO_PATH_CFG0(csid->id));
> + }
> +}
> +
> +static void __csid_configure_rdi_stream(struct csid_device *csid, u8 enable, u8 vc)
> +{
> + u32 val;
> + u8 lane_cnt = csid->phy.lane_cnt;
> + /* Source pads matching RDI channels on hardware. Pad 1 -> RDI0, Pad 2 -> RDI1, etc. */
> + struct v4l2_mbus_framefmt *input_format = &csid->fmt[MSM_CSID_PAD_FIRST_SRC + vc];
> + const struct csid_format_info *format = csid_get_fmt_entry(csid->res->formats->formats,
> + csid->res->formats->nformats,
> + input_format->code);
> +
> + if (!lane_cnt)
> + lane_cnt = 4;
> +
> + /*
> + * DT_ID is a two bit bitfield that is concatenated with
> + * the four least significant bits of the five bit VC
> + * bitfield to generate an internal CID value.
> + *
> + * CSID_RDI_CFG0(vc)
> + * DT_ID : 28:27
> + * VC : 26:22
> + * DT : 21:16
> + *
> + * CID : VC 3:0 << 2 | DT_ID 1:0
> + */
> + u8 dt_id = vc & 0x03;
> +
> + val = 1 << RDI_CFG0_TIMESTAMP_EN;
> + val |= 2 << RDI_CFG0_TIMESTAMP_STB_SEL;
> + /* note: for non-RDI path, this should be format->decode_format */
> + val |= DECODE_FORMAT_PAYLOAD_ONLY << RDI_CFG0_DECODE_FORMAT;
> + val |= vc << RDI_CFG0_VC;
> + val |= format->data_type << RDI_CFG0_DT;
> + val |= dt_id << RDI_CFG0_DT_ID;
> +
> + writel_relaxed(val, csid->base + CSID_RDI_CFG0(vc));
> +
> + val = 1 << RDI_CFG1_PACKING_FORMAT;
> + val |= 1 << RDI_CFG1_PIX_STORE;
> + val |= 1 << RDI_CFG1_DROP_H_EN;
> + val |= 1 << RDI_CFG1_DROP_V_EN;
> + val |= 1 << RDI_CFG1_CROP_H_EN;
> + val |= 1 << RDI_CFG1_CROP_V_EN;
> + val |= RDI_CFG1_EARLY_EOF_EN;
> +
> + writel_relaxed(val, csid->base + CSID_RDI_CFG1(vc));
> +
> + val = 0;
> + writel_relaxed(val, csid->base + CSID_RDI_IRQ_SUBSAMPLE_PERIOD(vc));
> +
> + val = 1;
> + writel_relaxed(val, csid->base + CSID_RDI_IRQ_SUBSAMPLE_PATTERN(vc));
> +
> + val = 0;
> + writel_relaxed(val, csid->base + CSID_RDI_CTRL(vc));
> +
> + val = readl_relaxed(csid->base + CSID_RDI_CFG0(vc));
> + val |= enable << RDI_CFG0_EN;
> + writel_relaxed(val, csid->base + CSID_RDI_CFG0(vc));
> +}
> +
> +static void csid_configure_stream(struct csid_device *csid, u8 enable)
> +{
> + u8 i;
> +
> + /* Loop through all enabled VCs and configure stream for each */
> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS; i++)
> + if (csid->phy.en_vc & BIT(i)) {
> + /* Configure CSID "top" */
> + __csid_configure_top(csid);
> + __csid_configure_rdi_stream(csid, enable, i);
> + __csid_configure_rx(csid, &csid->phy, i);
> + __csid_ctrl_rdi(csid, enable, i);
> + }
> +}
I really like this breakdown
> +
> +static int csid_configure_testgen_pattern(struct csid_device *csid, s32 val)
> +{
> + if (val > 0 && val <= csid->testgen.nmodes)
> + csid->testgen.mode = val;
Surely you should just set the val parameter directly ?
Also why is this a signed integer and how does it get assigned a
negative value which we need to mitigate against here ?
> +
> + return 0;
> +}
> +
> +/*
> + * csid_hw_version - CSID hardware version query
> + * @csid: CSID device
> + *
> + * Return HW version or error
> + */
> +static u32 csid_hw_version(struct csid_device *csid)
> +{
> + u32 hw_version;
> + u32 hw_gen;
> + u32 hw_rev;
> + u32 hw_step;
> +
> + hw_version = readl_relaxed(csid->base + CSID_HW_VERSION);
> + hw_gen = (hw_version >> HW_VERSION_GENERATION) & 0xF;
> + hw_rev = (hw_version >> HW_VERSION_REVISION) & 0xFFF;
> + hw_step = (hw_version >> HW_VERSION_STEPPING) & 0xFFFF;
> + dev_info(csid->camss->dev, "CSID HW Version = %u.%u.%u\n",
> + hw_gen, hw_rev, hw_step);
> +
> + return hw_version;
> +}
> +
> +/*
> + * csid_isr - CSID module interrupt service routine
> + * @irq: Interrupt line
> + * @dev: CSID device
> + *
> + * Return IRQ_HANDLED on success
> + */
> +static irqreturn_t csid_isr(int irq, void *dev)
> +{
> + struct csid_device *csid = dev;
> + u32 val, buf_done_val;
> + u8 reset_done;
> + int i;
> +
> + val = readl_relaxed(csid->base + CSID_TOP_IRQ_STATUS);
> + writel_relaxed(val, csid->base + CSID_TOP_IRQ_CLEAR);
> + reset_done = val & BIT(TOP_IRQ_STATUS_RESET_DONE);
> +
> + val = readl_relaxed(csid->base + CSID_CSI2_RX_IRQ_STATUS);
> + writel_relaxed(val, csid->base + CSID_CSI2_RX_IRQ_CLEAR);
> +
> + buf_done_val = readl_relaxed(csid->base + CSID_BUF_DONE_IRQ_STATUS);
> + writel_relaxed(buf_done_val, csid->base + CSID_BUF_DONE_IRQ_CLEAR);
> +
> + /* Read and clear IRQ status for each enabled RDI channel */
> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS; i++)
> + if (csid->phy.en_vc & BIT(i)) {
> + val = readl_relaxed(csid->base + CSID_CSI2_RDIN_IRQ_STATUS(i));
> + writel_relaxed(val, csid->base + CSID_CSI2_RDIN_IRQ_CLEAR(i));
> + }
> +
> + val = 1 << IRQ_CMD_CLEAR;
> + writel_relaxed(val, csid->base + CSID_IRQ_CMD);
> +
> + if (reset_done)
> + complete(&csid->reset_complete);
> +
> + return IRQ_HANDLED;
> +}
> +
> +/*
> + * csid_reset - Trigger reset on CSID module and wait to complete
> + * @csid: CSID device
> + *
> + * Return 0 on success or a negative error code otherwise
> + */
> +static int csid_reset(struct csid_device *csid)
> +{
> + unsigned long time;
> + u32 val;
> + int i;
> +
> + reinit_completion(&csid->reset_complete);
> +
> + writel_relaxed(1, csid->base + CSID_TOP_IRQ_CLEAR);
> + writel_relaxed(1, csid->base + CSID_IRQ_CMD);
> + writel_relaxed(1, csid->base + CSID_TOP_IRQ_MASK);
> +
> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS; i++)
> + if (csid->phy.en_vc & BIT(i)) {
> + writel_relaxed(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
> + csid->base + CSID_BUF_DONE_IRQ_CLEAR);
> + writel_relaxed(0x1 << IRQ_CMD_CLEAR, csid->base + CSID_IRQ_CMD);
> + writel_relaxed(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
> + csid->base + CSID_BUF_DONE_IRQ_MASK);
> + }
> +
> + /* preserve registers */
> + val = (0x1 << RST_LOCATION) | (0x1 << RST_MODE);
> + writel_relaxed(val, csid->base + CSID_RST_CFG);
> +
> + val = (0x1 << SELECT_HW_RST) | (0x1 << SELECT_IRQ_RST);
> + writel_relaxed(val, csid->base + CSID_RST_CMD);
> +
> + time = wait_for_completion_timeout(&csid->reset_complete,
> + msecs_to_jiffies(CSID_RESET_TIMEOUT_MS));
> + if (!time) {
> + dev_err(csid->camss->dev, "CSID reset timeout\n");
> + return -EIO;
> + }
> +
> + return 0;
> +}
> +
> +static u32 csid_src_pad_code(struct csid_device *csid, u32 sink_code,
> + unsigned int match_format_idx, u32 match_code)
> +{
> + switch (sink_code) {
> + case MEDIA_BUS_FMT_SBGGR10_1X10:
> + {
> + u32 src_code[] = {
> + MEDIA_BUS_FMT_SBGGR10_1X10,
> + MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_LE,
> + };
> +
> + return csid_find_code(src_code, ARRAY_SIZE(src_code),
> + match_format_idx, match_code);
> + }
> + case MEDIA_BUS_FMT_Y10_1X10:
> + {
> + u32 src_code[] = {
> + MEDIA_BUS_FMT_Y10_1X10,
> + MEDIA_BUS_FMT_Y10_2X8_PADHI_LE,
> + };
> +
> + return csid_find_code(src_code, ARRAY_SIZE(src_code),
> + match_format_idx, match_code);
> + }
> + default:
> + if (match_format_idx > 0)
> + return 0;
> +
> + return sink_code;
> + }
> +}
Same code as in gen2.
You could move the gen2 version of this into camss-csid.c and just reuse
in both.
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 10/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-07-09 16:06 ` [PATCH 10/13] media: qcom: camss: Add support for VFE hardware version Titan 780 Depeng Shao
2024-07-10 11:22 ` Krzysztof Kozlowski
@ 2024-07-10 11:47 ` Bryan O'Donoghue
2024-07-11 13:29 ` Depeng Shao
1 sibling, 1 reply; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-07-10 11:47 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
On 09/07/2024 17:06, Depeng Shao wrote:
> Add support for VFE found on SM8550 (Titan 780). This implementation is
> based on the titan 480 implementation. It supports the normal and lite
> VFE.
>
> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> ---
> drivers/media/platform/qcom/camss/Makefile | 1 +
> .../media/platform/qcom/camss/camss-vfe-780.c | 404 ++++++++++++++++++
> 2 files changed, 405 insertions(+)
> create mode 100644 drivers/media/platform/qcom/camss/camss-vfe-780.c
>
> diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
> index c336e4c1a399..a83b7a8dcef7 100644
> --- a/drivers/media/platform/qcom/camss/Makefile
> +++ b/drivers/media/platform/qcom/camss/Makefile
> @@ -17,6 +17,7 @@ qcom-camss-objs += \
> camss-vfe-4-8.o \
> camss-vfe-17x.o \
> camss-vfe-480.o \
> + camss-vfe-780.o \
> camss-vfe-gen1.o \
> camss-vfe.o \
> camss-video.o \
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-780.c b/drivers/media/platform/qcom/camss/camss-vfe-780.c
> new file mode 100644
> index 000000000000..abef2d5b9c2e
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss/camss-vfe-780.c
> @@ -0,0 +1,404 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * camss-vfe-780.c
> + *
> + * Qualcomm MSM Camera Subsystem - VFE (Video Front End) Module v780 (SM8550)
> + *
> + * Copyright (c) 2024 Qualcomm Technologies, Inc.
> + */
> +
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/iopoll.h>
> +
> +#include "camss.h"
> +#include "camss-vfe.h"
> +
> +#define VFE_HW_VERSION (vfe_is_lite(vfe) ? 0x1000 : 0x0)
> +
> +#define VFE_IRQ_CMD (vfe_is_lite(vfe) ? 0x1038 : 0x30)
> +#define IRQ_CMD_GLOBAL_CLEAR BIT(0)
> +
> +#define VFE_IRQ_MASK(n) ((vfe_is_lite(vfe) ? 0x1024 : 0x34) + (n) * 4)
> +#define IRQ_MASK_0_BUS_TOP_IRQ (vfe_is_lite(vfe) ? BIT(0) | BIT(1) | BIT(2) : \
> + BIT(0) | BIT(4) | BIT(18))
> +#define IRQ_MASK_1_BUS_TOP_IRQ(n) (vfe_is_lite(vfe) ? BIT(2 * n + 2) | BIT(2 * n + 3) : \
> + BIT(2 * n + 8) | BIT(2 * n + 9))
> +#define VFE_IRQ_CLEAR(n) ((vfe_is_lite(vfe) ? 0x102C : 0x3C) + (n) * 4)
> +#define VFE_IRQ_STATUS(n) ((vfe_is_lite(vfe) ? 0x101C : 0x44) + (n) * 4)
> +
> +#define BUS_REG_BASE (vfe_is_lite(vfe) ? 0x1200 : 0xC00)
> +
> +#define VFE_BUS_WM_CGC_OVERRIDE (BUS_REG_BASE + 0x08)
> +#define WM_CGC_OVERRIDE_ALL (0x7FFFFFF)
> +
> +#define VFE_BUS_WM_TEST_BUS_CTRL (BUS_REG_BASE + 0xDC)
> +
> +#define VFE_BUS_WM_CFG(n) (BUS_REG_BASE + 0x200 + (n) * 0x100)
> +#define WM_CFG_EN (0)
> +#define WM_VIR_FRM_EN (1)
> +#define WM_CFG_MODE (16)
> +#define MODE_QCOM_PLAIN (0)
> +#define MODE_MIPI_RAW (1)
> +#define VFE_BUS_WM_IMAGE_ADDR(n) (BUS_REG_BASE + 0x204 + (n) * 0x100)
> +#define VFE_BUS_WM_FRAME_INCR(n) (BUS_REG_BASE + 0x208 + (n) * 0x100)
> +#define VFE_BUS_WM_IMAGE_CFG_0(n) (BUS_REG_BASE + 0x20c + (n) * 0x100)
> +#define WM_IMAGE_CFG_0_DEFAULT_WIDTH (0xFFFF)
> +#define VFE_BUS_WM_IMAGE_CFG_1(n) (BUS_REG_BASE + 0x210 + (n) * 0x100)
> +#define VFE_BUS_WM_IMAGE_CFG_2(n) (BUS_REG_BASE + 0x214 + (n) * 0x100)
> +#define WM_IMAGE_CFG_2_DEFAULT_STRIDE (0xFFFF)
> +#define VFE_BUS_WM_PACKER_CFG(n) (BUS_REG_BASE + 0x218 + (n) * 0x100)
> +#define VFE_BUS_WM_HEADER_ADDR(n) (BUS_REG_BASE + 0x220 + (n) * 0x100)
> +#define VFE_BUS_WM_HEADER_INCR(n) (BUS_REG_BASE + 0x224 + (n) * 0x100)
> +#define VFE_BUS_WM_HEADER_CFG(n) (BUS_REG_BASE + 0x228 + (n) * 0x100)
> +
> +#define VFE_BUS_WM_IRQ_SUBSAMPLE_PERIOD(n) (BUS_REG_BASE + 0x230 + (n) * 0x100)
> +#define VFE_BUS_WM_IRQ_SUBSAMPLE_PATTERN(n) (BUS_REG_BASE + 0x234 + (n) * 0x100)
> +#define VFE_BUS_WM_FRAMEDROP_PERIOD(n) (BUS_REG_BASE + 0x238 + (n) * 0x100)
> +#define VFE_BUS_WM_FRAMEDROP_PATTERN(n) (BUS_REG_BASE + 0x23c + (n) * 0x100)
> +
> +#define VFE_BUS_WM_MMU_PREFETCH_CFG(n) (BUS_REG_BASE + 0x260 + (n) * 0x100)
> +#define VFE_BUS_WM_MMU_PREFETCH_MAX_OFFSET(n) (BUS_REG_BASE + 0x264 + (n) * 0x100)
> +#define VFE_BUS_WM_SYSTEM_CACHE_CFG(n) (BUS_REG_BASE + 0x268 + (n) * 0x100)
> +
> +/* for titan 780, each bus client is hardcoded to a specific path */
> +#define RDI_WM(n) ((vfe_is_lite(vfe) ? 0x0 : 0x17) + (n))
> +
> +#define MAX_VFE_OUTPUT_LINES 4
> +#define MAX_VFE_ACT_BUF 1
> +
> +static u32 vfe_hw_version(struct vfe_device *vfe)
> +{
> + u32 hw_version = readl_relaxed(vfe->base + VFE_HW_VERSION);
> +
> + u32 gen = (hw_version >> 28) & 0xF;
> + u32 rev = (hw_version >> 16) & 0xFFF;
> + u32 step = hw_version & 0xFFFF;
> +
> + dev_info(vfe->camss->dev, "VFE HW Version = %u.%u.%u\n", gen, rev, step);
> +
> + return hw_version;
> +}
This could be functionally decomposed into vfe_hw_version_v2() or
similar and exported by camss-vfe.c
> +
> +static void vfe_wm_start(struct vfe_device *vfe, u8 wm, struct vfe_line *line)
> +{
> + struct v4l2_pix_format_mplane *pix =
> + &line->video_out.active_fmt.fmt.pix_mp;
> +
> + wm = RDI_WM(wm); /* map to actual WM used (from wm=RDI index) */
> +
> + /* no clock gating at bus input */
> + writel_relaxed(0, vfe->base + VFE_BUS_WM_CGC_OVERRIDE);
> +
> + writel_relaxed(0x0, vfe->base + VFE_BUS_WM_TEST_BUS_CTRL);
> +
> + writel_relaxed(ALIGN(pix->plane_fmt[0].bytesperline, 16) * pix->height >> 8,
> + vfe->base + VFE_BUS_WM_FRAME_INCR(wm));
> + writel_relaxed((WM_IMAGE_CFG_0_DEFAULT_WIDTH & 0xFFFF),
> + vfe->base + VFE_BUS_WM_IMAGE_CFG_0(wm));
> + writel_relaxed(WM_IMAGE_CFG_2_DEFAULT_STRIDE,
> + vfe->base + VFE_BUS_WM_IMAGE_CFG_2(wm));
> + writel_relaxed(0, vfe->base + VFE_BUS_WM_PACKER_CFG(wm));
> +
> + /* no dropped frames, one irq per frame */
> + writel_relaxed(0, vfe->base + VFE_BUS_WM_FRAMEDROP_PERIOD(wm));
> + writel_relaxed(1, vfe->base + VFE_BUS_WM_FRAMEDROP_PATTERN(wm));
> + writel_relaxed(0, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PERIOD(wm));
> + writel_relaxed(1, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PATTERN(wm));
> +
> + writel_relaxed(1, vfe->base + VFE_BUS_WM_MMU_PREFETCH_CFG(wm));
> + writel_relaxed(0xFFFFFFFF, vfe->base + VFE_BUS_WM_MMU_PREFETCH_MAX_OFFSET(wm));
> +
> + writel_relaxed(1 << WM_CFG_EN | MODE_MIPI_RAW << WM_CFG_MODE,
> + vfe->base + VFE_BUS_WM_CFG(wm));
> +}
> +
> +static void vfe_wm_stop(struct vfe_device *vfe, u8 wm)
> +{
> + wm = RDI_WM(wm); /* map to actual WM used (from wm=RDI index) */
> + writel_relaxed(0, vfe->base + VFE_BUS_WM_CFG(wm));
> +}
> +
> +static void vfe_wm_update(struct vfe_device *vfe, u8 wm, u64 addr,
> + struct vfe_line *line)
> +{
> + wm = RDI_WM(wm); /* map to actual WM used (from wm=RDI index) */
> + writel_relaxed((addr >> 8) & 0xFFFFFFFF, vfe->base + VFE_BUS_WM_IMAGE_ADDR(wm));
> +
> + dev_dbg(vfe->camss->dev, "%s wm:%d, image buf addr:0x%llx\n",
> + __func__, wm, addr);
> +}
> +
> +static void vfe_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id)
> +{
> + /* TODO: Add register update support */
> +}
> +
> +static inline void vfe_reg_update_clear(struct vfe_device *vfe,
> + enum vfe_line_id line_id)
> +{
> + /* TODO: Add register update clear support */
> +}
> +
> +/*
> + * vfe_isr - VFE module interrupt handler
> + * @irq: Interrupt line
> + * @dev: VFE device
> + *
> + * Return IRQ_HANDLED on success
> + */
> +static irqreturn_t vfe_isr(int irq, void *dev)
> +{
> + /* Buf Done has beem moved to CSID in Titan 780.
> + * Disable VFE related IRQ.
> + * Clear the contents of this function.
> + * Return IRQ_HANDLED.
> + */
> + return IRQ_HANDLED;
> +}
What's the point of this ISR at all if it never fires and just returns
done ?
Since it takes no action - it can't do anything useful and therefore if
it ever did fire, would fire ad infinitum.
Please drop.
> +
> +/*
> + * vfe_halt - Trigger halt on VFE module and wait to complete
> + * @vfe: VFE device
> + *
> + * Return 0 on success or a negative error code otherwise
> + */
> +static int vfe_halt(struct vfe_device *vfe)
> +{
> + /* rely on vfe_disable_output() to stop the VFE */
> + return 0;
> +}
> +
> +static int vfe_get_output(struct vfe_line *line)
> +{
> + struct vfe_device *vfe = to_vfe(line);
> + struct vfe_output *output;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&vfe->output_lock, flags);
> +
> + output = &line->output;
> + if (output->state > VFE_OUTPUT_RESERVED) {
> + dev_err(vfe->camss->dev, "Output is running\n");
> + goto error;
> + }
> +
> + output->wm_num = 1;
> +
> + /* Correspondence between VFE line number and WM number.
> + * line 0 -> RDI 0, line 1 -> RDI1, line 2 -> RDI2, line 3 -> PIX/RDI3
> + * Note this 1:1 mapping will not work for PIX streams.
> + */
> + output->wm_idx[0] = line->id;
> + vfe->wm_output_map[line->id] = line->id;
> +
> + output->drop_update_idx = 0;
> +
> + spin_unlock_irqrestore(&vfe->output_lock, flags);
> +
> + return 0;
> +
> +error:
> + spin_unlock_irqrestore(&vfe->output_lock, flags);
> + output->state = VFE_OUTPUT_OFF;
> +
> + return -EINVAL;
> +}
This is copy/paste from vfe480 and should be functionally decomposed
into a common function in camss-vfe.c
> +
> +static int vfe_enable_output(struct vfe_line *line)
> +{
> + struct vfe_device *vfe = to_vfe(line);
> + struct vfe_output *output = &line->output;
> + unsigned long flags;
> + unsigned int i;
> +
> + spin_lock_irqsave(&vfe->output_lock, flags);
> +
> + vfe_reg_update_clear(vfe, line->id);
> +
> + if (output->state > VFE_OUTPUT_RESERVED) {
> + dev_err(vfe->camss->dev, "Output is not in reserved state %d\n",
> + output->state);
> + spin_unlock_irqrestore(&vfe->output_lock, flags);
> + return -EINVAL;
> + }
> +
> + WARN_ON(output->gen2.active_num);
> +
> + output->state = VFE_OUTPUT_ON;
> +
> + output->sequence = 0;
> +
> + vfe_wm_start(vfe, output->wm_idx[0], line);
> +
> + for (i = 0; i < MAX_VFE_ACT_BUF; i++) {
> + output->buf[i] = vfe_buf_get_pending(output);
> + if (!output->buf[i])
> + break;
> + output->gen2.active_num++;
> + vfe_wm_update(vfe, output->wm_idx[0], output->buf[i]->addr[0], line);
> +
> + vfe_reg_update(vfe, line->id);
I see this differs from vfe480 in that vfe_reg_update(vfe, line-id); is
done on each iteration of this loop whereas in 480 it is done directly
after the loop, seems to me this would be a valid fix for 480 too
leading to my next comment
> + }
> +
> + spin_unlock_irqrestore(&vfe->output_lock, flags);
> +
> + return 0;
> +}
This function is so similar across different SoCs with very minor
differences that instead of copy/pasting and very slightly tweaking, we
should be functionally decomposing and using a flag of some kind to
differentaite between wait_reg_update logic in 480 and not in 780.
Again I think we should functionally decompose into camss-vfe.c and use
a flag to branch the logic for the very slight logical difference
between the two
vfe-480.c
output->sequence = 0;
output->wait_reg_update = 0;
reinit_completion(&output->reg_update);
As a result your fix for line->id would be useful across SoCs instead of
isolated to vfe 780.
> +
> +/*
> + * vfe_enable - Enable streaming on VFE line
> + * @line: VFE line
> + *
> + * Return 0 on success or a negative error code otherwise
> + */
> +static int vfe_enable(struct vfe_line *line)
> +{
> + struct vfe_device *vfe = to_vfe(line);
> + int ret;
> +
> + mutex_lock(&vfe->stream_lock);
> +
> + vfe->stream_count++;
> +
> + mutex_unlock(&vfe->stream_lock);
> +
> + ret = vfe_get_output(line);
> + if (ret < 0)
> + goto error_get_output;
> +
> + ret = vfe_enable_output(line);
> + if (ret < 0)
> + goto error_enable_output;
> +
> + vfe->was_streaming = 1;
> +
> + return 0;
> +
> +error_enable_output:
> + vfe_put_output(line);
> +
> +error_get_output:
> + mutex_lock(&vfe->stream_lock);
> +
> + vfe->stream_count--;
> +
> + mutex_unlock(&vfe->stream_lock);
> +
> + return ret;
> +}
Same thesis on functional decomposition - this should be moved to
camss-vfe.c and made common - its only a minor difference betwen the
required logic on different SoCs so there's not a compelling reason to
have largely identical functions living in difference .c files in the
same driver.
> +
> +/*
> + * vfe_buf_done - Process write master done interrupt
> + * @vfe: VFE Device
> + * @wm: Write master id
> + */
> +static void vfe_buf_done(struct vfe_device *vfe, int wm)
> +{
> + struct vfe_line *line = &vfe->line[vfe->wm_output_map[wm]];
> + struct camss_buffer *ready_buf;
> + struct vfe_output *output;
> + unsigned long flags;
> + u32 index;
> + u64 ts = ktime_get_ns();
> +
> + spin_lock_irqsave(&vfe->output_lock, flags);
> +
> + if (vfe->wm_output_map[wm] == VFE_LINE_NONE) {
> + dev_err_ratelimited(vfe->camss->dev,
> + "Received wm done for unmapped index\n");
> + goto out_unlock;
> + }
> + output = &vfe->line[vfe->wm_output_map[wm]].output;
> +
> + ready_buf = output->buf[0];
> + if (!ready_buf) {
> + dev_err_ratelimited(vfe->camss->dev,
> + "Missing ready buf %d!\n", output->state);
> + goto out_unlock;
> + }
> +
> + ready_buf->vb.vb2_buf.timestamp = ts;
> + ready_buf->vb.sequence = output->sequence++;
> +
> + index = 0;
> + output->buf[0] = output->buf[1];
> + if (output->buf[0])
> + index = 1;
> +
> + output->buf[index] = vfe_buf_get_pending(output);
> +
> + if (output->buf[index]) {
> + vfe_wm_update(vfe, output->wm_idx[0], output->buf[index]->addr[0], line);
> + vfe_reg_update(vfe, line->id);
> + } else
> + output->gen2.active_num--;
> +
> + spin_unlock_irqrestore(&vfe->output_lock, flags);
> +
> + vb2_buffer_done(&ready_buf->vb.vb2_buf, VB2_BUF_STATE_DONE);
> +
> + return;
> +
> +out_unlock:
> + spin_unlock_irqrestore(&vfe->output_lock, flags);
> +}
> +
> +/*
> + * vfe_queue_buffer - Add empty buffer
> + * @vid: Video device structure
> + * @buf: Buffer to be enqueued
> + *
> + * Add an empty buffer - depending on the current number of buffers it will be
> + * put in pending buffer queue or directly given to the hardware to be filled.
> + *
> + * Return 0 on success or a negative error code otherwise
> + */
> +static int vfe_queue_buffer(struct camss_video *vid,
> + struct camss_buffer *buf)
> +{
> + struct vfe_line *line = container_of(vid, struct vfe_line, video_out);
> + struct vfe_device *vfe = to_vfe(line);
> + struct vfe_output *output;
> + unsigned long flags;
> +
> + output = &line->output;
> +
> + spin_lock_irqsave(&vfe->output_lock, flags);
> +
> + if (output->state == VFE_OUTPUT_ON &&
> + output->gen2.active_num < MAX_VFE_ACT_BUF) {
> + output->buf[output->gen2.active_num++] = buf;
> + vfe_wm_update(vfe, output->wm_idx[0], buf->addr[0], line);
> + vfe_reg_update(vfe, line->id);
> + } else {
> + vfe_buf_add_pending(output, buf);
> + }
> +
> + spin_unlock_irqrestore(&vfe->output_lock, flags);
> +
> + return 0;
> +}
> +
> +static const struct camss_video_ops vfe_video_ops_780 = {
> + .queue_buffer = vfe_queue_buffer,
> + .flush_buffers = vfe_flush_buffers,
> +};
> +
> +static void vfe_subdev_init(struct device *dev, struct vfe_device *vfe)
> +{
> + vfe->video_ops = vfe_video_ops_780;
> +}
> +
> +const struct vfe_hw_ops vfe_ops_780 = {
> + .global_reset = NULL,
> + .hw_version = vfe_hw_version,
> + .isr = vfe_isr,
> + .pm_domain_off = vfe_pm_domain_off,
> + .pm_domain_on = vfe_pm_domain_on,
> + .subdev_init = vfe_subdev_init,
> + .vfe_disable = vfe_disable,
> + .vfe_enable = vfe_enable,
> + .vfe_halt = vfe_halt,
> + .vfe_wm_stop = vfe_wm_stop,
> +};
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 11/13] media: qcom: camss: Add notify interface in camss driver
2024-07-09 16:06 ` [PATCH 11/13] media: qcom: camss: Add notify interface in camss driver Depeng Shao
@ 2024-07-10 11:54 ` Bryan O'Donoghue
2024-07-11 11:54 ` Depeng Shao
0 siblings, 1 reply; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-07-10 11:54 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
On 09/07/2024 17:06, Depeng Shao wrote:
> The main v4l2 process logic in camss vfe subdev driver, so the vfe driver
> handles the buf done irq and register update configuration. But the buf
> done irq and register update configuration have been moved CSID HW in
> Titan 780 and other new platform, so vfe driver needs to call into CSID
> driver to configure the register update. And CSID driver also needs to
> call into vfe driver to notify of the buf done irq.
>
> Adding this notify interface in camss structure to do the subdevs cross
> communication to decouple CSID and VFE, the subdevs can add an interface
> to process the message what is routed from other subdevices, then we can
> process the cross communication easily.
>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> ---
> .../platform/qcom/camss/camss-csid-gen3.c | 38 +++++++++++++++
> .../media/platform/qcom/camss/camss-csid.h | 8 ++++
> .../media/platform/qcom/camss/camss-vfe-780.c | 29 +++++++++++-
> drivers/media/platform/qcom/camss/camss-vfe.h | 1 +
> drivers/media/platform/qcom/camss/camss.c | 47 +++++++++++++++++++
> drivers/media/platform/qcom/camss/camss.h | 9 ++++
> 6 files changed, 130 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
> index 17fd7c5499de..585054948255 100644
> --- a/drivers/media/platform/qcom/camss/camss-csid-gen3.c
> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
> @@ -312,6 +312,18 @@ static u32 csid_hw_version(struct csid_device *csid)
> return hw_version;
> }
>
> +static void csid_reg_update(struct csid_device *csid, int port_id)
> +{
> + csid->reg_update |= REG_UPDATE_RDI(csid, port_id);
> + writel_relaxed(csid->reg_update, csid->base + CSID_REG_UPDATE_CMD);
> +}
> +
> +static inline void csid_reg_update_clear(struct csid_device *csid,
> + int port_id)
> +{
> + csid->reg_update &= ~REG_UPDATE_RDI(csid, port_id);
> +}
> +
> /*
> * csid_isr - CSID module interrupt service routine
> * @irq: Interrupt line
> @@ -341,6 +353,14 @@ static irqreturn_t csid_isr(int irq, void *dev)
> if (csid->phy.en_vc & BIT(i)) {
> val = readl_relaxed(csid->base + CSID_CSI2_RDIN_IRQ_STATUS(i));
> writel_relaxed(val, csid->base + CSID_CSI2_RDIN_IRQ_CLEAR(i));
> +
> + if (buf_done_val & BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i)) {
> + /* For Titan 780, Buf Done IRQ® has been moved to CSID from VFE.
> + * Once CSID received Buf Done, need notify this event to VFE.
> + * Trigger VFE to handle Buf Done process.
> + */
> + csid->camss->notify(&csid->subdev, CAMSS_MSG_BUF_DONE, (void *)&i);
Instead of a generic notify function with an enum passed to a switch
lets just have a dedicated function for each functional callback.
csid->camss->reg_update_cmd();
csid->camss->reg_clear_cmd();
We can get rid of a switch and an additional enum that way, plus
redundant "event not supported" error checking.
> + }
> }
>
> val = 1 << IRQ_CMD_CLEAR;
> @@ -434,6 +454,23 @@ static void csid_subdev_init(struct csid_device *csid)
> csid->testgen.nmodes = CSID_PAYLOAD_MODE_NUM_SUPPORTED_GEN2;
> }
>
> +static void csid_subdev_process_msg(struct csid_device *csid, unsigned int msg_type, void *arg)
> +{
> + int msg_data = *(int *)arg;
> +
> + switch (msg_type) {
> + case CAMSS_MSG_RUP:
> + csid_reg_update(csid, msg_data);
> + break;
> + case CAMSS_MSG_RUP_CLEAR:
> + csid_reg_update_clear(csid, msg_data);
> + break;
> + default:
> + dev_err(csid->camss->dev, "NOT Supported EVT Type\n");
> + break;
> + }
> +}
> +
> const struct csid_hw_ops csid_ops_gen3 = {
> .configure_stream = csid_configure_stream,
> .configure_testgen_pattern = csid_configure_testgen_pattern,
> @@ -442,4 +479,5 @@ const struct csid_hw_ops csid_ops_gen3 = {
> .reset = csid_reset,
> .src_pad_code = csid_src_pad_code,
> .subdev_init = csid_subdev_init,
> + .process_msg = csid_subdev_process_msg,
> };
> diff --git a/drivers/media/platform/qcom/camss/camss-csid.h b/drivers/media/platform/qcom/camss/camss-csid.h
> index ae5b6b0dc0ea..714a8db855fd 100644
> --- a/drivers/media/platform/qcom/camss/camss-csid.h
> +++ b/drivers/media/platform/qcom/camss/camss-csid.h
> @@ -152,6 +152,14 @@ struct csid_hw_ops {
> * @csid: CSID device
> */
> void (*subdev_init)(struct csid_device *csid);
> +
> + /*
> + * process_msg - receive message from other sub device
> + * @csid: CSID device
> + * @evt_type: event type
> + * @arg: arguments
> + */
> + void (*process_msg)(struct csid_device *csid, unsigned int evt_type, void *arg);
> };
>
> struct csid_subdev_resources {
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-780.c b/drivers/media/platform/qcom/camss/camss-vfe-780.c
> index abef2d5b9c2e..3279fe53b987 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe-780.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe-780.c
> @@ -131,13 +131,23 @@ static void vfe_wm_update(struct vfe_device *vfe, u8 wm, u64 addr,
>
> static void vfe_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id)
> {
> - /* TODO: Add register update support */
> + int port_id = line_id;
> +
> + /* RUP(register update) registers has beem moved to CSID in Titan 780.
> + * Notify the event of trigger RUP.
> + */
> + vfe->camss->notify(&vfe->line[line_id].subdev, CAMSS_MSG_RUP, (void *)&port_id);
> }
>
> static inline void vfe_reg_update_clear(struct vfe_device *vfe,
> enum vfe_line_id line_id)
> {
> - /* TODO: Add register update clear support */
> + int port_id = line_id;
> +
> + /* RUP(register update) registers has beem moved to CSID in Titan 780.
> + * Notify the event of trigger RUP clear.
> + */
> + vfe->camss->notify(&vfe->line[line_id].subdev, CAMSS_MSG_RUP_CLEAR, (void *)&port_id);
> }
>
> /*
> @@ -390,6 +400,20 @@ static void vfe_subdev_init(struct device *dev, struct vfe_device *vfe)
> vfe->video_ops = vfe_video_ops_780;
> }
>
> +static void vfe_subdev_process_msg(struct vfe_device *vfe, unsigned int msg_type, void *arg)
> +{
> + int port_id = *(int *)arg;
> +
> + switch (msg_type) {
> + case CAMSS_MSG_BUF_DONE:
> + vfe_buf_done(vfe, port_id);
> + break;
> +
> + default:
> + break;
> + }
> +}
> +
> const struct vfe_hw_ops vfe_ops_780 = {
> .global_reset = NULL,
> .hw_version = vfe_hw_version,
> @@ -401,4 +425,5 @@ const struct vfe_hw_ops vfe_ops_780 = {
> .vfe_enable = vfe_enable,
> .vfe_halt = vfe_halt,
> .vfe_wm_stop = vfe_wm_stop,
> + .process_msg = vfe_subdev_process_msg,
> };
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.h b/drivers/media/platform/qcom/camss/camss-vfe.h
> index 10e2cc3c0b83..a8b09ce9941b 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe.h
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.h
> @@ -115,6 +115,7 @@ struct vfe_hw_ops {
> int (*vfe_halt)(struct vfe_device *vfe);
> void (*violation_read)(struct vfe_device *vfe);
> void (*vfe_wm_stop)(struct vfe_device *vfe, u8 wm);
> + void (*process_msg)(struct vfe_device *vfe, unsigned int msg_type, void *arg);
> };
>
> struct vfe_isr_ops {
> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index 1f1f44f6fbb2..abeb0918e47d 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -2202,6 +2202,52 @@ static void camss_genpd_cleanup(struct camss *camss)
> dev_pm_domain_detach(camss->genpd, true);
> }
>
> +static void camss_notify_msg(struct v4l2_subdev *sd,
> + unsigned int msg_type, void *arg)
> +{
> + struct v4l2_device *v4l2_dev = sd->v4l2_dev;
> + struct camss *camss = to_camss(v4l2_dev);
> + struct vfe_device *vfe;
> + struct vfe_line *vfe_line;
> + struct csid_device *csid;
> + int evt_data = *(int *)arg;
> +
> + switch (msg_type) {
> + case CAMSS_MSG_BUF_DONE:
> + csid = v4l2_get_subdevdata(sd);
> + vfe = &(camss->vfe[csid->id]);
> + if (vfe->res->hw_ops->process_msg)
> + vfe->res->hw_ops->process_msg(vfe,
> + CAMSS_MSG_BUF_DONE, (void *)&evt_data);
> + break;
> +
> + case CAMSS_MSG_RUP:
> + vfe_line = v4l2_get_subdevdata(sd);
> + vfe = to_vfe(vfe_line);
> + csid = &(camss->csid[vfe->id]);
> +
> + if (csid->res->hw_ops->process_msg)
> + csid->res->hw_ops->process_msg(csid,
> + CAMSS_MSG_RUP, (void *)&evt_data);
> + break;
> +
> + case CAMSS_MSG_RUP_CLEAR:
> + vfe_line = v4l2_get_subdevdata(sd);
> + vfe = to_vfe(vfe_line);
> + csid = &(camss->csid[vfe->id]);
> +
> + if (csid->res->hw_ops->process_msg)
> + csid->res->hw_ops->process_msg(csid,
> + CAMSS_MSG_RUP_CLEAR, (void *)&evt_data);
> +
> + break;
> +
> + default:
> + dev_err(camss->dev, "Not supported evt type\n");
> + break;
> + }
> +}
Instead of having a central swiss army knife notify() callback these
should be CSID or VFE specific callbacks vfe->buf_done() csid->msg_rup()
etc.
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 12/13] media: qcom: camss: Add sm8550 support
2024-07-09 16:06 ` [PATCH 12/13] media: qcom: camss: Add sm8550 support Depeng Shao
@ 2024-07-10 12:02 ` Bryan O'Donoghue
2024-07-11 14:36 ` Depeng Shao
0 siblings, 1 reply; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-07-10 12:02 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
On 09/07/2024 17:06, Depeng Shao wrote:
> Add in functional logic throughout the code to support the SM8550.
>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> ---
> .../media/platform/qcom/camss/camss-csid.c | 21 +++++++++++++++++++
> .../qcom/camss/camss-csiphy-3ph-1-0.c | 6 ++++++
> drivers/media/platform/qcom/camss/camss-vfe.c | 6 ++++++
> drivers/media/platform/qcom/camss/camss.h | 1 +
> 4 files changed, 34 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/camss/camss-csid.c b/drivers/media/platform/qcom/camss/camss-csid.c
> index 858db5d4ca75..90fba25db4c6 100644
> --- a/drivers/media/platform/qcom/camss/camss-csid.c
> +++ b/drivers/media/platform/qcom/camss/camss-csid.c
> @@ -1013,6 +1013,7 @@ int msm_csid_subdev_init(struct camss *camss, struct csid_device *csid,
> {
> struct device *dev = camss->dev;
> struct platform_device *pdev = to_platform_device(dev);
> + struct resource *top_res;
> int i, j;
> int ret;
>
> @@ -1040,6 +1041,26 @@ int msm_csid_subdev_init(struct camss *camss, struct csid_device *csid,
> else
> csid->base = csid->res->parent_dev_ops->get_base_address(camss, id)
> + VFE_480_CSID_OFFSET;
> + } else if (camss->res->version == CAMSS_8550) {
> + /* for titan 780, CSID lite registers are inside the VFE lite region,
> + * between the VFE "top" and "bus" registers. this requires
> + * VFE to be initialized before CSID
> + */
> + if (csid_is_lite(csid))
> + csid->base = csid->res->parent_dev_ops->get_base_address(camss, id);
> + else {
> + csid->base = devm_platform_ioremap_resource_byname(pdev, res->reg[0]);
> + /* CSID "top" is a new function in Titan780.
> + * CSID can connect to VFE & SFE(Sensor Front End).
> + * This connection is ontrolled by CSID "top" registers.
> + * CSID "top" registers at only one region.
> + */
> + top_res = platform_get_resource_byname(pdev, IORESOURCE_MEM, res->reg[1]);
> + csid->top_base = ioremap(top_res->start, resource_size(top_res));
> + }
If we just specify the csid lite regs in the dts, we don't need custom
code to get a pointer to them.
Similarly the csid->top_base = () should be generic not SoC specific,
i.e. we should be able to add in CSID 980 without adding any custom code
to camss-csid.c
> +
> + if (IS_ERR(csid->base))
> + return PTR_ERR(csid->base);
> } else {
> csid->base = devm_platform_ioremap_resource_byname(pdev, res->reg[0]);
> if (IS_ERR(csid->base))
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> index b6d5a27b94a6..53c46c2e5896 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> @@ -631,6 +631,7 @@ static bool csiphy_is_gen2(u32 version)
> case CAMSS_845:
> case CAMSS_8250:
> case CAMSS_8280XP:
> + case CAMSS_8550:
> ret = true;
> break;
> }
> @@ -718,6 +719,11 @@ static int csiphy_init(struct csiphy_device *csiphy)
> regs->lane_regs = &lane_regs_sc8280xp[0];
> regs->lane_array_size = ARRAY_SIZE(lane_regs_sc8280xp);
> break;
> + case CAMSS_8550:
> + regs->lane_regs = &lane_regs_sm8550[0];
> + regs->lane_array_size = ARRAY_SIZE(lane_regs_sm8550);
> + regs->offset = 0x1000;
> + break;
> default:
> WARN(1, "unknown csiphy version\n");
> return -ENODEV;
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
> index 83c5a36d071f..479474c1cd95 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
> @@ -338,6 +338,7 @@ static u32 vfe_src_pad_code(struct vfe_line *line, u32 sink_code,
> case CAMSS_845:
> case CAMSS_8250:
> case CAMSS_8280XP:
> + case CAMSS_8550:
> switch (sink_code) {
> case MEDIA_BUS_FMT_YUYV8_1X16:
> {
> @@ -408,6 +409,10 @@ int vfe_reset(struct vfe_device *vfe)
>
> reinit_completion(&vfe->reset_complete);
>
> + /* The reset has been moved to csid in 8550 */
> + if (vfe->camss->res->version == CAMSS_8550)
> + return 0;
> +
Custom code for a specific SoC in camss.c camss-csid.c or camss-vfe.c
indicates to me we need to do more work elsewhere.
This would do the same job for you.
static void vfe_global_reset(struct vfe_device *vfe)
{
/* VFE780 has no global reset, simply report a completion */
complete(&vfe->reset_complete);
}
const struct vfe_hw_ops vfe_ops_780 = {
.global_reset = vfe_global_reset,
> vfe->res->hw_ops->global_reset(vfe);
>
> time = wait_for_completion_timeout(&vfe->reset_complete,
> @@ -1695,6 +1700,7 @@ static int vfe_bpl_align(struct vfe_device *vfe)
> case CAMSS_845:
> case CAMSS_8250:
> case CAMSS_8280XP:
> + case CAMSS_8550:
> ret = 16;
> break;
> default:
> diff --git a/drivers/media/platform/qcom/camss/camss.h b/drivers/media/platform/qcom/camss/camss.h
> index 65fcebd42c4b..feac83510a17 100644
> --- a/drivers/media/platform/qcom/camss/camss.h
> +++ b/drivers/media/platform/qcom/camss/camss.h
> @@ -79,6 +79,7 @@ enum camss_version {
> CAMSS_845,
> CAMSS_8250,
> CAMSS_8280XP,
> + CAMSS_8550,
> };
>
> enum icc_count {
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH V3 00/13] media: qcom: camss: Add sm8550 support
2024-07-10 11:27 ` Depeng Shao
@ 2024-07-10 12:30 ` Krzysztof Kozlowski
2024-07-11 11:14 ` Depeng Shao
0 siblings, 1 reply; 99+ messages in thread
From: Krzysztof Kozlowski @ 2024-07-10 12:30 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
On 10/07/2024 13:27, Depeng Shao wrote:
>
>
> On 7/10/2024 7:08 PM, Krzysztof Kozlowski wrote:
>> On 09/07/2024 18:06, Depeng Shao wrote:
>>> V3:
>>> - Rebased the change based on below change which will be merged firstly.
>>> "Move camss version related defs in to resources"
>>> Link: https://lore.kernel.org/all/20240522154659.510-1-quic_grosikop@quicinc.com/
>>> - Rebased the change based on Bryan's csiphy optimization change and add
>>> these changes into this series, so that the new csiphy-3ph driver don't
>>> need to add duplicate code. This has got Bryan's permission to add his
>>> patches into this series.
>>> - Refactor some changes based on the comments to move the random code to
>>> patches where they are used.
>>> - Remove the vfe780 irq function since it isn't doing the actual work.
>>> - Add dt-binding for sm8550 camss driver.
>>> Link to V2: https://lore.kernel.org/all/20240320141136.26827-1-quic_depengs@quicinc.com/
>>
>> I asked for reference to upstream DTS - where can I find the DTS patches?
>>
>> Best regards,
>> Krzysztof
>>
>
> Hi Krzysztof,
>
> Sorry for that, I thought add the dt-binding is also fine, since I saw
> other patches also do like this. Will add add the DTS in next patch set.
DTS should not be part of this patchset, but sent separately. It's
enough if you post a lore link to it.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 08/13] media: qcom: camss: csiphy-3ph: Add Gen2 v1.2 two-phase MIPI CSI-2 DPHY init
2024-07-10 11:09 ` Krzysztof Kozlowski
@ 2024-07-10 13:14 ` Depeng Shao
0 siblings, 0 replies; 99+ messages in thread
From: Depeng Shao @ 2024-07-10 13:14 UTC (permalink / raw)
To: Krzysztof Kozlowski, rfoss, todor.too, bryan.odonoghue, mchehab,
robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
On 7/10/2024 7:09 PM, Krzysztof Kozlowski wrote:
> On 09/07/2024 18:06, Depeng Shao wrote:
>> Add a PHY configuration sequence for the SM8550 which uses a Qualcomm
>> Gen 2 version 1.2 CSI-2 PHY.
>>
>> The PHY can be configured as two phase or three phase in C-PHY or D-PHY
>> mode. This configuration supports two-phase D-PHY mode.
>>
>> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
>> ---
>> .../qcom/camss/camss-csiphy-3ph-1-0.c | 105 ++++++++++++++++++
>> 1 file changed, 105 insertions(+)
>>
>> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
>> index 1219a25ec55b..b6d5a27b94a6 100644
>> --- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
>> +++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
>> @@ -324,6 +324,111 @@ csiphy_lane_regs lane_regs_sm8250[] = {
>> {0x0884, 0x01, 0x00, CSIPHY_DEFAULT_PARAMS},
>> };
>>
>> +/* GEN2 1.2 2PH */
>> +static const struct
>> +csiphy_lane_regs lane_regs_sm8550[] = {
>
> This should sparkle warnings.
>
> There is no user of it. You must organize your patches in logical junks.
> Adding piece of structure without users is not a logical chunk.
>
> Best regards,
> Krzysztof
>
Hi Krzysztof,
Sure, will move this patch to "media: qcom: camss: Add sm8550 support",
It is used in below code.
> + case CAMSS_8550:
> + regs->lane_regs = &lane_regs_sm8550[0];
> + regs->lane_array_size = ARRAY_SIZE(lane_regs_sm8550);
> + regs->offset = 0x1000;
> + break;
> default:
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 08/13] media: qcom: camss: csiphy-3ph: Add Gen2 v1.2 two-phase MIPI CSI-2 DPHY init
2024-07-10 11:13 ` Bryan O'Donoghue
@ 2024-07-10 13:33 ` Depeng Shao
0 siblings, 0 replies; 99+ messages in thread
From: Depeng Shao @ 2024-07-10 13:33 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
On 7/10/2024 7:13 PM, Bryan O'Donoghue wrote:
> On 09/07/2024 17:06, Depeng Shao wrote:
>> +/* GEN2 1.2 2PH */
>> +static const struct
>> +csiphy_lane_regs lane_regs_sm8550[] = {
>> + {0x0E90, 0x0f, 0x00, CSIPHY_DEFAULT_PARAMS},
>> + {0x0E98, 0x08, 0x00, CSIPHY_DEFAULT_PARAMS},
>
> Definitely not DPHY 1.2 init sequence.
>
> Could you update to something like /* GEN2 2.x - two phase 5 Gbps DPHY
> mode 4 lanes */
>
> Since the PHY can be in DPHY or CPHY mode at different data-rates it
> would be nice to call out the exact mode we are upstreaming here.
>
> ---
> bod
Yes, this isn't 1.2, it should be GEN2 2.1.2, thanks for catching this.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-07-10 11:07 ` Krzysztof Kozlowski
@ 2024-07-11 10:43 ` Depeng Shao
0 siblings, 0 replies; 99+ messages in thread
From: Depeng Shao @ 2024-07-11 10:43 UTC (permalink / raw)
To: Krzysztof Kozlowski, rfoss, todor.too, bryan.odonoghue, mchehab,
robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
Hi Krzysztof,
On 7/10/2024 7:07 PM, Krzysztof Kozlowski wrote:
>> +
>> +description: |
>
> Do not need '|' unless you need to preserve formatting.
>
> This wasn't tested so I am not going to perform full review.
>
> Look at "Re: [PATCH 1/6] media: dt-bindings: media: camss: Add
> qcom,sc7280-camss binding" - all comments apply.
>
> ...
>
Sure, I will follow the comments in
https://lore.kernel.org/linux-arm-msm/087e7f29-1fa8-4bc2-bb3d-acb941432381@kernel.org/
>> +
>> +required:
>> + - clock-names
>> + - clocks
>> + - compatible
>
> Keep the same order as in "properties:'.
>
Sure, I will update it.
>> +
>> + reg = <0 0x0ace4000 0 0x2000>,
>> + <0 0x0ace6000 0 0x2000>,
>> + <0 0x0ace8000 0 0x2000>,
>> + <0 0x0acea000 0 0x2000>,
>> + <0 0x0acec000 0 0x2000>,
>> + <0 0x0acee000 0 0x2000>,
>> + <0 0x0acf0000 0 0x2000>,
>> + <0 0x0acf2000 0 0x2000>,
>> + <0 0x0acb7000 0 0xd00>,
>> + <0 0x0acb9000 0 0xd00>,
>> + <0 0x0acbb000 0 0xd00>,
>> + <0 0x0acca000 0 0xa00>,
>> + <0 0x0acce000 0 0xa00>,
>> + <0 0x0acb6000 0 0x1000>,
>> + <0 0x0ac62000 0 0xf000>,
>> + <0 0x0ac71000 0 0xf000>,
>> + <0 0x0ac80000 0 0xf000>,
>> + <0 0x0acca000 0 0x2800>,
>> + <0 0x0acce000 0 0x2800>;
>> + reg-names = "csiphy0",
>> + "csiphy1",
>> + "csiphy2",
>> + "csiphy3",
>
> These (and many others further) looks misaligned.
>
Thanks for pointing out this, will fix this.
> Best regards,
> Krzysztof
>
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550
2024-07-10 11:20 ` Krzysztof Kozlowski
@ 2024-07-11 11:08 ` Depeng Shao
2024-07-11 11:12 ` Krzysztof Kozlowski
0 siblings, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-07-11 11:08 UTC (permalink / raw)
To: Krzysztof Kozlowski, rfoss, todor.too, bryan.odonoghue, mchehab,
robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
Hi Krzysztof,
On 7/10/2024 7:20 PM, Krzysztof Kozlowski wrote:
> On 09/07/2024 18:06, Depeng Shao wrote:
>> The CSID in SM8550 is gen3, it has new register offset and new
>> functionality. The buf done irq,register update and reset are
>> moved to CSID gen3. And CSID gen3 has a new register block which
>> is named as CSID top, it controls the output of CSID, since the
>> CSID can connect to Sensor Front End (SFE) or original VFE, the
>> register in top block is used to control the HW connection.
>>
>> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
>> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
>> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
>> ---
>> drivers/media/platform/qcom/camss/Makefile | 1 +
>> .../platform/qcom/camss/camss-csid-gen3.c | 445 ++++++++++++++++++
>> .../platform/qcom/camss/camss-csid-gen3.h | 26 +
>> .../media/platform/qcom/camss/camss-csid.h | 2 +
>> 4 files changed, 474 insertions(+)
>> create mode 100644 drivers/media/platform/qcom/camss/camss-csid-gen3.c
>> create mode 100644 drivers/media/platform/qcom/camss/camss-csid-gen3.h
>>
>> diff --git a/drivers/media/platform/qcom/camss/Makefile b/drivers/media/platform/qcom/camss/Makefile
>> index e636968a1126..c336e4c1a399 100644
>> --- a/drivers/media/platform/qcom/camss/Makefile
>> +++ b/drivers/media/platform/qcom/camss/Makefile
>> @@ -7,6 +7,7 @@ qcom-camss-objs += \
>> camss-csid-4-1.o \
>> camss-csid-4-7.o \
>> camss-csid-gen2.o \
>> + camss-csid-gen3.o \
>> camss-csiphy-2ph-1-0.o \
>> camss-csiphy-3ph-1-0.o \
>> camss-csiphy.o \
>> diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen3.c b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
>> new file mode 100644
>> index 000000000000..17fd7c5499de
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
>> @@ -0,0 +1,445 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * camss-csid-gen3.c
>> + *
>> + * Qualcomm MSM Camera Subsystem - CSID (CSI Decoder) Module
>> + *
>> + * Copyright (c) 2024 Qualcomm Technologies, Inc.
>> + */
>> +#include <linux/completion.h>
>> +#include <linux/delay.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/of.h>
>> +
>> +#include "camss.h"
>> +#include "camss-csid.h"
>> +#include "camss-csid-gen3.h"
>> +
>> +
>> +#define CSID_TOP_IO_PATH_CFG0(csid) (0x4 * (csid))
>> +#define OUTPUT_IFE_EN 0x100
>> +#define INTERNAL_CSID 1
>> +
>> +#define CSID_HW_VERSION 0x0
>> +#define HW_VERSION_STEPPING 0
>> +#define HW_VERSION_REVISION 16
>> +#define HW_VERSION_GENERATION 28
>> +
>> +#define CSID_RST_CFG 0xC
>> +#define RST_MODE 0
>> +#define RST_LOCATION 4
>> +
>> +#define CSID_RST_CMD 0x10
>> +#define SELECT_HW_RST 0
>> +#define SELECT_SW_RST 1
>> +#define SELECT_IRQ_RST 2
>> +
>> +#define CSID_CSI2_RX_IRQ_STATUS 0x9C
>> +#define CSID_CSI2_RX_IRQ_MASK 0xA0
>> +#define CSID_CSI2_RX_IRQ_CLEAR 0xA4
>> +#define CSID_CSI2_RX_IRQ_SET 0xA8
>> +
>> +#define CSID_CSI2_RDIN_IRQ_STATUS(rdi) (0xEC + 0x10 * (rdi))
>> +#define CSID_CSI2_RDIN_IRQ_MASK(rdi) (0xF0 + 0x10 * (rdi))
>> +#define CSID_CSI2_RDIN_INFO_FIFO_FULL 2
>
> That's a random set of indentations.
>
Thanks, will fixes this.
>> +#define CSID_CSI2_RDIN_INFO_CAMIF_EOF 3
>> +#define CSID_CSI2_RDIN_INFO_CAMIF_SOF 4
>> +#define CSID_CSI2_RDIN_INFO_INPUT_EOF 9
>> +#define CSID_CSI2_RDIN_INFO_INPUT_SOF 12
>
>
> ...
>
>> +
>> + writel_relaxed(val, csid->base + CSID_RDI_CFG0(vc));
>> +
>> + val = 1 << RDI_CFG1_PACKING_FORMAT;
>> + val |= 1 << RDI_CFG1_PIX_STORE;
>> + val |= 1 << RDI_CFG1_DROP_H_EN;
>> + val |= 1 << RDI_CFG1_DROP_V_EN;
>> + val |= 1 << RDI_CFG1_CROP_H_EN;
>> + val |= 1 << RDI_CFG1_CROP_V_EN;
>> + val |= RDI_CFG1_EARLY_EOF_EN;
>> +
>> + writel_relaxed(val, csid->base + CSID_RDI_CFG1(vc));
>> +
>> + val = 0;
>> + writel_relaxed(val, csid->base + CSID_RDI_IRQ_SUBSAMPLE_PERIOD(vc));
>> +
>> + val = 1;
>> + writel_relaxed(val, csid->base + CSID_RDI_IRQ_SUBSAMPLE_PATTERN(vc));
>> +
>> + val = 0;
>> + writel_relaxed(val, csid->base + CSID_RDI_CTRL(vc));
>> +
>> + val = readl_relaxed(csid->base + CSID_RDI_CFG0(vc));
>> + val |= enable << RDI_CFG0_EN;
>> + writel_relaxed(val, csid->base + CSID_RDI_CFG0(vc));
>> +}
>> +
>
> such patterns and...
>
>> + */
>> +static int csid_reset(struct csid_device *csid)
>> +{
>> + unsigned long time;
>> + u32 val;
>> + int i;
>> +
>> + reinit_completion(&csid->reset_complete);
>> +
>> + writel_relaxed(1, csid->base + CSID_TOP_IRQ_CLEAR);
>> + writel_relaxed(1, csid->base + CSID_IRQ_CMD);
>> + writel_relaxed(1, csid->base + CSID_TOP_IRQ_MASK);
>> +
>> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS; i++)
>> + if (csid->phy.en_vc & BIT(i)) {
>> + writel_relaxed(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
>> + csid->base + CSID_BUF_DONE_IRQ_CLEAR);
>> + writel_relaxed(0x1 << IRQ_CMD_CLEAR, csid->base + CSID_IRQ_CMD);
>> + writel_relaxed(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
>> + csid->base + CSID_BUF_DONE_IRQ_MASK);
>> + }
>> +
>> + /* preserve registers */
>> + val = (0x1 << RST_LOCATION) | (0x1 << RST_MODE);
>> + writel_relaxed(val, csid->base + CSID_RST_CFG);
>
> ... here - using everywhere relaxed here is odd and looks racy. These
> looks like some strict sequences.
>
Yes, these are some sequences to initialize the HW.
>
>> +
>> + val = (0x1 << SELECT_HW_RST) | (0x1 << SELECT_IRQ_RST);
>> + writel_relaxed(val, csid->base + CSID_RST_CMD);
>> +
>> + time = wait_for_completion_timeout(&csid->reset_complete,
>> + msecs_to_jiffies(CSID_RESET_TIMEOUT_MS));
>> + if (!time) {
>> + dev_err(csid->camss->dev, "CSID reset timeout\n");
>> + return -EIO;
>> + }
>> +
>
>
>> +
>> +static void csid_subdev_init(struct csid_device *csid)
>> +{
>> + csid->testgen.modes = csid_testgen_modes;
>> + csid->testgen.nmodes = CSID_PAYLOAD_MODE_NUM_SUPPORTED_GEN2;
>> +}
>> +
>> +const struct csid_hw_ops csid_ops_gen3 = {
>
> Isn't there a warning here?
>
>> + .configure_stream = csid_configure_stream,
>> + .configure_testgen_pattern = csid_configure_testgen_pattern,
>> + .hw_version = csid_hw_version,
>> + .isr = csid_isr,
>> + .reset = csid_reset,
>> + .src_pad_code = csid_src_pad_code,
>> + .subdev_init = csid_subdev_init,
>> +};
>
> Your patchset does not apply at all. Tried v6.9, v6.10, next. I see some
> dependency above, but that means no one can test it and no one can apply it.
>
> Fix the warnings, I cannot verify it but I am sure you have them.
>
My code base is next master branch, do you mean the 'declared and not
used' warning? I don't see this warning with below two version compiler
even though I just pick this patch and pull the code the latest version.
But it indeed have this issue, these structures are declared and will be
used later in "media: qcom: camss: Add sm8550 resources" patch, will
think about how to avoid this.
aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0
aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
---
CALL scripts/checksyscalls.sh
CC [M] drivers/media/platform/qcom/camss/camss-csid.o
CC [M] drivers/media/platform/qcom/camss/camss-csid-4-1.o
CC [M] drivers/media/platform/qcom/camss/camss-csid-4-7.o
CC [M] drivers/media/platform/qcom/camss/camss-csid-gen2.o
CC [M] drivers/media/platform/qcom/camss/camss-csid-gen3.o
CC [M] drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.o
CC [M] drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.o
---
89a4a25b7b56 (HEAD -> master) media: qcom: camss: Add CSID Gen3 support
for SM8550
d0cfd24496d3 media: qcom: camss: csiphy-3ph: Add Gen2 v1.2 two-phase
MIPI CSI-2 DPHY init
5795fd39a8ee dt-bindings: media: camss: Add qcom,sm8550-camss binding
> Best regards,
> Krzysztof
>
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550
2024-07-11 11:08 ` Depeng Shao
@ 2024-07-11 11:12 ` Krzysztof Kozlowski
2024-07-11 11:41 ` Depeng Shao
2024-07-31 15:26 ` Depeng Shao
0 siblings, 2 replies; 99+ messages in thread
From: Krzysztof Kozlowski @ 2024-07-11 11:12 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
On 11/07/2024 13:08, Depeng Shao wrote:
>>
>>> + */
>>> +static int csid_reset(struct csid_device *csid)
>>> +{
>>> + unsigned long time;
>>> + u32 val;
>>> + int i;
>>> +
>>> + reinit_completion(&csid->reset_complete);
>>> +
>>> + writel_relaxed(1, csid->base + CSID_TOP_IRQ_CLEAR);
>>> + writel_relaxed(1, csid->base + CSID_IRQ_CMD);
>>> + writel_relaxed(1, csid->base + CSID_TOP_IRQ_MASK);
>>> +
>>> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS; i++)
>>> + if (csid->phy.en_vc & BIT(i)) {
>>> + writel_relaxed(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
>>> + csid->base + CSID_BUF_DONE_IRQ_CLEAR);
>>> + writel_relaxed(0x1 << IRQ_CMD_CLEAR, csid->base + CSID_IRQ_CMD);
>>> + writel_relaxed(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
>>> + csid->base + CSID_BUF_DONE_IRQ_MASK);
>>> + }
>>> +
>>> + /* preserve registers */
>>> + val = (0x1 << RST_LOCATION) | (0x1 << RST_MODE);
>>> + writel_relaxed(val, csid->base + CSID_RST_CFG);
>>
>> ... here - using everywhere relaxed here is odd and looks racy. These
>> looks like some strict sequences.
>>
> Yes, these are some sequences to initialize the HW.
Hm? It's like you ignore the problem and just answer with whatever to
shut up the reviewer. Instead of replying with the same, address the
problem. Why ordering is not a problem here?
>
>>
>>> +
>>> + val = (0x1 << SELECT_HW_RST) | (0x1 << SELECT_IRQ_RST);
>>> + writel_relaxed(val, csid->base + CSID_RST_CMD);
>>> +
>>> + time = wait_for_completion_timeout(&csid->reset_complete,
>>> + msecs_to_jiffies(CSID_RESET_TIMEOUT_MS));
>>> + if (!time) {
>>> + dev_err(csid->camss->dev, "CSID reset timeout\n");
>>> + return -EIO;
>>> + }
>>> +
>>
>>
>>> +
>>> +static void csid_subdev_init(struct csid_device *csid)
>>> +{
>>> + csid->testgen.modes = csid_testgen_modes;
>>> + csid->testgen.nmodes = CSID_PAYLOAD_MODE_NUM_SUPPORTED_GEN2;
>>> +}
>>> +
>>> +const struct csid_hw_ops csid_ops_gen3 = {
>>
>> Isn't there a warning here?
>>
>>> + .configure_stream = csid_configure_stream,
>>> + .configure_testgen_pattern = csid_configure_testgen_pattern,
>>> + .hw_version = csid_hw_version,
>>> + .isr = csid_isr,
>>> + .reset = csid_reset,
>>> + .src_pad_code = csid_src_pad_code,
>>> + .subdev_init = csid_subdev_init,
>>> +};
>>
>> Your patchset does not apply at all. Tried v6.9, v6.10, next. I see some
>> dependency above, but that means no one can test it and no one can apply it.
>>
>> Fix the warnings, I cannot verify it but I am sure you have them.
>>
>
> My code base is next master branch, do you mean the 'declared and not
> used' warning? I don't see this warning with below two version compiler
> even though I just pick this patch and pull the code the latest version.
> But it indeed have this issue, these structures are declared and will be
> used later in "media: qcom: camss: Add sm8550 resources" patch, will
> think about how to avoid this.
>
> aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0
> aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
That's some old compilers... I am talking about recent GCC, recent clang
and of course W=1.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH V3 00/13] media: qcom: camss: Add sm8550 support
2024-07-10 12:30 ` Krzysztof Kozlowski
@ 2024-07-11 11:14 ` Depeng Shao
0 siblings, 0 replies; 99+ messages in thread
From: Depeng Shao @ 2024-07-11 11:14 UTC (permalink / raw)
To: Krzysztof Kozlowski, rfoss, todor.too, bryan.odonoghue, mchehab,
robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
Hi Krzysztof,
On 7/10/2024 8:30 PM, Krzysztof Kozlowski wrote:
> On 10/07/2024 13:27, Depeng Shao wrote:
>>
>>
>> On 7/10/2024 7:08 PM, Krzysztof Kozlowski wrote:
>>> On 09/07/2024 18:06, Depeng Shao wrote:
>>>> V3:
>>>> - Rebased the change based on below change which will be merged firstly.
>>>> "Move camss version related defs in to resources"
>>>> Link: https://lore.kernel.org/all/20240522154659.510-1-quic_grosikop@quicinc.com/
>>>> - Rebased the change based on Bryan's csiphy optimization change and add
>>>> these changes into this series, so that the new csiphy-3ph driver don't
>>>> need to add duplicate code. This has got Bryan's permission to add his
>>>> patches into this series.
>>>> - Refactor some changes based on the comments to move the random code to
>>>> patches where they are used.
>>>> - Remove the vfe780 irq function since it isn't doing the actual work.
>>>> - Add dt-binding for sm8550 camss driver.
>>>> Link to V2: https://lore.kernel.org/all/20240320141136.26827-1-quic_depengs@quicinc.com/
>>>
>>> I asked for reference to upstream DTS - where can I find the DTS patches?
>>>
>>> Best regards,
>>> Krzysztof
>>>
>>
>> Hi Krzysztof,
>>
>> Sorry for that, I thought add the dt-binding is also fine, since I saw
>> other patches also do like this. Will add add the DTS in next patch set.
>
> DTS should not be part of this patchset, but sent separately. It's
> enough if you post a lore link to it.
>
Thanks for the explanation, I will post the link in new version series.
> Best regards,
> Krzysztof
>
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550
2024-07-11 11:12 ` Krzysztof Kozlowski
@ 2024-07-11 11:41 ` Depeng Shao
2024-07-11 12:00 ` Bryan O'Donoghue
2024-07-31 15:26 ` Depeng Shao
1 sibling, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-07-11 11:41 UTC (permalink / raw)
To: Krzysztof Kozlowski, rfoss, todor.too, bryan.odonoghue, mchehab,
robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
Hi Krzysztof,
On 7/11/2024 7:12 PM, Krzysztof Kozlowski wrote:
> On 11/07/2024 13:08, Depeng Shao wrote:
>
>
>>>
>>>> + */
>>>> +static int csid_reset(struct csid_device *csid)
>>>> +{
>>>> + unsigned long time;
>>>> + u32 val;
>>>> + int i;
>>>> +
>>>> + reinit_completion(&csid->reset_complete);
>>>> +
>>>> + writel_relaxed(1, csid->base + CSID_TOP_IRQ_CLEAR);
>>>> + writel_relaxed(1, csid->base + CSID_IRQ_CMD);
>>>> + writel_relaxed(1, csid->base + CSID_TOP_IRQ_MASK);
>>>> +
>>>> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS; i++)
>>>> + if (csid->phy.en_vc & BIT(i)) {
>>>> + writel_relaxed(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
>>>> + csid->base + CSID_BUF_DONE_IRQ_CLEAR);
>>>> + writel_relaxed(0x1 << IRQ_CMD_CLEAR, csid->base + CSID_IRQ_CMD);
>>>> + writel_relaxed(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
>>>> + csid->base + CSID_BUF_DONE_IRQ_MASK);
>>>> + }
>>>> +
>>>> + /* preserve registers */
>>>> + val = (0x1 << RST_LOCATION) | (0x1 << RST_MODE);
>>>> + writel_relaxed(val, csid->base + CSID_RST_CFG);
>>>
>>> ... here - using everywhere relaxed here is odd and looks racy. These
>>> looks like some strict sequences.
>>>
>> Yes, these are some sequences to initialize the HW.
>
> Hm? It's like you ignore the problem and just answer with whatever to
> shut up the reviewer. Instead of replying with the same, address the
> problem. Why ordering is not a problem here?
>
Sorry, I didn't mean that, was trying to understand the problem, then
just sent out the mail by mistake.
Do you mean we should use writel to ensure the strict sequences?
Thanks for catching this problem, this problem is also in the the
existing camss driver. I will check all of them in this series, but the
problem in some existing camss drivers, maybe Bryan from Linaro can help
to fix them, since I don't have these devices to verify the modifications.
>>>> +
>>>> +const struct csid_hw_ops csid_ops_gen3 = {
>>>
>>> Isn't there a warning here?
>>>
>>>> + .configure_stream = csid_configure_stream,
>>>> + .configure_testgen_pattern = csid_configure_testgen_pattern,
>>>> + .hw_version = csid_hw_version,
>>>> + .isr = csid_isr,
>>>> + .reset = csid_reset,
>>>> + .src_pad_code = csid_src_pad_code,
>>>> + .subdev_init = csid_subdev_init,
>>>> +};
>>>
>>> Your patchset does not apply at all. Tried v6.9, v6.10, next. I see some
>>> dependency above, but that means no one can test it and no one can apply it.
>>>
>>> Fix the warnings, I cannot verify it but I am sure you have them.
>>>
>>
>> My code base is next master branch, do you mean the 'declared and not
>> used' warning? I don't see this warning with below two version compiler
>> even though I just pick this patch and pull the code the latest version.
>> But it indeed have this issue, these structures are declared and will be
>> used later in "media: qcom: camss: Add sm8550 resources" patch, will
>> think about how to avoid this.
>>
>> aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0
>> aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
>
> That's some old compilers... I am talking about recent GCC, recent clang
> and of course W=1.
>
Thanks for the sharing, I will try to upgrade to latest compiler to
avoid other potential issues.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 11/13] media: qcom: camss: Add notify interface in camss driver
2024-07-10 11:54 ` Bryan O'Donoghue
@ 2024-07-11 11:54 ` Depeng Shao
0 siblings, 0 replies; 99+ messages in thread
From: Depeng Shao @ 2024-07-11 11:54 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
Hi Bryan,
On 7/10/2024 7:54 PM, Bryan O'Donoghue wrote:
> On 09/07/2024 17:06, Depeng Shao wrote:
>> The main v4l2 process logic in camss vfe subdev driver, so the vfe driver
>> handles the buf done irq and register update configuration. But the buf
>> done irq and register update configuration have been moved CSID HW in
>> Titan 780 and other new platform, so vfe driver needs to call into CSID
>> driver to configure the register update. And CSID driver also needs to
>> call into vfe driver to notify of the buf done irq.
>>
>> Adding this notify interface in camss structure to do the subdevs cross
>> /*
>> * csid_isr - CSID module interrupt service routine
>> * @irq: Interrupt line
>> @@ -341,6 +353,14 @@ static irqreturn_t csid_isr(int irq, void *dev)
>> if (csid->phy.en_vc & BIT(i)) {
>> val = readl_relaxed(csid->base +
>> CSID_CSI2_RDIN_IRQ_STATUS(i));
>> writel_relaxed(val, csid->base +
>> CSID_CSI2_RDIN_IRQ_CLEAR(i));
>> +
>> + if (buf_done_val & BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET +
>> i)) {
>> + /* For Titan 780, Buf Done IRQ® has been moved to
>> CSID from VFE.
>> + * Once CSID received Buf Done, need notify this
>> event to VFE.
>> + * Trigger VFE to handle Buf Done process.
>> + */
>> + csid->camss->notify(&csid->subdev,
>> CAMSS_MSG_BUF_DONE, (void *)&i);
>
> Instead of a generic notify function with an enum passed to a switch
> lets just have a dedicated function for each functional callback.
>
> csid->camss->reg_update_cmd();
> csid->camss->reg_clear_cmd();
>
> We can get rid of a switch and an additional enum that way, plus
> redundant "event not supported" error checking.
>
Sure, will update the code based on suggestion.
>> + }
>> }
>> val = 1 << IRQ_CMD_CLEAR;
>> @@ -434,6 +454,23 @@ static void csid_subdev_init(struct csid_device
>> *csid)
>> csid->testgen.nmodes = CSID_PAYLOAD_MODE_NUM_SUPPORTED_GEN2;
>> }
>> +static void csid_subdev_process_msg(struct csid_device *csid,
>> unsigned int msg_type, void *arg)
>> +{
>> + int msg_data = *(int *)arg;
>> +
>> + switch (msg_type) {
>> + case CAMSS_MSG_RUP:
>> + csid_reg_update(csid, msg_data);
>> + break;
>> + case CAMSS_MSG_RUP_CLEAR:
>> + csid_reg_update_clear(csid, msg_data);
>> + break;
>> + default:
>> + dev_err(csid->camss->dev, "NOT Supported EVT Type\n");
>> + break;
>> + }
>> +}
>> +
>> const struct csid_hw_ops csid_ops_gen3 = {
>> .configure_stream = csid_configure_stream,
>> .configure_testgen_pattern = csid_configure_testgen_pattern,
>> @@ -442,4 +479,5 @@ const struct csid_hw_ops csid_ops_gen3 = {
>> .reset = csid_reset,
>> .src_pad_code = csid_src_pad_code,
>> .subdev_init = csid_subdev_init,
>> + .process_msg = csid_subdev_process_msg,
>> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.h
>> b/drivers/media/platform/qcom/camss/camss-vfe.h
>> index 10e2cc3c0b83..a8b09ce9941b 100644
>> --- a/drivers/media/platform/qcom/camss/camss-vfe.h
>> +++ b/drivers/media/platform/qcom/camss/camss-vfe.h
>> @@ -115,6 +115,7 @@ struct vfe_hw_ops {
>> int (*vfe_halt)(struct vfe_device *vfe);
>> void (*violation_read)(struct vfe_device *vfe);
>> void (*vfe_wm_stop)(struct vfe_device *vfe, u8 wm);
>> + void (*process_msg)(struct vfe_device *vfe, unsigned int
>> msg_type, void *arg);
>> };
>> struct vfe_isr_ops {
>> diff --git a/drivers/media/platform/qcom/camss/camss.c
>> b/drivers/media/platform/qcom/camss/camss.c
>> index 1f1f44f6fbb2..abeb0918e47d 100644
>> --- a/drivers/media/platform/qcom/camss/camss.c
>> +++ b/drivers/media/platform/qcom/camss/camss.c
>> @@ -2202,6 +2202,52 @@ static void camss_genpd_cleanup(struct camss
>> *camss)
>> dev_pm_domain_detach(camss->genpd, true);
>> }
>> +static void camss_notify_msg(struct v4l2_subdev *sd,
>> + unsigned int msg_type, void *arg)
>> +{
>> + struct v4l2_device *v4l2_dev = sd->v4l2_dev;
>> + struct camss *camss = to_camss(v4l2_dev);
>> + struct vfe_device *vfe;
>> + struct vfe_line *vfe_line;
>> + struct csid_device *csid;
>> + int evt_data = *(int *)arg;
>> +
>> + switch (msg_type) {
>> + case CAMSS_MSG_BUF_DONE:
>> + csid = v4l2_get_subdevdata(sd);
>> + vfe = &(camss->vfe[csid->id]);
>> + if (vfe->res->hw_ops->process_msg)
>> + vfe->res->hw_ops->process_msg(vfe,
>> + CAMSS_MSG_BUF_DONE, (void *)&evt_data);
>> + break;
>> +
>> + case CAMSS_MSG_RUP:
>> + vfe_line = v4l2_get_subdevdata(sd);
>> + vfe = to_vfe(vfe_line);
>> + csid = &(camss->csid[vfe->id]);
>> +
>> + if (csid->res->hw_ops->process_msg)
>> + csid->res->hw_ops->process_msg(csid,
>> + CAMSS_MSG_RUP, (void *)&evt_data);
>> + break;
>> +
>> + case CAMSS_MSG_RUP_CLEAR:
>> + vfe_line = v4l2_get_subdevdata(sd);
>> + vfe = to_vfe(vfe_line);
>> + csid = &(camss->csid[vfe->id]);
>> +
>> + if (csid->res->hw_ops->process_msg)
>> + csid->res->hw_ops->process_msg(csid,
>> + CAMSS_MSG_RUP_CLEAR, (void *)&evt_data);
>> +
>> + break;
>> +
>> + default:
>> + dev_err(camss->dev, "Not supported evt type\n");
>> + break;
>> + }
>> +}
>
> Instead of having a central swiss army knife notify() callback these
> should be CSID or VFE specific callbacks vfe->buf_done() csid->msg_rup()
> etc.
>
I will try to add the callback in CSID and VFE driver.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550
2024-07-11 11:41 ` Depeng Shao
@ 2024-07-11 12:00 ` Bryan O'Donoghue
2024-07-11 12:14 ` Depeng Shao
2024-07-11 12:17 ` Krzysztof Kozlowski
0 siblings, 2 replies; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-07-11 12:00 UTC (permalink / raw)
To: Depeng Shao, Krzysztof Kozlowski, rfoss, todor.too, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
On 11/07/2024 12:41, Depeng Shao wrote:
>>> Yes, these are some sequences to initialize the HW.
>>
>> Hm? It's like you ignore the problem and just answer with whatever to
>> shut up the reviewer. Instead of replying with the same, address the
>> problem. Why ordering is not a problem here?
>>
>
> Sorry, I didn't mean that, was trying to understand the problem, then
> just sent out the mail by mistake.
> Do you mean we should use writel to ensure the strict sequences?
> Thanks for catching this problem, this problem is also in the the
> existing camss driver. I will check all of them in this series, but the
> problem in some existing camss drivers, maybe Bryan from Linaro can help
> to fix them, since I don't have these devices to verify the modifications.
_relaxed is used I'm sure because that's what's always been used and
what downstream does.
Is there a good reason for it ? None that I can think of.
Krzysztof is right, there's no good reason to use relaxed() here at all,
you should drop it.
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550
2024-07-11 12:00 ` Bryan O'Donoghue
@ 2024-07-11 12:14 ` Depeng Shao
2024-07-11 12:17 ` Krzysztof Kozlowski
1 sibling, 0 replies; 99+ messages in thread
From: Depeng Shao @ 2024-07-11 12:14 UTC (permalink / raw)
To: Bryan O'Donoghue, Krzysztof Kozlowski, rfoss, todor.too,
mchehab, robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
Hi Bryan,
On 7/11/2024 8:00 PM, Bryan O'Donoghue wrote:
> On 11/07/2024 12:41, Depeng Shao wrote:
>>>> Yes, these are some sequences to initialize the HW.
>>>
>>> Hm? It's like you ignore the problem and just answer with whatever to
>>> shut up the reviewer. Instead of replying with the same, address the
>>> problem. Why ordering is not a problem here?
>>>
>>
>> Sorry, I didn't mean that, was trying to understand the problem, then
>> just sent out the mail by mistake.
>> Do you mean we should use writel to ensure the strict sequences?
>> Thanks for catching this problem, this problem is also in the the
>> existing camss driver. I will check all of them in this series, but
>> the problem in some existing camss drivers, maybe Bryan from Linaro
>> can help to fix them, since I don't have these devices to verify the
>> modifications.
>
> _relaxed is used I'm sure because that's what's always been used and
> what downstream does.
>
> Is there a good reason for it ? None that I can think of.
>
> Krzysztof is right, there's no good reason to use relaxed() here at all,
> you should drop it.
>
> ---
> bod
Sure, I will drop the _relaxed.
Most io_write don't use _relaxed in the Qualcomm downstream camera
driver, but few strict timing required code really have this problem, I
will fix them.
Thanks for highlight it.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550
2024-07-11 12:00 ` Bryan O'Donoghue
2024-07-11 12:14 ` Depeng Shao
@ 2024-07-11 12:17 ` Krzysztof Kozlowski
1 sibling, 0 replies; 99+ messages in thread
From: Krzysztof Kozlowski @ 2024-07-11 12:17 UTC (permalink / raw)
To: Bryan O'Donoghue, Depeng Shao, rfoss, todor.too, mchehab,
robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
On 11/07/2024 14:00, Bryan O'Donoghue wrote:
> On 11/07/2024 12:41, Depeng Shao wrote:
>>>> Yes, these are some sequences to initialize the HW.
>>>
>>> Hm? It's like you ignore the problem and just answer with whatever to
>>> shut up the reviewer. Instead of replying with the same, address the
>>> problem. Why ordering is not a problem here?
>>>
>>
>> Sorry, I didn't mean that, was trying to understand the problem, then
>> just sent out the mail by mistake.
>> Do you mean we should use writel to ensure the strict sequences?
>> Thanks for catching this problem, this problem is also in the the
>> existing camss driver. I will check all of them in this series, but the
>> problem in some existing camss drivers, maybe Bryan from Linaro can help
>> to fix them, since I don't have these devices to verify the modifications.
>
> _relaxed is used I'm sure because that's what's always been used and
> what downstream does.
>
> Is there a good reason for it ? None that I can think of.
>
> Krzysztof is right, there's no good reason to use relaxed() here at all,
> you should drop it.
>
In many cases relaxed will be fine, but in few might lead to tricky to
debug issues thus people introducing msleep() or other workarounds.
Usually init sequences are "sequences" for a reason, but of course here
maybe it does not matter.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 10/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-07-10 11:47 ` Bryan O'Donoghue
@ 2024-07-11 13:29 ` Depeng Shao
0 siblings, 0 replies; 99+ messages in thread
From: Depeng Shao @ 2024-07-11 13:29 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
Hi Bryan,
On 7/10/2024 7:47 PM, Bryan O'Donoghue wrote:
> On 09/07/2024 17:06, Depeng Shao wrote:
>> Add support for VFE found on SM8550 (Titan 780). This implementation is
>> based on the titan 480 implementation. It supports the normal and lite
>> VFE.
>>
>> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
>> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
>> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
>> ---
>> drivers/media/platform/qcom/camss/Makefile | 1 +
>> .../media/platform/qcom/camss/camss-vfe-780.c | 404 ++++++++++++++++++
>> 2 files changed, 405 insertions(+)
>> create mode 100644 drivers/media/platform/qcom/camss/camss-vfe-780.c
>>
>> diff --git a/drivers/media/platform/qcom/camss/Makefile
>> b/drivers/media/platform/qcom/camss/Makefile
>> index c336e4c1a399..a83b7a8dcef7 100644
>> --- a/drivers/media/platform/qcom/camss/Makefile
>> +++ b/drivers/media/platform/qcom/camss/Makefile
>> @@ -17,6 +17,7 @@ qcom-camss-objs += \
>> camss-vfe-4-8.o \
>> camss-vfe-17x.o \
>> camss-vfe-480.o \
>> + camss-vfe-780.o \
>> camss-vfe-gen1.o \
>> camss-vfe.o \
>> camss-video.o \
>> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-780.c
>> b/drivers/media/platform/qcom/camss/camss-vfe-780.c
>> new file mode 100644
>> index 000000000000..abef2d5b9c2e
>> --- /dev/null
>> +++ b/drivers/media/platform/qcom/camss/camss-vfe-780.c
>> @@ -0,0 +1,404 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * camss-vfe-780.c
>> +
>> +static u32 vfe_hw_version(struct vfe_device *vfe)
>> +{
>> + u32 hw_version = readl_relaxed(vfe->base + VFE_HW_VERSION);
>> +
>> + u32 gen = (hw_version >> 28) & 0xF;
>> + u32 rev = (hw_version >> 16) & 0xFFF;
>> + u32 step = hw_version & 0xFFFF;
>> +
>> + dev_info(vfe->camss->dev, "VFE HW Version = %u.%u.%u\n", gen,
>> rev, step);
>> +
>> + return hw_version;
>> +}
>
> This could be functionally decomposed into vfe_hw_version_v2() or
> similar and exported by camss-vfe.c
>
>> +
Yes, same with below comments, I will try to figure out which functions
can be moved to common files.
>> +
>> +/*
>> + * vfe_isr - VFE module interrupt handler
>> + * @irq: Interrupt line
>> + * @dev: VFE device
>> + *
>> + * Return IRQ_HANDLED on success
>> + */
>> +static irqreturn_t vfe_isr(int irq, void *dev)
>> +{
>> + /* Buf Done has beem moved to CSID in Titan 780.
>> + * Disable VFE related IRQ.
>> + * Clear the contents of this function.
>> + * Return IRQ_HANDLED.
>> + */
>> + return IRQ_HANDLED;
>> +}
>
> What's the point of this ISR at all if it never fires and just returns
> done ?
>
> Since it takes no action - it can't do anything useful and therefore if
> it ever did fire, would fire ad infinitum.
>
> Please drop
Sure, will drop it.
>> +
>> +static int vfe_get_output(struct vfe_line *line)
>> +{
>> + struct vfe_device *vfe = to_vfe(line);
>> + struct vfe_output *output;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&vfe->output_lock, flags);
>> +
>> + output = &line->output;
>> + if (output->state > VFE_OUTPUT_RESERVED) {
>> + dev_err(vfe->camss->dev, "Output is running\n");
>> + goto error;
>> + }
>> +
>> + output->wm_num = 1;
>> +
>> + /* Correspondence between VFE line number and WM number.
>> + * line 0 -> RDI 0, line 1 -> RDI1, line 2 -> RDI2, line 3 ->
>> PIX/RDI3
>> + * Note this 1:1 mapping will not work for PIX streams.
>> + */
>> + output->wm_idx[0] = line->id;
>> + vfe->wm_output_map[line->id] = line->id;
>> +
>> + output->drop_update_idx = 0;
>> +
>> + spin_unlock_irqrestore(&vfe->output_lock, flags);
>> +
>> + return 0;
>> +
>> +error:
>> + spin_unlock_irqrestore(&vfe->output_lock, flags);
>> + output->state = VFE_OUTPUT_OFF;
>> +
>> + return -EINVAL;
>> +}
>
> This is copy/paste from vfe480 and should be functionally decomposed
> into a common function in camss-vfe.
Sure, the flow of some functions are same with other platform, and don't
read/write registers, this can be moved to a common file and reused by
all platform.
I will think about this.
>> +
>> +static int vfe_enable_output(struct vfe_line *line)
>> +{
>> + struct vfe_device *vfe = to_vfe(line);
>> + struct vfe_output *output = &line->output;
>> + unsigned long flags;
>> + unsigned int i;
>> +
>> + spin_lock_irqsave(&vfe->output_lock, flags);
>> +
>> + vfe_reg_update_clear(vfe, line->id);
>> +
>> + if (output->state > VFE_OUTPUT_RESERVED) {
>> + dev_err(vfe->camss->dev, "Output is not in reserved state %d\n",
>> + output->state);
>> + spin_unlock_irqrestore(&vfe->output_lock, flags);
>> + return -EINVAL;
>> + }
>> +
>> + WARN_ON(output->gen2.active_num);
>> +
>> + output->state = VFE_OUTPUT_ON;
>> +
>> + output->sequence = 0;
>> +
>> + vfe_wm_start(vfe, output->wm_idx[0], line);
>> +
>> + for (i = 0; i < MAX_VFE_ACT_BUF; i++) {
>> + output->buf[i] = vfe_buf_get_pending(output);
>> + if (!output->buf[i])
>> + break;
>> + output->gen2.active_num++;
>> + vfe_wm_update(vfe, output->wm_idx[0],
>> output->buf[i]->addr[0], line);
>> +
>> + vfe_reg_update(vfe, line->id);
>
> I see this differs from vfe480 in that vfe_reg_update(vfe, line-id); is
> done on each iteration of this loop whereas in 480 it is done directly
> after the loop, seems to me this would be a valid fix for 480 too
> leading to my next comment
>
Yes, vfe-480 also need this.
>> + }
>> +
>> + spin_unlock_irqrestore(&vfe->output_lock, flags);
>> +
>> + return 0;
>> +}
>
> This function is so similar across different SoCs with very minor
> differences that instead of copy/pasting and very slightly tweaking, we
> should be functionally decomposing and using a flag of some kind to
> differentaite between wait_reg_update logic in 480 and not in 780.
>
> Again I think we should functionally decompose into camss-vfe.c and use
> a flag to branch the logic for the very slight logical difference
> between the two
>
> vfe-480.c
>
> output->sequence = 0;
> output->wait_reg_update = 0;
> reinit_completion(&output->reg_update);
>
> As a result your fix for line->id would be useful across SoCs instead of
> isolated to vfe 780.
>
Yes, some functions are same code flow, and don't read/write register,
this can be moved to a common file and reused by all platform.
I will think about this.
>> +
>> +/*
>> + * vfe_enable - Enable streaming on VFE line
>> + * @line: VFE line
>> + *
>> + * Return 0 on success or a negative error code otherwise
>> + */
>> +static int vfe_enable(struct vfe_line *line)
>> +{
>> + struct vfe_device *vfe = to_vfe(line);
>> + int ret;
>> +
>> + mutex_lock(&vfe->stream_lock);
>> +
>> + vfe->stream_count++;
>> +
>> + mutex_unlock(&vfe->stream_lock);
>> +
>> + ret = vfe_get_output(line);
>> + if (ret < 0)
>> + goto error_get_output;
>> +
>> + ret = vfe_enable_output(line);
>> + if (ret < 0)
>> + goto error_enable_output;
>> +
>> + vfe->was_streaming = 1;
>> +
>> + return 0;
>> +
>> +error_enable_output:
>> + vfe_put_output(line);
>> +
>> +error_get_output:
>> + mutex_lock(&vfe->stream_lock);
>> +
>> + vfe->stream_count--;
>> +
>> + mutex_unlock(&vfe->stream_lock);
>> +
>> + return ret;
>> +}
>
> Same thesis on functional decomposition - this should be moved to
> camss-vfe.c and made common - its only a minor difference betwen the
> required logic on different SoCs so there's not a compelling reason to
> have largely identical functions living in difference .c files in the
> same driver.
>
Sure, I will check which functions can be moved to camss-vfe.c.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 12/13] media: qcom: camss: Add sm8550 support
2024-07-10 12:02 ` Bryan O'Donoghue
@ 2024-07-11 14:36 ` Depeng Shao
0 siblings, 0 replies; 99+ messages in thread
From: Depeng Shao @ 2024-07-11 14:36 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
Hi Bryan,
On 7/10/2024 8:02 PM, Bryan O'Donoghue wrote:
> On 09/07/2024 17:06, Depeng Shao wrote:
>>
>> diff --git a/drivers/media/platform/qcom/camss/camss-csid.c
>> b/drivers/media/platform/qcom/camss/camss-csid.c
>> index 858db5d4ca75..90fba25db4c6 100644
>> --- a/drivers/media/platform/qcom/camss/camss-csid.c
>> +++ b/drivers/media/platform/qcom/camss/camss-csid.c
>> @@ -1013,6 +1013,7 @@ int msm_csid_subdev_init(struct camss *camss,
>> struct csid_device *csid,
>> {
>> struct device *dev = camss->dev;
>> struct platform_device *pdev = to_platform_device(dev);
>> + struct resource *top_res;
>> int i, j;
>> int ret;
>> @@ -1040,6 +1041,26 @@ int msm_csid_subdev_init(struct camss *camss,
>> struct csid_device *csid,
>> else
>> csid->base =
>> csid->res->parent_dev_ops->get_base_address(camss, id)
>> + VFE_480_CSID_OFFSET;
>> + } else if (camss->res->version == CAMSS_8550) {
>> + /* for titan 780, CSID lite registers are inside the VFE lite
>> region,
>> + * between the VFE "top" and "bus" registers. this requires
>> + * VFE to be initialized before CSID
>> + */
>> + if (csid_is_lite(csid))
>> + csid->base =
>> csid->res->parent_dev_ops->get_base_address(camss, id);
>> + else {
>> + csid->base = devm_platform_ioremap_resource_byname(pdev,
>> res->reg[0]);
>> + /* CSID "top" is a new function in Titan780.
>> + * CSID can connect to VFE & SFE(Sensor Front End).
>> + * This connection is ontrolled by CSID "top" registers.
>> + * CSID "top" registers at only one region.
>> + */
>> + top_res = platform_get_resource_byname(pdev,
>> IORESOURCE_MEM, res->reg[1]);
>> + csid->top_base = ioremap(top_res->start,
>> resource_size(top_res));
>> + }
>
> If we just specify the csid lite regs in the dts, we don't need custom
> code to get a pointer to them.
>
Yes, we can get the csid lite reg directly, will update this part.
> Similarly the csid->top_base = () should be generic not SoC specific,
> i.e. we should be able to add in CSID 980 without adding any custom code
> to camss-csid.c
>
csid lite doesn't have top reg block, but you are right, this can be
generic, we can get csid->top_base if res->reg[1] isn't NULL.
>> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c
>> b/drivers/media/platform/qcom/camss/camss-vfe.c
>> index 83c5a36d071f..479474c1cd95 100644
>> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
>> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
>> @@ -338,6 +338,7 @@ static u32 vfe_src_pad_code(struct vfe_line *line,
>> u32 sink_code,
>> case CAMSS_845:
>> case CAMSS_8250:
>> case CAMSS_8280XP:
>> + case CAMSS_8550:
>> switch (sink_code) {
>> case MEDIA_BUS_FMT_YUYV8_1X16:
>> {
>> @@ -408,6 +409,10 @@ int vfe_reset(struct vfe_device *vfe)
>> reinit_completion(&vfe->reset_complete);
>> + /* The reset has been moved to csid in 8550 */
>> + if (vfe->camss->res->version == CAMSS_8550)
>> + return 0;
>> +
>
> Custom code for a specific SoC in camss.c camss-csid.c or camss-vfe.c
> indicates to me we need to do more work elsewhere.
>
> This would do the same job for you.
>
> static void vfe_global_reset(struct vfe_device *vfe)
> {
> /* VFE780 has no global reset, simply report a completion */
> complete(&vfe->reset_complete);
> }
>
> const struct vfe_hw_ops vfe_ops_780 = {
> .global_reset = vfe_global_reset,
>
>> vfe->res->hw_ops->global_reset(vfe);
>> time = wait_for_completion_timeout(&vfe->reset_complete
Sure, I will optimize this part.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550
2024-07-10 11:28 ` Bryan O'Donoghue
@ 2024-07-11 15:33 ` Depeng Shao
2024-08-07 15:10 ` Depeng Shao
0 siblings, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-07-11 15:33 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
Hi Bryan,
On 7/10/2024 7:28 PM, Bryan O'Donoghue wrote:
> On 09/07/2024 17:06, Depeng Shao wrote:
>> The CSID in SM8550 is gen3, it has new register offset and new
>> functionality. The buf done irq,register update and reset are
>> moved to CSID gen3. And CSID gen3 has a new register block which
>> is named as CSID top, it controls the output of CSID, since the
>> CSID can connect to Sensor Front End (SFE) or original VFE, the
>> register in top block is used to control the HW connection.
>>
>> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
>> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
>> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
>> ---
>> drivers/media/platform/qcom/camss/Makefile | 1 +
>> .../platform/qcom/camss/camss-csid-gen3.c | 445 ++++++++++++++++++
>> .../platform/qcom/camss/camss-csid-gen3.h | 26 +
>> .../media/platform/qcom/camss/camss-csid.h | 2 +
>> 4 files changed, 474 insertions(+)
>> create mode 100644 drivers/media/platform/qcom/camss/camss-csid-gen3.c
>> create mode 100644 drivers/media/platform/qcom/camss/camss-csid-gen3.h
>>
>> +
>> +#define REG_UPDATE_RDI reg_update_rdi
>> +
>> +static void __csid_configure_rx(struct csid_device *csid,
>> + struct csid_phy_config *phy, int vc)
>> +{
>> + int val;
>> +
>> + val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
>> + val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
>> + val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX) <<
>> CSI2_RX_CFG0_PHY_NUM_SEL;
>> +
>> + writel_relaxed(val, csid->base + CSID_CSI2_RX_CFG0);
>> +
>> + val = 1 << CSI2_RX_CFG1_PACKET_ECC_CORRECTION_EN;
>> + if (vc > 3)
>> + val |= 1 << CSI2_RX_CFG1_VC_MODE;
>
> I realise downstream does these shifts but, I think in upstream we
> should just define a BIT(x)
>
> #define CSI2_RX_CFG1_VC_MODE BIT(2)
>
> val |= CSI2_RX_CFG1_VC_MODE;
>
Here CSI2_RX_CFG1_VC_MODE just means a register bit offset, not a
register configuration.
Some fixed configuration can do this, but some register bits value are
configured based on actual parameter.
e.g.; val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
If we want to use macro definition, maybe we can do like below.
#define CSI2_RX_CFG1_VC_MODE(n) ((n) << 2)
val |= CSI2_RX_CFG1_VC_MODE(1);
#define CSI2_RX_CFG0_DL0_INPUT_SEL(n) ((n) << 4)
val |= CSI2_RX_CFG0_DL0_INPUT_SEL(phy->lane_assign)
Could you please comment if we really need to do like this?
>> + writel_relaxed(val, csid->base + CSID_CSI2_RX_CFG1);
>> +}
>> +
>> +static void __csid_ctrl_rdi(struct csid_device *csid, int enable, u8
>> rdi)
>> +{
>> + int val;
>> +
>> + if (enable)
>> + val = 1 << RDI_CTRL_START_CMD;
>> + else
>> + val = 0 << RDI_CTRL_START_CMD;
>
> Here is an example of how the bit shifting is weird
>
> (0 << anything) is still zero
>
Understood, the value is same, but we can know the configuration clearly
on this register bit. If we do like above way, then it likes below.
#define RDI_CTRL_START_CMD(n) ((n) << 0) --> it is same with (n), but
we don't know the register bit offset clearly if we use (n).
if (enable)
val = RDI_CTRL_START_CMD(1);
else
val = RDI_CTRL_START_CMD(0);
>> + writel_relaxed(val, csid->base + CSID_RDI_CTRL(rdi));
>> +}
>> +
>> +static void __csid_configure_top(struct csid_device *csid)
>> +{
>> + u32 val;
>> +
>> + /* CSID "top" is a new function in Titan780.
>> + * CSID can connect to VFE & SFE(Sensor Front End).
>> + * This connection is ontrolled by CSID "top".
>> + * Only enable VFE path in current driver.
>> + */
>> + if (csid->top_base) {
>
> When is csid->top_base NULL ?
>
> Its required in your yaml.
>
csid->top_base is NULL when it is csid lite, I will add this info in yaml.
>> +
>> +static void csid_configure_stream(struct csid_device *csid, u8 enable)
>> +{
>> + u8 i;
>> +
>> + /* Loop through all enabled VCs and configure stream for each */
>> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS; i++)
>> + if (csid->phy.en_vc & BIT(i)) {
>> + /* Configure CSID "top" */
>> + __csid_configure_top(csid);
>> + __csid_configure_rdi_stream(csid, enable, i);
>> + __csid_configure_rx(csid, &csid->phy, i);
>> + __csid_ctrl_rdi(csid, enable, i);
>> + }
>> +}
>
> I really like this breakdown
Sorry, I don't get it, do you mean you like that configuring the
different block use different functions, and no other meaning?
>> +
>> +static int csid_configure_testgen_pattern(struct csid_device *csid,
>> s32 val)
>> +{
>> + if (val > 0 && val <= csid->testgen.nmodes)
>> + csid->testgen.mode = val;
>
> Surely you should just set the val parameter directly ?
>
> Also why is this a signed integer and how does it get assigned a
> negative value which we need to mitigate against here >
This was copied from csid-gen2 driver, they are same, so we can move to
common file.
And the val comes from ctrl->val, so I guess this is the reason why this
agrument is signed integer.
struct v4l2_ctrl {
...
s32 val;
...
};
>> +
>> +static u32 csid_src_pad_code(struct csid_device *csid, u32 sink_code,
>> + unsigned int match_format_idx, u32 match_code)
>> +{
>> + switch (sink_code) {
>> + case MEDIA_BUS_FMT_SBGGR10_1X10:
>> + {
>> + u32 src_code[] = {
>> + MEDIA_BUS_FMT_SBGGR10_1X10,
>> + MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_LE,
>> + };
>> +
>> + return csid_find_code(src_code, ARRAY_SIZE(src_code),
>> + match_format_idx, match_code);
>> + }
>> + case MEDIA_BUS_FMT_Y10_1X10:
>> + {
>> + u32 src_code[] = {
>> + MEDIA_BUS_FMT_Y10_1X10,
>> + MEDIA_BUS_FMT_Y10_2X8_PADHI_LE,
>> + };
>> +
>> + return csid_find_code(src_code, ARRAY_SIZE(src_code),
>> + match_format_idx, match_code);
>> + }
>> + default:
>> + if (match_format_idx > 0)
>> + return 0;
>> +
>> + return sink_code;
>> + }
>> +}
>
> Same code as in gen2.
>
> You could move the gen2 version of this into camss-csid.c and just reuse
> in both.
>
Sure, it is same with the comments in vfe driver, I will try to move
same code to camss-csid.c
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550
2024-07-11 11:12 ` Krzysztof Kozlowski
2024-07-11 11:41 ` Depeng Shao
@ 2024-07-31 15:26 ` Depeng Shao
2024-07-31 16:12 ` Bryan O'Donoghue
1 sibling, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-07-31 15:26 UTC (permalink / raw)
To: Krzysztof Kozlowski, rfoss, todor.too, bryan.odonoghue, mchehab,
robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
On 7/11/2024 7:12 PM, Krzysztof Kozlowski wrote:
> On 11/07/2024 13:08, Depeng Shao wrote:
>>>
>>>> +
>>>> +static void csid_subdev_init(struct csid_device *csid)
>>>> +{
>>>> + csid->testgen.modes = csid_testgen_modes;
>>>> + csid->testgen.nmodes = CSID_PAYLOAD_MODE_NUM_SUPPORTED_GEN2;
>>>> +}
>>>> +
>>>> +const struct csid_hw_ops csid_ops_gen3 = {
>>>
>>> Isn't there a warning here?
>>>
>>>> + .configure_stream = csid_configure_stream,
>>>> + .configure_testgen_pattern = csid_configure_testgen_pattern,
>>>> + .hw_version = csid_hw_version,
>>>> + .isr = csid_isr,
>>>> + .reset = csid_reset,
>>>> + .src_pad_code = csid_src_pad_code,
>>>> + .subdev_init = csid_subdev_init,
>>>> +};
>>>
>>> Your patchset does not apply at all. Tried v6.9, v6.10, next. I see some
>>> dependency above, but that means no one can test it and no one can apply it.
>>>
>>> Fix the warnings, I cannot verify it but I am sure you have them.
>>>
>>
>> My code base is next master branch, do you mean the 'declared and not
>> used' warning? I don't see this warning with below two version compiler
>> even though I just pick this patch and pull the code the latest version.
>> But it indeed have this issue, these structures are declared and will be
>> used later in "media: qcom: camss: Add sm8550 resources" patch, will
>> think about how to avoid this.
>>
>> aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.5.0-3ubuntu1~18.04) 7.5.0
>> aarch64-linux-gnu-gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
>
> That's some old compilers... I am talking about recent GCC, recent clang
> and of course W=1.
>
Hi Krzysztof,
I'm preparing the next version patches, then I find it is hard to avoid
such warning if only apply current patch, since this will be used in the
below patch, it will be in structures csid_res_8550 -> sm8550_resources
-> camss_dt_match, so I need to add all csid_res_8550, sm8550_resources,
camss_dt_match into this patch if I want to avoid the compile warning,
then I also need to add compatible info for it to avoid sm8550_resources
has unused variable warning, but the sm8550_resources structure also
need to add other items to make it complete, then the driver will be
incomplete but can be probed with this patch.
{ .compatible = "qcom,sm8550-camss", .data = &sm8550_resources },
https://lore.kernel.org/all/20240709160656.31146-14-quic_depengs@quicinc.com/
Could you please share some suggestions?
>
>
> Best regards,
> Krzysztof
>
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550
2024-07-31 15:26 ` Depeng Shao
@ 2024-07-31 16:12 ` Bryan O'Donoghue
2024-08-01 1:53 ` Depeng Shao
0 siblings, 1 reply; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-07-31 16:12 UTC (permalink / raw)
To: Depeng Shao, Krzysztof Kozlowski, rfoss, todor.too, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
On 31/07/2024 16:26, Depeng Shao wrote:
> I'm preparing the next version patches, then I find it is hard to avoid
> such warning if only apply current patch, since this will be used in the
> below patch, it will be in structures csid_res_8550 -> sm8550_resources
> -> camss_dt_match, so I need to add all csid_res_8550, sm8550_resources,
> camss_dt_match into this patch if I want to avoid the compile warning,
> then I also need to add compatible info for it to avoid sm8550_resources
> has unused variable warning, but the sm8550_resources structure also
> need to add other items to make it complete, then the driver will be
> incomplete but can be probed with this patch.
>
> { .compatible = "qcom,sm8550-camss", .data = &sm8550_resources },
>
> https://lore.kernel.org/all/20240709160656.31146-14-quic_depengs@quicinc.com/
Couldn't you just add the public structures at the same time they are
referenced in &sm8550_resources ?
That way your patchset would progressively apply with no warnings.
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 01/13] media: qcom: camss: csiphy-3ph: Fix trivial indentation fault in defines
2024-07-09 16:06 ` [PATCH 01/13] media: qcom: camss: csiphy-3ph: Fix trivial indentation fault in defines Depeng Shao
@ 2024-07-31 23:16 ` Vladimir Zapolskiy
0 siblings, 0 replies; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-07-31 23:16 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
On 7/9/24 19:06, Depeng Shao wrote:
> From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>
> Replace space with tab in define indentations.
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 02/13] media: qcom: camss: csiphy-3ph: Remove redundant PHY init sequence control loop
2024-07-09 16:06 ` [PATCH 02/13] media: qcom: camss: csiphy-3ph: Remove redundant PHY init sequence control loop Depeng Shao
@ 2024-07-31 23:27 ` Vladimir Zapolskiy
0 siblings, 0 replies; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-07-31 23:27 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
On 7/9/24 19:06, Depeng Shao wrote:
> From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>
> Adding a new CSIPHY init sequence using downstream as a reference prompted
> me to look at why we are splitting up the init sequence into chunks.
>
> Right now we declare CSI PHY init sequences as an array of five equally
> sized writes with a hard-coded control loop to iterate through each of the
> five indexes. One bug in this model is that if you don't have an even
> number of writes, you can't init the PHY as you wish.
>
> In downstream the original code has something of the character
> phy_init_seq[MAX_LANES][MAX_PARAMS] which in upstream we have translated
> into phy_init_seq[5][SOME_NUMBER_OF_EQUAL_WRITES];
>
> What the code does is take a pointer to the first index of the
> r = &phy_init_seq[0][0]; and then literally does write(r, value); r++;
>
> The controlling loop that hard-codes '5' in-lieu of MAX_LANES does no
> special sleep, fabric-coherence sync or even a printk() to justify its
> existence. Our compilers are optimising all of this away anyway so lets
> drop.
>
> Reduce the array declaration down to one flat aggregate init and let the
> code just step through. As a happy side-effect we can then also handle
> odd-number writes as the number of elements in the init sequence will no
> longer have to be evenly divisible.
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 03/13] media: qcom: camss: csiphy-3ph: Rename struct
2024-07-09 16:06 ` [PATCH 03/13] media: qcom: camss: csiphy-3ph: Rename struct Depeng Shao
@ 2024-07-31 23:28 ` Vladimir Zapolskiy
0 siblings, 0 replies; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-07-31 23:28 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
On 7/9/24 19:06, Depeng Shao wrote:
> From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>
> The existing structure captures the configuration of CSIPHY lane registers.
> Rename to struct csiphy_lane_regs to reflect.
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices
2024-07-09 16:06 ` [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices Depeng Shao
@ 2024-07-31 23:43 ` Vladimir Zapolskiy
2024-08-01 8:16 ` Bryan O'Donoghue
0 siblings, 1 reply; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-07-31 23:43 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
On 7/9/24 19:06, Depeng Shao wrote:
> From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>
> Add a nop callback to CSIPHY devices. Later patches will enumerate with
> enabling code.
Please avoid references to "patches" in the commit messages, it'll be
changes.
I took a look at the next changes, and in my opinion the selected names
.init / csiphy_init() / csiphy->res->hw_ops->init(csiphy) are confusing,
since there is no intention for real hardware initialization, which is
presumed by "hw_ops->init()", I see only routines to get some offsets
and populate allocated memory with some values... Not closely a hw_ops.
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> Reviewed-by: Elliot Berman <quic_eberman@quicinc.com>
> ---
> drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c | 6 ++++++
> drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c | 6 ++++++
> drivers/media/platform/qcom/camss/camss-csiphy.c | 4 ++++
> drivers/media/platform/qcom/camss/camss-csiphy.h | 1 +
> 4 files changed, 17 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c
> index cd4a8c369234..9d67e7fa6366 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy-2ph-1-0.c
> @@ -180,6 +180,11 @@ static irqreturn_t csiphy_isr(int irq, void *dev)
> return IRQ_HANDLED;
> }
>
> +static int csiphy_init(struct csiphy_device *csiphy)
> +{
> + return 0;
> +}
> +
> const struct csiphy_hw_ops csiphy_ops_2ph_1_0 = {
> .get_lane_mask = csiphy_get_lane_mask,
> .hw_version_read = csiphy_hw_version_read,
> @@ -187,4 +192,5 @@ const struct csiphy_hw_ops csiphy_ops_2ph_1_0 = {
> .lanes_enable = csiphy_lanes_enable,
> .lanes_disable = csiphy_lanes_disable,
> .isr = csiphy_isr,
> + .init = csiphy_init,
> };
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> index bc4834ee2dcc..b60c32a195df 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c
> @@ -581,6 +581,11 @@ static void csiphy_lanes_disable(struct csiphy_device *csiphy,
> CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(6));
> }
>
> +static int csiphy_init(struct csiphy_device *csiphy)
> +{
> + return 0;
> +}
> +
> const struct csiphy_hw_ops csiphy_ops_3ph_1_0 = {
> .get_lane_mask = csiphy_get_lane_mask,
> .hw_version_read = csiphy_hw_version_read,
> @@ -588,4 +593,5 @@ const struct csiphy_hw_ops csiphy_ops_3ph_1_0 = {
> .lanes_enable = csiphy_lanes_enable,
> .lanes_disable = csiphy_lanes_disable,
> .isr = csiphy_isr,
> + .init = csiphy_init,
> };
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.c b/drivers/media/platform/qcom/camss/camss-csiphy.c
> index 2f7361dfd461..ea5c7078ec8e 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy.c
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy.c
> @@ -576,6 +576,10 @@ int msm_csiphy_subdev_init(struct camss *camss,
> csiphy->cfg.combo_mode = 0;
> csiphy->res = &res->csiphy;
>
> + ret = csiphy->res->hw_ops->init(csiphy);
Here.
> + if (ret)
> + return ret;
> +
> /* Memory */
>
> csiphy->base = devm_platform_ioremap_resource_byname(pdev, res->reg[0]);
> diff --git a/drivers/media/platform/qcom/camss/camss-csiphy.h b/drivers/media/platform/qcom/camss/camss-csiphy.h
> index 47f0b6b09eba..bdf9a9c8bacc 100644
> --- a/drivers/media/platform/qcom/camss/camss-csiphy.h
> +++ b/drivers/media/platform/qcom/camss/camss-csiphy.h
> @@ -71,6 +71,7 @@ struct csiphy_hw_ops {
> void (*lanes_disable)(struct csiphy_device *csiphy,
> struct csiphy_config *cfg);
> irqreturn_t (*isr)(int irq, void *dev);
> + int (*init)(struct csiphy_device *csiphy);
> };
>
> struct csiphy_subdev_resources {
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 05/13] media: qcom: camss: csiphy-3ph: Move CSIPHY variables to data field inside csiphy struct
2024-07-09 16:06 ` [PATCH 05/13] media: qcom: camss: csiphy-3ph: Move CSIPHY variables to data field inside csiphy struct Depeng Shao
@ 2024-07-31 23:55 ` Vladimir Zapolskiy
0 siblings, 0 replies; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-07-31 23:55 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
Hi Bryan,
On 7/9/24 19:06, Depeng Shao wrote:
> From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>
> A .data field in the csiphy device structure allows us to extend out the
> register layout of the three phase capable CSIPHY layer.
>
> Move the existing lane configuration structure to an encapsulating
> structure -> struct csiphy_device_regs which is derived from the .data
> field populated at PHY init time, as opposed to calculated at lane
> configuration.
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
in my opinion the change is good, still it might be reasonable to rename
.init to something else and/or get it out of hw_ops.
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-07-09 16:06 ` [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding Depeng Shao
` (2 preceding siblings ...)
2024-07-10 11:07 ` Krzysztof Kozlowski
@ 2024-08-01 0:05 ` Vladimir Zapolskiy
2024-08-01 2:02 ` Depeng Shao
3 siblings, 1 reply; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-08-01 0:05 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
On 7/9/24 19:06, Depeng Shao wrote:
> Add bindings for qcom,sm8550-camss in order to support the camera
> subsystem for sm8550
>
> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> ---
> .../bindings/media/qcom,sm8550-camss.yaml | 545 ++++++++++++++++++
> 1 file changed, 545 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml
> new file mode 100644
> index 000000000000..d002b0ff119e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml
> @@ -0,0 +1,545 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/qcom,sm8550-camss.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm SM8550 Camera Subsystem (CAMSS)
> +
> +maintainers:
> + - Depeng Shao <quic_depengs@quicinc.com>
> +
> +description: |
> + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
> +
> +properties:
> + compatible:
> + const: qcom,sm8550-camss
> +
> + clocks:
> + minItems: 47
> + maxItems: 47
> +
> + clock-names:
> + items:
> + - const: cam_ahb_clk
> + - const: cam_hf_axi
> + - const: cam_sf_axi
> + - const: camnoc_axi
> + - const: camnoc_axi_src
> + - const: core_ahb
> + - const: cpas_ahb
> + - const: slow_ahb_src
> + - const: csiphy0
> + - const: csiphy0_timer
> + - const: csiphy1
> + - const: csiphy1_timer
> + - const: csiphy2
> + - const: csiphy2_timer
> + - const: csiphy3
> + - const: csiphy3_timer
> + - const: csiphy4
> + - const: csiphy4_timer
> + - const: csiphy5
> + - const: csiphy5_timer
> + - const: csiphy6
> + - const: csiphy6_timer
> + - const: csiphy7
> + - const: csiphy7_timer
> + - const: csid_src
> + - const: csid
> + - const: csiphy_rx
> + - const: vfe0_fast_ahb
> + - const: vfe0_src
> + - const: vfe0
> + - const: cpas_vfe0
> + - const: vfe1_fast_ahb
> + - const: vfe1_src
> + - const: vfe1
> + - const: cpas_vfe2
> + - const: vfe2_fast_ahb
> + - const: vfe2_src
> + - const: vfe2
> + - const: cpas_vfe1
> + - const: vfe_lite_ahb
> + - const: vfe_lite_csid_src
> + - const: vfe_lite
> + - const: vfe_lite_cphy_rx
> + - const: vfe_lite_csid
> + - const: cpas_ife_lite
> + - const: cpas_fast_ahb_clk
> + - const: fast_ahb_src
I believe most of *_src clocks should be removed from the list above as
parent clocks with no need for own separate management.
> +
> + interrupts:
> + minItems: 18
> + maxItems: 18
> +
> + interrupt-names:
> + items:
> + - const: csiphy0
> + - const: csiphy1
> + - const: csiphy2
> + - const: csiphy3
> + - const: csiphy4
> + - const: csiphy5
> + - const: csiphy6
> + - const: csiphy7
> + - const: csid0
> + - const: csid1
> + - const: csid2
> + - const: csid_lite0
> + - const: csid_lite1
> + - const: vfe0
> + - const: vfe1
> + - const: vfe2
> + - const: vfe_lite0
> + - const: vfe_lite1
> +
> + iommus:
> + maxItems: 1
> +
> + interconnects:
> + minItems: 4
> + maxItems: 4
> +
> + interconnect-names:
> + items:
> + - const: cam_ahb
> + - const: cam_hf_0_mnoc
> + - const: cam_sf_0_mnoc
> + - const: cam_sf_icp_mnoc
> +
> + power-domains:
> + items:
> + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
> + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller.
> + - description: IFE2 GDSC - Image Front End, Global Distributed Switch Controller.
> + - description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller.
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + description:
> + CSI input ports.
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description:
> + Input port for receiving CSI data.
> +
> + properties:
> + endpoint:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + clock-lanes:
> + maxItems: 1
> +
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> + required:
> + - clock-lanes
> + - data-lanes
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description:
> + Input port for receiving CSI data.
> +
> + properties:
> + endpoint:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + clock-lanes:
> + maxItems: 1
> +
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> + required:
> + - clock-lanes
> + - data-lanes
> +
> + port@2:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description:
> + Input port for receiving CSI data.
> +
> + properties:
> + endpoint:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + clock-lanes:
> + maxItems: 1
> +
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> + required:
> + - clock-lanes
> + - data-lanes
> +
> + port@3:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description:
> + Input port for receiving CSI data.
> +
> + properties:
> + endpoint:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + clock-lanes:
> + maxItems: 1
> +
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> + required:
> + - clock-lanes
> + - data-lanes
> +
> + port@4:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description:
> + Input port for receiving CSI data.
> +
> + properties:
> + endpoint:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + clock-lanes:
> + maxItems: 1
> +
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> + required:
> + - clock-lanes
> + - data-lanes
> +
> + port@5:
> + $ref: /schemas/graph.yaml#/$defs/port-base
> + unevaluatedProperties: false
> + description:
> + Input port for receiving CSI data.
> +
> + properties:
> + endpoint:
> + $ref: video-interfaces.yaml#
> + unevaluatedProperties: false
> +
> + properties:
> + clock-lanes:
> + maxItems: 1
> +
> + data-lanes:
> + minItems: 1
> + maxItems: 4
> +
> + required:
> + - clock-lanes
> + - data-lanes
> +
> + reg:
> + minItems: 19
> + maxItems: 19
> +
> + reg-names:
> + items:
> + - const: csiphy0
> + - const: csiphy1
> + - const: csiphy2
> + - const: csiphy3
> + - const: csiphy4
> + - const: csiphy5
> + - const: csiphy6
> + - const: csiphy7
> + - const: csid0
> + - const: csid1
> + - const: csid2
> + - const: csid_lite0
> + - const: csid_lite1
> + - const: csid_top
> + - const: vfe0
> + - const: vfe1
> + - const: vfe2
> + - const: vfe_lite0
> + - const: vfe_lite1
> +
> + vdda-phy-supply:
> + description:
> + Phandle to a regulator supply to PHY core block.
> +
> + vdda-pll-supply:
> + description:
> + Phandle to 1.2V regulator supply to PHY refclk pll block.
> +
> +required:
> + - clock-names
> + - clocks
> + - compatible
I would suggest to put 'compatible', 'reg' and 'reg-names' properties as
the first ones. 'clock-names' should follow 'clocks' property in the list.
> + - interconnects
> + - interconnect-names
> + - interrupts
> + - interrupt-names
> + - iommus
> + - power-domains
> + - reg
> + - reg-names
> + - vdda-phy-supply
> + - vdda-pll-supply
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/qcom,sm8550-camcc.h>
> + #include <dt-bindings/clock/qcom,sm8550-gcc.h>
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/power/qcom-rpmpd.h>
> + #include <dt-bindings/clock/qcom,rpmh.h>
> + #include <dt-bindings/interconnect/qcom,sm8550-rpmh.h>
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + camss: camss@ace4000 {
> + compatible = "qcom,sm8550-camss";
> +
> + reg = <0 0x0ace4000 0 0x2000>,
> + <0 0x0ace6000 0 0x2000>,
> + <0 0x0ace8000 0 0x2000>,
> + <0 0x0acea000 0 0x2000>,
> + <0 0x0acec000 0 0x2000>,
> + <0 0x0acee000 0 0x2000>,
> + <0 0x0acf0000 0 0x2000>,
> + <0 0x0acf2000 0 0x2000>,
> + <0 0x0acb7000 0 0xd00>,
> + <0 0x0acb9000 0 0xd00>,
> + <0 0x0acbb000 0 0xd00>,
> + <0 0x0acca000 0 0xa00>,
> + <0 0x0acce000 0 0xa00>,
> + <0 0x0acb6000 0 0x1000>,
> + <0 0x0ac62000 0 0xf000>,
> + <0 0x0ac71000 0 0xf000>,
> + <0 0x0ac80000 0 0xf000>,
> + <0 0x0acca000 0 0x2800>,
> + <0 0x0acce000 0 0x2800>;
> + reg-names = "csiphy0",
> + "csiphy1",
> + "csiphy2",
> + "csiphy3",
> + "csiphy4",
> + "csiphy5",
> + "csiphy6",
> + "csiphy7",
> + "csid0",
> + "csid1",
> + "csid2",
> + "csid_lite0",
> + "csid_lite1",
> + "csid_top",
> + "vfe0",
> + "vfe1",
> + "vfe2",
> + "vfe_lite0",
> + "vfe_lite1";
> +
> + vdda-phy-supply = <&vreg_l1e_0p88>;
> + vdda-pll-supply = <&vreg_l3e_1p2>;
> +
> + interrupts = <GIC_SPI 477 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 278 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 277 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 431 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 688 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
> +
> + interrupt-names = "csiphy0",
> + "csiphy1",
> + "csiphy2",
> + "csiphy3",
> + "csiphy4",
> + "csiphy5",
> + "csiphy6",
> + "csiphy7",
> + "csid0",
> + "csid1",
> + "csid2",
> + "csid_lite0",
> + "csid_lite1",
> + "vfe0",
> + "vfe1",
> + "vfe2",
> + "vfe_lite0",
> + "vfe_lite1";
> +
> + power-domains = <&camcc CAM_CC_IFE_0_GDSC>,
> + <&camcc CAM_CC_IFE_1_GDSC>,
> + <&camcc CAM_CC_IFE_2_GDSC>,
> + <&camcc CAM_CC_TITAN_TOP_GDSC>;
> +
> + clocks = <&gcc GCC_CAMERA_AHB_CLK>,
> + <&gcc GCC_CAMERA_HF_AXI_CLK>,
> + <&gcc GCC_CAMERA_SF_AXI_CLK>,
> + <&camcc CAM_CC_CAMNOC_AXI_CLK>,
> + <&camcc CAM_CC_CAMNOC_AXI_CLK_SRC>,
> + <&camcc CAM_CC_CORE_AHB_CLK>,
> + <&camcc CAM_CC_CPAS_AHB_CLK>,
> + <&camcc CAM_CC_SLOW_AHB_CLK_SRC>,
> + <&camcc CAM_CC_CSIPHY0_CLK>,
> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY1_CLK>,
> + <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY2_CLK>,
> + <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY3_CLK>,
> + <&camcc CAM_CC_CSI3PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY4_CLK>,
> + <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY5_CLK>,
> + <&camcc CAM_CC_CSI5PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY6_CLK>,
> + <&camcc CAM_CC_CSI6PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY7_CLK>,
> + <&camcc CAM_CC_CSI7PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSID_CLK_SRC>,
> + <&camcc CAM_CC_CSID_CLK>,
> + <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
> + <&camcc CAM_CC_IFE_0_FAST_AHB_CLK>,
> + <&camcc CAM_CC_IFE_0_CLK_SRC>,
> + <&camcc CAM_CC_IFE_0_CLK>,
> + <&camcc CAM_CC_CPAS_IFE_0_CLK>,
> + <&camcc CAM_CC_IFE_1_FAST_AHB_CLK>,
> + <&camcc CAM_CC_IFE_1_CLK_SRC>,
> + <&camcc CAM_CC_IFE_1_CLK>,
> + <&camcc CAM_CC_CPAS_IFE_1_CLK>,
> + <&camcc CAM_CC_IFE_2_FAST_AHB_CLK>,
> + <&camcc CAM_CC_IFE_2_CLK_SRC>,
> + <&camcc CAM_CC_IFE_2_CLK>,
> + <&camcc CAM_CC_CPAS_IFE_2_CLK>,
> + <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
> + <&camcc CAM_CC_IFE_LITE_CSID_CLK_SRC>,
> + <&camcc CAM_CC_IFE_LITE_CSID_CLK>,
> + <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
> + <&camcc CAM_CC_IFE_LITE_CLK>,
> + <&camcc CAM_CC_CPAS_IFE_LITE_CLK>,
> + <&camcc CAM_CC_CPAS_FAST_AHB_CLK>,
> + <&camcc CAM_CC_FAST_AHB_CLK_SRC>;
> +
> + clock-names = "cam_ahb_clk",
> + "cam_hf_axi",
> + "cam_sf_axi",
> + "camnoc_axi",
> + "camnoc_axi_src",
> + "core_ahb",
> + "cpas_ahb",
> + "slow_ahb_src",
> + "csiphy0",
> + "csiphy0_timer",
> + "csiphy1",
> + "csiphy1_timer",
> + "csiphy2",
> + "csiphy2_timer",
> + "csiphy3",
> + "csiphy3_timer",
> + "csiphy4",
> + "csiphy4_timer",
> + "csiphy5",
> + "csiphy5_timer",
> + "csiphy6",
> + "csiphy6_timer",
> + "csiphy7",
> + "csiphy7_timer",
> + "csid_src",
> + "csid",
> + "csiphy_rx",
> + "vfe0_fast_ahb",
> + "vfe0_src",
> + "vfe0",
> + "cpas_vfe0",
> + "vfe1_fast_ahb",
> + "vfe1_src",
> + "vfe1",
> + "cpas_vfe1",
> + "vfe2_fast_ahb",
> + "vfe2_src",
> + "vfe2",
> + "cpas_vfe2",
> + "vfe_lite_ahb",
> + "vfe_lite_csid_src",
> + "vfe_lite_csid",
> + "vfe_lite_cphy_rx",
> + "vfe_lite",
> + "cpas_ife_lite",
> + "cpas_fast_ahb_clk",
> + "fast_ahb_src";
> +
> + iommus = <&apps_smmu 0x800 0x20>;
> +
> + interconnects =
> + <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_CAMERA_CFG 0>,
> + <&mmss_noc MASTER_CAMNOC_HF 0 &mc_virt SLAVE_EBI1 0>,
> + <&mmss_noc MASTER_CAMNOC_SF 0 &mc_virt SLAVE_EBI1 0>,
> + <&mmss_noc MASTER_CAMNOC_ICP 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names =
> + "cam_ahb",
> + "cam_hf_0_mnoc",
> + "cam_sf_0_mnoc",
> + "cam_sf_icp_mnoc";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + csiphy_ep0: endpoint@0 {
> + reg = <0>;
> + clock-lanes = <7>;
> + data-lanes = <0 1>;
> + remote-endpoint = <&sensor_ep>;
> + };
> + };
> + };
> + };
> + };
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550
2024-07-31 16:12 ` Bryan O'Donoghue
@ 2024-08-01 1:53 ` Depeng Shao
2024-08-01 10:59 ` Bryan O'Donoghue
0 siblings, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-08-01 1:53 UTC (permalink / raw)
To: Bryan O'Donoghue, Krzysztof Kozlowski, rfoss, todor.too,
mchehab, robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
Hi Bryan,
On 8/1/2024 12:12 AM, Bryan O'Donoghue wrote:
> On 31/07/2024 16:26, Depeng Shao wrote:
>> I'm preparing the next version patches, then I find it is hard to
>> avoid such warning if only apply current patch, since this will be
>> used in the below patch, it will be in structures csid_res_8550 ->
>> sm8550_resources -> camss_dt_match, so I need to add all
>> csid_res_8550, sm8550_resources, camss_dt_match into this patch if I
>> want to avoid the compile warning,
>> then I also need to add compatible info for it to avoid
>> sm8550_resources has unused variable warning, but the sm8550_resources
>> structure also need to add other items to make it complete, then the
>> driver will be incomplete but can be probed with this patch.
>>
>> { .compatible = "qcom,sm8550-camss", .data = &sm8550_resources },
>>
>> https://lore.kernel.org/all/20240709160656.31146-14-quic_depengs@quicinc.com/
>
> Couldn't you just add the public structures at the same time they are
> referenced in &sm8550_resources ?
>
> That way your patchset would progressively apply with no warnings.
>
Sorry, I don't get it, but in my understanding, but looks like the only
way to avoid the compile warning is that adding compatible change in
early patch set.
I can add the compatible change and structure sm8550_resources in the
early patch, but the structure sm8550_resources will just have very few
info in this patch. Then fill the other elements in sm8550_resources in
the following patches, this can avoid the warning, but the issue is that
the sm8550 can be probed once having patch set 1, but the
sm8550_resources isn't complete in patch set 1.
Could you please common if this is fine?
patch set 1
+{ .compatible = "qcom,sm8550-camss", .data = &sm8550_resources },
+static const struct camss_resources sm8550_resources = {
+ .version = CAMSS_8550,
+ .pd_name = "top",
+ .icc_res = icc_res_sm8550,
+ .icc_path_num = ARRAY_SIZE(icc_res_sm8550),
+ .link_entities = camss_link_entities
+};
patch set2 - Adding csiphy driver and csiphy res to sm8550_resources
static const struct camss_resources sm8550_resources = {
.version = CAMSS_8550,
.pd_name = "top",
+ .csiphy_res = csiphy_res_8550,
.icc_res = icc_res_sm8550,
.icc_path_num = ARRAY_SIZE(icc_res_sm8550),
+ .csiphy_num = ARRAY_SIZE(csiphy_res_8550),
.link_entities = camss_link_entities
};
patch set 3 - Adding csid driver and csid res to sm8550_resources
static const struct camss_resources sm8550_resources = {
.version = CAMSS_8550,
.pd_name = "top",
.csiphy_res = csiphy_res_8550,
+ .csid_res = csid_res_8550,
.icc_res = icc_res_sm8550,
.icc_path_num = ARRAY_SIZE(icc_res_sm8550),
.csiphy_num = ARRAY_SIZE(csiphy_res_8550),
+ .csid_num = ARRAY_SIZE(csid_res_8550),
.link_entities = camss_link_entities
};
> ---
> bod
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-08-01 0:05 ` Vladimir Zapolskiy
@ 2024-08-01 2:02 ` Depeng Shao
0 siblings, 0 replies; 99+ messages in thread
From: Depeng Shao @ 2024-08-01 2:02 UTC (permalink / raw)
To: Vladimir Zapolskiy, rfoss, todor.too, bryan.odonoghue, mchehab,
robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
Hi Vladimir,
On 8/1/2024 8:05 AM, Vladimir Zapolskiy wrote:
> On 7/9/24 19:06, Depeng Shao wrote:
>> Add bindings for qcom,sm8550-camss in order to support the camera
>> subsystem for sm8550
>> +
>> + clock-names:
>> + items:
>> + - const: cam_ahb_clk
>> + - const: cam_hf_axi
>> + - const: cam_sf_axi
>> + - const: camnoc_axi
>> + - const: camnoc_axi_src
>> + - const: core_ahb
>> + - const: cpas_ahb
>> + - const: slow_ahb_src
>> + - const: csiphy0
>> + - const: csiphy0_timer
>> + - const: csiphy1
>> + - const: csiphy1_timer
>> + - const: csiphy2
>> + - const: csiphy2_timer
>> + - const: csiphy3
>> + - const: csiphy3_timer
>> + - const: csiphy4
>> + - const: csiphy4_timer
>> + - const: csiphy5
>> + - const: csiphy5_timer
>> + - const: csiphy6
>> + - const: csiphy6_timer
>> + - const: csiphy7
>> + - const: csiphy7_timer
>> + - const: csid_src
>> + - const: csid
>> + - const: csiphy_rx
>> + - const: vfe0_fast_ahb
>> + - const: vfe0_src
>> + - const: vfe0
>> + - const: cpas_vfe0
>> + - const: vfe1_fast_ahb
>> + - const: vfe1_src
>> + - const: vfe1
>> + - const: cpas_vfe2
>> + - const: vfe2_fast_ahb
>> + - const: vfe2_src
>> + - const: vfe2
>> + - const: cpas_vfe1
>> + - const: vfe_lite_ahb
>> + - const: vfe_lite_csid_src
>> + - const: vfe_lite
>> + - const: vfe_lite_cphy_rx
>> + - const: vfe_lite_csid
>> + - const: cpas_ife_lite
>> + - const: cpas_fast_ahb_clk
>> + - const: fast_ahb_src
>
> I believe most of *_src clocks should be removed from the list above as
> parent clocks with no need for own separate management.
>
Sure, Bryan has same comment, I have removed the *_src clk locally, this
change will be in new version patch.
>> +
>> +required:
>> + - clock-names
>> + - clocks
>> + - compatible
>
> I would suggest to put 'compatible', 'reg' and 'reg-names' properties as
> the first ones. 'clock-names' should follow 'clocks' property in the list.
>
Thanks for the suggestion, will add it in next version patch.
>> + - interconnects
>> + - interconnect-names
>> + - interrupts
>> + - interrupt-names
>> + - iommus
>> + - power-domains
>> + - reg
>> + - reg-names
>> + - vdda-phy-supply
>> + - vdda-pll-supply
>> + - ports
>> +
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices
2024-07-31 23:43 ` Vladimir Zapolskiy
@ 2024-08-01 8:16 ` Bryan O'Donoghue
2024-08-04 21:26 ` Vladimir Zapolskiy
0 siblings, 1 reply; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-08-01 8:16 UTC (permalink / raw)
To: Vladimir Zapolskiy, Depeng Shao, rfoss, todor.too, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
On 01/08/2024 00:43, Vladimir Zapolskiy wrote:
>> + ret = csiphy->res->hw_ops->init(csiphy);
>
> Here.
What name would make more sense to you ?
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550
2024-08-01 1:53 ` Depeng Shao
@ 2024-08-01 10:59 ` Bryan O'Donoghue
2024-08-01 11:14 ` Bryan O'Donoghue
0 siblings, 1 reply; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-08-01 10:59 UTC (permalink / raw)
To: Depeng Shao, Krzysztof Kozlowski, rfoss, todor.too, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
On 01/08/2024 02:53, Depeng Shao wrote:
> but the issue is that the sm8550 can be probed once having patch set 1,
> but the sm8550_resources isn't complete in patch set 1.
Doesn't matter until you _upstream_ a dts that operates on it.
Its not a massive deal if you start at patch #1 and and patch #1+n and a
there are a few warnings in between as you add stuff in but, for
preference every single patch applies and builds warning free.
If you
- Add bindings
- Do driver stuff
- Then do dts stuff
You don't need to worry about probe() doing mad things.
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550
2024-08-01 10:59 ` Bryan O'Donoghue
@ 2024-08-01 11:14 ` Bryan O'Donoghue
2024-08-01 13:49 ` Depeng Shao
0 siblings, 1 reply; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-08-01 11:14 UTC (permalink / raw)
To: Depeng Shao, Krzysztof Kozlowski, rfoss, todor.too, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
On 01/08/2024 11:59, Bryan O'Donoghue wrote:
> for preference every single patch applies and builds warning free.
Oops mistyped
- Every patch must apply cleanly
- You could make an argument for some specific cases that
a patch can generate a warning provided
- By the end of your set everything must be warning free
In this case though, I don't believe you need to make that case since,
the problem you describe about probe() isn't a problem at all as you
have no upstream dts that can drive the probe() at this point.
Just do the dts at the end and no problem.
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550
2024-08-01 11:14 ` Bryan O'Donoghue
@ 2024-08-01 13:49 ` Depeng Shao
0 siblings, 0 replies; 99+ messages in thread
From: Depeng Shao @ 2024-08-01 13:49 UTC (permalink / raw)
To: Bryan O'Donoghue, Krzysztof Kozlowski, rfoss, todor.too,
mchehab, robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
Hi Bryan,
On 8/1/2024 7:14 PM, Bryan O'Donoghue wrote:
> On 01/08/2024 11:59, Bryan O'Donoghue wrote:
>> for preference every single patch applies and builds warning free.
>
> Oops mistyped
>
> - Every patch must apply cleanly
> - You could make an argument for some specific cases that
> a patch can generate a warning provided
> - By the end of your set everything must be warning free
>
> In this case though, I don't believe you need to make that case since,
> the problem you describe about probe() isn't a problem at all as you
> have no upstream dts that can drive the probe() at this point.
>
> Just do the dts at the end and no problem.
>
Thanks for the confirmation, maybe also can add a checking for the res,
probe returns fail if the .data->xxx_res is NULL.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices
2024-08-01 8:16 ` Bryan O'Donoghue
@ 2024-08-04 21:26 ` Vladimir Zapolskiy
2024-08-07 13:08 ` Depeng Shao
0 siblings, 1 reply; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-08-04 21:26 UTC (permalink / raw)
To: Bryan O'Donoghue, Depeng Shao, rfoss, todor.too, mchehab,
robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
Hi Bryan,
On 8/1/24 11:16, Bryan O'Donoghue wrote:
> On 01/08/2024 00:43, Vladimir Zapolskiy wrote:
>>> + ret = csiphy->res->hw_ops->init(csiphy);
>>
>> Here.
>
> What name would make more sense to you ?
according to the implementation the .init() call just fills some data in
memory, so I believe this could be handled at build time, if it's done
carefully enough...
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices
2024-08-04 21:26 ` Vladimir Zapolskiy
@ 2024-08-07 13:08 ` Depeng Shao
2024-08-07 14:04 ` Bryan O'Donoghue
0 siblings, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-08-07 13:08 UTC (permalink / raw)
To: Vladimir Zapolskiy, Bryan O'Donoghue, rfoss, todor.too,
mchehab, robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
Hi Vladimir,
On 8/5/2024 5:26 AM, Vladimir Zapolskiy wrote:
> Hi Bryan,
>
> On 8/1/24 11:16, Bryan O'Donoghue wrote:
>> On 01/08/2024 00:43, Vladimir Zapolskiy wrote:
>>>> + ret = csiphy->res->hw_ops->init(csiphy);
>>>
>>> Here.
>>
>> What name would make more sense to you ?
>
> according to the implementation the .init() call just fills some data in
> memory, so I believe this could be handled at build time, if it's done
> carefully enough...
>
This camss-csiphy-3ph-1-0.c is reused by many platforms, the old
platforms have same CSI_COMMON_CTR register offset, their offset are
0x800, but some new platforms may have different CSI_COMMON_CTR register
offset, for example, the CSI_COMMON_CTR register offset is 0x1000 in
sm8550, then we need to add new file to support the new csiphy HW, e.g.,
camss-csiphy-3ph-2-0.c, so Bryan asked me to develop the CSIPHY driver
based on his changes, then we just need few code to enable new CSIPHY.
Regarding the hw_ops->init interface, since it fills HW register
configurations and HW register offset, then maybe, it also can be called
as HW operation.
And looks like we can't move it to camss-csiphy.c since it does platform
specific operation and it is related to the registers.
Please feel free to share other comments if you don't agree with it. Thanks.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices
2024-08-07 13:08 ` Depeng Shao
@ 2024-08-07 14:04 ` Bryan O'Donoghue
2024-08-07 15:03 ` Depeng Shao
0 siblings, 1 reply; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-08-07 14:04 UTC (permalink / raw)
To: Depeng Shao, Vladimir Zapolskiy, rfoss, todor.too, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
On 07/08/2024 14:08, Depeng Shao wrote:
> Hi Vladimir,
>
> On 8/5/2024 5:26 AM, Vladimir Zapolskiy wrote:
>> Hi Bryan,
>>
>> On 8/1/24 11:16, Bryan O'Donoghue wrote:
>>> On 01/08/2024 00:43, Vladimir Zapolskiy wrote:
>>>>> + ret = csiphy->res->hw_ops->init(csiphy);
>>>>
>>>> Here.
>>>
>>> What name would make more sense to you ?
>>
>> according to the implementation the .init() call just fills some data in
>> memory, so I believe this could be handled at build time, if it's done
>> carefully enough...
>>
>
> This camss-csiphy-3ph-1-0.c is reused by many platforms, the old
> platforms have same CSI_COMMON_CTR register offset, their offset are
> 0x800, but some new platforms may have different CSI_COMMON_CTR register
> offset, for example, the CSI_COMMON_CTR register offset is 0x1000 in
> sm8550, then we need to add new file to support the new csiphy HW, e.g.,
> camss-csiphy-3ph-2-0.c, so Bryan asked me to develop the CSIPHY driver
> based on his changes, then we just need few code to enable new CSIPHY.
>
> Regarding the hw_ops->init interface, since it fills HW register
> configurations and HW register offset, then maybe, it also can be called
> as HW operation.
>
> And looks like we can't move it to camss-csiphy.c since it does platform
> specific operation and it is related to the registers.
>
> Please feel free to share other comments if you don't agree with it.
> Thanks.
>
>
> Thanks,
> Depeng
So, I agree the phy init data could be obtained via resource structs
but, rather than add yet more patches to this series, I'd say we can
make the move to a separate resource struct pointer at a later date.
Lets drop this patch and @Depeng we can then do
+ regs->offset = 0x800;
media: qcom: camss: csiphy-3ph: Use an offset variable to find common
control regs
As a bonus that's one less patch for this series which @ 13 patches is
already large.
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices
2024-08-07 14:04 ` Bryan O'Donoghue
@ 2024-08-07 15:03 ` Depeng Shao
2024-08-07 15:37 ` Bryan O'Donoghue
0 siblings, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-08-07 15:03 UTC (permalink / raw)
To: Bryan O'Donoghue, Vladimir Zapolskiy, rfoss, todor.too,
mchehab, robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
Hi Bryan,
On 8/7/2024 10:04 PM, Bryan O'Donoghue wrote:
> On 07/08/2024 14:08, Depeng Shao wrote:
>> Hi Vladimir,
>>
>> On 8/5/2024 5:26 AM, Vladimir Zapolskiy wrote:
>>> Hi Bryan,
>>>
>>> On 8/1/24 11:16, Bryan O'Donoghue wrote:
>>>> On 01/08/2024 00:43, Vladimir Zapolskiy wrote:
>>>>>> + ret = csiphy->res->hw_ops->init(csiphy);
>>>>>
>>>>> Here.
>>>>
>>>> What name would make more sense to you ?
>>>
>>> according to the implementation the .init() call just fills some data in
>>> memory, so I believe this could be handled at build time, if it's done
>>> carefully enough...
>>>
>>
>> This camss-csiphy-3ph-1-0.c is reused by many platforms, the old
>> platforms have same CSI_COMMON_CTR register offset, their offset are
>> 0x800, but some new platforms may have different CSI_COMMON_CTR
>> register offset, for example, the CSI_COMMON_CTR register offset is
>> 0x1000 in sm8550, then we need to add new file to support the new
>> csiphy HW, e.g., camss-csiphy-3ph-2-0.c, so Bryan asked me to develop
>> the CSIPHY driver based on his changes, then we just need few code to
>> enable new CSIPHY.
>>
>> Regarding the hw_ops->init interface, since it fills HW register
>> configurations and HW register offset, then maybe, it also can be
>> called as HW operation.
>>
>> And looks like we can't move it to camss-csiphy.c since it does
>> platform specific operation and it is related to the registers.
>>
>> Please feel free to share other comments if you don't agree with it.
>> Thanks.
>>
>>
>> Thanks,
>> Depeng
>
> So, I agree the phy init data could be obtained via resource structs
> but, rather than add yet more patches to this series, I'd say we can
> make the move to a separate resource struct pointer at a later date.
>
> Lets drop this patch and @Depeng we can then do
>
> + regs->offset = 0x800;
>
> media: qcom: camss: csiphy-3ph: Use an offset variable to find common
> control regs
>
Do you mean only drop "[PATCH 04/13] media: qcom: camss: csiphy: Add an
init callback to CSI PHY devices"?
[PATCH 05/13] media: qcom: camss: csiphy-3ph: Move CSIPHY variables to
data field inside csiphy struct
Do you mean this is still needed? Just don't move the code from
csiphy_gen2_config_lanes to csiphy_init, right?
[PATCH 06/13] media: qcom: camss: csiphy-3ph: Use an offset variable to
find common control regs
The offset change is also needed, just need to add the offset for
different platform in csiphy_gen2_config_lanes .
Please correct me if my understanding is wrong. Thanks.
> As a bonus that's one less patch for this series which @ 13 patches is
> already large.
>
> ---
> bod
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550
2024-07-11 15:33 ` Depeng Shao
@ 2024-08-07 15:10 ` Depeng Shao
0 siblings, 0 replies; 99+ messages in thread
From: Depeng Shao @ 2024-08-07 15:10 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel, Yongsheng Li
Hi Bryan,
Looks like you missed this mail, Could you please check again?
On 7/11/2024 11:33 PM, Depeng Shao wrote:
> Hi Bryan,
>
> On 7/10/2024 7:28 PM, Bryan O'Donoghue wrote:
>> On 09/07/2024 17:06, Depeng Shao wrote:
>>> The CSID in SM8550 is gen3, it has new register offset and new
>>> functionality. The buf done irq,register update and reset are
>>> moved to CSID gen3. And CSID gen3 has a new register block which
>>> is named as CSID top, it controls the output of CSID, since the
>>> CSID can connect to Sensor Front End (SFE) or original VFE, the
>>> register in top block is used to control the HW connection.
>>>
>>> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
>>> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
>>> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
>>> ---
>>> drivers/media/platform/qcom/camss/Makefile | 1 +
>>> .../platform/qcom/camss/camss-csid-gen3.c | 445 ++++++++++++++++++
>>> .../platform/qcom/camss/camss-csid-gen3.h | 26 +
>>> .../media/platform/qcom/camss/camss-csid.h | 2 +
>>> 4 files changed, 474 insertions(+)
>>> create mode 100644 drivers/media/platform/qcom/camss/camss-csid-gen3.c
>>> create mode 100644 drivers/media/platform/qcom/camss/camss-csid-gen3.h
>>>
>
>>> +
>>> +#define REG_UPDATE_RDI reg_update_rdi
>>> +
>>> +static void __csid_configure_rx(struct csid_device *csid,
>>> + struct csid_phy_config *phy, int vc)
>>> +{
>>> + int val;
>>> +
>>> + val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
>>> + val |= phy->lane_assign << CSI2_RX_CFG0_DL0_INPUT_SEL;
>>> + val |= (phy->csiphy_id + CSI2_RX_CFG0_PHY_SEL_BASE_IDX) <<
>>> CSI2_RX_CFG0_PHY_NUM_SEL;
>>> +
>>> + writel_relaxed(val, csid->base + CSID_CSI2_RX_CFG0);
>>> +
>>> + val = 1 << CSI2_RX_CFG1_PACKET_ECC_CORRECTION_EN;
>>> + if (vc > 3)
>>> + val |= 1 << CSI2_RX_CFG1_VC_MODE;
>>
>> I realise downstream does these shifts but, I think in upstream we
>> should just define a BIT(x)
>>
>> #define CSI2_RX_CFG1_VC_MODE BIT(2)
>>
>> val |= CSI2_RX_CFG1_VC_MODE;
>>
>
> Here CSI2_RX_CFG1_VC_MODE just means a register bit offset, not a
> register configuration.
>
> Some fixed configuration can do this, but some register bits value are
> configured based on actual parameter.
> e.g.; val = (phy->lane_cnt - 1) << CSI2_RX_CFG0_NUM_ACTIVE_LANES;
>
> If we want to use macro definition, maybe we can do like below.
>
> #define CSI2_RX_CFG1_VC_MODE(n) ((n) << 2)
> val |= CSI2_RX_CFG1_VC_MODE(1);
>
>
> #define CSI2_RX_CFG0_DL0_INPUT_SEL(n) ((n) << 4)
> val |= CSI2_RX_CFG0_DL0_INPUT_SEL(phy->lane_assign)
>
> Could you please comment if we really need to do like this?
>
>
>>> + writel_relaxed(val, csid->base + CSID_CSI2_RX_CFG1);
>>> +}
>>> +
>>> +static void __csid_ctrl_rdi(struct csid_device *csid, int enable, u8
>>> rdi)
>>> +{
>>> + int val;
>>> +
>>> + if (enable)
>>> + val = 1 << RDI_CTRL_START_CMD;
>>> + else
>>> + val = 0 << RDI_CTRL_START_CMD;
>>
>> Here is an example of how the bit shifting is weird
>>
>> (0 << anything) is still zero
>>
>
> Understood, the value is same, but we can know the configuration clearly
> on this register bit. If we do like above way, then it likes below.
>
> #define RDI_CTRL_START_CMD(n) ((n) << 0) --> it is same with (n), but
> we don't know the register bit offset clearly if we use (n).
>
> if (enable)
> val = RDI_CTRL_START_CMD(1);
> else
> val = RDI_CTRL_START_CMD(0);
>
>>> + writel_relaxed(val, csid->base + CSID_RDI_CTRL(rdi));
>>> +}
>>> +
>>> +static void __csid_configure_top(struct csid_device *csid)
>>> +{
>>> + u32 val;
>>> +
>>> + /* CSID "top" is a new function in Titan780.
>>> + * CSID can connect to VFE & SFE(Sensor Front End).
>>> + * This connection is ontrolled by CSID "top".
>>> + * Only enable VFE path in current driver.
>>> + */
>>> + if (csid->top_base) {
>>
>> When is csid->top_base NULL ?
>>
>> Its required in your yaml.
>>
>
> csid->top_base is NULL when it is csid lite, I will add this info in yaml.
>
>
>>> +
>>> +static void csid_configure_stream(struct csid_device *csid, u8 enable)
>>> +{
>>> + u8 i;
>>> +
>>> + /* Loop through all enabled VCs and configure stream for each */
>>> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS; i++)
>>> + if (csid->phy.en_vc & BIT(i)) {
>>> + /* Configure CSID "top" */
>>> + __csid_configure_top(csid);
>>> + __csid_configure_rdi_stream(csid, enable, i);
>>> + __csid_configure_rx(csid, &csid->phy, i);
>>> + __csid_ctrl_rdi(csid, enable, i);
>>> + }
>>> +}
>>
>> I really like this breakdown
>
> Sorry, I don't get it, do you mean you like that configuring the
> different block use different functions, and no other meaning?
>
>>> +
>>> +static int csid_configure_testgen_pattern(struct csid_device *csid,
>>> s32 val)
>>> +{
>>> + if (val > 0 && val <= csid->testgen.nmodes)
>>> + csid->testgen.mode = val;
>>
>> Surely you should just set the val parameter directly ?
>>
>> Also why is this a signed integer and how does it get assigned a
>> negative value which we need to mitigate against here >
>
> This was copied from csid-gen2 driver, they are same, so we can move to
> common file.
>
> And the val comes from ctrl->val, so I guess this is the reason why this
> agrument is signed integer.
>
> struct v4l2_ctrl {
> ...
> s32 val;
> ...
> };
>
>
>
>>> +
>>> +static u32 csid_src_pad_code(struct csid_device *csid, u32 sink_code,
>>> + unsigned int match_format_idx, u32 match_code)
>>> +{
>>> + switch (sink_code) {
>>> + case MEDIA_BUS_FMT_SBGGR10_1X10:
>>> + {
>>> + u32 src_code[] = {
>>> + MEDIA_BUS_FMT_SBGGR10_1X10,
>>> + MEDIA_BUS_FMT_SBGGR10_2X8_PADHI_LE,
>>> + };
>>> +
>>> + return csid_find_code(src_code, ARRAY_SIZE(src_code),
>>> + match_format_idx, match_code);
>>> + }
>>> + case MEDIA_BUS_FMT_Y10_1X10:
>>> + {
>>> + u32 src_code[] = {
>>> + MEDIA_BUS_FMT_Y10_1X10,
>>> + MEDIA_BUS_FMT_Y10_2X8_PADHI_LE,
>>> + };
>>> +
>>> + return csid_find_code(src_code, ARRAY_SIZE(src_code),
>>> + match_format_idx, match_code);
>>> + }
>>> + default:
>>> + if (match_format_idx > 0)
>>> + return 0;
>>> +
>>> + return sink_code;
>>> + }
>>> +}
>>
>> Same code as in gen2.
>>
>> You could move the gen2 version of this into camss-csid.c and just
>> reuse in both.
>>
>
> Sure, it is same with the comments in vfe driver, I will try to move
> same code to camss-csid.c
>
> Thanks,
> Depeng
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices
2024-08-07 15:03 ` Depeng Shao
@ 2024-08-07 15:37 ` Bryan O'Donoghue
2024-08-08 14:02 ` Depeng Shao
0 siblings, 1 reply; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-08-07 15:37 UTC (permalink / raw)
To: Depeng Shao, Vladimir Zapolskiy, rfoss, todor.too, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
On 07/08/2024 16:03, Depeng Shao wrote:
> Hi Bryan,
>
> On 8/7/2024 10:04 PM, Bryan O'Donoghue wrote:
>> On 07/08/2024 14:08, Depeng Shao wrote:
>>> Hi Vladimir,
>>>
>>> On 8/5/2024 5:26 AM, Vladimir Zapolskiy wrote:
>>>> Hi Bryan,
>>>>
>>>> On 8/1/24 11:16, Bryan O'Donoghue wrote:
>>>>> On 01/08/2024 00:43, Vladimir Zapolskiy wrote:
>>>>>>> + ret = csiphy->res->hw_ops->init(csiphy);
>>>>>>
>>>>>> Here.
>>>>>
>>>>> What name would make more sense to you ?
>>>>
>>>> according to the implementation the .init() call just fills some
>>>> data in
>>>> memory, so I believe this could be handled at build time, if it's done
>>>> carefully enough...
>>>>
>>>
>>> This camss-csiphy-3ph-1-0.c is reused by many platforms, the old
>>> platforms have same CSI_COMMON_CTR register offset, their offset are
>>> 0x800, but some new platforms may have different CSI_COMMON_CTR
>>> register offset, for example, the CSI_COMMON_CTR register offset is
>>> 0x1000 in sm8550, then we need to add new file to support the new
>>> csiphy HW, e.g., camss-csiphy-3ph-2-0.c, so Bryan asked me to develop
>>> the CSIPHY driver based on his changes, then we just need few code to
>>> enable new CSIPHY.
>>>
>>> Regarding the hw_ops->init interface, since it fills HW register
>>> configurations and HW register offset, then maybe, it also can be
>>> called as HW operation.
>>>
>>> And looks like we can't move it to camss-csiphy.c since it does
>>> platform specific operation and it is related to the registers.
>>>
>>> Please feel free to share other comments if you don't agree with it.
>>> Thanks.
>>>
>>>
>>> Thanks,
>>> Depeng
>>
>> So, I agree the phy init data could be obtained via resource structs
>> but, rather than add yet more patches to this series, I'd say we can
>> make the move to a separate resource struct pointer at a later date.
>>
>> Lets drop this patch and @Depeng we can then do
>>
>
>> + regs->offset = 0x800;
>>
>> media: qcom: camss: csiphy-3ph: Use an offset variable to find common
>> control regs
>>
>
>
> Do you mean only drop "[PATCH 04/13] media: qcom: camss: csiphy: Add an
> init callback to CSI PHY devices"?
>
>
> [PATCH 05/13] media: qcom: camss: csiphy-3ph: Move CSIPHY variables to
> data field inside csiphy struct
> Do you mean this is still needed? Just don't move the code from
> csiphy_gen2_config_lanes to csiphy_init, right?
>
>
> [PATCH 06/13] media: qcom: camss: csiphy-3ph: Use an offset variable to
> find common control regs
> The offset change is also needed, just need to add the offset for
> different platform in csiphy_gen2_config_lanes .
>
> Please correct me if my understanding is wrong. Thanks.
Correct.
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices
2024-08-07 15:37 ` Bryan O'Donoghue
@ 2024-08-08 14:02 ` Depeng Shao
2024-08-12 11:32 ` Bryan O'Donoghue
0 siblings, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-08-08 14:02 UTC (permalink / raw)
To: Bryan O'Donoghue, Vladimir Zapolskiy, rfoss, todor.too,
mchehab, robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
Hi Bryan,
On 8/7/2024 11:37 PM, Bryan O'Donoghue wrote:
> On 07/08/2024 16:03, Depeng Shao wrote:
>> Hi Bryan,
>>
>> On 8/7/2024 10:04 PM, Bryan O'Donoghue wrote:
>>> On 07/08/2024 14:08, Depeng Shao wrote:
>>>> Hi Vladimir,
>>>>
>>>> On 8/5/2024 5:26 AM, Vladimir Zapolskiy wrote:
>>>>> Hi Bryan,
>>>>>
>>>>> On 8/1/24 11:16, Bryan O'Donoghue wrote:
>>>>>> On 01/08/2024 00:43, Vladimir Zapolskiy wrote:
>>>>>>>> + ret = csiphy->res->hw_ops->init(csiphy);
>>>>>>>
>>>>>>> Here.
>>>>>>
>>>>>> What name would make more sense to you ?
>>>>>
>>>>> according to the implementation the .init() call just fills some
>>>>> data in
>>>>> memory, so I believe this could be handled at build time, if it's done
>>>>> carefully enough...
>>>>>
>>>>
>>>> This camss-csiphy-3ph-1-0.c is reused by many platforms, the old
>>>> platforms have same CSI_COMMON_CTR register offset, their offset are
>>>> 0x800, but some new platforms may have different CSI_COMMON_CTR
>>>> register offset, for example, the CSI_COMMON_CTR register offset is
>>>> 0x1000 in sm8550, then we need to add new file to support the new
>>>> csiphy HW, e.g., camss-csiphy-3ph-2-0.c, so Bryan asked me to
>>>> develop the CSIPHY driver based on his changes, then we just need
>>>> few code to enable new CSIPHY.
>>>>
>>>> Regarding the hw_ops->init interface, since it fills HW register
>>>> configurations and HW register offset, then maybe, it also can be
>>>> called as HW operation.
>>>>
>>>> And looks like we can't move it to camss-csiphy.c since it does
>>>> platform specific operation and it is related to the registers.
>>>>
>>>> Please feel free to share other comments if you don't agree with it.
>>>> Thanks.
>>>>
>>>>
>>>> Thanks,
>>>> Depeng
>>>
>>> So, I agree the phy init data could be obtained via resource structs
>>> but, rather than add yet more patches to this series, I'd say we can
>>> make the move to a separate resource struct pointer at a later date.
>>>
>>> Lets drop this patch and @Depeng we can then do
>>>
>>
>>> + regs->offset = 0x800;
>>>
>>> media: qcom: camss: csiphy-3ph: Use an offset variable to find common
>>> control regs
>>>
>>
>>
>> Do you mean only drop "[PATCH 04/13] media: qcom: camss: csiphy: Add
>> an init callback to CSI PHY devices"?
>>
>>
>> [PATCH 05/13] media: qcom: camss: csiphy-3ph: Move CSIPHY variables to
>> data field inside csiphy struct
>> Do you mean this is still needed? Just don't move the code from
>> csiphy_gen2_config_lanes to csiphy_init, right?
>>
>>
>> [PATCH 06/13] media: qcom: camss: csiphy-3ph: Use an offset variable
>> to find common control regs
>> The offset change is also needed, just need to add the offset for
>> different platform in csiphy_gen2_config_lanes .
>>
>> Please correct me if my understanding is wrong. Thanks.
>
> Correct.
>
I'm updating the code based on above comments, but I meet crash issue if
I move the offset assignment to csiphy_gen2_config_lanes, since the
csiphy->res->hw_ops->reset(csiphy) is called earlier than
csiphy_gen2_config_lanes, so if we don't have the .init interface, we
only can move this offset value to `struct csiphy_subdev_resources`, but
if we add the offset to `struct csiphy_subdev_resources`, then below two
patches are also can be dropped.
[PATCH 05/13] media: qcom: camss: csiphy-3ph: Move CSIPHY variables to
data field inside csiphy struct
[PATCH 06/13] media: qcom: camss: csiphy-3ph: Use an offset variable to
find common control regs
Could you please comment on if I need to add the CSI_COMMON_CTR offset
to res directly?
Or add back the .init interface?
---
[ 43.162439] Unable to handle kernel NULL pointer dereference at
virtual address 000000000000000c
[ 43.428307] Call trace:
[ 43.430823] csiphy_reset+0x28/0x60 [qcom_camss]
[ 43.435572] csiphy_set_power+0x1e8/0x2d4 [qcom_camss]
[ 43.440846] pipeline_pm_power_one+0x74/0x10c [videodev]
[ 43.446306] pipeline_pm_power+0x44/0xe0 [videodev]
[ 43.451313] v4l2_pipeline_pm_get+0x44/0x80 [videodev]
[ 43.456588] video_open+0x6c/0xc4 [qcom_camss]
[ 43.461158] v4l2_open+0xb8/0x100 [videodev]
[ 43.465549] chrdev_open+0x174/0x208
[ 43.469224] do_dentry_open+0x290/0x4b4
[ 43.473164] vfs_open+0x30/0xf0
[ 43.476397] path_openat+0xaec/0xd2c
[ 43.480069] do_filp_open+0xb4/0x158
[ 43.483739] do_sys_openat2+0x84/0xe8
[ 43.487500] __arm64_sys_openat+0x70/0x98
[ 43.491619] invoke_syscall+0x40/0xf8
[ 43.495383] el0_svc_common+0xa8/0xd8
[ 43.499143] do_el0_svc+0x1c/0x28
[ 43.502545] el0_svc+0x38/0x68
[ 43.505691] el0t_64_sync_handler+0x90/0xfc
[ 43.509989] el0t_64_sync+0x190/0x194
[ 43.513751] Code: 52800028 aa0003f3 52827100 5283e801 (b9400e8a)
[ 43.520010] ---[ end trace 0000000000000000 ]---
Segmentation fault
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices
2024-08-08 14:02 ` Depeng Shao
@ 2024-08-12 11:32 ` Bryan O'Donoghue
2024-08-12 12:20 ` Depeng Shao
0 siblings, 1 reply; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-08-12 11:32 UTC (permalink / raw)
To: Depeng Shao, Vladimir Zapolskiy, rfoss, todor.too, mchehab, robh,
krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
On 08/08/2024 15:02, Depeng Shao wrote:
> I'm updating the code based on above comments, but I meet crash issue if
> I move the offset assignment to csiphy_gen2_config_lanes, since the
> csiphy->res->hw_ops->reset(csiphy) is called earlier than
> csiphy_gen2_config_lanes, so if we don't have the .init interface, we
> only can move this offset value to `struct csiphy_subdev_resources`, but
> if we add the offset to `struct csiphy_subdev_resources`, then below two
> patches are also can be dropped.
>
>
> [PATCH 05/13] media: qcom: camss: csiphy-3ph: Move CSIPHY variables to
> data field inside csiphy struct
> [PATCH 06/13] media: qcom: camss: csiphy-3ph: Use an offset variable to
> find common control regs
>
>
> Could you please comment on if I need to add the CSI_COMMON_CTR offset
> to res directly?
> Or add back the .init interface?
Ah, I hadn't recalled why the .init was added -> because sequencing.
Lets retain the patch but expand the commit log to explain why the init
is being added, instead of jumping through hoops to restructure to get
rid of it.
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices
2024-08-12 11:32 ` Bryan O'Donoghue
@ 2024-08-12 12:20 ` Depeng Shao
0 siblings, 0 replies; 99+ messages in thread
From: Depeng Shao @ 2024-08-12 12:20 UTC (permalink / raw)
To: Bryan O'Donoghue, Vladimir Zapolskiy, rfoss, todor.too,
mchehab, robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
Hi Bryan,
On 8/12/2024 7:32 PM, Bryan O'Donoghue wrote:
>
> Ah, I hadn't recalled why the .init was added -> because sequencing.
>
> Lets retain the patch but expand the commit log to explain why the init
> is being added, instead of jumping through hoops to restructure to get
> rid of it.
>
Thanks for the confirmation. I will retain the patch and add more commit
log.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-08-12 14:41 [PATCH v4 " Depeng Shao
@ 2024-08-12 14:41 ` Depeng Shao
2024-08-16 7:01 ` Krzysztof Kozlowski
` (3 more replies)
0 siblings, 4 replies; 99+ messages in thread
From: Depeng Shao @ 2024-08-12 14:41 UTC (permalink / raw)
To: rfoss, todor.too, bryan.odonoghue, mchehab, robh, krzk+dt,
conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
quic_depengs, Yongsheng Li
Add bindings for qcom,sm8550-camss in order to support the camera
subsystem for sm8550.
Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
---
.../bindings/media/qcom,sm8550-camss.yaml | 517 ++++++++++++++++++
1 file changed, 517 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml
diff --git a/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml
new file mode 100644
index 000000000000..2d6c5a42eeda
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,sm8550-camss.yaml
@@ -0,0 +1,517 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,sm8550-camss.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SM8550 Camera Subsystem (CAMSS)
+
+maintainers:
+ - Depeng Shao <quic_depengs@quicinc.com>
+
+description:
+ The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms.
+
+properties:
+ compatible:
+ const: qcom,sm8550-camss
+
+ reg:
+ maxItems: 19
+
+ reg-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csid_top
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: csiphy5
+ - const: csiphy6
+ - const: csiphy7
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ clocks:
+ maxItems: 36
+
+ clock-names:
+ items:
+ - const: camnoc_axi
+ - const: cpas_ahb
+ - const: cpas_fast_ahb_clk
+ - const: cpas_ife_lite
+ - const: cpas_vfe0
+ - const: cpas_vfe1
+ - const: cpas_vfe2
+ - const: csid
+ - const: csiphy0
+ - const: csiphy0_timer
+ - const: csiphy1
+ - const: csiphy1_timer
+ - const: csiphy2
+ - const: csiphy2_timer
+ - const: csiphy3
+ - const: csiphy3_timer
+ - const: csiphy4
+ - const: csiphy4_timer
+ - const: csiphy5
+ - const: csiphy5_timer
+ - const: csiphy6
+ - const: csiphy6_timer
+ - const: csiphy7
+ - const: csiphy7_timer
+ - const: csiphy_rx
+ - const: vfe0
+ - const: vfe0_fast_ahb
+ - const: vfe1
+ - const: vfe1_fast_ahb
+ - const: vfe2
+ - const: vfe2_fast_ahb
+ - const: vfe_lite
+ - const: vfe_lite_ahb
+ - const: vfe_lite_cphy_rx
+ - const: vfe_lite_csid
+ - const: gcc_axi_hf
+
+ interconnects:
+ maxItems: 4
+
+ interconnect-names:
+ items:
+ - const: ahb
+ - const: hf_0_mnoc
+ - const: icp_mnoc
+ - const: sf_0_mnoc
+
+ interrupts:
+ maxItems: 18
+
+ interrupt-names:
+ items:
+ - const: csid0
+ - const: csid1
+ - const: csid2
+ - const: csid_lite0
+ - const: csid_lite1
+ - const: csiphy0
+ - const: csiphy1
+ - const: csiphy2
+ - const: csiphy3
+ - const: csiphy4
+ - const: csiphy5
+ - const: csiphy6
+ - const: csiphy7
+ - const: vfe0
+ - const: vfe1
+ - const: vfe2
+ - const: vfe_lite0
+ - const: vfe_lite1
+
+ iommus:
+ maxItems: 1
+
+ power-domains:
+ items:
+ - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: IFE2 GDSC - Image Front End, Global Distributed Switch Controller.
+ - description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller.
+
+ power-domain-names:
+ items:
+ - const: ife0
+ - const: ife1
+ - const: ife2
+ - const: top
+
+ vdda-phy-supply:
+ description:
+ Phandle to a regulator supply to PHY core block.
+
+ vdda-pll-supply:
+ description:
+ Phandle to 1.2V regulator supply to PHY refclk pll block.
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ description:
+ CSI input ports.
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@1:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@2:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@3:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@4:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+ port@5:
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
+ description:
+ Input port for receiving CSI data.
+
+ properties:
+ endpoint:
+ $ref: video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ clock-lanes:
+ maxItems: 1
+
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+
+ required:
+ - clock-lanes
+ - data-lanes
+
+required:
+ - compatible
+ - clocks
+ - clock-names
+ - interconnects
+ - interconnect-names
+ - interrupts
+ - interrupt-names
+ - iommus
+ - power-domains
+ - power-domain-names
+ - reg
+ - reg-names
+ - vdda-phy-supply
+ - vdda-pll-supply
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,rpmh.h>
+ #include <dt-bindings/clock/qcom,sm8550-camcc.h>
+ #include <dt-bindings/clock/qcom,sm8550-gcc.h>
+ #include <dt-bindings/interconnect/qcom,sm8550-rpmh.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/qcom-rpmpd.h>
+
+ soc {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ camss: camss@ace4000 {
+ compatible = "qcom,sm8550-camss";
+
+ reg = <0 0x0acb7000 0 0xd00>,
+ <0 0x0acb9000 0 0xd00>,
+ <0 0x0acbb000 0 0xd00>,
+ <0 0x0acca000 0 0xa00>,
+ <0 0x0acce000 0 0xa00>,
+ <0 0x0acb6000 0 0x1000>,
+ <0 0x0ace4000 0 0x2000>,
+ <0 0x0ace6000 0 0x2000>,
+ <0 0x0ace8000 0 0x2000>,
+ <0 0x0acea000 0 0x2000>,
+ <0 0x0acec000 0 0x2000>,
+ <0 0x0acee000 0 0x2000>,
+ <0 0x0acf0000 0 0x2000>,
+ <0 0x0acf2000 0 0x2000>,
+ <0 0x0ac62000 0 0xf000>,
+ <0 0x0ac71000 0 0xf000>,
+ <0 0x0ac80000 0 0xf000>,
+ <0 0x0accb000 0 0x2800>,
+ <0 0x0accf000 0 0x2800>;
+ reg-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csid_top",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "csiphy6",
+ "csiphy7",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ clocks = <&camcc CAM_CC_CAMNOC_AXI_CLK>,
+ <&camcc CAM_CC_CPAS_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_FAST_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_LITE_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_0_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_1_CLK>,
+ <&camcc CAM_CC_CPAS_IFE_2_CLK>,
+ <&camcc CAM_CC_CSID_CLK>,
+ <&camcc CAM_CC_CSIPHY0_CLK>,
+ <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY1_CLK>,
+ <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY2_CLK>,
+ <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY3_CLK>,
+ <&camcc CAM_CC_CSI3PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY4_CLK>,
+ <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY5_CLK>,
+ <&camcc CAM_CC_CSI5PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY6_CLK>,
+ <&camcc CAM_CC_CSI6PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSIPHY7_CLK>,
+ <&camcc CAM_CC_CSI7PHYTIMER_CLK>,
+ <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_0_CLK>,
+ <&camcc CAM_CC_IFE_0_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_1_CLK>,
+ <&camcc CAM_CC_IFE_1_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_2_CLK>,
+ <&camcc CAM_CC_IFE_2_FAST_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CLK>,
+ <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
+ <&camcc CAM_CC_IFE_LITE_CSID_CLK>,
+ <&gcc GCC_CAMERA_HF_AXI_CLK>;
+
+ clock-names = "camnoc_axi",
+ "cpas_ahb",
+ "cpas_fast_ahb_clk",
+ "cpas_ife_lite",
+ "cpas_vfe0",
+ "cpas_vfe1",
+ "cpas_vfe2",
+ "csid",
+ "csiphy0",
+ "csiphy0_timer",
+ "csiphy1",
+ "csiphy1_timer",
+ "csiphy2",
+ "csiphy2_timer",
+ "csiphy3",
+ "csiphy3_timer",
+ "csiphy4",
+ "csiphy4_timer",
+ "csiphy5",
+ "csiphy5_timer",
+ "csiphy6",
+ "csiphy6_timer",
+ "csiphy7",
+ "csiphy7_timer",
+ "csiphy_rx",
+ "vfe0",
+ "vfe0_fast_ahb",
+ "vfe1",
+ "vfe1_fast_ahb",
+ "vfe2",
+ "vfe2_fast_ahb",
+ "vfe_lite",
+ "vfe_lite_ahb",
+ "vfe_lite_cphy_rx",
+ "vfe_lite_csid",
+ "gcc_axi_hf";
+
+ interconnects = <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_CAMERA_CFG 0>,
+ <&mmss_noc MASTER_CAMNOC_HF 0 &mc_virt SLAVE_EBI1 0>,
+ <&mmss_noc MASTER_CAMNOC_ICP 0 &mc_virt SLAVE_EBI1 0>,
+ <&mmss_noc MASTER_CAMNOC_SF 0 &mc_virt SLAVE_EBI1 0>;
+ interconnect-names = "ahb",
+ "hf_0_mnoc",
+ "icp_mnoc",
+ "sf_0_mnoc";
+
+ interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 431 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 477 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 278 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 277 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 688 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
+
+ interrupt-names = "csid0",
+ "csid1",
+ "csid2",
+ "csid_lite0",
+ "csid_lite1",
+ "csiphy0",
+ "csiphy1",
+ "csiphy2",
+ "csiphy3",
+ "csiphy4",
+ "csiphy5",
+ "csiphy6",
+ "csiphy7",
+ "vfe0",
+ "vfe1",
+ "vfe2",
+ "vfe_lite0",
+ "vfe_lite1";
+
+ iommus = <&apps_smmu 0x800 0x20>;
+
+ power-domains = <&camcc CAM_CC_IFE_0_GDSC>,
+ <&camcc CAM_CC_IFE_1_GDSC>,
+ <&camcc CAM_CC_IFE_2_GDSC>,
+ <&camcc CAM_CC_TITAN_TOP_GDSC>;
+
+ power-domain-names = "ife0",
+ "ife1",
+ "ife2",
+ "top";
+
+ vdda-phy-supply = <&vreg_l1e_0p88>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csiphy_ep0: endpoint@0 {
+ reg = <0>;
+ clock-lanes = <7>;
+ data-lanes = <0 1>;
+ remote-endpoint = <&sensor_ep>;
+ };
+ };
+ };
+ };
+ };
--
2.34.1
^ permalink raw reply related [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-08-12 14:41 ` [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding Depeng Shao
@ 2024-08-16 7:01 ` Krzysztof Kozlowski
2024-08-16 7:45 ` Depeng Shao
2024-09-05 15:20 ` Vladimir Zapolskiy
` (2 subsequent siblings)
3 siblings, 1 reply; 99+ messages in thread
From: Krzysztof Kozlowski @ 2024-08-16 7:01 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 12/08/2024 16:41, Depeng Shao wrote:
> Add bindings for qcom,sm8550-camss in order to support the camera
> subsystem for sm8550.
>
> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
...
> +
> +required:
> + - compatible
> + - clocks
> + - clock-names
> + - interconnects
> + - interconnect-names
> + - interrupts
> + - interrupt-names
> + - iommus
> + - power-domains
> + - power-domain-names
> + - reg
> + - reg-names
> + - vdda-phy-supply
> + - vdda-pll-supply
Order is still not as expected. I already commented on this - keep the
same order as in "properties:" block.
With the order fixed:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-08-16 7:01 ` Krzysztof Kozlowski
@ 2024-08-16 7:45 ` Depeng Shao
2024-09-30 7:17 ` Krzysztof Kozlowski
0 siblings, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-08-16 7:45 UTC (permalink / raw)
To: Krzysztof Kozlowski, rfoss, todor.too, bryan.odonoghue, mchehab,
robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hi Krzysztof,
On 8/16/2024 3:01 PM, Krzysztof Kozlowski wrote:
>> +required:
>> + - compatible
>> + - clocks
>> + - clock-names
>> + - interconnects
>> + - interconnect-names
>> + - interrupts
>> + - interrupt-names
>> + - iommus
>> + - power-domains
>> + - power-domain-names
>> + - reg
>> + - reg-names
>> + - vdda-phy-supply
>> + - vdda-pll-supply
>
> Order is still not as expected. I already commented on this - keep the
> same order as in "properties:" block.
>
> With the order fixed:
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>
Thanks for catching this, the order was correct in my local build, then
Vladimir posted a new comment, so I updated it again and forgot to
update the required item, I will correct the order in next version series.
Vladimir: "I would suggest to put 'compatible', 'reg' and 'reg-names'
properties as the first ones. 'clock-names' should follow 'clocks'
property in the list."
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH V3 00/13] media: qcom: camss: Add sm8550 support
2024-07-09 16:06 [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (13 preceding siblings ...)
2024-07-10 11:08 ` [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Krzysztof Kozlowski
@ 2024-08-24 17:05 ` Bryan O'Donoghue
14 siblings, 0 replies; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-08-24 17:05 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: quic_eberman, linux-media, linux-arm-msm, devicetree,
linux-kernel, kernel
> media: qcom: camss: Add CSID Gen3 support for SM8550
> media: qcom: camss: Add support for VFE hardware version Titan 780
Before your post your next version of this series, please make the patch
submission titles consistent.
e.g.
Add CSID 780 support
Add VFE 780 support
Mixing SoC versions "sm8550" and/or including "Titan" - what's that a
reader might ask - should be avoided.
No harm in including "Titan" but if you do, include it in both patches
and explain that Titan is the codename of the camera block in your SoC.
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-08-12 14:41 ` [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding Depeng Shao
2024-08-16 7:01 ` Krzysztof Kozlowski
@ 2024-09-05 15:20 ` Vladimir Zapolskiy
2024-09-05 15:54 ` Depeng Shao
2024-09-06 15:56 ` Vladimir Zapolskiy
2024-09-12 8:22 ` Vladimir Zapolskiy
3 siblings, 1 reply; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-09-05 15:20 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hello Depeng.
On 8/12/24 17:41, Depeng Shao wrote:
> Add bindings for qcom,sm8550-camss in order to support the camera
> subsystem for sm8550.
>
> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
<snip>
> +
> + interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 431 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 477 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 278 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 277 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 688 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
Please change all interrupt types to IRQ_TYPE_EDGE_RISING, this
will match the type set by the camss driver itself, and I believe
a rising edge interrupt here is correct.
A similar change would be needed in the dts file change.
> +
> + interrupt-names = "csid0",
> + "csid1",
> + "csid2",
> + "csid_lite0",
> + "csid_lite1",
> + "csiphy0",
> + "csiphy1",
> + "csiphy2",
> + "csiphy3",
> + "csiphy4",
> + "csiphy5",
> + "csiphy6",
> + "csiphy7",
> + "vfe0",
> + "vfe1",
> + "vfe2",
> + "vfe_lite0",
> + "vfe_lite1";
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-05 15:20 ` Vladimir Zapolskiy
@ 2024-09-05 15:54 ` Depeng Shao
0 siblings, 0 replies; 99+ messages in thread
From: Depeng Shao @ 2024-09-05 15:54 UTC (permalink / raw)
To: Vladimir Zapolskiy, rfoss, todor.too, bryan.odonoghue, mchehab,
robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hi Vladimir,
On 9/5/2024 11:20 PM, Vladimir Zapolskiy wrote:
> Hello Depeng.
>
> On 8/12/24 17:41, Depeng Shao wrote:
>> Add bindings for qcom,sm8550-camss in order to support the camera
>> subsystem for sm8550.
>>
>> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
>> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
>> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
>
> <snip>
>
>> +
>> + interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 431 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 477 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 278 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 277 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 688 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
>
> Please change all interrupt types to IRQ_TYPE_EDGE_RISING, this
> will match the type set by the camss driver itself, and I believe
> a rising edge interrupt here is correct.
>
> A similar change would be needed in the dts file change.
>
Sure, I will try this change. Thanks for the comments.
>> +
>> + interrupt-names = "csid0",
>> + "csid1",
>> + "csid2",
>> + "csid_lite0",
>> + "csid_lite1",
>> + "csiphy0",
>> + "csiphy1",
>> + "csiphy2",
>> + "csiphy3",
>> + "csiphy4",
>> + "csiphy5",
>> + "csiphy6",
>> + "csiphy7",
>> + "vfe0",
>> + "vfe1",
>> + "vfe2",
>> + "vfe_lite0",
>> + "vfe_lite1";
>
> --
> Best wishes,
> Vladimir
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-08-12 14:41 ` [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding Depeng Shao
2024-08-16 7:01 ` Krzysztof Kozlowski
2024-09-05 15:20 ` Vladimir Zapolskiy
@ 2024-09-06 15:56 ` Vladimir Zapolskiy
2024-09-25 15:13 ` Depeng Shao
2024-09-12 8:22 ` Vladimir Zapolskiy
3 siblings, 1 reply; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-09-06 15:56 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hi Depeng,
On 8/12/24 17:41, Depeng Shao wrote:
> Add bindings for qcom,sm8550-camss in order to support the camera
> subsystem for sm8550.
>
> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
there are a few more things, which I noticed.
> +
> + soc {
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + camss: camss@ace4000 {
> + compatible = "qcom,sm8550-camss";
> +
> + reg = <0 0x0acb7000 0 0xd00>,
> + <0 0x0acb9000 0 0xd00>,
> + <0 0x0acbb000 0 0xd00>,
> + <0 0x0acca000 0 0xa00>,
> + <0 0x0acce000 0 0xa00>,
> + <0 0x0acb6000 0 0x1000>,
> + <0 0x0ace4000 0 0x2000>,
> + <0 0x0ace6000 0 0x2000>,
> + <0 0x0ace8000 0 0x2000>,
> + <0 0x0acea000 0 0x2000>,
> + <0 0x0acec000 0 0x2000>,
> + <0 0x0acee000 0 0x2000>,
> + <0 0x0acf0000 0 0x2000>,
> + <0 0x0acf2000 0 0x2000>,
> + <0 0x0ac62000 0 0xf000>,
> + <0 0x0ac71000 0 0xf000>,
> + <0 0x0ac80000 0 0xf000>,
> + <0 0x0accb000 0 0x2800>,
> + <0 0x0accf000 0 0x2800>;
Please sort the list above in numerical order, this will change positions
of "vfe_lite0", "vfe_lite1" etc.
Another note, since it's not possible to map less than a page, so I believe
it might make sense to align all sizes to 0x1000.
> + reg-names = "csid0",
> + "csid1",
> + "csid2",
> + "csid_lite0",
> + "csid_lite1",
> + "csid_top",
> + "csiphy0",
> + "csiphy1",
> + "csiphy2",
> + "csiphy3",
> + "csiphy4",
> + "csiphy5",
> + "csiphy6",
> + "csiphy7",
> + "vfe0",
> + "vfe1",
> + "vfe2",
> + "vfe_lite0",
> + "vfe_lite1";
> +
> + clocks = <&camcc CAM_CC_CAMNOC_AXI_CLK>,
> + <&camcc CAM_CC_CPAS_AHB_CLK>,
> + <&camcc CAM_CC_CPAS_FAST_AHB_CLK>,
> + <&camcc CAM_CC_CPAS_IFE_LITE_CLK>,
> + <&camcc CAM_CC_CPAS_IFE_0_CLK>,
> + <&camcc CAM_CC_CPAS_IFE_1_CLK>,
> + <&camcc CAM_CC_CPAS_IFE_2_CLK>,
> + <&camcc CAM_CC_CSID_CLK>,
> + <&camcc CAM_CC_CSIPHY0_CLK>,
> + <&camcc CAM_CC_CSI0PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY1_CLK>,
> + <&camcc CAM_CC_CSI1PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY2_CLK>,
> + <&camcc CAM_CC_CSI2PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY3_CLK>,
> + <&camcc CAM_CC_CSI3PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY4_CLK>,
> + <&camcc CAM_CC_CSI4PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY5_CLK>,
> + <&camcc CAM_CC_CSI5PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY6_CLK>,
> + <&camcc CAM_CC_CSI6PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSIPHY7_CLK>,
> + <&camcc CAM_CC_CSI7PHYTIMER_CLK>,
> + <&camcc CAM_CC_CSID_CSIPHY_RX_CLK>,
> + <&camcc CAM_CC_IFE_0_CLK>,
> + <&camcc CAM_CC_IFE_0_FAST_AHB_CLK>,
> + <&camcc CAM_CC_IFE_1_CLK>,
> + <&camcc CAM_CC_IFE_1_FAST_AHB_CLK>,
> + <&camcc CAM_CC_IFE_2_CLK>,
> + <&camcc CAM_CC_IFE_2_FAST_AHB_CLK>,
> + <&camcc CAM_CC_IFE_LITE_CLK>,
> + <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
> + <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
> + <&camcc CAM_CC_IFE_LITE_CSID_CLK>,
> + <&gcc GCC_CAMERA_HF_AXI_CLK>;
Could you please put the &gcc provided clock as the first one in the list?
> +
> + clock-names = "camnoc_axi",
> + "cpas_ahb",
> + "cpas_fast_ahb_clk",
> + "cpas_ife_lite",
> + "cpas_vfe0",
> + "cpas_vfe1",
> + "cpas_vfe2",
> + "csid",
> + "csiphy0",
> + "csiphy0_timer",
> + "csiphy1",
> + "csiphy1_timer",
> + "csiphy2",
> + "csiphy2_timer",
> + "csiphy3",
> + "csiphy3_timer",
> + "csiphy4",
> + "csiphy4_timer",
> + "csiphy5",
> + "csiphy5_timer",
> + "csiphy6",
> + "csiphy6_timer",
> + "csiphy7",
> + "csiphy7_timer",
> + "csiphy_rx",
> + "vfe0",
> + "vfe0_fast_ahb",
> + "vfe1",
> + "vfe1_fast_ahb",
> + "vfe2",
> + "vfe2_fast_ahb",
> + "vfe_lite",
> + "vfe_lite_ahb",
> + "vfe_lite_cphy_rx",
> + "vfe_lite_csid",
> + "gcc_axi_hf";
> +
> + interconnects = <&gem_noc MASTER_APPSS_PROC 0 &config_noc SLAVE_CAMERA_CFG 0>,
> + <&mmss_noc MASTER_CAMNOC_HF 0 &mc_virt SLAVE_EBI1 0>,
> + <&mmss_noc MASTER_CAMNOC_ICP 0 &mc_virt SLAVE_EBI1 0>,
> + <&mmss_noc MASTER_CAMNOC_SF 0 &mc_virt SLAVE_EBI1 0>;
> + interconnect-names = "ahb",
> + "hf_0_mnoc",
> + "icp_mnoc",
> + "sf_0_mnoc";
Just a note for myself, interconnect names lost "cam_" prefix, and it should
be fine.
> +
> + interrupts = <GIC_SPI 601 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 603 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 431 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 605 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 477 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 278 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 277 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 602 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 604 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 688 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 606 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 377 IRQ_TYPE_LEVEL_HIGH>;
> +
> + interrupt-names = "csid0",
> + "csid1",
> + "csid2",
> + "csid_lite0",
> + "csid_lite1",
> + "csiphy0",
> + "csiphy1",
> + "csiphy2",
> + "csiphy3",
> + "csiphy4",
> + "csiphy5",
> + "csiphy6",
> + "csiphy7",
> + "vfe0",
> + "vfe1",
> + "vfe2",
> + "vfe_lite0",
> + "vfe_lite1";
> +
> + iommus = <&apps_smmu 0x800 0x20>;
> +
> + power-domains = <&camcc CAM_CC_IFE_0_GDSC>,
> + <&camcc CAM_CC_IFE_1_GDSC>,
> + <&camcc CAM_CC_IFE_2_GDSC>,
> + <&camcc CAM_CC_TITAN_TOP_GDSC>;
> +
> + power-domain-names = "ife0",
> + "ife1",
> + "ife2",
> + "top";
> +
> + vdda-phy-supply = <&vreg_l1e_0p88>;
> + vdda-pll-supply = <&vreg_l3e_1p2>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
In case of a single child node #address-cells/#size-cells could be omitted,
if I'm not mistaken about it...
> + port@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
Same as above.
> +
> + csiphy_ep0: endpoint@0 {
> + reg = <0>;
> + clock-lanes = <7>;
> + data-lanes = <0 1>;
> + remote-endpoint = <&sensor_ep>;
> + };
> + };
> + };
> + };
> + };
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-08-12 14:41 ` [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding Depeng Shao
` (2 preceding siblings ...)
2024-09-06 15:56 ` Vladimir Zapolskiy
@ 2024-09-12 8:22 ` Vladimir Zapolskiy
2024-09-12 11:41 ` Bryan O'Donoghue
3 siblings, 1 reply; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-09-12 8:22 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt, Neil Armstrong
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hi Depeng,
I do have one more ask for a change.
On 8/12/24 17:41, Depeng Shao wrote:
> Add bindings for qcom,sm8550-camss in order to support the camera
> subsystem for sm8550.
>
> Co-developed-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Yongsheng Li <quic_yon@quicinc.com>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
<snip>
> +
> + vdda-phy-supply:
> + description:
> + Phandle to a regulator supply to PHY core block.
> +
> + vdda-pll-supply:
> + description:
> + Phandle to 1.2V regulator supply to PHY refclk pll block.
> +
Here the supplies should be split into ones, which are specific to CSI blocks,
and I believe they shall be set as optional.
The proposed names are:
vdda-phy-01-supply
vdda-pll-01-supply
vdda-phy-23-supply
vdda-pll-23-supply
vdda-phy-46-supply
vdda-pll-46-supply
vdda-phy-57-supply
vdda-pll-57-supply
I understand that what I ask is much more clumsy, and it could be seen even as
unneeded, however it'll be the right set of properties to describe the CAMSS IP
in this respect.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-12 8:22 ` Vladimir Zapolskiy
@ 2024-09-12 11:41 ` Bryan O'Donoghue
2024-09-12 12:44 ` Vladimir Zapolskiy
2024-09-12 13:48 ` Neil Armstrong
0 siblings, 2 replies; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-09-12 11:41 UTC (permalink / raw)
To: Vladimir Zapolskiy, Depeng Shao, rfoss, todor.too, mchehab, robh,
krzk+dt, conor+dt, Neil Armstrong
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 12/09/2024 09:22, Vladimir Zapolskiy wrote:
>> +
>> + vdda-phy-supply:
>> + description:
>> + Phandle to a regulator supply to PHY core block.
>> +
>> + vdda-pll-supply:
>> + description:
>> + Phandle to 1.2V regulator supply to PHY refclk pll block.
>> +
>
> Here the supplies should be split into ones, which are specific to CSI
> blocks,
> and I believe they shall be set as optional.
In principle I agree with that, each CSIPHY should have its own vdda-phy
and vdda-pll regulator specified.
In practice though I don't believe its necessary, below.
> The proposed names are:
>
> vdda-phy-01-supply
> vdda-pll-01-supply
> vdda-phy-23-supply
> vdda-pll-23-supply
> vdda-phy-46-supply
> vdda-pll-46-supply
> vdda-phy-57-supply
> vdda-pll-57-supply
In principle, you're right, we need to expand the name set here.
> I understand that what I ask is much more clumsy, and it could be seen
> even as
> unneeded, however it'll be the right set of properties to describe the
> CAMSS IP
> in this respect
I think the following naming would be better as it matches the
power-grid naming in the docs.
csiphyX-vdda-phy-supply
csiphyX-vdda-pll-supply
=>
// voltage domain = vdd_a_csi_01_09 = regulator l1e
csiphy0-vdda-phy-supply = <&vreg_l1e_0p9>;
// voltage domain = vdd_a_csi_01_1p2 = regulator l3e
csiphy0-vdda-pll-supply = <&vreg_l3e_1p2>;
//
csiphy1-vdda-phy-supply = <&vreg_l1e_0p9>;
csiphy1-vdda-pll-supply = <&vreg_l3e_1p2>;
Where X indicates the CSIPHY number.
So in fact, in practice we don't need to differentiate these entries.
Checking x1e80100 ...
csiphy0
vdda-phy-supply = <&vreg_l2c_0p9>;
vdda-pll-supply = <&vreg_l1c_1p2>;
This is also the case for csiphy 1/2/4
So, I _don't_ believe this is work we need to do, since its the same
regulator for each PHY.
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-12 11:41 ` Bryan O'Donoghue
@ 2024-09-12 12:44 ` Vladimir Zapolskiy
2024-09-12 15:11 ` Bryan O'Donoghue
2024-09-12 13:48 ` Neil Armstrong
1 sibling, 1 reply; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-09-12 12:44 UTC (permalink / raw)
To: Bryan O'Donoghue, Depeng Shao, rfoss, todor.too, mchehab,
robh, krzk+dt, conor+dt, Neil Armstrong
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hi Bryan.
On 9/12/24 14:41, Bryan O'Donoghue wrote:
> On 12/09/2024 09:22, Vladimir Zapolskiy wrote:
>>> +
>>> + vdda-phy-supply:
>>> + description:
>>> + Phandle to a regulator supply to PHY core block.
>>> +
>>> + vdda-pll-supply:
>>> + description:
>>> + Phandle to 1.2V regulator supply to PHY refclk pll block.
>>> +
>>
>> Here the supplies should be split into ones, which are specific to CSI
>> blocks,
>> and I believe they shall be set as optional.
>
> In principle I agree with that, each CSIPHY should have its own vdda-phy
> and vdda-pll regulator specified.
>
> In practice though I don't believe its necessary, below.
>
>> The proposed names are:
>>
>> vdda-phy-01-supply
>> vdda-pll-01-supply
>> vdda-phy-23-supply
>> vdda-pll-23-supply
>> vdda-phy-46-supply
>> vdda-pll-46-supply
>> vdda-phy-57-supply
>> vdda-pll-57-supply
>
> In principle, you're right, we need to expand the name set here.
>
>> I understand that what I ask is much more clumsy, and it could be seen
>> even as
>> unneeded, however it'll be the right set of properties to describe the
>> CAMSS IP
>> in this respect
> I think the following naming would be better as it matches the
> power-grid naming in the docs.
>
> csiphyX-vdda-phy-supply
> csiphyX-vdda-pll-supply
I have no opinion about the names, any reason for name selection is
good for me.
> =>
>
> // voltage domain = vdd_a_csi_01_09 = regulator l1e
> csiphy0-vdda-phy-supply = <&vreg_l1e_0p9>;
>
> // voltage domain = vdd_a_csi_01_1p2 = regulator l3e
> csiphy0-vdda-pll-supply = <&vreg_l3e_1p2>;
>
> //
> csiphy1-vdda-phy-supply = <&vreg_l1e_0p9>;
> csiphy1-vdda-pll-supply = <&vreg_l3e_1p2>;
>
> Where X indicates the CSIPHY number.
>
> So in fact, in practice we don't need to differentiate these entries.
>
> Checking x1e80100 ...
Checking some particular board, right?
> csiphy0
>
> vdda-phy-supply = <&vreg_l2c_0p9>;
> vdda-pll-supply = <&vreg_l1c_1p2>;
>
> This is also the case for csiphy 1/2/4
>
> So, I _don't_ believe this is work we need to do, since its the same
> regulator for each PHY.
This is board specific, and even if the separation is not needed on the boards
you have just checked, still it may be needed on some boards, which are not yet
checked/not yet known.
It's needed to make the best predictions about all possible usage of hardware,
fortunately it's easy in this particular case, and it's trivial to correct it now
than on some day later on.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-12 11:41 ` Bryan O'Donoghue
2024-09-12 12:44 ` Vladimir Zapolskiy
@ 2024-09-12 13:48 ` Neil Armstrong
1 sibling, 0 replies; 99+ messages in thread
From: Neil Armstrong @ 2024-09-12 13:48 UTC (permalink / raw)
To: Bryan O'Donoghue, Vladimir Zapolskiy, Depeng Shao, rfoss,
todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 12/09/2024 13:41, Bryan O'Donoghue wrote:
> On 12/09/2024 09:22, Vladimir Zapolskiy wrote:
>>> +
>>> + vdda-phy-supply:
>>> + description:
>>> + Phandle to a regulator supply to PHY core block.
>>> +
>>> + vdda-pll-supply:
>>> + description:
>>> + Phandle to 1.2V regulator supply to PHY refclk pll block.
>>> +
>>
>> Here the supplies should be split into ones, which are specific to CSI blocks,
>> and I believe they shall be set as optional.
>
> In principle I agree with that, each CSIPHY should have its own vdda-phy and vdda-pll regulator specified.
>
> In practice though I don't believe its necessary, below.
>
>> The proposed names are:
>>
>> vdda-phy-01-supply
>> vdda-pll-01-supply
>> vdda-phy-23-supply
>> vdda-pll-23-supply
>> vdda-phy-46-supply
>> vdda-pll-46-supply
>> vdda-phy-57-supply
>> vdda-pll-57-supply
>
> In principle, you're right, we need to expand the name set here.
>
>> I understand that what I ask is much more clumsy, and it could be seen even as
>> unneeded, however it'll be the right set of properties to describe the CAMSS IP
>> in this respect
> I think the following naming would be better as it matches the power-grid naming in the docs.
>
> csiphyX-vdda-phy-supply
> csiphyX-vdda-pll-supply
>
> =>
>
> // voltage domain = vdd_a_csi_01_09 = regulator l1e
> csiphy0-vdda-phy-supply = <&vreg_l1e_0p9>;
>
> // voltage domain = vdd_a_csi_01_1p2 = regulator l3e
> csiphy0-vdda-pll-supply = <&vreg_l3e_1p2>;
>
> //
> csiphy1-vdda-phy-supply = <&vreg_l1e_0p9>;
> csiphy1-vdda-pll-supply = <&vreg_l3e_1p2>;
>
> Where X indicates the CSIPHY number.
>
> So in fact, in practice we don't need to differentiate these entries.
>
> Checking x1e80100 ...
>
> csiphy0
>
> vdda-phy-supply = <&vreg_l2c_0p9>;
> vdda-pll-supply = <&vreg_l1c_1p2>;
>
> This is also the case for csiphy 1/2/4
>
> So, I _don't_ believe this is work we need to do, since its the same regulator for each PHY.
Except when it's not the case, like on the SM8650 HDK:
VDD_A_CSI_01_0P9 => VREG_L2I_0P88
VDD_A_CSI_01_1P2 => VREG_L3I_1P2
VDD_A_CSI_24_0P9 => VREG_L1I_0P88
VDD_A_CSI_24_1P2 => VREG_L3I_1P2
VDD_A_CSI_35_0P9 => VREG_L2I_0P88
VDD_A_CSI_35_1P2 => VREG_L3I_1P2
the 1P2 all uses VREG_L3I_1P2, while the 0P9 are using VREG_L2I_0P88 or VREG_L1I_0P88
Not declaring the exact supplies is pure lazyness, it will bounce back at our faces at some point.
Neil
>
> ---
> bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-12 12:44 ` Vladimir Zapolskiy
@ 2024-09-12 15:11 ` Bryan O'Donoghue
2024-09-12 20:57 ` Vladimir Zapolskiy
2024-09-13 4:17 ` Dmitry Baryshkov
0 siblings, 2 replies; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-09-12 15:11 UTC (permalink / raw)
To: Vladimir Zapolskiy, Depeng Shao, rfoss, todor.too, mchehab, robh,
krzk+dt, conor+dt, Neil Armstrong
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 12/09/2024 13:44, Vladimir Zapolskiy wrote:
>> csiphy0
>>
>> vdda-phy-supply = <&vreg_l2c_0p9>;
>> vdda-pll-supply = <&vreg_l1c_1p2>;
>>
>> This is also the case for csiphy 1/2/4
>>
>> So, I _don't_ believe this is work we need to do, since its the same
>> regulator for each PHY.
>
> This is board specific, and even if the separation is not needed on the
> boards
> you have just checked, still it may be needed on some boards, which are
> not yet
> checked/not yet known.
There is a Power Grid Analysis document which specifies these rails @
the SoC level and assumes you've used the Qcom PMIC to power, moreover
the PGA re-uses the same regulator over and over again.
You _could_ provide that power from your own PMIC which provides the
same voltage range as the Qcom PMIC you haven't used. Even if you did
provide that from your own PMIC you'd have to provide _separate_ rails
for the various CSIPHYs before it would be required to have a per PHY
rail requirement on this SoC.
Are people really powering these SoCs with their own PMICs ?
No probably not.
Should we add the support for it anyway ?
Maybe.
So to reiterate:
1. csiphyX-vdda-phy-supply
csiphyX-vdda-pll-supply
In the dts and yaml
=> The names should be generic from the perspective of the driver
2. camss.c::csiphy_res_sm8550
[0].regulators = { "csiphy0-vdda-phy-supply",
"csiphy0-vdda-pll-supply" }
...
[N].regulators = { "csiphyN-vdda-phy-supply",
"csiphyN-vdda-pll-supply" }
=> The regulators for the PHY should be defined in the
PHY resources description
3. Required not optional in the yaml
=> You can't use the PHY without its regulators
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-12 15:11 ` Bryan O'Donoghue
@ 2024-09-12 20:57 ` Vladimir Zapolskiy
2024-09-12 22:41 ` Bryan O'Donoghue
2024-09-13 4:17 ` Dmitry Baryshkov
1 sibling, 1 reply; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-09-12 20:57 UTC (permalink / raw)
To: Bryan O'Donoghue, Depeng Shao, rfoss, todor.too, mchehab,
robh, krzk+dt, conor+dt, Neil Armstrong
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hi Bryan,
On 9/12/24 18:11, Bryan O'Donoghue wrote:
> On 12/09/2024 13:44, Vladimir Zapolskiy wrote:
>>> csiphy0
>>>
>>> vdda-phy-supply = <&vreg_l2c_0p9>;
>>> vdda-pll-supply = <&vreg_l1c_1p2>;
>>>
>>> This is also the case for csiphy 1/2/4
>>>
>>> So, I _don't_ believe this is work we need to do, since its the same
>>> regulator for each PHY.
>>
>> This is board specific, and even if the separation is not needed on the
>> boards
>> you have just checked, still it may be needed on some boards, which are
>> not yet
>> checked/not yet known.
>
> There is a Power Grid Analysis document which specifies these rails @
> the SoC level and assumes you've used the Qcom PMIC to power, moreover
> the PGA re-uses the same regulator over and over again.
>
> You _could_ provide that power from your own PMIC which provides the
> same voltage range as the Qcom PMIC you haven't used. Even if you did
> provide that from your own PMIC you'd have to provide _separate_ rails
> for the various CSIPHYs before it would be required to have a per PHY
> rail requirement on this SoC.
>
> Are people really powering these SoCs with their own PMICs ?
> No probably not.
>
> Should we add the support for it anyway ?
> Maybe.
To have a set of regulators is a matter of proper IC/IP description, actually
here I see very little option for a divergence or disagreement.
> So to reiterate:
>
> 1. csiphyX-vdda-phy-supply
> csiphyX-vdda-pll-supply
>
> In the dts and yaml
>
> => The names should be generic from the perspective of the driver
As for me I don't care about the particular names, somebody else can care.
> 2. camss.c::csiphy_res_sm8550
> [0].regulators = { "csiphy0-vdda-phy-supply",
> "csiphy0-vdda-pll-supply" }
> ...
>
> [N].regulators = { "csiphyN-vdda-phy-supply",
> "csiphyN-vdda-pll-supply" }
>
> => The regulators for the PHY should be defined in the
> PHY resources description
This is obvious.
> 3. Required not optional in the yaml
>
> => You can't use the PHY without its regulators
No, the supplies shall be optional, since it's absolutely possible to have
such a board, where supplies are merely not connected to the SoC.
Hence there shall be no requirement to describe any non-present supplies,
which is a legit case, if there is no connection and usage of the
correspondent non-supplied PHY.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-12 20:57 ` Vladimir Zapolskiy
@ 2024-09-12 22:41 ` Bryan O'Donoghue
2024-09-13 5:06 ` Vladimir Zapolskiy
0 siblings, 1 reply; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-09-12 22:41 UTC (permalink / raw)
To: Vladimir Zapolskiy, Depeng Shao, rfoss, todor.too, mchehab, robh,
krzk+dt, conor+dt, Neil Armstrong
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 12/09/2024 21:57, Vladimir Zapolskiy wrote:
>> 3. Required not optional in the yaml
>>
>> => You can't use the PHY without its regulators
>
> No, the supplies shall be optional, since it's absolutely possible to have
> such a board, where supplies are merely not connected to the SoC.
For any _used_ PHY both supplies are certainly required.
That's what the yaml/dts check for this should achieve.
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-12 15:11 ` Bryan O'Donoghue
2024-09-12 20:57 ` Vladimir Zapolskiy
@ 2024-09-13 4:17 ` Dmitry Baryshkov
1 sibling, 0 replies; 99+ messages in thread
From: Dmitry Baryshkov @ 2024-09-13 4:17 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Vladimir Zapolskiy, Depeng Shao, rfoss, todor.too, mchehab, robh,
krzk+dt, conor+dt, Neil Armstrong, linux-arm-msm, linux-media,
devicetree, linux-kernel, kernel, Yongsheng Li
On Thu, Sep 12, 2024 at 04:11:58PM GMT, Bryan O'Donoghue wrote:
> On 12/09/2024 13:44, Vladimir Zapolskiy wrote:
> > > csiphy0
> > >
> > > vdda-phy-supply = <&vreg_l2c_0p9>;
> > > vdda-pll-supply = <&vreg_l1c_1p2>;
> > >
> > > This is also the case for csiphy 1/2/4
> > >
> > > So, I _don't_ believe this is work we need to do, since its the same
> > > regulator for each PHY.
> >
> > This is board specific, and even if the separation is not needed on the
> > boards
> > you have just checked, still it may be needed on some boards, which are
> > not yet
> > checked/not yet known.
>
> There is a Power Grid Analysis document which specifies these rails @ the
> SoC level and assumes you've used the Qcom PMIC to power, moreover the PGA
> re-uses the same regulator over and over again.
>
> You _could_ provide that power from your own PMIC which provides the same
> voltage range as the Qcom PMIC you haven't used. Even if you did provide
> that from your own PMIC you'd have to provide _separate_ rails for the
> various CSIPHYs before it would be required to have a per PHY rail
> requirement on this SoC.
>
> Are people really powering these SoCs with their own PMICs ?
> No probably not.
Yes, they are.
--
With best wishes
Dmitry
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-12 22:41 ` Bryan O'Donoghue
@ 2024-09-13 5:06 ` Vladimir Zapolskiy
2024-09-17 22:40 ` Bryan O'Donoghue
0 siblings, 1 reply; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-09-13 5:06 UTC (permalink / raw)
To: Bryan O'Donoghue, Vladimir Zapolskiy, Depeng Shao, rfoss,
todor.too, mchehab, robh, krzk+dt, conor+dt, Neil Armstrong
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 9/13/24 01:41, Bryan O'Donoghue wrote:
> On 12/09/2024 21:57, Vladimir Zapolskiy wrote:
>>> 3. Required not optional in the yaml
>>>
>>> => You can't use the PHY without its regulators
>>
>> No, the supplies shall be optional, since it's absolutely possible to have
>> such a board, where supplies are merely not connected to the SoC.
>
> For any _used_ PHY both supplies are certainly required.
>
> That's what the yaml/dts check for this should achieve.
I believe it is technically possible by writing an enormously complex
scheme, when all possible "port" cases and combinations are listed.
Do you see any simpler way? Do you insist that it is utterly needed?
In any case, there are optional and required device tree properties,
the CAMSS supplies shall be split into multiple ones and become optional.
That's exactly the point of my first message in the discussion, so far
nothing has been added or changed.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-13 5:06 ` Vladimir Zapolskiy
@ 2024-09-17 22:40 ` Bryan O'Donoghue
2024-09-17 23:16 ` Vladimir Zapolskiy
0 siblings, 1 reply; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-09-17 22:40 UTC (permalink / raw)
To: Vladimir Zapolskiy, Vladimir Zapolskiy, Depeng Shao, rfoss,
todor.too, mchehab, robh, krzk+dt, conor+dt, Neil Armstrong
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 13/09/2024 06:06, Vladimir Zapolskiy wrote:
> On 9/13/24 01:41, Bryan O'Donoghue wrote:
>> On 12/09/2024 21:57, Vladimir Zapolskiy wrote:
>>>> 3. Required not optional in the yaml
>>>>
>>>> => You can't use the PHY without its regulators
>>>
>>> No, the supplies shall be optional, since it's absolutely possible to
>>> have
>>> such a board, where supplies are merely not connected to the SoC.
>>
>> For any _used_ PHY both supplies are certainly required.
>>
>> That's what the yaml/dts check for this should achieve.
>
> I believe it is technically possible by writing an enormously complex
> scheme, when all possible "port" cases and combinations are listed.
>
> Do you see any simpler way? Do you insist that it is utterly needed?
I asked Krzysztof about this offline.
He said something like
Quote:
This is possible, but I think not between child nodes.
https://elixir.bootlin.com/linux/v6.11-rc7/source/Documentation/devicetree/bindings/example-schema.yaml#L194
You could require something in children, but not in parent node. For
children something around:
https://elixir.bootlin.com/linux/v6.4-rc7/source/Documentation/devicetree/bindings/net/qcom,ipa.yaml#L174
allOf:
- if:
required:
- something-in-parent
then:
properties:
child-node:
required:
- something-in-child
I will see if I can turn that into a workable proposal/patch.
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-17 22:40 ` Bryan O'Donoghue
@ 2024-09-17 23:16 ` Vladimir Zapolskiy
2024-09-25 15:40 ` Depeng Shao
0 siblings, 1 reply; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-09-17 23:16 UTC (permalink / raw)
To: Bryan O'Donoghue, Depeng Shao, krzk+dt, Neil Armstrong,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li, mchehab, robh, todor.too, rfoss, conor+dt
Hi Bryan,
On 9/18/24 01:40, Bryan O'Donoghue wrote:
> On 13/09/2024 06:06, Vladimir Zapolskiy wrote:
>> On 9/13/24 01:41, Bryan O'Donoghue wrote:
>>> On 12/09/2024 21:57, Vladimir Zapolskiy wrote:
>>>>> 3. Required not optional in the yaml
>>>>>
>>>>> => You can't use the PHY without its regulators
>>>>
>>>> No, the supplies shall be optional, since it's absolutely possible to
>>>> have
>>>> such a board, where supplies are merely not connected to the SoC.
>>>
>>> For any _used_ PHY both supplies are certainly required.
>>>
>>> That's what the yaml/dts check for this should achieve.
>>
>> I believe it is technically possible by writing an enormously complex
>> scheme, when all possible "port" cases and combinations are listed.
>>
>> Do you see any simpler way? Do you insist that it is utterly needed?
>
> I asked Krzysztof about this offline.
>
> He said something like
>
> Quote:
> This is possible, but I think not between child nodes.
> https://elixir.bootlin.com/linux/v6.11-rc7/source/Documentation/devicetree/bindings/example-schema.yaml#L194
>
> You could require something in children, but not in parent node. For
> children something around:
> https://elixir.bootlin.com/linux/v6.4-rc7/source/Documentation/devicetree/bindings/net/qcom,ipa.yaml#L174
>
> allOf:
> - if:
> required:
> - something-in-parent
> then:
> properties:
> child-node:
> required:
> - something-in-child
>
> I will see if I can turn that into a workable proposal/patch.
>
thank you for pushing my review request forward.
Overall I believe making supply properties as optional ones is sufficient,
technically straightforward and merely good enough, thus please let me
ask you to ponder on this particular variant one more time.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-06 15:56 ` Vladimir Zapolskiy
@ 2024-09-25 15:13 ` Depeng Shao
2024-09-30 7:16 ` Krzysztof Kozlowski
2024-09-30 7:26 ` Krzysztof Kozlowski
0 siblings, 2 replies; 99+ messages in thread
From: Depeng Shao @ 2024-09-25 15:13 UTC (permalink / raw)
To: Vladimir Zapolskiy, rfoss, todor.too, bryan.odonoghue, mchehab,
robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hi Vladimir,
On 9/6/2024 11:56 PM, Vladimir Zapolskiy wrote:
>> + compatible = "qcom,sm8550-camss";
>> +
>> + reg = <0 0x0acb7000 0 0xd00>,
>> + <0 0x0acb9000 0 0xd00>,
>> + <0 0x0acbb000 0 0xd00>,
>> + <0 0x0acca000 0 0xa00>,
>> + <0 0x0acce000 0 0xa00>,
>> + <0 0x0acb6000 0 0x1000>,
>> + <0 0x0ace4000 0 0x2000>,
>> + <0 0x0ace6000 0 0x2000>,
>> + <0 0x0ace8000 0 0x2000>,
>> + <0 0x0acea000 0 0x2000>,
>> + <0 0x0acec000 0 0x2000>,
>> + <0 0x0acee000 0 0x2000>,
>> + <0 0x0acf0000 0 0x2000>,
>> + <0 0x0acf2000 0 0x2000>,
>> + <0 0x0ac62000 0 0xf000>,
>> + <0 0x0ac71000 0 0xf000>,
>> + <0 0x0ac80000 0 0xf000>,
>> + <0 0x0accb000 0 0x2800>,
>> + <0 0x0accf000 0 0x2800>;
>
> Please sort the list above in numerical order, this will change positions
> of "vfe_lite0", "vfe_lite1" etc.
>
> Another note, since it's not possible to map less than a page, so I believe
> it might make sense to align all sizes to 0x1000.
>
Sure, I previously sorted by the alphabetical order of reg_name.
I will update it based on your suggestion. And will also make sure the
align all sizes to 0x1000.
>> + <&camcc CAM_CC_IFE_LITE_CLK>,
>> + <&camcc CAM_CC_IFE_LITE_AHB_CLK>,
>> + <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>,
>> + <&camcc CAM_CC_IFE_LITE_CSID_CLK>,
>> + <&gcc GCC_CAMERA_HF_AXI_CLK>;
>
> Could you please put the &gcc provided clock as the first one in the list?
>
Sure, will do.
>> +
>> + interconnects = <&gem_noc MASTER_APPSS_PROC 0 &config_noc
>> SLAVE_CAMERA_CFG 0>,
>> + <&mmss_noc MASTER_CAMNOC_HF 0 &mc_virt
>> SLAVE_EBI1 0>,
>> + <&mmss_noc MASTER_CAMNOC_ICP 0 &mc_virt
>> SLAVE_EBI1 0>,
>> + <&mmss_noc MASTER_CAMNOC_SF 0 &mc_virt
>> SLAVE_EBI1 0>;
>> + interconnect-names = "ahb",
>> + "hf_0_mnoc",
>> + "icp_mnoc",
>> + "sf_0_mnoc";
>
> Just a note for myself, interconnect names lost "cam_" prefix, and it
> should
> be fine.
Krzysztof posted a comment in a SC7280 camss change and asked to remove
the "cam_" prefix.
https://lore.kernel.org/all/087e7f29-1fa8-4bc2-bb3d-acb941432381@kernel.org/
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>
> In case of a single child node #address-cells/#size-cells could be omitted,
> if I'm not mistaken about it...
>
I tried it, but dt_binding_check report below warning.
Documentation/devicetree/bindings/media/qcom,sm8550-camss.example.dts:221.29-39:
Warning (reg_format):
/example-0/soc/camss@ace4000/ports/port@0/endpoint@0:reg: property has
invalid length (4 bytes) (#address-cells == 2, #size-cells == 1)
Documentation/devicetree/bindings/media/qcom,sm8550-camss.example.dtb:
Warning (pci_device_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/media/qcom,sm8550-camss.example.dtb:
Warning (pci_device_bus_num): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/media/qcom,sm8550-camss.example.dtb:
Warning (simple_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/media/qcom,sm8550-camss.example.dtb:
Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/media/qcom,sm8550-camss.example.dtb:
Warning (spi_bus_reg): Failed prerequisite 'reg_format'
Documentation/devicetree/bindings/media/qcom,sm8550-camss.example.dts:220.48-225.27:
Warning (avoid_default_addr_size):
/example-0/soc/camss@ace4000/ports/port@0/endpoint@0: Relying on default
#address-cells value
Documentation/devicetree/bindings/media/qcom,sm8550-camss.example.dts:220.48-225.27:
Warning (avoid_default_addr_size):
/example-0/soc/camss@ace4000/ports/port@0/endpoint@0: Relying on default
#size-cells value
Documentation/devicetree/bindings/media/qcom,sm8550-camss.example.dtb:
Warning (unique_unit_address_if_enabled): Failed prerequisite
'avoid_default_addr_size'
Documentation/devicetree/bindings/media/qcom,sm8550-camss.example.dts:220.48-225.27:
Warning (graph_endpoint):
/example-0/soc/camss@ace4000/ports/port@0/endpoint@0: graph node
'#address-cells' is -1, must be 1
Documentation/devicetree/bindings/media/qcom,sm8550-camss.example.dts:220.48-225.27:
Warning (graph_endpoint):
/example-0/soc/camss@ace4000/ports/port@0/endpoint@0: graph node
'#size-cells' is -1, must be 0
>> + port@0 {
>> + reg = <0>;
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>
> Same as above.
>
Same warning..
>> +
>> + csiphy_ep0: endpoint@0 {
>> + reg = <0>;
>> + clock-lanes = <7>;
>> + data-lanes = <0 1>;
>> + remote-endpoint = <&sensor_ep>;
>> + };
>> + };
>> + };
>> + };
>> + };
>
---
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-17 23:16 ` Vladimir Zapolskiy
@ 2024-09-25 15:40 ` Depeng Shao
2024-09-30 9:26 ` Depeng Shao
2024-09-30 10:21 ` Bryan O'Donoghue
0 siblings, 2 replies; 99+ messages in thread
From: Depeng Shao @ 2024-09-25 15:40 UTC (permalink / raw)
To: Vladimir Zapolskiy, Bryan O'Donoghue, krzk+dt, Neil Armstrong,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li, mchehab, robh, todor.too, rfoss, conor+dt
Hi Vladimir, Bryan,
On 9/18/2024 7:16 AM, Vladimir Zapolskiy wrote:
> Hi Bryan,
>
> On 9/18/24 01:40, Bryan O'Donoghue wrote:
>> On 13/09/2024 06:06, Vladimir Zapolskiy wrote:
>>> On 9/13/24 01:41, Bryan O'Donoghue wrote:
>>>> On 12/09/2024 21:57, Vladimir Zapolskiy wrote:
>>>>>> 3. Required not optional in the yaml
>>>>>>
>>>>>> => You can't use the PHY without its regulators
>>>>>
>>>>> No, the supplies shall be optional, since it's absolutely possible to
>>>>> have
>>>>> such a board, where supplies are merely not connected to the SoC.
>>>>
>>>> For any _used_ PHY both supplies are certainly required.
>>>>
>>>> That's what the yaml/dts check for this should achieve.
>>>
>>> I believe it is technically possible by writing an enormously complex
>>> scheme, when all possible "port" cases and combinations are listed.
>>>
>>> Do you see any simpler way? Do you insist that it is utterly needed?
>>
>> I asked Krzysztof about this offline.
>>
>> He said something like
>>
>> Quote:
>> This is possible, but I think not between child nodes.
>> https://elixir.bootlin.com/linux/v6.11-rc7/source/Documentation/
>> devicetree/bindings/example-schema.yaml#L194
>>
>> You could require something in children, but not in parent node. For
>> children something around:
>> https://elixir.bootlin.com/linux/v6.4-rc7/source/Documentation/
>> devicetree/bindings/net/qcom,ipa.yaml#L174
>>
>> allOf:
>> - if:
>> required:
>> - something-in-parent
>> then:
>> properties:
>> child-node:
>> required:
>> - something-in-child
>>
>> I will see if I can turn that into a workable proposal/patch.
>>
>
> thank you for pushing my review request forward.
>
> Overall I believe making supply properties as optional ones is sufficient,
> technically straightforward and merely good enough, thus please let me
> ask you to ponder on this particular variant one more time.
>
So, we are discussing two things.
1# Use separate supplies for each CSI block, looks like there is no
doubt about it anymore. So, I will update it just like based on suggestion.
csiphyX-vdda-phy-supply
csiphyX-vdda-pll-supply
Then I will need below items in the required list if they are required.
required:
- csiphy0-vdda-phy-supply
- csiphy0-vdda-pll-supply
- csiphy1-vdda-phy-supply
- csiphy1-vdda-pll-supply
...
- csiphy7-vdda-phy-supply
- csiphy7-vdda-pll-supply
2# Regarding the CSI supplies, if they need to be making as optional?
Looks like there is no conclusion now.
@Bryan, do you agree with this?
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-25 15:13 ` Depeng Shao
@ 2024-09-30 7:16 ` Krzysztof Kozlowski
2024-09-30 8:46 ` Vladimir Zapolskiy
2024-09-30 7:26 ` Krzysztof Kozlowski
1 sibling, 1 reply; 99+ messages in thread
From: Krzysztof Kozlowski @ 2024-09-30 7:16 UTC (permalink / raw)
To: Depeng Shao, Vladimir Zapolskiy, rfoss, todor.too,
bryan.odonoghue, mchehab, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 25/09/2024 17:13, Depeng Shao wrote:
> Hi Vladimir,
>
> On 9/6/2024 11:56 PM, Vladimir Zapolskiy wrote:
>
>>> + compatible = "qcom,sm8550-camss";
>>> +
>>> + reg = <0 0x0acb7000 0 0xd00>,
>>> + <0 0x0acb9000 0 0xd00>,
>>> + <0 0x0acbb000 0 0xd00>,
>>> + <0 0x0acca000 0 0xa00>,
>>> + <0 0x0acce000 0 0xa00>,
>>> + <0 0x0acb6000 0 0x1000>,
>>> + <0 0x0ace4000 0 0x2000>,
>>> + <0 0x0ace6000 0 0x2000>,
>>> + <0 0x0ace8000 0 0x2000>,
>>> + <0 0x0acea000 0 0x2000>,
>>> + <0 0x0acec000 0 0x2000>,
>>> + <0 0x0acee000 0 0x2000>,
>>> + <0 0x0acf0000 0 0x2000>,
>>> + <0 0x0acf2000 0 0x2000>,
>>> + <0 0x0ac62000 0 0xf000>,
>>> + <0 0x0ac71000 0 0xf000>,
>>> + <0 0x0ac80000 0 0xf000>,
>>> + <0 0x0accb000 0 0x2800>,
>>> + <0 0x0accf000 0 0x2800>;
>>
>> Please sort the list above in numerical order, this will change positions
>> of "vfe_lite0", "vfe_lite1" etc.
>>
>> Another note, since it's not possible to map less than a page, so I believe
>> it might make sense to align all sizes to 0x1000.
>>
>
> Sure, I previously sorted by the alphabetical order of reg_name.
> I will update it based on your suggestion. And will also make sure the
> align all sizes to 0x1000.
If I understood correctly, you want to change the order from existing
devices, so no. You are supposed to keep the same order, as much as
possible.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-08-16 7:45 ` Depeng Shao
@ 2024-09-30 7:17 ` Krzysztof Kozlowski
0 siblings, 0 replies; 99+ messages in thread
From: Krzysztof Kozlowski @ 2024-09-30 7:17 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, bryan.odonoghue, mchehab, robh,
krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 16/08/2024 09:45, Depeng Shao wrote:
> Hi Krzysztof,
>
> On 8/16/2024 3:01 PM, Krzysztof Kozlowski wrote:
>
>>> +required:
>>> + - compatible
>>> + - clocks
>>> + - clock-names
>>> + - interconnects
>>> + - interconnect-names
>>> + - interrupts
>>> + - interrupt-names
>>> + - iommus
>>> + - power-domains
>>> + - power-domain-names
>>> + - reg
>>> + - reg-names
>>> + - vdda-phy-supply
>>> + - vdda-pll-supply
>>
>> Order is still not as expected. I already commented on this - keep the
>> same order as in "properties:" block.
>>
>> With the order fixed:
>>
>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
The review tag was given to above code with above changes. If you are
going to implement some more changes, including changing of orders of
some lists or adding ports, then drop this tag and explicitly mention in
patch changelog that tag was not added because of something.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-25 15:13 ` Depeng Shao
2024-09-30 7:16 ` Krzysztof Kozlowski
@ 2024-09-30 7:26 ` Krzysztof Kozlowski
2024-09-30 8:32 ` Vladimir Zapolskiy
2024-09-30 9:03 ` Bryan O'Donoghue
1 sibling, 2 replies; 99+ messages in thread
From: Krzysztof Kozlowski @ 2024-09-30 7:26 UTC (permalink / raw)
To: Depeng Shao, Vladimir Zapolskiy, rfoss, todor.too,
bryan.odonoghue, mchehab, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 25/09/2024 17:13, Depeng Shao wrote:
> Hi Vladimir,
>
> On 9/6/2024 11:56 PM, Vladimir Zapolskiy wrote:
>
>>> + compatible = "qcom,sm8550-camss";
>>> +
>>> + reg = <0 0x0acb7000 0 0xd00>,
>>> + <0 0x0acb9000 0 0xd00>,
>>> + <0 0x0acbb000 0 0xd00>,
>>> + <0 0x0acca000 0 0xa00>,
>>> + <0 0x0acce000 0 0xa00>,
>>> + <0 0x0acb6000 0 0x1000>,
>>> + <0 0x0ace4000 0 0x2000>,
>>> + <0 0x0ace6000 0 0x2000>,
>>> + <0 0x0ace8000 0 0x2000>,
>>> + <0 0x0acea000 0 0x2000>,
>>> + <0 0x0acec000 0 0x2000>,
>>> + <0 0x0acee000 0 0x2000>,
>>> + <0 0x0acf0000 0 0x2000>,
>>> + <0 0x0acf2000 0 0x2000>,
>>> + <0 0x0ac62000 0 0xf000>,
>>> + <0 0x0ac71000 0 0xf000>,
>>> + <0 0x0ac80000 0 0xf000>,
>>> + <0 0x0accb000 0 0x2800>,
>>> + <0 0x0accf000 0 0x2800>;
>>
>> Please sort the list above in numerical order, this will change positions
>> of "vfe_lite0", "vfe_lite1" etc.
>>
>> Another note, since it's not possible to map less than a page, so I believe
>> it might make sense to align all sizes to 0x1000.
And if Linux behavior changes then are you going to rewrite all the DTS
for new size?
No, the sizes reflect hardware register layout, not concept of pages.
I don't think that we should be coming with more nitpicky ideas, one
month after the patch was sent and reviewed.
Best regards,
Krzysztof
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-30 7:26 ` Krzysztof Kozlowski
@ 2024-09-30 8:32 ` Vladimir Zapolskiy
2024-09-30 9:03 ` Bryan O'Donoghue
1 sibling, 0 replies; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-09-30 8:32 UTC (permalink / raw)
To: Krzysztof Kozlowski, Depeng Shao, Vladimir Zapolskiy, rfoss,
todor.too, bryan.odonoghue, mchehab, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 9/30/24 10:26, Krzysztof Kozlowski wrote:
> On 25/09/2024 17:13, Depeng Shao wrote:
>> Hi Vladimir,
>>
>> On 9/6/2024 11:56 PM, Vladimir Zapolskiy wrote:
>>
>>>> + compatible = "qcom,sm8550-camss";
>>>> +
>>>> + reg = <0 0x0acb7000 0 0xd00>,
>>>> + <0 0x0acb9000 0 0xd00>,
>>>> + <0 0x0acbb000 0 0xd00>,
>>>> + <0 0x0acca000 0 0xa00>,
>>>> + <0 0x0acce000 0 0xa00>,
>>>> + <0 0x0acb6000 0 0x1000>,
>>>> + <0 0x0ace4000 0 0x2000>,
>>>> + <0 0x0ace6000 0 0x2000>,
>>>> + <0 0x0ace8000 0 0x2000>,
>>>> + <0 0x0acea000 0 0x2000>,
>>>> + <0 0x0acec000 0 0x2000>,
>>>> + <0 0x0acee000 0 0x2000>,
>>>> + <0 0x0acf0000 0 0x2000>,
>>>> + <0 0x0acf2000 0 0x2000>,
>>>> + <0 0x0ac62000 0 0xf000>,
>>>> + <0 0x0ac71000 0 0xf000>,
>>>> + <0 0x0ac80000 0 0xf000>,
>>>> + <0 0x0accb000 0 0x2800>,
>>>> + <0 0x0accf000 0 0x2800>;
>>>
>>> Please sort the list above in numerical order, this will change positions
>>> of "vfe_lite0", "vfe_lite1" etc.
>>>
>>> Another note, since it's not possible to map less than a page, so I believe
>>> it might make sense to align all sizes to 0x1000.
>
> And if Linux behavior changes then are you going to rewrite all the DTS
> for new size?
If Linux behaves properly with page size alignments today, then the selected
page size alignment for AMBA device IO memory regions is correct, hence any
future change from the correct IP device description to another one will be
invalid or noop.
There is nothing to worry about, I believe.
> No, the sizes reflect hardware register layout, not concept of pages.
>
Absolutely they do. It might be a coincidence that both are aligned in
this particular case or another one.
> I don't think that we should be coming with more nitpicky ideas, one
> month after the patch was sent and reviewed.
The change is not yet ready to be accepted from the technical perspective.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-30 7:16 ` Krzysztof Kozlowski
@ 2024-09-30 8:46 ` Vladimir Zapolskiy
2024-09-30 8:55 ` Bryan O'Donoghue
0 siblings, 1 reply; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-09-30 8:46 UTC (permalink / raw)
To: Krzysztof Kozlowski, Depeng Shao, rfoss, todor.too,
bryan.odonoghue, mchehab, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hello Krzysztof,
On 9/30/24 10:16, Krzysztof Kozlowski wrote:
> On 25/09/2024 17:13, Depeng Shao wrote:
>> Hi Vladimir,
>>
>> On 9/6/2024 11:56 PM, Vladimir Zapolskiy wrote:
>>
>>>> + compatible = "qcom,sm8550-camss";
>>>> +
>>>> + reg = <0 0x0acb7000 0 0xd00>,
>>>> + <0 0x0acb9000 0 0xd00>,
>>>> + <0 0x0acbb000 0 0xd00>,
>>>> + <0 0x0acca000 0 0xa00>,
>>>> + <0 0x0acce000 0 0xa00>,
>>>> + <0 0x0acb6000 0 0x1000>,
>>>> + <0 0x0ace4000 0 0x2000>,
>>>> + <0 0x0ace6000 0 0x2000>,
>>>> + <0 0x0ace8000 0 0x2000>,
>>>> + <0 0x0acea000 0 0x2000>,
>>>> + <0 0x0acec000 0 0x2000>,
>>>> + <0 0x0acee000 0 0x2000>,
>>>> + <0 0x0acf0000 0 0x2000>,
>>>> + <0 0x0acf2000 0 0x2000>,
>>>> + <0 0x0ac62000 0 0xf000>,
>>>> + <0 0x0ac71000 0 0xf000>,
>>>> + <0 0x0ac80000 0 0xf000>,
>>>> + <0 0x0accb000 0 0x2800>,
>>>> + <0 0x0accf000 0 0x2800>;
>>>
>>> Please sort the list above in numerical order, this will change positions
>>> of "vfe_lite0", "vfe_lite1" etc.
>>>
>>> Another note, since it's not possible to map less than a page, so I believe
>>> it might make sense to align all sizes to 0x1000.
>>>
>>
>> Sure, I previously sorted by the alphabetical order of reg_name.
>> I will update it based on your suggestion. And will also make sure the
>> align all sizes to 0x1000.
>
> If I understood correctly, you want to change the order from existing
> devices, so no. You are supposed to keep the same order, as much as
> possible.
Please elaborate, what do you mean here by the "existing evices"?
The list is not sorted by reg values, I ask to sort the list by reg values.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-30 8:46 ` Vladimir Zapolskiy
@ 2024-09-30 8:55 ` Bryan O'Donoghue
2024-09-30 9:15 ` Vladimir Zapolskiy
0 siblings, 1 reply; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-09-30 8:55 UTC (permalink / raw)
To: Vladimir Zapolskiy, Krzysztof Kozlowski, Depeng Shao, rfoss,
todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 30/09/2024 09:46, Vladimir Zapolskiy wrote:
> Hello Krzysztof,
>
> On 9/30/24 10:16, Krzysztof Kozlowski wrote:
>> On 25/09/2024 17:13, Depeng Shao wrote:
>>> Hi Vladimir,
>>>
>>> On 9/6/2024 11:56 PM, Vladimir Zapolskiy wrote:
>>>
>>>>> + compatible = "qcom,sm8550-camss";
>>>>> +
>>>>> + reg = <0 0x0acb7000 0 0xd00>,
>>>>> + <0 0x0acb9000 0 0xd00>,
>>>>> + <0 0x0acbb000 0 0xd00>,
>>>>> + <0 0x0acca000 0 0xa00>,
>>>>> + <0 0x0acce000 0 0xa00>,
>>>>> + <0 0x0acb6000 0 0x1000>,
>>>>> + <0 0x0ace4000 0 0x2000>,
>>>>> + <0 0x0ace6000 0 0x2000>,
>>>>> + <0 0x0ace8000 0 0x2000>,
>>>>> + <0 0x0acea000 0 0x2000>,
>>>>> + <0 0x0acec000 0 0x2000>,
>>>>> + <0 0x0acee000 0 0x2000>,
>>>>> + <0 0x0acf0000 0 0x2000>,
>>>>> + <0 0x0acf2000 0 0x2000>,
>>>>> + <0 0x0ac62000 0 0xf000>,
>>>>> + <0 0x0ac71000 0 0xf000>,
>>>>> + <0 0x0ac80000 0 0xf000>,
>>>>> + <0 0x0accb000 0 0x2800>,
>>>>> + <0 0x0accf000 0 0x2800>;
>>>>
>>>> Please sort the list above in numerical order, this will change
>>>> positions
>>>> of "vfe_lite0", "vfe_lite1" etc.
>>>>
>>>> Another note, since it's not possible to map less than a page, so I
>>>> believe
>>>> it might make sense to align all sizes to 0x1000.
>>>>
>>>
>>> Sure, I previously sorted by the alphabetical order of reg_name.
>>> I will update it based on your suggestion. And will also make sure the
>>> align all sizes to 0x1000.
>>
>> If I understood correctly, you want to change the order from existing
>> devices, so no. You are supposed to keep the same order, as much as
>> possible.
>
> Please elaborate, what do you mean here by the "existing evices"?
>
> The list is not sorted by reg values, I ask to sort the list by reg values.
>
> --
> Best wishes,
> Vladimir
We always sort by address:
camss: camss@ac5a000 {
compatible = "qcom,sc8280xp-camss";
reg = <0 0x0ac5a000 0 0x2000>,
<0 0x0ac5c000 0 0x2000>,
<0 0x0ac65000 0 0x2000>,
<0 0x0ac67000 0 0x2000>,
<0 0x0acaf000 0 0x4000>,
<0 0x0acb3000 0 0x1000>,
<0 0x0acb6000 0 0x4000>,
<0 0x0acba000 0 0x1000>,
<0 0x0acbd000 0 0x4000>,
<0 0x0acc1000 0 0x1000>,
<0 0x0acc4000 0 0x4000>,
<0 0x0acc8000 0 0x1000>,
<0 0x0accb000 0 0x4000>,
<0 0x0accf000 0 0x1000>,
<0 0x0acd2000 0 0x4000>,
<0 0x0acd6000 0 0x1000>,
<0 0x0acd9000 0 0x4000>,
<0 0x0acdd000 0 0x1000>,
<0 0x0ace0000 0 0x4000>,
<0 0x0ace4000 0 0x1000>;
reg-names = "csiphy2",
"csiphy3",
"csiphy0",
"csiphy1",
"vfe0",
"csid0",
"vfe1",
"csid1",
"vfe2",
"csid2",
"vfe_lite0",
"csid0_lite",
"vfe_lite1",
"csid1_lite",
"vfe_lite2",
"csid2_lite",
"vfe_lite3",
"csid3_lite",
"vfe3",
"csid3";
This is the way.
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-30 7:26 ` Krzysztof Kozlowski
2024-09-30 8:32 ` Vladimir Zapolskiy
@ 2024-09-30 9:03 ` Bryan O'Donoghue
1 sibling, 0 replies; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-09-30 9:03 UTC (permalink / raw)
To: Krzysztof Kozlowski, Depeng Shao, Vladimir Zapolskiy, rfoss,
todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 30/09/2024 08:26, Krzysztof Kozlowski wrote:
>>> Please sort the list above in numerical order, this will change positions
>>> of "vfe_lite0", "vfe_lite1" etc.
>>>
>>> Another note, since it's not possible to map less than a page, so I believe
>>> it might make sense to align all sizes to 0x1000.
> And if Linux behavior changes then are you going to rewrite all the DTS
> for new size?
>
> No, the sizes reflect hardware register layout, not concept of pages.
>
> I don't think that we should be coming with more nitpicky ideas, one
> month after the patch was sent and reviewed.
Agree.
1. My understanding has always been:
- Map the entire register bank extent
- The main reason for that is today you might only use
1/4 of the registers in a given bank but tomorrow you might
add in new functionality - like the HardISP in which case
you'd want the full set of registers not just the 1/4
or the 4k aligned version of that bank.
2. Pages can be all sorts of sizes so aligning to a page
makes no sense. 4k isn't special.
https://en.wikipedia.org/wiki/Page_(computer_memory)#Multiple_page_sizes
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-30 8:55 ` Bryan O'Donoghue
@ 2024-09-30 9:15 ` Vladimir Zapolskiy
0 siblings, 0 replies; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-09-30 9:15 UTC (permalink / raw)
To: Bryan O'Donoghue, Krzysztof Kozlowski, Depeng Shao, rfoss,
todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 9/30/24 11:55, Bryan O'Donoghue wrote:
> On 30/09/2024 09:46, Vladimir Zapolskiy wrote:
>> Hello Krzysztof,
>>
>> On 9/30/24 10:16, Krzysztof Kozlowski wrote:
>>> On 25/09/2024 17:13, Depeng Shao wrote:
>>>> Hi Vladimir,
>>>>
>>>> On 9/6/2024 11:56 PM, Vladimir Zapolskiy wrote:
>>>>
>>>>>> + compatible = "qcom,sm8550-camss";
>>>>>> +
>>>>>> + reg = <0 0x0acb7000 0 0xd00>,
>>>>>> + <0 0x0acb9000 0 0xd00>,
>>>>>> + <0 0x0acbb000 0 0xd00>,
>>>>>> + <0 0x0acca000 0 0xa00>,
>>>>>> + <0 0x0acce000 0 0xa00>,
>>>>>> + <0 0x0acb6000 0 0x1000>,
>>>>>> + <0 0x0ace4000 0 0x2000>,
>>>>>> + <0 0x0ace6000 0 0x2000>,
>>>>>> + <0 0x0ace8000 0 0x2000>,
>>>>>> + <0 0x0acea000 0 0x2000>,
>>>>>> + <0 0x0acec000 0 0x2000>,
>>>>>> + <0 0x0acee000 0 0x2000>,
>>>>>> + <0 0x0acf0000 0 0x2000>,
>>>>>> + <0 0x0acf2000 0 0x2000>,
>>>>>> + <0 0x0ac62000 0 0xf000>,
>>>>>> + <0 0x0ac71000 0 0xf000>,
>>>>>> + <0 0x0ac80000 0 0xf000>,
>>>>>> + <0 0x0accb000 0 0x2800>,
>>>>>> + <0 0x0accf000 0 0x2800>;
>>>>>
>>>>> Please sort the list above in numerical order, this will change
>>>>> positions
>>>>> of "vfe_lite0", "vfe_lite1" etc.
>>>>>
>>>>> Another note, since it's not possible to map less than a page, so I
>>>>> believe
>>>>> it might make sense to align all sizes to 0x1000.
>>>>>
>>>>
>>>> Sure, I previously sorted by the alphabetical order of reg_name.
>>>> I will update it based on your suggestion. And will also make sure the
>>>> align all sizes to 0x1000.
>>>
>>> If I understood correctly, you want to change the order from existing
>>> devices, so no. You are supposed to keep the same order, as much as
>>> possible.
>>
>> Please elaborate, what do you mean here by the "existing evices"?
>>
>> The list is not sorted by reg values, I ask to sort the list by reg values.
>>
>> --
>> Best wishes,
>> Vladimir
>
> We always sort by address:
>
Thank you for the given confirmation that there is a need to make
the change requested by me.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-25 15:40 ` Depeng Shao
@ 2024-09-30 9:26 ` Depeng Shao
2024-10-08 13:50 ` Vladimir Zapolskiy
2024-09-30 10:21 ` Bryan O'Donoghue
1 sibling, 1 reply; 99+ messages in thread
From: Depeng Shao @ 2024-09-30 9:26 UTC (permalink / raw)
To: Vladimir Zapolskiy, Bryan O'Donoghue, krzk+dt, Neil Armstrong,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li, mchehab, robh, todor.too, rfoss, conor+dt
Hi Bryan,
On 9/25/2024 11:40 PM, Depeng Shao wrote:
> Hi Vladimir, Bryan,
>
> On 9/18/2024 7:16 AM, Vladimir Zapolskiy wrote:
>> Hi Bryan,
>>
>> On 9/18/24 01:40, Bryan O'Donoghue wrote:
>>> On 13/09/2024 06:06, Vladimir Zapolskiy wrote:
>>>> On 9/13/24 01:41, Bryan O'Donoghue wrote:
>>>>> On 12/09/2024 21:57, Vladimir Zapolskiy wrote:
>>>>>>> 3. Required not optional in the yaml
>>>>>>>
>>>>>>> => You can't use the PHY without its regulators
>>>>>>
>>>>>> No, the supplies shall be optional, since it's absolutely possible to
>>>>>> have
>>>>>> such a board, where supplies are merely not connected to the SoC.
>>>>>
>>>>> For any _used_ PHY both supplies are certainly required.
>>>>>
>>>>> That's what the yaml/dts check for this should achieve.
>>>>
>>>> I believe it is technically possible by writing an enormously complex
>>>> scheme, when all possible "port" cases and combinations are listed.
>>>>
>>>> Do you see any simpler way? Do you insist that it is utterly needed?
>>>
>>> I asked Krzysztof about this offline.
>>>
>>> He said something like
>>>
>>> Quote:
>>> This is possible, but I think not between child nodes.
>>> https://elixir.bootlin.com/linux/v6.11-rc7/source/Documentation/
>>> devicetree/bindings/example-schema.yaml#L194
>>>
>>> You could require something in children, but not in parent node. For
>>> children something around:
>>> https://elixir.bootlin.com/linux/v6.4-rc7/source/Documentation/
>>> devicetree/bindings/net/qcom,ipa.yaml#L174
>>>
>>> allOf:
>>> - if:
>>> required:
>>> - something-in-parent
>>> then:
>>> properties:
>>> child-node:
>>> required:
>>> - something-in-child
>>>
>>> I will see if I can turn that into a workable proposal/patch.
>>>
>>
>> thank you for pushing my review request forward.
>>
>> Overall I believe making supply properties as optional ones is
>> sufficient,
>> technically straightforward and merely good enough, thus please let me
>> ask you to ponder on this particular variant one more time.
>>
>
> So, we are discussing two things.
>
> 1# Use separate supplies for each CSI block, looks like there is no
> doubt about it anymore. So, I will update it just like based on suggestion.
>
> csiphyX-vdda-phy-supply
> csiphyX-vdda-pll-supply
>
> Then I will need below items in the required list if they are required.
> required:
> - csiphy0-vdda-phy-supply
> - csiphy0-vdda-pll-supply
> - csiphy1-vdda-phy-supply
> - csiphy1-vdda-pll-supply
> ...
> - csiphy7-vdda-phy-supply
> - csiphy7-vdda-pll-supply
>
> 2# Regarding the CSI supplies, if they need to be making as optional?
> Looks like there is no conclusion now.
>
> @Bryan, do you agree with this?
>
I'm preparing the new version patches, and will send out for reviewing
in few days. I will follow Vladimir's comments if you have no response,
it means making supply properties as optional one, so they won't be
added to the required list.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-25 15:40 ` Depeng Shao
2024-09-30 9:26 ` Depeng Shao
@ 2024-09-30 10:21 ` Bryan O'Donoghue
1 sibling, 0 replies; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-09-30 10:21 UTC (permalink / raw)
To: Depeng Shao, Vladimir Zapolskiy, krzk+dt, Neil Armstrong,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li, mchehab, robh, todor.too, rfoss, conor+dt
On 25/09/2024 16:40, Depeng Shao wrote:
>
> 2# Regarding the CSI supplies, if they need to be making as optional?
> Looks like there is no conclusion now.
>
> @Bryan, do you agree with this?
It doesn't make sense to have those supplies optional. If you
instantiate a csiphy for your board you need a power supply for it.
I believe I said I would _try_ to come up with a proposal for that. I
should be able to get x1e80100 first pass patches out this week -
including such a proposed fix.
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-09-30 9:26 ` Depeng Shao
@ 2024-10-08 13:50 ` Vladimir Zapolskiy
2024-10-08 14:06 ` Bryan O'Donoghue
0 siblings, 1 reply; 99+ messages in thread
From: Vladimir Zapolskiy @ 2024-10-08 13:50 UTC (permalink / raw)
To: Depeng Shao, Bryan O'Donoghue, krzk+dt, Neil Armstrong,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li, mchehab, robh, todor.too, rfoss, conor+dt
Hi Depeng.
On 9/30/24 12:26, Depeng Shao wrote:
> Hi Bryan,
>
> On 9/25/2024 11:40 PM, Depeng Shao wrote:
>> Hi Vladimir, Bryan,
>>
>> On 9/18/2024 7:16 AM, Vladimir Zapolskiy wrote:
>>> Hi Bryan,
>>>
>>> On 9/18/24 01:40, Bryan O'Donoghue wrote:
>>>> On 13/09/2024 06:06, Vladimir Zapolskiy wrote:
>>>>> On 9/13/24 01:41, Bryan O'Donoghue wrote:
>>>>>> On 12/09/2024 21:57, Vladimir Zapolskiy wrote:
>>>>>>>> 3. Required not optional in the yaml
>>>>>>>>
>>>>>>>> => You can't use the PHY without its regulators
>>>>>>>
>>>>>>> No, the supplies shall be optional, since it's absolutely possible to
>>>>>>> have
>>>>>>> such a board, where supplies are merely not connected to the SoC.
>>>>>>
>>>>>> For any _used_ PHY both supplies are certainly required.
>>>>>>
>>>>>> That's what the yaml/dts check for this should achieve.
>>>>>
>>>>> I believe it is technically possible by writing an enormously complex
>>>>> scheme, when all possible "port" cases and combinations are listed.
>>>>>
>>>>> Do you see any simpler way? Do you insist that it is utterly needed?
>>>>
>>>> I asked Krzysztof about this offline.
>>>>
>>>> He said something like
>>>>
>>>> Quote:
>>>> This is possible, but I think not between child nodes.
>>>> https://elixir.bootlin.com/linux/v6.11-rc7/source/Documentation/
>>>> devicetree/bindings/example-schema.yaml#L194
>>>>
>>>> You could require something in children, but not in parent node. For
>>>> children something around:
>>>> https://elixir.bootlin.com/linux/v6.4-rc7/source/Documentation/
>>>> devicetree/bindings/net/qcom,ipa.yaml#L174
>>>>
>>>> allOf:
>>>> - if:
>>>> required:
>>>> - something-in-parent
>>>> then:
>>>> properties:
>>>> child-node:
>>>> required:
>>>> - something-in-child
>>>>
>>>> I will see if I can turn that into a workable proposal/patch.
>>>>
>>>
>>> thank you for pushing my review request forward.
>>>
>>> Overall I believe making supply properties as optional ones is
>>> sufficient,
>>> technically straightforward and merely good enough, thus please let me
>>> ask you to ponder on this particular variant one more time.
>>>
>>
>> So, we are discussing two things.
>>
>> 1# Use separate supplies for each CSI block, looks like there is no
>> doubt about it anymore. So, I will update it just like based on suggestion.
>>
>> csiphyX-vdda-phy-supply
>> csiphyX-vdda-pll-supply
>>
>> Then I will need below items in the required list if they are required.
>> required:
>> - csiphy0-vdda-phy-supply
>> - csiphy0-vdda-pll-supply
>> - csiphy1-vdda-phy-supply
>> - csiphy1-vdda-pll-supply
>> ...
>> - csiphy7-vdda-phy-supply
>> - csiphy7-vdda-pll-supply
>>
>> 2# Regarding the CSI supplies, if they need to be making as optional?
>> Looks like there is no conclusion now.
>>
>> @Bryan, do you agree with this?
>>
>
> I'm preparing the new version patches, and will send out for reviewing
> in few days. I will follow Vladimir's comments if you have no response,
> it means making supply properties as optional one, so they won't be
> added to the required list.
>
Recently I published the change, which moves regulator supplies from CSID
to CSIPHY, I believe it makes sense to base the SM8550 change and regulators
under discussion on top of the series:
https://lore.kernel.org/all/20240926211957.4108692-1-vladimir.zapolskiy@linaro.org/
Note, that SM8250 regulators are not changed, however their names are wrong,
the correction shall be a separate change later on...
Next, I developed my opinion regarding the supply regulator property names:
1) voltage supply regulator property names match the pattern "*v*-supply",
and the most common name is "vdd*-supply", the match to the pattern shall
be preserved,
2) also it would be much better and it will exclude any confusion, if SoC pin
names are put into the name, like it is done in a multitude of similar
cases.
So, in my opinion for SM8550 CAMSS a proposed set of voltage supply regulator
names should be this one:
- vdda-csi01-0p9-supply
- vdda-csi01-1p2-supply
- vdda-csi23-0p9-supply
- vdda-csi23-1p2-supply
- vdda-csi46-0p9-supply
- vdda-csi46-1p2-supply
- vdda-csi57-0p9-supply
- vdda-csi57-1p2-supply
Comments, corrections and objections are always welcome.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-10-08 13:50 ` Vladimir Zapolskiy
@ 2024-10-08 14:06 ` Bryan O'Donoghue
2024-10-08 15:47 ` Depeng Shao
0 siblings, 1 reply; 99+ messages in thread
From: Bryan O'Donoghue @ 2024-10-08 14:06 UTC (permalink / raw)
To: Vladimir Zapolskiy, Depeng Shao, krzk+dt, Neil Armstrong,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li, mchehab, robh, todor.too, rfoss, conor+dt
On 08/10/2024 14:50, Vladimir Zapolskiy wrote:
> Hi Depeng.
>
> On 9/30/24 12:26, Depeng Shao wrote:
>> Hi Bryan,
>>
>> On 9/25/2024 11:40 PM, Depeng Shao wrote:
>>> Hi Vladimir, Bryan,
>>>
>>> On 9/18/2024 7:16 AM, Vladimir Zapolskiy wrote:
>>>> Hi Bryan,
>>>>
>>>> On 9/18/24 01:40, Bryan O'Donoghue wrote:
>>>>> On 13/09/2024 06:06, Vladimir Zapolskiy wrote:
>>>>>> On 9/13/24 01:41, Bryan O'Donoghue wrote:
>>>>>>> On 12/09/2024 21:57, Vladimir Zapolskiy wrote:
>>>>>>>>> 3. Required not optional in the yaml
>>>>>>>>>
>>>>>>>>> => You can't use the PHY without its regulators
>>>>>>>>
>>>>>>>> No, the supplies shall be optional, since it's absolutely
>>>>>>>> possible to
>>>>>>>> have
>>>>>>>> such a board, where supplies are merely not connected to the SoC.
>>>>>>>
>>>>>>> For any _used_ PHY both supplies are certainly required.
>>>>>>>
>>>>>>> That's what the yaml/dts check for this should achieve.
>>>>>>
>>>>>> I believe it is technically possible by writing an enormously complex
>>>>>> scheme, when all possible "port" cases and combinations are listed.
>>>>>>
>>>>>> Do you see any simpler way? Do you insist that it is utterly needed?
>>>>>
>>>>> I asked Krzysztof about this offline.
>>>>>
>>>>> He said something like
>>>>>
>>>>> Quote:
>>>>> This is possible, but I think not between child nodes.
>>>>> https://elixir.bootlin.com/linux/v6.11-rc7/source/Documentation/
>>>>> devicetree/bindings/example-schema.yaml#L194
>>>>>
>>>>> You could require something in children, but not in parent node. For
>>>>> children something around:
>>>>> https://elixir.bootlin.com/linux/v6.4-rc7/source/Documentation/
>>>>> devicetree/bindings/net/qcom,ipa.yaml#L174
>>>>>
>>>>> allOf:
>>>>> - if:
>>>>> required:
>>>>> - something-in-parent
>>>>> then:
>>>>> properties:
>>>>> child-node:
>>>>> required:
>>>>> - something-in-child
>>>>>
>>>>> I will see if I can turn that into a workable proposal/patch.
>>>>>
>>>>
>>>> thank you for pushing my review request forward.
>>>>
>>>> Overall I believe making supply properties as optional ones is
>>>> sufficient,
>>>> technically straightforward and merely good enough, thus please let me
>>>> ask you to ponder on this particular variant one more time.
>>>>
>>>
>>> So, we are discussing two things.
>>>
>>> 1# Use separate supplies for each CSI block, looks like there is no
>>> doubt about it anymore. So, I will update it just like based on
>>> suggestion.
>>>
>>> csiphyX-vdda-phy-supply
>>> csiphyX-vdda-pll-supply
>>>
>>> Then I will need below items in the required list if they are required.
>>> required:
>>> - csiphy0-vdda-phy-supply
>>> - csiphy0-vdda-pll-supply
>>> - csiphy1-vdda-phy-supply
>>> - csiphy1-vdda-pll-supply
>>> ...
>>> - csiphy7-vdda-phy-supply
>>> - csiphy7-vdda-pll-supply
>>>
>>> 2# Regarding the CSI supplies, if they need to be making as optional?
>>> Looks like there is no conclusion now.
>>>
>>> @Bryan, do you agree with this?
>>>
>>
>> I'm preparing the new version patches, and will send out for reviewing
>> in few days. I will follow Vladimir's comments if you have no response,
>> it means making supply properties as optional one, so they won't be
>> added to the required list.
>>
>
> Recently I published the change, which moves regulator supplies from CSID
> to CSIPHY, I believe it makes sense to base the SM8550 change and
> regulators
> under discussion on top of the series:
>
> https://lore.kernel.org/all/20240926211957.4108692-1-
> vladimir.zapolskiy@linaro.org/
>
> Note, that SM8250 regulators are not changed, however their names are
> wrong,
> the correction shall be a separate change later on...
>
> Next, I developed my opinion regarding the supply regulator property names:
>
> 1) voltage supply regulator property names match the pattern "*v*-supply",
> and the most common name is "vdd*-supply", the match to the pattern
> shall
> be preserved,
> 2) also it would be much better and it will exclude any confusion, if
> SoC pin
> names are put into the name, like it is done in a multitude of similar
> cases.
>
> So, in my opinion for SM8550 CAMSS a proposed set of voltage supply
> regulator
> names should be this one:
>
> - vdda-csi01-0p9-supply
> - vdda-csi01-1p2-supply
> - vdda-csi23-0p9-supply
> - vdda-csi23-1p2-supply
> - vdda-csi46-0p9-supply
> - vdda-csi46-1p2-supply
> - vdda-csi57-0p9-supply
> - vdda-csi57-1p2-supply
So I communicated to Depeng to take the patch for the regulators but, I
still don't think the above is the right way to do this.
I will take a pass at constructing something in the schema to capture
the case where a regulator is required if and only if it is instantiated.
May not be possible with our current syntax/tools but is 100% how the
hardware works so IMO is the right thing to try to do.
---
bod
^ permalink raw reply [flat|nested] 99+ messages in thread
* Re: [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-10-08 14:06 ` Bryan O'Donoghue
@ 2024-10-08 15:47 ` Depeng Shao
0 siblings, 0 replies; 99+ messages in thread
From: Depeng Shao @ 2024-10-08 15:47 UTC (permalink / raw)
To: Bryan O'Donoghue, Vladimir Zapolskiy, krzk+dt, Neil Armstrong,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li, mchehab, robh, todor.too, rfoss, conor+dt
Hi Vladimir,
On 10/8/2024 10:06 PM, Bryan O'Donoghue wrote:
> On 08/10/2024 14:50, Vladimir Zapolskiy wrote:
>> Hi Depeng.
>>
>> On 9/30/24 12:26, Depeng Shao wrote:
>>> Hi Bryan,
>>>
>>> On 9/25/2024 11:40 PM, Depeng Shao wrote:
>>>> Hi Vladimir, Bryan,
>>>>
>>>> On 9/18/2024 7:16 AM, Vladimir Zapolskiy wrote:
>>>>> Hi Bryan,
>>>>>
>>>>> On 9/18/24 01:40, Bryan O'Donoghue wrote:
>>>>>> On 13/09/2024 06:06, Vladimir Zapolskiy wrote:
>>>>>>> On 9/13/24 01:41, Bryan O'Donoghue wrote:
>>>>>>>> On 12/09/2024 21:57, Vladimir Zapolskiy wrote:
>>>>>>>>>> 3. Required not optional in the yaml
>>>>>>>>>>
>>>>>>>>>> => You can't use the PHY without its regulators
>>>>>>>>>
>>>>>>>>> No, the supplies shall be optional, since it's absolutely
>>>>>>>>> possible to
>>>>>>>>> have
>>>>>>>>> such a board, where supplies are merely not connected to the SoC.
>>>>>>>>
>>>>>>>> For any _used_ PHY both supplies are certainly required.
>>>>>>>>
>>>>>>>> That's what the yaml/dts check for this should achieve.
>>>>>>>
>>>>>>> I believe it is technically possible by writing an enormously
>>>>>>> complex
>>>>>>> scheme, when all possible "port" cases and combinations are listed.
>>>>>>>
>>>>>>> Do you see any simpler way? Do you insist that it is utterly needed?
>>>>>>
>>>>>> I asked Krzysztof about this offline.
>>>>>>
>>>>>> He said something like
>>>>>>
>>>>>> Quote:
>>>>>> This is possible, but I think not between child nodes.
>>>>>> https://elixir.bootlin.com/linux/v6.11-rc7/source/Documentation/
>>>>>> devicetree/bindings/example-schema.yaml#L194
>>>>>>
>>>>>> You could require something in children, but not in parent node. For
>>>>>> children something around:
>>>>>> https://elixir.bootlin.com/linux/v6.4-rc7/source/Documentation/
>>>>>> devicetree/bindings/net/qcom,ipa.yaml#L174
>>>>>>
>>>>>> allOf:
>>>>>> - if:
>>>>>> required:
>>>>>> - something-in-parent
>>>>>> then:
>>>>>> properties:
>>>>>> child-node:
>>>>>> required:
>>>>>> - something-in-child
>>>>>>
>>>>>> I will see if I can turn that into a workable proposal/patch.
>>>>>>
>>>>>
>>>>> thank you for pushing my review request forward.
>>>>>
>>>>> Overall I believe making supply properties as optional ones is
>>>>> sufficient,
>>>>> technically straightforward and merely good enough, thus please let me
>>>>> ask you to ponder on this particular variant one more time.
>>>>>
>>>>
>>>> So, we are discussing two things.
>>>>
>>>> 1# Use separate supplies for each CSI block, looks like there is no
>>>> doubt about it anymore. So, I will update it just like based on
>>>> suggestion.
>>>>
>>>> csiphyX-vdda-phy-supply
>>>> csiphyX-vdda-pll-supply
>>>>
>>>> Then I will need below items in the required list if they are required.
>>>> required:
>>>> - csiphy0-vdda-phy-supply
>>>> - csiphy0-vdda-pll-supply
>>>> - csiphy1-vdda-phy-supply
>>>> - csiphy1-vdda-pll-supply
>>>> ...
>>>> - csiphy7-vdda-phy-supply
>>>> - csiphy7-vdda-pll-supply
>>>>
>>>> 2# Regarding the CSI supplies, if they need to be making as optional?
>>>> Looks like there is no conclusion now.
>>>>
>>>> @Bryan, do you agree with this?
>>>>
>>>
>>> I'm preparing the new version patches, and will send out for reviewing
>>> in few days. I will follow Vladimir's comments if you have no response,
>>> it means making supply properties as optional one, so they won't be
>>> added to the required list.
>>>
>>
>> Recently I published the change, which moves regulator supplies from CSID
>> to CSIPHY, I believe it makes sense to base the SM8550 change and
>> regulators
>> under discussion on top of the series:
>>
>> https://lore.kernel.org/all/20240926211957.4108692-1-
>> vladimir.zapolskiy@linaro.org/
>>
>> Note, that SM8250 regulators are not changed, however their names are
>> wrong,
>> the correction shall be a separate change later on...
>>
>> Next, I developed my opinion regarding the supply regulator property
>> names:
>>
>> 1) voltage supply regulator property names match the pattern "*v*-
>> supply",
>> and the most common name is "vdd*-supply", the match to the
>> pattern shall
>> be preserved,
>> 2) also it would be much better and it will exclude any confusion, if
>> SoC pin
>> names are put into the name, like it is done in a multitude of
>> similar
>> cases.
>>
>> So, in my opinion for SM8550 CAMSS a proposed set of voltage supply
>> regulator
>> names should be this one:
>>
>> - vdda-csi01-0p9-supply
>> - vdda-csi01-1p2-supply
>> - vdda-csi23-0p9-supply
>> - vdda-csi23-1p2-supply
>> - vdda-csi46-0p9-supply
>> - vdda-csi46-1p2-supply
>> - vdda-csi57-0p9-supply
>> - vdda-csi57-1p2-supply
>
> So I communicated to Depeng to take the patch for the regulators but, I
> still don't think the above is the right way to do this.
>
> I will take a pass at constructing something in the schema to capture
> the case where a regulator is required if and only if it is instantiated.
>
> May not be possible with our current syntax/tools but is 100% how the
> hardware works so IMO is the right thing to try to do.
>
Yes, I have picked your patch and rebased the SM8550 change based on
your patch. I also verified them and it works good.
But I don't understand why the names are csi01, csi23, csi46, csi57.
Could you please elaborate more?
I'm using csiphyX-vdda-phy-supply and csiphyX-vdda-pll-supply now.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 99+ messages in thread
end of thread, other threads:[~2024-10-08 15:47 UTC | newest]
Thread overview: 99+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-07-09 16:06 [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
2024-07-09 16:06 ` [PATCH 01/13] media: qcom: camss: csiphy-3ph: Fix trivial indentation fault in defines Depeng Shao
2024-07-31 23:16 ` Vladimir Zapolskiy
2024-07-09 16:06 ` [PATCH 02/13] media: qcom: camss: csiphy-3ph: Remove redundant PHY init sequence control loop Depeng Shao
2024-07-31 23:27 ` Vladimir Zapolskiy
2024-07-09 16:06 ` [PATCH 03/13] media: qcom: camss: csiphy-3ph: Rename struct Depeng Shao
2024-07-31 23:28 ` Vladimir Zapolskiy
2024-07-09 16:06 ` [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices Depeng Shao
2024-07-31 23:43 ` Vladimir Zapolskiy
2024-08-01 8:16 ` Bryan O'Donoghue
2024-08-04 21:26 ` Vladimir Zapolskiy
2024-08-07 13:08 ` Depeng Shao
2024-08-07 14:04 ` Bryan O'Donoghue
2024-08-07 15:03 ` Depeng Shao
2024-08-07 15:37 ` Bryan O'Donoghue
2024-08-08 14:02 ` Depeng Shao
2024-08-12 11:32 ` Bryan O'Donoghue
2024-08-12 12:20 ` Depeng Shao
2024-07-09 16:06 ` [PATCH 05/13] media: qcom: camss: csiphy-3ph: Move CSIPHY variables to data field inside csiphy struct Depeng Shao
2024-07-31 23:55 ` Vladimir Zapolskiy
2024-07-09 16:06 ` [PATCH 06/13] media: qcom: camss: csiphy-3ph: Use an offset variable to find common control regs Depeng Shao
2024-07-09 16:06 ` [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding Depeng Shao
2024-07-09 20:21 ` Rob Herring (Arm)
2024-07-10 9:37 ` Bryan O'Donoghue
2024-07-10 10:59 ` Depeng Shao
2024-07-10 11:07 ` Krzysztof Kozlowski
2024-07-11 10:43 ` Depeng Shao
2024-08-01 0:05 ` Vladimir Zapolskiy
2024-08-01 2:02 ` Depeng Shao
2024-07-09 16:06 ` [PATCH 08/13] media: qcom: camss: csiphy-3ph: Add Gen2 v1.2 two-phase MIPI CSI-2 DPHY init Depeng Shao
2024-07-10 11:09 ` Krzysztof Kozlowski
2024-07-10 13:14 ` Depeng Shao
2024-07-10 11:13 ` Bryan O'Donoghue
2024-07-10 13:33 ` Depeng Shao
2024-07-09 16:06 ` [PATCH 09/13] media: qcom: camss: Add CSID Gen3 support for SM8550 Depeng Shao
2024-07-10 11:20 ` Krzysztof Kozlowski
2024-07-11 11:08 ` Depeng Shao
2024-07-11 11:12 ` Krzysztof Kozlowski
2024-07-11 11:41 ` Depeng Shao
2024-07-11 12:00 ` Bryan O'Donoghue
2024-07-11 12:14 ` Depeng Shao
2024-07-11 12:17 ` Krzysztof Kozlowski
2024-07-31 15:26 ` Depeng Shao
2024-07-31 16:12 ` Bryan O'Donoghue
2024-08-01 1:53 ` Depeng Shao
2024-08-01 10:59 ` Bryan O'Donoghue
2024-08-01 11:14 ` Bryan O'Donoghue
2024-08-01 13:49 ` Depeng Shao
2024-07-10 11:28 ` Bryan O'Donoghue
2024-07-11 15:33 ` Depeng Shao
2024-08-07 15:10 ` Depeng Shao
2024-07-09 16:06 ` [PATCH 10/13] media: qcom: camss: Add support for VFE hardware version Titan 780 Depeng Shao
2024-07-10 11:22 ` Krzysztof Kozlowski
2024-07-10 11:47 ` Bryan O'Donoghue
2024-07-11 13:29 ` Depeng Shao
2024-07-09 16:06 ` [PATCH 11/13] media: qcom: camss: Add notify interface in camss driver Depeng Shao
2024-07-10 11:54 ` Bryan O'Donoghue
2024-07-11 11:54 ` Depeng Shao
2024-07-09 16:06 ` [PATCH 12/13] media: qcom: camss: Add sm8550 support Depeng Shao
2024-07-10 12:02 ` Bryan O'Donoghue
2024-07-11 14:36 ` Depeng Shao
2024-07-09 16:06 ` [PATCH 13/13] media: qcom: camss: Add sm8550 resources Depeng Shao
2024-07-10 11:08 ` [PATCH V3 00/13] media: qcom: camss: Add sm8550 support Krzysztof Kozlowski
2024-07-10 11:27 ` Depeng Shao
2024-07-10 12:30 ` Krzysztof Kozlowski
2024-07-11 11:14 ` Depeng Shao
2024-08-24 17:05 ` Bryan O'Donoghue
-- strict thread matches above, loose matches on Subject: below --
2024-08-12 14:41 [PATCH v4 " Depeng Shao
2024-08-12 14:41 ` [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding Depeng Shao
2024-08-16 7:01 ` Krzysztof Kozlowski
2024-08-16 7:45 ` Depeng Shao
2024-09-30 7:17 ` Krzysztof Kozlowski
2024-09-05 15:20 ` Vladimir Zapolskiy
2024-09-05 15:54 ` Depeng Shao
2024-09-06 15:56 ` Vladimir Zapolskiy
2024-09-25 15:13 ` Depeng Shao
2024-09-30 7:16 ` Krzysztof Kozlowski
2024-09-30 8:46 ` Vladimir Zapolskiy
2024-09-30 8:55 ` Bryan O'Donoghue
2024-09-30 9:15 ` Vladimir Zapolskiy
2024-09-30 7:26 ` Krzysztof Kozlowski
2024-09-30 8:32 ` Vladimir Zapolskiy
2024-09-30 9:03 ` Bryan O'Donoghue
2024-09-12 8:22 ` Vladimir Zapolskiy
2024-09-12 11:41 ` Bryan O'Donoghue
2024-09-12 12:44 ` Vladimir Zapolskiy
2024-09-12 15:11 ` Bryan O'Donoghue
2024-09-12 20:57 ` Vladimir Zapolskiy
2024-09-12 22:41 ` Bryan O'Donoghue
2024-09-13 5:06 ` Vladimir Zapolskiy
2024-09-17 22:40 ` Bryan O'Donoghue
2024-09-17 23:16 ` Vladimir Zapolskiy
2024-09-25 15:40 ` Depeng Shao
2024-09-30 9:26 ` Depeng Shao
2024-10-08 13:50 ` Vladimir Zapolskiy
2024-10-08 14:06 ` Bryan O'Donoghue
2024-10-08 15:47 ` Depeng Shao
2024-09-30 10:21 ` Bryan O'Donoghue
2024-09-13 4:17 ` Dmitry Baryshkov
2024-09-12 13:48 ` Neil Armstrong
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).