Received: by 10.223.185.116 with SMTP id b49csp937086wrg; Fri, 16 Feb 2018 09:33:03 -0800 (PST) X-Google-Smtp-Source: AH8x225r7ZQaH8XW+shgFzcQMplQpJ7blfazEsGEYewhiJFAvoh4KPdogzqhM8JwL8zJJD0RXvnx X-Received: by 10.101.98.133 with SMTP id f5mr5688570pgv.357.1518802383861; Fri, 16 Feb 2018 09:33:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518802383; cv=none; d=google.com; s=arc-20160816; b=UH58+44HnThzXCwopXbx/Ub033cPiRnLokaxzaPCkRa9dRgbaDacrL6XsYoQnlSIju G3S6Y7FxEbJCZLMHdgYaH+QI1L1faGla18SMaKiDQGka7OyIPEDiedLMLKIfnoKwfvMc V2K43KDdznmlrR6S62/W7YM+PBL6jJ8ql6z3DBglFXOjH6RLLVcdYKvqgp7dGJPRv4Nv uPNnNfh15w9g4LOiRXUDLUz5APuaLKZUTChK42YiEXC3liFOO99z3Mx5cthiTeXmaqhz o1xqgsoPyncqjLzZAQubbSD3pclFLDW/q+pKgj8EAIJyyZgpIaM1iVuXvKXj3R+3B0s9 Tezg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=NdixzQIE9YR8L7KAEtUF0AMHiRdfHVngOqvhptlAYkM=; b=l3bCF/XiEGW47tWKsGDT5tqA6BBjck5/ChHct9x0vM35MAWJQSbeyrqYXeSeNEpplD ML2RSXMVD4wiBAHjkyYUyYdn27eX+KV4g31KlGI0IgyC8tkkV3x+IFli18D83ZgBqpzW tdOgmP/P8Cf239lVUHv0PBQx47tO9fNz1of3qNbPl6+5HUcwuvcLFKov6YbiwquH19XQ WR50SizTICEIlI0iuNTPEhs2GZEomTPzwN2vyWwB/2/xZV4u6gPDvJ/iVOZGxfpbzxp0 Q+ZbZ+bmoSUXP+j3EIA7VjclEXJh1CFZ26Gdd+3uA7FE5DuRxr1h/uCYzlaMoY3WWHOM BuBA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o128si3083580pfo.68.2018.02.16.09.32.05; Fri, 16 Feb 2018 09:33:03 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1167255AbeBOVB4 (ORCPT + 99 others); Thu, 15 Feb 2018 16:01:56 -0500 Received: from gloria.sntech.de ([95.129.55.99]:37532 "EHLO gloria.sntech.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1162995AbeBOVBz (ORCPT ); Thu, 15 Feb 2018 16:01:55 -0500 Received: from ip9234b6d7.dynamic.kabel-deutschland.de ([146.52.182.215] helo=diego.localnet) by gloria.sntech.de with esmtpsa (TLS1.1:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1emQfB-0000LA-4q; Thu, 15 Feb 2018 22:01:53 +0100 From: Heiko =?ISO-8859-1?Q?St=FCbner?= To: Jerome Brunet Cc: Michael Turquette , Stephen Boyd , linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, Stephen Boyd , Shawn Guo , Dong Aisheng Subject: Re: [PATCH v2 4/8] clk: migrate the count of orphaned clocks at init Date: Thu, 15 Feb 2018 22:01:52 +0100 Message-ID: <1970074.VYjjbDuVRv@diego> In-Reply-To: <20180214134340.17242-5-jbrunet@baylibre.com> References: <20180214134340.17242-1-jbrunet@baylibre.com> <20180214134340.17242-5-jbrunet@baylibre.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am Mittwoch, 14. Februar 2018, 14:43:36 CET schrieb Jerome Brunet: > The orphan clocks reparents should migrate any existing count from the > orphan clock to its new acestor clocks, otherwise we may have > inconsistent counts in the tree and end-up with gated critical clocks > > Assuming we have two clocks, A and B. > * Clock A has CLK_IS_CRITICAL flag set. > * Clock B is an ancestor of A which can gate. Clock B gate is left > enabled by the bootloader. > > Step 1: Clock A is registered. Since it is a critical clock, it is > enabled. The clock being still an orphan, no parent are enabled. > > Step 2: Clock B is registered and reparented to clock A (potentially > through several other clocks). We are now in situation where the enable > count of clock A is 1 while the enable count of its ancestors is 0, which > is not good. > > Step 3: in lateinit, clk_disable_unused() is called, the enable_count of > clock B being 0, clock B is gated and and critical clock A actually gets > disabled. > > This situation was found while adding fdiv_clk gates to the meson8b > platform. These clocks parent clk81 critical clock, which is the mother > of all peripheral clocks in this system. Because of the issue described > here, the system is crashing when clk_disable_unused() is called. > > The situation is solved by reverting > commit f8f8f1d04494 ("clk: Don't touch hardware when reparenting during > registration"). To avoid breaking again the situation described in this > commit > description, enabling critical clock should be done before walking the > orphan list. This way, a parent critical clock may not be accidentally > disabled due to the CLK_OPS_PARENT_ENABLE mechanism. > > Fixes: f8f8f1d04494 ("clk: Don't touch hardware when reparenting during > registration") Cc: Stephen Boyd > Cc: Shawn Guo > Cc: Dong Aisheng > Signed-off-by: Jerome Brunet On a rk3288-veyron Chromebook Tested-by: Heiko Stuebner This made the hdmi on the machine work again with 4.16-rc1 . (hdmi-cec clock is sourced from the i2c connected pmic which provides the 32kHz clock needed) So it would be really cool if this could make it into 4.16-rc :-) Heiko