Re: [PATCH v4 3/6] media: qcom: camss: csiphy-3ph: Add Gen2 v1.1 two-phase MIPI CSI-2 DPHY init

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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@xxxxxxxxxx>
---
Reviewed-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>

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




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux