From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0A047C7618B for ; Tue, 23 Jul 2019 14:27:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D325E21849 for ; Tue, 23 Jul 2019 14:27:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563892032; bh=N+Ue7x6CR5Jb4q9/FJUaj8bwy6sXpTBfgYk9DGdpaTA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=lnTxrgBa9Vt2WJcEGzSaEd7wD9PBQXHndRsfjCUnhRyn0xiP+1pupisvvZxfD2mwj hod+fyE+JIp528TBehF1gAtl1LKKG8PaTmuyLhRWROzDfleTLzGs710HbTsTHWwtne vhuI7h4BUoihJKC6J8JXmEJh8cpE6LbObWEAdoJc= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2388126AbfGWO1M (ORCPT ); Tue, 23 Jul 2019 10:27:12 -0400 Received: from mail.kernel.org ([198.145.29.99]:42750 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729666AbfGWO1M (ORCPT ); Tue, 23 Jul 2019 10:27:12 -0400 Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 35C1C227C2; Tue, 23 Jul 2019 14:27:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1563892031; bh=N+Ue7x6CR5Jb4q9/FJUaj8bwy6sXpTBfgYk9DGdpaTA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=O1tSrR6mLbZR2SFl5YStt8tI1T83OBm70Z8ESu4jcAzFa76wk+ollTJfV90NuHKPx xeJRnVTTCeDOA5854nbQ/Irg5lO5cqWRHIUSmuzsmVc3dnP6/LcYuSBKXeO4et/siu InSv1WptHw8epZnmkfzgcuUtAzp1VubwZCYLYtDs= Received: by mail-qt1-f175.google.com with SMTP id x22so37187292qtp.12; Tue, 23 Jul 2019 07:27:11 -0700 (PDT) X-Gm-Message-State: APjAAAUw3F81CU0FCn9XvIaIwEggNIst5q4NehvDJ8R3Vf131HnF+fsy NRJAPGAzOnFySJ6PyHgNlIAwf3qw63Cw+QJdlw== X-Google-Smtp-Source: APXvYqzYpyWF+jLJrs6e1TZWlyLbEwUvquqzpcgaB5p3hKJ4WN2M09TU5Mw7X6X1t5LhM8wDdbeIHPeJsHsMaGrnJvw= X-Received: by 2002:ac8:3908:: with SMTP id s8mr8582738qtb.224.1563892030231; Tue, 23 Jul 2019 07:27:10 -0700 (PDT) MIME-Version: 1.0 References: <20190703011020.151615-1-saravanak@google.com> <20190703011020.151615-2-saravanak@google.com> <98b2e315-e8da-80ad-1ef8-e6b222c1c6fe@codeaurora.org> <20190722233501.GA19594@bogus> In-Reply-To: From: Rob Herring Date: Tue, 23 Jul 2019 08:26:58 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 1/6] dt-bindings: opp: Introduce opp-peak-KBps and opp-avg-KBps bindings To: Saravana Kannan Cc: Sibi Sankar , Georgi Djakov , Mark Rutland , Viresh Kumar , Nishanth Menon , Stephen Boyd , "Rafael J. Wysocki" , Vincent Guittot , "Sweeney, Sean" , daidavid1@codeaurora.org, Rajendra Nayak , Bjorn Andersson , Evan Green , Android Kernel Team , Linux PM , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , LKML Content-Type: text/plain; charset="UTF-8" Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org On Mon, Jul 22, 2019 at 5:41 PM Saravana Kannan wrote: > > On Mon, Jul 22, 2019 at 4:35 PM Rob Herring wrote: > > > > On Tue, Jul 16, 2019 at 11:58:08AM -0700, Saravana Kannan wrote: > > > On Tue, Jul 16, 2019 at 10:25 AM Sibi Sankar wrote: > > > > > > > > Hey Saravana, > > > > > > > > https://patchwork.kernel.org/patch/10850815/ > > > > There was already a discussion ^^ on how bandwidth bindings were to be > > > > named. > > > > > > Yes, I'm aware of that series. That series is trying to define a BW > > > mapping for an existing frequency OPP table. This patch is NOT about > > > adding a mapping to an existing table. This patch is about adding the > > > notion of BW OPP tables where BW is the "key" instead of "frequency". > > > > > > So let's not mixed up these two series. > > > > Maybe different reasons, but in the end we'd end up with 2 bandwidth > > properties. We need to sort out how they'd overlap/coexist. > > Oh, I totally agree! My point is that the other mapping isn't the > right approach because it doesn't handle a whole swath of use cases. > The one I'm proposing can act as a super set of the other (as in, can > handle that use case too). > > > The same comment in that series about defining a standard unit suffix > > also applies to this one. > > I thought I read that whole series and I don't remember reading about > the unit suffix. But I'll take a closer look. I've chosen to keep the > DT units at least as "high of a resolution" as what the APIs accept > today. The APIs take KB/s. So I make sure DT can capture KB/s > differences. If we all agree that KB/s is "too accurate" then I think > we should change everything to MB/s. Either one is fine with me, but trying to align to what the OS picked doesn't work. What does BSD use for example? More important is aligning across DT properties so we don't have folks picking whatever random unit they like. We generally try to go with the smallest units that will have enough (32-bit) range for everyone, so that's probably KB/s here. Rob