From patchwork Thu Dec 26 19:12:23 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Blumenstingl X-Patchwork-Id: 11310681 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 0124414B7 for ; Thu, 26 Dec 2019 19:12:51 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D2C2920838 for ; Thu, 26 Dec 2019 19:12:50 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=googlemail.com header.i=@googlemail.com header.b="nN/5xERv" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726925AbfLZTMr (ORCPT ); Thu, 26 Dec 2019 14:12:47 -0500 Received: from mail-wm1-f66.google.com ([209.85.128.66]:39271 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726809AbfLZTMq (ORCPT ); Thu, 26 Dec 2019 14:12:46 -0500 Received: by mail-wm1-f66.google.com with SMTP id 20so6672126wmj.4; Thu, 26 Dec 2019 11:12:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=tt36REs6xTGhoAu/DRKUVnoYElZnOVVi2F4lvnCzwxk=; b=nN/5xERvRFlldF3gW7sAZTJtfO1cS4PM2gDnf67/zENyO5n4o77HOWTbJd+ZG9QQEk rRmgS1gcOjN3hRQiIL+owsaJVLwFqTfL1/vG+uggrbXC0yBGM+RxK1zFTo6OGeRaCvvr 2bIXCEAwf2NTdJkSs9YLL71Y1MeiMYh+cgkFAqIiuMUmEUldmHj5l+11ytV6bc1yFMBx KSK2b/dgA5OZI681Yv5LvSHPpYjq5STPnwC0M/RjXSjn/F7jJrOyJThiJKZl71YehIwR pNI8Gvuz2bqniQpEFgzsYaEu9XkhkxVZNHC6U7sQeTE0867hzRQ7yq0Gjwpl4SU2o4WP c7yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=tt36REs6xTGhoAu/DRKUVnoYElZnOVVi2F4lvnCzwxk=; b=do5BZXSygILym60TcUevkjx44J+wPa9w6u0vlxoMR6yeVOX9oMds4nGeqfRVOYyL/3 M4UQwYTRxd7Lv2+tBxeOfvXyDVi7cEKvqxotARwWRZLZLmQT4Ac42/p72OInw9yniiz3 hzjPU7VwqBexJFJkv9njjFPYHgbNtQSrNBqcfp7kqcwa890y4B12B0Ez30HNC/bHJZiZ uTIVXxZY8Xo6gK7w11CKloIaUYqsBVsARSxPJSvwogeGJxvJn7t9ngtKvldvN2bOUNJt Fb66jN/GHBP4m64LfsQWpHgW0G0ZUNRWS6L9E7LVdaO4u2oY/x7jRyrHCwzSaKLlGrWs b+Zw== X-Gm-Message-State: APjAAAUhjn7DWTKjFCdBCU8hdcU7ILvaKOV/Ri2Eyj2lS8vmC3SM18UP SIPNbhc/v/PzCdsYDhgsW/cx4hItaB0= X-Google-Smtp-Source: APXvYqzZGxtmKwZ1j7QZvBVzxdXGXdom8ptwX/pQlRuThGcOkzVdWLF8jTR6H/5QaAJYZ0p+Ul4wvw== X-Received: by 2002:a05:600c:290f:: with SMTP id i15mr15657682wmd.115.1577387564126; Thu, 26 Dec 2019 11:12:44 -0800 (PST) Received: from localhost.localdomain (p200300F1373A1900428D5CFFFEB99DB8.dip0.t-ipconnect.de. [2003:f1:373a:1900:428d:5cff:feb9:9db8]) by smtp.googlemail.com with ESMTPSA id o7sm8965937wmh.11.2019.12.26.11.12.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Dec 2019 11:12:43 -0800 (PST) From: Martin Blumenstingl To: linux-amlogic@lists.infradead.org, jbrunet@baylibre.com, sboyd@kernel.org Cc: narmstrong@baylibre.com, mturquette@baylibre.com, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Martin Blumenstingl Subject: [PATCH v2 1/2] clk: meson: meson8b: make the CCF use the glitch-free "mali" mux Date: Thu, 26 Dec 2019 20:12:23 +0100 Message-Id: <20191226191224.3785282-2-martin.blumenstingl@googlemail.com> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20191226191224.3785282-1-martin.blumenstingl@googlemail.com> References: <20191226191224.3785282-1-martin.blumenstingl@googlemail.com> MIME-Version: 1.0 Sender: linux-clk-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org The "mali_0" or "mali_1" clock trees should not be updated while the clock is running. Enforce this by setting CLK_SET_RATE_GATE on the "mali_0" and "mali_1" gates. This makes the CCF switch to the "mali_1" tree when "mali_0" is currently active and vice versa, which is exactly what the vendor driver does when updating the frequency of the mali clock. This fixes a potential hang when changing the GPU frequency at runtime. Fixes: 74e1f2521f16ff ("clk: meson: meson8b: add the GPU clock tree") Signed-off-by: Martin Blumenstingl --- drivers/clk/meson/meson8b.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/drivers/clk/meson/meson8b.c b/drivers/clk/meson/meson8b.c index 3408297bff65..9fd31f23b2a9 100644 --- a/drivers/clk/meson/meson8b.c +++ b/drivers/clk/meson/meson8b.c @@ -1772,8 +1772,11 @@ static struct clk_regmap meson8b_hdmi_sys = { /* * The MALI IP is clocked by two identical clocks (mali_0 and mali_1) - * muxed by a glitch-free switch on Meson8b and Meson8m2. Meson8 only - * has mali_0 and no glitch-free mux. + * muxed by a glitch-free switch on Meson8b and Meson8m2. The CCF can + * actually manage this glitch-free mux because it does top-to-bottom + * updates the each clock tree and switches to the "inactive" one when + * CLK_SET_RATE_GATE is set. + * Meson8 only has mali_0 and no glitch-free mux. */ static const struct clk_parent_data meson8b_mali_0_1_parent_data[] = { { .fw_name = "xtal", .name = "xtal", .index = -1, }, @@ -1838,7 +1841,7 @@ static struct clk_regmap meson8b_mali_0 = { &meson8b_mali_0_div.hw }, .num_parents = 1, - .flags = CLK_SET_RATE_PARENT, + .flags = CLK_SET_RATE_GATE | CLK_SET_RATE_PARENT, }, }; @@ -1893,7 +1896,7 @@ static struct clk_regmap meson8b_mali_1 = { &meson8b_mali_1_div.hw }, .num_parents = 1, - .flags = CLK_SET_RATE_PARENT, + .flags = CLK_SET_RATE_GATE | CLK_SET_RATE_PARENT, }, }; From patchwork Thu Dec 26 19:12:24 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Martin Blumenstingl X-Patchwork-Id: 11310691 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id D77EE14B7 for ; Thu, 26 Dec 2019 19:13:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B4D7C206CB for ; Thu, 26 Dec 2019 19:13:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=googlemail.com header.i=@googlemail.com header.b="klF/ucA9" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726809AbfLZTMu (ORCPT ); Thu, 26 Dec 2019 14:12:50 -0500 Received: from mail-wr1-f65.google.com ([209.85.221.65]:34830 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726812AbfLZTMr (ORCPT ); Thu, 26 Dec 2019 14:12:47 -0500 Received: by mail-wr1-f65.google.com with SMTP id g17so24330184wro.2; Thu, 26 Dec 2019 11:12:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=mmT0zF9OrkbiD8lj/0dOwJG0ayj5vgSHBwzc+nFQ5Gg=; b=klF/ucA9NSUXwoHRk1+Si9sfnX9CSLC+s/ebG98azsGLVJj1eJB4Gh6K3XoDxFlgwf e4nZ54SihxAA0YFfk6F238dYP9TkFDlIdBWYh29QftbkX6XICz13muXv7qfEFCaUuUQp CoschbCdrD2XhSLd6SH9cxWtcrwocY4bonRfJDgF/CSuyvksP5uvGZLJz34FGSHXsrYg zsLYDYhhxGFxKmdmRKvL1TWzEJnbemd/PDUm2ivSnrRB7Y9/J1HMeXM/nofk/edIPYUi LHC/Mn0XfMUpeWAegjzOMgII4GO2Y5c/8pyPTtVL95QBAq4GwW17CZ6pacVbQsAwGKv0 faqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=mmT0zF9OrkbiD8lj/0dOwJG0ayj5vgSHBwzc+nFQ5Gg=; b=qljpTyowgcev/GpTKpIF1bbKMxxMJBHBfQTJwUrOsrX0sSjGHasmclpp+PMK7l6KZP 6U1I2tp8hd2AsYh3EQh9GguTjbDOOw69TknhWue/slRheRSWixFHlbgM5hQqg/nJksPR YyMY/Qcj1wkbwkg+SMLiKG1qF39WzqsYN7AdUBWV/Z3M2VBykz08yC2A0a80fM6VpyxV q3KZn9FtAkuJRmqGZO+ImA7P+Ta9saxlM407jsUr2lcfmt+/H46YYHfy4zjMzCyIveiF k446i4r6wnH6MYXG/7n8nmVsRsOq207ozdZcgKGW3aGisCcJtaYcpx73lwqz9ZBhalgY /tsg== X-Gm-Message-State: APjAAAURew1Zp+M336YWrlF1KybZmgRAxkSaZhH2GwmFru1jU0JaVs43 FqSFw+F4+w32wed9jHaznT8= X-Google-Smtp-Source: APXvYqzFEhUhoMbvJ+dMFP1fHZY7u43hjf0Ydx1AtPN8kQZ0UFLEecCP0onL5y0FIk42usYSrzPz3A== X-Received: by 2002:a5d:4085:: with SMTP id o5mr45964730wrp.321.1577387565138; Thu, 26 Dec 2019 11:12:45 -0800 (PST) Received: from localhost.localdomain (p200300F1373A1900428D5CFFFEB99DB8.dip0.t-ipconnect.de. [2003:f1:373a:1900:428d:5cff:feb9:9db8]) by smtp.googlemail.com with ESMTPSA id o7sm8965937wmh.11.2019.12.26.11.12.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Dec 2019 11:12:44 -0800 (PST) From: Martin Blumenstingl To: linux-amlogic@lists.infradead.org, jbrunet@baylibre.com, sboyd@kernel.org Cc: narmstrong@baylibre.com, mturquette@baylibre.com, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Martin Blumenstingl Subject: [PATCH v2 2/2] clk: clarify that clk_set_rate() does updates from top to bottom Date: Thu, 26 Dec 2019 20:12:24 +0100 Message-Id: <20191226191224.3785282-3-martin.blumenstingl@googlemail.com> X-Mailer: git-send-email 2.24.1 In-Reply-To: <20191226191224.3785282-1-martin.blumenstingl@googlemail.com> References: <20191226191224.3785282-1-martin.blumenstingl@googlemail.com> MIME-Version: 1.0 Sender: linux-clk-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-clk@vger.kernel.org clk_set_rate() currently starts updating the rate for a clock at the top-most affected clock and then walks down the tree to update the bottom-most affected clock last. This behavior is important for protected clocks where we can switch between multiple parents to achieve the same output. An example for this is the mali clock tree on Amlogic SoCs: mali_0_mux (must not change when enabled) mali_0_div (must not change when enabled) mali_0 (gate) mali_1_mux (must not change when enabled) mali_1_div (must not change when enabled) mali_1 (gate) The final output can either use mali_0_gate or mali_1. To change the final output we must switch to the "inactive" tree. Assuming mali_0 is active, then we need to prepare mali_1 with the new desired rate and finally switch the output to the mali_1 tree. This process will then protect the mali_1 tree and at the same time unprotect the mali_0 tree. The next call to clk_set_rate() will then switch from the mali_1 tree back to mali_0. Signed-off-by: Martin Blumenstingl Acked-by: Stephen Boyd --- include/linux/clk.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/clk.h b/include/linux/clk.h index 18b7b95a8253..7fd6a1febcf4 100644 --- a/include/linux/clk.h +++ b/include/linux/clk.h @@ -627,6 +627,9 @@ long clk_round_rate(struct clk *clk, unsigned long rate); * @clk: clock source * @rate: desired clock rate in Hz * + * Updating the rate starts at the top-most affected clock and then + * walks the tree down to the bottom-most clock that needs updating. + * * Returns success (0) or negative errno. */ int clk_set_rate(struct clk *clk, unsigned long rate);