From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L7Y7U-0007jv-3D for qemu-devel@nongnu.org; Tue, 02 Dec 2008 11:29:04 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L7Y7S-0007jj-2O for qemu-devel@nongnu.org; Tue, 02 Dec 2008 11:29:02 -0500 Received: from [199.232.76.173] (port=44034 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L7Y7R-0007jg-Sf for qemu-devel@nongnu.org; Tue, 02 Dec 2008 11:29:01 -0500 Received: from e33.co.us.ibm.com ([32.97.110.151]:60578) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1L7Y7R-0000c9-Hh for qemu-devel@nongnu.org; Tue, 02 Dec 2008 11:29:01 -0500 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e33.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id mB2GSOxM003557 for ; Tue, 2 Dec 2008 09:28:24 -0700 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mB2GSu7b125940 for ; Tue, 2 Dec 2008 09:28:58 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mB2GSuak017602 for ; Tue, 2 Dec 2008 09:28:56 -0700 Date: Tue, 2 Dec 2008 10:28:56 -0600 From: Ryan Harper Subject: Re: [Qemu-devel] [PATCH 2/2] LSI53C895A: Handle empty SCRIPTS opcode Message-ID: <20081202162856.GC13481@us.ibm.com> References: <555360.18887.qm@web51105.mail.re2.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <555360.18887.qm@web51105.mail.re2.yahoo.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Justin Chevrier Cc: qemu-devel@nongnu.org * Justin Chevrier [2008-12-02 10:00]: > Well I've finally sorted out what Openserver is doing. Basically after > each DMA transfer the Openserver driver would issue an empty (0) > SCRIPTS opcode. As the opcode is essentially a NOP it has no second > DWORD and therefore the DSP should only be incremented by 4 bytes > instead of the 8 bytes we currently do. Nice catch! > > Here's a snippet of the log: > > lsi_scsi: Data ready tag=0x100d9 len=16384 > ... > lsi_scsi: SCRIPTS dsp=068c5e50 opcode 01000400 arg 07a09000 > lsi_scsi: DMA addr=0x07a09000 len=1024 > lsi_scsi: SCRIPTS dsp=068c5e58 opcode 00000000 arg 01000400 > lsi_scsi: Wrong phase got 1 expected 0 > > Note the 2nd DWORD after the empty opcode; the next opcode in the DMA > transfer sequence. As can be expected the address after that has the > next DMA address to use. > > After the attached patch the DMA transfer is able to complete successfully: > > lsi_scsi: SCRIPTS dsp=068c5e50 opcode 01000400 arg 07a0d000 > lsi_scsi: DMA addr=0x07a0d000 len=1024 > lsi_scsi: SCRIPTS dsp=068c5e5c opcode 01000400 arg 07a0d400 > lsi_scsi: DMA addr=0x07a0d400 len=1024 > ... > > Tested againsted Openserver 5.0.5 and Debian ARM. > > Changelog: > > Handle empty SCRIPTS opcode > > Signed-off-by: Justin Chevrier Tested XP 32-bit, Linux 2.6.27 in 40-bit DMA mode. I don't seen any issues with the patch applied. Acked-by: Ryan Harper > > > > Index: hw/lsi53c895a.c > =================================================================== > --- hw/lsi53c895a.c (revision 5852) > +++ hw/lsi53c895a.c (working copy) > @@ -867,6 +867,12 @@ > again: > insn_processed++; > insn = read_dword(s, s->dsp); > + if(!insn) { > + /* If we receive an empty opcode increment the DSP by 4 bytes > + instead of 8 and execute the next opcode at that location */ > + s->dsp += 4; > + goto again; > + } > addr = read_dword(s, s->dsp + 4); > addr_high = 0; > DPRINTF("SCRIPTS dsp=%08x opcode %08x arg %08x\n", s->dsp, insn, addr); -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@us.ibm.com