Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp377710rwd; Wed, 14 Jun 2023 17:52:16 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4m7fejB4YLuPSFm4P9tTqUHnRS4U4mDG44Bg+1HonyqPPGXaplyC4WwylRVqlK2rM4llN/ X-Received: by 2002:a05:6808:1a8a:b0:39a:bef9:72cd with SMTP id bm10-20020a0568081a8a00b0039abef972cdmr10891180oib.47.1686790335811; Wed, 14 Jun 2023 17:52:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1686790335; cv=none; d=google.com; s=arc-20160816; b=lJ9U2V0US6bByZvfkcdq5GRzw36IFhQQlIESdYBenh3tUh/NS/U6y0qFkwJGcOdxL4 zzpUKb9+ic5TaBbvs18LB4OIWU69tZnhTD/ErdSW6Tutaz5j+MW/tgMCanuN6AM6dBV6 OGIIj7glDl9UJpe2o5iAoQ2DG9/a8y7uefgKR26/j0DSNM3nQJHu/koRjaiWynv+LZ7o Xy4LIV7sVv2tzenNNRBEFjwA7MJB9jg7/aaglvaP9LjPDD6IOObaPtPKrctOFSnTvZku mWynsKBLma8pubIOgKinn4wm6L1N1CShdVWUh1O8RrmCsZRh6U6GyPRMY4yTLnhLwmmb fJAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:date:to:cc:from:subject:references :in-reply-to:content-transfer-encoding:mime-version:message-id :dkim-signature; bh=zFWS/qLxpHcmQXXHA/0QfWakB1ea9egqgPNlvPD7j2I=; b=qwXcLq6l56lK6JXs+13UlGgmu4X0PPFDP9DVDTRZidb41M8qmTHLbfRcps9Kkp9Vwg QtYfGJUQVGxJsHY1E2rMk04ndD8+XLYeUcEzLqwmbtxT8/9P6f3R4uMybCeLq86mNKyE r/0RJ8beO4qO9B1sJZUkvpU8au2+pGiWLUEsb+YJ1S3yN+LX3vtzGKSngQ9gGt42zhr2 Gx59LC13aIBYssPki4I1Gd5tYwOF6QFToa5IVr6GwmYWJFJv28M4iCRbKbFLoNV6WZt8 qG4gtsXN6tB1fdAvkdEvtd1x3XwTLLpXh0q/AfFZWOWUyIz67/18df2hCEAU/QJUKXct oVAw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=UDrmucUc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id z7-20020a637e07000000b005309f24f940si2691352pgc.586.2023.06.14.17.52.03; Wed, 14 Jun 2023 17:52:15 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=UDrmucUc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237103AbjFOAuE (ORCPT + 99 others); Wed, 14 Jun 2023 20:50:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59912 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236439AbjFOAuD (ORCPT ); Wed, 14 Jun 2023 20:50:03 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 75F111BE3; Wed, 14 Jun 2023 17:50:02 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 123DB63516; Thu, 15 Jun 2023 00:50:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5FC5FC433C0; Thu, 15 Jun 2023 00:50:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1686790201; bh=OnZsw9VGDNW6KuY0k3YjEaktjmpS1FKjNJp4If98TW8=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=UDrmucUciHwXzwjWwArsQuCkffUdTOgVRhSqtnrPIRZvOFFsVLsPsD9QkFw7DKtMJ SH3uIpaDkQpyhWlLAK2RaB675mcPTmkn7dP7O5yn4CTL2J1jhCEyCIu22+AsHw7zio ZrHMm6dAK2VZpbPBgOicl3oWAm0CPkvF/XzCLnLxzdHgJvghqgadwheEgECf5bsasn GgjLXruMqUQ0A19R6kk9ENHc25Ev8pI1dutg4emORyHtAmlOlMRnOkdqKJ2cMVbuoE iCmeE+jJpz2AxkX/1W5EYBZ5y6mVSzLHMCARPpCk4vOE6Etm4+eav2huj9QtbnnmJN RkgFI22hVSnCQ== Message-ID: <0764b5fda92acb995ffbd05c4b3d2b2f.sboyd@kernel.org> Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20230526-topic-smd_icc-v6-0-263283111e66@linaro.org> References: <20230526-topic-smd_icc-v6-0-263283111e66@linaro.org> Subject: Re: [PATCH v6 00/22] Restructure RPM SMD ICC From: Stephen Boyd Cc: Marijn Suijten , linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-clk@vger.kernel.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, Konrad Dybcio , Krzysztof Kozlowski , Dmitry Baryshkov , Stephan Gerhold To: Andy Gross , Bjorn Andersson , Conor Dooley , Evan Green , Georgi Djakov , Konrad Dybcio , Krzysztof Kozlowski , Leo Yan , Michael Turquette , Rob Herring Date: Wed, 14 Jun 2023 17:49:59 -0700 User-Agent: alot/0.10 X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Quoting Konrad Dybcio (2023-06-14 11:04:19) > This series reshuffles things around, moving the management of SMD RPM > bus clocks to the interconnect framework where they belong. This helps > us solve a couple of issues: >=20 > 1. We can work towards unused clk cleanup of RPMCC without worrying > about it killing some NoC bus, resulting in the SoC dying. > Deasserting actually unused RPM clocks (among other things) will > let us achieve "true SoC-wide power collapse states", also known as > VDD_LOW and VDD_MIN. >=20 > 2. We no longer have to keep tons of quirky bus clock ifs in the icc > driver. You either have a RPM clock and call "rpm set rate" or you > have a single non-RPM clock (like AHB_CLK_SRC) or you don't have any. >=20 > 3. There's less overhead - instead of going through layers and layers of > the CCF, ratesetting comes down to calling max() and sending a single > RPM message. ICC is very very dynamic so that's a big plus. >=20 > The clocks still need to be vaguely described in the clk-smd-rpm driver, > as it gives them an initial kickoff, before actually telling RPM to > enable DVFS scaling. After RPM receives that command, all clocks that > have not been assigned a rate are considered unused and are shut down > in hardware, leading to the same issue as described in point 1. Why can't we move the enable of DVFS scaling call to the interconnect driver as well? We want the clk driver to not reference the interconnect resources at all.