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;
MIME-Version: 1.0
References: <20191031185538.15402-1-jeffrey.l.hugo@gmail.com>
 <20191031185715.15504-1-jeffrey.l.hugo@gmail.com> <20191107214352.8A82E2166E@mail.kernel.org>
In-Reply-To: <20191107214352.8A82E2166E@mail.kernel.org>
From:   Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
Date:   Thu, 7 Nov 2019 15:12:09 -0700
Message-ID: <CAOCk7NrHyY0+tF=90Z1WDa7VpgehDY7kHiqcR6g8K_P_uRpRQw@mail.gmail.com>
Subject: Re: [PATCH v5 1/3] clk: qcom: Allow constant ratio freq tables for rcg
To:     Stephen Boyd <sboyd@kernel.org>
Cc:     Bjorn Andersson <bjorn.andersson@linaro.org>,
        Michael Turquette <mturquette@baylibre.com>,
        Andy Gross <agross@kernel.org>,
        Marc Gonzalez <marc.w.gonzalez@free.fr>,
        MSM <linux-arm-msm@vger.kernel.org>, linux-clk@vger.kernel.org,
        lkml <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Nov 7, 2019 at 2:43 PM Stephen Boyd <sboyd@kernel.org> wrote:
>
> Quoting Jeffrey Hugo (2019-10-31 11:57:15)
> > Some RCGs (the gfx_3d_src_clk in msm8998 for example) are basically just
> > some constant ratio from the input across the entire frequency range.  It
> > would be great if we could specify the frequency table as a single entry
> > constant ratio instead of a long list, ie:
> >
> >         { .src = P_GPUPLL0_OUT_EVEN, .pre_div = 3 },
> >         { }
> >
> > So, lets support that.
> >
> > We need to fix a corner case in qcom_find_freq() where if the freq table
> > is non-null, but has no frequencies, we end up returning an "entry" before
> > the table array, which is bad.  Then, we need ignore the freq from the
> > table, and instead base everything on the requested freq.
> >
> > Suggested-by: Stephen Boyd <sboyd@kernel.org>
> > Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
> > ---
>
> Applied to clk-next and fixed the space thing. I guess ceil/floor
> rounding isn't a problem?
>

Thanks for fixing the nit.

Hmm.  Looking back at it, floor is only used with the rcg_floor_ops.
Right now, you can't use a constant ratio table with rcg_floor_ops -
looks like you'd probably hit a null pointer dereference.  I'm having
trouble seeing how the floor operation would work with this constant
ratio idea in a way that would be different than the normal rcg_ops.
I think I would say that either you have a good reason for using the
constant ratio table, in which case you should be using the normal
rcg_ops, or you have a good reason for using floor which is then
incompatible with a constant ratio table.  If you think that the
constant ratio table concept should be applied to floor ops, can you
please detail what you expect the behavior to be?