Date: Sun, 11 May 2014 00:17:59 +0200 From: Hans Petter Selasky <hps@selasky.org> To: Ian Lepore <ian@FreeBSD.org> Cc: "freebsd-arm@freebsd.org" <freebsd-arm@FreeBSD.org>, Alexander Motin <mav@FreeBSD.org> Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] Message-ID: <536EA597.3070700@selasky.org> In-Reply-To: <1399742062.22079.403.camel@revolution.hippie.lan> References: <20140425154430.GA76168@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <CAGW5k5bZ_bTQUXuzNm=tbwx3npz1_HoOR3vM8TBRVFs8zWCq-w@mail.gmail.com> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <CAJ-Vmo=XmH-RX6_i13NuAXhq-jTC%2BWedGiyOMJaPO4r014DSgw@mail.gmail.com> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <CAJ-Vmok-%2B7%2Bcq%2BDa6_C2AA7BuP5readY_Gfwwm_RF5kh4VerQA@mail.gmail.com> <5368A93D.3070608@selasky.org> <5368AC03.8080401@selasky.org> <536CE5E9.8020408@selasky.org> <1399647986.22079.367.camel@revolution.hippie.lan> <536D0575.1040407@selasky.org> <1399661378.22079.376.camel@revolution.hippie.lan> <536DDA6D.7060101@selasky.org> <1399724697.22079.386.camel@revolution.hippie.l an> <536E2EBB.7030104@selasky.org> <1399742062.22079.403.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 05/10/14 19:14, Ian Lepore wrote: > On Sat, 2014-05-10 at 15:50 +0200, Hans Petter Selasky wrote: >> On 05/10/14 14:24, Ian Lepore wrote: >>> On Sat, 2014-05-10 at 09:51 +0200, Hans Petter Selasky wrote: >>>> Hi, >>>> >>>> I've made one more patch to the DWC OTG driver. Nice if you can test >>>> that too. >>>> >>>> http://svnweb.freebsd.org/changeset/base/265806 >>>> >>>> BTW: I think I've found what is causing the glitches when using USB >>>> audio devices: >>>> >>>> diff --git a/sys/arm/arm/machdep.c b/sys/arm/arm/machdep.c >>>> index 0490be7..de7f015 100644 >>>> --- a/sys/arm/arm/machdep.c >>>> +++ b/sys/arm/arm/machdep.c >>>> @@ -423,7 +423,7 @@ cpu_est_clockrate(int cpu_id, uint64_t *rate) >>>> void >>>> cpu_idle(int busy) >>>> { >>>> - >>>> +#if 0 >>>> CTR2(KTR_SPARE2, "cpu_idle(%d) at %d", >>>> busy, curcpu); >>>> #ifndef NO_EVENTTIMERS >>>> @@ -442,6 +442,7 @@ cpu_idle(int busy) >>>> #endif >>>> CTR2(KTR_SPARE2, "cpu_idle(%d) at %d done", >>>> busy, curcpu); >>>> +#endif >>>> } >>>> >>>> int >>>> >>>> >>>> It appears that cpu_idle() is going to sleep when there are pending >>>> interrupts, and then waking up on the next timer IRQ! Can someone >>>> familiar with these parts of the kernel comment? >>>> >>>> Please try for yourself, with and without the patch above, using an USB >>>> audio device with the RPI-B! >>>> >>>> Still when the console is printing, there are significant glitches too >>>> :-) That's because the TTY layer is synchronously writing data to the >>>> serial line. That's OK for now. >>>> >>>> --HPS >>> >>> If there's an interrupt pending when the WaitForInterrupt instruction is >>> executed, the cpu doesn't go to sleep -- it acts like a nop. I think >>> the problem might be that the device write that re-enables the interrupt >>> hasn't yet made it to the device when the cpu clock stops. >>> >>> I don't have any usb audio gear to test with, could you please test the >>> attached patch and see if it fixes the glitches? >>> >>> -- Ian >>> >> >> Hi, >> >> That code is not used with RPI so it makes no difference. > > Doh! We have so much decoy code in freebsd-arm. > >> I think we >> need to do something like they are doing on x86, that the interrupts are >> enabled the instruction before the sleep instruction. Else we can loose >> interrupts. Can you write me a correct patch which implements that? >> > > ARM is not x86. From the ARM ARM: > > When a processor issues a WFI instruction it can suspend > execution and enter a low-power state. It can remain in that > state until the processor detects a reset or one of the > following WFI wake-up events: > * an IRQ interrupt, regardless of the value of the CPSR.I bit. > * an FIQ interrupt, regardless of the value of the CPSR.F bit. > * an asynchronous abort, regardless of the value of the CPSR.A > bit. > * a debug event, when invasive debug is enabled and the debug > event is permitted. > > Not only is enabling interrupts before WFI not necessary, it may be > completely the wrong thing to do... if there's an interrupt pending it > will fire as soon as the cpsr.I bit is set, and the handler will run > before the WFI executes. Depending on what the handler does maybe > putting the CPU to sleep isn't the right thing to do anymore -- the ISR > made something runnable that previously wasn't -- but upon return from > handling the interrupt we'll unconditionally go to sleep until the next > interrupt instead of returning to the scheduler which would now find new > non-idle work to do. > > Note that in the linux implementation they actually go so far as adding > a comment to explain that the code doesn't disable interrupts because > it's expected that the caller has already done so: > > https://github.com/torvalds/linux/blob/master/arch/arm/mm/proc-v6.S#L69 > > I wonder if this is related to some memory ordering trouble I've seen in > armv7, which I can't fully explain, but the attached patch makes it go > away (preventing spurious interrupts). It'd be interesting to see if it > has any effect on this situation. > > -- Ian > Hi, This patch makes no difference. Only the disabling of the cpu_idle() function completely eliminates the problem. --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?536EA597.3070700>