From patchwork Sun Sep 24 20:00:20 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jerome Brunet X-Patchwork-Id: 114144 Delivered-To: patch@linaro.org Received: by 10.140.106.117 with SMTP id d108csp1853779qgf; Sun, 24 Sep 2017 13:00:42 -0700 (PDT) X-Received: by 10.98.75.12 with SMTP id y12mr5366953pfa.43.1506283241982; Sun, 24 Sep 2017 13:00:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1506283241; cv=none; d=google.com; s=arc-20160816; b=KyAf2qX8vH0lqRuZ2Cvc+R3XEif/+Rt//saOERh4RIBdiHDkmx4xkC/qxrevJiPT9S TtoAU5d1I15RnCCcUUEhV+xoi5MWIHIWiZmUhyX6lvDvWqTkMewLFTLeB3HRXW020eRq HX1dY9qcRMJ3qDBbTj9Q8U8K1Fp9G61GutHCqPHUyrh2mfjrQw+zAoMw5BPCdkhqDjvr uDZ9dsL3dkZbGiYRXT8COSIXxdGe1v5Sum4jry5X05aUBKCkLmBOnavYv+fxmwRDFBfn RtGA46qOD81LR4Jwy651/PVvRBQ00AyEtG1DsUID9Lv5lfaETylQI3fzp9Kw2wdo5a2H P2eQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dkim-signature:arc-authentication-results; bh=aFlhKiVUpjvMr1zuncwsa8mIo1YTmyLnsdSLBfL/tuA=; b=GWlUSJG7dFIDHmVbtI0VLjWzC6b7Jn/SkzewqiKIFlqboIPFHrX1E3iEoNT5oKYjP9 Lon9wo3dAGy3DSxsU3OJePvtZDQ2rveTSTEnfgp4C/OHQFQI0zkG0/jtJVBgd/zrH5pt AYidjvXf8yo+h3g43i9tYmcwPaZk5BFTLINynjak4dvTl8DAnP6jyk81CIevcPWJQX62 y8Kq1QlhhpuswR87j24Kj1s23RRqJsjXvTWRljddwD4RVS6yWSvv7lzfnJw5xyAMtoWg 38yUDY+Qor1+68CtzWNCmrUCLTmP5Qu85LT8tI2ji43mq6D2Mfqz6BtEXy2JeDtqMOfB kmbw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=UJ0D/vjx; 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 w31si3028257pla.354.2017.09.24.13.00.41; Sun, 24 Sep 2017 13:00:41 -0700 (PDT) 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; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=UJ0D/vjx; 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 S1752891AbdIXUAk (ORCPT + 26 others); Sun, 24 Sep 2017 16:00:40 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:46578 "EHLO mail-wm0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752824AbdIXUAh (ORCPT ); Sun, 24 Sep 2017 16:00:37 -0400 Received: by mail-wm0-f54.google.com with SMTP id m72so14326691wmc.1 for ; Sun, 24 Sep 2017 13:00:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=aFlhKiVUpjvMr1zuncwsa8mIo1YTmyLnsdSLBfL/tuA=; b=UJ0D/vjxHgU92dSI+FmEQ7sbhEQjLkl9ZqkYmdbiGWlSu5j+IUllOoQ77kPSDNbeij Za6p8V49M219SWczFgcwxLHME6oI266qvOQzXPhpQfopIQFgUfGU51MC/0jdM9wVFhOw Xom6kSY40Z2Gm8GQRC/RSUnu/q/zCgU001qNwbZgK8rH7UzwR4gKjE0qdYRC1DOOKuuY zc9kbPynhOyQPqbgLTlDANUviaDT6Xjl6dA5NJxq5tnvqGHkENYoeM7bVXwZINQ8mAU8 OkpSNgSp7IVKqOEpD0RQ2Wz+Gr0MRDdXdAAOOV6Ce4UKlc/q0AEIHoG1zkP0jqmmeWP3 PkLA== 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; bh=aFlhKiVUpjvMr1zuncwsa8mIo1YTmyLnsdSLBfL/tuA=; b=hnN2NWzYxvB8cfP4VbiHsepjP8T/OKM0vKoCiOYZ8hd33PwD4Rh/L0W9lIStrYrGNW fWlo/HRKgcmf/KZTe+DNVSRVxHAJufCAb7cKLSBGKeHAxVbsnsSNa++jN/vMyA/sWi3k y8IZs87huJOD2b7fP8gpJNjtd+fdS9wZFLND9bRebiX1V+ZAoP5yVY9WS3Qy3RSoNU3f 6rmhmtg9I/n08dLdGoUK4qrz2bp2ZI8tVUPfUzFbQXLGk1wUMqLTiqnFujg9g16SKO+m 99P4Tv9YuMrpjbhvPr8dwFz8hMAqKho6z6VDB+mTl300g7yZjNxZ3WD8I9Vml/mARfCl tCqg== X-Gm-Message-State: AHPjjUjMMPyn+u5RRn7tt0pDTt0kW5c/xYHKgTagoWXfYWH0i5CQsZ+o OaOl2+xhyQlYEEIiy0TmjF2mFQ== X-Google-Smtp-Source: AOwi7QDG97inFWPPWDr1XeoX0IW83WjIEgW8W47SBwVImnjqJwi9gQEJOrT/vjpNoC65PvPrSKsdkg== X-Received: by 10.28.154.138 with SMTP id c132mr7858780wme.2.1506283236431; Sun, 24 Sep 2017 13:00:36 -0700 (PDT) Received: from localhost.localdomain (cag06-3-82-243-161-21.fbx.proxad.net. [82.243.161.21]) by smtp.googlemail.com with ESMTPSA id j5sm6786144wmg.8.2017.09.24.13.00.35 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 24 Sep 2017 13:00:35 -0700 (PDT) From: Jerome Brunet To: Stephen Boyd , Michael Turquette Cc: Jerome Brunet , linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org, Russell King , Linus Walleij , Quentin Schulz , Kevin Hilman , Peter De Schrijver Subject: [PATCH v4 00/10] clk: implement clock rate protection mechanism Date: Sun, 24 Sep 2017 22:00:20 +0200 Message-Id: <20170924200030.6227-1-jbrunet@baylibre.com> X-Mailer: git-send-email 2.13.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This Patchset is related the RFC [0] and the discussion around CLK_SET_RATE_GATE available here [1] This patchset introduce clock protection to the CCF core. This can then be used for: * Provide a way for a consumer to claim exclusivity over the rate control of a provider. Some clock consumers require that a clock rate must not deviate from its selected frequency. There can be several reasons for this, not least of which is that some hardware may not be able to handle or recover from a glitch caused by changing the clock rate while the hardware is in operation. For such HW, The ability to get exclusive control of a clock's rate, and release that exclusivity, could be seen as a fundamental clock rate control primitive. The exclusivity is not preemptible, so when claimed more than once, is rate is effectively locked. * Provide a similar functionality to providers themselves, fixing CLK_SET_RATE_GATE flag (enforce clock gating along the tree). While there might still be a few platforms relying the broken implementation, tests done has shown this change to be pretty safe. Changes since v3: [3] - Reorder patches following Stephen comments - Add before/after examples to the cosmetic change - Remove loops around protection where possible - Rename the API from "protect" to "exclusive" which decribe what the code better Changes since v2: [2] - Fix issues reported by Adriana Reus (Thanks !) - Dropped patch "clk: move CLK_SET_RATE_GATE protection from prepare to enable". This was broken as the protect count, like the prepare_count should only be accessed under the prepare_lock. Changes since v1: [1] - Check if the rate would actually change before continuing, and bail-out early if not. Changes since RFC: [0] - s/clk_protect/clk_rate_protect - Request rework around core_nolock function - Add clk_set_rate_protect - Reword clk_rate_protect and clk_unprotect documentation - Add few comments to explain the code - Add fixes for CLK_SET_RATE_GATE This was tested with the audio use case mentioned in [1] [0]: https://lkml.kernel.org/r/20170321183330.26722-1-jbrunet@baylibre.com [1]: https://lkml.kernel.org/r/148942423440.82235.17188153691656009029@resonance [2]: https://lkml.kernel.org/r/20170521215958.19743-1-jbrunet@baylibre.com [3]: https://lkml.kernel.org/r/20170612194438.12298-1-jbrunet@baylibre.com Jerome Brunet (10): clk: fix incorrect usage of ENOSYS clk: take the prepare lock out of clk_core_set_parent clk: add clk_core_set_phase_nolock function clk: rework calls to round and determine rate callbacks clk: use round rate to bail out early in set_rate clk: add clock protection mechanism to clk core clk: cosmetic changes to clk_summary debugfs entry clk: fix CLK_SET_RATE_GATE with clock rate protection clk: add clk_rate_exclusive api clk: fix set_rate_range when current rate is out of range drivers/clk/clk.c | 505 +++++++++++++++++++++++++++++++++++++------ include/linux/clk-provider.h | 1 + include/linux/clk.h | 57 +++++ 3 files changed, 492 insertions(+), 71 deletions(-) -- 2.13.5