All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Cc: Felipe Balbi <balbi@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Linux USB List <linux-usb@vger.kernel.org>,
	Roger Quadros <rogerq@ti.com>, John Youn <John.Youn@synopsys.com>,
	stable <stable@vger.kernel.org>,
	Andy Shevchenko <andy.shevchenko@gmail.com>,
	Wesley Cheng <wcheng@codeaurora.org>,
	Ferry Toth <fntoth@gmail.com>, Yu Chen <chenyu56@huawei.com>
Subject: Re: [PATCH v2] usb: dwc3: core: Do core softreset when switch mode
Date: Thu, 15 Apr 2021 12:54:37 -0700	[thread overview]
Message-ID: <CALAqxLWkumSzfq1uOTbHdpiYfKOyJoyOosChBb25iyS4RYWP3w@mail.gmail.com> (raw)
In-Reply-To: <2cb4e704b059a8cc91f37081c8ceb95c6492e416.1618503587.git.Thinh.Nguyen@synopsys.com>

On Thu, Apr 15, 2021 at 9:29 AM Thinh Nguyen <Thinh.Nguyen@synopsys.com> wrote:
>
> From: Yu Chen <chenyu56@huawei.com>
> From: John Stultz <john.stultz@linaro.org>
>
> According to the programming guide, to switch mode for DRD controller,
> the driver needs to do the following.
>
> To switch from device to host:
> 1. Reset controller with GCTL.CoreSoftReset
> 2. Set GCTL.PrtCapDir(host mode)
> 3. Reset the host with USBCMD.HCRESET
> 4. Then follow up with the initializing host registers sequence
>
> To switch from host to device:
> 1. Reset controller with GCTL.CoreSoftReset
> 2. Set GCTL.PrtCapDir(device mode)
> 3. Reset the device with DCTL.CSftRst
> 4. Then follow up with the initializing registers sequence
>
> Currently we're missing step 1) to do GCTL.CoreSoftReset and step 3) of
> switching from host to device. John Stult reported a lockup issue seen
> with HiKey960 platform without these steps[1]. Similar issue is observed
> with Ferry's testing platform[2].
>
> So, apply the required steps along with some fixes to Yu Chen's and John
> Stultz's version. The main fixes to their versions are the missing wait
> for clocks synchronization before clearing GCTL.CoreSoftReset and only
> apply DCTL.CSftRst when switching from host to device.
>
> [1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/
> [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/
>
> Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
> Cc: Ferry Toth <fntoth@gmail.com>
> Cc: Wesley Cheng <wcheng@codeaurora.org>
> Cc: <stable@vger.kernel.org>
> Fixes: 41ce1456e1db ("usb: dwc3: core: make dwc3_set_mode() work properly")
> Signed-off-by: Yu Chen <chenyu56@huawei.com>
> Signed-off-by: John Stultz <john.stultz@linaro.org>
> Signed-off-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
> ---
> Changes in v2:
> - Initialize mutex per device and not as global mutex.
> - Add additional checks for DRD only mode


Hey Thinh!

  Thanks so much for your persisting effort on this issue! Its
something I'd love to see finally resolved!

 >  static void __dwc3_set_mode(struct work_struct *work)
>  {
>         struct dwc3 *dwc = work_to_dwc(work);
>         unsigned long flags;
> +       unsigned int hw_mode;
> +       bool otg_enabled = false;
>         int ret;
>         u32 reg;
>
> +       mutex_lock(&dwc->mutex);
> +
> +       hw_mode = DWC3_GHWPARAMS0_MODE(dwc->hwparams.hwparams0);
> +       if (DWC3_VER_IS_PRIOR(DWC3, 330A) &&
> +           (dwc->hwparams.hwparams6 & DWC3_GHWPARAMS6_SRPSUPPORT))
> +               otg_enabled = true;

Unfortunately on HiKey960, this check ends up being true, and that
basically disables the needed (on HiKey960 at least) soft reset logic
below, so we still end up hitting the issue.

The revision/hwparams6 values on the board are:
  revision: 0x5533300a hwparams6: 0xfeaec20

Just to make sure, I did test disabling the check here, and it does
seem to avoid the !COREIDLE stuck problem seen frequently on the
board.

thanks
-john

  reply	other threads:[~2021-04-15 19:54 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-15  2:23 [PATCH] usb: dwc3: core: Do core softreset when switch mode Thinh Nguyen
2021-04-15  6:23 ` Felipe Balbi
2021-04-15  7:10   ` Thinh Nguyen
2021-04-15  7:53     ` Greg Kroah-Hartman
2021-04-15  8:04       ` Thinh Nguyen
2021-04-15 10:45     ` Felipe Balbi
2021-04-15 14:57       ` Thinh Nguyen
2021-04-15 22:31         ` Thinh Nguyen
2021-04-15 16:29 ` [PATCH v2] " Thinh Nguyen
2021-04-15 19:54   ` John Stultz [this message]
2021-04-15 20:11     ` Thinh Nguyen
2021-04-15 22:20   ` [PATCH v3] " Thinh Nguyen
2021-04-15 22:23     ` Thinh Nguyen
2021-04-16 21:17       ` Ferry Toth
2021-04-17  2:27         ` Thinh Nguyen
2021-04-17 14:22           ` Ferry Toth
2021-04-17 16:32             ` Ferry Toth
2021-04-18 23:03               ` Thinh Nguyen
2021-04-19  8:43                 ` Andy Shevchenko
2021-04-19 20:24                   ` Ferry Toth
2021-04-19  9:47                 ` Felipe Balbi
2021-04-19 20:15                 ` Ferry Toth
2021-04-19 21:23                   ` Thinh Nguyen
2021-04-20 19:55                     ` Ferry Toth
2021-04-21 19:01                       ` Thinh Nguyen
2021-04-21 22:30                         ` Ferry Toth
2021-04-22 20:55                         ` Ferry Toth
2021-04-22 21:58                           ` Thinh Nguyen
2021-04-23  7:18                             ` Ferry Toth
2021-04-16  0:12     ` John Stultz
2021-04-16  3:28       ` John Stultz
2021-04-16  9:10         ` Ferry Toth
2021-04-16 10:47     ` Felipe Balbi
2021-04-16 19:05       ` Wesley Cheng
2021-04-16 19:38       ` John Stultz
2021-04-16 19:49         ` Thinh Nguyen
2021-04-16 21:08           ` John Stultz
2021-04-17  6:25             ` Felipe Balbi
2021-04-19 19:49               ` Thinh Nguyen
2021-04-19 21:26     ` Wesley Cheng

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALAqxLWkumSzfq1uOTbHdpiYfKOyJoyOosChBb25iyS4RYWP3w@mail.gmail.com \
    --to=john.stultz@linaro.org \
    --cc=John.Youn@synopsys.com \
    --cc=Thinh.Nguyen@synopsys.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=balbi@kernel.org \
    --cc=chenyu56@huawei.com \
    --cc=fntoth@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=rogerq@ti.com \
    --cc=stable@vger.kernel.org \
    --cc=wcheng@codeaurora.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.