Received-SPF: pass (google.com: domain of linux-kernel+bounces-120138-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Precedence: bulk
MIME-Version: 1.0
References: <20240325-ucsi-reset-delay-v1-1-d9e183e0f1e6@chromium.org> <2024032624-subtitle-crisped-f4f1@gregkh>
In-Reply-To: <2024032624-subtitle-crisped-f4f1@gregkh>
From: Pavan Holla <pholla@chromium.org>
Date: Tue, 26 Mar 2024 16:34:44 -0700
Message-ID: <CAB2FV=4Z1W1HSba50KaB3rR4=Ussb5RWPwUArr0_=3pFwxpAhA@mail.gmail.com>
Subject: Re: [PATCH] usb: typec: ucsi: Wait 20ms before retrying reset
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, 
	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, 
	Abhishek Pandit-Subedi <abhishekpandit@chromium.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 26, 2024 at 1:29=E2=80=AFAM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Mon, Mar 25, 2024 at 09:19:43PM +0000, Pavan Holla wrote:
> > The PPM might take time to process reset. Allow 20ms for the reset to
> > complete before issuing another reset.
> What commit id does this fix?  Does it need to go to older kernels?

This does not fix any commit. However, the time taken by a CCI read is
insufficient for a ChromeOS EC and PDC to perform a reset.

> > There is a 20ms delay for a reset retry to complete. However, the first
> > reset attempt is expected to complete immediately after an async write
> > of the reset command. This patch adds 20ms between the async write and
> > the CCI read that expects the reset to be complete. The additional dela=
y
> > also allows the PPM to settle after the first reset, which seems to be
> > the intention behind the original 20ms delay ( kernel v4.14 has a comme=
nt
> > regarding the same )
>
> Why was the comment removed in newer kernels?

The comment was removed when the old UCSI API was removed in
2ede55468ca8cc236da66579359c2c406d4c1cba

> Where does the magic 20ms number come from?  What about systems that do
> not need that time delay, did things just slow down for them?

I am not sure how 20ms was decided upon. However, UCSI v1.2 has
MIN_TIME_TO_RESPOND_WITH_BUSY=3D10ms. So, we need to provide at least
10ms for the PPM to respond with CCI busy. Indeed, this patch slows down ot=
her
implementations by 20ms. UCSIv3 also defines a 200ms timeout for PPM_RESET.

Hi Heikki,

Do you think the right thing to do here is:
1) poll CCI ( poll duration TBD) for 20ms until busy is set or reset
is complete.
2) poll CCI ( poll duration TBD) for 180ms until reset is complete if
busy was set.
3) If either 1) or 2) timeout, retry the reset.

If you agree with the approach, please advise a poll duration as well ( 20m=
s? )

Thanks,
Pavan