From patchwork Tue Oct 27 13:52:48 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 312210 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE, SPF_PASS, URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 35998C55179 for ; Tue, 27 Oct 2020 16:52:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D4B2820723 for ; Tue, 27 Oct 2020 16:52:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603817556; bh=0eeB7qKmmbGRKV34fM5M6+cN10gAzIBlle4uu8UJFik=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=I5fTFfPBBBcQXLLlS80OfqWosIVe6SIDyw2HZT81UAriV7wGQBa0uy0kI4usQqL2p JvD+sfI+jUTmpxjAJqN61y/uSwtINr/iiBXbPIwgGfGu0U0oRkmUtyQlinmMO7gB3i mwFFiJcgVWh0tGBgjavVNoN231HUp76fQ1iKnZRQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1812909AbgJ0Qqm (ORCPT ); Tue, 27 Oct 2020 12:46:42 -0400 Received: from mail.kernel.org ([198.145.29.99]:34464 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S368876AbgJ0PmR (ORCPT ); Tue, 27 Oct 2020 11:42:17 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 24D5C22403; Tue, 27 Oct 2020 15:42:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603813336; bh=0eeB7qKmmbGRKV34fM5M6+cN10gAzIBlle4uu8UJFik=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=fPX4xRbxCc25edbojaoVGMLrWm2THuKfw+PRf7SgKroGltGEB/SPn+zgEO+Xoe64A 22IZQP5/YN9smAZMa4kJeTh4NtDPhsI8CzuDXwhH/IqSuHkfDDxJ/YQEHATSyio2eD tbUDAR6WDOXEYBgJaag8KH0V8OTjM7ybR6traNeY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Stefan Agner , Jerome Brunet , Anand Moon , Marek Szyprowski , Sasha Levin Subject: [PATCH 5.9 518/757] clk: meson: g12a: mark fclk_div2 as critical Date: Tue, 27 Oct 2020 14:52:48 +0100 Message-Id: <20201027135514.777322145@linuxfoundation.org> X-Mailer: git-send-email 2.29.1 In-Reply-To: <20201027135450.497324313@linuxfoundation.org> References: <20201027135450.497324313@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Stefan Agner [ Upstream commit 2c4e80e06790cb49ad2603855d30c5aac2209c47 ] On Amlogic Meson G12b platform, similar to fclk_div3, the fclk_div2 seems to be necessary for the system to operate correctly as well. Typically, the clock also gets chosen by the eMMC peripheral. This probably masked the problem so far. However, when booting from a SD card the clock seems to get disabled which leads to a system freeze. Let's mark this clock as critical, fixing boot from SD card on G12b platforms. Fixes: 085a4ea93d54 ("clk: meson: g12a: add peripheral clock controller") Signed-off-by: Stefan Agner Signed-off-by: Jerome Brunet Tested-by: Anand Moon Cc: Marek Szyprowski Link: https://lore.kernel.org/r/577e0129e8ee93972d92f13187ff4e4286182f67.1598629915.git.stefan@agner.ch Signed-off-by: Sasha Levin --- drivers/clk/meson/g12a.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/clk/meson/g12a.c b/drivers/clk/meson/g12a.c index 9803d44bb1578..b814d44917a5d 100644 --- a/drivers/clk/meson/g12a.c +++ b/drivers/clk/meson/g12a.c @@ -298,6 +298,17 @@ static struct clk_regmap g12a_fclk_div2 = { &g12a_fclk_div2_div.hw }, .num_parents = 1, + /* + * Similar to fclk_div3, it seems that this clock is used by + * the resident firmware and is required by the platform to + * operate correctly. + * Until the following condition are met, we need this clock to + * be marked as critical: + * a) Mark the clock used by a firmware resource, if possible + * b) CCF has a clock hand-off mechanism to make the sure the + * clock stays on until the proper driver comes along + */ + .flags = CLK_IS_CRITICAL, }, };