Messages in this thread | | | Date | Thu, 9 Nov 2023 20:24:39 +0100 | Subject | Re: [PATCH v4 3/6] media: qcom: camss: csiphy-3ph: Add Gen2 v1.1 two-phase MIPI CSI-2 DPHY init | From | Konrad Dybcio <> |
| |
On 11/9/23 18:11, Bryan O'Donoghue wrote: > On 09/11/2023 13:55, Konrad Dybcio wrote: >> >> >> On 11/9/23 12:30, Bryan O'Donoghue wrote: >>> Add a PHY configuration sequence for the sc8280xp which uses a Qualcomm >>> Gen 2 version 1.1 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: Bryan O'Donoghue <bryan.odonoghue@linaro.org> >>> --- >> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> >> >> Aside from initialization, looks like the reset seq should be more >> complex: >> >> https://git.codelinaro.org/clo/la/platform/vendor/opensource/camera-kernel/-/blob/LA.AU.1.3.7-02900-gen3_gvmgh.0/drivers/cam_sensor_module/cam_csiphy/include/cam_csiphy_1_1_hwreg.h?ref_type=tags#L39-45 >> >> https://git.codelinaro.org/clo/la/platform/vendor/opensource/camera-kernel/-/blob/LA.AU.1.3.7-02900-gen3_gvmgh.0/drivers/cam_sensor_module/cam_csiphy/cam_csiphy_core.c#L133-154 >> >> similarly for the "common regs" that seem to extend the init seq >> >> https://git.codelinaro.org/clo/la/platform/vendor/opensource/camera-kernel/-/blob/LA.AU.1.3.7-02900-gen3_gvmgh.0/drivers/cam_sensor_module/cam_csiphy/cam_csiphy_core.c#L491-527 >> >> Konrad > > So.. > > https://git.codelinaro.org/clo/la/platform/vendor/opensource/camera-kernel/-/blob/LA.AU.1.3.7-02900-gen3_gvmgh.0/drivers/cam_sensor_module/cam_csiphy/include/cam_csiphy_1_1_hwreg.h?ref_type=tags#L39 > > static struct csiphy_reg_t csiphy_reset_reg_1_1[] = { > {0x0814, 0x00, 0x05, CSIPHY_LANE_ENABLE}, // this is interesting > // powers off lanemask > // seems like a good > // idea to me > {0x0818, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS}, [1] > {0x081C, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS}, [2] > {0x0800, 0x01, 0x01, CSIPHY_DEFAULT_PARAMS}, // this we already > {0x0800, 0x00, 0x00, CSIPHY_DEFAULT_PARAMS}, // do right now > }; > > [1] [2] I don't see why you need that and I'd imagine the reset drives these values to zero anyway.. it should as I read the reg docs, I'd guess this is a reset sequence that comes out of a Si test bench. Since it's there on shipped devices, I'd skew towards including it, maybe some chips with this block had an erratum wrt the reset value
> > The 0x814 warrants an investigation - i.e. can we add it across platforms without breaking existing setups. > > I'll kick that to a separate - one LOC "series", so we can take our time validating if it has any unexpected side-effects across our various platforms. Sure, that's what I had in mind
Konrad
| |