Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp8877240ybi; Tue, 23 Jul 2019 17:13:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqyRoh5q2G3J1FS0+WpARXiZobH7YerBJie7c5aXE9MpJpn2PQ55rD9vV/uD26X91d4Hbwr/ X-Received: by 2002:a17:90a:9a95:: with SMTP id e21mr25701766pjp.98.1563927217877; Tue, 23 Jul 2019 17:13:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563927217; cv=none; d=google.com; s=arc-20160816; b=ndpcjXkvGSaPw+jH3pJv1du1BVcGv74NZJAk5jsdBrHE0Eh65UhCIisdPTjwysLweq pYIOl9GonCkfy7YEIg/d+RdlhIv2kZDq7EXKAsmEFj1eTmx7AS8UvxjbfZSKpge86/aj kJvnc1iuetlVdiZrVH0N1kKS1VFd3Y5FlT34n8NAnXAsTFKcGXVMXp+y2ce46kH0X4ZS gLyXfBL73QY7eRJaC35iNzKtrxbRmJYGqaW1MfC9SKJJax+DUNDPjaozU09Zs5cJEsn2 KmkSsoXI2ElEqMDW57eyagbkOPnahdjvloAWYsep3CNvVuokHaBuD19vXAB1SYXdNytq GdEw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=N+Ue7x6CR5Jb4q9/FJUaj8bwy6sXpTBfgYk9DGdpaTA=; b=FH99IyIL17rkWX9dUP5X3O4wFL+KiSUnVq0Dkx6rr/GETpS/4dD/QmB3DcH9zNnaSz cbZcMEdtifemJben/jskNvlcG92qM7k1hu9H7s8ujyvrsG9XBqQoa72orc5kLOo+iuJg xdj3SdwpiISRu+KPxJyXI6Oduxg3Pv+iZpvnFiHfSKlKMDC0mjm0U5x82xRju8P9o3za yb8iOqww7XNnBQSGOMlnDObPSXz4xEKMxb7jubGm8vAP8JZFiILHnWIwbiC/gal/oNRo hh7Ik761gjuuxNnRL/9J1lq5KYJts3oEvNtVlBr77BBzcORfcop9udqn3jZ45ABG+cia mJ9A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=O1tSrR6m; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g5si13758341pgn.360.2019.07.23.17.13.22; Tue, 23 Jul 2019 17:13:37 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=O1tSrR6m; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2390512AbfGWO1M (ORCPT + 99 others); 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-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-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@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