[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0eda5492-c933-c977-e0db-3bc92749afda@linaro.org>
Date: Tue, 19 Jul 2022 18:23:14 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To: Christian Marangi <ansuelsmth@...il.com>,
Bjorn Andersson <bjorn.andersson@...aro.org>
Cc: Andy Gross <agross@...nel.org>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
linux-arm-msm@...r.kernel.org, linux-clk@...r.kernel.org,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v5 3/3] clk: qcom: lcc-ipq806x: convert to parent data
On 19/07/2022 15:23, Christian Marangi wrote:
> On Mon, Jul 18, 2022 at 11:42:29PM -0500, Bjorn Andersson wrote:
>> On Thu 07 Jul 19:03 CDT 2022, Christian Marangi wrote:
>>
>>> Convert lcc-ipq806x driver to parent_data API.
>>>
>>> Signed-off-by: Christian Marangi <ansuelsmth@...il.com>
>>> ---
>>> v5:
>>> - Fix the same compilation error (don't know what the hell happen
>>> to my buildroot)
>>> v4:
>>> - Fix compilation error
>>> v3:
>>> - Inline pxo pll4 parent
>>> - Change .name from pxo to pxo_board
>>>
>>> drivers/clk/qcom/lcc-ipq806x.c | 77 ++++++++++++++++++----------------
>>> 1 file changed, 42 insertions(+), 35 deletions(-)
>>>
>>> diff --git a/drivers/clk/qcom/lcc-ipq806x.c b/drivers/clk/qcom/lcc-ipq806x.c
>>> index ba90bebba597..72d6aea5be30 100644
>>> --- a/drivers/clk/qcom/lcc-ipq806x.c
>>> +++ b/drivers/clk/qcom/lcc-ipq806x.c
>>> @@ -34,7 +34,9 @@ static struct clk_pll pll4 = {
>>> .status_bit = 16,
>>> .clkr.hw.init = &(struct clk_init_data){
>>> .name = "pll4",
>>> - .parent_names = (const char *[]){ "pxo" },
>>> + .parent_data = &(const struct clk_parent_data) {
>>> + .fw_name = "pxo", .name = "pxo_board",
>>
>> This changes the behavior from looking for the globally named "pxo" to
>> look for the globally named "pxo_board", in the event that no
>> clock-names of "pxo" was found (based on the .fw_name).
>>
>> So you probably want to keep this as .fw_name = "pxo", .name = "pxo".
>>
>
> Hi,
> I will make this change but just for reference, I could be wrong by
> Dimitry pointed out that the pattern is .fw_name pxo .name pxo_board.
> The original patch had both set to pxo and it was asked to be changed.
We are generally trying to get rid of manually registered 'pxo' clock,
thus all parent_names = pxo/cxo/xo entries are converted to .fw_name =
"pxo/cxo/xo", .name = "pxo_board/cxo_board/xo_board" clocks. This has
been done previously for all converted drivers w/o any questions. May be
it's worth it mentioning pxo_board in the commit message.
>
>>> + },
>>> .num_parents = 1,
>>> .ops = &clk_pll_ops,
>>> },
>>> @@ -64,9 +66,9 @@ static const struct parent_map lcc_pxo_pll4_map[] = {
>>> { P_PLL4, 2 }
>>> };
>>>
>>> -static const char * const lcc_pxo_pll4[] = {
>>> - "pxo",
>>> - "pll4_vote",
>>> +static const struct clk_parent_data lcc_pxo_pll4[] = {
>>> + { .fw_name = "pxo", .name = "pxo" },
>>> + { .fw_name = "pll4_vote", .name = "pll4_vote" },
>>
>> This is a reference to a clock defined in this same driver, so you can
>> use { .hw = &pll4_vote.clkr.hw } to avoid the lookup all together.
>>
>
> Eh... pll4_vote is defined in gcc (for some reason) the one we have here
> is pll4.
>
> I asked if this could be fixed in some way but it was said that it's
> better to not complicate things too much.
The chain is:
pxo -> pll4 @ lcc -> pll4_vote @ gcc -> i2s clocks @ lcc.
>
>>> };
>>>
>>> static struct freq_tbl clk_tbl_aif_mi2s[] = {
>>> @@ -131,18 +133,14 @@ static struct clk_rcg mi2s_osr_src = {
>>> .enable_mask = BIT(9),
>>> .hw.init = &(struct clk_init_data){
>>> .name = "mi2s_osr_src",
>>> - .parent_names = lcc_pxo_pll4,
>>> - .num_parents = 2,
>>> + .parent_data = lcc_pxo_pll4,
>>> + .num_parents = ARRAY_SIZE(lcc_pxo_pll4),
>>> .ops = &clk_rcg_ops,
>>> .flags = CLK_SET_RATE_GATE,
>>> },
>>> },
>>> };
>>>
>>> -static const char * const lcc_mi2s_parents[] = {
>>> - "mi2s_osr_src",
>>> -};
>>> -
>>> static struct clk_branch mi2s_osr_clk = {
>>> .halt_reg = 0x50,
>>> .halt_bit = 1,
>>> @@ -152,7 +150,9 @@ static struct clk_branch mi2s_osr_clk = {
>>> .enable_mask = BIT(17),
>>> .hw.init = &(struct clk_init_data){
>>> .name = "mi2s_osr_clk",
>>> - .parent_names = lcc_mi2s_parents,
>>> + .parent_hws = (const struct clk_hw*[]){
>>> + &mi2s_osr_src.clkr.hw,
>>> + },
>>> .num_parents = 1,
>>> .ops = &clk_branch_ops,
>>> .flags = CLK_SET_RATE_PARENT,
>>> @@ -167,7 +167,9 @@ static struct clk_regmap_div mi2s_div_clk = {
>>> .clkr = {
>>> .hw.init = &(struct clk_init_data){
>>> .name = "mi2s_div_clk",
>>> - .parent_names = lcc_mi2s_parents,
>>> + .parent_hws = (const struct clk_hw*[]){
>>
>> It would be wonderful if you could keep a space between ) and { in
>> these.
>>
>
> You mean only here or in the entire patch? I assume the latter.
>
>>> + &mi2s_osr_src.clkr.hw,
>>> + },
>>> .num_parents = 1,
>>> .ops = &clk_regmap_div_ops,
>>> },
>>> @@ -183,7 +185,9 @@ static struct clk_branch mi2s_bit_div_clk = {
>>> .enable_mask = BIT(15),
>>> .hw.init = &(struct clk_init_data){
>>> .name = "mi2s_bit_div_clk",
>>> - .parent_names = (const char *[]){ "mi2s_div_clk" },
>>> + .parent_hws = (const struct clk_hw*[]){
>>> + &mi2s_div_clk.clkr.hw,
>>> + },
>>> .num_parents = 1,
>>> .ops = &clk_branch_ops,
>>> .flags = CLK_SET_RATE_PARENT,
>>> @@ -191,6 +195,10 @@ static struct clk_branch mi2s_bit_div_clk = {
>>> },
>>> };
>>>
>>> +static const struct clk_parent_data lcc_mi2s_bit_div_codec_clk[] = {
>>> + { .hw = &mi2s_bit_div_clk.clkr.hw, },
>>> + { .fw_name = "mi2s_codec_clk", .name = "mi2s_codec_clk" },
>>
>> Is mi2s_codec_clk and external clock? I don't see it documented in the
>> DT binding. And if we're introducing new clock-names, perhaps we could
>> skip the _clk suffix - because obviously it's a clock :)
>>
>> Regards,
>> Bjorn
>>
>
> I also didn't find where is mi2s_codec_clk... but yes I will change the
> fw_name with the clock with _clk stripped.
Downstream seems not to use _codec_clk, it just always uses the
bit_div_clk as the codec's bit_clk. Maybe Srini knows additional
details, as APQ8064 has more or less the same structure of clocks.
>
> Will send v6 with the other question clarified.
>
--
With best wishes
Dmitry
Powered by blists - more mailing lists