From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:55630) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFHAF-0001Uu-47 for qemu-devel@nongnu.org; Tue, 03 Apr 2012 23:45:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SFHAD-00066J-5O for qemu-devel@nongnu.org; Tue, 03 Apr 2012 23:45:42 -0400 Received: from plane.gmane.org ([80.91.229.3]:47526) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SFHAC-000664-Uf for qemu-devel@nongnu.org; Tue, 03 Apr 2012 23:45:41 -0400 Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SFHA9-0006ne-5j for qemu-devel@nongnu.org; Wed, 04 Apr 2012 05:45:37 +0200 Received: from 213.33.220.118 ([213.33.220.118]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2012 05:45:37 +0200 Received: from e.voevodin by 213.33.220.118 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 04 Apr 2012 05:45:37 +0200 From: Evgeny Voevodin Date: Wed, 04 Apr 2012 07:45:26 +0400 Message-ID: <4F7BC3D6.2080405@samsung.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: Subject: Re: [Qemu-devel] gic_cpu_write() call in exynos4210_gic_init() List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Maksim Kozlov , Igor Mitsyanko , Dmitry Solodkiy On 03.04.2012 20:45, Peter Maydell wrote: > Hi; I've been working on a refactoring of the ARM GIC code (trying > to make it its own sysbus device rather than having the .c file > included from lots of places), and I noticed the following odd code > in hw/exynos4210_gic.c:exynos4210_gic_init(): > > gic_cpu_write(&s->gic, 1, 0, 1); > > This seems to be trying to enable the CPU interface for CPU 1 > (by directly calling the GIC function for writing a word to > that CPU interface). However, doing this in an init function > doesn't seem correct -- the write will change the GIC's internal > state but the change would be undone by a reset. (This happens > to work at the moment because we don't actually reset the GIC > at reset! However I intend to fix that bug...) > > What was the intention of this code, and can we just drop it, > or do it in some other way? Does the Exynos GIC really reset > with the second CPU interface enabled? > > My guess is that we either want a device property for CPU > interface state on reset (if the Exynos GIC resets differently > to the standard GIC), or this should be being done in the > arm_boot code if it's just trying to emulate behaviour of some > boot ROM... > > thanks > -- PMM > > Hi; Linux Kernel enables CPU0 during boot process (3.0 and earlier - in Internal GIC; 3.1 and later - in External GIC). CPU1 interface is enabled in secondary CPU bootloader by default, but only for Internal GIC. Since Kernel version 3.1 External GIC is used and it's CPU interface for CPU1 is not enabled. This call is a stub to perform, possibly, functionality of earliest SOC bootloader which seems to enable external GIC CPU1 interface (nobody saw the code of that). So, since new functionality of GIC is available, I think that obvious solution is to introduce Exynos-specific secondary CPU bootloader like in highbank, that would enable both External and Internal GIC CPU1 interfaces. I will send patches soon. Thanks. -- Kind regards, Evgeny Voevodin, Leading Software Engineer, ASWG, Moscow R&D center, Samsung Electronics e-mail: e.voevodin@samsung.com