mirror of https://lore.kernel.org/linux-amlogic/
 help / color / mirror / Atom feed
From: Jerome Brunet <jbrunet@baylibre.com>
To: Chuan Liu <chuan.liu@amlogic.com>,
	Xianwei Zhao <xianwei.zhao@amlogic.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Neil Armstrong <neil.armstrong@linaro.org>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@kernel.org>, Rob Herring <robh+dt@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Kevin Hilman <khilman@baylibre.com>,
	Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Subject: Re: [PATCH V2 4/4] clk: meson: c3: add c3 clock peripherals controller driver
Date: Tue, 17 Oct 2023 17:21:36 +0200	[thread overview]
Message-ID: <1jy1g1tg5e.fsf@starbuckisacylon.baylibre.com> (raw)
In-Reply-To: <ce3b4fa4-5823-4784-b41f-397ad07df3c6@amlogic.com>


On Tue 17 Oct 2023 at 22:59, Chuan Liu <chuan.liu@amlogic.com> wrote:

>>>>> +
>>>>> +static struct clk_regmap saradc = {
>>>>> +     .data = &(struct clk_regmap_gate_data){
>>>>> +             .offset = SAR_CLK_CTRL0,
>>>>> +             .bit_idx = 8,
>>>>> +     },
>>>>> +     .hw.init = &(struct clk_init_data) {
>>>>> +             .name = "saradc",
>>>>> +             .ops = &clk_regmap_gate_ops,
>>>>> +             .parent_hws = (const struct clk_hw *[]) {
>>>>> +                     &saradc_div.hw
>>>>> +             },
>>>>> +             .num_parents = 1,
>>>>> +             .flags = CLK_SET_RATE_PARENT,
>>>>> +     },
>>>>> +};
>>>>> +
>>>>> +static u32 pwm_parent_table[] = { 0, 2, 3 };
>>>> What's pwm parent 1, why can't it be used ?
>>> This 1 corresponds to gp1 pll, which is currently dedicated to emmc.
>> Given that gp1 does not exist in your PLL controller, it is going to be
>> hard to dedicate it to eMMC ;)
> Because the register corresponding to gp1_pll has permission restrictions,
> the corresponding register is read-only in the kernel (can read and write
> in the bl31 environment), here first mask the source to solve the
> permission problem before opening

The PWM sel clock does not have CLK_SET_RATE_PARENT so it is not going to
request rate change for any parent clock, it will just what is available.

Your reason does not apply here.

Also, if gp1 registers are read-only from the kernel, you can still
expose it with RO ops, possibly with CLK_GET_RATE_NOCACHE if the bl31
may change at runtime.

>>
>>>>> +
>>>>> +static const struct clk_parent_data pwm_parent_data[] = {
>>>>> +     { .fw_name = "xtal" },
>>>>> +     { .fw_name = "fclk_div4" },
>>>>> +     { .fw_name = "fclk_div3" }
>>>>> +};
>>>>> +
>>>>> +static struct clk_regmap pwm_a_sel = {
>>>>> +     .data = &(struct clk_regmap_mux_data){
>>>>> +             .offset = PWM_CLK_AB_CTRL,
>>>>> +             .mask = 0x3,
>>>>> +             .shift = 9,
>>>>> +             .table = pwm_parent_table,
>>>>> +     },
>>>>> +     .hw.init = &(struct clk_init_data){
>>>>> +             .name = "pwm_a_sel",
>>>>> +             .ops = &clk_regmap_mux_ops,
>>>>> +             .parent_data = pwm_parent_data,
>>>>> +             .num_parents = ARRAY_SIZE(pwm_parent_data),
>>>>> +     },
>>>>> +};
>>>>> +
>>>>> +static struct clk_regmap pwm_a_div = {
>>>>> +     .data = &(struct clk_regmap_div_data){
>>>>> +             .offset = PWM_CLK_AB_CTRL,
>>>>> +             .shift = 0,
>>>>> +             .width = 8,
>>>>> +     },
>>>>> +     .hw.init = &(struct clk_init_data){
>>>>> +             .name = "pwm_a_div",
>>>>> +             .ops = &clk_regmap_divider_ops,
>>>>> +             .parent_hws = (const struct clk_hw *[]) {
>>>>> +                     &pwm_a_sel.hw
>>>>> +             },
>>>>> +             .num_parents = 1,
>>>>> +             .flags = CLK_SET_RATE_PARENT,
>>>>> +     },
>>>>> +};

[...]

>>>>> +
>>>>> +static struct clk_regmap spifc = {
>>>>> +     .data = &(struct clk_regmap_gate_data){
>>>>> +             .offset = SPIFC_CLK_CTRL,
>>>>> +             .bit_idx = 8,
>>>>> +     },
>>>>> +     .hw.init = &(struct clk_init_data) {
>>>>> +             .name = "spifc",
>>>>> +             .ops = &clk_regmap_gate_ops,
>>>>> +             .parent_hws = (const struct clk_hw *[]) {
>>>>> +                     &spifc_div.hw
>>>>> +             },
>>>>> +             .num_parents = 1,
>>>>> +             .flags = CLK_SET_RATE_PARENT,
>>>>> +     },
>>>>> +};
>>>>> +
>>>>> +static u32 emmc_parent_table[] = { 0, 1, 2, 3, 4, 5, 7 };
>>>> What's 6 ? why can't it be used ?
>>>>
>> No answer ?
> 6 - gp1_pll,The permission reason is that the patch is submitted to open
> after the solution is resolved
>>
>>>>> +
>>>>> +static const struct clk_parent_data emmc_parent_data[] = {
>>>>> +     { .fw_name = "xtal" },
>>>>> +     { .fw_name = "fclk_div2" },
>>>>> +     { .fw_name = "fclk_div3" },
>>>>> +     { .fw_name = "hifi_pll" },
>>>>> +     { .fw_name = "fclk_div2p5" },
>>>>> +     { .fw_name = "fclk_div4" },
>>>>> +     { .fw_name = "gp0_pll" }
>>>>> +};
>> Not seeing gp1 there ? why would you need to dedicate an GP pll for MMC
>> ? Maybe I missing something but it seems to me the usual MMC rate are
>> acheivable with the fclks, especially 2p5.
> Permission reason

use RO ops.

>>
>>>>> +
>>>>> +static struct clk_regmap sd_emmc_a_sel = {
>>>>> +     .data = &(struct clk_regmap_mux_data){
>>>>> +             .offset = SD_EMMC_CLK_CTRL,
>>>>> +             .mask = 0x7,
>>>>> +             .shift = 9,
>>>>> +             .table = emmc_parent_table,
>>>>> +     },
>>>>> +     .hw.init = &(struct clk_init_data){
>>>>> +             .name = "sd_emmc_a_sel",
>>>>> +             .ops = &clk_regmap_mux_ops,
>>>>> +             .parent_data = emmc_parent_data,
>>>>> +             .num_parents = ARRAY_SIZE(emmc_parent_data),
>>>>> +     },
>>>>> +};
>>>>> +
>>>>> +static struct clk_regmap sd_emmc_a_div = {
>>>>> +     .data = &(struct clk_regmap_div_data){
>>>>> +             .offset = SD_EMMC_CLK_CTRL,
>>>>> +             .shift = 0,
>>>>> +             .width = 7,
>>>>> +     },
>>>>> +     .hw.init = &(struct clk_init_data){
>>>>> +             .name = "sd_emmc_a_div",
>>>>> +             .ops = &clk_regmap_divider_ops,
>>>>> +             .parent_hws = (const struct clk_hw *[]) {
>>>>> +                     &sd_emmc_a_sel.hw
>>>>> +             },
>>>>> +             .num_parents = 1,
>>>>> +             .flags = CLK_SET_RATE_PARENT,
>>>>> +     },
>>>>> +};
>>>>> +
>>>>> +static struct clk_regmap sd_emmc_a = {
>>>>> +     .data = &(struct clk_regmap_gate_data){
>>>>> +             .offset = SD_EMMC_CLK_CTRL,
>>>>> +             .bit_idx = 7,
>>>>> +     },
>>>>> +     .hw.init = &(struct clk_init_data) {
>>>>> +             .name = "sd_emmc_a",
>>>>> +             .ops = &clk_regmap_gate_ops,
>>>>> +             .parent_hws = (const struct clk_hw *[]) {
>>>>> +                     &sd_emmc_a_div.hw
>>>>> +             },
>>>>> +             .num_parents = 1,
>>>>> +             .flags = CLK_SET_RATE_PARENT,
>>>>> +     },
>>>>> +};

[...]

>>>>> +static u32 csi_phy_parent_table[] = { 0, 1, 2, 3, 4, 5, 7 };
>>>> Same here and all following instance
>>>>
>>> This 1 corresponds to gp1 pll, which is currently dedicated to emmc.
>> No it is not. Again mainline drivers are slightly different from AML
>> fork you might be used to. No PLL is dedicated to the mmc driver.
>> Unless you can make a strong case for it, I don't think it will happen
>> in the near future.
> For performance considerations, emmc needs to use a higher frequency clock
> source (currently our emmc driver has been adapted to 1152M), so we
> internally allocate gp1_pll to emmc.As mentioned above, the gp1_pll
> register permission problem is masked here first🙂

Your GP1 is controlled by the SCP FW and RO for the kernel. That's all from
the clock controller POV.

No reason to remove it here and elsewhere AFAICT

>>>>> +
>>>>> +static const struct clk_parent_data csi_phy_parent_data[] = {
>>>>> +     { .fw_name = "fclk_div2p5" },
>>>>> +     { .fw_name = "fclk_div3" },
>>>>> +     { .fw_name = "fclk_div4" },
>>>>> +     { .fw_name = "fclk_div5" },
>>>>> +     { .fw_name = "gp0_pll" },
>>>>> +     { .fw_name = "hifi_pll" },
>>>>> +     { .fw_name = "xtal" }
>>>>> +};
>>>>> +
>>>>> +static struct clk_regmap csi_phy0_sel = {
>>>>> +     .data = &(struct clk_regmap_mux_data){
>>>>> +             .offset = ISP0_CLK_CTRL,
>>>>> +             .mask = 0x7,
>>>>> +             .shift = 25,
>>>>> +             .table = csi_phy_parent_table,
>>>>> +     },
>>>>> +     .hw.init = &(struct clk_init_data){
>>>>> +             .name = "csi_phy0_sel",
>>>>> +             .ops = &clk_regmap_mux_ops,
>>>>> +             .parent_data = csi_phy_parent_data,
>>>>> +             .num_parents = ARRAY_SIZE(csi_phy_parent_data),
>>>>> +     },
>>>>> +};
>>>>> +
>>>>> +static struct clk_regmap csi_phy0_div = {
>>>>> +     .data = &(struct clk_regmap_div_data){
>>>>> +             .offset = ISP0_CLK_CTRL,
>>>>> +             .shift = 16,
>>>>> +             .width = 7,
>>>>> +     },
>>>>> +     .hw.init = &(struct clk_init_data){
>>>>> +             .name = "csi_phy0_div",
>>>>> +             .ops = &clk_regmap_divider_ops,
>>>>> +             .parent_hws = (const struct clk_hw *[]) {
>>>>> +                     &csi_phy0_sel.hw
>>>>> +             },
>>>>> +             .num_parents = 1,
>>>>> +             .flags = CLK_SET_RATE_PARENT,
>>>>> +     },
>>>>> +};
>>>>> +
>>>>> +static struct clk_regmap csi_phy0 = {
>>>>> +     .data = &(struct clk_regmap_gate_data){
>>>>> +             .offset = ISP0_CLK_CTRL,
>>>>> +             .bit_idx = 24,
>>>>> +     },
>>>>> +     .hw.init = &(struct clk_init_data) {
>>>>> +             .name = "csi_phy0",
>>>>> +             .ops = &clk_regmap_gate_ops,
>>>>> +             .parent_hws = (const struct clk_hw *[]) {
>>>>> +                     &csi_phy0_div.hw
>>>>> +             },
>>>>> +             .num_parents = 1,
>>>>> +             .flags = CLK_SET_RATE_PARENT,
>>>>> +     },
>>>>> +};

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

      reply	other threads:[~2023-10-17 15:37 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-10  6:29 [PATCH V2 0/4] Add C3 SoC PLLs and Peripheral clock Xianwei Zhao
2023-10-10  6:29 ` [PATCH V2 1/4] dt-bindings: clock: add Amlogic C3 PLL clock controller bindings Xianwei Zhao
     [not found]   ` <20231010132151.GA557938-robh@kernel.org>
2023-10-11  2:50     ` Xianwei Zhao
2023-10-13  7:35       ` Jerome Brunet
2023-10-16  6:41         ` Xianwei Zhao
2023-10-10  6:29 ` [PATCH V2 2/4] dt-bindings: clock: add Amlogic C3 peripherals " Xianwei Zhao
     [not found]   ` <20231010132520.GB557938-robh@kernel.org>
2023-10-11  2:54     ` Xianwei Zhao
2023-10-10  6:29 ` [PATCH V2 3/4] clk: meson: c3: add support for the C3 SoC PLL clock Xianwei Zhao
2023-10-13  7:49   ` Jerome Brunet
2023-10-17  6:15     ` Xianwei Zhao
2023-10-17 13:06       ` Jerome Brunet
2023-10-17 14:39         ` Chuan Liu
2023-10-17 14:42           ` Jerome Brunet
2023-10-10  6:29 ` [PATCH V2 4/4] clk: meson: c3: add c3 clock peripherals controller driver Xianwei Zhao
2023-10-12 23:51   ` Stephen Boyd
2023-10-13  7:38     ` Jerome Brunet
2023-10-13 22:01       ` Stephen Boyd
2023-10-16  6:49         ` Xianwei Zhao
2023-10-13  8:46   ` Jerome Brunet
2023-10-17  3:25     ` Xianwei Zhao
2023-10-17 13:28       ` Jerome Brunet
2023-10-17 14:59         ` Chuan Liu
2023-10-17 15:21           ` Jerome Brunet [this message]

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=1jy1g1tg5e.fsf@starbuckisacylon.baylibre.com \
    --to=jbrunet@baylibre.com \
    --cc=chuan.liu@amlogic.com \
    --cc=devicetree@vger.kernel.org \
    --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=neil.armstrong@linaro.org \
    --cc=robh+dt@kernel.org \
    --cc=sboyd@kernel.org \
    --cc=xianwei.zhao@amlogic.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®