Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp1447473pxj; Fri, 4 Jun 2021 14:57:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz2KvXjBfZHeKi02g+Rahs25wvYZLiZeZG4KhYQnqnWMfjeX5Fn1ihP0a2I7airhNvDlxhJ X-Received: by 2002:a17:906:4697:: with SMTP id a23mr2045066ejr.305.1622843856752; Fri, 04 Jun 2021 14:57:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622843856; cv=none; d=google.com; s=arc-20160816; b=oaI3oPX4qOaVj1q9gr41RIfT9yMw+5G/kzRRW/bKymQrHTrXBB4IHrzrVMLYSnXal5 clGUjC2iCcPyczbUhWx+ZEVs1MTEcz3M3tVCAOmvKtHL7BSd2ya8d/sA5nP7A6oWQ3VJ BkEj0GxSl7UFKzOtkxYjWoC5e0Z3ytHLXJ+J7s01zcR/ly2Spgohlh7fO8rmtc5wjzcb KsNbDI7/0HKw6GTz4GHs/JXWaE99I408KlZ0uroWyExzE6YPNEImzNkhZU+9Frxb9Xiy BcpFbxTL+qAOuY5AgtWSSqBia9sHWFiBA9uWAr1tOLLbM6ntxVBTe61EOEnNrPLyxDWJ qTAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:user-agent:from :references:in-reply-to:mime-version:dkim-signature; bh=3DYU5t9nuzfAYYmhd6HSphs3gWfN50+sEv5DeMPpACI=; b=N1OeE8De7CjLpWfWJbAMpMMPspVTiqY1gXAxqDXzLD8T42Y+ynZXUsXLzIm6Toa3vB 7g8rZK6s5ZXnRvUUbs4oS7mRZqwLFM12iMvEq5YMUdbkg33aRkrRBElCslBjBdecQesl 4mJ2plDQDeJWiP6cyB2J+7Ml5tUGx5O6gjVeWwF2QxWKcG6mlQlr3S8EyU6DXIZ/NMH7 3CLXZKlQNyYinsUcyB/UMhR3mudl6+SaSm9lSrKG2d17GdrW6KX38js78icyXSPgnEP3 LQxGcbs8+6/6wleO9RuvGvIpgnglqVCiGuCs2yVMe+yNHv1SO43N3ns1XPkRc7uScMFG acHQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=D5ZewtXr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id f13si5768354edy.493.2021.06.04.14.57.13; Fri, 04 Jun 2021 14:57:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=D5ZewtXr; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230075AbhFDV45 (ORCPT + 99 others); Fri, 4 Jun 2021 17:56:57 -0400 Received: from mail-ot1-f47.google.com ([209.85.210.47]:34533 "EHLO mail-ot1-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229930AbhFDV44 (ORCPT ); Fri, 4 Jun 2021 17:56:56 -0400 Received: by mail-ot1-f47.google.com with SMTP id v27-20020a056830091bb02903cd67d40070so7412960ott.1 for ; Fri, 04 Jun 2021 14:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:in-reply-to:references:from:user-agent:date:message-id :subject:to:cc; bh=3DYU5t9nuzfAYYmhd6HSphs3gWfN50+sEv5DeMPpACI=; b=D5ZewtXrnc2df+El9ZmfGqxur9CwKbv7QtTt11dEm496Zbj/vpTj51UtzaxzEAXBr6 L/eHi2e9aQCgj07t/dd+/GotaJPivYRZhFgcCJu2sGoi+af6wI6H/qjcliSmLtHLr3MF rkfGTjIHp7q8uBfn3aCI/FAuKpt6Yx53rawIc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from :user-agent:date:message-id:subject:to:cc; bh=3DYU5t9nuzfAYYmhd6HSphs3gWfN50+sEv5DeMPpACI=; b=VK/Xr6VTgutf6twZD/G9PLOtKgg2/nudvwQDp5AVWmHNfE8P7dvRH+QYGY3ll8OMbt 1yEfUb5arEsPeUoTIGKhVFMp47j388b29/tDjpy2Gf63Mb3YfIrMOUYMU+nkE/bfn9/P 11t0gDFH3lmiOf2cCyBs9Y9Yql7/g/gnCAmqWOMGHXJYFnaVzJVHoxfhPrPSgt0YV58X t6mQvpEqPJOQTZrsi68D7LCm7excbMYUqCLy9Ny/3o5g9vyGaiYaAmS6nw0EOSo5tdi0 bCp+UEbafx1ueJXilOkTkWDfQUi589uMK68sf+qn7DNEqZiXFftMuUYQWRBsY36numFj e0uw== X-Gm-Message-State: AOAM532QVaXboVqpKlyhEDybHuO9knDE+VqJiiHiWf1M5kD+PebKC7By zWz/obPvvva9iMDlzjJDMIUV6QZxW+sWIwgJyP+oLQ== X-Received: by 2002:a05:6830:3154:: with SMTP id c20mr5439195ots.233.1622843635345; Fri, 04 Jun 2021 14:53:55 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 4 Jun 2021 21:53:54 +0000 MIME-Version: 1.0 In-Reply-To: References: <1621596371-26482-1-git-send-email-mkshah@codeaurora.org> <1621596371-26482-4-git-send-email-mkshah@codeaurora.org> From: Stephen Boyd User-Agent: alot/0.9.1 Date: Fri, 4 Jun 2021 21:53:54 +0000 Message-ID: Subject: Re: [PATCH v8 3/5] arm64: dts: qcom: sc7180: Enable SoC sleep stats To: Bjorn Andersson Cc: Maulik Shah , evgreen@chromium.org, mka@chromium.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, agross@kernel.org, dianders@chromium.org, linux@roeck-us.net, rnayak@codeaurora.org, lsrao@codeaurora.org, devicetree@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Bjorn Andersson (2021-06-02 19:44:40) > On Wed 02 Jun 19:26 CDT 2021, Stephen Boyd wrote: > > > Quoting Bjorn Andersson (2021-05-31 10:57:03) > > > On Wed 26 May 18:30 CDT 2021, Stephen Boyd wrote: > > > > > > > Quoting Maulik Shah (2021-05-21 04:26:09) > > > > > @@ -3223,6 +3223,11 @@ > > > > > #power-domain-cells = <1>; > > > > > }; > > > > > > > > > > + rpmh-sleep-stats@c3f0000 { > > > > > + compatible = "qcom,rpmh-sleep-stats"; > > > > > + reg = <0 0x0c3f0000 0 0x400>; > > > > > + }; > > > > > + > > > > > > > > Does this need to be in DT? Can the sc7180-aoss-qmp driver use the > > > > aux-bus and stick the sleep stats device on there? > > > > > > > > > > The AOSS memory space has N chunks of "message ram", one is used for the > > > QMP protocol (presumably the APSS specific one), a different one is used > > > for the sleep stats. > > > > > > I presume we could have come up with a binding for the entire AOSS/AOP > > > and then describe (either implicit or explicitly) the QMP and > > > debug-stats under that. > > > > > > But we'd also have to come up with the same container-device for the RPM > > > case. > > > > Because the rpm node doesn't include this region of memory today? I > > still fail to see why we're changing the existing binding and adding a > > DT node for this new region that is basically a debug feature. > > We're not changing the binding, the memory region for the "AOSS QMP" > thing was never larger than 0x400. > > 0x100000 is the size of all the AOSS "msg_ram" regions. We don't have > this whole thing described in a binding and we don't have an > implementation for the whole thing. > > If we're going for that we'd need to extend the binding to indicate > which of the msg_ram regions are used for APSS QMP and for debug stats > on particular platform (either by compatible, explicit properties or as > some subnodes). Fair enough. At the least, can we change the name of the node then to 'sram' or 'ram'? The 'rpmh-sleep-stats' node name is nonsense. > > > That said, as I looked into my other objection, for the RPM > (non-hardened) case it seems that we're actually describing the RPM > region. So there it would make sense to describe it as such in DT - but > we don't have any other code (that I'm aware of) that would implement > the "qcom,-rpm". > I only half parsed this part. Are you saying that because we don't have a driver for qcom,-rpm we shouldn't keep it all within the rpm node?