Received: by 2002:a05:7412:1492:b0:e2:908c:2ebd with SMTP id s18csp56070rdh; Tue, 22 Aug 2023 12:26:17 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFY7QPFJdd1pok80QigAp45Xxcwvb5Dth2QAGPw6k082CGmQW9/OCY7BvnOc/gmxrLaZpmk X-Received: by 2002:a05:6402:1610:b0:525:469a:fc38 with SMTP id f16-20020a056402161000b00525469afc38mr7729829edv.31.1692732376814; Tue, 22 Aug 2023 12:26:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1692732376; cv=none; d=google.com; s=arc-20160816; b=uob5CgiNoAwNUEAErENt6LrTLyRwPStPGplDWh9y/8g2YQb7InnXHUyjAKmxpIc8Jd 6hlIJ0S3axOBBcSPNc1xAUKU2iT0eydWeSCNy7ulS7StI7xj1ddo6uRvKVZLltTrZUu1 EkdeZrWjPLX4P+Rk/j2LDUeix7et6T+cGALsRsQSyHigV0YtPIVX7SYTmZIwjQpjqrA3 htPCpLmjIKMK4wz4ByrUaXOwJOZvoyEA3Adq+dn2jNsdW/MYSNEcpvzzj8sEj7nG7fTV mPxpbzZex25qskNerm2Bfhs+3f4BISAYrrHias7Hftl/FmIs+sAPwxwib+cOqE8zwb6v dl/A== 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=dRU+xV4/+aujH3uPN8+LBCO8lYyHG0dBze3M1hel9fc=; fh=zdMWlvBANeBoEmYjWoKG7JHuQSR96pL4ZO820eHluSA=; b=rXGdFb0Z6dWHhj02+IuwU3JCXc+PJLl5pDdFf6di9N4NZ9iE/ge21UQdIl9wip9+4P rzT5etW1rIQyu+wl1TQ+mlrO38NpPi9iAfBksuTjltaK2Xk79qiNUP0bd/bduYkrVTOj If51axoa0dFjYm/UY77rUUcXr81VEN++bRW5N8DQ+R44g637V0Y3ZVmEi1m4nSKfRugR UmrGXqopuOPeNGr1Md3Sb8FPQzITybhEa8wRLnMTIxvgvtSRH4g5d7yZkIjErhH8Rz8p jGo+R2wmc1muOoozZ5s6oAQdWlgF8EXalZZKweF3LIRWE+KykdzfXRw/WPKFcYf8iEfH KGsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=OITsBL8G; 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 f12-20020a50ee8c000000b005234b452a4fsi7564295edr.68.2023.08.22.12.25.52; Tue, 22 Aug 2023 12:26:16 -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=OITsBL8G; 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 S229955AbjHVSxS (ORCPT + 99 others); Tue, 22 Aug 2023 14:53:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49896 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229941AbjHVSxO (ORCPT ); Tue, 22 Aug 2023 14:53:14 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 55CD5E61; Tue, 22 Aug 2023 11:53:04 -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 D9B0C65D7B; Tue, 22 Aug 2023 18:53:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3B0D6C433C7; Tue, 22 Aug 2023 18:53:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1692730383; bh=bKiDZmN49huWf7NWKy0Ori9rr/bVNoT6UpjkQ5TVMmo=; h=In-Reply-To:References:Subject:From:Cc:To:Date:From; b=OITsBL8GveepBAjZCgo5KbglXtc1/m82nLHDkWsfB54qKA6hFX1PynX1TEVeb5msA 2aG4TIbKW0mg9cZBRYmcO5eturhlFyCpCCsm6LqmpKu9Aunm2hyaMZHPPXXRk5jboE SmW3lXJcAjuLUOIwm/ur+B22J5i9nyRHRJTmuRZ2Xl7KxrbQDBMpI4EGOotoGYmC7i +T6u9I+V4ShC1r4JiBIXzcZskcD5Z1W2DnPNRUTQk5q8MRhsXryEQ+lPqoJseYaPZx dRC8c0YWeD60ilE64eQHnK7NmoSKVJ2WLS0VWmVbPYFl//j+J5CT7k0WdVffiT6OGx x0JR87wuG7Miw== Message-ID: Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable In-Reply-To: <20230808051407.647395-3-quic_imrashai@quicinc.com> References: <20230808051407.647395-1-quic_imrashai@quicinc.com> <20230808051407.647395-3-quic_imrashai@quicinc.com> Subject: Re: [PATCH 2/4] clk: qcom: branch: Add mem ops support for branch2 clocks From: Stephen Boyd Cc: Taniya Das , Imran Shaik , linux-arm-msm@vger.kernel.org, linux-clk@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Ajit Pandey , Jagadeesh Kona To: Andy Gross , Bjorn Andersson , Conor Dooley , Imran Shaik , Konrad Dybcio , Krzysztof Kozlowski , Michael Turquette , Rob Herring Date: Tue, 22 Aug 2023 11:52:59 -0700 User-Agent: alot/0.10 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS 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 Imran Shaik (2023-08-07 22:14:05) > diff --git a/drivers/clk/qcom/clk-branch.h b/drivers/clk/qcom/clk-branch.h > index 0cf800b9d08d..0ffda6bef00e 100644 > --- a/drivers/clk/qcom/clk-branch.h > +++ b/drivers/clk/qcom/clk-branch.h > @@ -24,8 +24,11 @@ > struct clk_branch { > u32 hwcg_reg; > u32 halt_reg; > + u32 mem_enable_reg; > + u32 mem_ack_reg; > u8 hwcg_bit; > u8 halt_bit; > + u8 mem_enable_ack_bit; > u8 halt_check; > #define BRANCH_VOTED BIT(7) /* Delay on disable */ > #define BRANCH_HALT 0 /* pol: 1 =3D halt */ I suspect making a wrapper around struct clk_branch would be a better approach so that we don't bloat all the other clk_branch structures that exist in the qcom clk drivers. $ git grep 'struct clk_branch' -- drivers/clk/qcom | wc -l 6357 How many of these are going to be using these new registers? It may also make sense to do that for hardware clock gating as well, but I'm not really sure. Anyway, the idea is struct clk_mem_branch { u32 enable_reg; u32 ack_reg; u8 ack_bit; struct clk_branch branch; }; and then a container_of define. Plus, you can put some comment above the structure to describe when these clks are used.