WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ppc-devel

Re: [XenPPC] NAP state

To: Amos Waterland <apw@xxxxxxxxxx>
Subject: Re: [XenPPC] NAP state
From: Hollis Blanchard <hollisb@xxxxxxxxxx>
Date: Tue, 10 Oct 2006 13:22:01 -0500
Cc: xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Tue, 10 Oct 2006 11:22:17 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20061010171220.GA16306@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-ppc-devel-request@lists.xensource.com?subject=help>
List-id: Xen PPC development <xen-ppc-devel.lists.xensource.com>
List-post: <mailto:xen-ppc-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel>, <mailto:xen-ppc-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ppc-devel>, <mailto:xen-ppc-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: IBM Linux Technology Center
References: <20061010171220.GA16306@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-ppc-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Tue, 2006-10-10 at 13:12 -0400, Amos Waterland wrote:
> Just as a sanity check, is the intention is to put the processor in the
> NAP state when .sleep() is invoked?

Yes.

> If so, is the following behavior expected?
> 
> @@ -395,12 +396,34 @@ static void __init __start_xen(multiboot
>      console_endboot();
>  
> +    while (1) {
> +        long before, after;
> +        before = mftb(); sleep(); after = mftb();
> +        printk("hid0 = %lx: slept for %ld timebase ticks (%ld seconds)\n", 
> +               mfhid0(), after - before, (after - before) / timebase_freq);
> +    }
> 
>      /* Hide UART from DOM0 if we're using it */
>      serial_endboot();
> 
> (XEN) hid0 = 51010180000000: slept for 1952282840 timebase ticks (9 seconds)
> (XEN) hid0 = 51010180000000: slept for 52834590 timebase ticks (0 seconds)
> (XEN) hid0 = 51010180000000: slept for 2078791813 timebase ticks (10 seconds)
> (XEN) hid0 = 51010180000000: slept for 52797943 timebase ticks (0 seconds)
> (XEN) hid0 = 51010180000000: slept for 2078719926 timebase ticks (10 seconds)
> (XEN) hid0 = 51010180000000: slept for 52860659 timebase ticks (0 seconds)
> (XEN) hid0 = 51010180000000: slept for 2078655488 timebase ticks (10 seconds)
> (XEN) hid0 = 51010180000000: slept for 52932165 timebase ticks (0 seconds)
> (XEN) hid0 = 51010180000000: slept for 2078598776 timebase ticks (10 seconds)
> ...

When the decrementer goes off in HV mode, it is set to 0x7fff0000. The
decrementer frequency on my Maple seems to be 0x0a6e49c0. At that rate,
it should take ~12 seconds for the decrementer to fire again, waking the
processor. That seems to match your output.

I'm not sure about the zero second results. Perhaps there was an
interrupt pending when you went to sleep? I think the UART would be
unmasked at that point...

We should probably set the decrementer to approx. the time the next Xen
timer will fire before going to sleep.

-- 
Hollis Blanchard
IBM Linux Technology Center


_______________________________________________
Xen-ppc-devel mailing list
Xen-ppc-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ppc-devel

<Prev in Thread] Current Thread [Next in Thread>