On 1/16/26 3:54 PM, Luca Weiss wrote:
> On Fri Jan 16, 2026 at 2:59 PM CET, Konrad Dybcio wrote:
>> On 1/16/26 2:38 PM, Luca Weiss wrote:
>>> Enable the CCI I2C busses and add nodes for the EEPROMs found on the
>>> camera that are connected there.
>>>
>>> Signed-off-by: Luca Weiss <[email protected]>
>>> ---
>>> arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 50
>>> ++++++++++++++++++++++++
>>> 1 file changed, 50 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>>> b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>>> index 7629ceddde2a..c4a706e945ba 100644
>>> --- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>>> +++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>>> @@ -529,6 +529,56 @@ vreg_l11f: ldo11 {
>>> };
>>> };
>>>
>>> +&cci0 {
>>> + status = "okay";
>>> +};
>>> +
>>> +&cci0_i2c0 {
>>> + /* Main cam: Sony IMX896 @ 0x1a */
>>> +
>>> + eeprom@50 {
>>> + compatible = "puya,p24c128f", "atmel,24c128";
>>> + reg = <0x50>;
>>> + vcc-supply = <&vreg_l6p>;
>>> + read-only;
>>> + };
>>> +
>>> + /* Dongwoon DW9784 VCM/OIS @ 0x72 */
>>> +};
>>> +
>>> +
>>> +&cci0_i2c1 {
>>> + /* Awinic AW86017 VCM @ 0x0c */
>>> + /* UW cam: OmniVision OV13B10 @ 0x36 */
>>
>> There's a driver for this one!
>
> Yep! Already got patches to add the required regulators & devicetree
> support to the driver, but since I've got zero on CAMSS so far, I
> couldn't test it more than reading chip ID.
That means the digital part works.. I'd say it's a good enough
indicator
>>> +
>>> + eeprom@52 {
>>> + compatible = "puya,p24c128f", "atmel,24c128";
>>> + reg = <0x52>;
>>> + vcc-supply = <&vreg_l6p>;
>>> + read-only;
>>> + };
>>> +};
>>> +
>>> +&cci1 {
>>> + /* cci1_i2c0 is not used for CCI */
>>> + pinctrl-0 = <&cci1_1_default>;
>>> + pinctrl-1 = <&cci1_1_sleep>;
>>
>> Let's keep them per-bus-subnode so we don't have to override it
>
> I don't see any upstream example of that, would the pinctrl work
> correctly with that?
Hmm.. I assumed it would.. and I assumed we do have examples but
ma-a-aybe they got stuck somewhere in the review purgatory?
If you'd be inclined to test that, you can add a pr_err() to e.g.
msm_pinmux_set_mux() and observe whether that changes as you
interact with the sensor over i2c
> While this isn't necessarily pretty like that, it does work :)
It's the right thing from the hw description standpoint.. we have
a huuuge amount of peripherals that fight for the same sets of pins
(which is part of the reason why you can't turn on all 30-some QUPs
by default, and depending on the function+QUPindex combo the pin
requirements differ)
Konrad
