Received: by 2002:a05:6a10:5bc5:0:0:0:0 with SMTP id os5csp1198120pxb; Mon, 11 Oct 2021 00:04:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzoOSh6F7Z2WvA7sAZpw5hYNtXezaLyIow1+Y2p4LhWfFRiK+dXjtnsnaudw+d8HktY0oUb X-Received: by 2002:a05:6402:5244:: with SMTP id t4mr39564650edd.14.1633935858927; Mon, 11 Oct 2021 00:04:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633935858; cv=none; d=google.com; s=arc-20160816; b=VEq1f+XrsYLVw+xZOFpgZMbV8qIeI8of0/0jk9DLSa/J5MWN/W+gf5qYDgtROdh4bR qF061KvFpoRmT4/ML8EYTWvtMJTRb4+smPRpxTQ5rTsvTPJmwAsXQzo91EkJTQ84uDND VvuD6gDlGP9pO9DFtZvC7NKjqiA+UgGvcEBTsrYqkYTp3/ZPDeRwOijFdTRV91l++LxH dkchoPpuSgartIWsU24vbOSjFo8cFWT05KEHnCiruc7cZ3mUUhr6NmlH4OTccLM56tAm W6BiLj0FkrXC1r/AkjRzjY8ExcyJbgzbRBOcsaYIf2QgReRMJ0nZG1+EvUK7a/pyPfej TuWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=x/mmnd2xS6lnbB9QPLJMo2wlzKhjrcLhfAOfd/17VlM=; b=qNwF1tt7w6n9l6ypcNkiCRtpWOwd+nDiusx+bx4QEoQ7kJ9GyYOfyiC2SXTUY8Y00B 0Sm8dDbqq/z8uQYvvBzKLTKISjMguF/zsGsqgvAvHSoNPAgSkyC6VJjnLm7hekA2j3yj V+XA8sdEO5mHWhhGxGYsAdDAoFX79iOSbEraIDbYbqnov/VywnCcyir5609K3owPzttm ur7TCUdaugdY2B4DlX9jyFn+Z2HnvgtjE6HRo63hhNVYaU4qdsZspNA2vEL31IfXU+vM MO+Q/LJmj5WlgnPKuve/GmRWHw5teqNYwbaptUtgI7asmY5Nqmhssv1KBmaYcOkiq4QO jtOQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="ot1gEZO/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id v23si10114499ejo.762.2021.10.11.00.03.54; Mon, 11 Oct 2021 00:04:18 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="ot1gEZO/"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S234085AbhJKGTa (ORCPT + 99 others); Mon, 11 Oct 2021 02:19:30 -0400 Received: from mail.kernel.org ([198.145.29.99]:38476 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234073AbhJKGT3 (ORCPT ); Mon, 11 Oct 2021 02:19:29 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id D4FB7608FB; Mon, 11 Oct 2021 06:17:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1633933049; bh=w2CW+S/hgiQRfRSNcRoqzQvvxHGT0QjqoAYHJpU41CE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ot1gEZO/1/Ajwq8F9VaK4PqYHid8O3QbOrbYkotxX2iKWSu9du5q4JIcYrde6WBak orqsQ9L8at+8ItJzRqdQ4NF1gJSAkyPCUzWJO15dzSLK8L9LwE0vgUot/eGfww5HUr gv5nYrRI9SvzmxYgzwibwy5YObs3E1XrstmQZQ5KKVMjg2c8NVBNYRWt0hkNzX4jWD nEhYUAKJofvxbFfJwiZBDjNwR0vklBaLVy1GsrABORh525EDAkFpIPMD2UZSfJZkSh dO+SUnSQ3OhNL7q4BH5jpmpGCWRAb3hqgf/X7GpYrtlMaFoz2QABrWkprGSEm7l2kY HYv5qdwXMf0jw== Date: Mon, 11 Oct 2021 11:47:18 +0530 From: Manivannan Sadhasivam To: Mauro Carvalho Chehab Cc: Michael Turquette , Stephen Boyd , linuxarm@huawei.com, mauro.chehab@huawei.com, linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 0/2] clk: fix the need of booking clk_ignore_unused=true on embedded devs Message-ID: <20211011061718.GB1834@thinkpad> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Mauro, On Thu, Oct 07, 2021 at 02:06:53PM +0200, Mauro Carvalho Chehab wrote: > Currently, the only way to boot a Kernel with drivers built as modules on embedded > devices like HiKey 970 is to pass clk_ignore_unused=true as a modprobe parameter. > > There are two separate issues: > > 1. the clk's core calls clk_disable_unused() too early. By the time this > function is called, only the builtin drivers were already probed/initialized. > Drivers built as modules will only be probed afterwards. > > This cause a race condition and boot instability, as the clk core will try > to disable clocks while the drivers built as modules are still being > probed and initialized. So you are mentioning a "race" condition here but it is not mentioned in the actual patch. If the issue you are seeing is because the clocks used by the modules are disabled before they are probed, why can't they just enable the clocks during the probe time? Am I missing something? Thanks, Mani > > I suspect that the same problem used to happen at the regulator's core, > as there's a code that waits for 30 seconds before disabling unused > regulators; > > 2. there are some gate clocks defined at HiKey 970 that should always be on, > as otherwise the system will hang, or the filesystem I/O will stop. > > Ps.: > I submitted already 3 or 4 versions of patches for HiKey 970 clock, but > they're all unreliable, due to the race conditions at the clk core due to (1). > > Patch 1 solves the issue with the clk core. > Patch 2 solves the HiKey 970 specific issues. > > Mauro Carvalho Chehab (2): > clk: wait for extra time before disabling unused clocks > clk: clk-hi3670: mark some clocks as CLK_IS_CRITICAL > > drivers/clk/clk.c | 51 +++++++++++++++++++----------- > drivers/clk/hisilicon/clk-hi3670.c | 24 +++++++------- > 2 files changed, 44 insertions(+), 31 deletions(-) > > -- > 2.31.1 > >