All of lore.kernel.org
 help / color / mirror / Atom feed
From: Xing Zheng <zhengxing@rock-chips.com>
To: Doug Anderson <dianders@chromium.org>
Cc: "Heiko Stübner" <heiko@sntech.de>,
	"elaine zhang" <elaine.zhang@rock-chips.com>,
	"Tao Huang" <huangtao@rock-chips.com>,
	"Brian Norris" <briannorris@chromium.org>,
	"Yakir Yang" <ykk@rock-chips.com>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@codeaurora.org>,
	linux-clk <linux-clk@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] clk: rockchip: add pclk_vio_grf to critical clock on the RK3399
Date: Mon, 13 Jun 2016 11:30:22 +0800	[thread overview]
Message-ID: <575E28CE.2020808@rock-chips.com> (raw)
In-Reply-To: <575E240C.9060502@rock-chips.com>

Hi Doug,

On 2016年06月13日 11:10, Xing Zheng wrote:
> Hi Doug,
>
> On 2016年06月13日 05:32, Doug Anderson wrote:
>> Xing,
>>
>> On Sun, Jun 12, 2016 at 2:48 AM, Xing 
>> Zheng<zhengxing@rock-chips.com>  wrote:
>>> The pclk_vio_grf supply power for GRF IOs, if it is disabled, will
>>> cause abnormal operation of the GRF.
>>>
>>> The clock tree of the pclk_vio like this:
>>>               | --> pclk_vio_grf
>>> ... pclk_vio | --> pclk_mipi_dsi1
>>>               | --> pclk_mipi_dsi0
>>>
>>> and the pclk_mipi_dsi0 and pclk_mipi_dsi1 don't have the flag
>>> CLK_IGNORE_UNUSED, and they will be disabled by clk_disable_unused
>>> when startup:
>>> clk_disable_unused
>>>    --> clk_disable_unprepare
>>>      --> clk_disable
>>>        --> clk_core_disable(core->parent)
>>>
>>> then, the pclk_vio_grf also is disabled. Therefore, we need to add
>>> pclk_vio_grf to critical clock and avoid to disable pclk_vio and
>>> pclk_vio_grf.
>>>
>>> Tested-by: Yakir Yang<ykk@rock-chips.com>
>>> Signed-off-by: Yakir Yang<ykk@rock-chips.com>
>>> Signed-off-by: Brian Norris<briannorris@chromium.org>
>>> Signed-off-by: Xing Zheng<zhengxing@rock-chips.com>
>>> ---
>>>
>>>   drivers/clk/rockchip/clk-rk3399.c |    1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/clk/rockchip/clk-rk3399.c 
>>> b/drivers/clk/rockchip/clk-rk3399.c
>>> index b6742fa..7ecb12c3 100644
>>> --- a/drivers/clk/rockchip/clk-rk3399.c
>>> +++ b/drivers/clk/rockchip/clk-rk3399.c
>>> @@ -1485,6 +1485,7 @@ static const char *const 
>>> rk3399_cru_critical_clocks[] __initconst = {
>>>          "gpll_hclk_perilp1_src",
>>>          "gpll_aclk_perilp0_src",
>>>          "gpll_aclk_perihp_src",
>>> +       "pclk_vio_grf",
>> This clock is only needed when doing video output (like eDP), right?
>> That means it is not really a critical clock.  Critical clocks are
>> supposed to be ones that are needed for the basic functioning of the
>> system and that can never be turned off in any circumstances. In this
>> case, if someone were running a rk3399 device and didn't have any
>> video output they would want this clock off.
>>
>> Can you figure out in exactly which circumstances this clock needs to
>> be on and then add a proper consumer of this clock?  For instance, if
>> this clock is needed whenever the VOP is outputting data, then the VOP
>> should be a client and should turn this clock on and off when video is
>> being output.  If this clock is needed whenever you access VOP
>> registers, then the VOP should be a client and turn this clock on
>> around register accesses.
>>
>>
Additional, we are discussing that we should turn the "pclk_vio" on and 
off in
video drivers when the video consumer needs to this clock.

Thanks.

>>
> Yes, the pclk_vio_grf is needed for doing video output.
> andpclk_vio_grf supply for: grf_soc_con9, 20~26, grf_hdcp
>
> From our design folks, we have many GRF registers in different power 
> domains,
> and these GRF gates should be always enabled. In this case, we can 
> avoid some
> of the operations GRF registers exception problems, and it is only a 
> very small
> increase in  power consumption (aboult <=1ma).
>
> I will refer the latest TRM to update a new patch for always enable 
> these GRFs.
>
> Please drop this patch.

-- 
- Xing Zheng

WARNING: multiple messages have this Message-ID (diff)
From: Xing Zheng <zhengxing-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
To: Doug Anderson <dianders-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Cc: "Tao Huang" <huangtao-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
	"Heiko Stübner" <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>,
	"Michael Turquette"
	<mturquette-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>,
	"Brian Norris"
	<briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	"Stephen Boyd" <sboyd-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"Yakir Yang" <ykk-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
	"elaine zhang"
	<elaine.zhang-TNX95d0MmH7DzftRWevZcw@public.gmane.org>,
	linux-clk <linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [PATCH] clk: rockchip: add pclk_vio_grf to critical clock on the RK3399
Date: Mon, 13 Jun 2016 11:30:22 +0800	[thread overview]
Message-ID: <575E28CE.2020808@rock-chips.com> (raw)
In-Reply-To: <575E240C.9060502-TNX95d0MmH7DzftRWevZcw@public.gmane.org>

Hi Doug,

On 2016年06月13日 11:10, Xing Zheng wrote:
> Hi Doug,
>
> On 2016年06月13日 05:32, Doug Anderson wrote:
>> Xing,
>>
>> On Sun, Jun 12, 2016 at 2:48 AM, Xing 
>> Zheng<zhengxing@rock-chips.com>  wrote:
>>> The pclk_vio_grf supply power for GRF IOs, if it is disabled, will
>>> cause abnormal operation of the GRF.
>>>
>>> The clock tree of the pclk_vio like this:
>>>               | --> pclk_vio_grf
>>> ... pclk_vio | --> pclk_mipi_dsi1
>>>               | --> pclk_mipi_dsi0
>>>
>>> and the pclk_mipi_dsi0 and pclk_mipi_dsi1 don't have the flag
>>> CLK_IGNORE_UNUSED, and they will be disabled by clk_disable_unused
>>> when startup:
>>> clk_disable_unused
>>>    --> clk_disable_unprepare
>>>      --> clk_disable
>>>        --> clk_core_disable(core->parent)
>>>
>>> then, the pclk_vio_grf also is disabled. Therefore, we need to add
>>> pclk_vio_grf to critical clock and avoid to disable pclk_vio and
>>> pclk_vio_grf.
>>>
>>> Tested-by: Yakir Yang<ykk@rock-chips.com>
>>> Signed-off-by: Yakir Yang<ykk@rock-chips.com>
>>> Signed-off-by: Brian Norris<briannorris@chromium.org>
>>> Signed-off-by: Xing Zheng<zhengxing@rock-chips.com>
>>> ---
>>>
>>>   drivers/clk/rockchip/clk-rk3399.c |    1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/clk/rockchip/clk-rk3399.c 
>>> b/drivers/clk/rockchip/clk-rk3399.c
>>> index b6742fa..7ecb12c3 100644
>>> --- a/drivers/clk/rockchip/clk-rk3399.c
>>> +++ b/drivers/clk/rockchip/clk-rk3399.c
>>> @@ -1485,6 +1485,7 @@ static const char *const 
>>> rk3399_cru_critical_clocks[] __initconst = {
>>>          "gpll_hclk_perilp1_src",
>>>          "gpll_aclk_perilp0_src",
>>>          "gpll_aclk_perihp_src",
>>> +       "pclk_vio_grf",
>> This clock is only needed when doing video output (like eDP), right?
>> That means it is not really a critical clock.  Critical clocks are
>> supposed to be ones that are needed for the basic functioning of the
>> system and that can never be turned off in any circumstances. In this
>> case, if someone were running a rk3399 device and didn't have any
>> video output they would want this clock off.
>>
>> Can you figure out in exactly which circumstances this clock needs to
>> be on and then add a proper consumer of this clock?  For instance, if
>> this clock is needed whenever the VOP is outputting data, then the VOP
>> should be a client and should turn this clock on and off when video is
>> being output.  If this clock is needed whenever you access VOP
>> registers, then the VOP should be a client and turn this clock on
>> around register accesses.
>>
>>
Additional, we are discussing that we should turn the "pclk_vio" on and 
off in
video drivers when the video consumer needs to this clock.

Thanks.

>>
> Yes, the pclk_vio_grf is needed for doing video output.
> andpclk_vio_grf supply for: grf_soc_con9, 20~26, grf_hdcp
>
> From our design folks, we have many GRF registers in different power 
> domains,
> and these GRF gates should be always enabled. In this case, we can 
> avoid some
> of the operations GRF registers exception problems, and it is only a 
> very small
> increase in  power consumption (aboult <=1ma).
>
> I will refer the latest TRM to update a new patch for always enable 
> these GRFs.
>
> Please drop this patch.

-- 
- Xing Zheng



_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: zhengxing@rock-chips.com (Xing Zheng)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] clk: rockchip: add pclk_vio_grf to critical clock on the RK3399
Date: Mon, 13 Jun 2016 11:30:22 +0800	[thread overview]
Message-ID: <575E28CE.2020808@rock-chips.com> (raw)
In-Reply-To: <575E240C.9060502@rock-chips.com>

Hi Doug,

On 2016?06?13? 11:10, Xing Zheng wrote:
> Hi Doug,
>
> On 2016?06?13? 05:32, Doug Anderson wrote:
>> Xing,
>>
>> On Sun, Jun 12, 2016 at 2:48 AM, Xing 
>> Zheng<zhengxing@rock-chips.com>  wrote:
>>> The pclk_vio_grf supply power for GRF IOs, if it is disabled, will
>>> cause abnormal operation of the GRF.
>>>
>>> The clock tree of the pclk_vio like this:
>>>               | --> pclk_vio_grf
>>> ... pclk_vio | --> pclk_mipi_dsi1
>>>               | --> pclk_mipi_dsi0
>>>
>>> and the pclk_mipi_dsi0 and pclk_mipi_dsi1 don't have the flag
>>> CLK_IGNORE_UNUSED, and they will be disabled by clk_disable_unused
>>> when startup:
>>> clk_disable_unused
>>>    --> clk_disable_unprepare
>>>      --> clk_disable
>>>        --> clk_core_disable(core->parent)
>>>
>>> then, the pclk_vio_grf also is disabled. Therefore, we need to add
>>> pclk_vio_grf to critical clock and avoid to disable pclk_vio and
>>> pclk_vio_grf.
>>>
>>> Tested-by: Yakir Yang<ykk@rock-chips.com>
>>> Signed-off-by: Yakir Yang<ykk@rock-chips.com>
>>> Signed-off-by: Brian Norris<briannorris@chromium.org>
>>> Signed-off-by: Xing Zheng<zhengxing@rock-chips.com>
>>> ---
>>>
>>>   drivers/clk/rockchip/clk-rk3399.c |    1 +
>>>   1 file changed, 1 insertion(+)
>>>
>>> diff --git a/drivers/clk/rockchip/clk-rk3399.c 
>>> b/drivers/clk/rockchip/clk-rk3399.c
>>> index b6742fa..7ecb12c3 100644
>>> --- a/drivers/clk/rockchip/clk-rk3399.c
>>> +++ b/drivers/clk/rockchip/clk-rk3399.c
>>> @@ -1485,6 +1485,7 @@ static const char *const 
>>> rk3399_cru_critical_clocks[] __initconst = {
>>>          "gpll_hclk_perilp1_src",
>>>          "gpll_aclk_perilp0_src",
>>>          "gpll_aclk_perihp_src",
>>> +       "pclk_vio_grf",
>> This clock is only needed when doing video output (like eDP), right?
>> That means it is not really a critical clock.  Critical clocks are
>> supposed to be ones that are needed for the basic functioning of the
>> system and that can never be turned off in any circumstances. In this
>> case, if someone were running a rk3399 device and didn't have any
>> video output they would want this clock off.
>>
>> Can you figure out in exactly which circumstances this clock needs to
>> be on and then add a proper consumer of this clock?  For instance, if
>> this clock is needed whenever the VOP is outputting data, then the VOP
>> should be a client and should turn this clock on and off when video is
>> being output.  If this clock is needed whenever you access VOP
>> registers, then the VOP should be a client and turn this clock on
>> around register accesses.
>>
>>
Additional, we are discussing that we should turn the "pclk_vio" on and 
off in
video drivers when the video consumer needs to this clock.

Thanks.

>>
> Yes, the pclk_vio_grf is needed for doing video output.
> andpclk_vio_grf supply for: grf_soc_con9, 20~26, grf_hdcp
>
> From our design folks, we have many GRF registers in different power 
> domains,
> and these GRF gates should be always enabled. In this case, we can 
> avoid some
> of the operations GRF registers exception problems, and it is only a 
> very small
> increase in  power consumption (aboult <=1ma).
>
> I will refer the latest TRM to update a new patch for always enable 
> these GRFs.
>
> Please drop this patch.

-- 
- Xing Zheng

  reply	other threads:[~2016-06-13  3:30 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-12  9:48 [PATCH] clk: rockchip: add pclk_vio_grf to critical clock on the RK3399 Xing Zheng
2016-06-12  9:48 ` Xing Zheng
2016-06-12  9:48 ` Xing Zheng
2016-06-12 21:32 ` Doug Anderson
2016-06-12 21:32   ` Doug Anderson
2016-06-13  3:10   ` Xing Zheng
2016-06-13  3:10     ` Xing Zheng
2016-06-13  3:30     ` Xing Zheng [this message]
2016-06-13  3:30       ` Xing Zheng
2016-06-13  3:30       ` Xing Zheng
2016-06-13 23:46     ` Doug Anderson
2016-06-13 23:46       ` Doug Anderson
2016-06-13 23:46       ` Doug Anderson
2016-06-14  3:02       ` Xing Zheng
2016-06-14  3:02         ` Xing Zheng
2016-06-14  3:49         ` Doug Anderson
2016-06-14  3:49           ` Doug Anderson
2016-06-14  3:49           ` Doug Anderson
2016-06-14  6:43           ` Heiko Stübner
2016-06-14  6:43             ` Heiko Stübner
2016-06-14  6:43             ` Heiko Stübner

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=575E28CE.2020808@rock-chips.com \
    --to=zhengxing@rock-chips.com \
    --cc=briannorris@chromium.org \
    --cc=dianders@chromium.org \
    --cc=elaine.zhang@rock-chips.com \
    --cc=heiko@sntech.de \
    --cc=huangtao@rock-chips.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@codeaurora.org \
    --cc=ykk@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.