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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9A50CC4332F for ; Thu, 31 Mar 2022 15:00:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237915AbiCaPCc (ORCPT ); Thu, 31 Mar 2022 11:02:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35300 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233421AbiCaPCb (ORCPT ); Thu, 31 Mar 2022 11:02:31 -0400 Received: from muru.com (muru.com [72.249.23.125]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8321B1480D4; Thu, 31 Mar 2022 08:00:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id AA72380DB; Thu, 31 Mar 2022 14:58:34 +0000 (UTC) Date: Thu, 31 Mar 2022 18:00:42 +0300 From: Tony Lindgren To: Maxime Ripard Cc: Marek Szyprowski , Mike Turquette , Stephen Boyd , linux-clk@vger.kernel.org, Dmitry Osipenko , 'Linux Samsung SOC' , linux-amlogic@lists.infradead.org, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH v2 3/3] clk: Drop the rate range on clk_put Message-ID: References: <20220325161144.1901695-1-maxime@cerno.tech> <20220325161144.1901695-4-maxime@cerno.tech> <366a0232-bb4a-c357-6aa8-636e398e05eb@samsung.com> <20220330084710.3r6b5pjspz5hdmy6@houat> <20220331095456.dyyxsiu2b3yw2vvs@houat> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220331095456.dyyxsiu2b3yw2vvs@houat> Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org * Maxime Ripard [220331 09:52]: > On Thu, Mar 31, 2022 at 12:42:10PM +0300, Tony Lindgren wrote: > > It seems the dts assigned-clock-parents no longer works now? > > That would make some kind of sense, __set_clk_parents calls clk_put on > both the assigned clock and its parent. > > Could you see what parent (and why?) it tries to enforce then? It picks the other option available for the mux clock that only has two options. No idea why, but if you have some debug patch in mind I can give it a try. > It looks like the gpt1_fck driver might favor another parent for that > rate, which, if it's an invalid configuration, shouldn't really happen? Hmm there's a gate clock and a mux clock, there's not really a rate selection available here for the sources. Regards, Tony