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
