All of lore.kernel.org
 help / color / mirror / Atom feed
From: Doug Anderson <dianders@chromium.org>
To: Kever Yang <kever.yang@rock-chips.com>
Cc: "Heiko Stübner" <heiko@sntech.de>,
	"Mike Turquette" <mturquette@linaro.org>,
	"Sonny Rao" <sonnyrao@chromium.org>,
	"Addy Ke" <addy.ke@rock-chips.com>,
	"Eddie Cai" <cf@rock-chips.com>,
	"ZhenFu Fang" <fzf@rock-chips.com>,
	"Yakir Yang" <ykk@rock-chips.com>, 姚智情 <yzq@rock-chips.com>,
	"戴克霖 (Jack)" <dkl@rock-chips.com>,
	"Tao Huang" <huangtao@rock-chips.com>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/5] clk: rockchip: add full support for HDMI clock on rk3288
Date: Thu, 13 Nov 2014 14:59:06 -0800	[thread overview]
Message-ID: <CAD=FV=Vzec3Qm-kc6zZ4VxSREoZbzVkWbzp-noHYdcEVrLYYSw@mail.gmail.com> (raw)
In-Reply-To: <54647142.4080800@rock-chips.com>

Hi,

On Thu, Nov 13, 2014 at 12:52 AM, Kever Yang <kever.yang@rock-chips.com> wrote:
> Hi Heiko,
>
> On 11/07/2014 05:06 AM, Heiko Stübner wrote:
>>
>> Hi Kever,
>>
>> Am Dienstag, 4. November 2014, 15:52:34 schrieb Kever Yang:
>>>
>>> we are going to make a clock usage solution for rk3288:
>>> 1. CPLL and GPLL always not change after assign init;
>>> 2. NPLL default as 500MHz, may used for most scene;
>>> 3. NPLL may be changed by VOP(HDMI) clock for some special
>>>     frequency requirement.
>>>
>>>      I test it with rk3288 evb on top of Heiko's clk-for-next
>>
>> In general I'm not really sure if allowing one component to arbitarily
>> change
>> a shared clock wouldn't result in trouble.
>>
>> At the moment only dclk_vop0 is included in your series, while the hdmi
>> controller can connect to both vop0 and vop1.
>> And as Doug mentioned the gpu also has the npll as one possible source.
>
> I think the problem GPU HANGs with 480MHz clock from usbphy has
> been fixed with my patch to gerrit:
> https://chromium-review.googlesource.com/#/c/229554/
>>
>>
>> Looking through the clock-tree there are a lot more components possibly
>> using
>> (or wanting to use) the npll: of course the VOPs, the edp, hdmi, isp,
>> hevc,
>> gpu, tsp uart0 and gmac. So I'm slightly uncomfortable with somehow
>> reserving
>> the npll for VOP0 alone.
>
> It's true that I customized the usage of npll for VOP0 when we need some
> very special frequency, but it doesn't means other modules can't use the
> npll, it will always decided by clock core for module clocks that which
> parent
> is the best.

We will just need to be very careful.  As I've mentioned in the past
we'll need to think about what happens to other clocks that happen to
be parented by NPLL whenever we change it.

So if we do this:

1. NPLL happens to be 500MHz.
2. We set GPU to be 500MHz and it picks NPLL.
3. We change NPLL to a different speed (like 600MHz).

...I believe in this scenario the GPU would start running at 600MHz
immediately.  We'd need to add special code to watch out for this and
pick an alternate clock for the GPU (like the USB 480) before the NPLL
change.  If NPLL later changes back to 500MHz and the GPU still wanted
500MHz, we'd have to decide what to do.


The summary is: it's pretty complicated

WARNING: multiple messages have this Message-ID (diff)
From: dianders@chromium.org (Doug Anderson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/5] clk: rockchip: add full support for HDMI clock on rk3288
Date: Thu, 13 Nov 2014 14:59:06 -0800	[thread overview]
Message-ID: <CAD=FV=Vzec3Qm-kc6zZ4VxSREoZbzVkWbzp-noHYdcEVrLYYSw@mail.gmail.com> (raw)
In-Reply-To: <54647142.4080800@rock-chips.com>

Hi,

On Thu, Nov 13, 2014 at 12:52 AM, Kever Yang <kever.yang@rock-chips.com> wrote:
> Hi Heiko,
>
> On 11/07/2014 05:06 AM, Heiko St?bner wrote:
>>
>> Hi Kever,
>>
>> Am Dienstag, 4. November 2014, 15:52:34 schrieb Kever Yang:
>>>
>>> we are going to make a clock usage solution for rk3288:
>>> 1. CPLL and GPLL always not change after assign init;
>>> 2. NPLL default as 500MHz, may used for most scene;
>>> 3. NPLL may be changed by VOP(HDMI) clock for some special
>>>     frequency requirement.
>>>
>>>      I test it with rk3288 evb on top of Heiko's clk-for-next
>>
>> In general I'm not really sure if allowing one component to arbitarily
>> change
>> a shared clock wouldn't result in trouble.
>>
>> At the moment only dclk_vop0 is included in your series, while the hdmi
>> controller can connect to both vop0 and vop1.
>> And as Doug mentioned the gpu also has the npll as one possible source.
>
> I think the problem GPU HANGs with 480MHz clock from usbphy has
> been fixed with my patch to gerrit:
> https://chromium-review.googlesource.com/#/c/229554/
>>
>>
>> Looking through the clock-tree there are a lot more components possibly
>> using
>> (or wanting to use) the npll: of course the VOPs, the edp, hdmi, isp,
>> hevc,
>> gpu, tsp uart0 and gmac. So I'm slightly uncomfortable with somehow
>> reserving
>> the npll for VOP0 alone.
>
> It's true that I customized the usage of npll for VOP0 when we need some
> very special frequency, but it doesn't means other modules can't use the
> npll, it will always decided by clock core for module clocks that which
> parent
> is the best.

We will just need to be very careful.  As I've mentioned in the past
we'll need to think about what happens to other clocks that happen to
be parented by NPLL whenever we change it.

So if we do this:

1. NPLL happens to be 500MHz.
2. We set GPU to be 500MHz and it picks NPLL.
3. We change NPLL to a different speed (like 600MHz).

...I believe in this scenario the GPU would start running at 600MHz
immediately.  We'd need to add special code to watch out for this and
pick an alternate clock for the GPU (like the USB 480) before the NPLL
change.  If NPLL later changes back to 500MHz and the GPU still wanted
500MHz, we'd have to decide what to do.


The summary is: it's pretty complicated

  reply	other threads:[~2014-11-13 22:59 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-04  7:52 [PATCH 0/5] clk: rockchip: add full support for HDMI clock on rk3288 Kever Yang
2014-11-04  7:52 ` Kever Yang
2014-11-04  7:52 ` [PATCH 1/5] clk: rockchip: add some clock rate into rate table for rk3288 Kever Yang
2014-11-04  7:52   ` Kever Yang
2014-11-04  7:52 ` [PATCH 2/5] clk: divider: make clk_divider_recalc/set_rate available Kever Yang
2014-11-04  7:52 ` [PATCH 3/5] clk: rockchip: introduce the div_ops handling for composite branches Kever Yang
2014-11-04  7:52   ` Kever Yang
2014-11-04  7:52 ` [PATCH 4/5] clk: rockchip: add the vop_determine_rate for vop dclock Kever Yang
2014-11-04  7:52   ` Kever Yang
2014-11-04  7:52 ` [PATCH 5/5] clk: rockchip: change DCLK_VOP0 to use new COMPOSITE_DIVOPS Kever Yang
2014-11-04  7:52   ` Kever Yang
2014-11-06 21:06 ` [PATCH 0/5] clk: rockchip: add full support for HDMI clock on rk3288 Heiko Stübner
2014-11-06 21:06   ` Heiko Stübner
2014-11-13  8:52   ` Kever Yang
2014-11-13  8:52     ` Kever Yang
2014-11-13 22:59     ` Doug Anderson [this message]
2014-11-13 22:59       ` Doug Anderson
     [not found]       ` <20141114014605.25314.49766@quantum>
2014-11-14  8:58         ` Kever Yang
2014-11-14  8:58           ` Kever Yang
2016-01-19 12:02       ` Tomeu Vizoso
2016-01-19 12:02         ` Tomeu Vizoso
2016-01-20 16:50         ` Doug Anderson
2016-01-20 16:50           ` Doug Anderson
2016-01-21  9:03           ` Tomeu Vizoso
2016-01-21  9:03             ` Tomeu Vizoso
2016-01-21 20:11             ` Doug Anderson
2016-01-21 20:11               ` Doug Anderson
2016-01-22 14:00               ` Tomeu Vizoso
2016-01-22 14:00                 ` Tomeu Vizoso
2016-01-22 17:07                 ` Doug Anderson
2016-01-22 17:07                   ` Doug Anderson
2016-01-26  8:28                   ` Tomeu Vizoso
2016-01-26  8:28                     ` Tomeu Vizoso
2016-01-26 16:32                     ` Doug Anderson
2016-01-26 16:32                       ` Doug Anderson
2016-01-27 10:20                       ` Tomeu Vizoso
2016-01-27 10:20                         ` Tomeu Vizoso
2016-01-27 16:46                         ` Doug Anderson
2016-01-27 16:46                           ` Doug Anderson

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='CAD=FV=Vzec3Qm-kc6zZ4VxSREoZbzVkWbzp-noHYdcEVrLYYSw@mail.gmail.com' \
    --to=dianders@chromium.org \
    --cc=addy.ke@rock-chips.com \
    --cc=cf@rock-chips.com \
    --cc=dkl@rock-chips.com \
    --cc=fzf@rock-chips.com \
    --cc=heiko@sntech.de \
    --cc=huangtao@rock-chips.com \
    --cc=kever.yang@rock-chips.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mturquette@linaro.org \
    --cc=sonnyrao@chromium.org \
    --cc=ykk@rock-chips.com \
    --cc=yzq@rock-chips.com \
    /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.