From owner-freebsd-acpi@FreeBSD.ORG  Tue Sep 18 08:18:23 2012
Return-Path: <owner-freebsd-acpi@FreeBSD.ORG>
Delivered-To: freebsd-acpi@FreeBSD.org
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id DAF311065672;
	Tue, 18 Sep 2012 08:18:23 +0000 (UTC) (envelope-from avg@FreeBSD.org)
Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140])
	by mx1.freebsd.org (Postfix) with ESMTP id F01758FC0C;
	Tue, 18 Sep 2012 08:18:22 +0000 (UTC)
Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua
	[212.40.38.100])
	by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA16677;
	Tue, 18 Sep 2012 11:18:21 +0300 (EEST)
	(envelope-from avg@FreeBSD.org)
Received: from localhost ([127.0.0.1])
	by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD))
	id 1TDt0f-0005gv-EE; Tue, 18 Sep 2012 11:18:21 +0300
Message-ID: <50582E4C.8060107@FreeBSD.org>
Date: Tue, 18 Sep 2012 11:18:20 +0300
From: Andriy Gapon <avg@FreeBSD.org>
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
	rv:15.0) Gecko/20120913 Thunderbird/15.0.1
MIME-Version: 1.0
To: "freebsd-acpi@freebsd.org" <freebsd-acpi@FreeBSD.org>
References: <504EDAFE.3000601@FreeBSD.org>
In-Reply-To: <504EDAFE.3000601@FreeBSD.org>
X-Enigmail-Version: 1.4.3
Content-Type: text/plain; charset=x-viet-vps
Content-Transfer-Encoding: 7bit
Cc: freebsd-hackers@FreeBSD.org
Subject: Re: do we always have acpi_cpu for a cpu?
X-BeenThere: freebsd-acpi@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ACPI and power management development <freebsd-acpi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
	<mailto:freebsd-acpi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-acpi>
List-Post: <mailto:freebsd-acpi@freebsd.org>
List-Help: <mailto:freebsd-acpi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-acpi>,
	<mailto:freebsd-acpi-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 18 Sep 2012 08:18:24 -0000


[ping]

on 11/09/2012 09:32 Andriy Gapon said the following:
> 
> I think that we always expect to have a one-to-one correspondence between
> acpi_cpu devices and actual (APIC) CPUs.  acpi_pcpu_get_id() seems to even
> assert that, if I am reading the code correctly.
> 
> The following patch adds the assert to acpi_cpu_idle as well and also removes
> what I believe to be an obsolete comment about HTT CPUs.
> 
>     acpi_cpu: expect every cpu to have a corresponding acpi_cpu object
> 
>     ... via Processor object in ASL namespace.
> 
> diff --git a/sys/dev/acpica/acpi_cpu.c b/sys/dev/acpica/acpi_cpu.c
> index 15201f9..203ed02 100644
> --- a/sys/dev/acpica/acpi_cpu.c
> +++ b/sys/dev/acpica/acpi_cpu.c
> @@ -925,23 +925,15 @@ acpi_cpu_idle()
>      uint32_t	start_time, end_time;
>      int		bm_active, cx_next_idx, i;
> 
> +    sc = cpu_softc[PCPU_GET(cpuid)];
> +    KASSERT(sc != NULL, ("acpi_cpu_idle: CPU without ACPI CPU"));
> +
>      /* If disabled, return immediately. */
>      if (cpu_disable_idle) {
>  	ACPI_ENABLE_IRQS();
>  	return;
>      }
> 
> -    /*
> -     * Look up our CPU id to get our softc.  If it's NULL, we'll use C1
> -     * since there is no ACPI processor object for this CPU.  This occurs
> -     * for logical CPUs in the HTT case.
> -     */
> -    sc = cpu_softc[PCPU_GET(cpuid)];
> -    if (sc == NULL) {
> -	acpi_cpu_c1();
> -	return;
> -    }
> -
>      /* Find the lowest state that has small enough latency. */
>      cx_next_idx = 0;
>      if (cpu_disable_deep_sleep)
> 


-- 
Andriy Gapon