From owner-freebsd-arm@FreeBSD.ORG Sat May 10 22:17:15 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF98C414; Sat, 10 May 2014 22:17:15 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7079AFAA; Sat, 10 May 2014 22:17:14 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 49C7C1FE02B; Sun, 11 May 2014 00:17:07 +0200 (CEST) Message-ID: <536EA597.3070700@selasky.org> Date: Sun, 11 May 2014 00:17:59 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: USB isochronous traffic with Rasberry Pi [WAS: Re: USB audio device on Raspberry Pi] References: <20140425154430.GA76168@utility-01.thismonkey.com> <5360C0A7.9010407@selasky.org> <1398867266.22079.51.camel@revolution.hippie.lan> <5362638B.1080104@selasky.org> <5363C133.2000304@selasky.org> <53677CB8.5000800@selasky.org> <1399303695.22079.239.camel@revolution.hippie.lan> <1399304157.22079.243.camel@revolution.hippie.lan> <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> In-Reply-To: <1399742062.22079.403.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" , Alexander Motin X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 May 2014 22:17:15 -0000 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