From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Scott Subject: Re: [PATCH ARM v7 09/13] mini-os: arm: time Date: Mon, 22 Sep 2014 10:35:16 +0000 Message-ID: <2E60909D-BE55-4E5C-8A38-98808E5893A3@citrix.com> References: <1407512862-9373-1-git-send-email-talex5@gmail.com> <1407512862-9373-10-git-send-email-talex5@gmail.com> <1410173983.10156.167.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XW0xj-0003Zh-Kf for xen-devel@lists.xenproject.org; Mon, 22 Sep 2014 10:35:19 +0000 In-Reply-To: Content-Language: en-US Content-ID: <810BBC61AED1304AB48C8DE3269184B0@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Thomas Leonard Cc: Dave Scott , Ian Campbell , Anil Madhavapeddy , Stefano Stabellini , Samuel Thibault , "xen-devel@lists.xenproject.org" List-Id: xen-devel@lists.xenproject.org Hi, On 8 Sep 2014, at 17:08, Thomas Leonard wrote: > On 8 September 2014 11:59, Ian Campbell wrote: >> On Fri, 2014-08-08 at 16:47 +0100, Thomas Leonard wrote: >> = >> Sorry for how long I took to get to this, travel and the resulting >> backlog conspired against me. > = > Hi Ian, > = > I'm on holiday for a few weeks now. Please feel free to apply any > minor changes if you don't want to wait. In any case, I'll take > another look at the end of Sep. > = > Regards, > = >>> + __asm__ __volatile__("isb;mrrc p15, 1, %0, %1, c14":"=3Dr"(c_lo), = "=3Dr"(c_hi)); >> = >> Is the isb really necessary here? > = > I don't think so. > = >>> + return (((uint64_t) c_hi) << 32) + c_lo; >>> +} >>> + >>> +/* monotonic_clock(): returns # of nanoseconds passed since time_init() >>> + * Note: This function is required to return accurate >>> + * time even in the absence of multiple timer ticks. >>> + */ >>> +uint64_t monotonic_clock(void) >>> +{ >>> + s_time_t time =3D ticks_to_ns(read_virtual_count() - cntvct_at_ini= t); >>> + //printk("monotonic_clock: %llu (%llu)\n", time, NSEC_TO_SEC(time)= ); >> = >> There's quite a few of these //printk(debug) statements in this patch... >> = >>> + return time; >>> +} >>> + >>> +int gettimeofday(struct timeval *tv, void *tz) >>> +{ >>> + uint64_t nsec =3D monotonic_clock(); >>> + nsec +=3D shadow_ts.tv_nsec; >>> + >>> + tv->tv_sec =3D shadow_ts.tv_sec; >>> + tv->tv_sec +=3D NSEC_TO_SEC(nsec); >>> + tv->tv_usec =3D NSEC_TO_USEC(nsec % 1000000000UL); >>> + >>> + return 0; >>> +} >>> + >>> +void set_vtimer_compare(uint64_t value) { >>> + uint32_t x, y; >>> + >>> + DEBUG("New CompareValue : %llx\n", value); >>> + x =3D 0xFFFFFFFFULL & value; >>> + y =3D (value >> 32) & 0xFFFFFFFF; >>> + >>> + __asm__ __volatile__("mcrr p15, 3, %0, %1, c14" >>> + ::"r"(x), "r"(y)); >> = >> I think you can use >> "mcrr p15, 3, %0, %H0, c14" :: "r" (value) >> here. >> = >> = >>> + >>> + __asm__ __volatile__("mov %0, #0x1\n" >>> + "mcr p15, 0, %0, c14, c3, 1\n" /* Enable timer and unmask = the output signal */ >>> + "isb":"=3Dr"(x)); >> = >> x =3D 1 before this would avoid the mov inside the inline stuff as well = as >> the strange looking use of an output register for a write. >> = >>> +} >>> + >>> +void unset_vtimer_compare(void) { >>> + uint32_t x; >>> + >>> + __asm__ __volatile__("mov %0, #0x2\n" >>> + "mcr p15, 0, %0, c14, c3, 1\n" /* Disable timer and mask t= he output signal */ >>> + "isb":"=3Dr"(x)); >> = >> and again. You probably just want a write_timer_ctl(uiint.. val) type >> function. >> = >>> +} >>> + >>> +void block_domain(s_time_t until) >>> +{ >>> + uint64_t until_count =3D ns_to_ticks(until) + cntvct_at_init; >>> + ASSERT(irqs_disabled()); >>> + if (read_virtual_count() < until_count) >>> + { >>> + set_vtimer_compare(until_count); >>> + //char buf[] =3D "sleep\n"; (void)HYPERVISOR_console_io(CONSOL= EIO_write, strlen(buf), buf); >>> + __asm__ __volatile__("wfi"); >>> + //char wake[] =3D "wake\n"; (void)HYPERVISOR_console_io(CONSOL= EIO_write, strlen(wake), wake); >> = >> More left over debug. I had a play with this yesterday on my cubieboard with Mirage. Using networ= k and vchan connections worked fine, so event channels are working ok. Howe= ver when I had no external event channel input and my domain blocked on a t= imer, it seemed to block forever in the =91wfi=92 (as I could see by enabli= ng these debug lines and then pressing =91enter=92 to trigger an interrupt = on the console). As far as I can tell the monotonic clock is giving me sens= ible values, and the =91until=92 value looked sensible. For now I can work = around the problem by attaching a vif to a busy network :-) Sorry for the vagueness of the bug report. I=92ll try to make a more minima= l repro example when I get the time. Dave >> = >>> + unset_vtimer_compare(); >>> + >>> + /* Give the IRQ handler a chance to handle whatever woke us up= . */ >>> + local_irq_enable(); >>> + local_irq_disable(); >>> + } >>> +} >> = >> Ian. >> = > = > = > = > -- = > Dr Thomas Leonard http://0install.net/ > GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 > GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA