From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:54120) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLtXR-0006aS-R9 for qemu-devel@nongnu.org; Wed, 10 Oct 2012 06:29:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLtXI-0003mX-Q5 for qemu-devel@nongnu.org; Wed, 10 Oct 2012 06:29:17 -0400 Received: from smtp4.mundo-r.com ([212.51.32.151]:29673) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLtXI-0003kn-J8 for qemu-devel@nongnu.org; Wed, 10 Oct 2012 06:29:08 -0400 Date: Wed, 10 Oct 2012 12:24:56 +0200 From: Alberto Garcia Message-ID: <20121010102455.GA18381@igalia.com> References: <20120831141231.GA18777@igalia.com> <5040E1A7.4010401@suse.de> <20121005132036.GA29555@igalia.com> <506EEE79.10608@redhat.com> <507155E1.6090907@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <507155E1.6090907@redhat.com> Subject: Re: [Qemu-devel] Ping [PATCH 0/2] Add TPCI200 and IP-Octal 232 IndustryPack emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Anthony Liguori , qemu-devel@nongnu.org, Blue Swirl , Paul Brook , Paolo Bonzini , Andreas =?iso-8859-1?Q?F=E4rber?= On Sun, Oct 07, 2012 at 12:13:53PM +0200, Avi Kivity wrote: > Luckily the low-order bits are used for offsets, and the high-order > bits are used for selecting the sub-device. > > So you could easily have > > struct IPackDevice { > DeviceState qdev; > int32_t slot; > /* IRQ objects for the IndustryPack INT0# and INT1# */ > qemu_irq *irq; > MemoryRegion io_space; > MemoryRegion id_space; > MemoryRegion int_space; > MemoryRegion mem8_space; /* for las3 */ > MemoryRegion mem16_space; /* for las2 */ > }; > > The PCI device would then just map each space (with > memory_region_add_subregion()) into las1/las2/las3 such that the > high bits select the device/space. The low bits would automatically > become the offset into the space. Hey, I finally found some time to look into this, the problem that I see is that the PCI carrier doesn't just map each space into its local address spaces, in addition to that: 1) it changes the data and addresses according to the endianness configuration in the local configuration registers (PCI BAR0). See adjust_addr()/adjust_value() and page 20 of the user manual. http://www.tews.com/Products/ArticleGroup/TPCI/TPCI200.html 2) read accesses to the local address space 1 are also used to acknowledge interrupts (manual page 33 and tpci200_read_las1()). On a related note, I was wondering whether it would be simpler to get rid of tpci200_cfg_ops and replace the current implementation of the local configuration registers with something like this: memory_region_init_ram_ptr(&s->mmio, "tpci200_mmio", 128, s->local_cfg); memory_region_init_alias(&s->io, "tpci200_io", &s->mmio, 0, 128); pci_register_bar(&s->dev, 0, PCI_BASE_ADDRESS_SPACE_MEMORY, &s->mmio); pci_register_bar(&s->dev, 1, PCI_BASE_ADDRESS_SPACE_IO, &s->io); (s->local_cfg would contain the config registers data) But it doesn't seem to work. Berto