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;
From:   Rahul Tanwar <rtanwar@maxlinear.com>
To:     Stephen Boyd <sboyd@kernel.org>,
        "linux-clk@vger.kernel.org" <linux-clk@vger.kernel.org>,
        "mturquette@baylibre.com" <mturquette@baylibre.com>
CC:     linux-lgm-soc <linux-lgm-soc@maxlinear.com>,
        Yi xin Zhu <yzhu@maxlinear.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH RESEND v2 3/5] clk: mxl: Avoid disabling gate clocks from
 clk driver
Thread-Topic: [PATCH RESEND v2 3/5] clk: mxl: Avoid disabling gate clocks from
 clk driver
Thread-Index: AQHYzkwFrQSJjUImDUOzXbBrfYxegA==
Date:   Wed, 5 Oct 2022 10:52:24 +0000
Message-ID: <MN2PR19MB3693559FBE8E207A11316312B15D9@MN2PR19MB3693.namprd19.prod.outlook.com>
References: <cover.1663827071.git.rtanwar@maxlinear.com>
 <5a88bd5a9e93cc6e794080e5cac821ae0c27ec56.1663827071.git.rtanwar@maxlinear.com>
 <20220929001745.A4F9FC433B5@smtp.kernel.org>
 <MN2PR19MB3693EEC08EAC5370F1D195FBB1579@MN2PR19MB3693.namprd19.prod.outlook.com>
 <20220930010123.38984C4347C@smtp.kernel.org>
Accept-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?usPp1yH0jIIIxffqcRKcYH3AuBAp2v/S03V6eDpQKIYFlaBSWbE30F9leicE?=
 =?us-ascii?Q?S1X4Vmxnlke57/i2AJqfyJHsk0reo0QHizpgDZrdM/zLm63DqEqTZ9Lg3mvG?=
 =?us-ascii?Q?mktIHhuX290twUnT8pfpZwKXpLHDEvu6F3dHgjLMtQMjNsTKszzFyIUbf26R?=
 =?us-ascii?Q?+69f27OdvJLo+OYMs0DSzOxGgANs/R4zynqQ3TWM4WmbxWBVvbfPN2UUKTgM?=
 =?us-ascii?Q?wh6IQuSD+Viy5LqaR/h+AZgh1mv1bx6zfegU99be89m6C+6xRIWw8bfL4ccT?=
 =?us-ascii?Q?qDxxJSUxUBf4IHkHJ1vtqiloo7JKIRn/8HR1mCa0QWH0r6YTEwE/8Gk9VJLM?=
 =?us-ascii?Q?0jH+y9BRXpUgHFYbWBioHhQt80zB7zmmZjVzThOSFC+e/LK/cM3tQcnVNFW4?=
 =?us-ascii?Q?z/2QTYcAg9KbfrHV/0KnmGU6N9Qj4uIxEPd/EzfRCR7xXd/mspLpQDIHloqA?=
 =?us-ascii?Q?DUKFUtFdUqt2rFKPw6+nV4CK2km6N8yMtze3A4Pel7wx1dloz9RG9JqDyNbr?=
 =?us-ascii?Q?twFgy2qE2dwDXA3r9hT8lnAhx7N2ng5pCS0dpkS3uU1xsovTa2XcMxZhpWNx?=
 =?us-ascii?Q?sNJdGBGY5yG2LnnPYWHoFXSnO8SQiKTFxZfXVBQ/MvYpkGzO6KBch5Hwj/NZ?=
 =?us-ascii?Q?CrRpGBi/NwoVyriI5AF4sqysTpqmcfEOYaqdzb8yEMYpcxk6cFbgP9VnODwn?=
 =?us-ascii?Q?p6kfsp2G4M06FZFQckQyriNkQo+2u0CJrBSwiqSF04KCsZXFDeHXxTZ9o+BY?=
 =?us-ascii?Q?qOq+FVUAKfdKDTH1NqUovFGiitDVVZCvPjJW32hmLyH1uAGDcoGufwyQoo8Z?=
 =?us-ascii?Q?CPqBkkf9gDoypkbSKdLNVHjNwm8gg2TIVi1biKxKX2GU9nR2UnhgpR/+pTGW?=
 =?us-ascii?Q?Fcs8jHNPzrwM4WCt0dGCuN6wfewx7DYp8yVej9FvpukHjqVIXH8rYfNSxadi?=
 =?us-ascii?Q?+97BI0nZc/SJBnz3IZAEFDNa9d5QpND1EMJgb07uRydiaFgAcFsmSuiJfg8H?=
 =?us-ascii?Q?h6FAjqBldLwN9Ui7kKtjkAXiN8nZEdhyIKqqhloKaJ/OUXAf7ZRhfpwenxe1?=
 =?us-ascii?Q?mrAJ+4ineGquSVT8Pl7+IndDFxCM1kPjKTYVPGXMxqXWqn30BcRh+lcR3Svp?=
 =?us-ascii?Q?OLqO84qt1mATmtkR+uFv5z8VUFLPSqsqrKnazsdXjbnNd9BIsD7ih6QqWZFO?=
 =?us-ascii?Q?j/bm0BQBhdjoBAxr+mxiM9MfNfd1yRz18hnlnVuvD/0OIc4ljgGJzqYkD+lz?=
 =?us-ascii?Q?I/ZA+F3oEt0tbhrOcltoe4x8FqHHSsZ4uMKz/AavjMXF+MNPuD7tx4wHRLA4?=
 =?us-ascii?Q?dQyKMBCD+Yov9ZDLmo+TQDqbChIDUhZWrZ9imaqLDcD8/ODk08q6lbpjkHD4?=
 =?us-ascii?Q?c1kNH7BmXJ5ThO6UYFBvxfGbJqXHQ1doHf6mnUIQCHgK1nA1sB3u2mC9QVWO?=
 =?us-ascii?Q?sX1Z+oiWE8gat77cxtE0G70FgR+GKGPVLcIxJ5ExszlnfhtOGAjhwiCoX3MF?=
 =?us-ascii?Q?32S8YxblFUOfWFbRX6ZVHVyOdcw6yum92/bsFCOFbX2MSe77azKrz0XojdJi?=
 =?us-ascii?Q?EnEJcMNUgqgRdOj3B4P0X8b07i6cNSie2TIW0Su3EJa6QnoYz/7+qo33+1bk?=
 =?us-ascii?Q?uQ=3D=3D?=
MIME-Version: 1.0
X-OriginatorOrg: maxlinear.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR19MB3693.namprd19.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 0247c3a1-217c-4cb5-6a19-08daa6bfafbc
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2022 10:52:24.3046
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: dac28005-13e0-41b8-8280-7663835f2b1d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: LbOy63rv2H08ug7i/3jJSAJflEpaKxfoaoN9GzLFtLRXkRe4xSwt97zQcXRFRfkQOEmIFz9iP/TeILiuXmqoxw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR19MB4247
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: maxlinear.com
Content-Language: en-US
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,
        SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

[Resend due to mail delivery failure in earlier reply - one email id got=20=
=0Acorrupted somehow in earlier reply]=0A=0AHi Stephen,=0A=0A=0AOn 30/9/202=
2 9:01 am, Stephen Boyd wrote:=0A> This email was sent from outside of MaxL=
inear.=0A>=20=0A>=20=0A> Quoting Rahul Tanwar (2022-09-28 22:45:59)=0A>> On=
 29/9/2022 8:17 am, Stephen Boyd wrote:=0A>>> This email was sent from outs=
ide of MaxLinear.=0A>>>=0A>>>=0A>>> Quoting Rahul Tanwar (2022-09-21 23:24:=
26)=0A>>>> In MxL's LGM SoC, gate clocks are supposed to be enabled or disa=
bled=0A>>>> from EPU (power management IP) in certain power saving modes. I=
f gate=0A>>>> clocks are allowed to be enabled/disabled from CGU clk driver=
, then=0A>>>> there arises a conflict where in case clk driver disables a g=
ate clk,=0A>>>> and then EPU tries to disable the same gate clk, then it wi=
ll hang=0A>>>> polling for the clk gated successful status.=0A>>>=0A>>> Is =
there any point in registering these clks when they're not supposed=0A>>> t=
o be controlled from Linux?=0A>>=0A>>=0A>> As mentioned in the full commit =
log, only reason to register these clks=0A>> is to be backward compatible w=
ith older versions of similar SoC's which=0A>> reuse the same clk CGU IP bu=
t do not use same power management IP. Such=0A>> older SoCs also use the sa=
me clk driver and for them these clks are=0A>> required to be controlled by=
 clk ops from Linux.=0A>>=0A>=20=0A> Why is the clk driver probing on the n=
ew SoCs? Is it providing=0A> something? Can we detect that the power manage=
ment IP exists and not=0A> register these clks?=0A>=20=0A=0AWe discussed in=
 the team about not registering gate clks at all as you=0Amentioned. But if=
 we do that, all peripheral drivers that use these clks=0Awould need modifi=
cations so their probe does not fail due to failure=0Areturns of clk relate=
d standard calls for e.g devm_clk_get(),=0Aclk_prepare_enable(). These are =
standard calls in probe for all the=0Adrivers and a lot of them use gate cl=
ks. So this would need a lot of=0Achanges with possibility of breaking work=
ing functionalities.=0A=0AAlso, i incorrectly mentioned about the reason be=
ing backward=0Acompatibility with older SoCs. Main reason is to support dif=
ferent power=0Aprofiles use cases as per end product requirements some of w=
hich might=0Acontrol it from clk framework i.e. this driver. We keep a inte=
rnal=0Adriver flag just for this purpose to provide this flexibility depend=
ing=0Aon the use case which is what we have used here.=0A=0AI am sending v3=
 with more clear & correct description about it to=0Ajustify the need for t=
hese changes.=0A=0AThanks,=0ARahul=0A=0A=0A>=20=0A