Received: by 10.192.165.156 with SMTP id m28csp187189imm; Tue, 10 Apr 2018 19:27:40 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/OrOItzbomreH1WfnAlfuNo3ED+7R7lEpWIhDtjIC0aRU1+XTDEAl5Uae/pi0NuzUqn90H X-Received: by 2002:a17:902:a50d:: with SMTP id s13-v6mr2980235plq.228.1523413660919; Tue, 10 Apr 2018 19:27:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523413660; cv=none; d=google.com; s=arc-20160816; b=njMCmFnT8z00NR6e/OizxPif22moJ+tB3WqW06Vectt1uukq9Syy4i8KSlnZo1vIGC YEWij+Vym3OX8xmfZz3FLEv33b0iYOeFtEFk//Ema3EpfBB1JBvUSiGw+ilVQLw+Lqyl iYYD5d39QQl7xe0cr3Tbq6hCa1GdrZc+IXenh2v62KwIey2ZjzIerw3U/FTN5rshlyHE YrPcMzWCBNBQQT8sKACH2VRFuO8sUj5Y2iSzcz1igwGu504+jo1Afq/wPOMv+LR1Kwq1 qP3FgYnWp4sZcHJ0p4wBwAWe+Mh/pJo9no30WaJTSZx499idX/hho4dUoBpPycq0WZA3 dgGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:date:subject:user-agent:message-id :references:cc:in-reply-to:from:to:content-transfer-encoding :mime-version:dkim-signature:arc-authentication-results; bh=RCt/VGrbINvAh24EyCZiAZBIT8QjlzCQjouPzmfU5/U=; b=jKaLRRvDts1klp2ViP8XytB7y7cBbqDQEaEE9THNi8Q+a3qlDSvi7kq/HO857bGKHE SqCsN763VoVeI5NlmTMcrAGZzcIelwwRTgaKi98qoihGnhaKWfD2b9aazwGnIDdp8OMK nTqdM2DpUYHa4sGkjbgwO3MKMj7PmeLs7+lfbjSxpqBNivAAoAZGkDxn9iwjXLcW8adx 4GWq3ydD/DS2id+ktC5iYHgP9IPZOYXnc2vOsfw7+Yl7/bo4PGmEA94vGENoH4VKhN7a LU91hmzN+8p0zCe/SOg0Nqr/w438ypvuEgRV0LwdmSt1+BGYO/wpZCtfWlbkFBMUm77k C3FQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@chromium.org header.s=google header.b=AfGZwnfl; 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=chromium.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a3si91670pfe.19.2018.04.10.19.27.03; Tue, 10 Apr 2018 19:27:40 -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=@chromium.org header.s=google header.b=AfGZwnfl; 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=chromium.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752850AbeDKCXM (ORCPT + 99 others); Tue, 10 Apr 2018 22:23:12 -0400 Received: from mail-pg0-f65.google.com ([74.125.83.65]:34520 "EHLO mail-pg0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752172AbeDKCXK (ORCPT ); Tue, 10 Apr 2018 22:23:10 -0400 Received: by mail-pg0-f65.google.com with SMTP id p10so86281pgn.1 for ; Tue, 10 Apr 2018 19:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:content-transfer-encoding:to:from:in-reply-to:cc :references:message-id:user-agent:subject:date; bh=RCt/VGrbINvAh24EyCZiAZBIT8QjlzCQjouPzmfU5/U=; b=AfGZwnflmjZdGWFueJVjVZhQ0bt6XjZz7agpKzlcfEI5hzOT/R1GdVUuHcz7pF5SfZ k1ilZvD1G9D3IbegIx7IwfpmyunFB1rbkzepedYdpe6IP4KCys3O3c/aliOKpy0WbsTM +Ysa6NJEoGUvHfL/CcPESGp24f0rwqsJw3gTM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding:to:from :in-reply-to:cc:references:message-id:user-agent:subject:date; bh=RCt/VGrbINvAh24EyCZiAZBIT8QjlzCQjouPzmfU5/U=; b=ukVnN1zW4krK4r0ggOqpExH3zOzbYQiXgOiBL7Jl3I8J/ngs3tScpVHcDZPkU3i/R+ axdkKeap9nItl6YY+K0Cp6uon8+KM1iTJJTk4xB7u5xqO541F1TJ/z2fSFGP7s6IVGKW 3JjJZL4ifHibibLGw4fckWCONdE0ipVfVGBdiw6XkV9pkiWE28qaSjk4hnRiy5WcimPY HHyagejNvbBQe77WBhk6COFqx2DsNNAucwNjYkITt8zucDI+oMk5TsBncpku/lReJP0u 24hiVdn1LDsWwfRORGNM4oL55XvRUndPQDNYSgUTiNk2rIuwcbkl5yl9IkNd6PMgfceb YZzg== X-Gm-Message-State: ALQs6tCypn5/RikVWusIEgle3QoBDMuWSfmIi0BOffr8wYIbBFbHPgLH ieN8ma6f2E0sNjuuv9uB499PtA== X-Received: by 10.98.7.83 with SMTP id b80mr2350368pfd.133.1523413389855; Tue, 10 Apr 2018 19:23:09 -0700 (PDT) Received: from localhost ([2620:0:1000:1511:d30e:62c6:f82c:ff40]) by smtp.gmail.com with ESMTPSA id 27sm121310pfo.137.2018.04.10.19.23.09 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 10 Apr 2018 19:23:09 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable To: Lina Iyer From: Stephen Boyd In-Reply-To: <20180409153631.GB19682@codeaurora.org> Cc: andy.gross@linaro.org, david.brown@linaro.org, linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org, rnayak@codeaurora.org, bjorn.andersson@linaro.org, linux-kernel@vger.kernel.org, evgreen@chromium.org, dianders@chromium.org References: <20180405161834.3850-1-ilina@codeaurora.org> <20180405161834.3850-5-ilina@codeaurora.org> <152306410070.94378.2738189478665128271@swboyd.mtv.corp.google.com> <20180409153631.GB19682@codeaurora.org> Message-ID: <152341338838.180276.13886596646409290675@swboyd.mtv.corp.google.com> User-Agent: alot/0.7 Subject: Re: [PATCH v5 04/10] drivers: qcom: rpmh: add RPMH helper functions Date: Tue, 10 Apr 2018 19:23:08 -0700 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Lina Iyer (2018-04-09 08:36:31) > On Fri, Apr 06 2018 at 19:21 -0600, Stephen Boyd wrote: > >Quoting Lina Iyer (2018-04-05 09:18:28) > >> diff --git a/include/soc/qcom/rpmh.h b/include/soc/qcom/rpmh.h > >> new file mode 100644 > >> index 000000000000..95334d4c1ede > >> --- /dev/null > >> +++ b/include/soc/qcom/rpmh.h > >> @@ -0,0 +1,34 @@ > >> +/* SPDX-License-Identifier: GPL-2.0 */ > >> +/* > >> + * Copyright (c) 2016-2018, The Linux Foundation. All rights reserved. > >> + */ > >> + > >> +#ifndef __SOC_QCOM_RPMH_H__ > >> +#define __SOC_QCOM_RPMH_H__ > >> + > >> +#include > >> +#include > >> + > >> +struct rpmh_client; > >> + > >> +#if IS_ENABLED(CONFIG_QCOM_RPMH) > >> +int rpmh_write(struct rpmh_client *rc, enum rpmh_state state, > >> + const struct tcs_cmd *cmd, u32 n); > >> + > >> +struct rpmh_client *rpmh_get_client(struct platform_device *pdev); > >> + > >> +void rpmh_release(struct rpmh_client *rc); > > > >Please get rid of this 'client' layer and fold it into the rpmh driver. > >Everything that uses the rpmh_client is a child device of the rpmh > >device so they should be able to just pass in their device pointer as > >their 'handle' and have the rpmh driver take that, get the parent device > >pointer, and pull an rpmh_drv structure out of there. The 'common' code > >can go into the base rpmh driver and get used from there and then we > >don't have to hop between two files to see how rpmh is used by the > >consumers. Code complexity goes down this way. > = > That would be not be a good idea. This layer is not just providing an > API interface. There is resource buffering, handling of memory for > requests and downstream quirks and debug going on in this layer. It > would be unwise to clobber the hardware centric rpmh-rsc layer. If you > look at the series as a whole, you would understand why this is > necessary. I plan to build more on top of these patches in the future as > we add support for system low power modes. The complexity doesn't go > away, it just thrown in to another file, which is already decently > sized. > = > I could try to use the device as a handle, and internally work on > getting the drv and other information from it, if that helps. But I do > not want to clobber these two files together. It doesn't help > maintainability. Using the device as a handle is a good start. Let's see how it looks once that part of the code gets replaced. I still fail to see how buffer management and requests are any different from poking the hardware, but OK. Maybe if this was a TCS "library" on top of the rpmh hardware interface?