From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net [23.128.96.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5E46D18C08 for ; Thu, 21 Sep 2023 17:49:20 +0000 (UTC) Received: from muru.com (muru.com [72.249.23.125]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 9EB268B4E4; Thu, 21 Sep 2023 10:41:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id BA1328109; Thu, 21 Sep 2023 12:16:27 +0000 (UTC) Date: Thu, 21 Sep 2023 15:16:26 +0300 From: Tony Lindgren To: =?utf-8?B?UMOpdGVy?= Ujfalusi Cc: Andreas Kemnade , bcousson@baylibre.com, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, conor+dt@kernel.org, lgirdwood@gmail.com, broonie@kernel.org, perex@perex.cz, tiwai@suse.com, jarkko.nikula@bitmer.com, dmitry.torokhov@gmail.com, linux-omap@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org Subject: Re: [PATCH 1/3] ASoC: ti: omap-mcbsp: Ignore errors for getting fck_src Message-ID: <20230921121626.GT5285@atomide.com> References: <20230705190324.355282-1-andreas@kemnade.info> <20230705190324.355282-2-andreas@kemnade.info> <7d58d52d-2087-45af-b29e-2515b63ead13@gmail.com> <20230920063353.GQ5285@atomide.com> Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net * Péter Ujfalusi [230920 17:40]: > It is not the parent's fck, it is the PRCM clock which is selected as > the sourcee of the clock generator (CLKS) for BCLK/FSYNC. That is the > functional clock as well for the McBSP instance. Oh OK > Out of reset it is using the PRCM source which is fine in all current users. > I would do this fix or workaround in a different way: instead of > ignoring the error, avoid it in the first place. Do nothing if the > already selected clock is requested. > That would remove the error and will fail in case the reparenting is not > working -> boards will know this and might be able to do something about > it in a reasonable way. > > How that sounds? Sounds good to me :) Tony