On 07/08/2024 14:08, Depeng Shao wrote:
Hi Vladimir,
On 8/5/2024 5:26 AM, Vladimir Zapolskiy wrote:
Hi Bryan,
On 8/1/24 11:16, Bryan O'Donoghue wrote:
On 01/08/2024 00:43, Vladimir Zapolskiy wrote:
+ ret = csiphy->res->hw_ops->init(csiphy);
Here.
What name would make more sense to you ?
according to the implementation the .init() call just fills some data in
memory, so I believe this could be handled at build time, if it's done
carefully enough...
This camss-csiphy-3ph-1-0.c is reused by many platforms, the old
platforms have same CSI_COMMON_CTR register offset, their offset are
0x800, but some new platforms may have different CSI_COMMON_CTR register
offset, for example, the CSI_COMMON_CTR register offset is 0x1000 in
sm8550, then we need to add new file to support the new csiphy HW, e.g.,
camss-csiphy-3ph-2-0.c, so Bryan asked me to develop the CSIPHY driver
based on his changes, then we just need few code to enable new CSIPHY.
Regarding the hw_ops->init interface, since it fills HW register
configurations and HW register offset, then maybe, it also can be called
as HW operation.
And looks like we can't move it to camss-csiphy.c since it does platform
specific operation and it is related to the registers.
Please feel free to share other comments if you don't agree with it.
Thanks.
Thanks,
Depeng
So, I agree the phy init data could be obtained via resource structs
but, rather than add yet more patches to this series, I'd say we can
make the move to a separate resource struct pointer at a later date.
Lets drop this patch and @Depeng we can then do
+ regs->offset = 0x800;
media: qcom: camss: csiphy-3ph: Use an offset variable to find common
control regs
As a bonus that's one less patch for this series which @ 13 patches is
already large.
---
bod
