Date: Thu, 30 Jul 2015 17:22:55 +0200 From: Svatopluk Kraus <onwahe@gmail.com> To: Hans Petter Selasky <hps@selasky.org> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: [RPI-B] [HEADS UP] DWC OTG TX path optimisation for 11-current Message-ID: <CAFHCsPXmm8rhZpiQ4uhPCkwBKC1o5gMLFYHEj9s5e3ObU21BPg@mail.gmail.com> In-Reply-To: <55BA1AC7.4050602@selasky.org> References: <55A7D8CE.4020809@selasky.org> <CAHNYxxMp9jGDbV-5=-cE6daR-O3eN5pdvO1s-=QfX=A9XYqYmA@mail.gmail.com> <55B23276.8090703@selasky.org> <CAHNYxxNc9uB62hHEv1PM9PcsGgUs=zsvNgatqLD0p%2BiiDA3Aiw@mail.gmail.com> <55B73113.2020308@selasky.org> <CAFHCsPVaPZpqXLS7OApa=Xz5VLnLjVpV5dYV8Pn2uHh1Lcz7Tg@mail.gmail.com> <55B8AB76.7030603@selasky.org> <CAFHCsPUMaYEwJsaGUFuw9yZi_5bmraSBsOYpRWvSeuebpXBJUA@mail.gmail.com> <55B8B297.1010008@selasky.org> <CAFHCsPVGLs8j6LAV%2Bg4rP_ueTOd8pUOupYFGvmgC3XGcJC720Q@mail.gmail.com> <20150729154516.GH78154@funkthat.com> <55B8F5EC.2050908@selasky.org> <CAFHCsPXmQCKt-5xWa6XwECqFO5oz4mT9m1mPu0dKmmQ%2BG9yUAA@mail.gmail.com> <55B9F914.7030403@selasky.org> <CAFHCsPVzFE-a2x2rsZRshGZExwZX9dCz2hXtpb2t5LFKN-14aQ@mail.gmail.com> <55BA1889.4040509@selasky.org> <55BA1AC7.4050602@selasky.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
Well, I'm trying to join answers for your previous emails in this one.
On Thu, Jul 30, 2015 at 2:38 PM, Hans Petter Selasky <hps@selasky.org> wrote:
> On 07/30/15 14:28, Hans Petter Selasky wrote:
>
> Can you run only "usbdump" while the interface is UP and the errors are printed in the console?
>
> We are looking for ERR different from "0".
It looks that there is no ERR different from "0" in usbdump at all.
Again, it looks that the load is generated "internally" and it does
not depend on explicit usb request directly.
>
> Does the interface come back when you down/up it?
Yes, it works.
> BTW: All your USB HUBs are self powered?
Yes, my usb hub has external power supply (12V, 4A) and my usb disk is
connected only.
>
> Does the device recover if you do:
>
> usbconfig -d X.Y reset
>
> for the ue0 ?
Yes, it does.
Anyhow, I think that I figured out why the system has so slow response
time when it's triggered. In general, it's not good idea to not limit
somehow interrupt filter execution time. If something wrong is
happening, then such filter can halt all system. I can get back fast
system response time with attached patch. Note that it's only a
proof-of-concept patch and it does not remove the problem. There is
still something what generates big load when it's triggered even if
system is 99% idle after trigger was pulled.
Svata
[-- Attachment #2 --]
diff --git a/sys/dev/usb/controller/dwc_otg.c b/sys/dev/usb/controller/dwc_otg.c
index 51f083b..cde366f 100644
--- a/sys/dev/usb/controller/dwc_otg.c
+++ b/sys/dev/usb/controller/dwc_otg.c
@@ -2554,8 +2554,12 @@ dwc_otg_interrupt_poll_locked(struct dwc_otg_softc *sc)
uint32_t temp;
uint8_t got_rx_status;
uint8_t x;
+ uint32_t count = 0;
repeat:
+ if (count++ > 2)
+ return;
+
/* get all channel interrupts */
for (x = 0; x != sc->sc_host_ch_max; x++) {
temp = DWC_OTG_READ_4(sc, DOTG_HCINT(x));
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFHCsPXmm8rhZpiQ4uhPCkwBKC1o5gMLFYHEj9s5e3ObU21BPg>