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=-4.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE, SPF_PASS autolearn=no 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 9791AC3A5A2 for ; Mon, 19 Aug 2019 18:26:56 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 7368822D6D for ; Mon, 19 Aug 2019 18:26:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1566239216; bh=Ivyitg0Ej4OT9+wlNtHSfddysy0Yzo6f+ai2y1gszXo=; h=In-Reply-To:References:Subject:From:Cc:To:Date:List-ID:From; b=UUr7UzhMMnYJlim0NI4V/dLGj5y9ezHvgOQk6Mwoi/5B4yLdOX4/lPCrbt7vNTGhw 0GAEPOLTpe2JAYgYuaKKmJ1aClhocE8r2zC3sq0UAHh70YgMPDZvjDpB/V9jLblHKp XUjmyPJF1Bu2WpNXPJ1DpM4zWwjKPR/UVCrvdF5c= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728290AbfHSS04 (ORCPT ); Mon, 19 Aug 2019 14:26:56 -0400 Received: from mail.kernel.org ([198.145.29.99]:52100 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727970AbfHSS0z (ORCPT ); Mon, 19 Aug 2019 14:26:55 -0400 Received: from kernel.org (unknown [104.132.0.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A950222CF6; Mon, 19 Aug 2019 18:26:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1566239214; bh=Ivyitg0Ej4OT9+wlNtHSfddysy0Yzo6f+ai2y1gszXo=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=yKwuiNEaKXSYTOZwJLHBcizgkZa/S9//ofj0LoEwmolfjTUp76LpNj7X/Gw2u9OVT lA2rQ2cnpzqET0Sj2IWzg0jTiYtu6cz3rBpDG/h5df4HVfJVWcUGMAydFgak4HldCg yjvbx6h0fC4neMZWruWmN2spKfWn+0bAiGb0txB4= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20190819165255.GA26807@tuxbook-pro> References: <1565037226-1684-1-git-send-email-jcrouse@codeaurora.org> <20190807234232.27AA720880@mail.kernel.org> <20190819165255.GA26807@tuxbook-pro> Subject: Re: [PATCH v2] drivers: qcom: Add BCM vote macro to header From: Stephen Boyd Cc: Jordan Crouse , freedreno@lists.freedesktop.org, linux-arm-msm@vger.kernel.org, Michael Turquette , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Andy Gross , Georgi Djakov , linux-clk@vger.kernel.org, Taniya Das To: Bjorn Andersson User-Agent: alot/0.8.1 Date: Mon, 19 Aug 2019 11:26:53 -0700 Message-Id: <20190819182654.A950222CF6@mail.kernel.org> Sender: linux-arm-msm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Quoting Bjorn Andersson (2019-08-19 09:52:55) > On Wed 07 Aug 16:42 PDT 2019, Stephen Boyd wrote: >=20 > > Quoting Jordan Crouse (2019-08-05 13:33:46) > > > The macro to generate a Bus Controller Manager (BCM) TCS command is u= sed > > > by the interconnect driver but might also be interesting to other > > > drivers that need to construct TCS commands for sub processors so move > > > it out of the sdm845 specific file and into the header. > > >=20 > > > Signed-off-by: Jordan Crouse > > > --- > >=20 > > Acked-by: Stephen Boyd > >=20 > > Unless this is supposed to be applied by me? > >=20 > > BTW, I wonder why we need an rpm clk driver much at all nowadays, except > > maybe for the XO clk state. The big user, from what I can tell, is the > > interconnect driver and we don't use any of the features of the clk > > framework besides the API to set a frequency. Maybe it would be better > > to just push push the bus frequency logic into interconnect code, then > > XO clk is the only thing we need to keep, and it can be a simple on/off > > thing. > >=20 >=20 > There's been a number of cases where we'll need to enable the buffered > XOs, but perhaps these are handled by other subsystems these days(?) >=20 > If so the one case that remains would be the operation of explicitly > holding CXO enabled during operations such as booting the remoteprocs. >=20 Yes I think the XO (and the buffers) is the only thing that we really seem to care about for the clk tree. Otherwise, the sole user is interconnect code and thus handling it in the rpmh clk driver doesn't really gain us anything. In fact, it just makes it worse because it ties the clk tree up with things that could take a while to process on the RPM side.