From owner-freebsd-embedded@FreeBSD.ORG Sun Feb 28 08:39:10 2010 Return-Path: Delivered-To: embedded@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8511106564A; Sun, 28 Feb 2010 08:39:10 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id A73488FC0C; Sun, 28 Feb 2010 08:39:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.3/8.14.1) with ESMTP id o1S8aInd028907; Sun, 28 Feb 2010 01:36:18 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Sun, 28 Feb 2010 01:36:31 -0700 (MST) Message-Id: <20100228.013631.850602504923951271.imp@bsdimp.com> To: rpaulo@FreeBSD.org From: "M. Warner Losh" In-Reply-To: References: <9D9E6892-ABE5-44B3-965B-383D80366D1B@neville-neil.com> X-Mailer: Mew version 6.3 on Emacs 22.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: jkoshy@FreeBSD.org, embedded@FreeBSD.org, fabient@FreeBSD.org Subject: Re: 3rd, and hopefully final, MIPS 24K hwpmc patch... X-BeenThere: freebsd-embedded@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Dedicated and Embedded Systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2010 08:39:11 -0000 In message: Rui Paulo writes: : > http://people.freebsd.org/~gnn/mipshwpmc_3.diff : > : > The biggest change was breaking out MIPS24K from generic MIPS, which will allow for the easy addition : > of other types of MIPS chips in the near future. @@ -2681,6 +2724,10 @@ } else if (pe >= PMC_EV_XSCALE_FIRST && pe <= PMC_EV_XSCALE_LAST) { ev = xscale_event_table; evfence = xscale_event_table + PMC_EVENT_TABLE_SIZE(xscale); + } else if (pe >= PMC_EV_MIPS24K_FIRST && pe <= PMC_EV_MIPS24K_LAST) { + ev = mips24k_event_table; + evfence = mips24k_event_table + PMC_EVENT_TABLE_SIZE(mips24k +); Looks like a stray new line. There does seem to be a number of places where we mix mips, arm, and x86 CPUs in case statements and the like. Yet there are other places we carefully ifdef them. What's the determining factors here? Also, the mips24k counters are specific to the mips24k, but the harvesting of the counters is fairly generic to the mips architecture (when counters are present). Why encode all the counter knowledge in the kernel when it might make better sense to have the userland routines do that decoding based on the core that's used? Maybe I'm misunderstanding something here, but I do know that linux asks the CPU how many performance counters there are and harvests them generically across a wide range of MIPS cores. Warner