From owner-freebsd-embedded@FreeBSD.ORG Sun Feb 28 18:48:33 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 5A951106566B; Sun, 28 Feb 2010 18:48:33 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from mail.meer.net (mail.meer.net [64.13.141.3]) by mx1.freebsd.org (Postfix) with ESMTP id 220F78FC14; Sun, 28 Feb 2010 18:48:32 +0000 (UTC) Received: from mail2.meer.net (mail2.meer.net [64.13.141.16]) by mail.meer.net (8.13.3/8.13.3/meer) with ESMTP id o1SIjVrX014441; Sun, 28 Feb 2010 10:45:31 -0800 (PST) (envelope-from gnn@neville-neil.com) Received: from [192.168.99.148] (host-216-220-114-135.dsl.bway.net [216.220.114.135]) (authenticated bits=0) by mail2.meer.net (8.14.1/8.14.3) with ESMTP id o1SIjJqJ073275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Feb 2010 10:45:29 -0800 (PST) (envelope-from gnn@neville-neil.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: George Neville-Neil In-Reply-To: <20100228.013631.850602504923951271.imp@bsdimp.com> Date: Sun, 28 Feb 2010 13:45:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4169243C-D569-40E7-9115-09DB72F691FE@neville-neil.com> References: <9D9E6892-ABE5-44B3-965B-383D80366D1B@neville-neil.com> <20100228.013631.850602504923951271.imp@bsdimp.com> To: "M. Warner Losh" X-Mailer: Apple Mail (2.1077) Cc: jkoshy@FreeBSD.org, embedded@FreeBSD.org, rpaulo@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 18:48:33 -0000 On Feb 28, 2010, at 03:36 , M. Warner Losh wrote: > In message: > Rui Paulo writes: > : > http://people.freebsd.org/~gnn/mipshwpmc_3.diff > : >=20 > : > 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. >=20 > @@ -2681,6 +2724,10 @@ > } else if (pe >=3D PMC_EV_XSCALE_FIRST && pe <=3D = PMC_EV_XSCALE_LAST) { > ev =3D xscale_event_table; > evfence =3D xscale_event_table + = PMC_EVENT_TABLE_SIZE(xscale); > + } else if (pe >=3D PMC_EV_MIPS24K_FIRST && pe <=3D = PMC_EV_MIPS24K_LAST) { > + ev =3D mips24k_event_table; > + evfence =3D mips24k_event_table + = PMC_EVENT_TABLE_SIZE(mips24k > +); >=20 > Looks like a stray new line. >=20 I can fix that. > 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? >=20 Well I followed the current standard so perhaps Joseph can comment more clearly on this. > 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. The decoding is done in libpmc but grabbing the counters out of the = hardware is done in the kernel. Unless I don't quite get what you're asking. BTW Realize that the patch is both library (user space) and kernel = (dev/hwpmc) so it can be a bit confusing, perhaps to look at. Best, George