[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <a6c6c701-eb45-47db-936f-b02fc260ce51@oss.qualcomm.com>
Date: Fri, 3 Oct 2025 13:03:10 +0200
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: Kieran Bingham <kieran.bingham@...asonboard.com>,
André Apitzsch <git@...tzsch.eu>,
Bjorn Andersson <andersson@...nel.org>,
Bryan O'Donoghue <bryan.odonoghue@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Daniel Scally <djrscally@...il.com>,
Griffin Kroah-Hartman <griffin.kroah@...rphone.com>,
Konrad Dybcio <konradybcio@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Rob Herring <robh@...nel.org>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
Wolfram Sang <wsa@...nel.org>, devicetree@...r.kernel.org
Cc: linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org
Subject: Re: [PATCH 3/4] arm64: dts: qcom: qcm6490-fairphone-fp5: Enable CCI
pull-up
On 10/3/25 12:35 PM, Kieran Bingham wrote:
> Quoting Konrad Dybcio (2025-10-02 13:45:49)
>> On 10/2/25 12:15 PM, Griffin Kroah-Hartman wrote:
>>> Enable vreg_l6p which is used as a pull-up for the CCI busses, to make
>>> sure I2C communication works as expected.
>>>
>>> Signed-off-by: Griffin Kroah-Hartman <griffin.kroah@...rphone.com>
>>> ---
>>
>> Makes me wonder if we should maybe extend the CCI definition
>> (or maybe the common i2c-bus binding?) to accept an external
>> pull-up supply, as this is a common problem.. (+Bryan, Wolfram)
>
> I'm a little confused about terminology here. To me CCI is the
> communiation protocol (how to write the registers on the i2c bus). But
> here' we're talking about 'pulling up' a cci bus ?
CCI is unfortunately also the name of the I2C controller housed within
the camera subsystem on qc platforms and we're talking about pulling
up sda/scl lanes
Konrad
>
> Is this actually impacting the bus - or is it more that it's /powering/
> the camera and VCM both simultaneously (which is what happens on the RPi
> cameras)
>
> My curiosity lies in the fact that indeed we somehow need to be able to
> coordinate the power relationship between multiple devices which ...
> while independent for configuration - they do impact each other. I.e. if
> you power on the camera and it simultaneously powers on the VCM - you
> get the VCM jumping position if it's not also configured, so I
> anticipate various bits of complexities here if they are all powered by
> the same line.
>
> I don't think a camera module should always be powered on for a phone
> running on a battery - perhaps on this device the sensors have a
> separate power down control ?
>
> --
> Kieran
>
>> We could then shut down the regulator when cameras are not
>> in use, preserving some trace amounts of power.
>>
>> Or maybe L6P is already used as a pull-up supply for more things
>> onboard and should be always-on either way? Could you please
>> check that, Griffin?
>>
>> Konrad
>>
>>> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
>>> index e115b6a52b299ef663ccfb614785f8f89091f39d..2dd2c452592aa6b0ac826f19eb9cb1a8b90cee47 100644
>>> --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
>>> +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
>>> @@ -749,6 +749,8 @@ vreg_l6p: ldo6 {
>>> regulator-name = "vreg_l6p";
>>> regulator-min-microvolt = <1700000>;
>>> regulator-max-microvolt = <1904000>;
>>> + /* Pull-up for CCI I2C busses */
>>> + regulator-always-on;
>>> };
>>>
>>> vreg_l7p: ldo7 {
>>>
Powered by blists - more mailing lists