Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754827AbbLJPad (ORCPT ); Thu, 10 Dec 2015 10:30:33 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:41290 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754268AbbLJPa3 (ORCPT ); Thu, 10 Dec 2015 10:30:29 -0500 Date: Thu, 10 Dec 2015 15:30:04 +0000 From: Mark Brown To: Rob Herring Cc: Juri Lelli , linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, peterz@infradead.org, vincent.guittot@linaro.org, mark.rutland@arm.com, linux@arm.linux.org.uk, sudeep.holla@arm.com, lorenzo.pieralisi@arm.com, catalin.marinas@arm.com, will.deacon@arm.com, morten.rasmussen@arm.com, dietmar.eggemann@arm.com, Pawel Moll , Ian Campbell , Kumar Gala , Maxime Ripard , Olof Johansson , Gregory CLEMENT , Paul Walmsley , Linus Walleij , Chen-Yu Tsai , Thomas Petazzoni Message-ID: <20151210153004.GA26758@sirena.org.uk> References: <1448288921-30307-1-git-send-email-juri.lelli@arm.com> <1448288921-30307-3-git-send-email-juri.lelli@arm.com> <20151124020631.GA15165@rob-hp-laptop> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gKMricLos+KVdGMg" Content-Disposition: inline In-Reply-To: <20151124020631.GA15165@rob-hp-laptop> X-Cookie: Youth is the trustee of posterity. User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [RFC PATCH 2/8] Documentation: arm: define DT cpu capacity bindings X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4005 Lines: 84 --gKMricLos+KVdGMg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 23, 2015 at 08:06:31PM -0600, Rob Herring wrote: > I think you need something absolute and probably per MHz (like=20 > dynamic-power-coefficient property). Perhaps the IPC (instructions per=20 > clock) value? > In other words, I want to see these numbers have a defined method=20 > of determining them and don't want to see random values from every=20 > vendor. ARM, Ltd. says core X has a value of Y would be good enough for= =20 > me. Vendor X's A57 having a value of 2 and Vendor Y's A57 having a=20 > value of 1024 is not what I want to see. Of course things like cache=20 > sizes can vary the performance, but is a baseline value good enough?=20 > However, no vendor will want to publish their values if these are=20 > absolute values relative to other vendors. > If you expect these to need frequent tuning, then don't put them in DT. I agree strongly. Putting what are essentially tuning numbers for the system into the ABI is going to lead us into a mess long term since if we change anything related to the performance of the system the numbers may become invalid and we've no real way of recovering sensible information. There is of course also the issue where people are getting the numbers =66rom in the first place - were the numbers picked for some particular use case or to optimise some particular benchmark, what other conditions existed at the time (cpufreq setup for example), what tuning goals did the people picking the numbers have and do any of those things correspond to what a given user wants? If detailed tuning the numbers for specific systems matters much will we get competing users patching the in kernel DTs over and over, and what do we do about ACPI systems? Having an absolute definition doesn't really help with this since the concrete effect DT authors see is that these are tuning numbers. It would be better to have the DT describe concrete physical properties of the system which we can then map onto numbers we like, that way if we get better information in future or just decide that completely different metrics are appropriate for tuning we can just do that without having to worry about translating the old metrics into new ones. We can then expose the tuning knobs to userspace for override if that's needed. If doing system specific tuning on vertically integrated systems really is terribly important it's not going to matter too much where the tuning is but we also have to consider more general purpose systems. We're not going to get out of having to pick numbers at some point, pushing them into DT doesn't get us out of that but it does make the situation harder to manage long term and makes the performance for the general user less relaible. It's also just more work all round, everyone doing the DT for a SoC is going to have to do some combination of cargo culting or repeating the callibration. I remember Peter remarking at one of the LPC discussions of this idea that there had been some bad experiences with getting numbers from=20 firmware on other systems. --gKMricLos+KVdGMg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWaZp7AAoJECTWi3JdVIfQfJMIAIZMYd+LY0Mk6ts6qB+ndE4D VCthS4iAzrD80rwQzywyz7BdoAzRbQzFqrvyMVB6IM2llEgzmtNCrbyHiL2RH5jH 3x9ToK6hBI6OLC55hrp4KRJuDqce63Y9LBIcd3UwxTLIp5WXpQhVH5nlh0GLpErB 5SuqnE0eBIzgwG8PjA16pNsJWNUYjufrxsM96iSzW/TtzVouXxOxAhigYd0zdJpT 6yGqsY9Nsfj9OpbiRG/JAY7tKucg26UCSQ893X/yTVsG9a3bWZdYIy62DZpF8rGl P3t9675UNhJG9WtzgaogNudsYeAso0ObV+XIDE8rE+zEe6E/QNacDTktUY9gGWM= =8hFr -----END PGP SIGNATURE----- --gKMricLos+KVdGMg-- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/