From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:38591) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdkTJ-0004Ge-Qp for qemu-devel@nongnu.org; Thu, 22 Dec 2011 10:22:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RdkT9-0008Ml-GL for qemu-devel@nongnu.org; Thu, 22 Dec 2011 10:22:17 -0500 Received: from mail-qw0-f52.google.com ([209.85.216.52]:44165) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdkT9-0008MZ-EB for qemu-devel@nongnu.org; Thu, 22 Dec 2011 10:22:07 -0500 Received: by qadc11 with SMTP id c11so5314130qad.4 for ; Thu, 22 Dec 2011 07:22:06 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4EF327A0.8060300@samsung.com> References: <1324295617-5798-1-git-send-email-e.voevodin@samsung.com> <1324295617-5798-5-git-send-email-e.voevodin@samsung.com> <4EF1F681.7090805@samsung.com> <4EF2D636.6000609@samsung.com> <4EF327A0.8060300@samsung.com> Date: Thu, 22 Dec 2011 15:22:06 +0000 Message-ID: From: Peter Maydell Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [PATCH v4 04/11] ARM: exynos4210: IRQ subsystem support. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Evgeny Voevodin Cc: m.kozlov@samsung.com, qemu-devel@nongnu.org, d.solodkiy@samsung.com On 22 December 2011 12:50, Evgeny Voevodin wrote: > Do you mean to use s->gic.cpuiomem[NCPU+1] as in a9mpcore.c a9mp_priv_init() > done? It depends what you want. If you need a memory region which behaves like "CPU interface for whatever the core making this read/write is", that is cpuiomem[0]. If you need a memory region which behaves like "CPU interface for core 0" regardless of which core accesses it, that is cpuiomem[1]. For "CPU interface for core 1", cpuiomem[2]. 11MPCore uses all of these. A9MP's built in GIC only needs cpuiomem[0]. If you need any of these at more than one address in the memory map, you need to create a memory region alias. > What should we use if we need the same for distributor which is represented > as gic.iomem? > Extend distributor in the same way? Your current wrapper functions for the distributor read/write routines don't do anything to pass a specific CPU number into the underlying GIC distributor read/write functions. So it should be sufficient to just map the distributor's existing memory region (again, if you need it in more than one place in the address space then create an alias memory region for it). -- PMM