From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:51095) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTakA-000373-R8 for qemu-devel@nongnu.org; Mon, 06 Jun 2011 10:25:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QTak9-0001m7-64 for qemu-devel@nongnu.org; Mon, 06 Jun 2011 10:25:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13628) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTak8-0001lB-A7 for qemu-devel@nongnu.org; Mon, 06 Jun 2011 10:25:24 -0400 Message-ID: <4DECE34F.4020904@redhat.com> Date: Mon, 06 Jun 2011 16:25:19 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1307363962-27223-1-git-send-email-kraxel@redhat.com> <1307363962-27223-14-git-send-email-kraxel@redhat.com> <4DECD780.5020807@cisco.com> <4DECDCBB.1010609@cisco.com> In-Reply-To: <4DECDCBB.1010609@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 13/31] usb-ehci: drop EXECUTING checks. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Ahern Cc: qemu-devel@nongnu.org Hi, >>> -#if EHCI_DEBUG == 0 >>> - if (qemu_get_clock_ns(vm_clock) / 1000>= ehci->frame_end_usec) { >>> - if (async) { >>> - DPRINTF("FETCHENTRY: FRAME timer elapsed, exit state machine\n"); >>> - goto out; >>> - } else { >>> - DPRINTF("FETCHENTRY: WARNING " >>> - "- frame timer elapsed during periodic\n"); >>> - } >>> - } >>> -#endif > > This check was added to per Section 4 of the EHCI spec -- the HC should > not start transactions that will not be completed before the end of the > micro-frame. If you remove this what causes the EHCI model to take a > breather? Look at patch #8. That brings a number of state machine changes. One of them is that the async schedule stops as soon as it notices it walks in circles (i.e. sees a QH the second time). >>> - case EST_FETCHENTRY: >>> - /* fall through */ >> >> Why drop this case too? As I recall that is needed for proper execution. The async schedule doesn't pause in fetchentry state any more (also done by patch #8). cheers, Gerd