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=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 0B638C4743D for ; Sun, 6 Jun 2021 03:44:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id DEFBF6136D for ; Sun, 6 Jun 2021 03:44:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230142AbhFFDqQ (ORCPT ); Sat, 5 Jun 2021 23:46:16 -0400 Received: from mail-oi1-f169.google.com ([209.85.167.169]:35691 "EHLO mail-oi1-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230025AbhFFDqO (ORCPT ); Sat, 5 Jun 2021 23:46:14 -0400 Received: by mail-oi1-f169.google.com with SMTP id v22so14378469oic.2 for ; Sat, 05 Jun 2021 20:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=NeFD/X/bZOxXpTRfRudMJyF7Fp7mjQ5t9npIatv+GWw=; b=h9FOpfPPswviZblqwRovErB5uSjagSMz/VMPp6ZmdE5TFmaXPe/oLhQH4NSGmWFpRe nE4j/rgDtjgkm8CeANZ/w22G4VOveRE5GcrHRKX1EQYcYEo/MXkR2lHaiiSjbUvX2YJ/ abU4CSpVqCEklGjUDBOnZcBG/JNs0VTJX/IgKSMuv6NTBNDz5MqxZgO2GoucnY/a1AnT Cx7O9Lfnxz3ro994dXeWK3D9p45HUNbY70cx/wE+zphui9JaZUQP74znulh79GxzqccP Yx0btF/44o7fcqtqAtBMfF4RzgJjuYQrDaHy07p4YsuPQ4kzOpcqx55LrV625JYW0BFV uo6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=NeFD/X/bZOxXpTRfRudMJyF7Fp7mjQ5t9npIatv+GWw=; b=ll4y+hGe00pdHVx0Ijlb0iTCTIFQIGdgcVvvJpFHgjiRWhuePaYt8G8TADlQepCTc7 r6qY9r9IhzSveJnOBDkQUEoK3zvnQoiB6w1wbtLeuHDudJfwuXW2aF/ik2/6oLgh5JQy 8S80OmdIMM2Tgr2zn2xcxrJBVEG/WBW3Egz93HC8nHNbzeLDLb7Q4YkGdmNEu6fr4Etf bEGWDu0Md0/7KmVPm5pWML0vrQdzHsF5rc/azvMLcoH6Ig93cdYW9BQJMnzaslA1VlzR krc5zil2ah5iA2fo9u1VYrDEv3+noO5QIdA26L67iIAQaGIU/Go0APF/GpGvXPS4tVBC +6KA== X-Gm-Message-State: AOAM531qFwebMV6ZFVTvWs+OlFYifs0v9aovu0f0CvJRRlnnryjyPk33 WWES262FzMqaX4kLeeb/WiHS3w== X-Google-Smtp-Source: ABdhPJyuWcnHt2IlLLaaW4PeU/4t+iP/z2uKL/taoQ4wCW2IlUseNhGAropDtu64zdIZwg4JVrn1HA== X-Received: by 2002:a54:4504:: with SMTP id l4mr9344859oil.152.1622950976611; Sat, 05 Jun 2021 20:42:56 -0700 (PDT) Received: from builder.lan (104-57-184-186.lightspeed.austtx.sbcglobal.net. [104.57.184.186]) by smtp.gmail.com with ESMTPSA id q1sm1432231oog.46.2021.06.05.20.42.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Jun 2021 20:42:56 -0700 (PDT) Date: Sat, 5 Jun 2021 22:42:54 -0500 From: Bjorn Andersson To: Stephen Boyd 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 Subject: Re: [PATCH v8 3/5] arm64: dts: qcom: sc7180: Enable SoC sleep stats Message-ID: References: <1621596371-26482-1-git-send-email-mkshah@codeaurora.org> <1621596371-26482-4-git-send-email-mkshah@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 04 Jun 16:53 CDT 2021, Stephen Boyd wrote: > 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. > Yes, "ram" sounds like a better node name for both the qmp and sleep-stats region - in the RPMH case. > > > > > > 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? What I was trying to say is that in the RPM (non-H) case the described memory region is not a chunk of "ram" (or "sram"), but seems to rather be the RPM region. So there it seems more reasonable to have a non-debug compatible, but I don't think we have any other use for it than the debug-stats... Regards, Bjorn