From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47544 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PBk8k-0002Zy-1p for qemu-devel@nongnu.org; Fri, 29 Oct 2010 04:16:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PBk8i-0003qT-Tu for qemu-devel@nongnu.org; Fri, 29 Oct 2010 04:16:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34628) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PBk8i-0003qN-LN for qemu-devel@nongnu.org; Fri, 29 Oct 2010 04:16:44 -0400 Date: Fri, 29 Oct 2010 10:16:26 +0200 From: "Michael S. Tsirkin" Message-ID: <20101029081626.GE22688@redhat.com> References: <20101027161227.GA9873@redhat.com> <20101028045426.GA5599@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: bonito: PCI_STATUS questions List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: chen huacai Cc: qemu-devel@nongnu.org, Aurelien Jarno On Thu, Oct 28, 2010 at 04:31:33PM +0800, chen huacai wrote: > Please see bonito64_pcibios_config_access() in > arch/mips/pci/ops-bonito64.c of Linux kernel code. > You will find something useful. Thanks! I found this: /* Clear aborts */ BONITO_PCICMD |=3D BONITO_PCICMD_MABORT_CLR | BONITO_PCICMD_MTABO= RT_CLR; BONITO_PCIMAP_CFG =3D (addr >> 16) | type; /* Flush Bonito register block */ dummy =3D BONITO_PCIMAP_CFG; mmiowb(); addrp =3D CFG_SPACE_REG(addr & 0xffff); if (access_type =3D=3D PCI_ACCESS_WRITE) { writel(cpu_to_le32(*data), addrp); /* Wait till done */ while (BONITO_PCIMSTAT & 0xF); } else { *data =3D le32_to_cpu(readl(addrp)); } /* Detect Master/Target abort */ if (BONITO_PCICMD & (BONITO_PCICMD_MABORT_CLR | BONITO_PCICMD_MTABORT_CLR)) { /* Error occurred */ /* Clear bits */ BONITO_PCICMD |=3D (BONITO_PCICMD_MABORT_CLR | BONITO_PCICMD_MTABORT_CLR); return -1; } So it looks like guest will clear bits, perform a transaction then check error bits. In other words, it looks like it assumes that writing 1 to these bits will clear them. Correct? > On Thu, Oct 28, 2010 at 12:54 PM, Michael S. Tsirkin w= rote: > > On Thu, Oct 28, 2010 at 08:57:01AM +0800, chen huacai wrote: > >> Because the code in PMON and Linux kernel use these bits to verify r= /w > >> operations. If one of them is 1 after r/w, PMON and Linux will > >> consider r/w has failed. > > > > Where's that code in Linux? > > > >> I guess that software will not set them to 1, because it is set by > >> hardware when operation fails. > > > > So I guess just making these write 1 to clear according to spec will = work? > > > >> On Thu, Oct 28, 2010 at 12:12 AM, Michael S. Tsirkin wrote: > >> > I see code in bonito.c that clears bits: > >> > PCI_STATUS_REC_MASTER_ABORT | PCI_STATUS_REC_TARGET_ABORT > >> > on each read and write. > >> > > >> > However > >> > 1. I don't see anything in code that would set these bits > >> > 2. The PCI spec says this about the status register: > >> > > >> > =A0 =A0 =A0 =A0Reads to this register behave normally. Writes are = slightly different in > >> > =A0 =A0 =A0 =A0that bits can be reset, but not set. A one bit is r= eset (if it is not > >> > =A0 =A0 =A0 =A0read-only) whenever the register is written, and th= e write data in the > >> > =A0 =A0 =A0 =A0corresponding bit location is a 1. For instance, to= clear bit 14 and not > >> > =A0 =A0 =A0 =A0affect any other bits, write the value 0100_0000_00= 00_0000b to the > >> > =A0 =A0 =A0 =A0register. > >> > > >> > while the code in bonito.c resets the bits to 0 on each write. > >> > > >> > Comments? > >> > > >> > -- > >> > MST > >> > > >> > >> > >> > >> -- > >> Huacai Chen > > >=20 >=20 >=20 > --=20 > Huacai Chen