All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeffrey Hugo <jeffrey.l.hugo@gmail.com>
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>
Subject: Re: [PATCH v5 1/3] clk: qcom: Allow constant ratio freq tables for rcg
Date: Thu, 7 Nov 2019 15:12:09 -0700	[thread overview]
Message-ID: <CAOCk7NrHyY0+tF=90Z1WDa7VpgehDY7kHiqcR6g8K_P_uRpRQw@mail.gmail.com> (raw)
In-Reply-To: <20191107214352.8A82E2166E@mail.kernel.org>

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?

  reply	other threads:[~2019-11-07 22:12 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-31 18:55 [PATCH v5 0/3] MSM8998 GPUCC Support Jeffrey Hugo
2019-10-31 18:57 ` [PATCH v5 1/3] clk: qcom: Allow constant ratio freq tables for rcg Jeffrey Hugo
2019-11-04 18:04   ` Joe Perches
2019-11-07 21:43   ` Stephen Boyd
2019-11-07 22:12     ` Jeffrey Hugo [this message]
2019-11-08  6:44       ` Stephen Boyd
2019-10-31 18:57 ` [PATCH v5 2/3] clk: qcom: Add MSM8998 GPU Clock Controller (GPUCC) driver Jeffrey Hugo
2019-11-07 21:44   ` Stephen Boyd
2019-10-31 18:58 ` [PATCH v5 3/3] arm64: dts: qcom: msm8998: Add gpucc node Jeffrey Hugo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAOCk7NrHyY0+tF=90Z1WDa7VpgehDY7kHiqcR6g8K_P_uRpRQw@mail.gmail.com' \
    --to=jeffrey.l.hugo@gmail.com \
    --cc=agross@kernel.org \
    --cc=bjorn.andersson@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.w.gonzalez@free.fr \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.