From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40691) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdhnZ-0002Jk-Ow for qemu-devel@nongnu.org; Thu, 22 Dec 2011 07:31:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RdhnV-00029Q-Gc for qemu-devel@nongnu.org; Thu, 22 Dec 2011 07:31:01 -0500 Received: from mail-qy0-f173.google.com ([209.85.216.173]:59327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RdhnV-00029L-8k for qemu-devel@nongnu.org; Thu, 22 Dec 2011 07:30:57 -0500 Received: by qcsd15 with SMTP id d15so5382991qcs.4 for ; Thu, 22 Dec 2011 04:30:56 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4EF2D636.6000609@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> Date: Thu, 22 Dec 2011 12:30:56 +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 07:03, Evgeny Voevodin wrote: > Second GIC (external) is represented as "exynos4210.gic" with splitted > mapping for CPU (0x10480000) and Distributer (0x10490000) (we used > arm_gic.c availability to split CPU and Distributer memories). > > The reason for creation of this device with it's own read/write functions > is: > > CPU and Distributer registers which are banked per SMP Core in internal GIC > are not banked in external GIC and their offsets could not be used as is > with arm_gic.c. > External GIC registers in comparison to Internal GIC registers are moved > from base by offset n * 0x8000 for each SMP Core, where n is SMP Core index. Right, so just map each of the memory regions arm_gic exposes for core 0, core 1, ... to these addresses, and don't map the memory region corresponding to "CPU interface for this core" at all. -- PMM