All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@kernel.org>
To: Serge Semin <Sergey.Semin@baikalelectronics.ru>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Felipe Balbi <felipe.balbi@linux.intel.com>,
	David Cohen <david.a.cohen@linux.intel.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>
Cc: Serge Semin <Sergey.Semin@baikalelectronics.ru>,
	Serge Semin <fancer.lancer@gmail.com>,
	Alexey Malahov <Alexey.Malahov@baikalelectronics.ru>,
	Pavel Parkhomenko <Pavel.Parkhomenko@baikalelectronics.ru>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
	Felipe Balbi <balbi@ti.com>
Subject: Re: [PATCH 2/3] usb: dwc3: ulpi: Replace CPU-based busyloop with Protocol-based one
Date: Tue, 27 Oct 2020 11:18:51 +0200	[thread overview]
Message-ID: <87h7qgc9hg.fsf@kernel.org> (raw)
In-Reply-To: <20201010222351.7323-3-Sergey.Semin@baikalelectronics.ru>

[-- Attachment #1: Type: text/plain, Size: 2800 bytes --]


Hi,

Serge Semin <Sergey.Semin@baikalelectronics.ru> writes:

> Originally the procedure of the ULPI transaction finish detection has been
> developed as a simple busy-loop with just decrementing counter and no
> delays. It's wrong since on different systems the loop will take a
> different time to complete. So if the system bus and CPU are fast enough
> to overtake the ULPI bus and the companion PHY reaction, then we'll get to
> take a false timeout error. Fix this by converting the busy-loop procedure
> to take the standard bus speed, address value and the registers access
> mode into account for the busy-loop delay calculation.
>
> Here is the way the fix works. It's known that the ULPI bus is clocked
> with 60MHz signal. In accordance with [1] the ULPI bus protocol is created
> so to spend 5 and 6 clock periods for immediate register write and read
> operations respectively, and 6 and 7 clock periods - for the extended
> register writes and reads. Based on that we can easily pre-calculate the
> time which will be needed for the controller to perform a requested IO
> operation. Note we'll still preserve the attempts counter in case if the
> DWC USB3 controller has got some internals delays.
>
> [1] UTMI+ Low Pin Interface (ULPI) Specification, Revision 1.1,
>     October 20, 2004, pp. 30 - 36.
>
> Fixes: 88bc9d194ff6 ("usb: dwc3: add ULPI interface support")
> Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
> ---
>  drivers/usb/dwc3/ulpi.c | 18 +++++++++++++++---
>  1 file changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/usb/dwc3/ulpi.c b/drivers/usb/dwc3/ulpi.c
> index 20f5d9aba317..0dbc826355a5 100644
> --- a/drivers/usb/dwc3/ulpi.c
> +++ b/drivers/usb/dwc3/ulpi.c
> @@ -7,6 +7,8 @@
>   * Author: Heikki Krogerus <heikki.krogerus@linux.intel.com>
>   */
>  
> +#include <linux/delay.h>
> +#include <linux/time64.h>
>  #include <linux/ulpi/regs.h>
>  
>  #include "core.h"
> @@ -17,12 +19,22 @@
>  		DWC3_GUSB2PHYACC_ADDR(ULPI_ACCESS_EXTENDED) | \
>  		DWC3_GUSB2PHYACC_EXTEND_ADDR(a) : DWC3_GUSB2PHYACC_ADDR(a))
>  
> -static int dwc3_ulpi_busyloop(struct dwc3 *dwc)
> +#define DWC3_ULPI_BASE_DELAY	DIV_ROUND_UP(NSEC_PER_SEC, 60000000L)
> +
> +static int dwc3_ulpi_busyloop(struct dwc3 *dwc, u8 addr, bool read)
>  {
> +	unsigned long ns = 5L * DWC3_ULPI_BASE_DELAY;
>  	unsigned count = 1000;
>  	u32 reg;
>  
> +	if (addr >= ULPI_EXT_VENDOR_SPECIFIC)
> +		ns += DWC3_ULPI_BASE_DELAY;
> +
> +	if (read)
> +		ns += DWC3_ULPI_BASE_DELAY;
> +
>  	while (count--) {
> +		ndelay(ns);

could we allow for a sleep here instead of a delay? Also, I wonder if
you need to make this so complex or should we just take the larger
access time of 7 clock cycles.

-- 
balbi

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 857 bytes --]

  reply	other threads:[~2020-10-27  9:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-10 22:23 [PATCH 0/3] usb: dwc3: ulpi: Fix UPLI registers read/write ops Serge Semin
2020-10-10 22:23 ` [PATCH 1/3] usb: dwc3: ulpi: Use VStsDone to detect PHY regs access completion Serge Semin
2020-10-27  9:15   ` Felipe Balbi
2020-10-27 20:13     ` Serge Semin
2020-10-10 22:23 ` [PATCH 2/3] usb: dwc3: ulpi: Replace CPU-based busyloop with Protocol-based one Serge Semin
2020-10-27  9:18   ` Felipe Balbi [this message]
2020-10-27 21:06     ` Serge Semin
2020-10-10 22:23 ` [PATCH 3/3] usb: dwc3: ulpi: Fix USB2.0 HS/FS/LS PHY suspend regression Serge Semin
2020-10-19 13:58 ` [PATCH 0/3] usb: dwc3: ulpi: Fix UPLI registers read/write ops Heikki Krogerus
2020-10-27  9:13 ` Felipe Balbi
2020-10-27 20:07   ` Serge Semin

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=87h7qgc9hg.fsf@kernel.org \
    --to=balbi@kernel.org \
    --cc=Alexey.Malahov@baikalelectronics.ru \
    --cc=Pavel.Parkhomenko@baikalelectronics.ru \
    --cc=Sergey.Semin@baikalelectronics.ru \
    --cc=balbi@ti.com \
    --cc=david.a.cohen@linux.intel.com \
    --cc=fancer.lancer@gmail.com \
    --cc=felipe.balbi@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.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.