public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Eugen Hristev <eugen.hristev@collabora.com>,
	kever.yang@rock-chips.com, u-boot@lists.denx.de
Cc: jonas@kwiboo.se, jagan@edgeble.ai, kernel@collabora.com,
	Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>,
	Tom Rini <trini@konsulko.com>
Subject: Re: [PATCH v2 02/10] usb: dwc3: core: improve reset sequence
Date: Tue, 1 Aug 2023 13:44:00 +0200	[thread overview]
Message-ID: <4df8f13d-ab99-e751-3160-af7218b9f29b@denx.de> (raw)
In-Reply-To: <20230801072811.10354-3-eugen.hristev@collabora.com>

On 8/1/23 09:28, Eugen Hristev wrote:
> From: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
> 
> [ Felipe: Ported from Linux kernel commit
> 	  f59dcab17629 ("usb: dwc3: core: improve reset sequence") ]
> 
> According to Synopsys Databook, we shouldn't be relying on
> GCTL.CORESOFTRESET bit as that's only for debugging purposes.
> Instead, let's use DCTL.CSFTRST if we're OTG or PERIPHERAL mode.
> 
> Host side block will be reset by XHCI driver if necessary. Note that this
> reduces amount of time spent on dwc3_probe() by a long margin.
> 
> We're still gonna wait for reset to finish for a long time
> (default to 1ms max), but tests show that the reset polling loop executed
> at most 19 times (modprobe dwc3 && modprobe -r dwc3 executed 1000
> times in a row).
> 
> Without proper core reset, observing random issues like when the
> USB(DWC3) is in device mode, the host device is not able to detect the
> USB device.
> 
> Signed-off-by: Venkatesh Yadav Abbarapu <venkatesh.abbarapu@amd.com>
> [eugen.hristev@collabora.com: keep the PHY resets code]
> Signed-off-by: Eugen Hristev <eugen.hristev@collabora.com>

NAK

> ---
> Not to be merged, I know Marek does not apply any patches to DWC3.

That is not true and taken out of context.

What needs to happen is, someone needs to sync the DWC3 with Linux 
instead of picking random subsets patches and turning the driver into a 
total unmaintainable mess, which will be horribly difficult to sync in 
the future due to these random patches mixed in the history. I explained 
how to do it to Xilinx, it is a trivial thing to do, but it seems they 
did not even bother to try the method.

  reply	other threads:[~2023-08-01 11:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-01  7:28 [PATCH v2 00/10] rockchip: rk3588: add support for DFU in SPL Eugen Hristev
2023-08-01  7:28 ` [PATCH v2 01/10] rockchip: allow env defines for SPL build Eugen Hristev
2023-08-12  2:45   ` Kever Yang
2023-08-01  7:28 ` [PATCH v2 02/10] usb: dwc3: core: improve reset sequence Eugen Hristev
2023-08-01 11:44   ` Marek Vasut [this message]
2023-08-01  7:28 ` [PATCH v2 03/10] usb: dwc3: gadget: Don't send unintended link state change Eugen Hristev
2023-08-01 11:44   ` Marek Vasut
2023-08-01  7:28 ` [PATCH v2 04/10] usb: dwc3: core: Only handle soft-reset in DCTL Eugen Hristev
2023-08-01 11:44   ` Marek Vasut
2023-08-01  7:28 ` [PATCH v2 05/10] usb: dwc3: Increase DWC3 controller halt timeout Eugen Hristev
2023-08-01 11:44   ` Marek Vasut
2023-08-01  7:28 ` [PATCH v2 06/10] ARM: dts: rockchip: rk3588-rock-5b-u-boot: add bootph-all to gadget nodes Eugen Hristev
2023-08-12  2:53   ` Kever Yang
2023-08-13  6:59     ` Eugen Hristev
2023-08-01  7:28 ` [PATCH v2 07/10] ARM: mach-rockchip: spl-boot-order: add possibility to DFU Eugen Hristev
2023-08-12  2:52   ` Kever Yang
2023-08-01  7:28 ` [PATCH v2 08/10] ARM: mach-rockchip: rk3588: add gadget device to the boot order Eugen Hristev
2023-08-01  7:28 ` [PATCH v2 09/10] rockchip: rk3588: prepare env for DFU Eugen Hristev
2023-08-01  7:28 ` [PATCH v2 10/10] configs: rockchip: rock5b-rk3588: enable DFU and related configs Eugen Hristev
2023-08-12  2:53   ` Kever Yang
2023-09-21 14:47 ` [PATCH v2 00/10] rockchip: rk3588: add support for DFU in SPL Eugen Hristev
2023-09-22  0:48   ` Kever Yang
2023-09-22  9:57     ` Eugen Hristev

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=4df8f13d-ab99-e751-3160-af7218b9f29b@denx.de \
    --to=marex@denx.de \
    --cc=eugen.hristev@collabora.com \
    --cc=jagan@edgeble.ai \
    --cc=jonas@kwiboo.se \
    --cc=kernel@collabora.com \
    --cc=kever.yang@rock-chips.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=venkatesh.abbarapu@amd.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