From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=45232 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PQRAC-0004TP-3G for qemu-devel@nongnu.org; Wed, 08 Dec 2010 16:03:05 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PQRA5-0000wf-DR for qemu-devel@nongnu.org; Wed, 08 Dec 2010 16:02:59 -0500 Received: from mail-ey0-f181.google.com ([209.85.215.181]:52148) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PQRA5-0000wQ-8f for qemu-devel@nongnu.org; Wed, 08 Dec 2010 16:02:53 -0500 Received: by eyh6 with SMTP id 6so1094864eyh.12 for ; Wed, 08 Dec 2010 13:02:52 -0800 (PST) Date: Wed, 8 Dec 2010 22:02:48 +0100 From: "Edgar E. Iglesias" Subject: Re: [Qemu-devel] [PATCH 1/6] [RFC] Emulation of GRLIB GPTimer as defined in GRLIB IP Core User's Manual. Message-ID: <20101208210248.GC14154@laped.lan> References: <4CFE0495.6060906@adacore.com> <20101208083005.GA6845@edde.se.axis.com> <4CFF525F.2040105@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CFF525F.2040105@adacore.com> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fabien Chouteau Cc: Blue Swirl , qemu-devel@nongnu.org On Wed, Dec 08, 2010 at 10:39:43AM +0100, Fabien Chouteau wrote: > On 12/08/2010 09:30 AM, Edgar E. Iglesias wrote: > > On Tue, Dec 07, 2010 at 10:55:33AM +0100, Fabien Chouteau wrote: > >> On 12/06/2010 06:12 PM, Blue Swirl wrote: > >>> On Mon, Dec 6, 2010 at 9:26 AM, Fabien Chouteau wrote: > >>>> +DeviceState *grlib_gptimer_create(target_phys_addr_t base, > >>>> + uint32_t nr_timers, > >>>> + uint32_t freq, > >>>> + qemu_irq *cpu_irqs, > >>>> + int base_irq) > >>> This function belongs to leon3.c. > >> I don't see why. GPTimer is a peripheral and you may want to use it in > >> an other system. > > This might depend a bit on taste, but I agree with Blue that we shouldn't > > clutter the device models with this kind of instantiator helper calls. > > IMO it's better to put them higher up (e.g board code or similar). > > Do you mean like Xilinx devices where the instantiators are in-lined > functions in hw/xilinx.h? Yes, that's one way. But if you only have a single board you can also just put the function with the board code. Cheers