From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:57052) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcZJC-00049g-Rc for qemu-devel@nongnu.org; Fri, 01 Jul 2011 04:42:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QcZJ4-0007NL-I7 for qemu-devel@nongnu.org; Fri, 01 Jul 2011 04:42:42 -0400 Received: from mel.act-europe.fr ([194.98.77.210]:34122) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QcZJ4-0007Ds-2u for qemu-devel@nongnu.org; Fri, 01 Jul 2011 04:42:34 -0400 Message-ID: <4E0D885B.2020204@adacore.com> Date: Fri, 01 Jul 2011 10:42:03 +0200 From: Fabien Chouteau MIME-Version: 1.0 References: <1309191246-26224-1-git-send-email-chouteau@adacore.com> <20110627152851.2ad8d560@schlenkerla.am.freescale.net> <4E09D884.8090700@adacore.com> <20110628124910.04228660@schlenkerla.am.freescale.net> <4E0C9B6E.3000100@adacore.com> <20110630142646.6a0a80a0@schlenkerla.am.freescale.net> In-Reply-To: <20110630142646.6a0a80a0@schlenkerla.am.freescale.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] [PowerPC][RFC] booke timers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Scott Wood Cc: qemu-devel@nongnu.org On 30/06/2011 21:26, Scott Wood wrote: > On Thu, 30 Jun 2011 17:51:10 +0200 > Fabien Chouteau wrote: > >> On 28/06/2011 19:49, Scott Wood wrote: >>> On Tue, 28 Jun 2011 15:35:00 +0200 >>> Fabien Chouteau wrote: >>> >>>> On 27/06/2011 22:28, Scott Wood wrote: >>>>> On Mon, 27 Jun 2011 18:14:06 +0200 >>>>> Fabien Chouteau wrote: >>>>> >>>>>> While working on the emulation of the freescale p2010 (e500v2) I realized that >>>>>> there's no implementation of booke's timers features. Currently mpc8544 uses >>>>>> ppc_emb (ppc_emb_timers_init) which is close but not exactly like booke (for >>>>>> example booke uses different SPR). >>>>> >>>>> ppc_emb_timers_init should be renamed something less generic, then. >>>> >>>> Agreed, can you help me to find a better name? >>> >>> What chips are covered by it? 40x? >> >> The function is used by ppc4xx_init (ppc4xx_devs.c) and ppc440_init_xilinx >> (virtex_ml507.c), so I guess ppc_4xx_timers_int will be fine... > > Doesn't 440 have normal booke timers? > Actually ppc_emb_timers_init should be renamed ppc40x_timers_init, and Xilinx's ppc440 should use the new implementation of booke timers. >>>>> I think some changes in the decrementer code are needed to provide booke >>>>> semantics -- no raising the interrupt based on the high bit of decr, and >>>>> stop counting when reach zero. >>>> >>>> Can you please explain, I don't see where I'm not compliant with booke's >>>> decrementer. >>> >>> It's not an issue with this code specifically, but existing behavior in the >>> decrementer code that isn't appropriate for booke. >>> >>> On classic/server powerpc, when decrementer hits zero, it wraps around, and >>> the upper bit of DECR is used to signal the interrupt. On booke, when >>> decrementer hits zero, it stops, and the upper bit of DECR is not special. >>> >> >> And that's why I implemented the booke_decr_cb function that will emulate this >> behavior. > > booke_decr_cb() doesn't control what happens when DECR is read after an > expiration, nor does it control whether an interrupt is raised if software > writes DECR with the high bit set. > OK, I will add a condition to avoid this on booke processors. >>>> It's just a mask to keep only the defined bits. >>> >>> Just seems unnecessary, and potentially harmful if CPU-specific code wants >>> to interpret implementation-defined bits, or if new bits are architected >>> in the future. >>> >> >> On the other hand, undefined bit should always be read as zeros. > > I don't think there's any such requirement. My bad ;) "The handling of reserved bits in System Registers (e.g. Integer Exception Register, Floating-Point Status and Control Register) is implementation-dependent. Software is permitted to write any value to such a bit with no visible effect on processors that implement this version of Book E. A subsequent reading of the bit returns a 0 if the last value written to the bit was 0 and returns an undefined value (0 or 1) otherwise." -- Fabien Chouteau