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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 09EE6C433EF for ; Tue, 7 Dec 2021 10:16:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234949AbhLGKUI (ORCPT ); Tue, 7 Dec 2021 05:20:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41728 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229574AbhLGKUH (ORCPT ); Tue, 7 Dec 2021 05:20:07 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3A880C061574; Tue, 7 Dec 2021 02:16:37 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 06958B8173F; Tue, 7 Dec 2021 10:16:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D0798C341C3; Tue, 7 Dec 2021 10:16:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1638872194; bh=B1oT697OtNR2k4tOPVurO8VmCv1cDWiUQ3tRM2Up8BE=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=uHw0odvRGScbwMTcj00jFfv2B4lUWZk3dxGYXzPUjECUov4nAjYYUtzqF5gU0m3oP 053cCMcRZ131qBScAEtkNvE6Trql+QhmQLXO9hrACYqmK7ev4I0qthG2M9o14cT+4Q Da0lB30tTfPsiWCzSFt/8m6jbm0Z8Ra/Pdo4wgG7qwAZE0DBcKp8jI43VD5ycrSjeE XMDwc4KPdRqMsIm386qSSr2zBx3WVerU3cqj6d6CaLGUVFeNMl9fz8S5QN388q7hCH nsJqZr4769IaDvrOA3Ya/CLIqMIGyMtNsfj6Kss3bT04ca4kfzcFvpInFHg5lwD4mx XJg87abq10Y5g== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1muXWS-00ATbR-S4; Tue, 07 Dec 2021 10:16:32 +0000 Date: Tue, 07 Dec 2021 10:16:32 +0000 Message-ID: <87mtlc1zzz.wl-maz@kernel.org> From: Marc Zyngier To: Shawn Guo Cc: Thomas Gleixner , Maulik Shah , Bjorn Andersson , Loic Poulain , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 3/3] irqchip: Add Qualcomm MPM controller driver In-Reply-To: <20211207094835.GO10105@dragon> References: <20211202122122.23548-1-shawn.guo@linaro.org> <20211202122122.23548-4-shawn.guo@linaro.org> <87wnkikqve.wl-maz@kernel.org> <20211206131530.GN10105@dragon> <87wnkh26ar.wl-maz@kernel.org> <20211207094835.GO10105@dragon> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: shawn.guo@linaro.org, tglx@linutronix.de, quic_mkshah@quicinc.com, bjorn.andersson@linaro.org, loic.poulain@linaro.org, linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 07 Dec 2021 09:48:36 +0000, Shawn Guo wrote: > > On Mon, Dec 06, 2021 at 01:48:12PM +0000, Marc Zyngier wrote: > > > > > +static int qcom_mpm_enter_sleep(struct qcom_mpm_priv *priv) > > > > > +{ > > > > > + int i, ret; > > > > > + > > > > > + for (i = 0; i < priv->reg_stride; i++) > > > > > + qcom_mpm_write(priv, MPM_REG_STATUS, i, 0); > > > > > + > > > > > + /* Notify RPM to write vMPM into HW */ > > > > > > > > What do you mean by 'into HW'? We just did that, right? or are these > > > > registers just fake and most of the stuff is in the RPM? > > > > > > I have a note about this in commit log. > > > > > > - All the register settings are done by APSS on an internal memory > > > region called vMPM, and RPM will flush them into hardware after it > > > receives a mailbox/IPC notification from APSS. > > > > > > So yes, these registers are fake/virtual in memory, and RPM will > > > actually flush the values into the MPM hardware block. > > > > Then why are you using MMIO accessors all over the place if this is > > just RAM? Who *owns* this memory? Is it normal DRAM? Or some flops > > exposed by a device? Why isn't the state simply communicated over the > > mailbox instead? > > It's a piece of internal memory (SRAM) which can be access by AP and > RPM. The communication mechanism is defined by SoC/RPM design, and we > can do nothing but following the procedure. Then the procedure needs to be documented: - Who owns the memory at any given time? - What are the events that trigger a change of ownership? - What are the messages exchanged between these entities? - What is the synchronisation mechanism between the various processing entities (MPM. RPM, APSS...)? - Is the per-interrupt tracking a HW requirement or a SW implementation choice? Could this instead be a one-shot operation iterating over the whole state? All this needs to be explained so that it is maintainable, because I'm getting tired of drivers that mimic the QC downstream code without justification nor documentation to support the implementation. M. -- Without deviation from the norm, progress is not possible.