* [PATCH 01/13] media: qcom: camss: csiphy-3ph: Fix trivial indentation fault in defines
2024-08-12 14:41 [PATCH v4 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
@ 2024-08-12 14:41 ` Depeng Shao
2024-08-12 14:41 ` [PATCH 02/13] media: qcom: camss: csiphy-3ph: Remove redundant PHY init sequence control loop Depeng Shao
` (12 subsequent siblings)
13 siblings, 0 replies; 107+ 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, Elliot Berman, Vladimir Zapolskiy
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>
---
.../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] 107+ messages in thread* [PATCH 02/13] media: qcom: camss: csiphy-3ph: Remove redundant PHY init sequence control loop
2024-08-12 14:41 [PATCH v4 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
2024-08-12 14:41 ` [PATCH 01/13] media: qcom: camss: csiphy-3ph: Fix trivial indentation fault in defines Depeng Shao
@ 2024-08-12 14:41 ` Depeng Shao
2024-08-12 14:41 ` [PATCH 03/13] media: qcom: camss: csiphy-3ph: Rename struct Depeng Shao
` (11 subsequent siblings)
13 siblings, 0 replies; 107+ 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, Elliot Berman, Vladimir Zapolskiy
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>
---
.../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] 107+ messages in thread* [PATCH 03/13] media: qcom: camss: csiphy-3ph: Rename struct
2024-08-12 14:41 [PATCH v4 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
2024-08-12 14:41 ` [PATCH 01/13] media: qcom: camss: csiphy-3ph: Fix trivial indentation fault in defines Depeng Shao
2024-08-12 14:41 ` [PATCH 02/13] media: qcom: camss: csiphy-3ph: Remove redundant PHY init sequence control loop Depeng Shao
@ 2024-08-12 14:41 ` Depeng Shao
2024-08-12 14:41 ` [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices Depeng Shao
` (10 subsequent siblings)
13 siblings, 0 replies; 107+ 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, Elliot Berman, Vladimir Zapolskiy
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>
---
.../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] 107+ messages in thread* [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices
2024-08-12 14:41 [PATCH v4 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (2 preceding siblings ...)
2024-08-12 14:41 ` [PATCH 03/13] media: qcom: camss: csiphy-3ph: Rename struct Depeng Shao
@ 2024-08-12 14:41 ` Depeng Shao
2024-08-19 0:17 ` Vladimir Zapolskiy
2024-08-12 14:41 ` [PATCH 05/13] media: qcom: camss: csiphy-3ph: Move CSIPHY variables to data field inside csiphy struct Depeng Shao
` (9 subsequent siblings)
13 siblings, 1 reply; 107+ 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
From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Add a nop init callback to CSIPHY devices, this callback is used to add
some HW register offset and register configuration for specific platform,
then different platform can reuse the same CSIPHY driver. Later changes
will enumerate with enabling code.
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Depeng Shao <quic_depengs@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] 107+ messages in thread* Re: [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices
2024-08-12 14:41 ` [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices Depeng Shao
@ 2024-08-19 0:17 ` Vladimir Zapolskiy
2024-09-04 14:20 ` Depeng Shao
0 siblings, 1 reply; 107+ messages in thread
From: Vladimir Zapolskiy @ 2024-08-19 0: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
On 8/12/24 17:41, Depeng Shao wrote:
> From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>
> Add a nop init callback to CSIPHY devices, this callback is used to add
> some HW register offset and register configuration for specific platform,
> then different platform can reuse the same CSIPHY driver. Later changes
> will enumerate with enabling code.
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Signed-off-by: Depeng Shao <quic_depengs@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;
> +}
As far as I see from the patchset there is no intention to populate this function,
see a comment below.
> 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;
I've already expressed concerns about a necessity of this function, since it
adds runtime burden of work, which can be successfully done at compile time,
but okay...
Since it is needed for 3PH case only, it may make sense to remove it from 2PH
and call it here conditionally like
if (csiphy->res->hw_ops->init)
ret = csiphy->res->hw_ops->init(csiphy);
But it's up to you, I hope the callback will be removed in short future.
> /* 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] 107+ messages in thread* Re: [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices
2024-08-19 0:17 ` Vladimir Zapolskiy
@ 2024-09-04 14:20 ` Depeng Shao
2024-09-04 14:51 ` Bryan O'Donoghue
0 siblings, 1 reply; 107+ messages in thread
From: Depeng Shao @ 2024-09-04 14:20 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
Hi Bryan,
On 8/19/2024 8:17 AM, Vladimir Zapolskiy wrote:
> On 8/12/24 17:41, Depeng Shao wrote:
>> From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> I've already expressed concerns about a necessity of this function,
> since it
> adds runtime burden of work, which can be successfully done at compile
> time,
> but okay...
>
> Since it is needed for 3PH case only, it may make sense to remove it
> from 2PH
> and call it here conditionally like
>
> if (csiphy->res->hw_ops->init)
> ret = csiphy->res->hw_ops->init(csiphy);
>
> But it's up to you, I hope the callback will be removed in short future.
>
Could you please comment on if it is fine to remove the init from 2PH
driver?
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices
2024-09-04 14:20 ` Depeng Shao
@ 2024-09-04 14:51 ` Bryan O'Donoghue
0 siblings, 0 replies; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-09-04 14:51 UTC (permalink / raw)
To: Depeng Shao, Vladimir Zapolskiy, rfoss, todor.too, mchehab, robh,
krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel
On 04/09/2024 15:20, Depeng Shao wrote:
> Hi Bryan,
>
> On 8/19/2024 8:17 AM, Vladimir Zapolskiy wrote:
>> On 8/12/24 17:41, Depeng Shao wrote:
>>> From: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>
>> I've already expressed concerns about a necessity of this function,
>> since it
>> adds runtime burden of work, which can be successfully done at compile
>> time,
>> but okay...
>>
>> Since it is needed for 3PH case only, it may make sense to remove it
>> from 2PH
>> and call it here conditionally like
>>
>> if (csiphy->res->hw_ops->init)
>> ret = csiphy->res->hw_ops->init(csiphy);
>>
>> But it's up to you, I hope the callback will be removed in short future.
>>
>
> Could you please comment on if it is fine to remove the init from 2PH
> driver?
>
>
> Thanks,
> Depeng
Yes, its dead code ATM we can enumerate this callback when/if its needed.
Agreed.
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread
* [PATCH 05/13] media: qcom: camss: csiphy-3ph: Move CSIPHY variables to data field inside csiphy struct
2024-08-12 14:41 [PATCH v4 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (3 preceding siblings ...)
2024-08-12 14:41 ` [PATCH 04/13] media: qcom: camss: csiphy: Add an init callback to CSI PHY devices Depeng Shao
@ 2024-08-12 14:41 ` Depeng Shao
2024-08-19 0:01 ` Vladimir Zapolskiy
2024-08-12 14:41 ` [PATCH 06/13] media: qcom: camss: csiphy-3ph: Use an offset variable to find common control regs Depeng Shao
` (8 subsequent siblings)
13 siblings, 1 reply; 107+ 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, Vladimir Zapolskiy
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>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
---
.../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] 107+ messages in thread* Re: [PATCH 05/13] media: qcom: camss: csiphy-3ph: Move CSIPHY variables to data field inside csiphy struct
2024-08-12 14:41 ` [PATCH 05/13] media: qcom: camss: csiphy-3ph: Move CSIPHY variables to data field inside csiphy struct Depeng Shao
@ 2024-08-19 0:01 ` Vladimir Zapolskiy
2024-08-28 14:11 ` Depeng Shao
0 siblings, 1 reply; 107+ messages in thread
From: Vladimir Zapolskiy @ 2024-08-19 0: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
On 8/12/24 17:41, 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>
> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> ---
> .../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;
I would suggest to make the type/name above explicit:
struct csiphy_device_regs *regs;
> };
>
> struct camss_subdev_resources;
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 05/13] media: qcom: camss: csiphy-3ph: Move CSIPHY variables to data field inside csiphy struct
2024-08-19 0:01 ` Vladimir Zapolskiy
@ 2024-08-28 14:11 ` Depeng Shao
0 siblings, 0 replies; 107+ messages in thread
From: Depeng Shao @ 2024-08-28 14:11 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
Hi Bryan,
On 8/19/2024 8:01 AM, Vladimir Zapolskiy wrote:
> On 8/12/24 17:41, 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>
>> Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
>> ---
>> .../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.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;
>
> I would suggest to make the type/name above explicit:
>
I will follow Vladimir's suggestion to update the type/name, please
reply this mail if you have other comment.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread
* [PATCH 06/13] media: qcom: camss: csiphy-3ph: Use an offset variable to find common control regs
2024-08-12 14:41 [PATCH v4 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (4 preceding siblings ...)
2024-08-12 14:41 ` [PATCH 05/13] media: qcom: camss: csiphy-3ph: Move CSIPHY variables to data field inside csiphy struct Depeng Shao
@ 2024-08-12 14:41 ` Depeng Shao
2024-08-18 23:59 ` Vladimir Zapolskiy
2024-08-12 14:41 ` [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding Depeng Shao
` (7 subsequent siblings)
13 siblings, 1 reply; 107+ 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
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] 107+ messages in thread* Re: [PATCH 06/13] media: qcom: camss: csiphy-3ph: Use an offset variable to find common control regs
2024-08-12 14:41 ` [PATCH 06/13] media: qcom: camss: csiphy-3ph: Use an offset variable to find common control regs Depeng Shao
@ 2024-08-18 23:59 ` Vladimir Zapolskiy
0 siblings, 0 replies; 107+ messages in thread
From: Vladimir Zapolskiy @ 2024-08-18 23:59 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
On 8/12/24 17:41, Depeng Shao wrote:
> 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))
Macro value above shall be this one: ((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))
Macro value above shall be this one: ((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;
> };
>
With two minor fixes above,
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 107+ messages in thread
* [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding
2024-08-12 14:41 [PATCH v4 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (5 preceding siblings ...)
2024-08-12 14:41 ` [PATCH 06/13] media: qcom: camss: csiphy-3ph: Use an offset variable to find common control regs Depeng Shao
@ 2024-08-12 14:41 ` Depeng Shao
2024-08-16 7:01 ` Krzysztof Kozlowski
` (3 more replies)
2024-08-12 14:41 ` [PATCH 08/13] media: qcom: camss: csid: Move common code into csid core Depeng Shao
` (6 subsequent siblings)
13 siblings, 4 replies; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ 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; 107+ 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] 107+ messages in thread
* [PATCH 08/13] media: qcom: camss: csid: Move common code into csid core
2024-08-12 14:41 [PATCH v4 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (6 preceding siblings ...)
2024-08-12 14:41 ` [PATCH 07/13] dt-bindings: media: camss: Add qcom,sm8550-camss binding Depeng Shao
@ 2024-08-12 14:41 ` Depeng Shao
2024-08-14 23:53 ` Bryan O'Donoghue
2024-08-12 14:41 ` [PATCH 09/13] media: qcom: camss: vfe: Move common code into vfe core Depeng Shao
` (5 subsequent siblings)
13 siblings, 1 reply; 107+ 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
The get hw version and src pad code functions can be common code in csid
core file, then the csid driver of different hw version can reuse them,
rather than adding duplicate code in csid driver for each version.
Suggested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
---
.../platform/qcom/camss/camss-csid-4-1.c | 19 -----
.../platform/qcom/camss/camss-csid-4-7.c | 42 ----------
.../platform/qcom/camss/camss-csid-gen2.c | 60 ---------------
.../media/platform/qcom/camss/camss-csid.c | 77 +++++++++++++++++++
.../media/platform/qcom/camss/camss-csid.h | 21 +++++
5 files changed, 98 insertions(+), 121 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-csid-4-1.c b/drivers/media/platform/qcom/camss/camss-csid-4-1.c
index c95861420502..6998e1c52895 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-4-1.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-4-1.c
@@ -17,7 +17,6 @@
#include "camss-csid-gen1.h"
#include "camss.h"
-#define CAMSS_CSID_HW_VERSION 0x0
#define CAMSS_CSID_CORE_CTRL_0 0x004
#define CAMSS_CSID_CORE_CTRL_1 0x008
#define CAMSS_CSID_RST_CMD 0x00c
@@ -139,15 +138,6 @@ static int csid_configure_testgen_pattern(struct csid_device *csid, s32 val)
return 0;
}
-static u32 csid_hw_version(struct csid_device *csid)
-{
- u32 hw_version = readl_relaxed(csid->base + CAMSS_CSID_HW_VERSION);
-
- dev_dbg(csid->camss->dev, "CSID HW Version = 0x%08x\n", hw_version);
-
- return hw_version;
-}
-
static irqreturn_t csid_isr(int irq, void *dev)
{
struct csid_device *csid = dev;
@@ -180,15 +170,6 @@ static int csid_reset(struct csid_device *csid)
return 0;
}
-static u32 csid_src_pad_code(struct csid_device *csid, u32 sink_code,
- unsigned int match_format_idx, u32 match_code)
-{
- 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;
diff --git a/drivers/media/platform/qcom/camss/camss-csid-4-7.c b/drivers/media/platform/qcom/camss/camss-csid-4-7.c
index 08578a143688..66054d4872e6 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-4-7.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-4-7.c
@@ -16,7 +16,6 @@
#include "camss-csid-gen1.h"
#include "camss.h"
-#define CAMSS_CSID_HW_VERSION 0x0
#define CAMSS_CSID_CORE_CTRL_0 0x004
#define CAMSS_CSID_CORE_CTRL_1 0x008
#define CAMSS_CSID_RST_CMD 0x010
@@ -151,15 +150,6 @@ static int csid_configure_testgen_pattern(struct csid_device *csid, s32 val)
return 0;
}
-static u32 csid_hw_version(struct csid_device *csid)
-{
- u32 hw_version = readl_relaxed(csid->base + CAMSS_CSID_HW_VERSION);
-
- dev_dbg(csid->camss->dev, "CSID HW Version = 0x%08x\n", hw_version);
-
- return hw_version;
-}
-
/*
* isr - CSID module interrupt service routine
* @irq: Interrupt line
@@ -205,38 +195,6 @@ static int csid_reset(struct csid_device *csid)
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;
diff --git a/drivers/media/platform/qcom/camss/camss-csid-gen2.c b/drivers/media/platform/qcom/camss/camss-csid-gen2.c
index e1c757933e27..2a1746dcc1c5 100644
--- a/drivers/media/platform/qcom/camss/camss-csid-gen2.c
+++ b/drivers/media/platform/qcom/camss/camss-csid-gen2.c
@@ -22,11 +22,6 @@
* alternate register layout.
*/
-#define CSID_HW_VERSION 0x0
-#define HW_VERSION_STEPPING 0
-#define HW_VERSION_REVISION 16
-#define HW_VERSION_GENERATION 28
-
#define CSID_RST_STROBES 0x10
#define RST_STROBES 0
@@ -351,29 +346,6 @@ static int csid_configure_testgen_pattern(struct csid_device *csid, s32 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_dbg(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
@@ -443,38 +415,6 @@ static int csid_reset(struct csid_device *csid)
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;
diff --git a/drivers/media/platform/qcom/camss/camss-csid.c b/drivers/media/platform/qcom/camss/camss-csid.c
index 858db5d4ca75..5806df7e7a7c 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.c
+++ b/drivers/media/platform/qcom/camss/camss-csid.c
@@ -29,6 +29,11 @@
#define VFE_480_CSID_OFFSET 0x1200
#define VFE_480_LITE_CSID_OFFSET 0x200
+#define CSID_HW_VERSION 0x0
+#define HW_VERSION_STEPPING 0
+#define HW_VERSION_REVISION 16
+#define HW_VERSION_GENERATION 28
+
#define MSM_CSID_NAME "msm_csid"
const char * const csid_testgen_modes[] = {
@@ -590,6 +595,78 @@ static int csid_set_clock_rates(struct csid_device *csid)
return 0;
}
+/*
+ * csid_hw_version - CSID hardware version query
+ * @csid: CSID device
+ *
+ * Return HW version or error
+ */
+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:%d HW Version = %u.%u.%u\n",
+ csid->id, hw_gen, hw_rev, hw_step);
+
+ return hw_version;
+}
+
+/*
+ * csid_src_pad_code - Pick an output/src format based on the input/sink format
+ * @csid: CSID device
+ * @sink_code: The sink format of the input
+ * @match_format_idx: Request preferred index, as defined by subdevice csid
+ * format. Set @match_code to 0 if used.
+ * @match_code: Request preferred code, set @match_format_idx to 0 if used
+ *
+ * Return 0 on failure or src format code otherwise
+ */
+u32 csid_src_pad_code(struct csid_device *csid, u32 sink_code,
+ unsigned int match_format_idx, u32 match_code)
+{
+ if (csid->camss->res->version == CAMSS_8x16) {
+ if (match_format_idx > 0)
+ return 0;
+
+ return sink_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;
+ }
+}
+
/*
* csid_set_power - Power on/off CSID module
* @sd: CSID V4L2 subdevice
diff --git a/drivers/media/platform/qcom/camss/camss-csid.h b/drivers/media/platform/qcom/camss/camss-csid.h
index 8cdae98e4dca..f52209b96583 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.h
+++ b/drivers/media/platform/qcom/camss/camss-csid.h
@@ -237,4 +237,25 @@ extern const struct csid_hw_ops csid_ops_gen2;
*/
bool csid_is_lite(struct csid_device *csid);
+/*
+ * csid_hw_version - CSID hardware version query
+ * @csid: CSID device
+ *
+ * Return HW version or error
+ */
+u32 csid_hw_version(struct csid_device *csid);
+
+/*
+ * csid_src_pad_code - Pick an output/src format based on the input/sink format
+ * @csid: CSID device
+ * @sink_code: The sink format of the input
+ * @match_format_idx: Request preferred index, as defined by subdevice csid
+ * format. Set @match_code to 0 if used.
+ * @match_code: Request preferred code, set @match_format_idx to 0 if used
+ *
+ * Return 0 on failure or src format code otherwise
+ */
+u32 csid_src_pad_code(struct csid_device *csid, u32 sink_code,
+ unsigned int match_format_idx, u32 match_code);
+
#endif /* QC_MSM_CAMSS_CSID_H */
--
2.34.1
^ permalink raw reply related [flat|nested] 107+ messages in thread* Re: [PATCH 08/13] media: qcom: camss: csid: Move common code into csid core
2024-08-12 14:41 ` [PATCH 08/13] media: qcom: camss: csid: Move common code into csid core Depeng Shao
@ 2024-08-14 23:53 ` Bryan O'Donoghue
2024-08-24 12:50 ` Vladimir Zapolskiy
0 siblings, 1 reply; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-14 23:53 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel
On 12/08/2024 15:41, Depeng Shao wrote:
> The get hw version and src pad code functions can be common code in csid
> core file, then the csid driver of different hw version can reuse them,
> rather than adding duplicate code in csid driver for each version.
>
> Suggested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> ---
> .../platform/qcom/camss/camss-csid-4-1.c | 19 -----
> .../platform/qcom/camss/camss-csid-4-7.c | 42 ----------
> .../platform/qcom/camss/camss-csid-gen2.c | 60 ---------------
> .../media/platform/qcom/camss/camss-csid.c | 77 +++++++++++++++++++
> .../media/platform/qcom/camss/camss-csid.h | 21 +++++
> 5 files changed, 98 insertions(+), 121 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss/camss-csid-4-1.c b/drivers/media/platform/qcom/camss/camss-csid-4-1.c
> index c95861420502..6998e1c52895 100644
> --- a/drivers/media/platform/qcom/camss/camss-csid-4-1.c
> +++ b/drivers/media/platform/qcom/camss/camss-csid-4-1.c
> @@ -17,7 +17,6 @@
> #include "camss-csid-gen1.h"
> #include "camss.h"
>
> -#define CAMSS_CSID_HW_VERSION 0x0
> #define CAMSS_CSID_CORE_CTRL_0 0x004
> #define CAMSS_CSID_CORE_CTRL_1 0x008
> #define CAMSS_CSID_RST_CMD 0x00c
> @@ -139,15 +138,6 @@ static int csid_configure_testgen_pattern(struct csid_device *csid, s32 val)
> return 0;
> }
>
> -static u32 csid_hw_version(struct csid_device *csid)
> -{
> - u32 hw_version = readl_relaxed(csid->base + CAMSS_CSID_HW_VERSION);
> -
> - dev_dbg(csid->camss->dev, "CSID HW Version = 0x%08x\n", hw_version);
> -
> - return hw_version;
> -}
>
> -static u32 csid_hw_version(struct csid_device *csid)
> -{
> - u32 hw_version = readl_relaxed(csid->base + CAMSS_CSID_HW_VERSION);
> -
> - dev_dbg(csid->camss->dev, "CSID HW Version = 0x%08x\n", hw_version);
> -
> - return hw_version;
> -}
Is it also the case with csid-4-1 and csid-47 that the HW version is in
the format x.x.x - because you're removing this printout which just
prints the register in favour of a later function that decodes that
register into three parts.
Suggest having a csid_hw_version_gen1() for these two and a
csid_hw_version_gen2() which does the x.x.x print instead.
=> camss-csid-4-1.c and camss-csid-4-7.c will have hw_version =
csid_hw_version_gen1()
=> camss-csid-gen2, camss-csid-790 will have hw_version = hw_version_gen2()
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 08/13] media: qcom: camss: csid: Move common code into csid core
2024-08-14 23:53 ` Bryan O'Donoghue
@ 2024-08-24 12:50 ` Vladimir Zapolskiy
0 siblings, 0 replies; 107+ messages in thread
From: Vladimir Zapolskiy @ 2024-08-24 12:50 UTC (permalink / raw)
To: Bryan O'Donoghue, Depeng Shao, rfoss, todor.too, mchehab,
robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel
On 8/15/24 02:53, Bryan O'Donoghue wrote:
> On 12/08/2024 15:41, Depeng Shao wrote:
>> The get hw version and src pad code functions can be common code in csid
>> core file, then the csid driver of different hw version can reuse them,
>> rather than adding duplicate code in csid driver for each version.
>>
>> Suggested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
>> ---
>> .../platform/qcom/camss/camss-csid-4-1.c | 19 -----
>> .../platform/qcom/camss/camss-csid-4-7.c | 42 ----------
>> .../platform/qcom/camss/camss-csid-gen2.c | 60 ---------------
>> .../media/platform/qcom/camss/camss-csid.c | 77 +++++++++++++++++++
>> .../media/platform/qcom/camss/camss-csid.h | 21 +++++
>> 5 files changed, 98 insertions(+), 121 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/camss/camss-csid-4-1.c b/drivers/media/platform/qcom/camss/camss-csid-4-1.c
>> index c95861420502..6998e1c52895 100644
>> --- a/drivers/media/platform/qcom/camss/camss-csid-4-1.c
>> +++ b/drivers/media/platform/qcom/camss/camss-csid-4-1.c
>> @@ -17,7 +17,6 @@
>> #include "camss-csid-gen1.h"
>> #include "camss.h"
>>
>> -#define CAMSS_CSID_HW_VERSION 0x0
>> #define CAMSS_CSID_CORE_CTRL_0 0x004
>> #define CAMSS_CSID_CORE_CTRL_1 0x008
>> #define CAMSS_CSID_RST_CMD 0x00c
>> @@ -139,15 +138,6 @@ static int csid_configure_testgen_pattern(struct csid_device *csid, s32 val)
>> return 0;
>> }
>>
>> -static u32 csid_hw_version(struct csid_device *csid)
>> -{
>> - u32 hw_version = readl_relaxed(csid->base + CAMSS_CSID_HW_VERSION);
>> -
>> - dev_dbg(csid->camss->dev, "CSID HW Version = 0x%08x\n", hw_version);
>> -
>> - return hw_version;
>> -}
>>
>> -static u32 csid_hw_version(struct csid_device *csid)
>> -{
>> - u32 hw_version = readl_relaxed(csid->base + CAMSS_CSID_HW_VERSION);
>> -
>> - dev_dbg(csid->camss->dev, "CSID HW Version = 0x%08x\n", hw_version);
>> -
>> - return hw_version;
>> -}
>
> Is it also the case with csid-4-1 and csid-47 that the HW version is in
> the format x.x.x - because you're removing this printout which just
> prints the register in favour of a later function that decodes that
> register into three parts.
>
> Suggest having a csid_hw_version_gen1() for these two and a
> csid_hw_version_gen2() which does the x.x.x print instead.
>
> => camss-csid-4-1.c and camss-csid-4-7.c will have hw_version =
> csid_hw_version_gen1()
>
> => camss-csid-gen2, camss-csid-790 will have hw_version = hw_version_gen2()
>
I believe here two different output formats is unnecessary, let's just stick
to one or another version (not important which one) for all platforms.
In any case for sake of simplicity there should be just one generic function,
and, if for whatever reason it is necessary to print out different formats,
this shall be selected in runtime within a single shared function.
FWIW, I'm quite happy with the current version.
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 107+ messages in thread
* [PATCH 09/13] media: qcom: camss: vfe: Move common code into vfe core
2024-08-12 14:41 [PATCH v4 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (7 preceding siblings ...)
2024-08-12 14:41 ` [PATCH 08/13] media: qcom: camss: csid: Move common code into csid core Depeng Shao
@ 2024-08-12 14:41 ` Depeng Shao
2024-08-15 0:09 ` Bryan O'Donoghue
2024-08-12 14:41 ` [PATCH 10/13] media: qcom: camss: Add sm8550 compatible Depeng Shao
` (4 subsequent siblings)
13 siblings, 1 reply; 107+ 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
Some v4l2 buffer related logic functions can be moved to vfe core as
common code, then the vfe driver of different hw version can reuse them,
this also can avoid adding duplicate code for new version supporting.
Suggested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
---
.../media/platform/qcom/camss/camss-vfe-17x.c | 112 +-------
.../media/platform/qcom/camss/camss-vfe-4-1.c | 9 -
.../media/platform/qcom/camss/camss-vfe-4-7.c | 11 -
.../media/platform/qcom/camss/camss-vfe-4-8.c | 11 -
.../media/platform/qcom/camss/camss-vfe-480.c | 258 +----------------
drivers/media/platform/qcom/camss/camss-vfe.c | 264 ++++++++++++++++++
drivers/media/platform/qcom/camss/camss-vfe.h | 58 +++-
7 files changed, 340 insertions(+), 383 deletions(-)
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-17x.c b/drivers/media/platform/qcom/camss/camss-vfe-17x.c
index 380c99321030..e5ee7e717b3b 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-17x.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-17x.c
@@ -14,8 +14,6 @@
#include "camss.h"
#include "camss-vfe.h"
-#define VFE_HW_VERSION (0x000)
-
#define VFE_GLOBAL_RESET_CMD (0x018)
#define GLOBAL_RESET_CMD_CORE BIT(0)
#define GLOBAL_RESET_CMD_CAMIF BIT(1)
@@ -176,20 +174,6 @@
#define VFE_BUS_WM_FRAME_INC(n) (0x2258 + (n) * 0x100)
#define VFE_BUS_WM_BURST_LIMIT(n) (0x225c + (n) * 0x100)
-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_dbg(vfe->camss->dev, "VFE HW Version = %u.%u.%u\n",
- gen, rev, step);
-
- return hw_version;
-}
-
static inline void vfe_reg_set(struct vfe_device *vfe, u32 reg, u32 set_bits)
{
u32 bits = readl_relaxed(vfe->base + reg);
@@ -438,62 +422,6 @@ static int vfe_get_output(struct vfe_line *line)
return -EINVAL;
}
-static int vfe_enable_output(struct vfe_line *line)
-{
- struct vfe_device *vfe = to_vfe(line);
- struct vfe_output *output = &line->output;
- const struct vfe_hw_ops *ops = vfe->res->hw_ops;
- struct media_entity *sensor;
- unsigned long flags;
- unsigned int frame_skip = 0;
- unsigned int i;
-
- sensor = camss_find_sensor(&line->subdev.entity);
- if (sensor) {
- struct v4l2_subdev *subdev = media_entity_to_v4l2_subdev(sensor);
-
- v4l2_subdev_call(subdev, sensor, g_skip_frames, &frame_skip);
- /* Max frame skip is 29 frames */
- if (frame_skip > VFE_FRAME_DROP_VAL - 1)
- frame_skip = VFE_FRAME_DROP_VAL - 1;
- }
-
- spin_lock_irqsave(&vfe->output_lock, flags);
-
- ops->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;
- output->wait_reg_update = 0;
- reinit_completion(&output->reg_update);
-
- vfe_wm_start(vfe, output->wm_idx[0], line);
-
- for (i = 0; i < 2; 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);
- }
-
- ops->reg_update(vfe, line->id);
-
- spin_unlock_irqrestore(&vfe->output_lock, flags);
-
- return 0;
-}
-
/*
* vfe_enable - Enable streaming on VFE line
* @line: VFE line
@@ -518,7 +446,7 @@ static int vfe_enable(struct vfe_line *line)
if (ret < 0)
goto error_get_output;
- ret = vfe_enable_output(line);
+ ret = vfe_enable_output_v2(line);
if (ret < 0)
goto error_enable_output;
@@ -627,40 +555,6 @@ static void vfe_isr_wm_done(struct vfe_device *vfe, u8 wm)
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 < 2) {
- output->buf[output->gen2.active_num++] = buf;
- vfe_wm_update(vfe, output->wm_idx[0], buf->addr[0], line);
- } else {
- vfe_buf_add_pending(output, buf);
- }
-
- spin_unlock_irqrestore(&vfe->output_lock, flags);
-
- return 0;
-}
-
static const struct vfe_isr_ops vfe_isr_ops_170 = {
.reset_ack = vfe_isr_reset_ack,
.halt_ack = vfe_isr_halt_ack,
@@ -671,7 +565,7 @@ static const struct vfe_isr_ops vfe_isr_ops_170 = {
};
static const struct camss_video_ops vfe_video_ops_170 = {
- .queue_buffer = vfe_queue_buffer,
+ .queue_buffer = vfe_queue_buffer_v2,
.flush_buffers = vfe_flush_buffers,
};
@@ -695,5 +589,7 @@ const struct vfe_hw_ops vfe_ops_170 = {
.vfe_enable = vfe_enable,
.vfe_halt = vfe_halt,
.violation_read = vfe_violation_read,
+ .vfe_wm_start = vfe_wm_start,
.vfe_wm_stop = vfe_wm_stop,
+ .vfe_wm_update = vfe_wm_update,
};
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
index 1bd3a6ef1d04..6930799f77c2 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
@@ -210,15 +210,6 @@
#define MSM_VFE_VFE0_UB_SIZE 1023
#define MSM_VFE_VFE0_UB_SIZE_RDI (MSM_VFE_VFE0_UB_SIZE / 3)
-static u32 vfe_hw_version(struct vfe_device *vfe)
-{
- u32 hw_version = readl_relaxed(vfe->base + VFE_0_HW_VERSION);
-
- dev_dbg(vfe->camss->dev, "VFE HW Version = 0x%08x\n", hw_version);
-
- return hw_version;
-}
-
static u16 vfe_get_ub_size(u8 vfe_id)
{
if (vfe_id == 0)
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
index ce0719106bd3..76729607db02 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
@@ -18,8 +18,6 @@
#include "camss-vfe-gen1.h"
-#define VFE_0_HW_VERSION 0x000
-
#define VFE_0_GLOBAL_RESET_CMD 0x018
#define VFE_0_GLOBAL_RESET_CMD_CORE BIT(0)
#define VFE_0_GLOBAL_RESET_CMD_CAMIF BIT(1)
@@ -254,15 +252,6 @@
#define MSM_VFE_VFE1_UB_SIZE 1535
#define MSM_VFE_VFE1_UB_SIZE_RDI (MSM_VFE_VFE1_UB_SIZE / 3)
-static u32 vfe_hw_version(struct vfe_device *vfe)
-{
- u32 hw_version = readl_relaxed(vfe->base + VFE_0_HW_VERSION);
-
- dev_dbg(vfe->camss->dev, "VFE HW Version = 0x%08x\n", hw_version);
-
- return hw_version;
-}
-
static u16 vfe_get_ub_size(u8 vfe_id)
{
if (vfe_id == 0)
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-8.c b/drivers/media/platform/qcom/camss/camss-vfe-4-8.c
index 6b59c8107a3c..b2f7d855d8dd 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-4-8.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-4-8.c
@@ -17,8 +17,6 @@
#include "camss-vfe.h"
#include "camss-vfe-gen1.h"
-#define VFE_0_HW_VERSION 0x000
-
#define VFE_0_GLOBAL_RESET_CMD 0x018
#define VFE_0_GLOBAL_RESET_CMD_CORE BIT(0)
#define VFE_0_GLOBAL_RESET_CMD_CAMIF BIT(1)
@@ -247,15 +245,6 @@
#define MSM_VFE_VFE1_UB_SIZE 1535
#define MSM_VFE_VFE1_UB_SIZE_RDI (MSM_VFE_VFE1_UB_SIZE / 3)
-static u32 vfe_hw_version(struct vfe_device *vfe)
-{
- u32 hw_version = readl_relaxed(vfe->base + VFE_0_HW_VERSION);
-
- dev_dbg(vfe->camss->dev, "VFE HW Version = 0x%08x\n", hw_version);
-
- return hw_version;
-}
-
static inline void vfe_reg_clr(struct vfe_device *vfe, u32 reg, u32 clr_bits)
{
u32 bits = readl_relaxed(vfe->base + reg);
diff --git a/drivers/media/platform/qcom/camss/camss-vfe-480.c b/drivers/media/platform/qcom/camss/camss-vfe-480.c
index dc2735476c82..e6d3b27de323 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe-480.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe-480.c
@@ -15,8 +15,6 @@
#include "camss.h"
#include "camss-vfe.h"
-#define VFE_HW_VERSION (0x00)
-
#define VFE_GLOBAL_RESET_CMD (vfe_is_lite(vfe) ? 0x0c : 0x1c)
#define GLOBAL_RESET_HW_AND_REG (vfe_is_lite(vfe) ? BIT(1) : BIT(0))
@@ -92,19 +90,6 @@ static inline int bus_irq_mask_0_comp_done(struct vfe_device *vfe, int n)
#define MAX_VFE_OUTPUT_LINES 4
-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_dbg(vfe->camss->dev, "VFE HW Version = %u.%u.%u\n", gen, rev, step);
-
- return hw_version;
-}
-
static void vfe_global_reset(struct vfe_device *vfe)
{
writel_relaxed(IRQ_MASK_0_RESET_ACK, vfe->base + VFE_IRQ_MASK(0));
@@ -167,18 +152,16 @@ static inline void vfe_reg_update_clear(struct vfe_device *vfe,
vfe->reg_update &= ~REG_UPDATE_RDI(vfe, line_id);
}
-static void vfe_enable_irq_common(struct vfe_device *vfe)
-{
- /* enable reset ack IRQ and top BUS status IRQ */
- writel_relaxed(IRQ_MASK_0_RESET_ACK | IRQ_MASK_0_BUS_TOP_IRQ,
- vfe->base + VFE_IRQ_MASK(0));
-}
-
-static void vfe_enable_lines_irq(struct vfe_device *vfe)
+static void vfe_enable_irq(struct vfe_device *vfe)
{
int i;
u32 bus_irq_mask = 0;
+ if (!vfe->stream_count)
+ /* enable reset ack IRQ and top BUS status IRQ */
+ writel(IRQ_MASK_0_RESET_ACK | IRQ_MASK_0_BUS_TOP_IRQ,
+ vfe->base + VFE_IRQ_MASK(0));
+
for (i = 0; i < MAX_VFE_OUTPUT_LINES; i++) {
/* Enable IRQ for newly added lines, but also keep already running lines's IRQ */
if (vfe->line[i].output.state == VFE_OUTPUT_RESERVED ||
@@ -188,11 +171,10 @@ static void vfe_enable_lines_irq(struct vfe_device *vfe)
}
}
- writel_relaxed(bus_irq_mask, vfe->base + VFE_BUS_IRQ_MASK(0));
+ writel(bus_irq_mask, vfe->base + VFE_BUS_IRQ_MASK(0));
}
static void vfe_isr_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id);
-static void vfe_isr_wm_done(struct vfe_device *vfe, u8 wm);
/*
* vfe_isr - VFE module interrupt handler
@@ -226,7 +208,7 @@ static irqreturn_t vfe_isr(int irq, void *dev)
vfe_isr_reg_update(vfe, i);
if (status & BUS_IRQ_MASK_0_COMP_DONE(vfe, RDI_COMP_GROUP(i)))
- vfe_isr_wm_done(vfe, i);
+ vfe_buf_done(vfe, i);
}
}
@@ -245,132 +227,6 @@ static int vfe_halt(struct vfe_device *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;
- output->wait_reg_update = 0;
- reinit_completion(&output->reg_update);
-
- vfe_wm_start(vfe, output->wm_idx[0], line);
-
- for (i = 0; i < 2; 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);
-
- if (!vfe->stream_count)
- vfe_enable_irq_common(vfe);
-
- vfe->stream_count++;
-
- vfe_enable_lines_irq(vfe);
-
- 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_isr_reg_update - Process reg update interrupt
* @vfe: VFE Device
@@ -394,97 +250,8 @@ static void vfe_isr_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id)
spin_unlock_irqrestore(&vfe->output_lock, flags);
}
-/*
- * vfe_isr_wm_done - Process write master done interrupt
- * @vfe: VFE Device
- * @wm: Write master id
- */
-static void vfe_isr_wm_done(struct vfe_device *vfe, u8 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);
- 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 < 2) {
- output->buf[output->gen2.active_num++] = buf;
- vfe_wm_update(vfe, output->wm_idx[0], buf->addr[0], line);
- } 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_480 = {
- .queue_buffer = vfe_queue_buffer,
+ .queue_buffer = vfe_queue_buffer_v2,
.flush_buffers = vfe_flush_buffers,
};
@@ -494,6 +261,7 @@ static void vfe_subdev_init(struct device *dev, struct vfe_device *vfe)
}
const struct vfe_hw_ops vfe_ops_480 = {
+ .enable_irq = vfe_enable_irq,
.global_reset = vfe_global_reset,
.hw_version = vfe_hw_version,
.isr = vfe_isr,
@@ -501,7 +269,11 @@ const struct vfe_hw_ops vfe_ops_480 = {
.pm_domain_on = vfe_pm_domain_on,
.subdev_init = vfe_subdev_init,
.vfe_disable = vfe_disable,
- .vfe_enable = vfe_enable,
+ .vfe_enable = vfe_enable_v2,
.vfe_halt = vfe_halt,
+ .vfe_wm_start = vfe_wm_start,
.vfe_wm_stop = vfe_wm_stop,
+ .vfe_wm_update = vfe_wm_update,
+ .reg_update = vfe_reg_update,
+ .reg_update_clear = vfe_reg_update_clear,
};
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
index 83c5a36d071f..f6650694f47e 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -32,6 +32,11 @@
#define SCALER_RATIO_MAX 16
+#define VFE_HW_VERSION 0x0
+#define HW_VERSION_STEPPING 0
+#define HW_VERSION_REVISION 16
+#define HW_VERSION_GENERATION 28
+
static const struct camss_format_info formats_rdi_8x16[] = {
{ MEDIA_BUS_FMT_UYVY8_1X16, 8, V4L2_PIX_FMT_UYVY, 1,
PER_PLANE_DATA(0, 1, 1, 1, 1, 16) },
@@ -402,6 +407,265 @@ static u32 vfe_src_pad_code(struct vfe_line *line, u32 sink_code,
return 0;
}
+/*
+ * vfe_hw_version - Process write master done interrupt
+ * @vfe: VFE Device
+ *
+ * Return vfe hw version
+ */
+u32 vfe_hw_version(struct vfe_device *vfe)
+{
+ u32 hw_version = readl_relaxed(vfe->base + VFE_HW_VERSION);
+
+ u32 gen = (hw_version >> HW_VERSION_GENERATION) & 0xF;
+ u32 rev = (hw_version >> HW_VERSION_REVISION) & 0xFFF;
+ u32 step = (hw_version >> HW_VERSION_STEPPING) & 0xFFFF;
+
+ dev_info(vfe->camss->dev, "VFE:%d HW Version = %u.%u.%u\n",
+ vfe->id, gen, rev, step);
+
+ return hw_version;
+}
+
+/*
+ * vfe_buf_done - Process write master done interrupt
+ * @vfe: VFE Device
+ * @wm: Write master id
+ */
+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->res->hw_ops->vfe_wm_update(vfe, output->wm_idx[0],
+ output->buf[index]->addr[0],
+ line);
+ vfe->res->hw_ops->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);
+}
+
+int vfe_enable_output_v2(struct vfe_line *line)
+{
+ struct vfe_device *vfe = to_vfe(line);
+ struct vfe_output *output = &line->output;
+ const struct vfe_hw_ops *ops = vfe->res->hw_ops;
+ struct media_entity *sensor;
+ unsigned long flags;
+ unsigned int frame_skip = 0;
+ unsigned int i;
+
+ sensor = camss_find_sensor(&line->subdev.entity);
+ if (sensor) {
+ struct v4l2_subdev *subdev = media_entity_to_v4l2_subdev(sensor);
+
+ v4l2_subdev_call(subdev, sensor, g_skip_frames, &frame_skip);
+ /* Max frame skip is 29 frames */
+ if (frame_skip > VFE_FRAME_DROP_VAL - 1)
+ frame_skip = VFE_FRAME_DROP_VAL - 1;
+ }
+
+ spin_lock_irqsave(&vfe->output_lock, flags);
+
+ ops->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;
+ output->wait_reg_update = 0;
+ reinit_completion(&output->reg_update);
+
+ ops->vfe_wm_start(vfe, output->wm_idx[0], line);
+
+ for (i = 0; i < 2; i++) {
+ output->buf[i] = vfe_buf_get_pending(output);
+ if (!output->buf[i])
+ break;
+ output->gen2.active_num++;
+ ops->vfe_wm_update(vfe, output->wm_idx[0],
+ output->buf[i]->addr[0], line);
+ ops->reg_update(vfe, line->id);
+ }
+
+ spin_unlock_irqrestore(&vfe->output_lock, flags);
+
+ return 0;
+}
+
+/*
+ * vfe_queue_buffer_v2 - 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
+ */
+int vfe_queue_buffer_v2(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 < 2) {
+ output->buf[output->gen2.active_num++] = buf;
+ vfe->res->hw_ops->vfe_wm_update(vfe, output->wm_idx[0],
+ buf->addr[0], line);
+ vfe->res->hw_ops->reg_update(vfe, line->id);
+ } else {
+ vfe_buf_add_pending(output, buf);
+ }
+
+ spin_unlock_irqrestore(&vfe->output_lock, flags);
+
+ return 0;
+}
+
+/*
+ * vfe_enable_v2 - Enable streaming on VFE line
+ * @line: VFE line
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+int vfe_enable_v2(struct vfe_line *line)
+{
+ struct vfe_device *vfe = to_vfe(line);
+ int ret;
+
+ mutex_lock(&vfe->stream_lock);
+
+ if (vfe->res->hw_ops->enable_irq)
+ vfe->res->hw_ops->enable_irq(vfe);
+
+ vfe->stream_count++;
+
+ mutex_unlock(&vfe->stream_lock);
+
+ ret = vfe_get_output_v2(line);
+ if (ret < 0)
+ goto error_get_output;
+
+ ret = vfe_enable_output_v2(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_get_output_v2 - Get vfe output port for corresponding VFE line
+ * @line: VFE line
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+int vfe_get_output_v2(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;
+}
+
int vfe_reset(struct vfe_device *vfe)
{
unsigned long time;
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.h b/drivers/media/platform/qcom/camss/camss-vfe.h
index 10e2cc3c0b83..fcbf4f609129 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.h
+++ b/drivers/media/platform/qcom/camss/camss-vfe.h
@@ -99,7 +99,7 @@ struct vfe_line {
struct vfe_device;
struct vfe_hw_ops {
- void (*enable_irq_common)(struct vfe_device *vfe);
+ void (*enable_irq)(struct vfe_device *vfe);
void (*global_reset)(struct vfe_device *vfe);
u32 (*hw_version)(struct vfe_device *vfe);
irqreturn_t (*isr)(int irq, void *dev);
@@ -114,7 +114,12 @@ struct vfe_hw_ops {
int (*vfe_enable)(struct vfe_line *line);
int (*vfe_halt)(struct vfe_device *vfe);
void (*violation_read)(struct vfe_device *vfe);
+ void (*vfe_wm_start)(struct vfe_device *vfe, u8 wm,
+ struct vfe_line *line);
void (*vfe_wm_stop)(struct vfe_device *vfe, u8 wm);
+ void (*vfe_buf_done)(struct vfe_device *vfe, int port_id);
+ void (*vfe_wm_update)(struct vfe_device *vfe, u8 wm, u32 addr,
+ struct vfe_line *line);
};
struct vfe_isr_ops {
@@ -252,4 +257,55 @@ void vfe_put(struct vfe_device *vfe);
*/
bool vfe_is_lite(struct vfe_device *vfe);
+/*
+ * vfe_hw_version - Process write master done interrupt
+ * @vfe: VFE Device
+ *
+ * Return vfe hw version
+ */
+u32 vfe_hw_version(struct vfe_device *vfe);
+/*
+ * vfe_enable - Enable streaming on VFE line
+ * @line: VFE line
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+int vfe_enable_v2(struct vfe_line *line);
+
+/*
+ * vfe_buf_done - Process write master done interrupt
+ * @vfe: VFE Device
+ * @wm: Write master id
+ */
+void vfe_buf_done(struct vfe_device *vfe, int wm);
+
+/*
+ * vfe_get_output_v2 - Get vfe output line
+ * line: VFE line
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+int vfe_get_output_v2(struct vfe_line *line);
+
+/*
+ * vfe_enable_output_v2 - Enable vfe output line
+ * line: VFE line
+ *
+ * Return 0 on success or a negative error code otherwise
+ */
+int vfe_enable_output_v2(struct vfe_line *line);
+
+/*
+ * vfe_queue_buffer_v2 - 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
+ */
+int vfe_queue_buffer_v2(struct camss_video *vid,
+ struct camss_buffer *buf);
+
#endif /* QC_MSM_CAMSS_VFE_H */
--
2.34.1
^ permalink raw reply related [flat|nested] 107+ messages in thread* Re: [PATCH 09/13] media: qcom: camss: vfe: Move common code into vfe core
2024-08-12 14:41 ` [PATCH 09/13] media: qcom: camss: vfe: Move common code into vfe core Depeng Shao
@ 2024-08-15 0:09 ` Bryan O'Donoghue
2024-08-16 13:07 ` Depeng Shao
2024-08-24 13:06 ` Vladimir Zapolskiy
0 siblings, 2 replies; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-15 0:09 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel
On 12/08/2024 15:41, Depeng Shao wrote:
> Some v4l2 buffer related logic functions can be moved to vfe core as
> common code, then the vfe driver of different hw version can reuse them,
> this also can avoid adding duplicate code for new version supporting.
>
> Suggested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> ---
> .../media/platform/qcom/camss/camss-vfe-17x.c | 112 +-------
> .../media/platform/qcom/camss/camss-vfe-4-1.c | 9 -
> .../media/platform/qcom/camss/camss-vfe-4-7.c | 11 -
> .../media/platform/qcom/camss/camss-vfe-4-8.c | 11 -
> .../media/platform/qcom/camss/camss-vfe-480.c | 258 +----------------
> drivers/media/platform/qcom/camss/camss-vfe.c | 264 ++++++++++++++++++
> drivers/media/platform/qcom/camss/camss-vfe.h | 58 +++-
> 7 files changed, 340 insertions(+), 383 deletions(-)
>
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-17x.c b/drivers/media/platform/qcom/camss/camss-vfe-17x.c
> index 380c99321030..e5ee7e717b3b 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe-17x.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe-17x.c
> @@ -14,8 +14,6 @@
> #include "camss.h"
> #include "camss-vfe.h"
>
> -#define VFE_HW_VERSION (0x000)
> -
> #define VFE_GLOBAL_RESET_CMD (0x018)
> #define GLOBAL_RESET_CMD_CORE BIT(0)
> #define GLOBAL_RESET_CMD_CAMIF BIT(1)
> @@ -176,20 +174,6 @@
> #define VFE_BUS_WM_FRAME_INC(n) (0x2258 + (n) * 0x100)
> #define VFE_BUS_WM_BURST_LIMIT(n) (0x225c + (n) * 0x100)
>
> -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_dbg(vfe->camss->dev, "VFE HW Version = %u.%u.%u\n",
> - gen, rev, step);
> -
> - return hw_version;
> -}
> -
> static inline void vfe_reg_set(struct vfe_device *vfe, u32 reg, u32 set_bits)
> {
> u32 bits = readl_relaxed(vfe->base + reg);
> @@ -438,62 +422,6 @@ static int vfe_get_output(struct vfe_line *line)
> return -EINVAL;
> }
>
> -static int vfe_enable_output(struct vfe_line *line)
> -{
> - struct vfe_device *vfe = to_vfe(line);
> - struct vfe_output *output = &line->output;
> - const struct vfe_hw_ops *ops = vfe->res->hw_ops;
> - struct media_entity *sensor;
> - unsigned long flags;
> - unsigned int frame_skip = 0;
> - unsigned int i;
> -
> - sensor = camss_find_sensor(&line->subdev.entity);
> - if (sensor) {
> - struct v4l2_subdev *subdev = media_entity_to_v4l2_subdev(sensor);
> -
> - v4l2_subdev_call(subdev, sensor, g_skip_frames, &frame_skip);
> - /* Max frame skip is 29 frames */
> - if (frame_skip > VFE_FRAME_DROP_VAL - 1)
> - frame_skip = VFE_FRAME_DROP_VAL - 1;
> - }
> -
> - spin_lock_irqsave(&vfe->output_lock, flags);
> -
> - ops->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;
> - output->wait_reg_update = 0;
> - reinit_completion(&output->reg_update);
> -
> - vfe_wm_start(vfe, output->wm_idx[0], line);
> -
> - for (i = 0; i < 2; 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);
> - }
> -
> - ops->reg_update(vfe, line->id);
> -
> - spin_unlock_irqrestore(&vfe->output_lock, flags);
> -
> - return 0;
> -}
> -
> /*
> * vfe_enable - Enable streaming on VFE line
> * @line: VFE line
> @@ -518,7 +446,7 @@ static int vfe_enable(struct vfe_line *line)
> if (ret < 0)
> goto error_get_output;
>
> - ret = vfe_enable_output(line);
> + ret = vfe_enable_output_v2(line);
> if (ret < 0)
> goto error_enable_output;
>
> @@ -627,40 +555,6 @@ static void vfe_isr_wm_done(struct vfe_device *vfe, u8 wm)
> 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 < 2) {
> - output->buf[output->gen2.active_num++] = buf;
> - vfe_wm_update(vfe, output->wm_idx[0], buf->addr[0], line);
> - } else {
> - vfe_buf_add_pending(output, buf);
> - }
> -
> - spin_unlock_irqrestore(&vfe->output_lock, flags);
> -
> - return 0;
> -}
> -
> static const struct vfe_isr_ops vfe_isr_ops_170 = {
> .reset_ack = vfe_isr_reset_ack,
> .halt_ack = vfe_isr_halt_ack,
> @@ -671,7 +565,7 @@ static const struct vfe_isr_ops vfe_isr_ops_170 = {
> };
>
> static const struct camss_video_ops vfe_video_ops_170 = {
> - .queue_buffer = vfe_queue_buffer,
> + .queue_buffer = vfe_queue_buffer_v2,
> .flush_buffers = vfe_flush_buffers,
> };
>
> @@ -695,5 +589,7 @@ const struct vfe_hw_ops vfe_ops_170 = {
> .vfe_enable = vfe_enable,
> .vfe_halt = vfe_halt,
> .violation_read = vfe_violation_read,
> + .vfe_wm_start = vfe_wm_start,
> .vfe_wm_stop = vfe_wm_stop,
> + .vfe_wm_update = vfe_wm_update,
> };
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
> index 1bd3a6ef1d04..6930799f77c2 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
> @@ -210,15 +210,6 @@
> #define MSM_VFE_VFE0_UB_SIZE 1023
> #define MSM_VFE_VFE0_UB_SIZE_RDI (MSM_VFE_VFE0_UB_SIZE / 3)
>
> -static u32 vfe_hw_version(struct vfe_device *vfe)
> -{
> - u32 hw_version = readl_relaxed(vfe->base + VFE_0_HW_VERSION);
> -
> - dev_dbg(vfe->camss->dev, "VFE HW Version = 0x%08x\n", hw_version);
> -
> - return hw_version;
> -}
> -
> static u16 vfe_get_ub_size(u8 vfe_id)
> {
> if (vfe_id == 0)
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
> index ce0719106bd3..76729607db02 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
> @@ -18,8 +18,6 @@
> #include "camss-vfe-gen1.h"
>
>
> -#define VFE_0_HW_VERSION 0x000
> -
> #define VFE_0_GLOBAL_RESET_CMD 0x018
> #define VFE_0_GLOBAL_RESET_CMD_CORE BIT(0)
> #define VFE_0_GLOBAL_RESET_CMD_CAMIF BIT(1)
> @@ -254,15 +252,6 @@
> #define MSM_VFE_VFE1_UB_SIZE 1535
> #define MSM_VFE_VFE1_UB_SIZE_RDI (MSM_VFE_VFE1_UB_SIZE / 3)
>
> -static u32 vfe_hw_version(struct vfe_device *vfe)
> -{
> - u32 hw_version = readl_relaxed(vfe->base + VFE_0_HW_VERSION);
> -
> - dev_dbg(vfe->camss->dev, "VFE HW Version = 0x%08x\n", hw_version);
> -
> - return hw_version;
> -}
> -
> static u16 vfe_get_ub_size(u8 vfe_id)
> {
> if (vfe_id == 0)
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-8.c b/drivers/media/platform/qcom/camss/camss-vfe-4-8.c
> index 6b59c8107a3c..b2f7d855d8dd 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe-4-8.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe-4-8.c
> @@ -17,8 +17,6 @@
> #include "camss-vfe.h"
> #include "camss-vfe-gen1.h"
>
> -#define VFE_0_HW_VERSION 0x000
> -
> #define VFE_0_GLOBAL_RESET_CMD 0x018
> #define VFE_0_GLOBAL_RESET_CMD_CORE BIT(0)
> #define VFE_0_GLOBAL_RESET_CMD_CAMIF BIT(1)
> @@ -247,15 +245,6 @@
> #define MSM_VFE_VFE1_UB_SIZE 1535
> #define MSM_VFE_VFE1_UB_SIZE_RDI (MSM_VFE_VFE1_UB_SIZE / 3)
>
> -static u32 vfe_hw_version(struct vfe_device *vfe)
> -{
> - u32 hw_version = readl_relaxed(vfe->base + VFE_0_HW_VERSION);
> -
> - dev_dbg(vfe->camss->dev, "VFE HW Version = 0x%08x\n", hw_version);
> -
> - return hw_version;
> -}
> -
> static inline void vfe_reg_clr(struct vfe_device *vfe, u32 reg, u32 clr_bits)
> {
> u32 bits = readl_relaxed(vfe->base + reg);
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-480.c b/drivers/media/platform/qcom/camss/camss-vfe-480.c
> index dc2735476c82..e6d3b27de323 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe-480.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe-480.c
> @@ -15,8 +15,6 @@
> #include "camss.h"
> #include "camss-vfe.h"
>
> -#define VFE_HW_VERSION (0x00)
> -
> #define VFE_GLOBAL_RESET_CMD (vfe_is_lite(vfe) ? 0x0c : 0x1c)
> #define GLOBAL_RESET_HW_AND_REG (vfe_is_lite(vfe) ? BIT(1) : BIT(0))
>
> @@ -92,19 +90,6 @@ static inline int bus_irq_mask_0_comp_done(struct vfe_device *vfe, int n)
>
> #define MAX_VFE_OUTPUT_LINES 4
>
> -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_dbg(vfe->camss->dev, "VFE HW Version = %u.%u.%u\n", gen, rev, step);
> -
> - return hw_version;
> -}
> -
> static void vfe_global_reset(struct vfe_device *vfe)
> {
> writel_relaxed(IRQ_MASK_0_RESET_ACK, vfe->base + VFE_IRQ_MASK(0));
> @@ -167,18 +152,16 @@ static inline void vfe_reg_update_clear(struct vfe_device *vfe,
> vfe->reg_update &= ~REG_UPDATE_RDI(vfe, line_id);
> }
>
> -static void vfe_enable_irq_common(struct vfe_device *vfe)
> -{
> - /* enable reset ack IRQ and top BUS status IRQ */
> - writel_relaxed(IRQ_MASK_0_RESET_ACK | IRQ_MASK_0_BUS_TOP_IRQ,
> - vfe->base + VFE_IRQ_MASK(0));
> -}
> -
> -static void vfe_enable_lines_irq(struct vfe_device *vfe)
> +static void vfe_enable_irq(struct vfe_device *vfe)
> {
> int i;
> u32 bus_irq_mask = 0;
>
> + if (!vfe->stream_count)
> + /* enable reset ack IRQ and top BUS status IRQ */
> + writel(IRQ_MASK_0_RESET_ACK | IRQ_MASK_0_BUS_TOP_IRQ,
> + vfe->base + VFE_IRQ_MASK(0));
> +
> for (i = 0; i < MAX_VFE_OUTPUT_LINES; i++) {
> /* Enable IRQ for newly added lines, but also keep already running lines's IRQ */
> if (vfe->line[i].output.state == VFE_OUTPUT_RESERVED ||
> @@ -188,11 +171,10 @@ static void vfe_enable_lines_irq(struct vfe_device *vfe)
> }
> }
>
> - writel_relaxed(bus_irq_mask, vfe->base + VFE_BUS_IRQ_MASK(0));
> + writel(bus_irq_mask, vfe->base + VFE_BUS_IRQ_MASK(0));
> }
>
> static void vfe_isr_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id);
> -static void vfe_isr_wm_done(struct vfe_device *vfe, u8 wm);
>
> /*
> * vfe_isr - VFE module interrupt handler
> @@ -226,7 +208,7 @@ static irqreturn_t vfe_isr(int irq, void *dev)
> vfe_isr_reg_update(vfe, i);
>
> if (status & BUS_IRQ_MASK_0_COMP_DONE(vfe, RDI_COMP_GROUP(i)))
> - vfe_isr_wm_done(vfe, i);
> + vfe_buf_done(vfe, i);
> }
> }
>
> @@ -245,132 +227,6 @@ static int vfe_halt(struct vfe_device *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;
> - output->wait_reg_update = 0;
> - reinit_completion(&output->reg_update);
> -
> - vfe_wm_start(vfe, output->wm_idx[0], line);
> -
> - for (i = 0; i < 2; 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);
> -
> - if (!vfe->stream_count)
> - vfe_enable_irq_common(vfe);
> -
> - vfe->stream_count++;
> -
> - vfe_enable_lines_irq(vfe);
> -
> - 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_isr_reg_update - Process reg update interrupt
> * @vfe: VFE Device
> @@ -394,97 +250,8 @@ static void vfe_isr_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id)
> spin_unlock_irqrestore(&vfe->output_lock, flags);
> }
>
> -/*
> - * vfe_isr_wm_done - Process write master done interrupt
> - * @vfe: VFE Device
> - * @wm: Write master id
> - */
> -static void vfe_isr_wm_done(struct vfe_device *vfe, u8 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);
> - 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 < 2) {
> - output->buf[output->gen2.active_num++] = buf;
> - vfe_wm_update(vfe, output->wm_idx[0], buf->addr[0], line);
> - } 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_480 = {
> - .queue_buffer = vfe_queue_buffer,
> + .queue_buffer = vfe_queue_buffer_v2,
> .flush_buffers = vfe_flush_buffers,
> };
>
> @@ -494,6 +261,7 @@ static void vfe_subdev_init(struct device *dev, struct vfe_device *vfe)
> }
>
> const struct vfe_hw_ops vfe_ops_480 = {
> + .enable_irq = vfe_enable_irq,
> .global_reset = vfe_global_reset,
> .hw_version = vfe_hw_version,
> .isr = vfe_isr,
> @@ -501,7 +269,11 @@ const struct vfe_hw_ops vfe_ops_480 = {
> .pm_domain_on = vfe_pm_domain_on,
> .subdev_init = vfe_subdev_init,
> .vfe_disable = vfe_disable,
> - .vfe_enable = vfe_enable,
> + .vfe_enable = vfe_enable_v2,
> .vfe_halt = vfe_halt,
> + .vfe_wm_start = vfe_wm_start,
> .vfe_wm_stop = vfe_wm_stop,
> + .vfe_wm_update = vfe_wm_update,
> + .reg_update = vfe_reg_update,
> + .reg_update_clear = vfe_reg_update_clear,
> };
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
> index 83c5a36d071f..f6650694f47e 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
> @@ -32,6 +32,11 @@
>
> #define SCALER_RATIO_MAX 16
>
> +#define VFE_HW_VERSION 0x0
> +#define HW_VERSION_STEPPING 0
> +#define HW_VERSION_REVISION 16
> +#define HW_VERSION_GENERATION 28
> +
> static const struct camss_format_info formats_rdi_8x16[] = {
> { MEDIA_BUS_FMT_UYVY8_1X16, 8, V4L2_PIX_FMT_UYVY, 1,
> PER_PLANE_DATA(0, 1, 1, 1, 1, 16) },
> @@ -402,6 +407,265 @@ static u32 vfe_src_pad_code(struct vfe_line *line, u32 sink_code,
> return 0;
> }
>
> +/*
> + * vfe_hw_version - Process write master done interrupt
> + * @vfe: VFE Device
> + *
> + * Return vfe hw version
> + */
> +u32 vfe_hw_version(struct vfe_device *vfe)
> +{
> + u32 hw_version = readl_relaxed(vfe->base + VFE_HW_VERSION);
> +
> + u32 gen = (hw_version >> HW_VERSION_GENERATION) & 0xF;
> + u32 rev = (hw_version >> HW_VERSION_REVISION) & 0xFFF;
> + u32 step = (hw_version >> HW_VERSION_STEPPING) & 0xFFFF;
> +
> + dev_info(vfe->camss->dev, "VFE:%d HW Version = %u.%u.%u\n",
> + vfe->id, gen, rev, step);
> +
> + return hw_version;
> +}
> +
> +/*
> + * vfe_buf_done - Process write master done interrupt
> + * @vfe: VFE Device
> + * @wm: Write master id
> + */
> +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->res->hw_ops->vfe_wm_update(vfe, output->wm_idx[0],
> + output->buf[index]->addr[0],
> + line);
> + vfe->res->hw_ops->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);
> +}
> +
> +int vfe_enable_output_v2(struct vfe_line *line)
> +{
> + struct vfe_device *vfe = to_vfe(line);
> + struct vfe_output *output = &line->output;
> + const struct vfe_hw_ops *ops = vfe->res->hw_ops;
> + struct media_entity *sensor;
> + unsigned long flags;
> + unsigned int frame_skip = 0;
> + unsigned int i;
> +
> + sensor = camss_find_sensor(&line->subdev.entity);
> + if (sensor) {
> + struct v4l2_subdev *subdev = media_entity_to_v4l2_subdev(sensor);
> +
> + v4l2_subdev_call(subdev, sensor, g_skip_frames, &frame_skip);
> + /* Max frame skip is 29 frames */
> + if (frame_skip > VFE_FRAME_DROP_VAL - 1)
> + frame_skip = VFE_FRAME_DROP_VAL - 1;
> + }
> +
> + spin_lock_irqsave(&vfe->output_lock, flags);
> +
> + ops->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;
> + output->wait_reg_update = 0;
> + reinit_completion(&output->reg_update);
> +
> + ops->vfe_wm_start(vfe, output->wm_idx[0], line);
> +
> + for (i = 0; i < 2; i++) {
> + output->buf[i] = vfe_buf_get_pending(output);
> + if (!output->buf[i])
> + break;
> + output->gen2.active_num++;
> + ops->vfe_wm_update(vfe, output->wm_idx[0],
> + output->buf[i]->addr[0], line);
> + ops->reg_update(vfe, line->id);
> + }
> +
> + spin_unlock_irqrestore(&vfe->output_lock, flags);
> +
> + return 0;
> +}
> +
> +/*
> + * vfe_queue_buffer_v2 - 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
> + */
> +int vfe_queue_buffer_v2(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 < 2) {
> + output->buf[output->gen2.active_num++] = buf;
> + vfe->res->hw_ops->vfe_wm_update(vfe, output->wm_idx[0],
> + buf->addr[0], line);
> + vfe->res->hw_ops->reg_update(vfe, line->id);
> + } else {
> + vfe_buf_add_pending(output, buf);
> + }
> +
> + spin_unlock_irqrestore(&vfe->output_lock, flags);
> +
> + return 0;
> +}
> +
> +/*
> + * vfe_enable_v2 - Enable streaming on VFE line
> + * @line: VFE line
> + *
> + * Return 0 on success or a negative error code otherwise
> + */
> +int vfe_enable_v2(struct vfe_line *line)
> +{
> + struct vfe_device *vfe = to_vfe(line);
> + int ret;
> +
> + mutex_lock(&vfe->stream_lock);
> +
> + if (vfe->res->hw_ops->enable_irq)
> + vfe->res->hw_ops->enable_irq(vfe);
Right so generally speaking I don't believe we should have any null
function pointers.
We just mandate that to be comitted, an impelmentation must provide a
dummy but, in this case when do we ever want a dummy function anyway
surely enable_irq() is a fundamental operation that is core to the logic.
Also a style nit-pick if you get a hw_ops pointer you don't have to jump
through so -> many -> indirection -> hoops.
Code will look neater that way.
I'll go through the vfe_enable() stuff in more detail on your next drop.
Please ensure again with the hw_version() that you have equivalent logic
before and after => no behaviour change similarly with vfe_enable() and
friends.
The objective is to remove code duplication, not to change logical
behaviors at all, no matter how seemingly trival that change might be ->
hw_version 0xsomenumber instea of 0xX, 0xY 0xZ
It probably sounds dogmatic but, its safer that way.
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 09/13] media: qcom: camss: vfe: Move common code into vfe core
2024-08-15 0:09 ` Bryan O'Donoghue
@ 2024-08-16 13:07 ` Depeng Shao
2024-08-24 13:06 ` Vladimir Zapolskiy
1 sibling, 0 replies; 107+ messages in thread
From: Depeng Shao @ 2024-08-16 13:07 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel
Hi Bryan,
On 8/15/2024 8:09 AM, Bryan O'Donoghue wrote:
>> +
>> +/*
>> + * vfe_enable_v2 - Enable streaming on VFE line
>> + * @line: VFE line
>> + *
>> + * Return 0 on success or a negative error code otherwise
>> + */
>> +int vfe_enable_v2(struct vfe_line *line)
>> +{
>> + struct vfe_device *vfe = to_vfe(line);
>> + int ret;
>> +
>> + mutex_lock(&vfe->stream_lock);
>> +
>> + if (vfe->res->hw_ops->enable_irq)
>> + vfe->res->hw_ops->enable_irq(vfe);
>
> Right so generally speaking I don't believe we should have any null
> function pointers.
>
> We just mandate that to be comitted, an impelmentation must provide a
> dummy but, in this case when do we ever want a dummy function anyway
> surely enable_irq() is a fundamental operation that is core to the logic.
>
> Also a style nit-pick if you get a hw_ops pointer you don't have to jump
> through so -> many -> indirection -> hoops.
>
Ok, I will declare the hw_ops first.
> Code will look neater that way.
>
> I'll go through the vfe_enable() stuff in more detail on your next drop.
>
> Please ensure again with the hw_version() that you have equivalent logic
> before and after => no behaviour change similarly with vfe_enable() and
> friends.
>
> The objective is to remove code duplication, not to change logical
> behaviors at all, no matter how seemingly trival that change might be ->
> hw_version 0xsomenumber instea of 0xX, 0xY 0xZ
>
> It probably sounds dogmatic but, its safer that way.
>
Sure, I won't change the original code.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 09/13] media: qcom: camss: vfe: Move common code into vfe core
2024-08-15 0:09 ` Bryan O'Donoghue
2024-08-16 13:07 ` Depeng Shao
@ 2024-08-24 13:06 ` Vladimir Zapolskiy
2024-08-28 0:07 ` Bryan O'Donoghue
2024-09-02 13:11 ` Depeng Shao
1 sibling, 2 replies; 107+ messages in thread
From: Vladimir Zapolskiy @ 2024-08-24 13:06 UTC (permalink / raw)
To: Bryan O'Donoghue, Depeng Shao, rfoss, todor.too, mchehab,
robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel
Hi Bryan,
On 8/15/24 03:09, Bryan O'Donoghue wrote:
> On 12/08/2024 15:41, Depeng Shao wrote:
>> Some v4l2 buffer related logic functions can be moved to vfe core as
>> common code, then the vfe driver of different hw version can reuse them,
>> this also can avoid adding duplicate code for new version supporting.
>>
>> Suggested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
>> ---
>> .../media/platform/qcom/camss/camss-vfe-17x.c | 112 +-------
>> .../media/platform/qcom/camss/camss-vfe-4-1.c | 9 -
>> .../media/platform/qcom/camss/camss-vfe-4-7.c | 11 -
>> .../media/platform/qcom/camss/camss-vfe-4-8.c | 11 -
>> .../media/platform/qcom/camss/camss-vfe-480.c | 258 +----------------
>> drivers/media/platform/qcom/camss/camss-vfe.c | 264 ++++++++++++++++++
>> drivers/media/platform/qcom/camss/camss-vfe.h | 58 +++-
>> 7 files changed, 340 insertions(+), 383 deletions(-)
>>
>> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-17x.c b/drivers/media/platform/qcom/camss/camss-vfe-17x.c
>> index 380c99321030..e5ee7e717b3b 100644
>> --- a/drivers/media/platform/qcom/camss/camss-vfe-17x.c
>> +++ b/drivers/media/platform/qcom/camss/camss-vfe-17x.c
>> @@ -14,8 +14,6 @@
>> #include "camss.h"
>> #include "camss-vfe.h"
>>
>> -#define VFE_HW_VERSION (0x000)
>> -
>> #define VFE_GLOBAL_RESET_CMD (0x018)
>> #define GLOBAL_RESET_CMD_CORE BIT(0)
>> #define GLOBAL_RESET_CMD_CAMIF BIT(1)
>> @@ -176,20 +174,6 @@
>> #define VFE_BUS_WM_FRAME_INC(n) (0x2258 + (n) * 0x100)
>> #define VFE_BUS_WM_BURST_LIMIT(n) (0x225c + (n) * 0x100)
>>
>> -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_dbg(vfe->camss->dev, "VFE HW Version = %u.%u.%u\n",
>> - gen, rev, step);
>> -
>> - return hw_version;
>> -}
>> -
>> static inline void vfe_reg_set(struct vfe_device *vfe, u32 reg, u32 set_bits)
>> {
>> u32 bits = readl_relaxed(vfe->base + reg);
>> @@ -438,62 +422,6 @@ static int vfe_get_output(struct vfe_line *line)
>> return -EINVAL;
>> }
>>
>> -static int vfe_enable_output(struct vfe_line *line)
>> -{
>> - struct vfe_device *vfe = to_vfe(line);
>> - struct vfe_output *output = &line->output;
>> - const struct vfe_hw_ops *ops = vfe->res->hw_ops;
>> - struct media_entity *sensor;
>> - unsigned long flags;
>> - unsigned int frame_skip = 0;
>> - unsigned int i;
>> -
>> - sensor = camss_find_sensor(&line->subdev.entity);
>> - if (sensor) {
>> - struct v4l2_subdev *subdev = media_entity_to_v4l2_subdev(sensor);
>> -
>> - v4l2_subdev_call(subdev, sensor, g_skip_frames, &frame_skip);
>> - /* Max frame skip is 29 frames */
>> - if (frame_skip > VFE_FRAME_DROP_VAL - 1)
>> - frame_skip = VFE_FRAME_DROP_VAL - 1;
>> - }
>> -
>> - spin_lock_irqsave(&vfe->output_lock, flags);
>> -
>> - ops->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;
>> - output->wait_reg_update = 0;
>> - reinit_completion(&output->reg_update);
>> -
>> - vfe_wm_start(vfe, output->wm_idx[0], line);
>> -
>> - for (i = 0; i < 2; 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);
>> - }
>> -
>> - ops->reg_update(vfe, line->id);
>> -
>> - spin_unlock_irqrestore(&vfe->output_lock, flags);
>> -
>> - return 0;
>> -}
>> -
>> /*
>> * vfe_enable - Enable streaming on VFE line
>> * @line: VFE line
>> @@ -518,7 +446,7 @@ static int vfe_enable(struct vfe_line *line)
>> if (ret < 0)
>> goto error_get_output;
>>
>> - ret = vfe_enable_output(line);
>> + ret = vfe_enable_output_v2(line);
>> if (ret < 0)
>> goto error_enable_output;
>>
>> @@ -627,40 +555,6 @@ static void vfe_isr_wm_done(struct vfe_device *vfe, u8 wm)
>> 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 < 2) {
>> - output->buf[output->gen2.active_num++] = buf;
>> - vfe_wm_update(vfe, output->wm_idx[0], buf->addr[0], line);
>> - } else {
>> - vfe_buf_add_pending(output, buf);
>> - }
>> -
>> - spin_unlock_irqrestore(&vfe->output_lock, flags);
>> -
>> - return 0;
>> -}
>> -
>> static const struct vfe_isr_ops vfe_isr_ops_170 = {
>> .reset_ack = vfe_isr_reset_ack,
>> .halt_ack = vfe_isr_halt_ack,
>> @@ -671,7 +565,7 @@ static const struct vfe_isr_ops vfe_isr_ops_170 = {
>> };
>>
>> static const struct camss_video_ops vfe_video_ops_170 = {
>> - .queue_buffer = vfe_queue_buffer,
>> + .queue_buffer = vfe_queue_buffer_v2,
>> .flush_buffers = vfe_flush_buffers,
>> };
>>
>> @@ -695,5 +589,7 @@ const struct vfe_hw_ops vfe_ops_170 = {
>> .vfe_enable = vfe_enable,
>> .vfe_halt = vfe_halt,
>> .violation_read = vfe_violation_read,
>> + .vfe_wm_start = vfe_wm_start,
>> .vfe_wm_stop = vfe_wm_stop,
>> + .vfe_wm_update = vfe_wm_update,
>> };
>> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
>> index 1bd3a6ef1d04..6930799f77c2 100644
>> --- a/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
>> +++ b/drivers/media/platform/qcom/camss/camss-vfe-4-1.c
>> @@ -210,15 +210,6 @@
>> #define MSM_VFE_VFE0_UB_SIZE 1023
>> #define MSM_VFE_VFE0_UB_SIZE_RDI (MSM_VFE_VFE0_UB_SIZE / 3)
>>
>> -static u32 vfe_hw_version(struct vfe_device *vfe)
>> -{
>> - u32 hw_version = readl_relaxed(vfe->base + VFE_0_HW_VERSION);
>> -
>> - dev_dbg(vfe->camss->dev, "VFE HW Version = 0x%08x\n", hw_version);
>> -
>> - return hw_version;
>> -}
>> -
>> static u16 vfe_get_ub_size(u8 vfe_id)
>> {
>> if (vfe_id == 0)
>> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
>> index ce0719106bd3..76729607db02 100644
>> --- a/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
>> +++ b/drivers/media/platform/qcom/camss/camss-vfe-4-7.c
>> @@ -18,8 +18,6 @@
>> #include "camss-vfe-gen1.h"
>>
>>
>> -#define VFE_0_HW_VERSION 0x000
>> -
>> #define VFE_0_GLOBAL_RESET_CMD 0x018
>> #define VFE_0_GLOBAL_RESET_CMD_CORE BIT(0)
>> #define VFE_0_GLOBAL_RESET_CMD_CAMIF BIT(1)
>> @@ -254,15 +252,6 @@
>> #define MSM_VFE_VFE1_UB_SIZE 1535
>> #define MSM_VFE_VFE1_UB_SIZE_RDI (MSM_VFE_VFE1_UB_SIZE / 3)
>>
>> -static u32 vfe_hw_version(struct vfe_device *vfe)
>> -{
>> - u32 hw_version = readl_relaxed(vfe->base + VFE_0_HW_VERSION);
>> -
>> - dev_dbg(vfe->camss->dev, "VFE HW Version = 0x%08x\n", hw_version);
>> -
>> - return hw_version;
>> -}
>> -
>> static u16 vfe_get_ub_size(u8 vfe_id)
>> {
>> if (vfe_id == 0)
>> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-4-8.c b/drivers/media/platform/qcom/camss/camss-vfe-4-8.c
>> index 6b59c8107a3c..b2f7d855d8dd 100644
>> --- a/drivers/media/platform/qcom/camss/camss-vfe-4-8.c
>> +++ b/drivers/media/platform/qcom/camss/camss-vfe-4-8.c
>> @@ -17,8 +17,6 @@
>> #include "camss-vfe.h"
>> #include "camss-vfe-gen1.h"
>>
>> -#define VFE_0_HW_VERSION 0x000
>> -
>> #define VFE_0_GLOBAL_RESET_CMD 0x018
>> #define VFE_0_GLOBAL_RESET_CMD_CORE BIT(0)
>> #define VFE_0_GLOBAL_RESET_CMD_CAMIF BIT(1)
>> @@ -247,15 +245,6 @@
>> #define MSM_VFE_VFE1_UB_SIZE 1535
>> #define MSM_VFE_VFE1_UB_SIZE_RDI (MSM_VFE_VFE1_UB_SIZE / 3)
>>
>> -static u32 vfe_hw_version(struct vfe_device *vfe)
>> -{
>> - u32 hw_version = readl_relaxed(vfe->base + VFE_0_HW_VERSION);
>> -
>> - dev_dbg(vfe->camss->dev, "VFE HW Version = 0x%08x\n", hw_version);
>> -
>> - return hw_version;
>> -}
>> -
>> static inline void vfe_reg_clr(struct vfe_device *vfe, u32 reg, u32 clr_bits)
>> {
>> u32 bits = readl_relaxed(vfe->base + reg);
>> diff --git a/drivers/media/platform/qcom/camss/camss-vfe-480.c b/drivers/media/platform/qcom/camss/camss-vfe-480.c
>> index dc2735476c82..e6d3b27de323 100644
>> --- a/drivers/media/platform/qcom/camss/camss-vfe-480.c
>> +++ b/drivers/media/platform/qcom/camss/camss-vfe-480.c
>> @@ -15,8 +15,6 @@
>> #include "camss.h"
>> #include "camss-vfe.h"
>>
>> -#define VFE_HW_VERSION (0x00)
>> -
>> #define VFE_GLOBAL_RESET_CMD (vfe_is_lite(vfe) ? 0x0c : 0x1c)
>> #define GLOBAL_RESET_HW_AND_REG (vfe_is_lite(vfe) ? BIT(1) : BIT(0))
>>
>> @@ -92,19 +90,6 @@ static inline int bus_irq_mask_0_comp_done(struct vfe_device *vfe, int n)
>>
>> #define MAX_VFE_OUTPUT_LINES 4
>>
>> -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_dbg(vfe->camss->dev, "VFE HW Version = %u.%u.%u\n", gen, rev, step);
>> -
>> - return hw_version;
>> -}
>> -
>> static void vfe_global_reset(struct vfe_device *vfe)
>> {
>> writel_relaxed(IRQ_MASK_0_RESET_ACK, vfe->base + VFE_IRQ_MASK(0));
>> @@ -167,18 +152,16 @@ static inline void vfe_reg_update_clear(struct vfe_device *vfe,
>> vfe->reg_update &= ~REG_UPDATE_RDI(vfe, line_id);
>> }
>>
>> -static void vfe_enable_irq_common(struct vfe_device *vfe)
>> -{
>> - /* enable reset ack IRQ and top BUS status IRQ */
>> - writel_relaxed(IRQ_MASK_0_RESET_ACK | IRQ_MASK_0_BUS_TOP_IRQ,
>> - vfe->base + VFE_IRQ_MASK(0));
>> -}
>> -
>> -static void vfe_enable_lines_irq(struct vfe_device *vfe)
>> +static void vfe_enable_irq(struct vfe_device *vfe)
>> {
>> int i;
>> u32 bus_irq_mask = 0;
>>
>> + if (!vfe->stream_count)
>> + /* enable reset ack IRQ and top BUS status IRQ */
>> + writel(IRQ_MASK_0_RESET_ACK | IRQ_MASK_0_BUS_TOP_IRQ,
>> + vfe->base + VFE_IRQ_MASK(0));
>> +
>> for (i = 0; i < MAX_VFE_OUTPUT_LINES; i++) {
>> /* Enable IRQ for newly added lines, but also keep already running lines's IRQ */
>> if (vfe->line[i].output.state == VFE_OUTPUT_RESERVED ||
>> @@ -188,11 +171,10 @@ static void vfe_enable_lines_irq(struct vfe_device *vfe)
>> }
>> }
>>
>> - writel_relaxed(bus_irq_mask, vfe->base + VFE_BUS_IRQ_MASK(0));
>> + writel(bus_irq_mask, vfe->base + VFE_BUS_IRQ_MASK(0));
>> }
>>
>> static void vfe_isr_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id);
>> -static void vfe_isr_wm_done(struct vfe_device *vfe, u8 wm);
>>
>> /*
>> * vfe_isr - VFE module interrupt handler
>> @@ -226,7 +208,7 @@ static irqreturn_t vfe_isr(int irq, void *dev)
>> vfe_isr_reg_update(vfe, i);
>>
>> if (status & BUS_IRQ_MASK_0_COMP_DONE(vfe, RDI_COMP_GROUP(i)))
>> - vfe_isr_wm_done(vfe, i);
>> + vfe_buf_done(vfe, i);
>> }
>> }
>>
>> @@ -245,132 +227,6 @@ static int vfe_halt(struct vfe_device *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;
>> - output->wait_reg_update = 0;
>> - reinit_completion(&output->reg_update);
>> -
>> - vfe_wm_start(vfe, output->wm_idx[0], line);
>> -
>> - for (i = 0; i < 2; 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);
>> -
>> - if (!vfe->stream_count)
>> - vfe_enable_irq_common(vfe);
>> -
>> - vfe->stream_count++;
>> -
>> - vfe_enable_lines_irq(vfe);
>> -
>> - 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_isr_reg_update - Process reg update interrupt
>> * @vfe: VFE Device
>> @@ -394,97 +250,8 @@ static void vfe_isr_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id)
>> spin_unlock_irqrestore(&vfe->output_lock, flags);
>> }
>>
>> -/*
>> - * vfe_isr_wm_done - Process write master done interrupt
>> - * @vfe: VFE Device
>> - * @wm: Write master id
>> - */
>> -static void vfe_isr_wm_done(struct vfe_device *vfe, u8 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);
>> - 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 < 2) {
>> - output->buf[output->gen2.active_num++] = buf;
>> - vfe_wm_update(vfe, output->wm_idx[0], buf->addr[0], line);
>> - } 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_480 = {
>> - .queue_buffer = vfe_queue_buffer,
>> + .queue_buffer = vfe_queue_buffer_v2,
>> .flush_buffers = vfe_flush_buffers,
>> };
>>
>> @@ -494,6 +261,7 @@ static void vfe_subdev_init(struct device *dev, struct vfe_device *vfe)
>> }
>>
>> const struct vfe_hw_ops vfe_ops_480 = {
>> + .enable_irq = vfe_enable_irq,
>> .global_reset = vfe_global_reset,
>> .hw_version = vfe_hw_version,
>> .isr = vfe_isr,
>> @@ -501,7 +269,11 @@ const struct vfe_hw_ops vfe_ops_480 = {
>> .pm_domain_on = vfe_pm_domain_on,
>> .subdev_init = vfe_subdev_init,
>> .vfe_disable = vfe_disable,
>> - .vfe_enable = vfe_enable,
>> + .vfe_enable = vfe_enable_v2,
>> .vfe_halt = vfe_halt,
>> + .vfe_wm_start = vfe_wm_start,
>> .vfe_wm_stop = vfe_wm_stop,
>> + .vfe_wm_update = vfe_wm_update,
>> + .reg_update = vfe_reg_update,
>> + .reg_update_clear = vfe_reg_update_clear,
>> };
>> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
>> index 83c5a36d071f..f6650694f47e 100644
>> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
>> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
>> @@ -32,6 +32,11 @@
>>
>> #define SCALER_RATIO_MAX 16
>>
>> +#define VFE_HW_VERSION 0x0
>> +#define HW_VERSION_STEPPING 0
>> +#define HW_VERSION_REVISION 16
>> +#define HW_VERSION_GENERATION 28
>> +
>> static const struct camss_format_info formats_rdi_8x16[] = {
>> { MEDIA_BUS_FMT_UYVY8_1X16, 8, V4L2_PIX_FMT_UYVY, 1,
>> PER_PLANE_DATA(0, 1, 1, 1, 1, 16) },
>> @@ -402,6 +407,265 @@ static u32 vfe_src_pad_code(struct vfe_line *line, u32 sink_code,
>> return 0;
>> }
>>
>> +/*
>> + * vfe_hw_version - Process write master done interrupt
>> + * @vfe: VFE Device
>> + *
>> + * Return vfe hw version
>> + */
>> +u32 vfe_hw_version(struct vfe_device *vfe)
>> +{
>> + u32 hw_version = readl_relaxed(vfe->base + VFE_HW_VERSION);
>> +
>> + u32 gen = (hw_version >> HW_VERSION_GENERATION) & 0xF;
>> + u32 rev = (hw_version >> HW_VERSION_REVISION) & 0xFFF;
>> + u32 step = (hw_version >> HW_VERSION_STEPPING) & 0xFFFF;
>> +
>> + dev_info(vfe->camss->dev, "VFE:%d HW Version = %u.%u.%u\n",
>> + vfe->id, gen, rev, step);
>> +
>> + return hw_version;
>> +}
>> +
>> +/*
>> + * vfe_buf_done - Process write master done interrupt
>> + * @vfe: VFE Device
>> + * @wm: Write master id
>> + */
>> +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->res->hw_ops->vfe_wm_update(vfe, output->wm_idx[0],
>> + output->buf[index]->addr[0],
>> + line);
>> + vfe->res->hw_ops->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);
>> +}
>> +
>> +int vfe_enable_output_v2(struct vfe_line *line)
>> +{
>> + struct vfe_device *vfe = to_vfe(line);
>> + struct vfe_output *output = &line->output;
>> + const struct vfe_hw_ops *ops = vfe->res->hw_ops;
>> + struct media_entity *sensor;
>> + unsigned long flags;
>> + unsigned int frame_skip = 0;
>> + unsigned int i;
>> +
>> + sensor = camss_find_sensor(&line->subdev.entity);
>> + if (sensor) {
>> + struct v4l2_subdev *subdev = media_entity_to_v4l2_subdev(sensor);
>> +
>> + v4l2_subdev_call(subdev, sensor, g_skip_frames, &frame_skip);
>> + /* Max frame skip is 29 frames */
>> + if (frame_skip > VFE_FRAME_DROP_VAL - 1)
>> + frame_skip = VFE_FRAME_DROP_VAL - 1;
>> + }
>> +
>> + spin_lock_irqsave(&vfe->output_lock, flags);
>> +
>> + ops->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;
>> + output->wait_reg_update = 0;
>> + reinit_completion(&output->reg_update);
>> +
>> + ops->vfe_wm_start(vfe, output->wm_idx[0], line);
>> +
>> + for (i = 0; i < 2; i++) {
>> + output->buf[i] = vfe_buf_get_pending(output);
>> + if (!output->buf[i])
>> + break;
>> + output->gen2.active_num++;
>> + ops->vfe_wm_update(vfe, output->wm_idx[0],
>> + output->buf[i]->addr[0], line);
>> + ops->reg_update(vfe, line->id);
>> + }
>> +
>> + spin_unlock_irqrestore(&vfe->output_lock, flags);
>> +
>> + return 0;
>> +}
>> +
>> +/*
>> + * vfe_queue_buffer_v2 - 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
>> + */
>> +int vfe_queue_buffer_v2(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 < 2) {
>> + output->buf[output->gen2.active_num++] = buf;
>> + vfe->res->hw_ops->vfe_wm_update(vfe, output->wm_idx[0],
>> + buf->addr[0], line);
>> + vfe->res->hw_ops->reg_update(vfe, line->id);
>> + } else {
>> + vfe_buf_add_pending(output, buf);
>> + }
>> +
>> + spin_unlock_irqrestore(&vfe->output_lock, flags);
>> +
>> + return 0;
>> +}
>> +
>> +/*
>> + * vfe_enable_v2 - Enable streaming on VFE line
>> + * @line: VFE line
>> + *
>> + * Return 0 on success or a negative error code otherwise
>> + */
>> +int vfe_enable_v2(struct vfe_line *line)
>> +{
>> + struct vfe_device *vfe = to_vfe(line);
>> + int ret;
>> +
>> + mutex_lock(&vfe->stream_lock);
>> +
>> + if (vfe->res->hw_ops->enable_irq)
>> + vfe->res->hw_ops->enable_irq(vfe);
>
> Right so generally speaking I don't believe we should have any null
> function pointers.
>
> We just mandate that to be comitted, an impelmentation must provide a
> dummy but, in this case when do we ever want a dummy function anyway
> surely enable_irq() is a fundamental operation that is core to the logic.
Why? What could be a justification here?
The image capturing media pipeline for all recent Qualcomm SoCs, including
this one in the series for SM8550, can be set up and enabled without
touching VFE interrupts at all.
It might be extremely confusing to see in the code that some not ever
requested interrupts are enabled/disabled, and then to discover that just
some stubs around VFE interrupts are added. And it's the case especially
in this new vfe_enable_v2() function, which I believe is intended for
CAMSS support on new platforms.
What's worse, since these VFE interrupts are not needed on the modern
platforms, it will require to add a proposed dummy "return 0" function
into any CAMSS support for new platforms forever. I believe it'd be better
to clearly say that it's a legacy to have an obligatory support of VFE
interrupts.
> Also a style nit-pick if you get a hw_ops pointer you don't have to jump
> through so -> many -> indirection -> hoops.
>
> Code will look neater that way.
>
> I'll go through the vfe_enable() stuff in more detail on your next drop.
>
> Please ensure again with the hw_version() that you have equivalent logic
> before and after => no behaviour change similarly with vfe_enable() and
> friends.
>
> The objective is to remove code duplication, not to change logical
> behaviors at all, no matter how seemingly trival that change might be ->
> hw_version 0xsomenumber instea of 0xX, 0xY 0xZ
>
> It probably sounds dogmatic but, its safer that way.
>
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 09/13] media: qcom: camss: vfe: Move common code into vfe core
2024-08-24 13:06 ` Vladimir Zapolskiy
@ 2024-08-28 0:07 ` Bryan O'Donoghue
2024-09-02 13:11 ` Depeng Shao
1 sibling, 0 replies; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-28 0:07 UTC (permalink / raw)
To: Vladimir Zapolskiy, Depeng Shao, rfoss, todor.too, mchehab, robh,
krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel
On 24/08/2024 14:06, Vladimir Zapolskiy wrote:
>> Right so generally speaking I don't believe we should have any null
>> function pointers.
>>
>> We just mandate that to be comitted, an impelmentation must provide a
>> dummy but, in this case when do we ever want a dummy function anyway
>> surely enable_irq() is a fundamental operation that is core to the logic.
>
> Why? What could be a justification here?
a) In principle I don't believe we should be adding an interface that
requires an exception in its first go.
b) I don't think its a good idea to proliferate patterns like this
throughout the code
if (vfe->res->hw_ops->enable_irq)
vfe->res->hw_ops->enable_irq();
too->many->indirection->calls();
easily dealt with but "looks wrong"
https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/
So if we are adding callbacks, the exception should be stubbing to an
empty function because 9/10 of implementations find the interface useful.
> It might be extremely confusing to see in the code that some not ever
> requested interrupts are enabled/disabled, and then to discover that just
> some stubs around VFE interrupts are added. And it's the case especially
> in this new vfe_enable_v2() function, which I believe is intended for
> CAMSS support on new platforms.
>
> What's worse, since these VFE interrupts are not needed on the modern
> platforms, it will require to add a proposed dummy "return 0" function
> into any CAMSS support for new platforms forever. I believe it'd be better
> to clearly say that it's a legacy to have an obligatory support of VFE
> interrupts.
I think enable_irq();/disable_irq(); should be handled from wm_start()
and wm_stop() for each VFE so that 480 and after can have shared
top-level logic.
However VFE can raise several error cases which TBH we should probably
be capturing somehow, if not in IRQ then in debugfs and/or trace
https://git.codelinaro.org/bryan.odonoghue/kernel/-/commit/cd88d924eb55f5dfeb2283e6e0eef37d5bd4c1c4
@Depeng can you move your enable_irq(); to camss-vfe-480.c::wm_start()
just after we switch on a WM
https://git.codelinaro.org/bryan.odonoghue/kernel/-/blob/2ea8172164e2b12a629cf3d939edac9a0f7a9368/drivers/media/platform/qcom/camss/camss-vfe-480.c#L127
as well as a disable_irq() to camss-vfe-480.c::wm_stop(); @ the top of
the function ?
https://git.codelinaro.org/bryan.odonoghue/kernel/-/blob/2ea8172164e2b12a629cf3d939edac9a0f7a9368/drivers/media/platform/qcom/camss/camss-vfe-480.c#L131
disable_irq() should also collapse the TOP irq when stream_count == 0
The stream_count variable should ensure the TOP irq value only gets
switched on/off once while also removing the special case from your
proposed amalgamated code.
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 09/13] media: qcom: camss: vfe: Move common code into vfe core
2024-08-24 13:06 ` Vladimir Zapolskiy
2024-08-28 0:07 ` Bryan O'Donoghue
@ 2024-09-02 13:11 ` Depeng Shao
1 sibling, 0 replies; 107+ messages in thread
From: Depeng Shao @ 2024-09-02 13:11 UTC (permalink / raw)
To: Vladimir Zapolskiy, Bryan O'Donoghue, rfoss, todor.too,
mchehab, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel
Hi Vladimir,
On 8/24/2024 9:06 PM, Vladimir Zapolskiy wrote:
>>> +
>>> +/*
>>> + * vfe_enable_v2 - Enable streaming on VFE line
>>> + * @line: VFE line
>>> + *
>>> + * Return 0 on success or a negative error code otherwise
>>> + */
>>> +int vfe_enable_v2(struct vfe_line *line)
>>> +{
>>> + struct vfe_device *vfe = to_vfe(line);
>>> + int ret;
>>> +
>>> + mutex_lock(&vfe->stream_lock);
>>> +
>>> + if (vfe->res->hw_ops->enable_irq)
>>> + vfe->res->hw_ops->enable_irq(vfe);
>>
>> Right so generally speaking I don't believe we should have any null
>> function pointers.
>>
>> We just mandate that to be comitted, an impelmentation must provide a
>> dummy but, in this case when do we ever want a dummy function anyway
>> surely enable_irq() is a fundamental operation that is core to the logic.
>
> Why? What could be a justification here?
>
> The image capturing media pipeline for all recent Qualcomm SoCs, including
> this one in the series for SM8550, can be set up and enabled without
> touching VFE interrupts at all.
>
> It might be extremely confusing to see in the code that some not ever
> requested interrupts are enabled/disabled, and then to discover that just
> some stubs around VFE interrupts are added. And it's the case especially
> in this new vfe_enable_v2() function, which I believe is intended for
> CAMSS support on new platforms.
>
> What's worse, since these VFE interrupts are not needed on the modern
> platforms, it will require to add a proposed dummy "return 0" function
> into any CAMSS support for new platforms forever. I believe it'd be better
> to clearly say that it's a legacy to have an obligatory support of VFE
> interrupts.
>
Sure, I will add a proposed dummy "return 0" function for these interfaces.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread
* [PATCH 10/13] media: qcom: camss: Add sm8550 compatible
2024-08-12 14:41 [PATCH v4 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (8 preceding siblings ...)
2024-08-12 14:41 ` [PATCH 09/13] media: qcom: camss: vfe: Move common code into vfe core Depeng Shao
@ 2024-08-12 14:41 ` Depeng Shao
2024-08-13 12:57 ` Bryan O'Donoghue
2024-08-12 14:41 ` [PATCH 11/13] media: qcom: camss: csiphy-3ph: Add Gen2 v2.1.2 two-phase MIPI CSI-2 DPHY support Depeng Shao
` (3 subsequent siblings)
13 siblings, 1 reply; 107+ 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
Add CAMSS_8550 enum, sm8550 compatible and sm8550 camss drvier private
data, the private data just include some basic information now, later
changes will enumerate with csiphy, csid and vfe resources.
Also add a default case in vfe_src_pad_code to get rid of a compile
warning since a new hw enum is added.
drivers/media/platform/qcom/camss/camss-vfe.c:291:10: warning:
enumeration value 'CAMSS_8550' not handled in switch [-Wswitch]
291 | switch (vfe->camss->res->version) {
| ^~~~~~~~~~~~~~~~~~~~~~~~
Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
---
drivers/media/platform/qcom/camss/camss-vfe.c | 4 +++
drivers/media/platform/qcom/camss/camss.c | 32 +++++++++++++++++++
drivers/media/platform/qcom/camss/camss.h | 1 +
3 files changed, 37 insertions(+)
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
index f6650694f47e..71bd55e854bb 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -403,6 +403,10 @@ static u32 vfe_src_pad_code(struct vfe_line *line, u32 sink_code,
return sink_code;
}
break;
+ default:
+ WARN(1, "Unsupported HW version: %x\n",
+ vfe->camss->res->version);
+ break;
}
return 0;
}
diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
index 51b1d3550421..519b37794745 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -1480,6 +1480,29 @@ static const struct resources_icc icc_res_sc8280xp[] = {
},
};
+static const struct resources_icc icc_res_sm8550[] = {
+ {
+ .name = "ahb",
+ .icc_bw_tbl.avg = 2097152,
+ .icc_bw_tbl.peak = 2097152,
+ },
+ {
+ .name = "hf_0_mnoc",
+ .icc_bw_tbl.avg = 2097152,
+ .icc_bw_tbl.peak = 2097152,
+ },
+ {
+ .name = "icp_mnoc",
+ .icc_bw_tbl.avg = 2097152,
+ .icc_bw_tbl.peak = 2097152,
+ },
+ {
+ .name = "sf_0_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
@@ -2443,6 +2466,14 @@ 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",
+ .icc_res = icc_res_sm8550,
+ .icc_path_num = ARRAY_SIZE(icc_res_sm8550),
+ .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 },
@@ -2450,6 +2481,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 },
{ }
};
diff --git a/drivers/media/platform/qcom/camss/camss.h b/drivers/media/platform/qcom/camss/camss.h
index 73c47c07fc30..5568ab32d5d7 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] 107+ messages in thread* Re: [PATCH 10/13] media: qcom: camss: Add sm8550 compatible
2024-08-12 14:41 ` [PATCH 10/13] media: qcom: camss: Add sm8550 compatible Depeng Shao
@ 2024-08-13 12:57 ` Bryan O'Donoghue
0 siblings, 0 replies; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-13 12:57 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel
On 12/08/2024 15:41, Depeng Shao wrote:
> Add CAMSS_8550 enum, sm8550 compatible and sm8550 camss drvier private
> data, the private data just include some basic information now, later
> changes will enumerate with csiphy, csid and vfe resources.
>
> Also add a default case in vfe_src_pad_code to get rid of a compile
> warning since a new hw enum is added.
>
> drivers/media/platform/qcom/camss/camss-vfe.c:291:10: warning:
> enumeration value 'CAMSS_8550' not handled in switch [-Wswitch]
> 291 | switch (vfe->camss->res->version) {
> | ^~~~~~~~~~~~~~~~~~~~~~~~
>
> Signed-off-by: Depeng Shao <quic_depengs@quicinc.com>
> ---
> drivers/media/platform/qcom/camss/camss-vfe.c | 4 +++
> drivers/media/platform/qcom/camss/camss.c | 32 +++++++++++++++++++
> drivers/media/platform/qcom/camss/camss.h | 1 +
> 3 files changed, 37 insertions(+)
>
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
> index f6650694f47e..71bd55e854bb 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
> @@ -403,6 +403,10 @@ static u32 vfe_src_pad_code(struct vfe_line *line, u32 sink_code,
> return sink_code;
> }
> break;
> + default:
> + WARN(1, "Unsupported HW version: %x\n",
> + vfe->camss->res->version);
> + break;
> }
> return 0;
> }
Please make the addition of the standalone case a standalone patch ;)
Then add.
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
To this patch.
> diff --git a/drivers/media/platform/qcom/camss/camss.c b/drivers/media/platform/qcom/camss/camss.c
> index 51b1d3550421..519b37794745 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -1480,6 +1480,29 @@ static const struct resources_icc icc_res_sc8280xp[] = {
> },
> };
>
> +static const struct resources_icc icc_res_sm8550[] = {
> + {
> + .name = "ahb",
> + .icc_bw_tbl.avg = 2097152,
> + .icc_bw_tbl.peak = 2097152,
> + },
> + {
> + .name = "hf_0_mnoc",
> + .icc_bw_tbl.avg = 2097152,
> + .icc_bw_tbl.peak = 2097152,
> + },
> + {
> + .name = "icp_mnoc",
> + .icc_bw_tbl.avg = 2097152,
> + .icc_bw_tbl.peak = 2097152,
> + },
> + {
> + .name = "sf_0_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
> @@ -2443,6 +2466,14 @@ 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",
> + .icc_res = icc_res_sm8550,
> + .icc_path_num = ARRAY_SIZE(icc_res_sm8550),
> + .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 },
> @@ -2450,6 +2481,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 },
> { }
> };
>
> diff --git a/drivers/media/platform/qcom/camss/camss.h b/drivers/media/platform/qcom/camss/camss.h
> index 73c47c07fc30..5568ab32d5d7 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 {
^ permalink raw reply [flat|nested] 107+ messages in thread
* [PATCH 11/13] media: qcom: camss: csiphy-3ph: Add Gen2 v2.1.2 two-phase MIPI CSI-2 DPHY support
2024-08-12 14:41 [PATCH v4 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (9 preceding siblings ...)
2024-08-12 14:41 ` [PATCH 10/13] media: qcom: camss: Add sm8550 compatible Depeng Shao
@ 2024-08-12 14:41 ` Depeng Shao
2024-08-12 14:41 ` [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550 Depeng Shao
` (2 subsequent siblings)
13 siblings, 0 replies; 107+ 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
Add a PHY configuration sequence and PHY resource for the sm8550 which
uses a Qualcomm Gen 2 version 2.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 | 111 ++++++++++++++++++
drivers/media/platform/qcom/camss/camss.c | 110 +++++++++++++++++
2 files changed, 221 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..06463d7eeb2a 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 2.1.2 2PH DPHY mode */
+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)
{
@@ -526,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;
}
@@ -613,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.c b/drivers/media/platform/qcom/camss/camss.c
index 519b37794745..1cdd40f49c27 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -1480,6 +1480,114 @@ 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 resources_icc icc_res_sm8550[] = {
{
.name = "ahb",
@@ -2469,8 +2577,10 @@ static const struct camss_resources sc8280xp_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
};
--
2.34.1
^ permalink raw reply related [flat|nested] 107+ messages in thread* [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550
2024-08-12 14:41 [PATCH v4 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (10 preceding siblings ...)
2024-08-12 14:41 ` [PATCH 11/13] media: qcom: camss: csiphy-3ph: Add Gen2 v2.1.2 two-phase MIPI CSI-2 DPHY support Depeng Shao
@ 2024-08-12 14:41 ` Depeng Shao
2024-08-14 16:08 ` Bryan O'Donoghue
` (6 more replies)
2024-08-12 14:41 ` [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780 Depeng Shao
2024-08-13 12:35 ` [PATCH v4 00/13] media: qcom: camss: Add sm8550 support Bryan O'Donoghue
13 siblings, 7 replies; 107+ 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
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.
The sm8550 also has a new block is named as CSID top, CSID can
connect to VFE or SFE(Sensor Front End), the connection is controlled
by CSID top.
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 | 339 ++++++++++++++++++
.../platform/qcom/camss/camss-csid-gen3.h | 26 ++
.../media/platform/qcom/camss/camss-csid.c | 46 ++-
.../media/platform/qcom/camss/camss-csid.h | 10 +
drivers/media/platform/qcom/camss/camss.c | 91 +++++
drivers/media/platform/qcom/camss/camss.h | 2 +
7 files changed, 503 insertions(+), 12 deletions(-)
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..d96bc126f0a9
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
@@ -0,0 +1,339 @@
+// 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_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_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_REG_UPDATE_CMD 0x18
+
+#define CSID_BUF_DONE_IRQ_STATUS 0x8C
+#define BUF_DONE_IRQ_STATUS_RDI_OFFSET (csid_is_lite(csid) ? 1 : 14)
+#define CSID_BUF_DONE_IRQ_MASK 0x90
+#define CSID_BUF_DONE_IRQ_CLEAR 0x94
+#define CSID_BUF_DONE_IRQ_SET 0x98
+
+#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
+
+#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_PHY_NUM_SEL 20
+
+#define CSID_CSI2_RX_CFG1 0x204
+#define CSI2_RX_CFG1_ECC_CORRECTION_EN 0
+#define CSI2_RX_CFG1_VC_MODE 2
+
+#define CSID_RDI_CFG0(rdi) (0x500 + 0x100 * (rdi))
+#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_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_PIX_STORE 10
+#define RDI_CFG1_PACKING_FORMAT 15
+
+#define CSID_RDI_CTRL(rdi) (0x504 + 0x100 * (rdi))
+#define RDI_CTRL_START_CMD 0
+
+#define CSID_RDI_IRQ_SUBSAMPLE_PATTERN(rdi) (0x548 + 0x100 * (rdi))
+#define CSID_RDI_IRQ_SUBSAMPLE_PERIOD(rdi) (0x54C + 0x100 * (rdi))
+
+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(val, csid->base + CSID_CSI2_RX_CFG0);
+
+ val = 1 << CSI2_RX_CFG1_ECC_CORRECTION_EN;
+ if (vc > 3)
+ val |= 1 << CSI2_RX_CFG1_VC_MODE;
+ writel(val, csid->base + CSID_CSI2_RX_CFG1);
+}
+
+static void __csid_ctrl_rdi(struct csid_device *csid, int enable, u8 rdi)
+{
+ int val = 0;
+
+ if (enable)
+ val = 1 << RDI_CTRL_START_CMD;
+
+ writel(val, csid->base + CSID_RDI_CTRL(rdi));
+}
+
+static void __csid_configure_top(struct csid_device *csid)
+{
+ u32 val;
+
+ /* csid lite doesn't need to configure top register */
+ if (csid->res->is_lite)
+ return;
+
+ /* CSID top is a new function in Titan780.
+ * CSID can connect to VFE & SFE(Sensor Front End).
+ * This connection is controlled by CSID top.
+ * Only enable VFE path in current driver.
+ */
+ val = OUTPUT_IFE_EN | INTERNAL_CSID;
+ writel(val, csid->camss->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 |= 1 << 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(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;
+
+ writel(val, csid->base + CSID_RDI_CFG1(vc));
+
+ val = 0;
+ writel(val, csid->base + CSID_RDI_IRQ_SUBSAMPLE_PERIOD(vc));
+
+ val = 1;
+ writel(val, csid->base + CSID_RDI_IRQ_SUBSAMPLE_PATTERN(vc));
+
+ val = 0;
+ writel(val, csid->base + CSID_RDI_CTRL(vc));
+
+ val = readl(csid->base + CSID_RDI_CFG0(vc));
+
+ if (enable)
+ val |= 1 << RDI_CFG0_EN;
+ writel(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)) {
+ __csid_configure_top(csid);
+ __csid_configure_rdi_stream(csid, enable, i);
+ __csid_configure_rx(csid, &csid->phy, i);
+ __csid_ctrl_rdi(csid, enable, i);
+ }
+}
+
+/*
+ * 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(csid->base + CSID_TOP_IRQ_STATUS);
+ writel(val, csid->base + CSID_TOP_IRQ_CLEAR);
+ reset_done = val & BIT(TOP_IRQ_STATUS_RESET_DONE);
+
+ val = readl(csid->base + CSID_CSI2_RX_IRQ_STATUS);
+ writel(val, csid->base + CSID_CSI2_RX_IRQ_CLEAR);
+
+ buf_done_val = readl(csid->base + CSID_BUF_DONE_IRQ_STATUS);
+ writel(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(csid->base + CSID_CSI2_RDIN_IRQ_STATUS(i));
+ writel(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.
+ */
+ camss_buf_done(csid->camss, csid->id, i);
+ }
+ }
+
+ val = 1 << IRQ_CMD_CLEAR;
+ writel(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(1, csid->base + CSID_TOP_IRQ_CLEAR);
+ writel(1, csid->base + CSID_IRQ_CMD);
+ writel(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(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
+ csid->base + CSID_BUF_DONE_IRQ_CLEAR);
+ writel(0x1 << IRQ_CMD_CLEAR, csid->base + CSID_IRQ_CMD);
+ writel(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(val, csid->base + CSID_RST_CFG);
+
+ val = (0x1 << SELECT_HW_RST) | (0x1 << SELECT_IRQ_RST);
+ writel(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 void csid_subdev_reg_update(struct csid_device *csid, int port_id, bool is_clear)
+{
+ if (is_clear) {
+ csid->reg_update &= ~REG_UPDATE_RDI(csid, port_id);
+ } else {
+ csid->reg_update |= REG_UPDATE_RDI(csid, port_id);
+ writel(csid->reg_update, csid->base + CSID_REG_UPDATE_CMD);
+ }
+}
+
+static void csid_subdev_init(struct csid_device *csid)
+{
+ /* nop */
+}
+
+const struct csid_hw_ops csid_ops_gen3 = {
+ /* No testgen pattern hw in csid gen3 HW */
+ .configure_testgen_pattern = NULL,
+ .configure_stream = csid_configure_stream,
+ .hw_version = csid_hw_version,
+ .isr = csid_isr,
+ .reset = csid_reset,
+ .src_pad_code = csid_src_pad_code,
+ .subdev_init = csid_subdev_init,
+ .reg_update = csid_subdev_reg_update,
+};
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..43aa0d8d89b9
--- /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 3
+ *
+ * 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.c b/drivers/media/platform/qcom/camss/camss-csid.c
index 5806df7e7a7c..8ce08929d91f 100644
--- a/drivers/media/platform/qcom/camss/camss-csid.c
+++ b/drivers/media/platform/qcom/camss/camss-csid.c
@@ -838,7 +838,7 @@ static void csid_try_format(struct csid_device *csid,
break;
case MSM_CSID_PAD_SRC:
- if (csid->testgen_mode->cur.val == 0) {
+ if (!csid->testgen_mode || csid->testgen_mode->cur.val == 0) {
/* Test generator is disabled, */
/* keep pad formats in sync */
u32 code = fmt->code;
@@ -1042,6 +1042,7 @@ static int csid_init_formats(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
static int csid_set_test_pattern(struct csid_device *csid, s32 value)
{
struct csid_testgen_config *tg = &csid->testgen;
+ const struct csid_hw_ops *hw_ops = csid->res->hw_ops;
/* If CSID is linked to CSIPHY, do not allow to enable test generator */
if (value && media_pad_remote_pad_first(&csid->pads[MSM_CSID_PAD_SINK]))
@@ -1049,7 +1050,10 @@ static int csid_set_test_pattern(struct csid_device *csid, s32 value)
tg->enabled = !!value;
- return csid->res->hw_ops->configure_testgen_pattern(csid, value);
+ if (hw_ops->configure_testgen_pattern)
+ return -EOPNOTSUPP;
+ else
+ return hw_ops->configure_testgen_pattern(csid, value);
}
/*
@@ -1121,6 +1125,19 @@ int msm_csid_subdev_init(struct camss *camss, struct csid_device *csid,
csid->base = devm_platform_ioremap_resource_byname(pdev, res->reg[0]);
if (IS_ERR(csid->base))
return PTR_ERR(csid->base);
+
+ /* CSID "top" is a new function in new version HW,
+ * CSID can connect to VFE & SFE(Sensor Front End).
+ * this connection is controlled by CSID "top" registers.
+ * There is only one CSID "top" region for all CSIDs.
+ */
+ if (!csid_is_lite(csid) && res->reg[1] && !camss->csid_top_base) {
+ camss->csid_top_base =
+ devm_platform_ioremap_resource_byname(pdev, res->reg[1]);
+
+ if (IS_ERR(camss->csid_top_base))
+ return PTR_ERR(camss->csid_top_base);
+ }
}
/* Interrupt */
@@ -1267,7 +1284,7 @@ static int csid_link_setup(struct media_entity *entity,
/* If test generator is enabled */
/* do not allow a link from CSIPHY to CSID */
- if (csid->testgen_mode->cur.val != 0)
+ if (csid->testgen_mode && csid->testgen_mode->cur.val != 0)
return -EBUSY;
sd = media_entity_to_v4l2_subdev(remote->entity);
@@ -1366,15 +1383,20 @@ int msm_csid_register_entity(struct csid_device *csid,
return ret;
}
- csid->testgen_mode = v4l2_ctrl_new_std_menu_items(&csid->ctrls,
- &csid_ctrl_ops, V4L2_CID_TEST_PATTERN,
- csid->testgen.nmodes, 0, 0,
- csid->testgen.modes);
-
- if (csid->ctrls.error) {
- dev_err(dev, "Failed to init ctrl: %d\n", csid->ctrls.error);
- ret = csid->ctrls.error;
- goto free_ctrl;
+ if (csid->res->hw_ops->configure_testgen_pattern) {
+ csid->testgen_mode =
+ v4l2_ctrl_new_std_menu_items(&csid->ctrls,
+ &csid_ctrl_ops,
+ V4L2_CID_TEST_PATTERN,
+ csid->testgen.nmodes, 0,
+ 0, csid->testgen.modes);
+
+ if (csid->ctrls.error) {
+ dev_err(dev, "Failed to init ctrl: %d\n",
+ csid->ctrls.error);
+ ret = csid->ctrls.error;
+ goto free_ctrl;
+ }
}
csid->subdev.ctrl_handler = &csid->ctrls;
diff --git a/drivers/media/platform/qcom/camss/camss-csid.h b/drivers/media/platform/qcom/camss/camss-csid.h
index f52209b96583..2715707dcdb4 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);
+
+ /*
+ * reg_update - receive message from other sub device
+ * @csid: CSID device
+ * @port_id: Port id
+ * @is_clear: Indicate if it is clearing reg update or setting reg update
+ */
+ void (*reg_update)(struct csid_device *csid, int port_id, bool is_clear);
};
struct csid_subdev_resources {
@@ -168,6 +176,7 @@ struct csid_device {
struct media_pad pads[MSM_CSID_PADS_NUM];
void __iomem *base;
u32 irq;
+ u32 reg_update;
char irq_name[30];
struct camss_clock *clock;
int nclocks;
@@ -228,6 +237,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.c b/drivers/media/platform/qcom/camss/camss.c
index 1cdd40f49c27..7ee102948dc4 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -1588,6 +1588,84 @@ static const struct camss_subdev_resources csiphy_res_8550[] = {
}
};
+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 resources_icc icc_res_sm8550[] = {
{
.name = "ahb",
@@ -1768,6 +1846,17 @@ void camss_pm_domain_off(struct camss *camss, int id)
}
}
+void camss_buf_done(struct camss *camss, int hw_id, int port_id)
+{
+ struct vfe_device *vfe;
+
+ if (hw_id < camss->res->vfe_num) {
+ vfe = &(camss->vfe[hw_id]);
+
+ vfe->res->hw_ops->vfe_buf_done(vfe, port_id);
+ }
+}
+
static int vfe_parent_dev_ops_get(struct camss *camss, int id)
{
int ret = -EINVAL;
@@ -2578,9 +2667,11 @@ 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
};
diff --git a/drivers/media/platform/qcom/camss/camss.h b/drivers/media/platform/qcom/camss/camss.h
index 5568ab32d5d7..d6b6558a82b9 100644
--- a/drivers/media/platform/qcom/camss/camss.h
+++ b/drivers/media/platform/qcom/camss/camss.h
@@ -117,6 +117,7 @@ struct camss {
struct device_link *genpd_link;
struct icc_path *icc_path[ICC_SM8250_COUNT];
const struct camss_resources *res;
+ void __iomem *csid_top_base;
};
struct camss_camera_interface {
@@ -155,5 +156,6 @@ void camss_pm_domain_off(struct camss *camss, int id);
int camss_vfe_get(struct camss *camss, int id);
void camss_vfe_put(struct camss *camss, int id);
void camss_delete(struct camss *camss);
+void camss_buf_done(struct camss *camss, int hw_id, int port_id);
#endif /* QC_MSM_CAMSS_H */
--
2.34.1
^ permalink raw reply related [flat|nested] 107+ messages in thread* Re: [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550
2024-08-12 14:41 ` [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550 Depeng Shao
@ 2024-08-14 16:08 ` Bryan O'Donoghue
2024-08-15 15:14 ` Depeng Shao
2024-08-16 11:34 ` Bryan O'Donoghue
` (5 subsequent siblings)
6 siblings, 1 reply; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-14 16:08 UTC (permalink / raw)
To: 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/08/2024 15:41, 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.
>
> The sm8550 also has a new block is named as CSID top, CSID can
> connect to VFE or SFE(Sensor Front End), the connection is controlled
> by CSID top.
>
> 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 | 339 ++++++++++++++++++
> .../platform/qcom/camss/camss-csid-gen3.h | 26 ++
So this "gen2" and "gen3" stuff would make sense if we had a number of
SoCs based on gen2 and gen3 which were controlled from the upper-level
gen2.c and gen3.c.
What you're submitting here is csid-780 so the file should be named
csid-780.
When we add 680 or 880 then it makes sense to try to encapsulate a class
of generation into one file - potentially.
I'd guess that was the intent behind gen2.c.
TL;DR please name your file csid-xxx.c
> .../media/platform/qcom/camss/camss-csid.c | 46 ++-
> .../media/platform/qcom/camss/camss-csid.h | 10 +
> drivers/media/platform/qcom/camss/camss.c | 91 +++++
> drivers/media/platform/qcom/camss/camss.h | 2 +
> 7 files changed, 503 insertions(+), 12 deletions(-)
> 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..d96bc126f0a9
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
> @@ -0,0 +1,339 @@
> +// 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_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_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_REG_UPDATE_CMD 0x18
> +
> +#define CSID_BUF_DONE_IRQ_STATUS 0x8C
> +#define BUF_DONE_IRQ_STATUS_RDI_OFFSET (csid_is_lite(csid) ? 1 : 14)
> +#define CSID_BUF_DONE_IRQ_MASK 0x90
> +#define CSID_BUF_DONE_IRQ_CLEAR 0x94
> +#define CSID_BUF_DONE_IRQ_SET 0x98
> +
> +#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
> +
> +#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_PHY_NUM_SEL 20
> +
> +#define CSID_CSI2_RX_CFG1 0x204
> +#define CSI2_RX_CFG1_ECC_CORRECTION_EN 0
> +#define CSI2_RX_CFG1_VC_MODE 2
> +
> +#define CSID_RDI_CFG0(rdi) (0x500 + 0x100 * (rdi))
> +#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_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_PIX_STORE 10
> +#define RDI_CFG1_PACKING_FORMAT 15
> +
> +#define CSID_RDI_CTRL(rdi) (0x504 + 0x100 * (rdi))
> +#define RDI_CTRL_START_CMD 0
> +
> +#define CSID_RDI_IRQ_SUBSAMPLE_PATTERN(rdi) (0x548 + 0x100 * (rdi))
> +#define CSID_RDI_IRQ_SUBSAMPLE_PERIOD(rdi) (0x54C + 0x100 * (rdi))
> +
> +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(val, csid->base + CSID_CSI2_RX_CFG0);
> +
> + val = 1 << CSI2_RX_CFG1_ECC_CORRECTION_EN;
> + if (vc > 3)
> + val |= 1 << CSI2_RX_CFG1_VC_MODE;
So again these are needless bit-shifts.
#define CSI2_RX_CFG1_PACKET_ECC_CORRECTION_EN BIT(0)
val = CSI2_RX_CFG1_PACKET_ECC_CORRECTION_EN;
> + writel(val, csid->base + CSID_CSI2_RX_CFG1);
> +}
> +
> +static void __csid_ctrl_rdi(struct csid_device *csid, int enable, u8 rdi)
> +{
> + int val = 0;
> +
> + if (enable)
> + val = 1 << RDI_CTRL_START_CMD;
and again, please apply BIT() as thorougly as possible in your submission.
> + writel(val, csid->base + CSID_RDI_CTRL(rdi));
> +}
> +
> +static void __csid_configure_top(struct csid_device *csid)
> +{
> + u32 val;
> +
> + /* csid lite doesn't need to configure top register */
> + if (csid->res->is_lite)
> + return;
> +
> + /* CSID top is a new function in Titan780.
> + * CSID can connect to VFE & SFE(Sensor Front End).
> + * This connection is controlled by CSID top.
> + * Only enable VFE path in current driver.
> + */
> + val = OUTPUT_IFE_EN | INTERNAL_CSID;
> + writel(val, csid->camss->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 |= 1 << 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(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;
> +
> + writel(val, csid->base + CSID_RDI_CFG1(vc));
> +
> + val = 0;
> + writel(val, csid->base + CSID_RDI_IRQ_SUBSAMPLE_PERIOD(vc));
> +
> + val = 1;
> + writel(val, csid->base + CSID_RDI_IRQ_SUBSAMPLE_PATTERN(vc));
> +
> + val = 0;
> + writel(val, csid->base + CSID_RDI_CTRL(vc));
> +
> + val = readl(csid->base + CSID_RDI_CFG0(vc));
> +
> + if (enable)
> + val |= 1 << RDI_CFG0_EN;
> + writel(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)) {
> + __csid_configure_top(csid);
> + __csid_configure_rdi_stream(csid, enable, i);
> + __csid_configure_rx(csid, &csid->phy, i);
> + __csid_ctrl_rdi(csid, enable, i);
> + }
> +}
> +
> +/*
> + * 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(csid->base + CSID_TOP_IRQ_STATUS);
> + writel(val, csid->base + CSID_TOP_IRQ_CLEAR);
> + reset_done = val & BIT(TOP_IRQ_STATUS_RESET_DONE);
> +
> + val = readl(csid->base + CSID_CSI2_RX_IRQ_STATUS);
> + writel(val, csid->base + CSID_CSI2_RX_IRQ_CLEAR);
> +
> + buf_done_val = readl(csid->base + CSID_BUF_DONE_IRQ_STATUS);
> + writel(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(csid->base + CSID_CSI2_RDIN_IRQ_STATUS(i));
> + writel(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.
> + */
> + camss_buf_done(csid->camss, csid->id, i);
> + }
> + }
> +
> + val = 1 << IRQ_CMD_CLEAR;
> + writel(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(1, csid->base + CSID_TOP_IRQ_CLEAR);
> + writel(1, csid->base + CSID_IRQ_CMD);
> + writel(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(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
> + csid->base + CSID_BUF_DONE_IRQ_CLEAR);
> + writel(0x1 << IRQ_CMD_CLEAR, csid->base + CSID_IRQ_CMD);
> + writel(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(val, csid->base + CSID_RST_CFG);
> +
> + val = (0x1 << SELECT_HW_RST) | (0x1 << SELECT_IRQ_RST);
> + writel(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 void csid_subdev_reg_update(struct csid_device *csid, int port_id, bool is_clear)
> +{
> + if (is_clear) {
> + csid->reg_update &= ~REG_UPDATE_RDI(csid, port_id);
> + } else {
> + csid->reg_update |= REG_UPDATE_RDI(csid, port_id);
> + writel(csid->reg_update, csid->base + CSID_REG_UPDATE_CMD);
> + }
> +}
Right so this function should
1. Write the register
2. Wait on a completion
See camss-vfe-480.c::vfe_isr_reg_update()
3. Have that completion fire in the CSID ISR
4. Or timeout
5. Returning either 0 for success or -ETIMEDOUT
to the calling function so that we can be sure the RUP interrupt has
fired and completed - or we have appropriately timed out and captured
the failure.
Also - in camss-vfe-480.c the ISR clears the RUP which one assumes is
still the required logical flow with the RUP now residing in CSID.
> +
> +static void csid_subdev_init(struct csid_device *csid)
> +{
> + /* nop */
> +}
> +
> +const struct csid_hw_ops csid_ops_gen3 = {
> + /* No testgen pattern hw in csid gen3 HW */
> + .configure_testgen_pattern = NULL,
> + .configure_stream = csid_configure_stream,
> + .hw_version = csid_hw_version,
> + .isr = csid_isr,
> + .reset = csid_reset,
> + .src_pad_code = csid_src_pad_code,
> + .subdev_init = csid_subdev_init,
> + .reg_update = csid_subdev_reg_update,
> +};
> 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..43aa0d8d89b9
> --- /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 3
> + *
> + * 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.c b/drivers/media/platform/qcom/camss/camss-csid.c
> index 5806df7e7a7c..8ce08929d91f 100644
> --- a/drivers/media/platform/qcom/camss/camss-csid.c
> +++ b/drivers/media/platform/qcom/camss/camss-csid.c
> @@ -838,7 +838,7 @@ static void csid_try_format(struct csid_device *csid,
> break;
>
> case MSM_CSID_PAD_SRC:
> - if (csid->testgen_mode->cur.val == 0) {
> + if (!csid->testgen_mode || csid->testgen_mode->cur.val == 0) {
See my comments on adding new guards to core functionality.
Is this sm8550 specific or generic ?
> /* Test generator is disabled, */
> /* keep pad formats in sync */
> u32 code = fmt->code;
> @@ -1042,6 +1042,7 @@ static int csid_init_formats(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh)
> static int csid_set_test_pattern(struct csid_device *csid, s32 value)
> {
> struct csid_testgen_config *tg = &csid->testgen;
> + const struct csid_hw_ops *hw_ops = csid->res->hw_ops;
>
> /* If CSID is linked to CSIPHY, do not allow to enable test generator */
> if (value && media_pad_remote_pad_first(&csid->pads[MSM_CSID_PAD_SINK]))
> @@ -1049,7 +1050,10 @@ static int csid_set_test_pattern(struct csid_device *csid, s32 value)
>
> tg->enabled = !!value;
>
> - return csid->res->hw_ops->configure_testgen_pattern(csid, value);
> + if (hw_ops->configure_testgen_pattern)
> + return -EOPNOTSUPP;
> + else
> + return hw_ops->configure_testgen_pattern(csid, value);
If you just add a dummy configure_testgen_pattern we can get rid of this
branching stuff.
> }
>
> /*
> @@ -1121,6 +1125,19 @@ int msm_csid_subdev_init(struct camss *camss, struct csid_device *csid,
> csid->base = devm_platform_ioremap_resource_byname(pdev, res->reg[0]);
> if (IS_ERR(csid->base))
> return PTR_ERR(csid->base);
> +
> + /* CSID "top" is a new function in new version HW,
> + * CSID can connect to VFE & SFE(Sensor Front End).
> + * this connection is controlled by CSID "top" registers.
> + * There is only one CSID "top" region for all CSIDs.
> + */
> + if (!csid_is_lite(csid) && res->reg[1] && !camss->csid_top_base) {
> + camss->csid_top_base =
> + devm_platform_ioremap_resource_byname(pdev, res->reg[1]);
That's a complex clause.
Let me send you a patch to do it a different way.
> +
> + if (IS_ERR(camss->csid_top_base))
> + return PTR_ERR(camss->csid_top_base);
> + }
> }
>
> /* Interrupt */
> @@ -1267,7 +1284,7 @@ static int csid_link_setup(struct media_entity *entity,
>
> /* If test generator is enabled */
> /* do not allow a link from CSIPHY to CSID */
> - if (csid->testgen_mode->cur.val != 0)
> + if (csid->testgen_mode && csid->testgen_mode->cur.val != 0)
OK, so stuff like this isn't really about enabling 8550.
If you want to add an additional guard here, it _needs_ to be a
standalone patch which fixes a particular issue.
I'm not sure if this new guard is necessary - and the right place to
tease that out, is in a specific patch for that purpose, not in a new
silicon enabling patch.
That's a blanket comment for the series.
> return -EBUSY;
>
> sd = media_entity_to_v4l2_subdev(remote->entity);
> @@ -1366,15 +1383,20 @@ int msm_csid_register_entity(struct csid_device *csid,
> return ret;
> }
>
> - csid->testgen_mode = v4l2_ctrl_new_std_menu_items(&csid->ctrls,
> - &csid_ctrl_ops, V4L2_CID_TEST_PATTERN,
> - csid->testgen.nmodes, 0, 0,
> - csid->testgen.modes);
> -
> - if (csid->ctrls.error) {
> - dev_err(dev, "Failed to init ctrl: %d\n", csid->ctrls.error);
> - ret = csid->ctrls.error;
> - goto free_ctrl;
> + if (csid->res->hw_ops->configure_testgen_pattern) {
> + csid->testgen_mode =
> + v4l2_ctrl_new_std_menu_items(&csid->ctrls,
> + &csid_ctrl_ops,
> + V4L2_CID_TEST_PATTERN,
> + csid->testgen.nmodes, 0,
> + 0, csid->testgen.modes);
Here again - what's going on here and how is it 8550/csid-680 specific ?
Don't just add new guards or new debug statements unless its under a
heading of "add a new check for reason X".
The reason for that is we want granular patches in particular we don't
want to "backdoor" in fixes into a new SoC which can't be cherry-picked
back to a stable kernel.
> +
> + if (csid->ctrls.error) {
> + dev_err(dev, "Failed to init ctrl: %d\n",
> + csid->ctrls.error);
> + ret = csid->ctrls.error;
> + goto free_ctrl;
> + }
> }
>
> csid->subdev.ctrl_handler = &csid->ctrls;
> diff --git a/drivers/media/platform/qcom/camss/camss-csid.h b/drivers/media/platform/qcom/camss/camss-csid.h
> index f52209b96583..2715707dcdb4 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);
> +
> + /*
> + * reg_update - receive message from other sub device
> + * @csid: CSID device
> + * @port_id: Port id
> + * @is_clear: Indicate if it is clearing reg update or setting reg update
> + */
> + void (*reg_update)(struct csid_device *csid, int port_id, bool is_clear);
> };
>
> struct csid_subdev_resources {
> @@ -168,6 +176,7 @@ struct csid_device {
> struct media_pad pads[MSM_CSID_PADS_NUM];
> void __iomem *base;
> u32 irq;
> + u32 reg_update;
> char irq_name[30];
> struct camss_clock *clock;
> int nclocks;
> @@ -228,6 +237,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.c b/drivers/media/platform/qcom/camss/camss.c
> index 1cdd40f49c27..7ee102948dc4 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -1588,6 +1588,84 @@ static const struct camss_subdev_resources csiphy_res_8550[] = {
> }
> };
>
> +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 } },
I think you should be setting at least _one_ CAMNOC clock in the CSID.
> + .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 resources_icc icc_res_sm8550[] = {
> {
> .name = "ahb",
> @@ -1768,6 +1846,17 @@ void camss_pm_domain_off(struct camss *camss, int id)
> }
> }
>
> +void camss_buf_done(struct camss *camss, int hw_id, int port_id)
> +{
> + struct vfe_device *vfe;
> +
> + if (hw_id < camss->res->vfe_num) {
> + vfe = &(camss->vfe[hw_id]);
> +
> + vfe->res->hw_ops->vfe_buf_done(vfe, port_id);
> + }
> +}
> +
> static int vfe_parent_dev_ops_get(struct camss *camss, int id)
> {
> int ret = -EINVAL;
> @@ -2578,9 +2667,11 @@ 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
> };
>
> diff --git a/drivers/media/platform/qcom/camss/camss.h b/drivers/media/platform/qcom/camss/camss.h
> index 5568ab32d5d7..d6b6558a82b9 100644
> --- a/drivers/media/platform/qcom/camss/camss.h
> +++ b/drivers/media/platform/qcom/camss/camss.h
> @@ -117,6 +117,7 @@ struct camss {
> struct device_link *genpd_link;
> struct icc_path *icc_path[ICC_SM8250_COUNT];
> const struct camss_resources *res;
> + void __iomem *csid_top_base;
> };
>
> struct camss_camera_interface {
> @@ -155,5 +156,6 @@ void camss_pm_domain_off(struct camss *camss, int id);
> int camss_vfe_get(struct camss *camss, int id);
> void camss_vfe_put(struct camss *camss, int id);
> void camss_delete(struct camss *camss);
> +void camss_buf_done(struct camss *camss, int hw_id, int port_id);
>
> #endif /* QC_MSM_CAMSS_H */
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550
2024-08-14 16:08 ` Bryan O'Donoghue
@ 2024-08-15 15:14 ` Depeng Shao
2024-08-15 16:10 ` Bryan O'Donoghue
0 siblings, 1 reply; 107+ messages in thread
From: Depeng Shao @ 2024-08-15 15:14 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hi Bryan,
>> ---
>> drivers/media/platform/qcom/camss/Makefile | 1 +
>> .../platform/qcom/camss/camss-csid-gen3.c | 339 ++++++++++++++++++
>> .../platform/qcom/camss/camss-csid-gen3.h | 26 ++
>
>
> So this "gen2" and "gen3" stuff would make sense if we had a number of
> SoCs based on gen2 and gen3 which were controlled from the upper-level
> gen2.c and gen3.c.
>
> What you're submitting here is csid-780 so the file should be named
> csid-780.
>
> When we add 680 or 880 then it makes sense to try to encapsulate a class
> of generation into one file - potentially.
>
> I'd guess that was the intent behind gen2.c.
>
> TL;DR please name your file csid-xxx.c
Sure, I will use csid-780.c
>> +
>> + writel(val, csid->base + CSID_CSI2_RX_CFG0);
>> +
>> + val = 1 << CSI2_RX_CFG1_ECC_CORRECTION_EN;
>> + if (vc > 3)
>> + val |= 1 << CSI2_RX_CFG1_VC_MODE;
>
> So again these are needless bit-shifts.
>
> #define CSI2_RX_CFG1_PACKET_ECC_CORRECTION_EN BIT(0)
>
> val = CSI2_RX_CFG1_PACKET_ECC_CORRECTION_EN;
>
You posted same comments in v3 series, I also replied it.
https://lore.kernel.org/all/eeaf4f4e-5200-4b13-b38f-3f3385fc2a2b@quicinc.com/
Some of register bits which just need to be configured to 0 or 1, then
can use BIT(X), but some register bits need to configure a specific
value, e.g., CSID_RDI_CFG0 bits[22:26] need to configure a vc vaule,
bits[16:21] need to configure a dt value, then we can't use BIT(x) to
handle this.
>> +
>> +static void csid_subdev_reg_update(struct csid_device *csid, int
>> port_id, bool is_clear)
>> +{
>> + if (is_clear) {
>> + csid->reg_update &= ~REG_UPDATE_RDI(csid, port_id);
>> + } else {
>> + csid->reg_update |= REG_UPDATE_RDI(csid, port_id);
>> + writel(csid->reg_update, csid->base + CSID_REG_UPDATE_CMD);
>> + }
>> +}
>
> Right so this function should
>
> 1. Write the register
> 2. Wait on a completion
> See camss-vfe-480.c::vfe_isr_reg_update()
> 3. Have that completion fire in the CSID ISR
> 4. Or timeout
> 5. Returning either 0 for success or -ETIMEDOUT
>
> to the calling function so that we can be sure the RUP interrupt has
> fired and completed - or we have appropriately timed out and captured
> the failure.
>
> Also - in camss-vfe-480.c the ISR clears the RUP which one assumes is
> still the required logical flow with the RUP now residing in CSID.
>
Sure, I forget to add this, will add them in next series.
>> case MSM_CSID_PAD_SRC:
>> - if (csid->testgen_mode->cur.val == 0) {
>> + if (!csid->testgen_mode || csid->testgen_mode->cur.val == 0) {
>
> See my comments on adding new guards to core functionality.
>
> Is this sm8550 specific or generic ?
>
It is sm8550 specific, since we don't have testgen mode in sm8550 csid,
so need to add some guards, the guards are added for similar reason.
>> /* Test generator is disabled, */
>> /* keep pad formats in sync */
>> u32 code = fmt->code;
>> @@ -1042,6 +1042,7 @@ static int csid_init_formats(struct v4l2_subdev
>> *sd, struct v4l2_subdev_fh *fh)
>> static int csid_set_test_pattern(struct csid_device *csid, s32 value)
>> {
>> struct csid_testgen_config *tg = &csid->testgen;
>> + const struct csid_hw_ops *hw_ops = csid->res->hw_ops;
>> /* If CSID is linked to CSIPHY, do not allow to enable test
>> generator */
>> if (value && media_pad_remote_pad_first(&csid-
>> >pads[MSM_CSID_PAD_SINK]))
>> @@ -1049,7 +1050,10 @@ static int csid_set_test_pattern(struct
>> csid_device *csid, s32 value)
>> tg->enabled = !!value;
>> - return csid->res->hw_ops->configure_testgen_pattern(csid, value);
>> + if (hw_ops->configure_testgen_pattern)
>> + return -EOPNOTSUPP;
>> + else
>> + return hw_ops->configure_testgen_pattern(csid, value);
>
> If you just add a dummy configure_testgen_pattern we can get rid of this
> branching stuff.
>
Do you mean add dummy function in csid-780/gen3.c? How about the other
ops in vfe_ops_780, add dummy function or use NULL? We need to guards if
we set it as NULL.
static int csid_configure_testgen_pattern(struct csid_device *csid, s32 val)
{
return 0;
}
>> }
>> /*
>> @@ -1121,6 +1125,19 @@ int msm_csid_subdev_init(struct camss *camss,
>> struct csid_device *csid,
>> csid->base = devm_platform_ioremap_resource_byname(pdev,
>> res->reg[0]);
>> if (IS_ERR(csid->base))
>> return PTR_ERR(csid->base);
>> +
>> + /* CSID "top" is a new function in new version HW,
>> + * CSID can connect to VFE & SFE(Sensor Front End).
>> + * this connection is controlled by CSID "top" registers.
>> + * There is only one CSID "top" region for all CSIDs.
>> + */
>> + if (!csid_is_lite(csid) && res->reg[1] && !camss-
>> >csid_top_base) {
>> + camss->csid_top_base =
>> + devm_platform_ioremap_resource_byname(pdev, res-
>> >reg[1]);
>
> That's a complex clause.
>
> Let me send you a patch to do it a different way.
>
I was also thinking to addd it in camss level, then I thought it is in
csid block, so I moved it to csid, but it is also fine to add it in
camss. Can I add your patch into this series? Just like the csiphy patches.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550
2024-08-15 15:14 ` Depeng Shao
@ 2024-08-15 16:10 ` Bryan O'Donoghue
0 siblings, 0 replies; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-15 16:10 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 15/08/2024 16:14, Depeng Shao wrote:
> Hi Bryan,
>
>
>>> ---
>>> drivers/media/platform/qcom/camss/Makefile | 1 +
>>> .../platform/qcom/camss/camss-csid-gen3.c | 339 ++++++++++++++++++
>>> .../platform/qcom/camss/camss-csid-gen3.h | 26 ++
>>
>>
>> So this "gen2" and "gen3" stuff would make sense if we had a number of
>> SoCs based on gen2 and gen3 which were controlled from the upper-level
>> gen2.c and gen3.c.
>>
>> What you're submitting here is csid-780 so the file should be named
>> csid-780.
>>
>> When we add 680 or 880 then it makes sense to try to encapsulate a
>> class of generation into one file - potentially.
>>
>> I'd guess that was the intent behind gen2.c.
>>
>> TL;DR please name your file csid-xxx.c
>
> Sure, I will use csid-780.c
>
>>> +
>>> + writel(val, csid->base + CSID_CSI2_RX_CFG0);
>>> +
>>> + val = 1 << CSI2_RX_CFG1_ECC_CORRECTION_EN;
>>> + if (vc > 3)
>>> + val |= 1 << CSI2_RX_CFG1_VC_MODE;
>>
>> So again these are needless bit-shifts.
>>
>> #define CSI2_RX_CFG1_PACKET_ECC_CORRECTION_EN BIT(0)
>>
>> val = CSI2_RX_CFG1_PACKET_ECC_CORRECTION_EN;
>>
>
> You posted same comments in v3 series, I also replied it.
> https://lore.kernel.org/all/eeaf4f4e-5200-4b13-b38f-3f3385fc2a2b@quicinc.com/
>
> Some of register bits which just need to be configured to 0 or 1, then
> can use BIT(X), but some register bits need to configure a specific
> value, e.g., CSID_RDI_CFG0 bits[22:26] need to configure a vc vaule,
> bits[16:21] need to configure a dt value, then we can't use BIT(x) to
> handle this.
Yes please use macros() to bury any _necessary_ bit shifts to populate a
_bit_field_ away but as an example CSI2_RX_CFG1_PACKET_ECC_CORRECTION_EN
is not a bit-field.
>
>
>>> case MSM_CSID_PAD_SRC:
>>> - if (csid->testgen_mode->cur.val == 0) {
>>> + if (!csid->testgen_mode || csid->testgen_mode->cur.val == 0) {
>>
>> See my comments on adding new guards to core functionality.
>>
>> Is this sm8550 specific or generic ?
>>
>
> It is sm8550 specific, since we don't have testgen mode in sm8550 csid,
> so need to add some guards, the guards are added for similar reason.
Hmm, I see in my tree I just assigned testgen_mode to some dummy data.
You're right, retain this, when we enable testgen as a standalone entity
outside of CSID we can address this again.
>
>>> /* Test generator is disabled, */
>>> /* keep pad formats in sync */
>>> u32 code = fmt->code;
>>> @@ -1042,6 +1042,7 @@ static int csid_init_formats(struct v4l2_subdev
>>> *sd, struct v4l2_subdev_fh *fh)
>>> static int csid_set_test_pattern(struct csid_device *csid, s32 value)
>>> {
>>> struct csid_testgen_config *tg = &csid->testgen;
>>> + const struct csid_hw_ops *hw_ops = csid->res->hw_ops;
>>> /* If CSID is linked to CSIPHY, do not allow to enable test
>>> generator */
>>> if (value && media_pad_remote_pad_first(&csid-
>>> >pads[MSM_CSID_PAD_SINK]))
>>> @@ -1049,7 +1050,10 @@ static int csid_set_test_pattern(struct
>>> csid_device *csid, s32 value)
>>> tg->enabled = !!value;
>>> - return csid->res->hw_ops->configure_testgen_pattern(csid, value);
>>> + if (hw_ops->configure_testgen_pattern)
>>> + return -EOPNOTSUPP;
>>> + else
>>> + return hw_ops->configure_testgen_pattern(csid, value);
>>
>> If you just add a dummy configure_testgen_pattern we can get rid of
>> this branching stuff.
>>
>
> Do you mean add dummy function in csid-780/gen3.c? How about the other
> ops in vfe_ops_780, add dummy function or use NULL? We need to guards if
> we set it as NULL.
See above, you're right what you have is fine.
>
> static int csid_configure_testgen_pattern(struct csid_device *csid, s32
> val)
> {
> return 0;
> }
>
>>> }
>>> /*
>>> @@ -1121,6 +1125,19 @@ int msm_csid_subdev_init(struct camss *camss,
>>> struct csid_device *csid,
>>> csid->base = devm_platform_ioremap_resource_byname(pdev,
>>> res->reg[0]);
>>> if (IS_ERR(csid->base))
>>> return PTR_ERR(csid->base);
>>> +
>>> + /* CSID "top" is a new function in new version HW,
>>> + * CSID can connect to VFE & SFE(Sensor Front End).
>>> + * this connection is controlled by CSID "top" registers.
>>> + * There is only one CSID "top" region for all CSIDs.
>>> + */
>>> + if (!csid_is_lite(csid) && res->reg[1] && !camss-
>>> >csid_top_base) {
>>> + camss->csid_top_base =
>>> + devm_platform_ioremap_resource_byname(pdev, res-
>>> >reg[1]);
>>
>> That's a complex clause.
>>
>> Let me send you a patch to do it a different way.
>>
>
> I was also thinking to addd it in camss level, then I thought it is in
> csid block, so I moved it to csid, but it is also fine to add it in
> camss. Can I add your patch into this series? Just like the csiphy patches.
static const struct resources_wrapper csid_wrapper_res_sm8550 = {
.reg = "csid_wrapper",
};
Yes go ahead, all you should need to do then is add
"&csid_wrapper_res_sm8550" to your resources.
static const struct camss_resources sm8550_resources = {
.version = CAMSS_SM8550,
.pd_name = "top",
.csiphy_res = csiphy_res_sm8550,
.csid_res = csid_res_sm8550,
.ispif_res = NULL,
.vfe_res = vfe_res_sm8550,
.csid_wrapper_res = &csid_wrapper_res_sm8550,
...
};
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550
2024-08-12 14:41 ` [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550 Depeng Shao
2024-08-14 16:08 ` Bryan O'Donoghue
@ 2024-08-16 11:34 ` Bryan O'Donoghue
2024-08-16 13:11 ` Depeng Shao
2024-08-16 14:21 ` Bryan O'Donoghue
` (4 subsequent siblings)
6 siblings, 1 reply; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-16 11:34 UTC (permalink / raw)
To: 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/08/2024 15:41, Depeng Shao wrote:
> +
> +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)) {
> + __csid_configure_top(csid);
> + __csid_configure_rdi_stream(csid, enable, i);
> + __csid_configure_rx(csid, &csid->phy, i);
> + __csid_ctrl_rdi(csid, enable, i);
> + }
> +}
Just noticed this too.
You're configuring the CSID routing here for each enabled VC but, you
should only do that once @ the top level
->
__csid_configure_top(csid);
/* 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)) {
__csid_configure_rdi_stream(csid, enable, i);
__csid_configure_rx(csid, &csid->phy, i);
__csid_ctrl_rdi(csid, enable, i);
}
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550
2024-08-16 11:34 ` Bryan O'Donoghue
@ 2024-08-16 13:11 ` Depeng Shao
0 siblings, 0 replies; 107+ messages in thread
From: Depeng Shao @ 2024-08-16 13:11 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hi Bryan,
On 8/16/2024 7:34 PM, Bryan O'Donoghue wrote:
>
> Just noticed this too.
>
> You're configuring the CSID routing here for each enabled VC but, you
> should only do that once @ the top level
>
> ->
>
>
> __csid_configure_top(csid);
>
> /* 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)) {
> __csid_configure_rdi_stream(csid, enable, i);
> __csid_configure_rx(csid, &csid->phy, i);
> __csid_ctrl_rdi(csid, enable, i);
> }
>
Yes, you are right, will move configure_top out of the for loop.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550
2024-08-12 14:41 ` [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550 Depeng Shao
2024-08-14 16:08 ` Bryan O'Donoghue
2024-08-16 11:34 ` Bryan O'Donoghue
@ 2024-08-16 14:21 ` Bryan O'Donoghue
2024-08-19 13:23 ` Depeng Shao
2024-08-16 14:45 ` Bryan O'Donoghue
` (3 subsequent siblings)
6 siblings, 1 reply; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-16 14:21 UTC (permalink / raw)
To: 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/08/2024 15:41, Depeng Shao wrote:
> +#define CSID_RDI_CFG1(rdi) (0x510 + 0x100 * (rdi))
> +#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_PIX_STORE 10
Hmm - is bit 10 valid ? I'm looking at a register set derived from 8550
and don't see it
> +#define RDI_CFG1_PACKING_FORMAT 15
Bit 15 selects either BIT(15) = 0 PACKING_FORMAT_PLAIN or BIT(15) = 1
PACKING_FORMAT_MIPI
Please give this bit a more descriptive name =>
#define RDI_CFG1_PACKING_FORMAT_MIPI 15
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550
2024-08-16 14:21 ` Bryan O'Donoghue
@ 2024-08-19 13:23 ` Depeng Shao
0 siblings, 0 replies; 107+ messages in thread
From: Depeng Shao @ 2024-08-19 13:23 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hi Bryan,
On 8/16/2024 10:21 PM, Bryan O'Donoghue wrote:
> On 12/08/2024 15:41, Depeng Shao wrote:
>> +#define CSID_RDI_CFG1(rdi) (0x510 + 0x100 * (rdi))
>> +#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_PIX_STORE 10
>
> Hmm - is bit 10 valid ? I'm looking at a register set derived from 8550
> and don't see it
>
The bit10 is valid in sm8550, but it isn't there in sm8750.
>> +#define RDI_CFG1_PACKING_FORMAT 15
>
> Bit 15 selects either BIT(15) = 0 PACKING_FORMAT_PLAIN or BIT(15) = 1
> PACKING_FORMAT_MIPI
>
> Please give this bit a more descriptive name =>
>
> #define RDI_CFG1_PACKING_FORMAT_MIPI 15
>
Sure. I will update it.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550
2024-08-12 14:41 ` [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550 Depeng Shao
` (2 preceding siblings ...)
2024-08-16 14:21 ` Bryan O'Donoghue
@ 2024-08-16 14:45 ` Bryan O'Donoghue
2024-08-19 13:18 ` Depeng Shao
2024-08-16 14:49 ` Bryan O'Donoghue
` (2 subsequent siblings)
6 siblings, 1 reply; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-16 14:45 UTC (permalink / raw)
To: 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/08/2024 15:41, Depeng Shao wrote:
> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS; i++)
> + if (csid->phy.en_vc & BIT(i)) {
> + writel(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
> + csid->base + CSID_BUF_DONE_IRQ_CLEAR);
> + writel(0x1 << IRQ_CMD_CLEAR, csid->base + CSID_IRQ_CMD);
IRQ_CMD_CLEAR is for the CSID block not per RDI.
I think you need to move the write outside of this loop too.
> + writel(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
> + csid->base + CSID_BUF_DONE_IRQ_MASK);
> + }
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550
2024-08-16 14:45 ` Bryan O'Donoghue
@ 2024-08-19 13:18 ` Depeng Shao
0 siblings, 0 replies; 107+ messages in thread
From: Depeng Shao @ 2024-08-19 13:18 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hi Bryan,
On 8/16/2024 10:45 PM, Bryan O'Donoghue wrote:
> On 12/08/2024 15:41, Depeng Shao wrote:
>> + for (i = 0; i < MSM_CSID_MAX_SRC_STREAMS; i++)
>> + if (csid->phy.en_vc & BIT(i)) {
>> + writel(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
>> + csid->base + CSID_BUF_DONE_IRQ_CLEAR);
>> + writel(0x1 << IRQ_CMD_CLEAR, csid->base + CSID_IRQ_CMD);
>
> IRQ_CMD_CLEAR is for the CSID block not per RDI.
>
Sure, I will move IRQ_CMD_CLEAR outside of this loop.
> I think you need to move the write outside of this loop too.
>
>> + writel(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
>> + csid->base + CSID_BUF_DONE_IRQ_MASK);
>> + }
>
Yes, this also can be moved to outside of the loop. I will update them.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550
2024-08-12 14:41 ` [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550 Depeng Shao
` (3 preceding siblings ...)
2024-08-16 14:45 ` Bryan O'Donoghue
@ 2024-08-16 14:49 ` Bryan O'Donoghue
2024-08-24 13:19 ` Vladimir Zapolskiy
2024-09-30 9:23 ` Vladimir Zapolskiy
6 siblings, 0 replies; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-16 14:49 UTC (permalink / raw)
To: 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/08/2024 15:41, Depeng Shao wrote:
> + writel(1, csid->base + CSID_TOP_IRQ_CLEAR);
> + writel(1, csid->base + CSID_IRQ_CMD);
CSID_IRQ_CMD bit(0) = CMD_CLEAR
> + writel(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(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
> + csid->base + CSID_BUF_DONE_IRQ_CLEAR);
> + writel(0x1 << IRQ_CMD_CLEAR, csid->base + CSID_IRQ_CMD);
CSID_IRQ_CMD bit(0) = CMD_CLEAR
and again here.
> + writel(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
> + csid->base + CSID_BUF_DONE_IRQ_MASK);
> + }
re: previous comments
1. Please define bits so that'd be
#define CSID_IRQ_CMD_CLEAR BIT(0)
writel(CSID_IRQ_CMD_CLEAR, csid->base + CSID_IRQ_CMD);
There's no value in circumscribing the meaning of bitfields in upstream
code, we just make our own lives easier by having self-documenting code.
TL;DR please name your bits - a blanket statement for the series.
2. And as mentioned above, you don't need to execute that clear n times
in a loop. Just do it once at the top of the routine.
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550
2024-08-12 14:41 ` [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550 Depeng Shao
` (4 preceding siblings ...)
2024-08-16 14:49 ` Bryan O'Donoghue
@ 2024-08-24 13:19 ` Vladimir Zapolskiy
2024-09-30 9:23 ` Vladimir Zapolskiy
6 siblings, 0 replies; 107+ messages in thread
From: Vladimir Zapolskiy @ 2024-08-24 13:19 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 8/12/24 17:41, 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.
>
> The sm8550 also has a new block is named as CSID top, CSID can
> connect to VFE or SFE(Sensor Front End), the connection is controlled
> by CSID top.
>
> 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 | 339 ++++++++++++++++++
> .../platform/qcom/camss/camss-csid-gen3.h | 26 ++
> .../media/platform/qcom/camss/camss-csid.c | 46 ++-
> .../media/platform/qcom/camss/camss-csid.h | 10 +
> drivers/media/platform/qcom/camss/camss.c | 91 +++++
> drivers/media/platform/qcom/camss/camss.h | 2 +
> 7 files changed, 503 insertions(+), 12 deletions(-)
> 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..d96bc126f0a9
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss/camss-csid-gen3.c
> @@ -0,0 +1,339 @@
> +// 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_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_CLEAR(rdi) (0xF4 + 0x10 * (rdi))
> +#define CSID_CSI2_RDIN_IRQ_SET(rdi) (0xF8 + 0x10 * (rdi))
> +
> +#define CSID_TOP_IRQ_STATUS 0x7C
The list of macros shall be sorted by register offset value.
> +#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_REG_UPDATE_CMD 0x18
> +
> +#define CSID_BUF_DONE_IRQ_STATUS 0x8C
> +#define BUF_DONE_IRQ_STATUS_RDI_OFFSET (csid_is_lite(csid) ? 1 : 14)
> +#define CSID_BUF_DONE_IRQ_MASK 0x90
> +#define CSID_BUF_DONE_IRQ_CLEAR 0x94
> +#define CSID_BUF_DONE_IRQ_SET 0x98
> +
> +#define CSI2_RX_CFG0_PHY_SEL_BASE_IDX 1
> +
> +#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_PHY_NUM_SEL 20
> +
> +#define CSID_CSI2_RX_CFG1 0x204
> +#define CSI2_RX_CFG1_ECC_CORRECTION_EN 0
> +#define CSI2_RX_CFG1_VC_MODE 2
> +
> +#define CSID_RDI_CFG0(rdi) (0x500 + 0x100 * (rdi))
> +#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_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_PIX_STORE 10
> +#define RDI_CFG1_PACKING_FORMAT 15
> +
> +#define CSID_RDI_CTRL(rdi) (0x504 + 0x100 * (rdi))
Sorted by register offset please.
> +#define RDI_CTRL_START_CMD 0
> +
> +#define CSID_RDI_IRQ_SUBSAMPLE_PATTERN(rdi) (0x548 + 0x100 * (rdi))
> +#define CSID_RDI_IRQ_SUBSAMPLE_PERIOD(rdi) (0x54C + 0x100 * (rdi))
> +
> +static inline int reg_update_rdi(struct csid_device *csid, int n)
> +{
> + return BIT(n + 4) + BIT(20 + n);
Taking as unshifted bit BIT(4) is RUP and BIT(20) is AUP, add
corresponding macros for them, then
return (... | ...) << n;
> +}
> +#define REG_UPDATE_RDI reg_update_rdi
> +
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550
2024-08-12 14:41 ` [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550 Depeng Shao
` (5 preceding siblings ...)
2024-08-24 13:19 ` Vladimir Zapolskiy
@ 2024-09-30 9:23 ` Vladimir Zapolskiy
2024-09-30 9:38 ` Depeng Shao
6 siblings, 1 reply; 107+ messages in thread
From: Vladimir Zapolskiy @ 2024-09-30 9:23 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:
> 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.
>
> The sm8550 also has a new block is named as CSID top, CSID can
> connect to VFE or SFE(Sensor Front End), the connection is controlled
> by CSID top.
>
> 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>
> @@ -1049,7 +1050,10 @@ static int csid_set_test_pattern(struct csid_device *csid, s32 value)
>
> tg->enabled = !!value;
>
> - return csid->res->hw_ops->configure_testgen_pattern(csid, value);
> + if (hw_ops->configure_testgen_pattern)
> + return -EOPNOTSUPP;
> + else
> + return hw_ops->configure_testgen_pattern(csid, value);
> }
>
> /*
Here you accedentally break the TPG on all platforms and introduce a NULL
pointer dereference, please fix it.
Any generic/non-sm8550 support related changes like the part of this
one shall be split into a stand-alone generic change aside of the added
SM8550 platform support, it will simplify patch reviews and hunting bugs
like the one above.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550
2024-09-30 9:23 ` Vladimir Zapolskiy
@ 2024-09-30 9:38 ` Depeng Shao
0 siblings, 0 replies; 107+ messages in thread
From: Depeng Shao @ 2024-09-30 9:38 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/30/2024 5:23 PM, Vladimir Zapolskiy wrote:
>> @@ -1049,7 +1050,10 @@ static int csid_set_test_pattern(struct
>> csid_device *csid, s32 value)
>> tg->enabled = !!value;
>> - return csid->res->hw_ops->configure_testgen_pattern(csid, value);
>> + if (hw_ops->configure_testgen_pattern)
>> + return -EOPNOTSUPP;
>> + else
>> + return hw_ops->configure_testgen_pattern(csid, value);
>> }
>> /*
>
> Here you accedentally break the TPG on all platforms and introduce a NULL
> pointer dereference, please fix it.
>
> Any generic/non-sm8550 support related changes like the part of this
> one shall be split into a stand-alone generic change aside of the added
> SM8550 platform support, it will simplify patch reviews and hunting bugs
> like the one above.
>
Thanks for catching this. This is indeed a bug which is introduced by
this patch. And I will follow your suggestion to use a stand-alone
generic change for the TPG part.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread
* [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-12 14:41 [PATCH v4 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (11 preceding siblings ...)
2024-08-12 14:41 ` [PATCH 12/13] media: qcom: camss: Add CSID Gen3 support for sm8550 Depeng Shao
@ 2024-08-12 14:41 ` Depeng Shao
2024-08-14 11:13 ` Vladimir Zapolskiy
` (6 more replies)
2024-08-13 12:35 ` [PATCH v4 00/13] media: qcom: camss: Add sm8550 support Bryan O'Donoghue
13 siblings, 7 replies; 107+ 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 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 | 148 ++++++++++++++++++
drivers/media/platform/qcom/camss/camss-vfe.c | 33 ++--
drivers/media/platform/qcom/camss/camss-vfe.h | 1 +
drivers/media/platform/qcom/camss/camss.c | 132 ++++++++++++++++
drivers/media/platform/qcom/camss/camss.h | 2 +
6 files changed, 304 insertions(+), 13 deletions(-)
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..e1c4d25cdc40
--- /dev/null
+++ b/drivers/media/platform/qcom/camss/camss-vfe-780.c
@@ -0,0 +1,148 @@
+// 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 BUS_REG_BASE (vfe_is_lite(vfe) ? 0x200 : 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 BIT(0)
+#define WM_VIR_FRM_EN BIT(1)
+#define WM_CFG_MODE BIT(16)
+#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))
+
+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(WM_CGC_OVERRIDE_ALL, vfe->base + VFE_BUS_WM_CGC_OVERRIDE);
+
+ writel(0x0, vfe->base + VFE_BUS_WM_TEST_BUS_CTRL);
+
+ writel(ALIGN(pix->plane_fmt[0].bytesperline, 16) * pix->height >> 8,
+ vfe->base + VFE_BUS_WM_FRAME_INCR(wm));
+ writel((WM_IMAGE_CFG_0_DEFAULT_WIDTH & 0xFFFF),
+ vfe->base + VFE_BUS_WM_IMAGE_CFG_0(wm));
+ writel(WM_IMAGE_CFG_2_DEFAULT_STRIDE,
+ vfe->base + VFE_BUS_WM_IMAGE_CFG_2(wm));
+ writel(0, vfe->base + VFE_BUS_WM_PACKER_CFG(wm));
+
+ /* no dropped frames, one irq per frame */
+ writel(0, vfe->base + VFE_BUS_WM_FRAMEDROP_PERIOD(wm));
+ writel(1, vfe->base + VFE_BUS_WM_FRAMEDROP_PATTERN(wm));
+ writel(0, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PERIOD(wm));
+ writel(1, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PATTERN(wm));
+
+ writel(1, vfe->base + VFE_BUS_WM_MMU_PREFETCH_CFG(wm));
+ writel(0xFFFFFFFF, vfe->base + VFE_BUS_WM_MMU_PREFETCH_MAX_OFFSET(wm));
+
+ writel(WM_CFG_EN | 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(0, vfe->base + VFE_BUS_WM_CFG(wm));
+}
+
+static void vfe_wm_update(struct vfe_device *vfe, u8 wm, u32 addr,
+ struct vfe_line *line)
+{
+ wm = RDI_WM(wm); /* map to actual WM used (from wm=RDI index) */
+ writel((addr >> 8) & 0xFFFFFFFF, vfe->base + VFE_BUS_WM_IMAGE_ADDR(wm));
+
+ dev_dbg(vfe->camss->dev, "%s wm:%d, image buf addr:0x%x\n",
+ __func__, wm, addr);
+}
+
+static void vfe_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id)
+{
+ int port_id = line_id;
+
+ /* RUP(register update) registers has beem moved to CSID in Titan 780.
+ * Notify the event of trigger RUP.
+ */
+ camss_reg_update(vfe->camss, vfe->id, port_id, false);
+}
+
+static inline void vfe_reg_update_clear(struct vfe_device *vfe,
+ enum vfe_line_id line_id)
+{
+ int port_id = line_id;
+
+ /* RUP(register update) registers has beem moved to CSID in Titan 780.
+ * Notify the event of trigger RUP clear.
+ */
+ camss_reg_update(vfe->camss, vfe->id, port_id, true);
+}
+
+static const struct camss_video_ops vfe_video_ops_780 = {
+ .queue_buffer = vfe_queue_buffer_v2,
+ .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 = {
+ .enable_irq = NULL,
+ .global_reset = NULL,
+ .hw_version = vfe_hw_version,
+ .isr = NULL,
+ .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_v2,
+ .vfe_halt = NULL,
+ .vfe_wm_start = vfe_wm_start,
+ .vfe_wm_stop = vfe_wm_stop,
+ .vfe_buf_done = vfe_buf_done,
+ .vfe_wm_update = vfe_wm_update,
+ .reg_update = vfe_reg_update,
+ .reg_update_clear = vfe_reg_update_clear,
+};
diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
index 71bd55e854bb..507fc7785ac8 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.c
+++ b/drivers/media/platform/qcom/camss/camss-vfe.c
@@ -343,6 +343,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:
{
@@ -674,15 +675,17 @@ int vfe_reset(struct vfe_device *vfe)
{
unsigned long time;
- reinit_completion(&vfe->reset_complete);
+ if (vfe->res->hw_ops->global_reset) {
+ reinit_completion(&vfe->reset_complete);
- vfe->res->hw_ops->global_reset(vfe);
+ vfe->res->hw_ops->global_reset(vfe);
- time = wait_for_completion_timeout(&vfe->reset_complete,
- msecs_to_jiffies(VFE_RESET_TIMEOUT_MS));
- if (!time) {
- dev_err(vfe->camss->dev, "VFE reset timeout\n");
- return -EIO;
+ time = wait_for_completion_timeout(&vfe->reset_complete,
+ msecs_to_jiffies(VFE_RESET_TIMEOUT_MS));
+ if (!time) {
+ dev_err(vfe->camss->dev, "VFE reset timeout\n");
+ return -EIO;
+ }
}
return 0;
@@ -1120,7 +1123,8 @@ void vfe_put(struct vfe_device *vfe)
} else if (vfe->power_count == 1) {
if (vfe->was_streaming) {
vfe->was_streaming = 0;
- vfe->res->hw_ops->vfe_halt(vfe);
+ if (vfe->res->hw_ops->vfe_halt)
+ vfe->res->hw_ops->vfe_halt(vfe);
}
camss_disable_clocks(vfe->nclocks, vfe->clock);
pm_runtime_put_sync(vfe->camss->dev);
@@ -1807,11 +1811,13 @@ int msm_vfe_subdev_init(struct camss *camss, struct vfe_device *vfe,
vfe->irq = ret;
snprintf(vfe->irq_name, sizeof(vfe->irq_name), "%s_%s%d",
dev_name(dev), MSM_VFE_NAME, id);
- ret = devm_request_irq(dev, vfe->irq, vfe->res->hw_ops->isr,
- IRQF_TRIGGER_RISING, vfe->irq_name, vfe);
- if (ret < 0) {
- dev_err(dev, "request_irq failed: %d\n", ret);
- return ret;
+ if (vfe->res->hw_ops->isr) {
+ ret = devm_request_irq(dev, vfe->irq, vfe->res->hw_ops->isr,
+ IRQF_TRIGGER_RISING, vfe->irq_name, vfe);
+ if (ret < 0) {
+ dev_err(dev, "request_irq failed: %d\n", ret);
+ return ret;
+ }
}
/* Clocks */
@@ -1963,6 +1969,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-vfe.h b/drivers/media/platform/qcom/camss/camss-vfe.h
index fcbf4f609129..9dec5bc0d1b1 100644
--- a/drivers/media/platform/qcom/camss/camss-vfe.h
+++ b/drivers/media/platform/qcom/camss/camss-vfe.h
@@ -243,6 +243,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 7ee102948dc4..92a0fa02e415 100644
--- a/drivers/media/platform/qcom/camss/camss.c
+++ b/drivers/media/platform/qcom/camss/camss.c
@@ -1666,6 +1666,125 @@ static const struct camss_subdev_resources csid_res_8550[] = {
}
};
+static const struct camss_subdev_resources vfe_res_8550[] = {
+ /* VFE0 */
+ {
+ .regulators = {},
+ .clock = { "gcc_axi_hf", "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 = { "gcc_axi_hf", "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 = { "gcc_axi_hf", "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 = { "gcc_axi_hf", "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 = { "gcc_axi_hf", "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 = "ahb",
@@ -1846,6 +1965,17 @@ void camss_pm_domain_off(struct camss *camss, int id)
}
}
+void camss_reg_update(struct camss *camss, int hw_id, int port_id, bool is_clear)
+{
+ struct csid_device *csid;
+
+ if (hw_id < camss->res->csid_num) {
+ csid = &(camss->csid[hw_id]);
+
+ csid->res->hw_ops->reg_update(csid, port_id, is_clear);
+ }
+}
+
void camss_buf_done(struct camss *camss, int hw_id, int port_id)
{
struct vfe_device *vfe;
@@ -2668,10 +2798,12 @@ static const struct camss_resources sm8550_resources = {
.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
};
diff --git a/drivers/media/platform/qcom/camss/camss.h b/drivers/media/platform/qcom/camss/camss.h
index d6b6558a82b9..697846e70e78 100644
--- a/drivers/media/platform/qcom/camss/camss.h
+++ b/drivers/media/platform/qcom/camss/camss.h
@@ -157,5 +157,7 @@ int camss_vfe_get(struct camss *camss, int id);
void camss_vfe_put(struct camss *camss, int id);
void camss_delete(struct camss *camss);
void camss_buf_done(struct camss *camss, int hw_id, int port_id);
+void camss_reg_update(struct camss *camss, int hw_id,
+ int port_id, bool is_clear);
#endif /* QC_MSM_CAMSS_H */
--
2.34.1
^ permalink raw reply related [flat|nested] 107+ messages in thread* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-12 14:41 ` [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780 Depeng Shao
@ 2024-08-14 11:13 ` Vladimir Zapolskiy
2024-08-14 13:10 ` Depeng Shao
2024-08-14 16:23 ` Bryan O'Donoghue
` (5 subsequent siblings)
6 siblings, 1 reply; 107+ messages in thread
From: Vladimir Zapolskiy @ 2024-08-14 11:13 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,
please find a few review comments, all asked changes are non-functional.
On 8/12/24 17:41, 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 | 148 ++++++++++++++++++
> drivers/media/platform/qcom/camss/camss-vfe.c | 33 ++--
> drivers/media/platform/qcom/camss/camss-vfe.h | 1 +
> drivers/media/platform/qcom/camss/camss.c | 132 ++++++++++++++++
> drivers/media/platform/qcom/camss/camss.h | 2 +
> 6 files changed, 304 insertions(+), 13 deletions(-)
> 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..e1c4d25cdc40
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss/camss-vfe-780.c
> @@ -0,0 +1,148 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * camss-vfe-780.c
I understand that a file name copied from a previous file and updated,
let's just remove it, it serves no purpose, but adds this unnecessary
work on every next copy.
> + *
> + * 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 BUS_REG_BASE (vfe_is_lite(vfe) ? 0x200 : 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 BIT(0)
> +#define WM_VIR_FRM_EN BIT(1)
> +#define WM_CFG_MODE BIT(16)
> +#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)
Three VFE_BUS_WM_HEADER_* macra above are not used, please remove.
> +
> +#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)
Good to know that there is such a register, but it's not used,
please remove the macro.
> +
> +/* for titan 780, each bus client is hardcoded to a specific path */
> +#define RDI_WM(n) ((vfe_is_lite(vfe) ? 0x0 : 0x17) + (n))
> +
> +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) */
Please move the comment on its own line.
> +
> + /* no clock gating at bus input */
> + writel(WM_CGC_OVERRIDE_ALL, vfe->base + VFE_BUS_WM_CGC_OVERRIDE);
> +
> + writel(0x0, vfe->base + VFE_BUS_WM_TEST_BUS_CTRL);
> +
> + writel(ALIGN(pix->plane_fmt[0].bytesperline, 16) * pix->height >> 8,
> + vfe->base + VFE_BUS_WM_FRAME_INCR(wm));
> + writel((WM_IMAGE_CFG_0_DEFAULT_WIDTH & 0xFFFF),
> + vfe->base + VFE_BUS_WM_IMAGE_CFG_0(wm));
> + writel(WM_IMAGE_CFG_2_DEFAULT_STRIDE,
> + vfe->base + VFE_BUS_WM_IMAGE_CFG_2(wm));
> + writel(0, vfe->base + VFE_BUS_WM_PACKER_CFG(wm));
> +
> + /* no dropped frames, one irq per frame */
> + writel(0, vfe->base + VFE_BUS_WM_FRAMEDROP_PERIOD(wm));
> + writel(1, vfe->base + VFE_BUS_WM_FRAMEDROP_PATTERN(wm));
> + writel(0, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PERIOD(wm));
> + writel(1, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PATTERN(wm));
> +
> + writel(1, vfe->base + VFE_BUS_WM_MMU_PREFETCH_CFG(wm));
> + writel(0xFFFFFFFF, vfe->base + VFE_BUS_WM_MMU_PREFETCH_MAX_OFFSET(wm));
> +
> + writel(WM_CFG_EN | 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) */
Please move the comment on its own line or remove it as obvious one.
> + writel(0, vfe->base + VFE_BUS_WM_CFG(wm));
> +}
> +
> +static void vfe_wm_update(struct vfe_device *vfe, u8 wm, u32 addr,
> + struct vfe_line *line)
> +{
> + wm = RDI_WM(wm); /* map to actual WM used (from wm=RDI index) */
Please move the comment on its own line or remove it as obvious one.
> + writel((addr >> 8) & 0xFFFFFFFF, vfe->base + VFE_BUS_WM_IMAGE_ADDR(wm));
> +
> + dev_dbg(vfe->camss->dev, "%s wm:%d, image buf addr:0x%x\n",
> + __func__, wm, addr);
There will be no confusion in runtime about a source of the debug
message, please remove that __func__ information.
> +}
> +
> +static void vfe_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id)
> +{
> + int port_id = line_id;
> +
> + /* RUP(register update) registers has beem moved to CSID in Titan 780.
Huh, it's unusual to see a network subsystem style comment formatting here.
There is a typo, s/beem/been/
> + * Notify the event of trigger RUP.
> + */
I suppose it would be good enough to remove the comment completely as
an obvious one.
> + camss_reg_update(vfe->camss, vfe->id, port_id, false);
> +}
> +
> +static inline void vfe_reg_update_clear(struct vfe_device *vfe,
> + enum vfe_line_id line_id)
> +{
> + int port_id = line_id;
> +
> + /* RUP(register update) registers has beem moved to CSID in Titan 780.
> + * Notify the event of trigger RUP clear.
> + */
Same as above.
> + camss_reg_update(vfe->camss, vfe->id, port_id, true);
> +}
> +
> +static const struct camss_video_ops vfe_video_ops_780 = {
> + .queue_buffer = vfe_queue_buffer_v2,
> + .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 = {
> + .enable_irq = NULL,
> + .global_reset = NULL,
> + .hw_version = vfe_hw_version,
> + .isr = NULL,
> + .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_v2,
> + .vfe_halt = NULL,
> + .vfe_wm_start = vfe_wm_start,
> + .vfe_wm_stop = vfe_wm_stop,
> + .vfe_buf_done = vfe_buf_done,
> + .vfe_wm_update = vfe_wm_update,
> + .reg_update = vfe_reg_update,
> + .reg_update_clear = vfe_reg_update_clear,
> +};
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
> index 71bd55e854bb..507fc7785ac8 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
> @@ -343,6 +343,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:
> {
> @@ -674,15 +675,17 @@ int vfe_reset(struct vfe_device *vfe)
> {
> unsigned long time;
>
> - reinit_completion(&vfe->reset_complete);
> + if (vfe->res->hw_ops->global_reset) {
> + reinit_completion(&vfe->reset_complete);
>
> - vfe->res->hw_ops->global_reset(vfe);
> + vfe->res->hw_ops->global_reset(vfe);
>
> - time = wait_for_completion_timeout(&vfe->reset_complete,
> - msecs_to_jiffies(VFE_RESET_TIMEOUT_MS));
> - if (!time) {
> - dev_err(vfe->camss->dev, "VFE reset timeout\n");
> - return -EIO;
> + time = wait_for_completion_timeout(&vfe->reset_complete,
> + msecs_to_jiffies(VFE_RESET_TIMEOUT_MS));
> + if (!time) {
> + dev_err(vfe->camss->dev, "VFE reset timeout\n");
> + return -EIO;
> + }
This goes to some other preceding change, since it's unrelated to Titan 780
support, but the latter depends on it.
> }
>
> return 0;
> @@ -1120,7 +1123,8 @@ void vfe_put(struct vfe_device *vfe)
> } else if (vfe->power_count == 1) {
> if (vfe->was_streaming) {
> vfe->was_streaming = 0;
> - vfe->res->hw_ops->vfe_halt(vfe);
> + if (vfe->res->hw_ops->vfe_halt)
> + vfe->res->hw_ops->vfe_halt(vfe);
This goes to some other change, since it's unrelated to Titan 780 support.
> }
> camss_disable_clocks(vfe->nclocks, vfe->clock);
> pm_runtime_put_sync(vfe->camss->dev);
> @@ -1807,11 +1811,13 @@ int msm_vfe_subdev_init(struct camss *camss, struct vfe_device *vfe,
> vfe->irq = ret;
> snprintf(vfe->irq_name, sizeof(vfe->irq_name), "%s_%s%d",
> dev_name(dev), MSM_VFE_NAME, id);
> - ret = devm_request_irq(dev, vfe->irq, vfe->res->hw_ops->isr,
> - IRQF_TRIGGER_RISING, vfe->irq_name, vfe);
> - if (ret < 0) {
> - dev_err(dev, "request_irq failed: %d\n", ret);
> - return ret;
> + if (vfe->res->hw_ops->isr) {
> + ret = devm_request_irq(dev, vfe->irq, vfe->res->hw_ops->isr,
> + IRQF_TRIGGER_RISING, vfe->irq_name, vfe);
> + if (ret < 0) {
> + dev_err(dev, "request_irq failed: %d\n", ret);
> + return ret;
> + }
This change shall be done in a seperate preceding commit, since it's
unrelated to Titan 780 support.
> }
>
> /* Clocks */
> @@ -1963,6 +1969,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-vfe.h b/drivers/media/platform/qcom/camss/camss-vfe.h
> index fcbf4f609129..9dec5bc0d1b1 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe.h
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.h
> @@ -243,6 +243,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 7ee102948dc4..92a0fa02e415 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -1666,6 +1666,125 @@ static const struct camss_subdev_resources csid_res_8550[] = {
> }
> };
>
> +static const struct camss_subdev_resources vfe_res_8550[] = {
> + /* VFE0 */
> + {
> + .regulators = {},
> + .clock = { "gcc_axi_hf", "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 = { "gcc_axi_hf", "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 = { "gcc_axi_hf", "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 = { "gcc_axi_hf", "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 = { "gcc_axi_hf", "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 = "ahb",
> @@ -1846,6 +1965,17 @@ void camss_pm_domain_off(struct camss *camss, int id)
> }
> }
>
> +void camss_reg_update(struct camss *camss, int hw_id, int port_id, bool is_clear)
Please let it be just a declarative 'clear' instead of questioning 'is_clear'.
> +{
> + struct csid_device *csid;
> +
> + if (hw_id < camss->res->csid_num) {
> + csid = &(camss->csid[hw_id]);
> +
> + csid->res->hw_ops->reg_update(csid, port_id, is_clear);
> + }
> +}
> +
Please add the new exported function camss_reg_update() in a separate
preceding commit.
> void camss_buf_done(struct camss *camss, int hw_id, int port_id)
> {
> struct vfe_device *vfe;
> @@ -2668,10 +2798,12 @@ static const struct camss_resources sm8550_resources = {
> .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
> };
>
> diff --git a/drivers/media/platform/qcom/camss/camss.h b/drivers/media/platform/qcom/camss/camss.h
> index d6b6558a82b9..697846e70e78 100644
> --- a/drivers/media/platform/qcom/camss/camss.h
> +++ b/drivers/media/platform/qcom/camss/camss.h
> @@ -157,5 +157,7 @@ int camss_vfe_get(struct camss *camss, int id);
> void camss_vfe_put(struct camss *camss, int id);
> void camss_delete(struct camss *camss);
> void camss_buf_done(struct camss *camss, int hw_id, int port_id);
> +void camss_reg_update(struct camss *camss, int hw_id,
> + int port_id, bool is_clear);
>
> #endif /* QC_MSM_CAMSS_H */
Thank you for the efforts to get support of Titan 780 in the upstream.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-14 11:13 ` Vladimir Zapolskiy
@ 2024-08-14 13:10 ` Depeng Shao
2024-08-14 23:20 ` Vladimir Zapolskiy
0 siblings, 1 reply; 107+ messages in thread
From: Depeng Shao @ 2024-08-14 13:10 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 8/14/2024 7:13 PM, Vladimir Zapolskiy wrote:
> Hi Depeng,
>
> please find a few review comments, all asked changes are non-functional.
>
>> +void camss_reg_update(struct camss *camss, int hw_id, int port_id,
>> bool is_clear)
>
> Please let it be just a declarative 'clear' instead of questioning
> 'is_clear'.
>
>> +{
>> + struct csid_device *csid;
>> +
>> + if (hw_id < camss->res->csid_num) {
>> + csid = &(camss->csid[hw_id]);
>> +
>> + csid->res->hw_ops->reg_update(csid, port_id, is_clear);
>> + }
>> +}
>> +
>
> Please add the new exported function camss_reg_update() in a separate
> preceding commit.
>
>> void camss_buf_done(struct camss *camss, int hw_id, int port_id)
>> {
>> struct vfe_device *vfe;
Thanks for your comments, I will address them in new series.
But I have some concern about above comment, you want to add a separate
commit for camss_reg_update, maybe camss_buf_done also need to do this,
but I guess I will get new comments from Krzysztof if I make a separate
change, Krzysztof posted few comments in v3 series, he asked, "must
organize your patches in logical junks" and the code must have a user.
Please check below comments.
https://lore.kernel.org/all/e1b298df-05da-4881-a628-149a8a625544@kernel.org/
https://lore.kernel.org/all/d0f8b72d-4355-43cd-a5f9-c44aab8147e5@kernel.org/
Or I don't add reg update and buf done functionality in
camss-csid-gen3.c and camss-vfe-780.c firstly, then add them in a later
commit.
Could you please comment on whether this is acceptable? Please also help
to common on if one commit to add them or need two separate commits, one
is for reg update and the other one is for buf done.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-14 13:10 ` Depeng Shao
@ 2024-08-14 23:20 ` Vladimir Zapolskiy
2024-08-15 14:42 ` Depeng Shao
0 siblings, 1 reply; 107+ messages in thread
From: Vladimir Zapolskiy @ 2024-08-14 23: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
Hi Depeng,
On 8/14/24 16:10, Depeng Shao wrote:
> Hi Vladimir,
>
> On 8/14/2024 7:13 PM, Vladimir Zapolskiy wrote:
>> Hi Depeng,
>>
>> please find a few review comments, all asked changes are non-functional.
>>
>
>>> +void camss_reg_update(struct camss *camss, int hw_id, int port_id,
>>> bool is_clear)
>>
>> Please let it be just a declarative 'clear' instead of questioning
>> 'is_clear'.
>>
>>> +{
>>> + struct csid_device *csid;
>>> +
>>> + if (hw_id < camss->res->csid_num) {
>>> + csid = &(camss->csid[hw_id]);
>>> +
>>> + csid->res->hw_ops->reg_update(csid, port_id, is_clear);
>>> + }
>>> +}
>>> +
>>
>> Please add the new exported function camss_reg_update() in a separate
>> preceding commit.
>>
>>> void camss_buf_done(struct camss *camss, int hw_id, int port_id)
>>> {
>>> struct vfe_device *vfe;
>
> Thanks for your comments, I will address them in new series.
>
> But I have some concern about above comment, you want to add a separate
> commit for camss_reg_update, maybe camss_buf_done also need to do this,
> but I guess I will get new comments from Krzysztof if I make a separate
> change, Krzysztof posted few comments in v3 series, he asked, "must
> organize your patches in logical junks" and the code must have a user.
>
> Please check below comments.
>
> https://lore.kernel.org/all/e1b298df-05da-4881-a628-149a8a625544@kernel.org/
>
> https://lore.kernel.org/all/d0f8b72d-4355-43cd-a5f9-c44aab8147e5@kernel.org/
Krzysztof is absolutely right in his two comments.
From what I see there is a difference between his concerns and mine ones
though, Krzysztof points to unused data, which should raise a build time
warning, and I asked to make a separate commit for a non-static function,
I believe it'll be removed by the linker silently...
The potential runtime logic change introduced by camss_reg_update() in the
generic code is not trivial, which opens an option to update/fix it lately
referencing a commit from generic domain rather than platform specific one.
If someone for whatever reasons wants to merge a new generic and shared
camss_reg_update() function within a the platform specific code/commit,
I won't strongly object, let it be merged together then.
>
> Or I don't add reg update and buf done functionality in
> camss-csid-gen3.c and camss-vfe-780.c firstly, then add them in a later
> commit.
>
> Could you please comment on whether this is acceptable? Please also help
> to common on if one commit to add them or need two separate commits, one
> is for reg update and the other one is for buf done.
>
I would prefer to see two more separate commits within non-platform specific
code, however as I stated above if it causes anyone's concerns, including
your own, let it be kept as it is done today. Eventually we do discuss
a non-functional change.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-14 23:20 ` Vladimir Zapolskiy
@ 2024-08-15 14:42 ` Depeng Shao
2024-08-15 14:57 ` Vladimir Zapolskiy
0 siblings, 1 reply; 107+ messages in thread
From: Depeng Shao @ 2024-08-15 14:42 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 8/15/2024 7:20 AM, Vladimir Zapolskiy wrote:
>>
>>>> +void camss_reg_update(struct camss *camss, int hw_id, int port_id,
>>>> bool is_clear)
>>>
>>>> +{
>>>> + struct csid_device *csid;
>>>> +
>>>> + if (hw_id < camss->res->csid_num) {
>>>> + csid = &(camss->csid[hw_id]);
>>>> +
>>>> + csid->res->hw_ops->reg_update(csid, port_id, is_clear);
>>>> + }
>>>> +}
>>>> +
>>>
>>> Please add the new exported function camss_reg_update() in a separate
>>> preceding commit.
>>
>> Thanks for your comments, I will address them in new series.
>>
>> But I have some concern about above comment, you want to add a separate
>> commit for camss_reg_update, maybe camss_buf_done also need to do this,
>> but I guess I will get new comments from Krzysztof if I make a separate
>> change, Krzysztof posted few comments in v3 series, he asked, "must
>> organize your patches in logical junks" and the code must have a user.
>>
>> Please check below comments.
>>
>> https://lore.kernel.org/all/e1b298df-05da-4881-
>> a628-149a8a625544@kernel.org/
>>
>> https://lore.kernel.org/all/d0f8b72d-4355-43cd-a5f9-
>> c44aab8147e5@kernel.org/
>
> Krzysztof is absolutely right in his two comments.
>
> From what I see there is a difference between his concerns and mine ones
> though, Krzysztof points to unused data, which should raise a build time
> warning, and I asked to make a separate commit for a non-static function,
> I believe it'll be removed by the linker silently...
>
> The potential runtime logic change introduced by camss_reg_update() in the
> generic code is not trivial, which opens an option to update/fix it lately
> referencing a commit from generic domain rather than platform specific one.
>
> If someone for whatever reasons wants to merge a new generic and shared
> camss_reg_update() function within a the platform specific code/commit,
> I won't strongly object, let it be merged together then.
>
>>
>> Or I don't add reg update and buf done functionality in
>> camss-csid-gen3.c and camss-vfe-780.c firstly, then add them in a later
>> commit.
>>
>> Could you please comment on whether this is acceptable? Please also help
>> to common on if one commit to add them or need two separate commits, one
>> is for reg update and the other one is for buf done.
>>
>
> I would prefer to see two more separate commits within non-platform
> specific
> code, however as I stated above if it causes anyone's concerns, including
> your own, let it be kept as it is done today. Eventually we do discuss
> a non-functional change.
>
Thanks for the confirmation, even though I add the rup_update and
buf_done function in later commits, it is still called in platform
specific code(camss-vfe-780.c), so I will keep as it is done today.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-15 14:42 ` Depeng Shao
@ 2024-08-15 14:57 ` Vladimir Zapolskiy
2024-08-15 15:43 ` Depeng Shao
0 siblings, 1 reply; 107+ messages in thread
From: Vladimir Zapolskiy @ 2024-08-15 14:57 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/15/24 17:42, Depeng Shao wrote:
> Hi Vladimir,
>
> On 8/15/2024 7:20 AM, Vladimir Zapolskiy wrote:
>
>>>
>>>>> +void camss_reg_update(struct camss *camss, int hw_id, int port_id,
>>>>> bool is_clear)
>>>>
>>>>> +{
>>>>> + struct csid_device *csid;
>>>>> +
>>>>> + if (hw_id < camss->res->csid_num) {
>>>>> + csid = &(camss->csid[hw_id]);
>>>>> +
>>>>> + csid->res->hw_ops->reg_update(csid, port_id, is_clear);
>>>>> + }
>>>>> +}
>>>>> +
>>>>
>>>> Please add the new exported function camss_reg_update() in a separate
>>>> preceding commit.
>
>>>
>>> Thanks for your comments, I will address them in new series.
>>>
>>> But I have some concern about above comment, you want to add a separate
>>> commit for camss_reg_update, maybe camss_buf_done also need to do this,
>>> but I guess I will get new comments from Krzysztof if I make a separate
>>> change, Krzysztof posted few comments in v3 series, he asked, "must
>>> organize your patches in logical junks" and the code must have a user.
>>>
>>> Please check below comments.
>>>
>>> https://lore.kernel.org/all/e1b298df-05da-4881-
>>> a628-149a8a625544@kernel.org/
>>>
>>> https://lore.kernel.org/all/d0f8b72d-4355-43cd-a5f9-
>>> c44aab8147e5@kernel.org/
>>
>> Krzysztof is absolutely right in his two comments.
>>
>> From what I see there is a difference between his concerns and mine ones
>> though, Krzysztof points to unused data, which should raise a build time
>> warning, and I asked to make a separate commit for a non-static function,
>> I believe it'll be removed by the linker silently...
>>
>> The potential runtime logic change introduced by camss_reg_update() in the
>> generic code is not trivial, which opens an option to update/fix it lately
>> referencing a commit from generic domain rather than platform specific one.
>>
>> If someone for whatever reasons wants to merge a new generic and shared
>> camss_reg_update() function within a the platform specific code/commit,
>> I won't strongly object, let it be merged together then.
>>
>>>
>>> Or I don't add reg update and buf done functionality in
>>> camss-csid-gen3.c and camss-vfe-780.c firstly, then add them in a later
>>> commit.
>>>
>>> Could you please comment on whether this is acceptable? Please also help
>>> to common on if one commit to add them or need two separate commits, one
>>> is for reg update and the other one is for buf done.
>>>
>>
>> I would prefer to see two more separate commits within non-platform
>> specific
>> code, however as I stated above if it causes anyone's concerns, including
>> your own, let it be kept as it is done today. Eventually we do discuss
>> a non-functional change.
>>
>
> Thanks for the confirmation, even though I add the rup_update and
> buf_done function in later commits, it is still called in platform
> specific code(camss-vfe-780.c), so I will keep as it is done today.
let it be so.
I have another ask about it, please move new camss_reg_update() out from
camss.c into camss-csid.c, and camss_buf_done() from camss.c into camss-vfe.c
Thank you.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-15 14:57 ` Vladimir Zapolskiy
@ 2024-08-15 15:43 ` Depeng Shao
2024-08-15 21:31 ` Vladimir Zapolskiy
0 siblings, 1 reply; 107+ messages in thread
From: Depeng Shao @ 2024-08-15 15:43 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,
>>
>> Thanks for the confirmation, even though I add the rup_update and
>> buf_done function in later commits, it is still called in platform
>> specific code(camss-vfe-780.c), so I will keep as it is done today.
>
> let it be so.
>
> I have another ask about it, please move new camss_reg_update() out from
> camss.c into camss-csid.c, and camss_buf_done() from camss.c into camss-
> vfe.c
>
The cross direct call has been removed by below commit, so it looks
strange if I add the cross direct call.
media: qcom: camss: Decouple VFE from CSID
https://lore.kernel.org/lkml/20240522154659.510-9-quic_grosikop@quicinc.com/
I use the v4l2_subdev_notify to do the cross communication in v1 and v2
series, but Bryan said, "The subdev notify is I think not the right fit
for this purpose within our driver.".
Then I add an internal notify interface in camss structure, but Bryan
suggested to use direct call, so I add these functions directly in camss.c
https://lore.kernel.org/all/236cfe43-8321-4168-8630-fb9528f581bd@linaro.org/
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-15 15:43 ` Depeng Shao
@ 2024-08-15 21:31 ` Vladimir Zapolskiy
2024-08-16 12:42 ` Depeng Shao
0 siblings, 1 reply; 107+ messages in thread
From: Vladimir Zapolskiy @ 2024-08-15 21:31 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/15/24 18:43, Depeng Shao wrote:
> Hi Vladimir,
>
>>>
>>> Thanks for the confirmation, even though I add the rup_update and
>>> buf_done function in later commits, it is still called in platform
>>> specific code(camss-vfe-780.c), so I will keep as it is done today.
>>
>> let it be so.
>>
>> I have another ask about it, please move new camss_reg_update() out from
>> camss.c into camss-csid.c, and camss_buf_done() from camss.c into camss-
>> vfe.c
>>
>
> The cross direct call has been removed by below commit, so it looks
> strange if I add the cross direct call.
>
> media: qcom: camss: Decouple VFE from CSID
> https://lore.kernel.org/lkml/20240522154659.510-9-quic_grosikop@quicinc.com/
This I don't understand, please elaborate. I don't ask for a "cross direct
call", but you do introduce a CSID specific function in the generic camss.c
and another VFE specific function in the same camss.c
What I ask is just move the current versions of camss_buf_done() and
camss_reg_update() out from camss.c to the files, which are related to the
sub-IP blocks, and of course move the function declarations from camss.h
into camss-vfe.h and camss-csid.h respectively.
If possible there shall be no CSID or VFE specific specific code in camss.c,
and that fact is that it's possible.
> I use the v4l2_subdev_notify to do the cross communication in v1 and v2
> series, but Bryan said, "The subdev notify is I think not the right fit
> for this purpose within our driver.".
As far as I see all of that is irrelevant.
> Then I add an internal notify interface in camss structure, but Bryan
> suggested to use direct call, so I add these functions directly in camss.c
>
> https://lore.kernel.org/all/236cfe43-8321-4168-8630-fb9528f581bd@linaro.org/
>
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-15 21:31 ` Vladimir Zapolskiy
@ 2024-08-16 12:42 ` Depeng Shao
2024-08-20 14:01 ` Vladimir Zapolskiy
0 siblings, 1 reply; 107+ messages in thread
From: Depeng Shao @ 2024-08-16 12:42 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 8/16/2024 5:31 AM, Vladimir Zapolskiy wrote:
> Hi Depeng.
>
> On 8/15/24 18:43, Depeng Shao wrote:
>> Hi Vladimir,
>>
>>>>
>>>> Thanks for the confirmation, even though I add the rup_update and
>>>> buf_done function in later commits, it is still called in platform
>>>> specific code(camss-vfe-780.c), so I will keep as it is done today.
>>>
>>> let it be so.
>>>
>>> I have another ask about it, please move new camss_reg_update() out from
>>> camss.c into camss-csid.c, and camss_buf_done() from camss.c into camss-
>>> vfe.c
>>>
>>
>> The cross direct call has been removed by below commit, so it looks
>> strange if I add the cross direct call.
>>
>> media: qcom: camss: Decouple VFE from CSID
>> https://lore.kernel.org/lkml/20240522154659.510-9-
>> quic_grosikop@quicinc.com/
>
> This I don't understand, please elaborate. I don't ask for a "cross direct
> call", but you do introduce a CSID specific function in the generic camss.c
> and another VFE specific function in the same camss.c
>
CSID calls vfe_get/vfe_put to power up/reset vfe hw in old code, but
above decouple commit removes this cross direct call, this commit has
been merged recently.
> What I ask is just move the current versions of camss_buf_done() and
> camss_reg_update() out from camss.c to the files, which are related to the
> sub-IP blocks, and of course move the function declarations from camss.h
> into camss-vfe.h and camss-csid.h respectively.
>
> If possible there shall be no CSID or VFE specific specific code in
> camss.c,
> and that fact is that it's possible.
>
Yes, I understand what you mean. Let's take camss_buf_done as example,
if we move camss_buf_done to camss-vfe.c, but this function is called in
csid csid driver, so here will have a cross direct call again,
camss_reg_update is same. Since the cross call is removed in above
commit, then it will be strange if I do this again.
So, I moved them to camss.c
>> I use the v4l2_subdev_notify to do the cross communication in v1 and v2
>> series, but Bryan said, "The subdev notify is I think not the right fit
>> for this purpose within our driver.".
>
> As far as I see all of that is irrelevant.
>
>> Then I add an internal notify interface in camss structure, but Bryan
>> suggested to use direct call, so I add these functions directly in
>> camss.c
>>
>> https://lore.kernel.org/all/236cfe43-8321-4168-8630-
>> fb9528f581bd@linaro.org/
>>
>
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-16 12:42 ` Depeng Shao
@ 2024-08-20 14:01 ` Vladimir Zapolskiy
0 siblings, 0 replies; 107+ messages in thread
From: Vladimir Zapolskiy @ 2024-08-20 14: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
Hi Depeng.
On 8/16/24 15:42, Depeng Shao wrote:
> Hi Vladimir,
>
> On 8/16/2024 5:31 AM, Vladimir Zapolskiy wrote:
>> Hi Depeng.
>>
>> On 8/15/24 18:43, Depeng Shao wrote:
>>> Hi Vladimir,
>>>
>>>>>
>>>>> Thanks for the confirmation, even though I add the rup_update and
>>>>> buf_done function in later commits, it is still called in platform
>>>>> specific code(camss-vfe-780.c), so I will keep as it is done today.
>>>>
>>>> let it be so.
>>>>
>>>> I have another ask about it, please move new camss_reg_update() out from
>>>> camss.c into camss-csid.c, and camss_buf_done() from camss.c into camss-
>>>> vfe.c
>>>>
>>>
>>> The cross direct call has been removed by below commit, so it looks
>>> strange if I add the cross direct call.
>>>
>>> media: qcom: camss: Decouple VFE from CSID
>>> https://lore.kernel.org/lkml/20240522154659.510-9-
>>> quic_grosikop@quicinc.com/
>>
>> This I don't understand, please elaborate. I don't ask for a "cross direct
>> call", but you do introduce a CSID specific function in the generic camss.c
>> and another VFE specific function in the same camss.c
>>
>
> CSID calls vfe_get/vfe_put to power up/reset vfe hw in old code, but
> above decouple commit removes this cross direct call, this commit has
> been merged recently.
Apparently I was imprecise, this is not the thing, which I don't understand,
for me it was the wording of "cross direct call".
>> What I ask is just move the current versions of camss_buf_done() and
>> camss_reg_update() out from camss.c to the files, which are related to the
>> sub-IP blocks, and of course move the function declarations from camss.h
>> into camss-vfe.h and camss-csid.h respectively.
>>
>> If possible there shall be no CSID or VFE specific specific code in
>> camss.c,
>> and that fact is that it's possible.
>>
>
> Yes, I understand what you mean. Let's take camss_buf_done as example,
> if we move camss_buf_done to camss-vfe.c, but this function is called in
> csid csid driver, so here will have a cross direct call again,
> camss_reg_update is same. Since the cross call is removed in above
> commit, then it will be strange if I do this again.
It might be strange, but what I ask is to make the code way less convoluted.
> So, I moved them to camss.c
I'm still missing the essence of having two layers of indirection instead
of just one. Previous code was a function call from csid to vfe, now it's
csid to camss to vfe, I don't understand why there is a need to introduce
just an additional layer, it greatly complicates the code, also it slightly
drops the performance.
Previously there was no 'struct vfe_device *' or 'struct csid_device *'
types in the generic camss.c, now these "new" types leaked from camss-csid.h
and camss-vfe.h into camss.c, and the reason why remains unknown.
Okay, please ignore this one review request, let it be kept as is for a while.
As a side note, generally there might be various reasons to revert the code
changes or to return to the previous logic.
Thank you.
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-12 14:41 ` [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780 Depeng Shao
2024-08-14 11:13 ` Vladimir Zapolskiy
@ 2024-08-14 16:23 ` Bryan O'Donoghue
2024-08-15 13:33 ` Depeng Shao
2024-08-15 0:16 ` Bryan O'Donoghue
` (4 subsequent siblings)
6 siblings, 1 reply; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-14 16:23 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 15:41, 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 | 148 ++++++++++++++++++
> drivers/media/platform/qcom/camss/camss-vfe.c | 33 ++--
> drivers/media/platform/qcom/camss/camss-vfe.h | 1 +
> drivers/media/platform/qcom/camss/camss.c | 132 ++++++++++++++++
> drivers/media/platform/qcom/camss/camss.h | 2 +
> 6 files changed, 304 insertions(+), 13 deletions(-)
> 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..e1c4d25cdc40
> --- /dev/null
> +++ b/drivers/media/platform/qcom/camss/camss-vfe-780.c
> @@ -0,0 +1,148 @@
> +// 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 BUS_REG_BASE (vfe_is_lite(vfe) ? 0x200 : 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 BIT(0)
> +#define WM_VIR_FRM_EN BIT(1)
> +#define WM_CFG_MODE BIT(16)
> +#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))
> +
> +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(WM_CGC_OVERRIDE_ALL, vfe->base + VFE_BUS_WM_CGC_OVERRIDE);
> +
> + writel(0x0, vfe->base + VFE_BUS_WM_TEST_BUS_CTRL);
> +
> + writel(ALIGN(pix->plane_fmt[0].bytesperline, 16) * pix->height >> 8,
> + vfe->base + VFE_BUS_WM_FRAME_INCR(wm));
> + writel((WM_IMAGE_CFG_0_DEFAULT_WIDTH & 0xFFFF),
> + vfe->base + VFE_BUS_WM_IMAGE_CFG_0(wm));
> + writel(WM_IMAGE_CFG_2_DEFAULT_STRIDE,
> + vfe->base + VFE_BUS_WM_IMAGE_CFG_2(wm));
> + writel(0, vfe->base + VFE_BUS_WM_PACKER_CFG(wm));
> +
> + /* no dropped frames, one irq per frame */
> + writel(0, vfe->base + VFE_BUS_WM_FRAMEDROP_PERIOD(wm));
> + writel(1, vfe->base + VFE_BUS_WM_FRAMEDROP_PATTERN(wm));
> + writel(0, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PERIOD(wm));
> + writel(1, vfe->base + VFE_BUS_WM_IRQ_SUBSAMPLE_PATTERN(wm));
> +
> + writel(1, vfe->base + VFE_BUS_WM_MMU_PREFETCH_CFG(wm));
> + writel(0xFFFFFFFF, vfe->base + VFE_BUS_WM_MMU_PREFETCH_MAX_OFFSET(wm));
> +
> + writel(WM_CFG_EN | 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(0, vfe->base + VFE_BUS_WM_CFG(wm));
> +}
> +
> +static void vfe_wm_update(struct vfe_device *vfe, u8 wm, u32 addr,
> + struct vfe_line *line)
> +{
> + wm = RDI_WM(wm); /* map to actual WM used (from wm=RDI index) */
> + writel((addr >> 8) & 0xFFFFFFFF, vfe->base + VFE_BUS_WM_IMAGE_ADDR(wm));
> +
> + dev_dbg(vfe->camss->dev, "%s wm:%d, image buf addr:0x%x\n",
> + __func__, wm, addr);
> +}
> +
> +static void vfe_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id)
> +{
> + int port_id = line_id;
> +
> + /* RUP(register update) registers has beem moved to CSID in Titan 780.
> + * Notify the event of trigger RUP.
> + */
> + camss_reg_update(vfe->camss, vfe->id, port_id, false);
> +}
> +
> +static inline void vfe_reg_update_clear(struct vfe_device *vfe,
> + enum vfe_line_id line_id)
> +{
> + int port_id = line_id;
> +
> + /* RUP(register update) registers has beem moved to CSID in Titan 780.
> + * Notify the event of trigger RUP clear.
> + */
> + camss_reg_update(vfe->camss, vfe->id, port_id, true);
> +}
> +
> +static const struct camss_video_ops vfe_video_ops_780 = {
> + .queue_buffer = vfe_queue_buffer_v2,
> + .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 = {
> + .enable_irq = NULL,
> + .global_reset = NULL,
> + .hw_version = vfe_hw_version,
> + .isr = NULL,
> + .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_v2,
> + .vfe_halt = NULL,
> + .vfe_wm_start = vfe_wm_start,
> + .vfe_wm_stop = vfe_wm_stop,
> + .vfe_buf_done = vfe_buf_done,
> + .vfe_wm_update = vfe_wm_update,
> + .reg_update = vfe_reg_update,
> + .reg_update_clear = vfe_reg_update_clear,
> +};
> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.c b/drivers/media/platform/qcom/camss/camss-vfe.c
> index 71bd55e854bb..507fc7785ac8 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe.c
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.c
> @@ -343,6 +343,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:
> {
> @@ -674,15 +675,17 @@ int vfe_reset(struct vfe_device *vfe)
> {
> unsigned long time;
>
> - reinit_completion(&vfe->reset_complete);
> + if (vfe->res->hw_ops->global_reset) {
> + reinit_completion(&vfe->reset_complete);
>
> - vfe->res->hw_ops->global_reset(vfe);
> + vfe->res->hw_ops->global_reset(vfe);
>
> - time = wait_for_completion_timeout(&vfe->reset_complete,
> - msecs_to_jiffies(VFE_RESET_TIMEOUT_MS));
> - if (!time) {
> - dev_err(vfe->camss->dev, "VFE reset timeout\n");
> - return -EIO;
> + time = wait_for_completion_timeout(&vfe->reset_complete,
> + msecs_to_jiffies(VFE_RESET_TIMEOUT_MS));
> + if (!time) {
> + dev_err(vfe->camss->dev, "VFE reset timeout\n");
> + return -EIO;
> + }
Per my comment on the CSID - this feels like a fix you are introducing
here in the guise of a silicon add.
Please break it up.
If you have a number of fixes to core functionality they need to be
1. Granular and individual
2. Indivdually scrutable with their own patch and descritption
3. git cherry-pickable
4. Have a Fixes tag
5. And be cc'd to stable@vger.kernel.org
Can't accept either the fixes or the silicon add if the two live mixed
up in one patch.
> }
>
> return 0;
> @@ -1120,7 +1123,8 @@ void vfe_put(struct vfe_device *vfe)
> } else if (vfe->power_count == 1) {
> if (vfe->was_streaming) {
> vfe->was_streaming = 0;
> - vfe->res->hw_ops->vfe_halt(vfe);
> + if (vfe->res->hw_ops->vfe_halt)
> + vfe->res->hw_ops->vfe_halt(vfe);
Similar comment.
> }
> camss_disable_clocks(vfe->nclocks, vfe->clock);
> pm_runtime_put_sync(vfe->camss->dev);
> @@ -1807,11 +1811,13 @@ int msm_vfe_subdev_init(struct camss *camss, struct vfe_device *vfe,
> vfe->irq = ret;
> snprintf(vfe->irq_name, sizeof(vfe->irq_name), "%s_%s%d",
> dev_name(dev), MSM_VFE_NAME, id);
> - ret = devm_request_irq(dev, vfe->irq, vfe->res->hw_ops->isr,
> - IRQF_TRIGGER_RISING, vfe->irq_name, vfe);
> - if (ret < 0) {
> - dev_err(dev, "request_irq failed: %d\n", ret);
> - return ret;
> + if (vfe->res->hw_ops->isr) {
And again.
> + ret = devm_request_irq(dev, vfe->irq, vfe->res->hw_ops->isr,
> + IRQF_TRIGGER_RISING, vfe->irq_name, vfe);
> + if (ret < 0) {
> + dev_err(dev, "request_irq failed: %d\n", ret);
> + return ret;
> + }
> }
>
> /* Clocks */
> @@ -1963,6 +1969,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-vfe.h b/drivers/media/platform/qcom/camss/camss-vfe.h
> index fcbf4f609129..9dec5bc0d1b1 100644
> --- a/drivers/media/platform/qcom/camss/camss-vfe.h
> +++ b/drivers/media/platform/qcom/camss/camss-vfe.h
> @@ -243,6 +243,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 7ee102948dc4..92a0fa02e415 100644
> --- a/drivers/media/platform/qcom/camss/camss.c
> +++ b/drivers/media/platform/qcom/camss/camss.c
> @@ -1666,6 +1666,125 @@ static const struct camss_subdev_resources csid_res_8550[] = {
> }
> };
>
> +static const struct camss_subdev_resources vfe_res_8550[] = {
> + /* VFE0 */
> + {
> + .regulators = {},
> + .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb_clk", "vfe0_fast_ahb",
> + "vfe0", "cpas_vfe0", "camnoc_axi" },
Should the camnoc AXI clock go here or in the CSID ?
> + .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 = { "gcc_axi_hf", "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 = { "gcc_axi_hf", "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 = { "gcc_axi_hf", "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 = { "gcc_axi_hf", "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 },
I realise you're specifying all of the operating points here but the
clock only needs to appear once i.e.
1 x 300 MHz
1 x 400 MHz
1 x 480 MHz
etc.
> + { 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 = "ahb",
> @@ -1846,6 +1965,17 @@ void camss_pm_domain_off(struct camss *camss, int id)
> }
> }
>
> +void camss_reg_update(struct camss *camss, int hw_id, int port_id, bool is_clear)
> +{
> + struct csid_device *csid;
> +
> + if (hw_id < camss->res->csid_num) {
Does this cause do anything ? Is it just defensive programming ? Can the
hw_id index exceed the number of CSIDs defined and if so why ?
Smells wrong.
> + csid = &(camss->csid[hw_id]);
> +
> + csid->res->hw_ops->reg_update(csid, port_id, is_clear);
> + }
> +}
> +
> void camss_buf_done(struct camss *camss, int hw_id, int port_id)
> {
> struct vfe_device *vfe;
> @@ -2668,10 +2798,12 @@ static const struct camss_resources sm8550_resources = {
> .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
> };
>
> diff --git a/drivers/media/platform/qcom/camss/camss.h b/drivers/media/platform/qcom/camss/camss.h
> index d6b6558a82b9..697846e70e78 100644
> --- a/drivers/media/platform/qcom/camss/camss.h
> +++ b/drivers/media/platform/qcom/camss/camss.h
> @@ -157,5 +157,7 @@ int camss_vfe_get(struct camss *camss, int id);
> void camss_vfe_put(struct camss *camss, int id);
> void camss_delete(struct camss *camss);
> void camss_buf_done(struct camss *camss, int hw_id, int port_id);
> +void camss_reg_update(struct camss *camss, int hw_id,
> + int port_id, bool is_clear);
>
> #endif /* QC_MSM_CAMSS_H */
All in all good work, looks like good progress and thanks for sticking
with your submissions.
Please follow up on the points raised.
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-14 16:23 ` Bryan O'Donoghue
@ 2024-08-15 13:33 ` Depeng Shao
2024-08-15 16:16 ` Bryan O'Donoghue
0 siblings, 1 reply; 107+ messages in thread
From: Depeng Shao @ 2024-08-15 13:33 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hi Bryan,
On 8/15/2024 12:23 AM, Bryan O'Donoghue wrote:
>> @@ -674,15 +675,17 @@ int vfe_reset(struct vfe_device *vfe)
>> {
>> unsigned long time;
>> - reinit_completion(&vfe->reset_complete);
>> + if (vfe->res->hw_ops->global_reset) {
>> + reinit_completion(&vfe->reset_complete);
>> - vfe->res->hw_ops->global_reset(vfe);
>> + vfe->res->hw_ops->global_reset(vfe);
>> - time = wait_for_completion_timeout(&vfe->reset_complete,
>> - msecs_to_jiffies(VFE_RESET_TIMEOUT_MS));
>> - if (!time) {
>> - dev_err(vfe->camss->dev, "VFE reset timeout\n");
>> - return -EIO;
>> + time = wait_for_completion_timeout(&vfe->reset_complete,
>> + msecs_to_jiffies(VFE_RESET_TIMEOUT_MS));
>> + if (!time) {
>> + dev_err(vfe->camss->dev, "VFE reset timeout\n");
>> + return -EIO;
>> + }
>
> Per my comment on the CSID - this feels like a fix you are introducing
> here in the guise of a silicon add.
>
> Please break it up.
>
> If you have a number of fixes to core functionality they need to be
>
> 1. Granular and individual
> 2. Indivdually scrutable with their own patch and descritption
> 3. git cherry-pickable
> 4. Have a Fixes tag
> 5. And be cc'd to stable@vger.kernel.org
>
> Can't accept either the fixes or the silicon add if the two live mixed
> up in one patch.
>
This isn't a bug fix, adding a null pointer checking just because vfe780
doesn't have enable_irq/global_reset/isr/vfe_halt hw_ops, so adding the
null checking for these hw_ops in this patch and adding them in one patch.
The original code doesn't have any bug.
>> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.h b/drivers/
>> media/platform/qcom/camss/camss-vfe.h
>> index fcbf4f609129..9dec5bc0d1b1 100644
>> --- a/drivers/media/platform/qcom/camss/camss-vfe.h
>> +++ b/drivers/media/platform/qcom/camss/camss-vfe.h
>> @@ -243,6 +243,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 7ee102948dc4..92a0fa02e415 100644
>> --- a/drivers/media/platform/qcom/camss/camss.c
>> +++ b/drivers/media/platform/qcom/camss/camss.c
>> @@ -1666,6 +1666,125 @@ static const struct camss_subdev_resources
>> csid_res_8550[] = {
>> }
>> };
>> +static const struct camss_subdev_resources vfe_res_8550[] = {
>> + /* VFE0 */
>> + {
>> + .regulators = {},
>> + .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb_clk",
>> "vfe0_fast_ahb",
>> + "vfe0", "cpas_vfe0", "camnoc_axi" },
>
> Should the camnoc AXI clock go here or in the CSID ?
>
camnoc is responsible for ddr writing, so it is needed for the WM in vfe.
>> + /* VFE4 lite */
>> + {
>> + .regulators = {},
>> + .clock = { "gcc_axi_hf", "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 },
>
> I realise you're specifying all of the operating points here but the
> clock only needs to appear once i.e.
>
> 1 x 300 MHz
> 1 x 400 MHz
> 1 x 480 MHz
>
> etc.
>
Sure, will update in next series.
>> + { 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
>> + }
>> + },
>> +};
>> +void camss_reg_update(struct camss *camss, int hw_id, int port_id,
>> bool is_clear)
>> +{
>> + struct csid_device *csid;
>> +
>> + if (hw_id < camss->res->csid_num) {
>
> Does this cause do anything ? Is it just defensive programming ? Can the
> hw_id index exceed the number of CSIDs defined and if so why ?
>
> Smells wrong.
>
It is just a defensive programming, just like some null pointer checking.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-15 13:33 ` Depeng Shao
@ 2024-08-15 16:16 ` Bryan O'Donoghue
0 siblings, 0 replies; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-15 16:16 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 15/08/2024 14:33, Depeng Shao wrote:
> Hi Bryan,
>
> On 8/15/2024 12:23 AM, Bryan O'Donoghue wrote:
>
>>> @@ -674,15 +675,17 @@ int vfe_reset(struct vfe_device *vfe)
>>> {
>>> unsigned long time;
>>> - reinit_completion(&vfe->reset_complete);
>>> + if (vfe->res->hw_ops->global_reset) {
>>> + reinit_completion(&vfe->reset_complete);
>>> - vfe->res->hw_ops->global_reset(vfe);
>>> + vfe->res->hw_ops->global_reset(vfe);
>>> - time = wait_for_completion_timeout(&vfe->reset_complete,
>>> - msecs_to_jiffies(VFE_RESET_TIMEOUT_MS));
>>> - if (!time) {
>>> - dev_err(vfe->camss->dev, "VFE reset timeout\n");
>>> - return -EIO;
>>> + time = wait_for_completion_timeout(&vfe->reset_complete,
>>> + msecs_to_jiffies(VFE_RESET_TIMEOUT_MS));
>>> + if (!time) {
>>> + dev_err(vfe->camss->dev, "VFE reset timeout\n");
>>> + return -EIO;
>>> + }
>>
>> Per my comment on the CSID - this feels like a fix you are introducing
>> here in the guise of a silicon add.
>>
>> Please break it up.
>>
>> If you have a number of fixes to core functionality they need to be
>>
>> 1. Granular and individual
>> 2. Indivdually scrutable with their own patch and descritption
>> 3. git cherry-pickable
>> 4. Have a Fixes tag
>> 5. And be cc'd to stable@vger.kernel.org
>>
>> Can't accept either the fixes or the silicon add if the two live mixed
>> up in one patch.
>>
>
> This isn't a bug fix, adding a null pointer checking just because vfe780
> doesn't have enable_irq/global_reset/isr/vfe_halt hw_ops, so adding the
> null checking for these hw_ops in this patch and adding them in one patch.
> The original code doesn't have any bug.
Right but you could just have
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,
}
Instead of having a bunch of special cases in the top level code.
>
>>> diff --git a/drivers/media/platform/qcom/camss/camss-vfe.h b/drivers/
>>> media/platform/qcom/camss/camss-vfe.h
>>> index fcbf4f609129..9dec5bc0d1b1 100644
>>> --- a/drivers/media/platform/qcom/camss/camss-vfe.h
>>> +++ b/drivers/media/platform/qcom/camss/camss-vfe.h
>>> @@ -243,6 +243,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 7ee102948dc4..92a0fa02e415 100644
>>> --- a/drivers/media/platform/qcom/camss/camss.c
>>> +++ b/drivers/media/platform/qcom/camss/camss.c
>>> @@ -1666,6 +1666,125 @@ static const struct camss_subdev_resources
>>> csid_res_8550[] = {
>>> }
>>> };
>>> +static const struct camss_subdev_resources vfe_res_8550[] = {
>>> + /* VFE0 */
>>> + {
>>> + .regulators = {},
>>> + .clock = { "gcc_axi_hf", "cpas_ahb", "cpas_fast_ahb_clk",
>>> "vfe0_fast_ahb",
>>> + "vfe0", "cpas_vfe0", "camnoc_axi" },
>>
>> Should the camnoc AXI clock go here or in the CSID ?
>>
>
> camnoc is responsible for ddr writing, so it is needed for the WM in vfe.
Right, I don't recall if you specified the clock for CSID and VFE but
just for the record it should appear in only the one block.. VFE sounds
good to me.
>
>
>>> + /* VFE4 lite */
>>> + {
>>> + .regulators = {},
>>> + .clock = { "gcc_axi_hf", "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 },
>>
>> I realise you're specifying all of the operating points here but the
>> clock only needs to appear once i.e.
>>
>> 1 x 300 MHz
>> 1 x 400 MHz
>> 1 x 480 MHz
>>
>> etc.
>>
>
> Sure, will update in next series.
>
>>> + { 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
>>> + }
>>> + },
>>> +};
>
>>> +void camss_reg_update(struct camss *camss, int hw_id, int port_id,
>>> bool is_clear)
>>> +{
>>> + struct csid_device *csid;
>>> +
>>> + if (hw_id < camss->res->csid_num) {
>>
>> Does this cause do anything ? Is it just defensive programming ? Can
>> the hw_id index exceed the number of CSIDs defined and if so why ?
>>
>> Smells wrong.
>>
>
> It is just a defensive programming, just like some null pointer checking.
Right so, please drop then. We require the indexes to be in range in
order to merge, our job is to make sure this is so.
Lets just reason about the code and make sure the indexes are right.
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-12 14:41 ` [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780 Depeng Shao
2024-08-14 11:13 ` Vladimir Zapolskiy
2024-08-14 16:23 ` Bryan O'Donoghue
@ 2024-08-15 0:16 ` Bryan O'Donoghue
2024-08-15 14:24 ` Depeng Shao
2024-08-15 0:25 ` Bryan O'Donoghue
` (3 subsequent siblings)
6 siblings, 1 reply; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-15 0:16 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 15:41, Depeng Shao wrote:
> +static void vfe_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id)
> +{
> + int port_id = line_id;
> +
> + /* RUP(register update) registers has beem moved to CSID in Titan 780.
> + * Notify the event of trigger RUP.
> + */
> + camss_reg_update(vfe->camss, vfe->id, port_id, false);
> +}
> +
> +static inline void vfe_reg_update_clear(struct vfe_device *vfe,
> + enum vfe_line_id line_id)
> +{
> + int port_id = line_id;
> +
> + /* RUP(register update) registers has beem moved to CSID in Titan 780.
> + * Notify the event of trigger RUP clear.
> + */
> + camss_reg_update(vfe->camss, vfe->id, port_id, true);
> +}
Hmm, so another thought here.
camss_reg_update() is not an accurate name -> camss_rup_update() because
in this case we only update the RUP register, not the AUP or MUP.
reg is an abbreviation for register - but RUP has a defined meaning in
the camera namespace i.e. RUP = register update and its job is to latch
shadow registers to real registers.
camss_rup_update() please.
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-15 0:16 ` Bryan O'Donoghue
@ 2024-08-15 14:24 ` Depeng Shao
0 siblings, 0 replies; 107+ messages in thread
From: Depeng Shao @ 2024-08-15 14:24 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, bryan.odonoghue, mchehab,
robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hi Bryan,
>> +
>> +static inline void vfe_reg_update_clear(struct vfe_device *vfe,
>> + enum vfe_line_id line_id)
>> +{
>> + int port_id = line_id;
>> +
>> + /* RUP(register update) registers has beem moved to CSID in Titan
>> 780.
>> + * Notify the event of trigger RUP clear.
>> + */
>> + camss_reg_update(vfe->camss, vfe->id, port_id, true);
>> +}
>
> Hmm, so another thought here.
>
> camss_reg_update() is not an accurate name -> camss_rup_update() because
> in this case we only update the RUP register, not the AUP or MUP.
>
> reg is an abbreviation for register - but RUP has a defined meaning in
> the camera namespace i.e. RUP = register update and its job is to latch
> shadow registers to real registers.
>
> camss_rup_update() please.
>
Yes, you are right, the rup_update is reasonable, I will update it in
next version patch.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-12 14:41 ` [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780 Depeng Shao
` (2 preceding siblings ...)
2024-08-15 0:16 ` Bryan O'Donoghue
@ 2024-08-15 0:25 ` Bryan O'Donoghue
2024-08-15 14:21 ` Depeng Shao
2024-08-19 11:05 ` Bryan O'Donoghue
` (2 subsequent siblings)
6 siblings, 1 reply; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-15 0:25 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 15:41, Depeng Shao wrote:
> +void camss_reg_update(struct camss *camss, int hw_id, int port_id, bool is_clear)
> +{
> + struct csid_device *csid;
> +
> + if (hw_id < camss->res->csid_num) {
> + csid = &(camss->csid[hw_id]);
> +
> + csid->res->hw_ops->reg_update(csid, port_id, is_clear);
> + }
> +}
The naming here doesn't make the action clear
hw_ops->rup_update(csid, port, clear);
"is_clear" is not required since the type is a bool the "is" is implied
in the the logical state so just "clear" will do.
But re: my previous comment on having the ISR do the clear as is done in
the VFE 480, I don't think this is_clear parameter is warranted.
We want the calling function to request the rup_update() for the
rup_update() function to wait on completion and the ISR() to do the
clear once the RUP interrupt has been raised.
At least I think that's how it should work - could you please experiment
with your code for the flow - as it appears to match the VFE 480 logic.
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-15 0:25 ` Bryan O'Donoghue
@ 2024-08-15 14:21 ` Depeng Shao
2024-08-15 16:17 ` Bryan O'Donoghue
2024-09-29 1:28 ` Depeng Shao
0 siblings, 2 replies; 107+ messages in thread
From: Depeng Shao @ 2024-08-15 14:21 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hi Bryan,
On 8/15/2024 8:25 AM, Bryan O'Donoghue wrote:
> On 12/08/2024 15:41, Depeng Shao wrote:
>> +void camss_reg_update(struct camss *camss, int hw_id, int port_id,
>> bool is_clear)
>> +{
>> + struct csid_device *csid;
>> +
>> + if (hw_id < camss->res->csid_num) {
>> + csid = &(camss->csid[hw_id]);
>> +
>> + csid->res->hw_ops->reg_update(csid, port_id, is_clear);
>> + }
>> +}
>
> The naming here doesn't make the action clear
>
> hw_ops->rup_update(csid, port, clear);
>
> "is_clear" is not required since the type is a bool the "is" is implied
> in the the logical state so just "clear" will do.
>
> But re: my previous comment on having the ISR do the clear as is done in
> the VFE 480, I don't think this is_clear parameter is warranted.
>
> We want the calling function to request the rup_update() for the
> rup_update() function to wait on completion and the ISR() to do the
> clear once the RUP interrupt has been raised.
>
> At least I think that's how it should work - could you please experiment
> with your code for the flow - as it appears to match the VFE 480 logic.
>
Thanks for catching this, I forget to add the rup irq, so this logic is
also missed. I have tried it just now, the logic works good, will add it
in next version patch.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-15 14:21 ` Depeng Shao
@ 2024-08-15 16:17 ` Bryan O'Donoghue
2024-09-29 1:28 ` Depeng Shao
1 sibling, 0 replies; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-15 16:17 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 15/08/2024 15:21, Depeng Shao wrote:
> Thanks for catching this, I forget to add the rup irq, so this logic is
> also missed. I have tried it just now, the logic works good, will add it
> in next version patch.
Cool.
Thanks for sticking with this.
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-15 14:21 ` Depeng Shao
2024-08-15 16:17 ` Bryan O'Donoghue
@ 2024-09-29 1:28 ` Depeng Shao
2024-09-29 23:57 ` Bryan O'Donoghue
1 sibling, 1 reply; 107+ messages in thread
From: Depeng Shao @ 2024-09-29 1:28 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hi Bryan,
On 8/15/2024 10:21 PM, Depeng Shao wrote:
> Hi Bryan,
>
> On 8/15/2024 8:25 AM, Bryan O'Donoghue wrote:
>> On 12/08/2024 15:41, Depeng Shao wrote:
>>> +void camss_reg_update(struct camss *camss, int hw_id, int port_id,
>>> bool is_clear)
>>> +{
>>> + struct csid_device *csid;
>>> +
>>> + if (hw_id < camss->res->csid_num) {
>>> + csid = &(camss->csid[hw_id]);
>>> +
>>> + csid->res->hw_ops->reg_update(csid, port_id, is_clear);
>>> + }
>>> +}
>>
>> The naming here doesn't make the action clear
>>
>> hw_ops->rup_update(csid, port, clear);
>>
The register name in SWI is IFE_0_TOP_REG_UPDATE_CMD in SM8250 platform,
and it is CSID0_RUP_AUP_CMD in SM8550, so it isn't only RUP, and AUP is
also updated, so maybe the original name reg_update is better. This is
what VFE 480 driver is using.
>> "is_clear" is not required since the type is a bool the "is" is
>> implied in the the logical state so just "clear" will do.
>>
>> But re: my previous comment on having the ISR do the clear as is done
>> in the VFE 480, I don't think this is_clear parameter is warranted.
>>
>> We want the calling function to request the rup_update() for the
>> rup_update() function to wait on completion and the ISR() to do the
>> clear once the RUP interrupt has been raised.
>>
>> At least I think that's how it should work - could you please
>> experiment with your code for the flow - as it appears to match the
>> VFE 480 logic.
>>
>
> Thanks for catching this, I forget to add the rup irq, so this logic is
> also missed. I have tried it just now, the logic works good, will add it
> in next version patch.
>
I go through the code again, and find we don't do the wait for
completion in VFE 480 driver, this is just used in VFE gen1 driver and
just during disabling port.
Here, what I tried is clearing rup_aup when receiving the rup irq.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-09-29 1:28 ` Depeng Shao
@ 2024-09-29 23:57 ` Bryan O'Donoghue
2024-09-30 5:37 ` Depeng Shao
0 siblings, 1 reply; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-09-29 23:57 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
On 29/09/2024 02:28, Depeng Shao wrote:
>>>
>>
>> Thanks for catching this, I forget to add the rup irq, so this logic
>> is also missed. I have tried it just now, the logic works good, will
>> add it in next version patch.
>>
>
> I go through the code again, and find we don't do the wait for
> completion in VFE 480 driver, this is just used in VFE gen1 driver and
> just during disabling port.
Right but, we _should_ wait for completion there, the fact we don't is a
bug.
One context issues a command to take an action and another context in
this case an ISR has to fire for that action to be complete.
Therefore we _should_ wait_for_completion() in the initiating context
and timeout if it exceeds a reasonable timeout.
Granted, we've "dropped the ball" in 480 you're right, it needs to be
fixed and will be but, please in your submission do the right thing.
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-09-29 23:57 ` Bryan O'Donoghue
@ 2024-09-30 5:37 ` Depeng Shao
0 siblings, 0 replies; 107+ messages in thread
From: Depeng Shao @ 2024-09-30 5:37 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hi Bryan,
On 9/30/2024 7:57 AM, Bryan O'Donoghue wrote:
> On 29/09/2024 02:28, Depeng Shao wrote:
>>>>
>>>
>>> Thanks for catching this, I forget to add the rup irq, so this logic
>>> is also missed. I have tried it just now, the logic works good, will
>>> add it in next version patch.
>>>
>>
>> I go through the code again, and find we don't do the wait for
>> completion in VFE 480 driver, this is just used in VFE gen1 driver and
>> just during disabling port.
>
> Right but, we _should_ wait for completion there, the fact we don't is a
> bug.
>
> One context issues a command to take an action and another context in
> this case an ISR has to fire for that action to be complete.
>
> Therefore we _should_ wait_for_completion() in the initiating context
> and timeout if it exceeds a reasonable timeout.
>
> Granted, we've "dropped the ball" in 480 you're right, it needs to be
> fixed and will be but, please in your submission do the right thing.
>
Qualcomm downstream camera driver use the rup to move the req to a list
to maintenance a state machine. If we don't get rup then we will enter
bubble state.
But we are downplaying this process now due to AUP, and the bubble
processing has been disabled in latest code base, since we think the
buffer must be filled to the given address if we have configured the AUP
and got buf done irq.
And this per frame wait_for_completion flow isn't exist in whole camss
code, and current camss driver just use buf done irq to trigger the per
frame flow.
E.g.,
irqreturn_t vfe_irq()
{
if (rup_irq)
reg_update_clear();
if (buf_done_irq) {
vfe_wm_update();
reg_update(); --> We can't do wait_for_completion at here in irq
context
vb2_buffer_done();
}
}
Just VFE gen1 driver use this wait_for_complete in vfe_disable_output,
and this flow has been removed in vfe gen2(camss-vfe.c), so looks like
we don't need to add this wait_for_completion support and also can
remove below code in camss-vfe-480.c
vfe_isr_reg_update()
{
if (output->wait_reg_update) {
output->wait_reg_update = 0;
complete(&output->reg_update);
}
}
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-12 14:41 ` [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780 Depeng Shao
` (3 preceding siblings ...)
2024-08-15 0:25 ` Bryan O'Donoghue
@ 2024-08-19 11:05 ` Bryan O'Donoghue
2024-08-19 13:07 ` Depeng Shao
2024-08-21 11:11 ` Vladimir Zapolskiy
2024-08-27 13:16 ` Bryan O'Donoghue
6 siblings, 1 reply; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-19 11:05 UTC (permalink / raw)
To: 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/08/2024 15:41, Depeng Shao wrote:
> +#define VFE_BUS_WM_CFG(n) (BUS_REG_BASE + 0x200 + (n) * 0x100)
<snip>
> +#define RDI_WM(n) ((vfe_is_lite(vfe) ? 0x0 : 0x17) + (n))
> +
> +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) */
OK so one more point here.
The non-lite VFE has I think in the case of sm8550 twenty seven
different bus clients.
The above code takes a given index - take the example of index 0 meaning
RDI0 and
1. Determines if is_lite() is true deriving a jump of 0 or 0x17
2. Uses this index as a further offset to functions such as
VFE_BUS_WM_CFG(n)
3. In no way articulates which bus client is which.
So for a non lite case -> RDI0 is bus client # 23
The code we have for CAMSS just assumes RDI is the only client we are
programming - which I'm not proposing to change for now, however the
code is very not obvious in what it is doing here.
This BTW isn't a criticism of what you've done here but, even though I
have access to the registers in front of me, I had to spend about 30
minutes looking up and verifying these offsets.
That's not sustainable.
Could you please add a comment which details what each index relates to.
/*
* Bus client mapping
*
* 0 = VID_Y ?
* 1 = VID_C
* .. etc
* .. etc
* 23 = RDI0
* 24 = RDI1
*/
I'll try to apply a similar level of index documentation for existing
upstream submissions so that working out client mappings is less tedious
and will be requiring these mappings for new VFE silicon enabling code
upstream.
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-19 11:05 ` Bryan O'Donoghue
@ 2024-08-19 13:07 ` Depeng Shao
0 siblings, 0 replies; 107+ messages in thread
From: Depeng Shao @ 2024-08-19 13:07 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel,
Yongsheng Li
Hi Bryan,
On 8/19/2024 7:05 PM, Bryan O'Donoghue wrote:
> On 12/08/2024 15:41, Depeng Shao wrote:
>> +#define VFE_BUS_WM_CFG(n) (BUS_REG_BASE + 0x200 + (n) * 0x100)
>
> <snip>
>
>> +#define RDI_WM(n) ((vfe_is_lite(vfe) ? 0x0 : 0x17) + (n))
>> +
>> +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) */
>
> OK so one more point here.
>
> The non-lite VFE has I think in the case of sm8550 twenty seven
> different bus clients.
>
> The above code takes a given index - take the example of index 0 meaning
> RDI0 and
>
> 1. Determines if is_lite() is true deriving a jump of 0 or 0x17
> 2. Uses this index as a further offset to functions such as
> VFE_BUS_WM_CFG(n)
> 3. In no way articulates which bus client is which.
>
> So for a non lite case -> RDI0 is bus client # 23
>
> The code we have for CAMSS just assumes RDI is the only client we are
> programming - which I'm not proposing to change for now, however the
> code is very not obvious in what it is doing here.
>
> This BTW isn't a criticism of what you've done here but, even though I
> have access to the registers in front of me, I had to spend about 30
> minutes looking up and verifying these offsets.
>
> That's not sustainable.
>
> Could you please add a comment which details what each index relates to.
>
> /*
> * Bus client mapping
> *
> * 0 = VID_Y ?
> * 1 = VID_C
> * .. etc
> * .. etc
> * 23 = RDI0
> * 24 = RDI1
> */
>
> I'll try to apply a similar level of index documentation for existing
> upstream submissions so that working out client mappings is less tedious
> and will be requiring these mappings for new VFE silicon enabling code
> upstream.
>
Sure, I will add the comment for the bus client mapping in next version
patch.
But the comment will occupy too many lines, I will fold the comment, e.g.,
/*
* Bus client mapping
*
* Full VFE:
* 0 = VID_Y, 1 = VID_C, 2 = VID 4:1, 3 = VID 16:1, 4 = DISP Y, 5 =
DISP C, 6 = DISP 4:1,
* 7 = DISP 16:1, 8 = FD_Y, 9 = FD_C, ...
* ...
* 23 = RDI0, 24 = RDI1, 25 = RDI2, 26 = LTM STATS
*
* VFE LITE:
* 0 = RDI0, 1 = RDI1, 2 = RDI3, 4 = RDI4
*/
Since the full VFE has many ports, can we just add comment for the RDI
client?
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-12 14:41 ` [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780 Depeng Shao
` (4 preceding siblings ...)
2024-08-19 11:05 ` Bryan O'Donoghue
@ 2024-08-21 11:11 ` Vladimir Zapolskiy
2024-08-24 13:31 ` Vladimir Zapolskiy
2024-08-27 13:16 ` Bryan O'Donoghue
6 siblings, 1 reply; 107+ messages in thread
From: Vladimir Zapolskiy @ 2024-08-21 11:11 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 8/12/24 17:41, 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>
> ---
<snip>
> +
> +static void vfe_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id)
> +{
> + int port_id = line_id;
> +
> + /* RUP(register update) registers has beem moved to CSID in Titan 780.
> + * Notify the event of trigger RUP.
> + */
> + camss_reg_update(vfe->camss, vfe->id, port_id, false);
> +}
> +
> +static inline void vfe_reg_update_clear(struct vfe_device *vfe,
> + enum vfe_line_id line_id)
> +{
> + int port_id = line_id;
Once I said that the comment with a typo can be removed from these two
functions, however the functions can be removed, since they are trivial,
use camss_reg_update(vfe->camss, vfe->id, port_id, ...) directly in the code.
> +
> + /* RUP(register update) registers has beem moved to CSID in Titan 780.
> + * Notify the event of trigger RUP clear.
> + */
> + camss_reg_update(vfe->camss, vfe->id, port_id, true);
> +}
> +
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-21 11:11 ` Vladimir Zapolskiy
@ 2024-08-24 13:31 ` Vladimir Zapolskiy
0 siblings, 0 replies; 107+ messages in thread
From: Vladimir Zapolskiy @ 2024-08-24 13:31 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 8/21/24 14:11, Vladimir Zapolskiy wrote:
> On 8/12/24 17:41, 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>
>> ---
>
> <snip>
>
>> +
>> +static void vfe_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id)
>> +{
>> + int port_id = line_id;
>> +
>> + /* RUP(register update) registers has beem moved to CSID in Titan 780.
>> + * Notify the event of trigger RUP.
>> + */
>> + camss_reg_update(vfe->camss, vfe->id, port_id, false);
>> +}
>> +
>> +static inline void vfe_reg_update_clear(struct vfe_device *vfe,
>> + enum vfe_line_id line_id)
>> +{
>> + int port_id = line_id;
>
> Once I said that the comment with a typo can be removed from these two
> functions, however the functions can be removed, since they are trivial,
> use camss_reg_update(vfe->camss, vfe->id, port_id, ...) directly in the code.
>
I see that these new vfe_reg_update() and vfe_reg_update_clear() are
callback functions now, so, without making a step back, now it will not
be straightforward to get rid of one more level of indirection.
Just remove the comments then.
>> +
>> + /* RUP(register update) registers has beem moved to CSID in Titan 780.
>> + * Notify the event of trigger RUP clear.
>> + */
>> + camss_reg_update(vfe->camss, vfe->id, port_id, true);
>> +}
>> +
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780
2024-08-12 14:41 ` [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780 Depeng Shao
` (5 preceding siblings ...)
2024-08-21 11:11 ` Vladimir Zapolskiy
@ 2024-08-27 13:16 ` Bryan O'Donoghue
6 siblings, 0 replies; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-27 13:16 UTC (permalink / raw)
To: 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/08/2024 15:41, Depeng Shao wrote:
> +static void vfe_reg_update(struct vfe_device *vfe, enum vfe_line_id line_id)
> +{
> + int port_id = line_id;
> +
> + /* RUP(register update) registers has beem moved to CSID in Titan 780.
> + * Notify the event of trigger RUP.
> + */
> + camss_reg_update(vfe->camss, vfe->id, port_id, false);
> +}
> +
> +static inline void vfe_reg_update_clear(struct vfe_device *vfe,
> + enum vfe_line_id line_id)
> +{
> + int port_id = line_id;
> +
> + /* RUP(register update) registers has beem moved to CSID in Titan 780.
> + * Notify the event of trigger RUP clear.
> + */
> + camss_reg_update(vfe->camss, vfe->id, port_id, true);
> +}
I think I tend to agree with Vlad here, that this is a needless layer of
wrappering.
I'm not sure that's exactly what you guys where talking about but, I
rebased my x1e80100 stuff on top of your stuff
https://git.codelinaro.org/bryan.odonoghue/kernel/-/tree/linux-next-24-08-15-x1e80100-camss-debufsoff-cleanup?ref_type=heads
and anyway the above wrapper didn't make alot of sense to me.
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread
* Re: [PATCH v4 00/13] media: qcom: camss: Add sm8550 support
2024-08-12 14:41 [PATCH v4 00/13] media: qcom: camss: Add sm8550 support Depeng Shao
` (12 preceding siblings ...)
2024-08-12 14:41 ` [PATCH 13/13] media: qcom: camss: Add support for VFE hardware version Titan 780 Depeng Shao
@ 2024-08-13 12:35 ` Bryan O'Donoghue
2024-08-13 12:42 ` Depeng Shao
13 siblings, 1 reply; 107+ messages in thread
From: Bryan O'Donoghue @ 2024-08-13 12:35 UTC (permalink / raw)
To: Depeng Shao, rfoss, todor.too, mchehab, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel
On 12/08/2024 15:41, Depeng Shao wrote:
> v4:
> - Update dt-bindings based on comments - Krzysztof, bod, Vladimir
> - Move common code into csid core and vfe core driver - bod
> - Remove *_relaxed in the csid and vfe drivers - Krzysztof
> - Reorganize patches in logical junks, make sure that new added
> structures have users in current patch - Krzysztof
> - Remove notify function and add new functions in camss for buf done
> and reg update - bod
> - Remove custom code to get csid base - bod
> - Remove ISR function in vfe780 driver since it is never fired - bod
> - Move csid_top_base to camss structure since we only have one csid
> top block, and just need to get base once for csid top
> - Add Vladimir's RB
> - Remove prerequisite-patch-id in the cover letter since the changes
> have been merged
> - Add dtsi patch link for reference - Krzysztof
> https://lore.kernel.org/all/20240807123333.2056518-1-quic_depengs@quicinc.com/
> - Link to v3: https://lore.kernel.org/all/20240709160656.31146-1-quic_depengs@quicinc.com/
>
> 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
>
> ---
@Depeng.
Can you please fix the following checkpatch splats.
scripts/checkpatch.pl --strict *.patch
total: 0 errors, 0 warnings, 0 checks, 20 lines checked
0001-media-qcom-camss-csiphy-3ph-Fix-trivial-indentation-.patch has no
obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 589 lines checked
0002-media-qcom-camss-csiphy-3ph-Remove-redundant-PHY-ini.patch has no
obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 40 lines checked
0003-media-qcom-camss-csiphy-3ph-Rename-struct.patch has no obvious
style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 49 lines checked
0004-media-qcom-camss-csiphy-Add-an-init-callback-to-CSI-.patch has no
obvious style problems and is ready for submission.
total: 0 errors, 0 warnings, 0 checks, 82 lines checked
0005-media-qcom-camss-csiphy-3ph-Move-CSIPHY-variables-to.patch has no
obvious style problems and is ready for submission.
CHECK: Macro argument 'offset' may be better as '(offset)' to avoid
precedence issues
#33: FILE: drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c:45:
+#define CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(offset, n) (offset + 0x4 * (n))
CHECK: Macro argument 'offset' may be better as '(offset)' to avoid
precedence issues
#38: FILE: drivers/media/platform/qcom/camss/camss-csiphy-3ph-1-0.c:49:
+#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(offset, n) ((offset + 0xb0) +
0x4 * (n))
total: 0 errors, 0 warnings, 2 checks, 157 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or
--fix-inplace.
0006-media-qcom-camss-csiphy-3ph-Use-an-offset-variable-t.patch has
style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#19:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 517 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or
--fix-inplace.
0007-dt-bindings-media-camss-Add-qcom-sm8550-camss-bindin.patch has
style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
CHECK: Alignment should match open parenthesis
#255: FILE: drivers/media/platform/qcom/camss/camss-csid.c:616:
+ dev_info(csid->camss->dev, "CSID:%d HW Version = %u.%u.%u\n",
+ csid->id, hw_gen, hw_rev, hw_step);
total: 0 errors, 0 warnings, 1 checks, 289 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or
--fix-inplace.
0008-media-qcom-camss-csid-Move-common-code-into-csid-cor.patch has
style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
CHECK: braces {} should be used on all arms of this statement
#677: FILE: drivers/media/platform/qcom/camss/camss-vfe.c:470:
+ if (output->buf[index]) {
[...]
+ } else
[...]
CHECK: Unbalanced braces around else statement
#682: FILE: drivers/media/platform/qcom/camss/camss-vfe.c:475:
+ } else
CHECK: Alignment should match open parenthesis
#775: FILE: drivers/media/platform/qcom/camss/camss-vfe.c:568:
+ if (output->state == VFE_OUTPUT_ON &&
+ output->gen2.active_num < 2) {
total: 0 errors, 0 warnings, 3 checks, 885 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or
--fix-inplace.
0009-media-qcom-camss-vfe-Move-common-code-into-vfe-core.patch has style
problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
total: 0 errors, 0 warnings, 0 checks, 67 lines checked
0010-media-qcom-camss-Add-sm8550-compatible.patch has no obvious style
problems and is ready for submission.
0010-media-qcom-camss-Add-sm8550-compatible.patch:6: drvier ==> driver
total: 0 errors, 0 warnings, 0 checks, 253 lines checked
0011-media-qcom-camss-csiphy-3ph-Add-Gen2-v2.1.2-two-phas.patch has no
obvious style problems and is ready for submission.
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#42:
new file mode 100644
CHECK: Please use a blank line after function/struct/union/enum declarations
#146: FILE: drivers/media/platform/qcom/camss/camss-csid-gen3.c:100:
+}
+#define REG_UPDATE_RDI reg_update_rdi
CHECK: Alignment should match open parenthesis
#337: FILE: drivers/media/platform/qcom/camss/camss-csid-gen3.c:291:
+ writel(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
+ csid->base + CSID_BUF_DONE_IRQ_CLEAR);
CHECK: Alignment should match open parenthesis
#340: FILE: drivers/media/platform/qcom/camss/camss-csid-gen3.c:294:
+ writel(BIT(BUF_DONE_IRQ_STATUS_RDI_OFFSET + i),
+ csid->base + CSID_BUF_DONE_IRQ_MASK);
CHECK: Please don't use multiple blank lines
#412: FILE: drivers/media/platform/qcom/camss/camss-csid-gen3.h:21:
+
+
CHECK: Unnecessary parentheses around camss->vfe[hw_id]
#643: FILE: drivers/media/platform/qcom/camss/camss.c:1854:
+ vfe = &(camss->vfe[hw_id]);
total: 0 errors, 1 warnings, 5 checks, 607 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or
--fix-inplace.
0012-media-qcom-camss-Add-CSID-Gen3-support-for-sm8550.patch has style
problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#37:
new file mode 100644
CHECK: Alignment should match open parenthesis
#219: FILE: drivers/media/platform/qcom/camss/camss-vfe.c:684:
+ time = wait_for_completion_timeout(&vfe->reset_complete,
+ msecs_to_jiffies(VFE_RESET_TIMEOUT_MS));
CHECK: Unnecessary parentheses around camss->csid[hw_id]
#415: FILE: drivers/media/platform/qcom/camss/camss.c:1973:
+ csid = &(camss->csid[hw_id]);
total: 0 errors, 1 warnings, 2 checks, 388 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or
--fix-inplace.
0013-media-qcom-camss-Add-support-for-VFE-hardware-versio.patch has
style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS.
---
bod
^ permalink raw reply [flat|nested] 107+ messages in thread* Re: [PATCH v4 00/13] media: qcom: camss: Add sm8550 support
2024-08-13 12:35 ` [PATCH v4 00/13] media: qcom: camss: Add sm8550 support Bryan O'Donoghue
@ 2024-08-13 12:42 ` Depeng Shao
0 siblings, 0 replies; 107+ messages in thread
From: Depeng Shao @ 2024-08-13 12:42 UTC (permalink / raw)
To: Bryan O'Donoghue, rfoss, todor.too, mchehab, robh, krzk+dt,
conor+dt
Cc: linux-arm-msm, linux-media, devicetree, linux-kernel, kernel
Hi Bryan,
On 8/13/2024 8:35 PM, Bryan O'Donoghue wrote:
>
> @Depeng.
>
> Can you please fix the following checkpatch splats.
>
> scripts/checkpatch.pl --strict *.patch
>
Thanks for the reminder, I didn't add --strict before. I will make sure
add --strict option for the new version series.
Thanks,
Depeng
^ permalink raw reply [flat|nested] 107+ messages in thread