From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754825AbcGTS4M (ORCPT ); Wed, 20 Jul 2016 14:56:12 -0400 Received: from mail-oi0-f68.google.com ([209.85.218.68]:34976 "EHLO mail-oi0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752485AbcGTS4K (ORCPT ); Wed, 20 Jul 2016 14:56:10 -0400 Date: Wed, 20 Jul 2016 13:56:07 -0500 From: Rob Herring To: Juri Lelli Cc: 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, broonie@kernel.org, Pawel Moll , Ian Campbell , Kumar Gala , Maxime Ripard , Olof Johansson , Gregory CLEMENT , Paul Walmsley , Linus Walleij , Chen-Yu Tsai , Thomas Petazzoni Subject: Re: [PATCH v6 1/8] Documentation: arm: define DT cpu capacity-dmips-mhz bindings Message-ID: <20160720185607.GA30072@rob-hp-laptop> References: <1468932048-31635-1-git-send-email-juri.lelli@arm.com> <1468932048-31635-2-git-send-email-juri.lelli@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1468932048-31635-2-git-send-email-juri.lelli@arm.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 19, 2016 at 01:40:41PM +0100, Juri Lelli wrote: > ARM systems may be configured to have cpus with different power/performance > characteristics within the same chip. In this case, additional information > has to be made available to the kernel (the scheduler in particular) for it > to be aware of such differences and take decisions accordingly. > > Therefore, this patch aims at standardizing cpu capacities device tree > bindings for ARM platforms. Bindings define cpu capacity-dmips-mhz > parameter, to allow operating systems to retrieve such information from > the device tree and initialize related kernel structures, paving the way > for common code in the kernel to deal with heterogeneity. > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Cc: Ian Campbell > Cc: Kumar Gala > Cc: Maxime Ripard > Cc: Olof Johansson > Cc: Gregory CLEMENT > Cc: Paul Walmsley > Cc: Linus Walleij > Cc: Chen-Yu Tsai > Cc: Thomas Petazzoni > Cc: devicetree@vger.kernel.org > Signed-off-by: Juri Lelli > --- > > Changes from v1: > - removed section regarding capacity-scale > - added information regarding normalization > > Changes from v4: > - binding changed to capacity-dmips-mhz > - sections and changelod updated accordingly > > Changes from v5: > - addressed Mark and Vincent comments > --- > .../devicetree/bindings/arm/cpu-capacity.txt | 236 +++++++++++++++++++++ > Documentation/devicetree/bindings/arm/cpus.txt | 10 + > 2 files changed, 246 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/cpu-capacity.txt I guess I'm okay with the scaled values, so: Acked-by: Rob Herring [...] > +Example 2 (ARM 32-bit, 4-cpu system, two clusters, > + cpus 0,1@1GHz, cpus 2,3@500MHz): > +capacities-dmips-mhz are scaled w.r.t. 2 (cpu@0 and cpu@1), this means that first > +cpu@0 and cpu@1 are twice fast than cpu@2 and cpu@3 (at the same frequency) This example is a bit confusing with both the capacity and frequency being half. I also find it a bit unrealistic to have a 2x performance difference on the same micro arch. But it is all just an example... Rob From mboxrd@z Thu Jan 1 00:00:00 1970 From: robh@kernel.org (Rob Herring) Date: Wed, 20 Jul 2016 13:56:07 -0500 Subject: [PATCH v6 1/8] Documentation: arm: define DT cpu capacity-dmips-mhz bindings In-Reply-To: <1468932048-31635-2-git-send-email-juri.lelli@arm.com> References: <1468932048-31635-1-git-send-email-juri.lelli@arm.com> <1468932048-31635-2-git-send-email-juri.lelli@arm.com> Message-ID: <20160720185607.GA30072@rob-hp-laptop> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Tue, Jul 19, 2016 at 01:40:41PM +0100, Juri Lelli wrote: > ARM systems may be configured to have cpus with different power/performance > characteristics within the same chip. In this case, additional information > has to be made available to the kernel (the scheduler in particular) for it > to be aware of such differences and take decisions accordingly. > > Therefore, this patch aims at standardizing cpu capacities device tree > bindings for ARM platforms. Bindings define cpu capacity-dmips-mhz > parameter, to allow operating systems to retrieve such information from > the device tree and initialize related kernel structures, paving the way > for common code in the kernel to deal with heterogeneity. > > Cc: Rob Herring > Cc: Pawel Moll > Cc: Mark Rutland > Cc: Ian Campbell > Cc: Kumar Gala > Cc: Maxime Ripard > Cc: Olof Johansson > Cc: Gregory CLEMENT > Cc: Paul Walmsley > Cc: Linus Walleij > Cc: Chen-Yu Tsai > Cc: Thomas Petazzoni > Cc: devicetree at vger.kernel.org > Signed-off-by: Juri Lelli > --- > > Changes from v1: > - removed section regarding capacity-scale > - added information regarding normalization > > Changes from v4: > - binding changed to capacity-dmips-mhz > - sections and changelod updated accordingly > > Changes from v5: > - addressed Mark and Vincent comments > --- > .../devicetree/bindings/arm/cpu-capacity.txt | 236 +++++++++++++++++++++ > Documentation/devicetree/bindings/arm/cpus.txt | 10 + > 2 files changed, 246 insertions(+) > create mode 100644 Documentation/devicetree/bindings/arm/cpu-capacity.txt I guess I'm okay with the scaled values, so: Acked-by: Rob Herring [...] > +Example 2 (ARM 32-bit, 4-cpu system, two clusters, > + cpus 0,1 at 1GHz, cpus 2,3 at 500MHz): > +capacities-dmips-mhz are scaled w.r.t. 2 (cpu at 0 and cpu at 1), this means that first > +cpu at 0 and cpu at 1 are twice fast than cpu at 2 and cpu at 3 (at the same frequency) This example is a bit confusing with both the capacity and frequency being half. I also find it a bit unrealistic to have a 2x performance difference on the same micro arch. But it is all just an example... Rob