Linux USB
 help / color / mirror / Atom feed
From: Anne Macedo <retpolanne@posteo.net>
To: Christian Lamparter <chunkeey@gmail.com>
Cc: Mathias Nyman <mathias.nyman@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	Vinod Koul <vkoul@kernel.org>,
	Christian Lamparter <chunkeey@googlemail.com>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: host: xhci: parameterize Renesas delay/retry
Date: Mon, 19 Jun 2023 10:12:36 +0000	[thread overview]
Message-ID: <5a057964ae1e26ed934035c183bf2967@posteo.net> (raw)
In-Reply-To: <f4b0f337-c530-8c4f-dc22-cfaf834dd5f0@gmail.com>

On 19.06.2023 10:19, Christian Lamparter wrote:
> On 6/19/23 00:46, Anne Macedo wrote:
>> Cards based on Renesas uPD720202 have their firmware downloaded during
>> boot by xhci-pci. At this step, the status of the firmware is read and
>> it takes a while for this read to happen (up to a few seconds). The
>> macros RENESAS_RETRY and RENESAS_DELAY are used to retry reading this
>> status byte from PCI a few times. If it can't read the status byte in
>> RENESAS_RETRY tries, it times out.
>> 
>> However, since this may vary from card to card, these retry and delay
>> values need to be tweaked. In order to avoid having to patch the code 
>> to
>> change these values, CONFIG_USB_XHCI_PCI_RENESAS_RETRY and
>> CONFIG_USB_XHCI_PCI_RENESAS_DELAY are introduced.
>> 
>> If applied, this patch helps to fix errors such as:
>> 
>> ROM Download Step 34 failed at position 136 bytes
>> Firmware Download Step 2 failed at position 8 bytes with (-110)
>> 
>> while loading xhci-pci when using these cards.
>> 
>> This error in particular has been noticed by this e-mail [1].
>> 
>> [1] https://lore.kernel.org/lkml/20190626070658.GP2962@vkoul-mobl/
> 
> Can you tell me on what hardware (is it something older, with maybe
> a Synopsys/Designware PCIe host controller?) do you experience these
> errors and what delay+retry values are you configuring in order to
> get your DUT up an running?

It's a PH61 Rev 1.2 board with the Renesas uPD720201 host controller.
I'm using 10 as the delay and 6000 as the retry.
> 
> From what I can tell, the quoted [1] link to Vinod's mail was just
> an update during development. This was v3 of the patch series back
> then (and it went on to v10 I think, so this wasn't an issue with
> what's in the kernel right now).
> 

I see. That was the only reference I found to the timeout error I was
seeing, so that's why I decided to tweak these retry+delay values.

> Note: If you are interested I still got the "uPD720201/uPD720202 User's
> Manual" back then from Renesas site. (Nowadays they want you to
> register or something.). This document was the base for the code and
> maybe there's something in there you can quote to extend the
> retries/delays.

Definitely interested! I did find a .pdf on Google though, I can check 
it.

> 
> (From what I vaguely remember. Most of the transfer was fast and
> no retries where necessary, but some register write took so long.
> Vinod  also posted hints about a newer firmware for the
> uPD720201/uPD720202. Have you tried that as well?)

I was using the upd72020x-fw AUR package on my Arch Linux build,
if that's any relevant. However, it's quite old and I don't really know
how it works. I missed these hints, sorry, could you point me to
them?
> 
> Regards,
> Christian


  reply	other threads:[~2023-06-19 10:12 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-18 22:46 [PATCH] usb: host: xhci: parameterize Renesas delay/retry Anne Macedo
2023-06-19  5:46 ` Greg Kroah-Hartman
2023-06-19  9:59   ` retpolanne
2023-06-19  8:19 ` Christian Lamparter
2023-06-19 10:12   ` Anne Macedo [this message]
2023-06-21 20:20     ` Christian Lamparter
2023-06-21 22:21       ` Anne Macedo

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=5a057964ae1e26ed934035c183bf2967@posteo.net \
    --to=retpolanne@posteo.net \
    --cc=chunkeey@gmail.com \
    --cc=chunkeey@googlemail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mathias.nyman@intel.com \
    --cc=vkoul@kernel.org \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox