[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fad5cb33-0e7c-499b-bad7-bbdacca8076a@packett.cool>
Date: Tue, 16 Sep 2025 17:08:44 -0300
From: Val Packett <val@...kett.cool>
To: André Apitzsch <git@...tzsch.eu>,
Sakari Ailus <sakari.ailus@...ux.intel.com>
Cc: Mauro Carvalho Chehab <mchehab@...nel.org>, Rob Herring
<robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, devicetree@...r.kernel.org,
Daniel Scally <djrscally@...il.com>, ~postmarketos/upstreaming@...ts.sr.ht,
phone-devel@...r.kernel.org, linux-media@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 7/7] media: i2c: dw9719: Fix power on/off sequence
On 9/15/25 5:48 PM, André Apitzsch wrote:
> Hi Sakari,
>
> @Val, please see below.
>
> Am Montag, dem 18.08.2025 um 07:44 +0000 schrieb Sakari Ailus:
>> Hi André,
>>
>> On Sun, Aug 17, 2025 at 07:09:26PM +0200, André Apitzsch via B4 Relay
>> wrote:
>>> u64 val;
>>> int ret;
>>> int err;
>>> @@ -109,13 +116,15 @@ static int dw9719_power_up(struct
>>> dw9719_device *dw9719, bool detect)
>>> if (ret)
>>> return ret;
>>>
>>> - /* Jiggle SCL pin to wake up device */
>>> - reg_pwr = (dw9719->model == DW9718S) ? DW9718S_PD :
>>> DW9719_CONTROL;
>>> - cci_write(dw9719->regmap, reg_pwr, DW9719_SHUTDOWN, &ret);
>>> - fsleep(100);
>>> + /*
>>> + * Need 100us to transition from SHUTDOWN to STANDBY.
>>> + * Jiggle the SCL pin to wake up the device (even when the
>>> regulator
>>> + * is shared) and wait double the time to be sure, then
>>> retry the write.
>> Why double? Isn't the datasheet correct when it comes to the power-on
>> sequence?
>>
> I haven't noticed any problems during power-up of DW9761. However,
> according to the commit message, there seems be an issue with DW9718S.
> But I don't own the device and cannot test it.
>
> Maybe Val can provided some additional information.
I haven't had access to the datasheet for the DW9718S, so this was all
deduced experimentally. By "to be sure" I meant that I literally raised
the timeout "just in case", not based on actual issues.
The actually important change was expecting the failure on the write and
not erroring out.
Thanks,
~val
Powered by blists - more mailing lists