Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Felipe Balbi <balbi@kernel.org>
To:     Jun Li <jun.li@nxp.com>, Thinh Nguyen <Thinh.Nguyen@synopsys.com>,
        Jun Li <lijun.kernel@gmail.com>
Cc:     John Stultz <john.stultz@linaro.org>,
        lkml <linux-kernel@vger.kernel.org>,
        Yu Chen <chenyu56@huawei.com>,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Rob Herring <robh+dt@kernel.org>,
        Mark Rutland <mark.rutland@arm.com>,
        ShuFan Lee <shufan_lee@richtek.com>,
        Heikki Krogerus <heikki.krogerus@linux.intel.com>,
        Suzuki K Poulose <suzuki.poulose@arm.com>,
        Chunfeng Yun <chunfeng.yun@mediatek.com>,
        Hans de Goede <hdegoede@redhat.com>,
        Andy Shevchenko <andy.shevchenko@gmail.com>,
        Valentin Schneider <valentin.schneider@arm.com>,
        Jack Pham <jackp@codeaurora.org>,
        Linux USB List <linux-usb@vger.kernel.org>,
        "open list\:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@vger.kernel.org>, Peter Chen <peter.chen@nxp.com>,
        Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Subject: RE: [PATCH v4 3/9] usb: dwc3: Increase timeout for CmdAct cleared by device controller
In-Reply-To: <VE1PR04MB6528AB046FD441A5DDD83CD289BA0@VE1PR04MB6528.eurprd04.prod.outlook.com>
References: <20191028215919.83697-1-john.stultz@linaro.org> <20191028215919.83697-4-john.stultz@linaro.org> <87mudjj4rc.fsf@gmail.com> <CALAqxLU+9uEcdRVaLfh+eQrDtZbDGod9pRXhBX=prAhg9MXagw@mail.gmail.com> <CAKgpwJVaKpsgMjKcnYyJsfNj0ibkPt=mdn-NxfOkeX1jfL=9iQ@mail.gmail.com> <87h7wqmwrv.fsf@kernel.org> <CAKgpwJXfWv5=MDqBCADhe2iXf6eiP0GQ13Bwo9fkuU5kGO7dsw@mail.gmail.com> <87imgx35pg.fsf@kernel.org> <VE1PR04MB65283F16826D2254128073C589BD0@VE1PR04MB6528.eurprd04.prod.outlook.com> <3d757998-56f2-6fff-a724-f713867ae785@synopsys.com> <87ftc0xsig.fsf@kernel.org> <VE1PR04MB6528AB046FD441A5DDD83CD289BA0@VE1PR04MB6528.eurprd04.prod.outlook.com>
Date:   Sat, 16 May 2020 14:57:29 +0300
Message-ID: <87d074xfbq.fsf@kernel.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
        micalg=pgp-sha256; protocol="application/pgp-signature"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


Hi,

Jun Li <jun.li@nxp.com> writes:
>> >> Hi Thinh, could you comment this?
>> >
>> > You only need to wake up the usb2 phy when issuing the command while
>> > running in highspeed or below. If you're running in SS or higher,
>> > internally the controller does it for you for usb3 phy. In Jun's case,
>> > it seems like it takes longer for his phy to wake up.
>> >
>> > IMO, in this case, I think it's fine to increase the command timeout.
>>=20
>> Is there an upper limit to this? Is 32k clock the slowest that can be fe=
d to the
>> PHY as a suspend clock?
>
> Yes, 32K clock is the slowest, Per DWC3 document on Power Down Scale
> (bits 31:19 of GCTL):
>
> "Power Down Scale (PwrDnScale)
> The USB3 suspend_clk input replaces pipe3_rx_pclk as a clock source
> to a small part of the USB3 controller that operates when the SS PHY
> is in its lowest power (P3) state, and therefore does not provide a clock.
> The Power Down Scale field specifies how many suspend_clk periods
> fit into a 16 kHz clock period. When performing the division, round up
> the remainder.
> For example, when using an 8-bit/16-bit/32-bit PHY and 25-MHz Suspend clo=
ck,
> Power Down Scale =3D 25000 kHz/16 kHz =3D 13'd1563 (rounder up)
> Note:
> - Minimum Suspend clock frequency is 32 kHz
> - Maximum Suspend clock frequency is 125 MHz"

Cool, now do we have an upper bound for how many clock cycles it takes
to wake up the PHY? Then we can just set the time to that upper bound.

=2D-=20
balbi

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEElLzh7wn96CXwjh2IzL64meEamQYFAl6/1SkACgkQzL64meEa
mQZL+w/6AxOqdqZMxD6dJoy944O3y9M5glYLwe/tfeeCGMbA/mULQDUi9CSFu7iu
JTj+bJm3AMgWwzyJByWjEeOhw9M60ntIG2fztMEU/RuIsPCfSbXCxHHgccQx5JgW
atB9hxrMgI3BT41qqL98Ze+fJ540iii/0LA5/Dt1lw6NNjGKKxMC8dxipokcBUOc
oWqj4FS6J1JWrjjwLBna04l2UtrxM4NlFhSLxr5QCUx2ISVCDGB2nkW+lqjsPqoT
Ge4rKpUGqnJVbFHTR359GUnjbcPPzwp55LaQHfxxgvhQ+GlRpLBb6mFfeqj6a0JZ
EXvBxWDj9seVyvpL2xeLtOdhCzy5NCU5djHVEm4yckQ0I2yXccT9/SSQUJyD9I9o
2WomGpZZ1OxwKqL2XAcZyhvpstMXq+TvmJ8kjvaHIcEHROA1aFiIrxlyQQORssHH
8x4wZzwD7BuOCcZJy/W5cYyMi8dakbF4OhAKOOyg0AbU3weApPE2n2f5ZoYZVAFe
WJSlNC45benjGZdHrAMFvcNMuptBdIMF67oLXxoqa0gajL3zGvLateErsFqsJn1Z
jsZWNrVB5he+chQqraP37y5ZB2Nn95Et0/MPf1kgDO+JkVqkbyAX/HmuVILZ3Tgl
IBsFYDBphzkiWi0xTXGewtUUhSwerJL1PDPROdt4/wJkJqIXPEg=
=fLB9
-----END PGP SIGNATURE-----
--=-=-=--