linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Yu Tu <yu.tu@amlogic.com>
To: Jerome Brunet <jbrunet@baylibre.com>, <linux-clk@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-amlogic@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>, <devicetree@vger.kernel.org>,
	Rob Herring <robh+dt@kernel.org>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Kevin Hilman <khilman@baylibre.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Subject: Re: [PATCH V3 3/6] clk: meson: S4: add support for Amlogic S4 SoC PLL clock driver
Date: Thu, 29 Sep 2022 15:07:49 +0800	[thread overview]
Message-ID: <095f1bd9-c390-196f-cccc-700d75c70cb0@amlogic.com> (raw)
In-Reply-To: <1jy1u3zfas.fsf@starbuckisacylon.baylibre.com>

Hi Jerome,
	Thank you for your reply.

On 2022/9/28 23:27, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
> 
> 
> On Wed 21 Sep 2022 at 16:40, Yu Tu <yu.tu@amlogic.com> wrote:
> 
>> Hi Jerome,
>>
>> On 2022/8/30 15:37, Yu Tu wrote:
>>> On 2022/8/30 14:44, Jerome Brunet wrote:
>>>> [ EXTERNAL EMAIL ]
>>>>
>>>>
>>>> On Tue 30 Aug 2022 at 14:13, Yu Tu <yu.tu@amlogic.com> wrote:
>>>>
>>>>> On 2022/8/29 17:48, Jerome Brunet wrote:
>>>>>> [ EXTERNAL EMAIL ]
>>>>>> On Mon 15 Aug 2022 at 21:20, Yu Tu <yu.tu@amlogic.com> wrote:
>>>>>>
>>>>>>>>>> +
>>>>>>>>>> +static struct clk_regmap s4_hdmi_pll_dco = {
>>>>>>>>>> +    .data = &(struct meson_clk_pll_data){
>>>>>>>>>> +        .en = {
>>>>>>>>>> +            .reg_off = ANACTRL_HDMIPLL_CTRL0,
>>>>>>>>>> +            .shift   = 28,
>>>>>>>>>> +            .width   = 1,
>>>>>>>>>> +        },
>>>>>>>>>> +        .m = {
>>>>>>>>>> +            .reg_off = ANACTRL_HDMIPLL_CTRL0,
>>>>>>>>>> +            .shift   = 0,
>>>>>>>>>> +            .width   = 8,
>>>>>>>>>> +        },
>>>>>>>>>> +        .n = {
>>>>>>>>>> +            .reg_off = ANACTRL_HDMIPLL_CTRL0,
>>>>>>>>>> +            .shift   = 10,
>>>>>>>>>> +            .width   = 5,
>>>>>>>>>> +        },
>>>>>>>>>> +        .frac = {
>>>>>>>>>> +            .reg_off = ANACTRL_HDMIPLL_CTRL1,
>>>>>>>>>> +            .shift   = 0,
>>>>>>>>>> +            .width   = 17,
>>>>>>>>>> +        },
>>>>>>>>>> +        .l = {
>>>>>>>>>> +            .reg_off = ANACTRL_HDMIPLL_CTRL0,
>>>>>>>>>> +            .shift   = 31,
>>>>>>>>>> +            .width   = 1,
>>>>>>>>>> +        },
>>>>>>>>>> +        .rst = {
>>>>>>>>>> +            .reg_off = ANACTRL_HDMIPLL_CTRL0,
>>>>>>>>>> +            .shift   = 29,
>>>>>>>>>> +            .width   = 1,
>>>>>>>>>> +        },
>>>>>>>>>> +    },
>>>>>>>>>> +    .hw.init = &(struct clk_init_data){
>>>>>>>>>> +        .name = "hdmi_pll_dco",
>>>>>>>>>> +        .ops = &meson_clk_pll_ro_ops,
>>>>>>>>>> +        .parent_data = (const struct clk_parent_data []) {
>>>>>>>>>> +            { .fw_name = "xtal", }
>>>>>>>>>> +        },
>>>>>>>>>> +        .num_parents = 1,
>>>>>>>>>> +        /*
>>>>>>>>>> +         * Display directly handle hdmi pll registers ATM, we need
>>>>>>>>>> +         * NOCACHE to keep our view of the clock as accurate as
>>>>>>>>>> +         * possible
>>>>>>>>>> +         */
>>>>>>>>>
>>>>>>>>> Is it really ?
>>>>>>>>>
>>>>>>>>> Given that HDMI support for the s4 is there yet, the
>>>>>>>>> addresses have changes and the region is no longer a syscon, it is
>>>>>>>>> time
>>>>>>>>> for the HDMI driver to get fixed.
>>>>>>> The HDMI PLL is configured in the Uboot phase and does not change the
>>>>>>> frequency in the kernel phase. So we use the NOCACHE flag and
>>>>>>> "ro_ops".
>>>>>> That's no reason to put NOCACHE or ro-ops
>>>>>> If you want the frequencies to be statically assinged, the correct way
>>>>>> would be through assigned-rate in DT I guess.
>>>>>
>>>>> Okay. You're right. However, when registering with OPS, HDMI PLL will be
>>>>> reset. It takes time for PLL to stabilize the output frequency, which
>>>>> will
>>>>> lead to the startup screen flashing.
>>>>>
>>>>> I would like to know how to solve this problem if not using ro_ops.
>>>>>
>>>>>>
>>>>
>>>> You can add new ops or tweak the current init function.
>>> HDMI PLL is not different from other PLLS, so I think adding OPS is
>>> weird.
>>>
>>>>
>>>> Safest would be to do the following :
>>>>    * Check if the PLLs is already on.
>>>>    * Check if the 'pll->init_regs' matches what is already set
>>>>      - if so, you can skip the reset
>>>>      - if not, you need to reset as usual
>>> static int meson_clk_pll_init(struct clk_hw *hw)
>>> {
>>>           struct clk_regmap *clk = to_clk_regmap(hw);
>>>           struct meson_clk_pll_data *pll = meson_clk_pll_data(clk);
>>>           if (pll->init_count) {
>>>                   meson_parm_write(clk->map, &pll->rst, 1);
>>>                   regmap_multi_reg_write(clk->map, pll->init_regs,
>>>                                   |      pll->init_count);
>>>                   meson_parm_write(clk->map, &pll->rst, 0);
>>>           }
>>>           return 0;
>>> }
>>> Because the init function looks like this. Therefore, HDMI PLL init_count
>>> is not given.
> 
> I don't get the remark. You've got pll->init_count right there.
> 
>>> Can I change it like this?
> 
> What change ? The function above looks a lot like  meson_clk_pll_init()
> in the actual source
> 
>>
>> I don't know if this change meets your requirements? Please give us your
>> valuable advice.
> 
> What change ?

static struct clk_regmap s4_hdmi_pll_dco = { 

         .data = &(struct meson_clk_pll_data){ 

                 .en = { 

                         .reg_off = ANACTRL_HDMIPLL_CTRL0, 

                         .shift   = 28, 

                         .width   = 1, 

                 }, 

                 .m = { 

                         .reg_off = ANACTRL_HDMIPLL_CTRL0, 

                         .shift   = 0, 

                         .width   = 8, 

                 }, 

                 .n = { 

                         .reg_off = ANACTRL_HDMIPLL_CTRL0, 

                         .shift   = 10, 

                         .width   = 5, 

                 }, 

                 .frac = { 

                         .reg_off = ANACTRL_HDMIPLL_CTRL1, 

                         .shift   = 0, 

                         .width   = 17, 

                 }, 

                 .l = { 

                         .reg_off = ANACTRL_HDMIPLL_CTRL0, 

                         .shift   = 31, 

                         .width   = 1, 

                 }, 

                 .rst = { 

                         .reg_off = ANACTRL_HDMIPLL_CTRL0, 

                         .shift   = 29, 

                         .width   = 1, 

                 }, 

                 .range = &s4_gp0_pll_mult_range, 

         }, 

         .hw.init = &(struct clk_init_data){ 

                 .name = "hdmi_pll_dco", 

                 .ops = &meson_clk_pll_ops, 

                 .parent_data = (const struct clk_parent_data []) { 

                         { .fw_name = "xtal", } 

                 }, 

                 .num_parents = 1, 

         }, 

};

This is my code right now. Because init_count and init_regs are not 
defined, HDMI PLL is not reset. In this way, the kernel will not blink 
when the Uboot starts. Then in the kernel stage, if we want to change 
the HDMI PLL frequency value, we can directly change M, N and OD. In 
fact, we will not change the HDMI PLL frequency value later.

I wonder if you accept this change?




  reply	other threads:[~2022-09-29  7:08 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-05  8:57 [PATCH V3 0/6] Add S4 SoC PLL and Peripheral clock controller Yu Tu
2022-08-05  8:57 ` [PATCH V3 1/6] dt-bindings: clock: meson: add S4 SoC PLL clock controller bindings Yu Tu
2022-08-05  9:13   ` Krzysztof Kozlowski
2022-08-05  8:57 ` [PATCH V3 2/6] arm64: dts: meson: add S4 Soc PLL clock controller in DT Yu Tu
2022-08-05  9:16   ` Krzysztof Kozlowski
2022-08-05  9:39     ` Yu Tu
2022-08-10 13:32       ` Jerome Brunet
2022-08-15  6:17         ` Yu Tu
2022-08-29  9:43           ` Jerome Brunet
2022-08-30  6:05             ` Yu Tu
2022-08-30  6:36               ` Jerome Brunet
2022-08-30  7:06                 ` Yu Tu
2022-08-05  8:57 ` [PATCH V3 3/6] clk: meson: S4: add support for Amlogic S4 SoC PLL clock driver Yu Tu
2022-08-10 13:47   ` Jerome Brunet
2022-08-15  6:34     ` Yu Tu
2022-08-15 13:20       ` Yu Tu
2022-08-29  9:48         ` Jerome Brunet
2022-08-30  6:13           ` Yu Tu
2022-08-30  6:44             ` Jerome Brunet
2022-08-30  7:37               ` Yu Tu
2022-09-21  8:40                 ` Yu Tu
2022-09-28 15:27                   ` Jerome Brunet
2022-09-29  7:07                     ` Yu Tu [this message]
2022-10-22 12:22                       ` Jerome Brunet
2022-10-24 11:33                         ` Yu Tu
2022-08-29  9:46       ` Jerome Brunet
2022-08-30  6:08         ` Yu Tu
2022-08-05  8:57 ` [PATCH V3 4/6] dt-bindings: clk: meson: add S4 SoC peripheral clock controller bindings Yu Tu
2022-08-05  9:15   ` Krzysztof Kozlowski
2022-08-05  9:33     ` Yu Tu
2022-08-08  6:16       ` Krzysztof Kozlowski
2022-08-08 10:00         ` Yu Tu
2022-08-05  8:57 ` [PATCH V3 5/6] arm64: dts: meson: add S4 Soc Peripheral clock controller in DT Yu Tu
2022-08-05  9:16   ` Krzysztof Kozlowski
2022-08-05  9:36     ` Yu Tu
2022-08-08  6:17       ` Krzysztof Kozlowski
2022-08-08 10:02         ` Yu Tu
2022-08-05  8:57 ` [PATCH V3 6/6] clk: meson: s4: add s4 SoC peripheral clock controller driver Yu Tu
2022-08-10 13:57   ` Jerome Brunet
2022-08-16 12:00     ` Yu Tu
2022-08-29 12:19       ` Jerome Brunet
2022-08-30  8:20         ` Yu Tu
2022-09-21  9:01           ` Yu Tu
2022-09-28 15:35             ` Jerome Brunet

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=095f1bd9-c390-196f-cccc-700d75c70cb0@amlogic.com \
    --to=yu.tu@amlogic.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jbrunet@baylibre.com \
    --cc=khilman@baylibre.com \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=linux-amlogic@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.blumenstingl@googlemail.com \
    --cc=mturquette@baylibre.com \
    --cc=narmstrong@baylibre.com \
    --cc=robh+dt@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).