Received: by 2002:a05:6520:4211:b029:f4:110d:56bc with SMTP id o17csp1549601lkv; Wed, 19 May 2021 12:32:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxzYEY9PYBxTduFwVVxxdAIN6d/5CHCzmtAhMdzGnzF/kdixlF+o08xeYxJW31gJM2gZiSN X-Received: by 2002:a5d:9c58:: with SMTP id 24mr1270473iof.153.1621452732444; Wed, 19 May 2021 12:32:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1621452732; cv=none; d=google.com; s=arc-20160816; b=yoHqDW1+hoALhQI1kU0b95IdcTT31BZkui+MAHJLSiaUMHSDuuYLrBDwIfLm2wJh+p 8NiwoWJry7xSTscDWg5q/Gwsa7VRzMDKgK5YfQFSRDKr1BHWRPVNIQVwQNGmNa79SNUK D4vinv+/asg9pFhU9jYTd/EBje4UlfLmP05TnQIwqj1R1wZRJXQ2CdDJszs1f0vb+7V2 J/LGvYQGozhNuW664dq8CeTGy1txmMSgLeX2XeloyxaRZVUcQGheCRmwd6xXhNH2bJcI dLm218aE6YWt70dQszpHytlPBPqJ9RYdB8IWImr0RC1x3bBU/UWNEZ9rPSg6c+AJQfaA OliA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:date:message-id:in-reply-to:subject :cc:to:from:user-agent:references:dkim-signature; bh=bAo7Ei/TUi10dkjUS5XYUKLdKDhp8o5GDEEhLvW8E/8=; b=gfKqmYII065bX9EBW97tIR0UxkRs/mzARgyuk1qG2sAkfm6jfovYj3AFayI2byLrzn G/mGt8Zds53Qrk8lLTKvxhgdf9t1BQdk3WZHgaIdGQBt0XeppAD60yjwyIwEM1gv0J4H y+4RUOFgIZO5upVio0LYDVaUvWU8MQM8/MiGQXpuw5kTB7oNSL6YcIQODAtlet/Cobl/ 55SsjIOW0vmWAOx0zK1SOqXdmxspK4vsujRn3XkvDipWge2N7XB2hzc6wYPo5hbsTxGE kJ6iQDU/w/USPVf8tHsN8wKAbV/vabKqNFv4bekmSkcrvxIh0gTcKbFgf4GSG9j/huh/ Wlgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=oL1E6C3s; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t19si102283iog.66.2021.05.19.12.31.59; Wed, 19 May 2021 12:32:12 -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=@baylibre-com.20150623.gappssmtp.com header.s=20150623 header.b=oL1E6C3s; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1352903AbhESMdE (ORCPT + 99 others); Wed, 19 May 2021 08:33:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42546 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229507AbhESMdD (ORCPT ); Wed, 19 May 2021 08:33:03 -0400 Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B6884C06175F for ; Wed, 19 May 2021 05:31:43 -0700 (PDT) Received: by mail-wm1-x335.google.com with SMTP id f75-20020a1c1f4e0000b0290171001e7329so3223161wmf.1 for ; Wed, 19 May 2021 05:31:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baylibre-com.20150623.gappssmtp.com; s=20150623; h=references:user-agent:from:to:cc:subject:in-reply-to:message-id :date:mime-version; bh=bAo7Ei/TUi10dkjUS5XYUKLdKDhp8o5GDEEhLvW8E/8=; b=oL1E6C3sCn5SHZuQHZQ4qSR511zUkj1ReiFbYY7jMF3nHEXzAwrJBxV5BlKQfH5J4o RP7yi+L6XxHJn7+zxVHoPJa0rOXsTP3b/bODa1ijp9XrcLFVIs8L0JGMjxcSSswU0LeS jybN7+Bw8gTm3Ru3oTvtzkLVn1YlrM0zMXUv0+mNX5NrcAFh9+W+stJKmRHzv/7xAqr+ fmTYrsF+ZlDhafMfvFJTkjDOTLrYgCGMcCqASE96TXMJbuP7/CsJPZM07Tt889kaAskz QUctp0dN9NOVjtNLssocI3ukWFH6O/rSqk7dKPcnuProg7E/pu0p9okkQ4i2uXvEkUqv qJtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:message-id:date:mime-version; bh=bAo7Ei/TUi10dkjUS5XYUKLdKDhp8o5GDEEhLvW8E/8=; b=KKOO0z9De/TcB+TBmUAiuXp4ljl+TVglNdm/qPY1z6QOtPcfz5Ug1pFTAmm6zjlg3O SNX9qmm6XUtzx43iBI9clSmetvLwILC7dZcEgy/PNxuL6TJTgCbmm4vHhGnCW8xeIntp IcJ0dPI/dq0sZp9g4CotT4uMUeC9P0p+NzatdEi5Gn35jrz6QNIsJWVxQkXIU8yWwJib qLvm86gKtlgR59HnmDpwB7b13lRoxSHvQ5n3AXT3+Dp0XHdd0OElUbjE9VJxoU7MNPSs PL7n2TsnTG2hPOSt4g6FzHhgXd8MC8nXe2wuTyG9Q8wKY/A4NrTk98ZeYl4axni56TZu zrWw== X-Gm-Message-State: AOAM530pC2RJfwDfx467mYXVRZir/LvVVdDd+FlxeIWmBvIy746zZHqM lcKyF6CrgIAyX2hHsHzBZjr0dg== X-Received: by 2002:a05:600c:19cb:: with SMTP id u11mr11538782wmq.185.1621427502264; Wed, 19 May 2021 05:31:42 -0700 (PDT) Received: from localhost (82-65-169-74.subs.proxad.net. [82.65.169.74]) by smtp.gmail.com with ESMTPSA id u19sm1185904wmq.7.2021.05.19.05.31.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 19 May 2021 05:31:41 -0700 (PDT) References: <20210517203724.1006254-1-martin.blumenstingl@googlemail.com> <20210517203724.1006254-2-martin.blumenstingl@googlemail.com> <1jtun01o5p.fsf@starbuckisacylon.baylibre.com> User-agent: mu4e 1.4.15; emacs 27.1 From: Jerome Brunet To: Martin Blumenstingl Cc: mturquette@baylibre.com, sboyd@kernel.org, Neil Armstrong , linux-clk@vger.kernel.org, khilman@baylibre.com, linux-kernel@vger.kernel.org, linux-amlogic@lists.infradead.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH RFC v1 1/3] clk: divider: Add re-usable determine_rate implementations In-reply-to: Message-ID: <1jv97eaor6.fsf@starbuckisacylon.baylibre.com> Date: Wed, 19 May 2021 14:31:41 +0200 MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 18 May 2021 at 22:33, Martin Blumenstingl wrote: > Hi Jerome, > > On Tue, May 18, 2021 at 9:44 AM Jerome Brunet wrote: > [...] >> > +int divider_ro_determine_rate(struct clk_hw *hw, struct clk_rate_request *req, >> > + const struct clk_div_table *table, u8 width, >> > + unsigned long flags, unsigned int val) >> > +{ >> > + int div; >> > + >> > + div = _get_div(table, val, flags, width); >> > + >> > + /* Even a read-only clock can propagate a rate change */ >> > + if (clk_hw_get_flags(hw) & CLK_SET_RATE_PARENT) { >> > + if (!req->best_parent_hw) >> > + return -EINVAL; >> > + >> > + req->best_parent_rate = clk_hw_round_rate(req->best_parent_hw, >> > + req->rate * div); >> > + } >> > + >> > + req->rate = DIV_ROUND_UP_ULL((u64)req->best_parent_rate, div); >> > + >> > + return 0; >> > +} >> > +EXPORT_SYMBOL_GPL(divider_ro_determine_rate); >> >> For a final version, could you factorize the code with the .round_rate() >> variant ? It would remove a bit of duplication. > my first idea was to basically let the new _determine_rate code just > forward all relevant parameters to _round_rate > however, I discarded that as it turned out to be less understandable > for me as parameters need to be mapped in both ways > > while writing this mail I noticed that the opposite direction > (meaning: _round_rate forwards to _determine_rate) will probably work. > I'll give it a try in the next days > if you had anything else in mind then please let me know Yep, the idea would be to use the determine_rate() part as the common implementation. AFAICT, all you need is to build req_rate structure in the round_rate() part. > >> Maybe determine_rate() can also replace round_rate() in the generic >> divider ops ? > sure, I'll add that as a separate patch in this series > note to myself: testing can be done with the MMC drivers as we're > using the generic clk_divider_ops there > > > Best regards, > Martin