* [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-08-13 1:15 ` Peng Fan
0 siblings, 0 replies; 48+ messages in thread
From: Peng Fan @ 2018-08-13 1:15 UTC (permalink / raw)
To: linux-arm-kernel
Hi Anson,
> > > -----Original Message-----
> > > From: Anson Huang
> > > Sent: 2018?8?8? 12:39
> > > To: shawnguo at kernel.org; s.hauer at pengutronix.de;
> > > kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > > mturquette at baylibre.com; sboyd at kernel.org;
> > > linux-arm-kernel at lists.infradead.org;
> > > linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org
> > > Cc: dl-linux-imx <linux-imx@nxp.com>
> > > Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> > >
> > > Clock framework will enable those clocks registered with
> > > CLK_IS_CRITICAL flag, so no need to have clks_init_on array during
> > > clock
> > initialization now.
> >
> > Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> > or "init-on-arrary=<xxx>"
> > and enable those clocks?
>
> Parsing the clocks arrays from dtb is another way of enabling critical clocks, but
> for current i.MX6/7 platforms, we implement it in same way as most of other
> SoCs, currently I did NOT see any necessity of putting them in dtb, just adding
> flag during clock registering is more simple, if there is any special requirement
> for different clocks set to be enabled, then we can add support to enable the
> method of parsing critical-clocks from dtb. Just my two cents.
Thinking about OP-TEE want to use one device, but it's clocks are registered
by Linux, because there is no module in Linux side use it, it will shutdown the clock,
which cause OP-TEE could not access the device.
Then people have to modify clk code to add CLK_IS_CRITICAL flag to make sure
the clocks are not shutdown by Linux.
However adding a new property in clk node and let driver code parse the dts,
there is no need to modify clk driver code when OP-TEE needs another device clock.
Regards,
Peng.
>
> Anson.
>
> >
> > Regards,
> > Peng.
> >
> > >
> > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > > ---
> > > drivers/clk/imx/clk-imx7d.c | 27 ++++++++-------------------
> > > drivers/clk/imx/clk.h | 7 +++++++
> > > 2 files changed, 15 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/drivers/clk/imx/clk-imx7d.c
> > > b/drivers/clk/imx/clk-imx7d.c index c4518d7..076460b 100644
> > > --- a/drivers/clk/imx/clk-imx7d.c
> > > +++ b/drivers/clk/imx/clk-imx7d.c
> > > @@ -379,13 +379,6 @@ static const char *pll_enet_bypass_sel[] = {
> > > "pll_enet_main", "pll_enet_main_src static const char
> > > *pll_audio_bypass_sel[] = { "pll_audio_main", "pll_audio_main_src",
> > > }; static const char *pll_video_bypass_sel[] = { "pll_video_main",
> > > "pll_video_main_src", };
> > >
> > > -static int const clks_init_on[] __initconst = {
> > > - IMX7D_ARM_A7_ROOT_CLK, IMX7D_MAIN_AXI_ROOT_CLK,
> > > - IMX7D_PLL_SYS_MAIN_480M_CLK, IMX7D_IPG_ROOT_CLK,
> > > - IMX7D_DRAM_PHYM_ROOT_CLK, IMX7D_DRAM_ROOT_CLK,
> > > - IMX7D_DRAM_PHYM_ALT_ROOT_CLK, IMX7D_DRAM_ALT_ROOT_CLK,
> > > -};
> > > -
> > > static struct clk_onecell_data clk_data;
> > >
> > > static struct clk ** const uart_clks[] __initconst = { @@ -403,7
> > > +396,6 @@ static void __init imx7d_clocks_init(struct device_node
> > *ccm_node) {
> > > struct device_node *np;
> > > void __iomem *base;
> > > - int i;
> > >
> > > clks[IMX7D_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
> > > clks[IMX7D_OSC_24M_CLK] = of_clk_get_by_name(ccm_node, "osc");
> > @@
> > > -466,7 +458,7 @@ static void __init imx7d_clocks_init(struct
> > > device_node
> > > *ccm_node)
> > > clks[IMX7D_PLL_SYS_MAIN_120M] =
> > > imx_clk_fixed_factor("pll_sys_main_120m", "pll_sys_main_clk", 1, 4);
> > > clks[IMX7D_PLL_DRAM_MAIN_533M] =
> > > imx_clk_fixed_factor("pll_dram_533m", "pll_dram_main_clk", 1, 2);
> > >
> > > - clks[IMX7D_PLL_SYS_MAIN_480M_CLK] =
> > > imx_clk_gate_dis("pll_sys_main_480m_clk", "pll_sys_main_480m", base
> > > + 0xb0, 4);
> > > + clks[IMX7D_PLL_SYS_MAIN_480M_CLK] =
> > > +imx_clk_gate_dis_flags("pll_sys_main_480m_clk",
> > > +"pll_sys_main_480m", base + 0xb0, 4, CLK_IS_CRITICAL);
> > > clks[IMX7D_PLL_SYS_MAIN_240M_CLK] =
> > > imx_clk_gate_dis("pll_sys_main_240m_clk", "pll_sys_main_240m", base
> > > + 0xb0, 5);
> > > clks[IMX7D_PLL_SYS_MAIN_120M_CLK] =
> > > imx_clk_gate_dis("pll_sys_main_120m_clk", "pll_sys_main_120m", base
> > > + 0xb0, 6);
> > > clks[IMX7D_PLL_DRAM_MAIN_533M_CLK] =
> > > imx_clk_gate("pll_dram_533m_clk", "pll_dram_533m", base + 0x70, 12);
> > > @@
> > > -719,7 +711,7 @@ static void __init imx7d_clocks_init(struct
> > > device_node
> > > *ccm_node)
> > > clks[IMX7D_ENET_AXI_ROOT_DIV] =
> > > imx_clk_divider2("enet_axi_post_div", "enet_axi_pre_div", base +
> > > 0x8900, 0,
> > 6);
> > > clks[IMX7D_NAND_USDHC_BUS_ROOT_CLK] =
> > > imx_clk_divider2("nand_usdhc_root_clk", "nand_usdhc_pre_div", base +
> > > 0x8980, 0, 6);
> > > clks[IMX7D_AHB_CHANNEL_ROOT_DIV] =
> > > imx_clk_divider2("ahb_root_clk", "ahb_pre_div", base + 0x9000, 0, 6);
> > > - clks[IMX7D_IPG_ROOT_CLK] = imx_clk_divider2("ipg_root_clk",
> > > "ahb_root_clk", base + 0x9080, 0, 2);
> > > + clks[IMX7D_IPG_ROOT_CLK] = imx_clk_divider_flags("ipg_root_clk",
> > > +"ahb_root_clk", base + 0x9080, 0, 2, CLK_IS_CRITICAL |
> > > +CLK_OPS_PARENT_ENABLE | CLK_SET_RATE_PARENT);
> > > clks[IMX7D_DRAM_ROOT_DIV] = imx_clk_divider2("dram_post_div",
> > > "dram_cg", base + 0x9880, 0, 3);
> > > clks[IMX7D_DRAM_PHYM_ALT_ROOT_DIV] =
> > > imx_clk_divider2("dram_phym_alt_post_div", "dram_phym_alt_pre_div",
> > > base
> > > + 0xa000, 0, 3);
> > > clks[IMX7D_DRAM_ALT_ROOT_DIV] =
> > > imx_clk_divider2("dram_alt_post_div", "dram_alt_pre_div", base +
> > > 0xa080, 0, 3); @@ -783,17 +775,17 @@ static void __init
> > > imx7d_clocks_init(struct device_node *ccm_node)
> > > clks[IMX7D_CLKO1_ROOT_DIV] = imx_clk_divider2("clko1_post_div",
> > > "clko1_pre_div", base + 0xbd80, 0, 6);
> > > clks[IMX7D_CLKO2_ROOT_DIV] = imx_clk_divider2("clko2_post_div",
> > > "clko2_pre_div", base + 0xbe00, 0, 6);
> > >
> > > - clks[IMX7D_ARM_A7_ROOT_CLK] = imx_clk_gate4("arm_a7_root_clk",
> > > "arm_a7_div", base + 0x4000, 0);
> > > + clks[IMX7D_ARM_A7_ROOT_CLK] =
> > > imx_clk_gate2_flags("arm_a7_root_clk",
> > > +"arm_a7_div", base + 0x4000, 0, CLK_IS_CRITICAL |
> > > +CLK_OPS_PARENT_ENABLE);
> > > clks[IMX7D_ARM_M4_ROOT_CLK] =
> imx_clk_gate4("arm_m4_root_clk",
> > > "arm_m4_div", base + 0x4010, 0);
> > > - clks[IMX7D_MAIN_AXI_ROOT_CLK] = imx_clk_gate4("main_axi_root_clk",
> > > "axi_post_div", base + 0x4040, 0);
> > > + clks[IMX7D_MAIN_AXI_ROOT_CLK] =
> > > +imx_clk_gate2_flags("main_axi_root_clk", "axi_post_div", base +
> > > +0x4040, 0, CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE);
> > > clks[IMX7D_DISP_AXI_ROOT_CLK] =
> imx_clk_gate4("disp_axi_root_clk",
> > > "disp_axi_post_div", base + 0x4050, 0);
> > > clks[IMX7D_ENET_AXI_ROOT_CLK] =
> imx_clk_gate4("enet_axi_root_clk",
> > > "enet_axi_post_div", base + 0x4060, 0);
> > > clks[IMX7D_OCRAM_CLK] = imx_clk_gate4("ocram_clk",
> > > "main_axi_root_clk", base + 0x4110, 0);
> > > clks[IMX7D_OCRAM_S_CLK] = imx_clk_gate4("ocram_s_clk",
> > > "ahb_root_clk", base + 0x4120, 0);
> > > - clks[IMX7D_DRAM_ROOT_CLK] = imx_clk_gate4("dram_root_clk",
> > > "dram_post_div", base + 0x4130, 0);
> > > - clks[IMX7D_DRAM_PHYM_ROOT_CLK] =
> > > imx_clk_gate4("dram_phym_root_clk", "dram_phym_cg", base + 0x4130,
> 0);
> > > - clks[IMX7D_DRAM_PHYM_ALT_ROOT_CLK] =
> > > imx_clk_gate4("dram_phym_alt_root_clk", "dram_phym_alt_post_div",
> > > base
> > > + 0x4130, 0);
> > > - clks[IMX7D_DRAM_ALT_ROOT_CLK] =
> > imx_clk_gate4("dram_alt_root_clk",
> > > "dram_alt_post_div", base + 0x4130, 0);
> > > + clks[IMX7D_DRAM_ROOT_CLK] =
> imx_clk_gate2_flags("dram_root_clk",
> > > "dram_post_div", base + 0x4130, 0, CLK_IS_CRITICAL |
> > > CLK_OPS_PARENT_ENABLE);
> > > + clks[IMX7D_DRAM_PHYM_ROOT_CLK] =
> > > imx_clk_gate2_flags("dram_phym_root_clk", "dram_phym_cg", base +
> > > 0x4130, 0, CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE);
> > > + clks[IMX7D_DRAM_PHYM_ALT_ROOT_CLK] =
> > > imx_clk_gate2_flags("dram_phym_alt_root_clk",
> > > "dram_phym_alt_post_div", base + 0x4130, 0, CLK_IS_CRITICAL |
> > > CLK_OPS_PARENT_ENABLE);
> > > + clks[IMX7D_DRAM_ALT_ROOT_CLK] =
> > > +imx_clk_gate2_flags("dram_alt_root_clk", "dram_alt_post_div", base
> > > ++ 0x4130, 0, CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE);
> > > clks[IMX7D_OCOTP_CLK] = imx_clk_gate4("ocotp_clk",
> "ipg_root_clk",
> > > base + 0x4230, 0);
> > > clks[IMX7D_SNVS_CLK] = imx_clk_gate4("snvs_clk", "ipg_root_clk",
> > > base + 0x4250, 0);
> > > clks[IMX7D_MU_ROOT_CLK] = imx_clk_gate4("mu_root_clk",
> > > "ipg_root_clk", base + 0x4270, 0); @@ -882,9 +874,6 @@ static void
> > > __init imx7d_clocks_init(struct device_node *ccm_node)
> > > clk_data.clk_num = ARRAY_SIZE(clks);
> > > of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
> > >
> > > - for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
> > > - clk_prepare_enable(clks[clks_init_on[i]]);
> > > -
> > > clk_set_parent(clks[IMX7D_PLL_ARM_MAIN_BYPASS],
> > > clks[IMX7D_PLL_ARM_MAIN]);
> > > clk_set_parent(clks[IMX7D_PLL_DRAM_MAIN_BYPASS],
> > > clks[IMX7D_PLL_DRAM_MAIN]);
> > > clk_set_parent(clks[IMX7D_PLL_SYS_MAIN_BYPASS],
> > > clks[IMX7D_PLL_SYS_MAIN]); diff --git a/drivers/clk/imx/clk.h
> > > b/drivers/clk/imx/clk.h index 8076ec0..5895e223 100644
> > > --- a/drivers/clk/imx/clk.h
> > > +++ b/drivers/clk/imx/clk.h
> > > @@ -137,6 +137,13 @@ static inline struct clk
> > > *imx_clk_gate_dis(const char *name, const char *parent,
> > > shift, CLK_GATE_SET_TO_DISABLE, &imx_ccm_lock); }
> > >
> > > +static inline struct clk *imx_clk_gate_dis_flags(const char *name,
> > > +const char
> > > *parent,
> > > + void __iomem *reg, u8 shift, unsigned long flags) {
> > > + return clk_register_gate(NULL, name, parent, flags |
> > > CLK_SET_RATE_PARENT, reg,
> > > + shift, CLK_GATE_SET_TO_DISABLE, &imx_ccm_lock); }
> > > +
> > > static inline struct clk *imx_clk_gate2(const char *name, const
> > > char
> > *parent,
> > > void __iomem *reg, u8 shift)
> > > {
> > > --
> > > 2.7.4
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-08-13 1:15 ` Peng Fan
0 siblings, 0 replies; 48+ messages in thread
From: Peng Fan @ 2018-08-13 1:15 UTC (permalink / raw)
To: Anson Huang, shawnguo, s.hauer, kernel, Fabio Estevam,
mturquette, sboyd, linux-arm-kernel, linux-clk, linux-kernel,
Rob Herring
Cc: dl-linux-imx
SGkgQW5zb24sDQoNCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBGcm9t
OiBBbnNvbiBIdWFuZw0KPiA+ID4gU2VudDogMjAxOMTqONTCOMjVIDEyOjM5DQo+ID4gPiBUbzog
c2hhd25ndW9Aa2VybmVsLm9yZzsgcy5oYXVlckBwZW5ndXRyb25peC5kZTsNCj4gPiA+IGtlcm5l
bEBwZW5ndXRyb25peC5kZTsgRmFiaW8gRXN0ZXZhbSA8ZmFiaW8uZXN0ZXZhbUBueHAuY29tPjsN
Cj4gPiA+IG10dXJxdWV0dGVAYmF5bGlicmUuY29tOyBzYm95ZEBrZXJuZWwub3JnOw0KPiA+ID4g
bGludXgtYXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOw0KPiA+ID4gbGludXgtY2xrQHZn
ZXIua2VybmVsLm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZw0KPiA+ID4gQ2M6IGRs
LWxpbnV4LWlteCA8bGludXgtaW14QG54cC5jb20+DQo+ID4gPiBTdWJqZWN0OiBbUEFUQ0ggMi8y
XSBjbGs6IGlteDogaW14N2Q6IHJlbW92ZSBjbGtzX2luaXRfb24gYXJyYXkNCj4gPiA+DQo+ID4g
PiBDbG9jayBmcmFtZXdvcmsgd2lsbCBlbmFibGUgdGhvc2UgY2xvY2tzIHJlZ2lzdGVyZWQgd2l0
aA0KPiA+ID4gQ0xLX0lTX0NSSVRJQ0FMIGZsYWcsIHNvIG5vIG5lZWQgdG8gaGF2ZSBjbGtzX2lu
aXRfb24gYXJyYXkgZHVyaW5nDQo+ID4gPiBjbG9jaw0KPiA+IGluaXRpYWxpemF0aW9uIG5vdy4N
Cj4gPg0KPiA+IFdpbGwgaXQgYmUgbW9yZSBmbGV4aWJsZSB0byBwYXJzZSBkdHMgc2F5aW5nICJj
cml0aWNhbC1jbG9ja3MgPSA8eHh4PiINCj4gPiBvciAiaW5pdC1vbi1hcnJhcnk9PHh4eD4iDQo+
ID4gYW5kIGVuYWJsZSB0aG9zZSBjbG9ja3M/DQo+IA0KPiBQYXJzaW5nIHRoZSBjbG9ja3MgYXJy
YXlzIGZyb20gZHRiIGlzIGFub3RoZXIgd2F5IG9mIGVuYWJsaW5nIGNyaXRpY2FsIGNsb2Nrcywg
YnV0DQo+IGZvciBjdXJyZW50IGkuTVg2LzcgcGxhdGZvcm1zLCB3ZSBpbXBsZW1lbnQgaXQgaW4g
c2FtZSB3YXkgYXMgbW9zdCBvZiBvdGhlcg0KPiBTb0NzLCBjdXJyZW50bHkgSSBkaWQgTk9UIHNl
ZSBhbnkgbmVjZXNzaXR5IG9mIHB1dHRpbmcgdGhlbSBpbiBkdGIsIGp1c3QgYWRkaW5nDQo+IGZs
YWcgZHVyaW5nIGNsb2NrIHJlZ2lzdGVyaW5nIGlzIG1vcmUgc2ltcGxlLCBpZiB0aGVyZSBpcyBh
bnkgc3BlY2lhbCByZXF1aXJlbWVudA0KPiBmb3IgZGlmZmVyZW50IGNsb2NrcyBzZXQgdG8gYmUg
ZW5hYmxlZCwgdGhlbiB3ZSBjYW4gYWRkIHN1cHBvcnQgdG8gZW5hYmxlIHRoZQ0KPiBtZXRob2Qg
b2YgcGFyc2luZyBjcml0aWNhbC1jbG9ja3MgZnJvbSBkdGIuIEp1c3QgbXkgdHdvIGNlbnRzLg0K
DQpUaGlua2luZyBhYm91dCBPUC1URUUgd2FudCB0byB1c2Ugb25lIGRldmljZSwgYnV0IGl0J3Mg
Y2xvY2tzIGFyZSByZWdpc3RlcmVkDQpieSBMaW51eCwgYmVjYXVzZSB0aGVyZSBpcyBubyBtb2R1
bGUgaW4gTGludXggc2lkZSB1c2UgaXQsIGl0IHdpbGwgc2h1dGRvd24gdGhlIGNsb2NrLA0Kd2hp
Y2ggY2F1c2UgT1AtVEVFIGNvdWxkIG5vdCBhY2Nlc3MgdGhlIGRldmljZS4NCg0KVGhlbiBwZW9w
bGUgaGF2ZSB0byBtb2RpZnkgY2xrIGNvZGUgdG8gYWRkIENMS19JU19DUklUSUNBTCBmbGFnIHRv
IG1ha2Ugc3VyZQ0KdGhlIGNsb2NrcyBhcmUgbm90IHNodXRkb3duIGJ5IExpbnV4Lg0KDQpIb3dl
dmVyIGFkZGluZyBhIG5ldyBwcm9wZXJ0eSBpbiBjbGsgbm9kZSBhbmQgbGV0IGRyaXZlciBjb2Rl
IHBhcnNlIHRoZSBkdHMsDQp0aGVyZSBpcyBubyBuZWVkIHRvIG1vZGlmeSBjbGsgZHJpdmVyIGNv
ZGUgd2hlbiBPUC1URUUgbmVlZHMgYW5vdGhlciBkZXZpY2UgY2xvY2suDQoNClJlZ2FyZHMsDQpQ
ZW5nLg0KDQo+IA0KPiBBbnNvbi4NCj4gDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IFBlbmcuDQo+
ID4NCj4gPiA+DQo+ID4gPiBTaWduZWQtb2ZmLWJ5OiBBbnNvbiBIdWFuZyA8QW5zb24uSHVhbmdA
bnhwLmNvbT4NCj4gPiA+IC0tLQ0KPiA+ID4gIGRyaXZlcnMvY2xrL2lteC9jbGstaW14N2QuYyB8
IDI3ICsrKysrKysrLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ID4gIGRyaXZlcnMvY2xrL2lteC9j
bGsuaCAgICAgICB8ICA3ICsrKysrKysNCj4gPiA+ICAyIGZpbGVzIGNoYW5nZWQsIDE1IGluc2Vy
dGlvbnMoKyksIDE5IGRlbGV0aW9ucygtKQ0KPiA+ID4NCj4gPiA+IGRpZmYgLS1naXQgYS9kcml2
ZXJzL2Nsay9pbXgvY2xrLWlteDdkLmMNCj4gPiA+IGIvZHJpdmVycy9jbGsvaW14L2Nsay1pbXg3
ZC5jIGluZGV4IGM0NTE4ZDcuLjA3NjQ2MGIgMTAwNjQ0DQo+ID4gPiAtLS0gYS9kcml2ZXJzL2Ns
ay9pbXgvY2xrLWlteDdkLmMNCj4gPiA+ICsrKyBiL2RyaXZlcnMvY2xrL2lteC9jbGstaW14N2Qu
Yw0KPiA+ID4gQEAgLTM3OSwxMyArMzc5LDYgQEAgc3RhdGljIGNvbnN0IGNoYXIgKnBsbF9lbmV0
X2J5cGFzc19zZWxbXSA9IHsNCj4gPiA+ICJwbGxfZW5ldF9tYWluIiwgInBsbF9lbmV0X21haW5f
c3JjICBzdGF0aWMgY29uc3QgY2hhcg0KPiA+ID4gKnBsbF9hdWRpb19ieXBhc3Nfc2VsW10gPSB7
ICJwbGxfYXVkaW9fbWFpbiIsICJwbGxfYXVkaW9fbWFpbl9zcmMiLA0KPiA+ID4gfTsgc3RhdGlj
IGNvbnN0IGNoYXIgKnBsbF92aWRlb19ieXBhc3Nfc2VsW10gPSB7ICJwbGxfdmlkZW9fbWFpbiIs
DQo+ID4gPiAicGxsX3ZpZGVvX21haW5fc3JjIiwgfTsNCj4gPiA+DQo+ID4gPiAtc3RhdGljIGlu
dCBjb25zdCBjbGtzX2luaXRfb25bXSBfX2luaXRjb25zdCA9IHsNCj4gPiA+IC0JSU1YN0RfQVJN
X0E3X1JPT1RfQ0xLLCBJTVg3RF9NQUlOX0FYSV9ST09UX0NMSywNCj4gPiA+IC0JSU1YN0RfUExM
X1NZU19NQUlOXzQ4ME1fQ0xLLCBJTVg3RF9JUEdfUk9PVF9DTEssDQo+ID4gPiAtCUlNWDdEX0RS
QU1fUEhZTV9ST09UX0NMSywgSU1YN0RfRFJBTV9ST09UX0NMSywNCj4gPiA+IC0JSU1YN0RfRFJB
TV9QSFlNX0FMVF9ST09UX0NMSywgSU1YN0RfRFJBTV9BTFRfUk9PVF9DTEssDQo+ID4gPiAtfTsN
Cj4gPiA+IC0NCj4gPiA+ICBzdGF0aWMgc3RydWN0IGNsa19vbmVjZWxsX2RhdGEgY2xrX2RhdGE7
DQo+ID4gPg0KPiA+ID4gIHN0YXRpYyBzdHJ1Y3QgY2xrICoqIGNvbnN0IHVhcnRfY2xrc1tdIF9f
aW5pdGNvbnN0ID0geyBAQCAtNDAzLDcNCj4gPiA+ICszOTYsNiBAQCBzdGF0aWMgdm9pZCBfX2lu
aXQgaW14N2RfY2xvY2tzX2luaXQoc3RydWN0IGRldmljZV9ub2RlDQo+ID4gKmNjbV9ub2RlKSAg
ew0KPiA+ID4gIAlzdHJ1Y3QgZGV2aWNlX25vZGUgKm5wOw0KPiA+ID4gIAl2b2lkIF9faW9tZW0g
KmJhc2U7DQo+ID4gPiAtCWludCBpOw0KPiA+ID4NCj4gPiA+ICAJY2xrc1tJTVg3RF9DTEtfRFVN
TVldID0gaW14X2Nsa19maXhlZCgiZHVtbXkiLCAwKTsNCj4gPiA+ICAJY2xrc1tJTVg3RF9PU0Nf
MjRNX0NMS10gPSBvZl9jbGtfZ2V0X2J5X25hbWUoY2NtX25vZGUsICJvc2MiKTsNCj4gPiBAQA0K
PiA+ID4gLTQ2Niw3ICs0NTgsNyBAQCBzdGF0aWMgdm9pZCBfX2luaXQgaW14N2RfY2xvY2tzX2lu
aXQoc3RydWN0DQo+ID4gPiBkZXZpY2Vfbm9kZQ0KPiA+ID4gKmNjbV9ub2RlKQ0KPiA+ID4gIAlj
bGtzW0lNWDdEX1BMTF9TWVNfTUFJTl8xMjBNXSA9DQo+ID4gPiBpbXhfY2xrX2ZpeGVkX2ZhY3Rv
cigicGxsX3N5c19tYWluXzEyMG0iLCAicGxsX3N5c19tYWluX2NsayIsIDEsIDQpOw0KPiA+ID4g
IAljbGtzW0lNWDdEX1BMTF9EUkFNX01BSU5fNTMzTV0gPQ0KPiA+ID4gaW14X2Nsa19maXhlZF9m
YWN0b3IoInBsbF9kcmFtXzUzM20iLCAicGxsX2RyYW1fbWFpbl9jbGsiLCAxLCAyKTsNCj4gPiA+
DQo+ID4gPiAtCWNsa3NbSU1YN0RfUExMX1NZU19NQUlOXzQ4ME1fQ0xLXSA9DQo+ID4gPiBpbXhf
Y2xrX2dhdGVfZGlzKCJwbGxfc3lzX21haW5fNDgwbV9jbGsiLCAicGxsX3N5c19tYWluXzQ4MG0i
LCBiYXNlDQo+ID4gPiArIDB4YjAsIDQpOw0KPiA+ID4gKwljbGtzW0lNWDdEX1BMTF9TWVNfTUFJ
Tl80ODBNX0NMS10gPQ0KPiA+ID4gK2lteF9jbGtfZ2F0ZV9kaXNfZmxhZ3MoInBsbF9zeXNfbWFp
bl80ODBtX2NsayIsDQo+ID4gPiArInBsbF9zeXNfbWFpbl80ODBtIiwgYmFzZSArIDB4YjAsIDQs
IENMS19JU19DUklUSUNBTCk7DQo+ID4gPiAgCWNsa3NbSU1YN0RfUExMX1NZU19NQUlOXzI0ME1f
Q0xLXSA9DQo+ID4gPiBpbXhfY2xrX2dhdGVfZGlzKCJwbGxfc3lzX21haW5fMjQwbV9jbGsiLCAi
cGxsX3N5c19tYWluXzI0MG0iLCBiYXNlDQo+ID4gPiArIDB4YjAsIDUpOw0KPiA+ID4gIAljbGtz
W0lNWDdEX1BMTF9TWVNfTUFJTl8xMjBNX0NMS10gPQ0KPiA+ID4gaW14X2Nsa19nYXRlX2Rpcygi
cGxsX3N5c19tYWluXzEyMG1fY2xrIiwgInBsbF9zeXNfbWFpbl8xMjBtIiwgYmFzZQ0KPiA+ID4g
KyAweGIwLCA2KTsNCj4gPiA+ICAJY2xrc1tJTVg3RF9QTExfRFJBTV9NQUlOXzUzM01fQ0xLXSA9
DQo+ID4gPiBpbXhfY2xrX2dhdGUoInBsbF9kcmFtXzUzM21fY2xrIiwgInBsbF9kcmFtXzUzM20i
LCBiYXNlICsgMHg3MCwgMTIpOw0KPiA+ID4gQEANCj4gPiA+IC03MTksNyArNzExLDcgQEAgc3Rh
dGljIHZvaWQgX19pbml0IGlteDdkX2Nsb2Nrc19pbml0KHN0cnVjdA0KPiA+ID4gZGV2aWNlX25v
ZGUNCj4gPiA+ICpjY21fbm9kZSkNCj4gPiA+ICAJY2xrc1tJTVg3RF9FTkVUX0FYSV9ST09UX0RJ
Vl0gPQ0KPiA+ID4gaW14X2Nsa19kaXZpZGVyMigiZW5ldF9heGlfcG9zdF9kaXYiLCAiZW5ldF9h
eGlfcHJlX2RpdiIsIGJhc2UgKw0KPiA+ID4gMHg4OTAwLCAwLA0KPiA+IDYpOw0KPiA+ID4gIAlj
bGtzW0lNWDdEX05BTkRfVVNESENfQlVTX1JPT1RfQ0xLXSA9DQo+ID4gPiBpbXhfY2xrX2Rpdmlk
ZXIyKCJuYW5kX3VzZGhjX3Jvb3RfY2xrIiwgIm5hbmRfdXNkaGNfcHJlX2RpdiIsIGJhc2UgKw0K
PiA+ID4gMHg4OTgwLCAwLCA2KTsNCj4gPiA+ICAJY2xrc1tJTVg3RF9BSEJfQ0hBTk5FTF9ST09U
X0RJVl0gPQ0KPiA+ID4gaW14X2Nsa19kaXZpZGVyMigiYWhiX3Jvb3RfY2xrIiwgImFoYl9wcmVf
ZGl2IiwgYmFzZSArIDB4OTAwMCwgMCwgNik7DQo+ID4gPiAtCWNsa3NbSU1YN0RfSVBHX1JPT1Rf
Q0xLXSA9IGlteF9jbGtfZGl2aWRlcjIoImlwZ19yb290X2NsayIsDQo+ID4gPiAiYWhiX3Jvb3Rf
Y2xrIiwgYmFzZSArIDB4OTA4MCwgMCwgMik7DQo+ID4gPiArCWNsa3NbSU1YN0RfSVBHX1JPT1Rf
Q0xLXSA9IGlteF9jbGtfZGl2aWRlcl9mbGFncygiaXBnX3Jvb3RfY2xrIiwNCj4gPiA+ICsiYWhi
X3Jvb3RfY2xrIiwgYmFzZSArIDB4OTA4MCwgMCwgMiwgQ0xLX0lTX0NSSVRJQ0FMIHwNCj4gPiA+
ICtDTEtfT1BTX1BBUkVOVF9FTkFCTEUgfCBDTEtfU0VUX1JBVEVfUEFSRU5UKTsNCj4gPiA+ICAJ
Y2xrc1tJTVg3RF9EUkFNX1JPT1RfRElWXSA9IGlteF9jbGtfZGl2aWRlcjIoImRyYW1fcG9zdF9k
aXYiLA0KPiA+ID4gImRyYW1fY2ciLCBiYXNlICsgMHg5ODgwLCAwLCAzKTsNCj4gPiA+ICAJY2xr
c1tJTVg3RF9EUkFNX1BIWU1fQUxUX1JPT1RfRElWXSA9DQo+ID4gPiBpbXhfY2xrX2RpdmlkZXIy
KCJkcmFtX3BoeW1fYWx0X3Bvc3RfZGl2IiwgImRyYW1fcGh5bV9hbHRfcHJlX2RpdiIsDQo+ID4g
PiBiYXNlDQo+ID4gPiArIDB4YTAwMCwgMCwgMyk7DQo+ID4gPiAgCWNsa3NbSU1YN0RfRFJBTV9B
TFRfUk9PVF9ESVZdID0NCj4gPiA+IGlteF9jbGtfZGl2aWRlcjIoImRyYW1fYWx0X3Bvc3RfZGl2
IiwgImRyYW1fYWx0X3ByZV9kaXYiLCBiYXNlICsNCj4gPiA+IDB4YTA4MCwgMCwgMyk7IEBAIC03
ODMsMTcgKzc3NSwxNyBAQCBzdGF0aWMgdm9pZCBfX2luaXQNCj4gPiA+IGlteDdkX2Nsb2Nrc19p
bml0KHN0cnVjdCBkZXZpY2Vfbm9kZSAqY2NtX25vZGUpDQo+ID4gPiAgCWNsa3NbSU1YN0RfQ0xL
TzFfUk9PVF9ESVZdID0gaW14X2Nsa19kaXZpZGVyMigiY2xrbzFfcG9zdF9kaXYiLA0KPiA+ID4g
ImNsa28xX3ByZV9kaXYiLCBiYXNlICsgMHhiZDgwLCAwLCA2KTsNCj4gPiA+ICAJY2xrc1tJTVg3
RF9DTEtPMl9ST09UX0RJVl0gPSBpbXhfY2xrX2RpdmlkZXIyKCJjbGtvMl9wb3N0X2RpdiIsDQo+
ID4gPiAiY2xrbzJfcHJlX2RpdiIsIGJhc2UgKyAweGJlMDAsIDAsIDYpOw0KPiA+ID4NCj4gPiA+
IC0JY2xrc1tJTVg3RF9BUk1fQTdfUk9PVF9DTEtdID0gaW14X2Nsa19nYXRlNCgiYXJtX2E3X3Jv
b3RfY2xrIiwNCj4gPiA+ICJhcm1fYTdfZGl2IiwgYmFzZSArIDB4NDAwMCwgMCk7DQo+ID4gPiAr
CWNsa3NbSU1YN0RfQVJNX0E3X1JPT1RfQ0xLXSA9DQo+ID4gPiBpbXhfY2xrX2dhdGUyX2ZsYWdz
KCJhcm1fYTdfcm9vdF9jbGsiLA0KPiA+ID4gKyJhcm1fYTdfZGl2IiwgYmFzZSArIDB4NDAwMCwg
MCwgQ0xLX0lTX0NSSVRJQ0FMIHwNCj4gPiA+ICtDTEtfT1BTX1BBUkVOVF9FTkFCTEUpOw0KPiA+
ID4gIAljbGtzW0lNWDdEX0FSTV9NNF9ST09UX0NMS10gPQ0KPiBpbXhfY2xrX2dhdGU0KCJhcm1f
bTRfcm9vdF9jbGsiLA0KPiA+ID4gImFybV9tNF9kaXYiLCBiYXNlICsgMHg0MDEwLCAwKTsNCj4g
PiA+IC0JY2xrc1tJTVg3RF9NQUlOX0FYSV9ST09UX0NMS10gPSBpbXhfY2xrX2dhdGU0KCJtYWlu
X2F4aV9yb290X2NsayIsDQo+ID4gPiAiYXhpX3Bvc3RfZGl2IiwgYmFzZSArIDB4NDA0MCwgMCk7
DQo+ID4gPiArCWNsa3NbSU1YN0RfTUFJTl9BWElfUk9PVF9DTEtdID0NCj4gPiA+ICtpbXhfY2xr
X2dhdGUyX2ZsYWdzKCJtYWluX2F4aV9yb290X2NsayIsICJheGlfcG9zdF9kaXYiLCBiYXNlICsN
Cj4gPiA+ICsweDQwNDAsIDAsIENMS19JU19DUklUSUNBTCB8IENMS19PUFNfUEFSRU5UX0VOQUJM
RSk7DQo+ID4gPiAgCWNsa3NbSU1YN0RfRElTUF9BWElfUk9PVF9DTEtdID0NCj4gaW14X2Nsa19n
YXRlNCgiZGlzcF9heGlfcm9vdF9jbGsiLA0KPiA+ID4gImRpc3BfYXhpX3Bvc3RfZGl2IiwgYmFz
ZSArIDB4NDA1MCwgMCk7DQo+ID4gPiAgCWNsa3NbSU1YN0RfRU5FVF9BWElfUk9PVF9DTEtdID0N
Cj4gaW14X2Nsa19nYXRlNCgiZW5ldF9heGlfcm9vdF9jbGsiLA0KPiA+ID4gImVuZXRfYXhpX3Bv
c3RfZGl2IiwgYmFzZSArIDB4NDA2MCwgMCk7DQo+ID4gPiAgCWNsa3NbSU1YN0RfT0NSQU1fQ0xL
XSA9IGlteF9jbGtfZ2F0ZTQoIm9jcmFtX2NsayIsDQo+ID4gPiAibWFpbl9heGlfcm9vdF9jbGsi
LCBiYXNlICsgMHg0MTEwLCAwKTsNCj4gPiA+ICAJY2xrc1tJTVg3RF9PQ1JBTV9TX0NMS10gPSBp
bXhfY2xrX2dhdGU0KCJvY3JhbV9zX2NsayIsDQo+ID4gPiAiYWhiX3Jvb3RfY2xrIiwgYmFzZSAr
IDB4NDEyMCwgMCk7DQo+ID4gPiAtCWNsa3NbSU1YN0RfRFJBTV9ST09UX0NMS10gPSBpbXhfY2xr
X2dhdGU0KCJkcmFtX3Jvb3RfY2xrIiwNCj4gPiA+ICJkcmFtX3Bvc3RfZGl2IiwgYmFzZSArIDB4
NDEzMCwgMCk7DQo+ID4gPiAtCWNsa3NbSU1YN0RfRFJBTV9QSFlNX1JPT1RfQ0xLXSA9DQo+ID4g
PiBpbXhfY2xrX2dhdGU0KCJkcmFtX3BoeW1fcm9vdF9jbGsiLCAiZHJhbV9waHltX2NnIiwgYmFz
ZSArIDB4NDEzMCwNCj4gMCk7DQo+ID4gPiAtCWNsa3NbSU1YN0RfRFJBTV9QSFlNX0FMVF9ST09U
X0NMS10gPQ0KPiA+ID4gaW14X2Nsa19nYXRlNCgiZHJhbV9waHltX2FsdF9yb290X2NsayIsICJk
cmFtX3BoeW1fYWx0X3Bvc3RfZGl2IiwNCj4gPiA+IGJhc2UNCj4gPiA+ICsgMHg0MTMwLCAwKTsN
Cj4gPiA+IC0JY2xrc1tJTVg3RF9EUkFNX0FMVF9ST09UX0NMS10gPQ0KPiA+IGlteF9jbGtfZ2F0
ZTQoImRyYW1fYWx0X3Jvb3RfY2xrIiwNCj4gPiA+ICJkcmFtX2FsdF9wb3N0X2RpdiIsIGJhc2Ug
KyAweDQxMzAsIDApOw0KPiA+ID4gKwljbGtzW0lNWDdEX0RSQU1fUk9PVF9DTEtdID0NCj4gaW14
X2Nsa19nYXRlMl9mbGFncygiZHJhbV9yb290X2NsayIsDQo+ID4gPiAiZHJhbV9wb3N0X2RpdiIs
IGJhc2UgKyAweDQxMzAsIDAsIENMS19JU19DUklUSUNBTCB8DQo+ID4gPiBDTEtfT1BTX1BBUkVO
VF9FTkFCTEUpOw0KPiA+ID4gKwljbGtzW0lNWDdEX0RSQU1fUEhZTV9ST09UX0NMS10gPQ0KPiA+
ID4gaW14X2Nsa19nYXRlMl9mbGFncygiZHJhbV9waHltX3Jvb3RfY2xrIiwgImRyYW1fcGh5bV9j
ZyIsIGJhc2UgKw0KPiA+ID4gMHg0MTMwLCAwLCBDTEtfSVNfQ1JJVElDQUwgfCBDTEtfT1BTX1BB
UkVOVF9FTkFCTEUpOw0KPiA+ID4gKwljbGtzW0lNWDdEX0RSQU1fUEhZTV9BTFRfUk9PVF9DTEtd
ID0NCj4gPiA+IGlteF9jbGtfZ2F0ZTJfZmxhZ3MoImRyYW1fcGh5bV9hbHRfcm9vdF9jbGsiLA0K
PiA+ID4gImRyYW1fcGh5bV9hbHRfcG9zdF9kaXYiLCBiYXNlICsgMHg0MTMwLCAwLCBDTEtfSVNf
Q1JJVElDQUwgfA0KPiA+ID4gQ0xLX09QU19QQVJFTlRfRU5BQkxFKTsNCj4gPiA+ICsJY2xrc1tJ
TVg3RF9EUkFNX0FMVF9ST09UX0NMS10gPQ0KPiA+ID4gK2lteF9jbGtfZ2F0ZTJfZmxhZ3MoImRy
YW1fYWx0X3Jvb3RfY2xrIiwgImRyYW1fYWx0X3Bvc3RfZGl2IiwgYmFzZQ0KPiA+ID4gKysgMHg0
MTMwLCAwLCBDTEtfSVNfQ1JJVElDQUwgfCBDTEtfT1BTX1BBUkVOVF9FTkFCTEUpOw0KPiA+ID4g
IAljbGtzW0lNWDdEX09DT1RQX0NMS10gPSBpbXhfY2xrX2dhdGU0KCJvY290cF9jbGsiLA0KPiAi
aXBnX3Jvb3RfY2xrIiwNCj4gPiA+IGJhc2UgKyAweDQyMzAsIDApOw0KPiA+ID4gIAljbGtzW0lN
WDdEX1NOVlNfQ0xLXSA9IGlteF9jbGtfZ2F0ZTQoInNudnNfY2xrIiwgImlwZ19yb290X2NsayIs
DQo+ID4gPiBiYXNlICsgMHg0MjUwLCAwKTsNCj4gPiA+ICAJY2xrc1tJTVg3RF9NVV9ST09UX0NM
S10gPSBpbXhfY2xrX2dhdGU0KCJtdV9yb290X2NsayIsDQo+ID4gPiAiaXBnX3Jvb3RfY2xrIiwg
YmFzZSArIDB4NDI3MCwgMCk7IEBAIC04ODIsOSArODc0LDYgQEAgc3RhdGljIHZvaWQNCj4gPiA+
IF9faW5pdCBpbXg3ZF9jbG9ja3NfaW5pdChzdHJ1Y3QgZGV2aWNlX25vZGUgKmNjbV9ub2RlKQ0K
PiA+ID4gIAljbGtfZGF0YS5jbGtfbnVtID0gQVJSQVlfU0laRShjbGtzKTsNCj4gPiA+ICAJb2Zf
Y2xrX2FkZF9wcm92aWRlcihucCwgb2ZfY2xrX3NyY19vbmVjZWxsX2dldCwgJmNsa19kYXRhKTsN
Cj4gPiA+DQo+ID4gPiAtCWZvciAoaSA9IDA7IGkgPCBBUlJBWV9TSVpFKGNsa3NfaW5pdF9vbik7
IGkrKykNCj4gPiA+IC0JCWNsa19wcmVwYXJlX2VuYWJsZShjbGtzW2Nsa3NfaW5pdF9vbltpXV0p
Ow0KPiA+ID4gLQ0KPiA+ID4gIAljbGtfc2V0X3BhcmVudChjbGtzW0lNWDdEX1BMTF9BUk1fTUFJ
Tl9CWVBBU1NdLA0KPiA+ID4gY2xrc1tJTVg3RF9QTExfQVJNX01BSU5dKTsNCj4gPiA+ICAJY2xr
X3NldF9wYXJlbnQoY2xrc1tJTVg3RF9QTExfRFJBTV9NQUlOX0JZUEFTU10sDQo+ID4gPiBjbGtz
W0lNWDdEX1BMTF9EUkFNX01BSU5dKTsNCj4gPiA+ICAJY2xrX3NldF9wYXJlbnQoY2xrc1tJTVg3
RF9QTExfU1lTX01BSU5fQllQQVNTXSwNCj4gPiA+IGNsa3NbSU1YN0RfUExMX1NZU19NQUlOXSk7
IGRpZmYgLS1naXQgYS9kcml2ZXJzL2Nsay9pbXgvY2xrLmgNCj4gPiA+IGIvZHJpdmVycy9jbGsv
aW14L2Nsay5oIGluZGV4IDgwNzZlYzAuLjU4OTVlMjIzIDEwMDY0NA0KPiA+ID4gLS0tIGEvZHJp
dmVycy9jbGsvaW14L2Nsay5oDQo+ID4gPiArKysgYi9kcml2ZXJzL2Nsay9pbXgvY2xrLmgNCj4g
PiA+IEBAIC0xMzcsNiArMTM3LDEzIEBAIHN0YXRpYyBpbmxpbmUgc3RydWN0IGNsaw0KPiA+ID4g
KmlteF9jbGtfZ2F0ZV9kaXMoY29uc3QgY2hhciAqbmFtZSwgY29uc3QgY2hhciAqcGFyZW50LA0K
PiA+ID4gIAkJCXNoaWZ0LCBDTEtfR0FURV9TRVRfVE9fRElTQUJMRSwgJmlteF9jY21fbG9jayk7
ICB9DQo+ID4gPg0KPiA+ID4gK3N0YXRpYyBpbmxpbmUgc3RydWN0IGNsayAqaW14X2Nsa19nYXRl
X2Rpc19mbGFncyhjb25zdCBjaGFyICpuYW1lLA0KPiA+ID4gK2NvbnN0IGNoYXINCj4gPiA+ICpw
YXJlbnQsDQo+ID4gPiArCQl2b2lkIF9faW9tZW0gKnJlZywgdTggc2hpZnQsIHVuc2lnbmVkIGxv
bmcgZmxhZ3MpIHsNCj4gPiA+ICsJcmV0dXJuIGNsa19yZWdpc3Rlcl9nYXRlKE5VTEwsIG5hbWUs
IHBhcmVudCwgZmxhZ3MgfA0KPiA+ID4gQ0xLX1NFVF9SQVRFX1BBUkVOVCwgcmVnLA0KPiA+ID4g
KwkJCXNoaWZ0LCBDTEtfR0FURV9TRVRfVE9fRElTQUJMRSwgJmlteF9jY21fbG9jayk7IH0NCj4g
PiA+ICsNCj4gPiA+ICBzdGF0aWMgaW5saW5lIHN0cnVjdCBjbGsgKmlteF9jbGtfZ2F0ZTIoY29u
c3QgY2hhciAqbmFtZSwgY29uc3QNCj4gPiA+IGNoYXINCj4gPiAqcGFyZW50LA0KPiA+ID4gIAkJ
dm9pZCBfX2lvbWVtICpyZWcsIHU4IHNoaWZ0KQ0KPiA+ID4gIHsNCj4gPiA+IC0tDQo+ID4gPiAy
LjcuNA0KDQo=
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
2018-08-13 1:15 ` Peng Fan
(?)
@ 2018-08-14 7:31 ` Anson Huang
-1 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-08-14 7:31 UTC (permalink / raw)
To: Peng Fan, shawnguo, s.hauer, kernel, Fabio Estevam, mturquette,
sboyd, linux-arm-kernel, linux-clk, linux-kernel, Rob Herring
Cc: dl-linux-imx
Hi, Peng
Anson Huang
Best Regards!
> -----Original Message-----
> From: Peng Fan
> Sent: Monday, August 13, 2018 9:16 AM
> To: Anson Huang <anson.huang@nxp.com>; shawnguo@kernel.org;
> s.hauer@pengutronix.de; kernel@pengutronix.de; Fabio Estevam
> <fabio.estevam@nxp.com>; mturquette@baylibre.com; sboyd@kernel.org;
> linux-arm-kernel@lists.infradead.org; linux-clk@vger.kernel.org;
> linux-kernel@vger.kernel.org; Rob Herring <robh@kernel.org>
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>
> Hi Anson,
>
> > > > -----Original Message-----
> > > > From: Anson Huang
> > > > Sent: 2018年8月8日 12:39
> > > > To: shawnguo@kernel.org; s.hauer@pengutronix.de;
> > > > kernel@pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > > > mturquette@baylibre.com; sboyd@kernel.org;
> > > > linux-arm-kernel@lists.infradead.org;
> > > > linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org
> > > > Cc: dl-linux-imx <linux-imx@nxp.com>
> > > > Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> > > >
> > > > Clock framework will enable those clocks registered with
> > > > CLK_IS_CRITICAL flag, so no need to have clks_init_on array during
> > > > clock
> > > initialization now.
> > >
> > > Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> > > or "init-on-arrary=<xxx>"
> > > and enable those clocks?
> >
> > Parsing the clocks arrays from dtb is another way of enabling critical
> > clocks, but for current i.MX6/7 platforms, we implement it in same way
> > as most of other SoCs, currently I did NOT see any necessity of
> > putting them in dtb, just adding flag during clock registering is more
> > simple, if there is any special requirement for different clocks set
> > to be enabled, then we can add support to enable the method of parsing
> critical-clocks from dtb. Just my two cents.
>
> Thinking about OP-TEE want to use one device, but it's clocks are registered by
> Linux, because there is no module in Linux side use it, it will shutdown the clock,
> which cause OP-TEE could not access the device.
>
> Then people have to modify clk code to add CLK_IS_CRITICAL flag to make sure
> the clocks are not shutdown by Linux.
>
> However adding a new property in clk node and let driver code parse the dts,
> there is no need to modify clk driver code when OP-TEE needs another device
> clock.
For supporting OP-TEE or other features which has special requirement about clock
settings, I think we can have another patch to add parsing critical clocks from dtb in
common place of i.MX clock drivers.
Anson.
>
> Regards,
> Peng.
>
> >
> > Anson.
> >
> > >
> > > Regards,
> > > Peng.
> > >
> > > >
> > > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > > > ---
> > > > drivers/clk/imx/clk-imx7d.c | 27 ++++++++-------------------
> > > > drivers/clk/imx/clk.h | 7 +++++++
> > > > 2 files changed, 15 insertions(+), 19 deletions(-)
> > > >
> > > > diff --git a/drivers/clk/imx/clk-imx7d.c
> > > > b/drivers/clk/imx/clk-imx7d.c index c4518d7..076460b 100644
> > > > --- a/drivers/clk/imx/clk-imx7d.c
> > > > +++ b/drivers/clk/imx/clk-imx7d.c
> > > > @@ -379,13 +379,6 @@ static const char *pll_enet_bypass_sel[] = {
> > > > "pll_enet_main", "pll_enet_main_src static const char
> > > > *pll_audio_bypass_sel[] = { "pll_audio_main",
> > > > "pll_audio_main_src", }; static const char *pll_video_bypass_sel[]
> > > > = { "pll_video_main", "pll_video_main_src", };
> > > >
> > > > -static int const clks_init_on[] __initconst = {
> > > > - IMX7D_ARM_A7_ROOT_CLK, IMX7D_MAIN_AXI_ROOT_CLK,
> > > > - IMX7D_PLL_SYS_MAIN_480M_CLK, IMX7D_IPG_ROOT_CLK,
> > > > - IMX7D_DRAM_PHYM_ROOT_CLK, IMX7D_DRAM_ROOT_CLK,
> > > > - IMX7D_DRAM_PHYM_ALT_ROOT_CLK,
> IMX7D_DRAM_ALT_ROOT_CLK,
> > > > -};
> > > > -
> > > > static struct clk_onecell_data clk_data;
> > > >
> > > > static struct clk ** const uart_clks[] __initconst = { @@ -403,7
> > > > +396,6 @@ static void __init imx7d_clocks_init(struct device_node
> > > *ccm_node) {
> > > > struct device_node *np;
> > > > void __iomem *base;
> > > > - int i;
> > > >
> > > > clks[IMX7D_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
> > > > clks[IMX7D_OSC_24M_CLK] = of_clk_get_by_name(ccm_node,
> "osc");
> > > @@
> > > > -466,7 +458,7 @@ static void __init imx7d_clocks_init(struct
> > > > device_node
> > > > *ccm_node)
> > > > clks[IMX7D_PLL_SYS_MAIN_120M] =
> > > > imx_clk_fixed_factor("pll_sys_main_120m", "pll_sys_main_clk", 1, 4);
> > > > clks[IMX7D_PLL_DRAM_MAIN_533M] =
> > > > imx_clk_fixed_factor("pll_dram_533m", "pll_dram_main_clk", 1, 2);
> > > >
> > > > - clks[IMX7D_PLL_SYS_MAIN_480M_CLK] =
> > > > imx_clk_gate_dis("pll_sys_main_480m_clk", "pll_sys_main_480m",
> > > > base
> > > > + 0xb0, 4);
> > > > + clks[IMX7D_PLL_SYS_MAIN_480M_CLK] =
> > > > +imx_clk_gate_dis_flags("pll_sys_main_480m_clk",
> > > > +"pll_sys_main_480m", base + 0xb0, 4, CLK_IS_CRITICAL);
> > > > clks[IMX7D_PLL_SYS_MAIN_240M_CLK] =
> > > > imx_clk_gate_dis("pll_sys_main_240m_clk", "pll_sys_main_240m",
> > > > base
> > > > + 0xb0, 5);
> > > > clks[IMX7D_PLL_SYS_MAIN_120M_CLK] =
> > > > imx_clk_gate_dis("pll_sys_main_120m_clk", "pll_sys_main_120m",
> > > > base
> > > > + 0xb0, 6);
> > > > clks[IMX7D_PLL_DRAM_MAIN_533M_CLK] =
> > > > imx_clk_gate("pll_dram_533m_clk", "pll_dram_533m", base + 0x70,
> > > > 12); @@
> > > > -719,7 +711,7 @@ static void __init imx7d_clocks_init(struct
> > > > device_node
> > > > *ccm_node)
> > > > clks[IMX7D_ENET_AXI_ROOT_DIV] =
> > > > imx_clk_divider2("enet_axi_post_div", "enet_axi_pre_div", base +
> > > > 0x8900, 0,
> > > 6);
> > > > clks[IMX7D_NAND_USDHC_BUS_ROOT_CLK] =
> > > > imx_clk_divider2("nand_usdhc_root_clk", "nand_usdhc_pre_div", base
> > > > + 0x8980, 0, 6);
> > > > clks[IMX7D_AHB_CHANNEL_ROOT_DIV] =
> > > > imx_clk_divider2("ahb_root_clk", "ahb_pre_div", base + 0x9000, 0, 6);
> > > > - clks[IMX7D_IPG_ROOT_CLK] = imx_clk_divider2("ipg_root_clk",
> > > > "ahb_root_clk", base + 0x9080, 0, 2);
> > > > + clks[IMX7D_IPG_ROOT_CLK] = imx_clk_divider_flags("ipg_root_clk",
> > > > +"ahb_root_clk", base + 0x9080, 0, 2, CLK_IS_CRITICAL |
> > > > +CLK_OPS_PARENT_ENABLE | CLK_SET_RATE_PARENT);
> > > > clks[IMX7D_DRAM_ROOT_DIV] = imx_clk_divider2("dram_post_div",
> > > > "dram_cg", base + 0x9880, 0, 3);
> > > > clks[IMX7D_DRAM_PHYM_ALT_ROOT_DIV] =
> > > > imx_clk_divider2("dram_phym_alt_post_div",
> > > > "dram_phym_alt_pre_div", base
> > > > + 0xa000, 0, 3);
> > > > clks[IMX7D_DRAM_ALT_ROOT_DIV] =
> > > > imx_clk_divider2("dram_alt_post_div", "dram_alt_pre_div", base +
> > > > 0xa080, 0, 3); @@ -783,17 +775,17 @@ static void __init
> > > > imx7d_clocks_init(struct device_node *ccm_node)
> > > > clks[IMX7D_CLKO1_ROOT_DIV] = imx_clk_divider2("clko1_post_div",
> > > > "clko1_pre_div", base + 0xbd80, 0, 6);
> > > > clks[IMX7D_CLKO2_ROOT_DIV] = imx_clk_divider2("clko2_post_div",
> > > > "clko2_pre_div", base + 0xbe00, 0, 6);
> > > >
> > > > - clks[IMX7D_ARM_A7_ROOT_CLK] =
> imx_clk_gate4("arm_a7_root_clk",
> > > > "arm_a7_div", base + 0x4000, 0);
> > > > + clks[IMX7D_ARM_A7_ROOT_CLK] =
> > > > imx_clk_gate2_flags("arm_a7_root_clk",
> > > > +"arm_a7_div", base + 0x4000, 0, CLK_IS_CRITICAL |
> > > > +CLK_OPS_PARENT_ENABLE);
> > > > clks[IMX7D_ARM_M4_ROOT_CLK] =
> > imx_clk_gate4("arm_m4_root_clk",
> > > > "arm_m4_div", base + 0x4010, 0);
> > > > - clks[IMX7D_MAIN_AXI_ROOT_CLK] =
> imx_clk_gate4("main_axi_root_clk",
> > > > "axi_post_div", base + 0x4040, 0);
> > > > + clks[IMX7D_MAIN_AXI_ROOT_CLK] =
> > > > +imx_clk_gate2_flags("main_axi_root_clk", "axi_post_div", base +
> > > > +0x4040, 0, CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE);
> > > > clks[IMX7D_DISP_AXI_ROOT_CLK] =
> > imx_clk_gate4("disp_axi_root_clk",
> > > > "disp_axi_post_div", base + 0x4050, 0);
> > > > clks[IMX7D_ENET_AXI_ROOT_CLK] =
> > imx_clk_gate4("enet_axi_root_clk",
> > > > "enet_axi_post_div", base + 0x4060, 0);
> > > > clks[IMX7D_OCRAM_CLK] = imx_clk_gate4("ocram_clk",
> > > > "main_axi_root_clk", base + 0x4110, 0);
> > > > clks[IMX7D_OCRAM_S_CLK] = imx_clk_gate4("ocram_s_clk",
> > > > "ahb_root_clk", base + 0x4120, 0);
> > > > - clks[IMX7D_DRAM_ROOT_CLK] = imx_clk_gate4("dram_root_clk",
> > > > "dram_post_div", base + 0x4130, 0);
> > > > - clks[IMX7D_DRAM_PHYM_ROOT_CLK] =
> > > > imx_clk_gate4("dram_phym_root_clk", "dram_phym_cg", base + 0x4130,
> > 0);
> > > > - clks[IMX7D_DRAM_PHYM_ALT_ROOT_CLK] =
> > > > imx_clk_gate4("dram_phym_alt_root_clk", "dram_phym_alt_post_div",
> > > > base
> > > > + 0x4130, 0);
> > > > - clks[IMX7D_DRAM_ALT_ROOT_CLK] =
> > > imx_clk_gate4("dram_alt_root_clk",
> > > > "dram_alt_post_div", base + 0x4130, 0);
> > > > + clks[IMX7D_DRAM_ROOT_CLK] =
> > imx_clk_gate2_flags("dram_root_clk",
> > > > "dram_post_div", base + 0x4130, 0, CLK_IS_CRITICAL |
> > > > CLK_OPS_PARENT_ENABLE);
> > > > + clks[IMX7D_DRAM_PHYM_ROOT_CLK] =
> > > > imx_clk_gate2_flags("dram_phym_root_clk", "dram_phym_cg", base +
> > > > 0x4130, 0, CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE);
> > > > + clks[IMX7D_DRAM_PHYM_ALT_ROOT_CLK] =
> > > > imx_clk_gate2_flags("dram_phym_alt_root_clk",
> > > > "dram_phym_alt_post_div", base + 0x4130, 0, CLK_IS_CRITICAL |
> > > > CLK_OPS_PARENT_ENABLE);
> > > > + clks[IMX7D_DRAM_ALT_ROOT_CLK] =
> > > > +imx_clk_gate2_flags("dram_alt_root_clk", "dram_alt_post_div",
> > > > +base
> > > > ++ 0x4130, 0, CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE);
> > > > clks[IMX7D_OCOTP_CLK] = imx_clk_gate4("ocotp_clk",
> > "ipg_root_clk",
> > > > base + 0x4230, 0);
> > > > clks[IMX7D_SNVS_CLK] = imx_clk_gate4("snvs_clk", "ipg_root_clk",
> > > > base + 0x4250, 0);
> > > > clks[IMX7D_MU_ROOT_CLK] = imx_clk_gate4("mu_root_clk",
> > > > "ipg_root_clk", base + 0x4270, 0); @@ -882,9 +874,6 @@ static void
> > > > __init imx7d_clocks_init(struct device_node *ccm_node)
> > > > clk_data.clk_num = ARRAY_SIZE(clks);
> > > > of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
> > > >
> > > > - for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
> > > > - clk_prepare_enable(clks[clks_init_on[i]]);
> > > > -
> > > > clk_set_parent(clks[IMX7D_PLL_ARM_MAIN_BYPASS],
> > > > clks[IMX7D_PLL_ARM_MAIN]);
> > > > clk_set_parent(clks[IMX7D_PLL_DRAM_MAIN_BYPASS],
> > > > clks[IMX7D_PLL_DRAM_MAIN]);
> > > > clk_set_parent(clks[IMX7D_PLL_SYS_MAIN_BYPASS],
> > > > clks[IMX7D_PLL_SYS_MAIN]); diff --git a/drivers/clk/imx/clk.h
> > > > b/drivers/clk/imx/clk.h index 8076ec0..5895e223 100644
> > > > --- a/drivers/clk/imx/clk.h
> > > > +++ b/drivers/clk/imx/clk.h
> > > > @@ -137,6 +137,13 @@ static inline struct clk
> > > > *imx_clk_gate_dis(const char *name, const char *parent,
> > > > shift, CLK_GATE_SET_TO_DISABLE, &imx_ccm_lock); }
> > > >
> > > > +static inline struct clk *imx_clk_gate_dis_flags(const char
> > > > +*name, const char
> > > > *parent,
> > > > + void __iomem *reg, u8 shift, unsigned long flags) {
> > > > + return clk_register_gate(NULL, name, parent, flags |
> > > > CLK_SET_RATE_PARENT, reg,
> > > > + shift, CLK_GATE_SET_TO_DISABLE, &imx_ccm_lock); }
> > > > +
> > > > static inline struct clk *imx_clk_gate2(const char *name, const
> > > > char
> > > *parent,
> > > > void __iomem *reg, u8 shift)
> > > > {
> > > > --
> > > > 2.7.4
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-08-14 7:31 ` Anson Huang
0 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-08-14 7:31 UTC (permalink / raw)
To: linux-arm-kernel
Hi, Peng
Anson Huang
Best Regards!
> -----Original Message-----
> From: Peng Fan
> Sent: Monday, August 13, 2018 9:16 AM
> To: Anson Huang <anson.huang@nxp.com>; shawnguo at kernel.org;
> s.hauer at pengutronix.de; kernel at pengutronix.de; Fabio Estevam
> <fabio.estevam@nxp.com>; mturquette at baylibre.com; sboyd at kernel.org;
> linux-arm-kernel at lists.infradead.org; linux-clk at vger.kernel.org;
> linux-kernel at vger.kernel.org; Rob Herring <robh@kernel.org>
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>
> Hi Anson,
>
> > > > -----Original Message-----
> > > > From: Anson Huang
> > > > Sent: 2018?8?8? 12:39
> > > > To: shawnguo at kernel.org; s.hauer at pengutronix.de;
> > > > kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > > > mturquette at baylibre.com; sboyd at kernel.org;
> > > > linux-arm-kernel at lists.infradead.org;
> > > > linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org
> > > > Cc: dl-linux-imx <linux-imx@nxp.com>
> > > > Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> > > >
> > > > Clock framework will enable those clocks registered with
> > > > CLK_IS_CRITICAL flag, so no need to have clks_init_on array during
> > > > clock
> > > initialization now.
> > >
> > > Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> > > or "init-on-arrary=<xxx>"
> > > and enable those clocks?
> >
> > Parsing the clocks arrays from dtb is another way of enabling critical
> > clocks, but for current i.MX6/7 platforms, we implement it in same way
> > as most of other SoCs, currently I did NOT see any necessity of
> > putting them in dtb, just adding flag during clock registering is more
> > simple, if there is any special requirement for different clocks set
> > to be enabled, then we can add support to enable the method of parsing
> critical-clocks from dtb. Just my two cents.
>
> Thinking about OP-TEE want to use one device, but it's clocks are registered by
> Linux, because there is no module in Linux side use it, it will shutdown the clock,
> which cause OP-TEE could not access the device.
>
> Then people have to modify clk code to add CLK_IS_CRITICAL flag to make sure
> the clocks are not shutdown by Linux.
>
> However adding a new property in clk node and let driver code parse the dts,
> there is no need to modify clk driver code when OP-TEE needs another device
> clock.
For supporting OP-TEE or other features which has special requirement about clock
settings, I think we can have another patch to add parsing critical clocks from dtb in
common place of i.MX clock drivers.
Anson.
>
> Regards,
> Peng.
>
> >
> > Anson.
> >
> > >
> > > Regards,
> > > Peng.
> > >
> > > >
> > > > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > > > ---
> > > > drivers/clk/imx/clk-imx7d.c | 27 ++++++++-------------------
> > > > drivers/clk/imx/clk.h | 7 +++++++
> > > > 2 files changed, 15 insertions(+), 19 deletions(-)
> > > >
> > > > diff --git a/drivers/clk/imx/clk-imx7d.c
> > > > b/drivers/clk/imx/clk-imx7d.c index c4518d7..076460b 100644
> > > > --- a/drivers/clk/imx/clk-imx7d.c
> > > > +++ b/drivers/clk/imx/clk-imx7d.c
> > > > @@ -379,13 +379,6 @@ static const char *pll_enet_bypass_sel[] = {
> > > > "pll_enet_main", "pll_enet_main_src static const char
> > > > *pll_audio_bypass_sel[] = { "pll_audio_main",
> > > > "pll_audio_main_src", }; static const char *pll_video_bypass_sel[]
> > > > = { "pll_video_main", "pll_video_main_src", };
> > > >
> > > > -static int const clks_init_on[] __initconst = {
> > > > - IMX7D_ARM_A7_ROOT_CLK, IMX7D_MAIN_AXI_ROOT_CLK,
> > > > - IMX7D_PLL_SYS_MAIN_480M_CLK, IMX7D_IPG_ROOT_CLK,
> > > > - IMX7D_DRAM_PHYM_ROOT_CLK, IMX7D_DRAM_ROOT_CLK,
> > > > - IMX7D_DRAM_PHYM_ALT_ROOT_CLK,
> IMX7D_DRAM_ALT_ROOT_CLK,
> > > > -};
> > > > -
> > > > static struct clk_onecell_data clk_data;
> > > >
> > > > static struct clk ** const uart_clks[] __initconst = { @@ -403,7
> > > > +396,6 @@ static void __init imx7d_clocks_init(struct device_node
> > > *ccm_node) {
> > > > struct device_node *np;
> > > > void __iomem *base;
> > > > - int i;
> > > >
> > > > clks[IMX7D_CLK_DUMMY] = imx_clk_fixed("dummy", 0);
> > > > clks[IMX7D_OSC_24M_CLK] = of_clk_get_by_name(ccm_node,
> "osc");
> > > @@
> > > > -466,7 +458,7 @@ static void __init imx7d_clocks_init(struct
> > > > device_node
> > > > *ccm_node)
> > > > clks[IMX7D_PLL_SYS_MAIN_120M] =
> > > > imx_clk_fixed_factor("pll_sys_main_120m", "pll_sys_main_clk", 1, 4);
> > > > clks[IMX7D_PLL_DRAM_MAIN_533M] =
> > > > imx_clk_fixed_factor("pll_dram_533m", "pll_dram_main_clk", 1, 2);
> > > >
> > > > - clks[IMX7D_PLL_SYS_MAIN_480M_CLK] =
> > > > imx_clk_gate_dis("pll_sys_main_480m_clk", "pll_sys_main_480m",
> > > > base
> > > > + 0xb0, 4);
> > > > + clks[IMX7D_PLL_SYS_MAIN_480M_CLK] =
> > > > +imx_clk_gate_dis_flags("pll_sys_main_480m_clk",
> > > > +"pll_sys_main_480m", base + 0xb0, 4, CLK_IS_CRITICAL);
> > > > clks[IMX7D_PLL_SYS_MAIN_240M_CLK] =
> > > > imx_clk_gate_dis("pll_sys_main_240m_clk", "pll_sys_main_240m",
> > > > base
> > > > + 0xb0, 5);
> > > > clks[IMX7D_PLL_SYS_MAIN_120M_CLK] =
> > > > imx_clk_gate_dis("pll_sys_main_120m_clk", "pll_sys_main_120m",
> > > > base
> > > > + 0xb0, 6);
> > > > clks[IMX7D_PLL_DRAM_MAIN_533M_CLK] =
> > > > imx_clk_gate("pll_dram_533m_clk", "pll_dram_533m", base + 0x70,
> > > > 12); @@
> > > > -719,7 +711,7 @@ static void __init imx7d_clocks_init(struct
> > > > device_node
> > > > *ccm_node)
> > > > clks[IMX7D_ENET_AXI_ROOT_DIV] =
> > > > imx_clk_divider2("enet_axi_post_div", "enet_axi_pre_div", base +
> > > > 0x8900, 0,
> > > 6);
> > > > clks[IMX7D_NAND_USDHC_BUS_ROOT_CLK] =
> > > > imx_clk_divider2("nand_usdhc_root_clk", "nand_usdhc_pre_div", base
> > > > + 0x8980, 0, 6);
> > > > clks[IMX7D_AHB_CHANNEL_ROOT_DIV] =
> > > > imx_clk_divider2("ahb_root_clk", "ahb_pre_div", base + 0x9000, 0, 6);
> > > > - clks[IMX7D_IPG_ROOT_CLK] = imx_clk_divider2("ipg_root_clk",
> > > > "ahb_root_clk", base + 0x9080, 0, 2);
> > > > + clks[IMX7D_IPG_ROOT_CLK] = imx_clk_divider_flags("ipg_root_clk",
> > > > +"ahb_root_clk", base + 0x9080, 0, 2, CLK_IS_CRITICAL |
> > > > +CLK_OPS_PARENT_ENABLE | CLK_SET_RATE_PARENT);
> > > > clks[IMX7D_DRAM_ROOT_DIV] = imx_clk_divider2("dram_post_div",
> > > > "dram_cg", base + 0x9880, 0, 3);
> > > > clks[IMX7D_DRAM_PHYM_ALT_ROOT_DIV] =
> > > > imx_clk_divider2("dram_phym_alt_post_div",
> > > > "dram_phym_alt_pre_div", base
> > > > + 0xa000, 0, 3);
> > > > clks[IMX7D_DRAM_ALT_ROOT_DIV] =
> > > > imx_clk_divider2("dram_alt_post_div", "dram_alt_pre_div", base +
> > > > 0xa080, 0, 3); @@ -783,17 +775,17 @@ static void __init
> > > > imx7d_clocks_init(struct device_node *ccm_node)
> > > > clks[IMX7D_CLKO1_ROOT_DIV] = imx_clk_divider2("clko1_post_div",
> > > > "clko1_pre_div", base + 0xbd80, 0, 6);
> > > > clks[IMX7D_CLKO2_ROOT_DIV] = imx_clk_divider2("clko2_post_div",
> > > > "clko2_pre_div", base + 0xbe00, 0, 6);
> > > >
> > > > - clks[IMX7D_ARM_A7_ROOT_CLK] =
> imx_clk_gate4("arm_a7_root_clk",
> > > > "arm_a7_div", base + 0x4000, 0);
> > > > + clks[IMX7D_ARM_A7_ROOT_CLK] =
> > > > imx_clk_gate2_flags("arm_a7_root_clk",
> > > > +"arm_a7_div", base + 0x4000, 0, CLK_IS_CRITICAL |
> > > > +CLK_OPS_PARENT_ENABLE);
> > > > clks[IMX7D_ARM_M4_ROOT_CLK] =
> > imx_clk_gate4("arm_m4_root_clk",
> > > > "arm_m4_div", base + 0x4010, 0);
> > > > - clks[IMX7D_MAIN_AXI_ROOT_CLK] =
> imx_clk_gate4("main_axi_root_clk",
> > > > "axi_post_div", base + 0x4040, 0);
> > > > + clks[IMX7D_MAIN_AXI_ROOT_CLK] =
> > > > +imx_clk_gate2_flags("main_axi_root_clk", "axi_post_div", base +
> > > > +0x4040, 0, CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE);
> > > > clks[IMX7D_DISP_AXI_ROOT_CLK] =
> > imx_clk_gate4("disp_axi_root_clk",
> > > > "disp_axi_post_div", base + 0x4050, 0);
> > > > clks[IMX7D_ENET_AXI_ROOT_CLK] =
> > imx_clk_gate4("enet_axi_root_clk",
> > > > "enet_axi_post_div", base + 0x4060, 0);
> > > > clks[IMX7D_OCRAM_CLK] = imx_clk_gate4("ocram_clk",
> > > > "main_axi_root_clk", base + 0x4110, 0);
> > > > clks[IMX7D_OCRAM_S_CLK] = imx_clk_gate4("ocram_s_clk",
> > > > "ahb_root_clk", base + 0x4120, 0);
> > > > - clks[IMX7D_DRAM_ROOT_CLK] = imx_clk_gate4("dram_root_clk",
> > > > "dram_post_div", base + 0x4130, 0);
> > > > - clks[IMX7D_DRAM_PHYM_ROOT_CLK] =
> > > > imx_clk_gate4("dram_phym_root_clk", "dram_phym_cg", base + 0x4130,
> > 0);
> > > > - clks[IMX7D_DRAM_PHYM_ALT_ROOT_CLK] =
> > > > imx_clk_gate4("dram_phym_alt_root_clk", "dram_phym_alt_post_div",
> > > > base
> > > > + 0x4130, 0);
> > > > - clks[IMX7D_DRAM_ALT_ROOT_CLK] =
> > > imx_clk_gate4("dram_alt_root_clk",
> > > > "dram_alt_post_div", base + 0x4130, 0);
> > > > + clks[IMX7D_DRAM_ROOT_CLK] =
> > imx_clk_gate2_flags("dram_root_clk",
> > > > "dram_post_div", base + 0x4130, 0, CLK_IS_CRITICAL |
> > > > CLK_OPS_PARENT_ENABLE);
> > > > + clks[IMX7D_DRAM_PHYM_ROOT_CLK] =
> > > > imx_clk_gate2_flags("dram_phym_root_clk", "dram_phym_cg", base +
> > > > 0x4130, 0, CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE);
> > > > + clks[IMX7D_DRAM_PHYM_ALT_ROOT_CLK] =
> > > > imx_clk_gate2_flags("dram_phym_alt_root_clk",
> > > > "dram_phym_alt_post_div", base + 0x4130, 0, CLK_IS_CRITICAL |
> > > > CLK_OPS_PARENT_ENABLE);
> > > > + clks[IMX7D_DRAM_ALT_ROOT_CLK] =
> > > > +imx_clk_gate2_flags("dram_alt_root_clk", "dram_alt_post_div",
> > > > +base
> > > > ++ 0x4130, 0, CLK_IS_CRITICAL | CLK_OPS_PARENT_ENABLE);
> > > > clks[IMX7D_OCOTP_CLK] = imx_clk_gate4("ocotp_clk",
> > "ipg_root_clk",
> > > > base + 0x4230, 0);
> > > > clks[IMX7D_SNVS_CLK] = imx_clk_gate4("snvs_clk", "ipg_root_clk",
> > > > base + 0x4250, 0);
> > > > clks[IMX7D_MU_ROOT_CLK] = imx_clk_gate4("mu_root_clk",
> > > > "ipg_root_clk", base + 0x4270, 0); @@ -882,9 +874,6 @@ static void
> > > > __init imx7d_clocks_init(struct device_node *ccm_node)
> > > > clk_data.clk_num = ARRAY_SIZE(clks);
> > > > of_clk_add_provider(np, of_clk_src_onecell_get, &clk_data);
> > > >
> > > > - for (i = 0; i < ARRAY_SIZE(clks_init_on); i++)
> > > > - clk_prepare_enable(clks[clks_init_on[i]]);
> > > > -
> > > > clk_set_parent(clks[IMX7D_PLL_ARM_MAIN_BYPASS],
> > > > clks[IMX7D_PLL_ARM_MAIN]);
> > > > clk_set_parent(clks[IMX7D_PLL_DRAM_MAIN_BYPASS],
> > > > clks[IMX7D_PLL_DRAM_MAIN]);
> > > > clk_set_parent(clks[IMX7D_PLL_SYS_MAIN_BYPASS],
> > > > clks[IMX7D_PLL_SYS_MAIN]); diff --git a/drivers/clk/imx/clk.h
> > > > b/drivers/clk/imx/clk.h index 8076ec0..5895e223 100644
> > > > --- a/drivers/clk/imx/clk.h
> > > > +++ b/drivers/clk/imx/clk.h
> > > > @@ -137,6 +137,13 @@ static inline struct clk
> > > > *imx_clk_gate_dis(const char *name, const char *parent,
> > > > shift, CLK_GATE_SET_TO_DISABLE, &imx_ccm_lock); }
> > > >
> > > > +static inline struct clk *imx_clk_gate_dis_flags(const char
> > > > +*name, const char
> > > > *parent,
> > > > + void __iomem *reg, u8 shift, unsigned long flags) {
> > > > + return clk_register_gate(NULL, name, parent, flags |
> > > > CLK_SET_RATE_PARENT, reg,
> > > > + shift, CLK_GATE_SET_TO_DISABLE, &imx_ccm_lock); }
> > > > +
> > > > static inline struct clk *imx_clk_gate2(const char *name, const
> > > > char
> > > *parent,
> > > > void __iomem *reg, u8 shift)
> > > > {
> > > > --
> > > > 2.7.4
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-08-14 7:31 ` Anson Huang
0 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-08-14 7:31 UTC (permalink / raw)
To: Peng Fan, shawnguo, s.hauer, kernel, Fabio Estevam, mturquette,
sboyd, linux-arm-kernel, linux-clk, linux-kernel, Rob Herring
Cc: dl-linux-imx
SGksIFBlbmcNCg0KQW5zb24gSHVhbmcNCkJlc3QgUmVnYXJkcyENCg0KDQo+IC0tLS0tT3JpZ2lu
YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFBlbmcgRmFuDQo+IFNlbnQ6IE1vbmRheSwgQXVndXN0
IDEzLCAyMDE4IDk6MTYgQU0NCj4gVG86IEFuc29uIEh1YW5nIDxhbnNvbi5odWFuZ0BueHAuY29t
Pjsgc2hhd25ndW9Aa2VybmVsLm9yZzsNCj4gcy5oYXVlckBwZW5ndXRyb25peC5kZTsga2VybmVs
QHBlbmd1dHJvbml4LmRlOyBGYWJpbyBFc3RldmFtDQo+IDxmYWJpby5lc3RldmFtQG54cC5jb20+
OyBtdHVycXVldHRlQGJheWxpYnJlLmNvbTsgc2JveWRAa2VybmVsLm9yZzsNCj4gbGludXgtYXJt
LWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOyBsaW51eC1jbGtAdmdlci5rZXJuZWwub3JnOw0K
PiBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwub3JnOyBSb2IgSGVycmluZyA8cm9iaEBrZXJuZWwu
b3JnPg0KPiBDYzogZGwtbGludXgtaW14IDxsaW51eC1pbXhAbnhwLmNvbT4NCj4gU3ViamVjdDog
UkU6IFtQQVRDSCAyLzJdIGNsazogaW14OiBpbXg3ZDogcmVtb3ZlIGNsa3NfaW5pdF9vbiBhcnJh
eQ0KPiANCj4gSGkgQW5zb24sDQo+IA0KPiA+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPiA+ID4gPiBGcm9tOiBBbnNvbiBIdWFuZw0KPiA+ID4gPiBTZW50OiAyMDE4xOo41MI4yNUg
MTI6MzkNCj4gPiA+ID4gVG86IHNoYXduZ3VvQGtlcm5lbC5vcmc7IHMuaGF1ZXJAcGVuZ3V0cm9u
aXguZGU7DQo+ID4gPiA+IGtlcm5lbEBwZW5ndXRyb25peC5kZTsgRmFiaW8gRXN0ZXZhbSA8ZmFi
aW8uZXN0ZXZhbUBueHAuY29tPjsNCj4gPiA+ID4gbXR1cnF1ZXR0ZUBiYXlsaWJyZS5jb207IHNi
b3lkQGtlcm5lbC5vcmc7DQo+ID4gPiA+IGxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFk
Lm9yZzsNCj4gPiA+ID4gbGludXgtY2xrQHZnZXIua2VybmVsLm9yZzsgbGludXgta2VybmVsQHZn
ZXIua2VybmVsLm9yZw0KPiA+ID4gPiBDYzogZGwtbGludXgtaW14IDxsaW51eC1pbXhAbnhwLmNv
bT4NCj4gPiA+ID4gU3ViamVjdDogW1BBVENIIDIvMl0gY2xrOiBpbXg6IGlteDdkOiByZW1vdmUg
Y2xrc19pbml0X29uIGFycmF5DQo+ID4gPiA+DQo+ID4gPiA+IENsb2NrIGZyYW1ld29yayB3aWxs
IGVuYWJsZSB0aG9zZSBjbG9ja3MgcmVnaXN0ZXJlZCB3aXRoDQo+ID4gPiA+IENMS19JU19DUklU
SUNBTCBmbGFnLCBzbyBubyBuZWVkIHRvIGhhdmUgY2xrc19pbml0X29uIGFycmF5IGR1cmluZw0K
PiA+ID4gPiBjbG9jaw0KPiA+ID4gaW5pdGlhbGl6YXRpb24gbm93Lg0KPiA+ID4NCj4gPiA+IFdp
bGwgaXQgYmUgbW9yZSBmbGV4aWJsZSB0byBwYXJzZSBkdHMgc2F5aW5nICJjcml0aWNhbC1jbG9j
a3MgPSA8eHh4PiINCj4gPiA+IG9yICJpbml0LW9uLWFycmFyeT08eHh4PiINCj4gPiA+IGFuZCBl
bmFibGUgdGhvc2UgY2xvY2tzPw0KPiA+DQo+ID4gUGFyc2luZyB0aGUgY2xvY2tzIGFycmF5cyBm
cm9tIGR0YiBpcyBhbm90aGVyIHdheSBvZiBlbmFibGluZyBjcml0aWNhbA0KPiA+IGNsb2Nrcywg
YnV0IGZvciBjdXJyZW50IGkuTVg2LzcgcGxhdGZvcm1zLCB3ZSBpbXBsZW1lbnQgaXQgaW4gc2Ft
ZSB3YXkNCj4gPiBhcyBtb3N0IG9mIG90aGVyIFNvQ3MsIGN1cnJlbnRseSBJIGRpZCBOT1Qgc2Vl
IGFueSBuZWNlc3NpdHkgb2YNCj4gPiBwdXR0aW5nIHRoZW0gaW4gZHRiLCBqdXN0IGFkZGluZyBm
bGFnIGR1cmluZyBjbG9jayByZWdpc3RlcmluZyBpcyBtb3JlDQo+ID4gc2ltcGxlLCBpZiB0aGVy
ZSBpcyBhbnkgc3BlY2lhbCByZXF1aXJlbWVudCBmb3IgZGlmZmVyZW50IGNsb2NrcyBzZXQNCj4g
PiB0byBiZSBlbmFibGVkLCB0aGVuIHdlIGNhbiBhZGQgc3VwcG9ydCB0byBlbmFibGUgdGhlIG1l
dGhvZCBvZiBwYXJzaW5nDQo+IGNyaXRpY2FsLWNsb2NrcyBmcm9tIGR0Yi4gSnVzdCBteSB0d28g
Y2VudHMuDQo+IA0KPiBUaGlua2luZyBhYm91dCBPUC1URUUgd2FudCB0byB1c2Ugb25lIGRldmlj
ZSwgYnV0IGl0J3MgY2xvY2tzIGFyZSByZWdpc3RlcmVkIGJ5DQo+IExpbnV4LCBiZWNhdXNlIHRo
ZXJlIGlzIG5vIG1vZHVsZSBpbiBMaW51eCBzaWRlIHVzZSBpdCwgaXQgd2lsbCBzaHV0ZG93biB0
aGUgY2xvY2ssDQo+IHdoaWNoIGNhdXNlIE9QLVRFRSBjb3VsZCBub3QgYWNjZXNzIHRoZSBkZXZp
Y2UuDQo+IA0KPiBUaGVuIHBlb3BsZSBoYXZlIHRvIG1vZGlmeSBjbGsgY29kZSB0byBhZGQgQ0xL
X0lTX0NSSVRJQ0FMIGZsYWcgdG8gbWFrZSBzdXJlDQo+IHRoZSBjbG9ja3MgYXJlIG5vdCBzaHV0
ZG93biBieSBMaW51eC4NCj4gDQo+IEhvd2V2ZXIgYWRkaW5nIGEgbmV3IHByb3BlcnR5IGluIGNs
ayBub2RlIGFuZCBsZXQgZHJpdmVyIGNvZGUgcGFyc2UgdGhlIGR0cywNCj4gdGhlcmUgaXMgbm8g
bmVlZCB0byBtb2RpZnkgY2xrIGRyaXZlciBjb2RlIHdoZW4gT1AtVEVFIG5lZWRzIGFub3RoZXIg
ZGV2aWNlDQo+IGNsb2NrLg0KRm9yIHN1cHBvcnRpbmcgT1AtVEVFIG9yIG90aGVyIGZlYXR1cmVz
IHdoaWNoIGhhcyBzcGVjaWFsIHJlcXVpcmVtZW50IGFib3V0IGNsb2NrDQpzZXR0aW5ncywgSSB0
aGluayB3ZSBjYW4gaGF2ZSBhbm90aGVyIHBhdGNoIHRvIGFkZCBwYXJzaW5nIGNyaXRpY2FsIGNs
b2NrcyBmcm9tIGR0YiBpbg0KY29tbW9uIHBsYWNlIG9mIGkuTVggY2xvY2sgZHJpdmVycy4gDQoN
CkFuc29uLg0KDQo+IA0KPiBSZWdhcmRzLA0KPiBQZW5nLg0KPiANCj4gPg0KPiA+IEFuc29uLg0K
PiA+DQo+ID4gPg0KPiA+ID4gUmVnYXJkcywNCj4gPiA+IFBlbmcuDQo+ID4gPg0KPiA+ID4gPg0K
PiA+ID4gPiBTaWduZWQtb2ZmLWJ5OiBBbnNvbiBIdWFuZyA8QW5zb24uSHVhbmdAbnhwLmNvbT4N
Cj4gPiA+ID4gLS0tDQo+ID4gPiA+ICBkcml2ZXJzL2Nsay9pbXgvY2xrLWlteDdkLmMgfCAyNyAr
KysrKysrKy0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiA+ID4gIGRyaXZlcnMvY2xrL2lteC9jbGsu
aCAgICAgICB8ICA3ICsrKysrKysNCj4gPiA+ID4gIDIgZmlsZXMgY2hhbmdlZCwgMTUgaW5zZXJ0
aW9ucygrKSwgMTkgZGVsZXRpb25zKC0pDQo+ID4gPiA+DQo+ID4gPiA+IGRpZmYgLS1naXQgYS9k
cml2ZXJzL2Nsay9pbXgvY2xrLWlteDdkLmMNCj4gPiA+ID4gYi9kcml2ZXJzL2Nsay9pbXgvY2xr
LWlteDdkLmMgaW5kZXggYzQ1MThkNy4uMDc2NDYwYiAxMDA2NDQNCj4gPiA+ID4gLS0tIGEvZHJp
dmVycy9jbGsvaW14L2Nsay1pbXg3ZC5jDQo+ID4gPiA+ICsrKyBiL2RyaXZlcnMvY2xrL2lteC9j
bGstaW14N2QuYw0KPiA+ID4gPiBAQCAtMzc5LDEzICszNzksNiBAQCBzdGF0aWMgY29uc3QgY2hh
ciAqcGxsX2VuZXRfYnlwYXNzX3NlbFtdID0gew0KPiA+ID4gPiAicGxsX2VuZXRfbWFpbiIsICJw
bGxfZW5ldF9tYWluX3NyYyAgc3RhdGljIGNvbnN0IGNoYXINCj4gPiA+ID4gKnBsbF9hdWRpb19i
eXBhc3Nfc2VsW10gPSB7ICJwbGxfYXVkaW9fbWFpbiIsDQo+ID4gPiA+ICJwbGxfYXVkaW9fbWFp
bl9zcmMiLCB9OyBzdGF0aWMgY29uc3QgY2hhciAqcGxsX3ZpZGVvX2J5cGFzc19zZWxbXQ0KPiA+
ID4gPiA9IHsgInBsbF92aWRlb19tYWluIiwgInBsbF92aWRlb19tYWluX3NyYyIsIH07DQo+ID4g
PiA+DQo+ID4gPiA+IC1zdGF0aWMgaW50IGNvbnN0IGNsa3NfaW5pdF9vbltdIF9faW5pdGNvbnN0
ID0gew0KPiA+ID4gPiAtCUlNWDdEX0FSTV9BN19ST09UX0NMSywgSU1YN0RfTUFJTl9BWElfUk9P
VF9DTEssDQo+ID4gPiA+IC0JSU1YN0RfUExMX1NZU19NQUlOXzQ4ME1fQ0xLLCBJTVg3RF9JUEdf
Uk9PVF9DTEssDQo+ID4gPiA+IC0JSU1YN0RfRFJBTV9QSFlNX1JPT1RfQ0xLLCBJTVg3RF9EUkFN
X1JPT1RfQ0xLLA0KPiA+ID4gPiAtCUlNWDdEX0RSQU1fUEhZTV9BTFRfUk9PVF9DTEssDQo+IElN
WDdEX0RSQU1fQUxUX1JPT1RfQ0xLLA0KPiA+ID4gPiAtfTsNCj4gPiA+ID4gLQ0KPiA+ID4gPiAg
c3RhdGljIHN0cnVjdCBjbGtfb25lY2VsbF9kYXRhIGNsa19kYXRhOw0KPiA+ID4gPg0KPiA+ID4g
PiAgc3RhdGljIHN0cnVjdCBjbGsgKiogY29uc3QgdWFydF9jbGtzW10gX19pbml0Y29uc3QgPSB7
IEBAIC00MDMsNw0KPiA+ID4gPiArMzk2LDYgQEAgc3RhdGljIHZvaWQgX19pbml0IGlteDdkX2Ns
b2Nrc19pbml0KHN0cnVjdCBkZXZpY2Vfbm9kZQ0KPiA+ID4gKmNjbV9ub2RlKSAgew0KPiA+ID4g
PiAgCXN0cnVjdCBkZXZpY2Vfbm9kZSAqbnA7DQo+ID4gPiA+ICAJdm9pZCBfX2lvbWVtICpiYXNl
Ow0KPiA+ID4gPiAtCWludCBpOw0KPiA+ID4gPg0KPiA+ID4gPiAgCWNsa3NbSU1YN0RfQ0xLX0RV
TU1ZXSA9IGlteF9jbGtfZml4ZWQoImR1bW15IiwgMCk7DQo+ID4gPiA+ICAJY2xrc1tJTVg3RF9P
U0NfMjRNX0NMS10gPSBvZl9jbGtfZ2V0X2J5X25hbWUoY2NtX25vZGUsDQo+ICJvc2MiKTsNCj4g
PiA+IEBADQo+ID4gPiA+IC00NjYsNyArNDU4LDcgQEAgc3RhdGljIHZvaWQgX19pbml0IGlteDdk
X2Nsb2Nrc19pbml0KHN0cnVjdA0KPiA+ID4gPiBkZXZpY2Vfbm9kZQ0KPiA+ID4gPiAqY2NtX25v
ZGUpDQo+ID4gPiA+ICAJY2xrc1tJTVg3RF9QTExfU1lTX01BSU5fMTIwTV0gPQ0KPiA+ID4gPiBp
bXhfY2xrX2ZpeGVkX2ZhY3RvcigicGxsX3N5c19tYWluXzEyMG0iLCAicGxsX3N5c19tYWluX2Ns
ayIsIDEsIDQpOw0KPiA+ID4gPiAgCWNsa3NbSU1YN0RfUExMX0RSQU1fTUFJTl81MzNNXSA9DQo+
ID4gPiA+IGlteF9jbGtfZml4ZWRfZmFjdG9yKCJwbGxfZHJhbV81MzNtIiwgInBsbF9kcmFtX21h
aW5fY2xrIiwgMSwgMik7DQo+ID4gPiA+DQo+ID4gPiA+IC0JY2xrc1tJTVg3RF9QTExfU1lTX01B
SU5fNDgwTV9DTEtdID0NCj4gPiA+ID4gaW14X2Nsa19nYXRlX2RpcygicGxsX3N5c19tYWluXzQ4
MG1fY2xrIiwgInBsbF9zeXNfbWFpbl80ODBtIiwNCj4gPiA+ID4gYmFzZQ0KPiA+ID4gPiArIDB4
YjAsIDQpOw0KPiA+ID4gPiArCWNsa3NbSU1YN0RfUExMX1NZU19NQUlOXzQ4ME1fQ0xLXSA9DQo+
ID4gPiA+ICtpbXhfY2xrX2dhdGVfZGlzX2ZsYWdzKCJwbGxfc3lzX21haW5fNDgwbV9jbGsiLA0K
PiA+ID4gPiArInBsbF9zeXNfbWFpbl80ODBtIiwgYmFzZSArIDB4YjAsIDQsIENMS19JU19DUklU
SUNBTCk7DQo+ID4gPiA+ICAJY2xrc1tJTVg3RF9QTExfU1lTX01BSU5fMjQwTV9DTEtdID0NCj4g
PiA+ID4gaW14X2Nsa19nYXRlX2RpcygicGxsX3N5c19tYWluXzI0MG1fY2xrIiwgInBsbF9zeXNf
bWFpbl8yNDBtIiwNCj4gPiA+ID4gYmFzZQ0KPiA+ID4gPiArIDB4YjAsIDUpOw0KPiA+ID4gPiAg
CWNsa3NbSU1YN0RfUExMX1NZU19NQUlOXzEyME1fQ0xLXSA9DQo+ID4gPiA+IGlteF9jbGtfZ2F0
ZV9kaXMoInBsbF9zeXNfbWFpbl8xMjBtX2NsayIsICJwbGxfc3lzX21haW5fMTIwbSIsDQo+ID4g
PiA+IGJhc2UNCj4gPiA+ID4gKyAweGIwLCA2KTsNCj4gPiA+ID4gIAljbGtzW0lNWDdEX1BMTF9E
UkFNX01BSU5fNTMzTV9DTEtdID0NCj4gPiA+ID4gaW14X2Nsa19nYXRlKCJwbGxfZHJhbV81MzNt
X2NsayIsICJwbGxfZHJhbV81MzNtIiwgYmFzZSArIDB4NzAsDQo+ID4gPiA+IDEyKTsgQEANCj4g
PiA+ID4gLTcxOSw3ICs3MTEsNyBAQCBzdGF0aWMgdm9pZCBfX2luaXQgaW14N2RfY2xvY2tzX2lu
aXQoc3RydWN0DQo+ID4gPiA+IGRldmljZV9ub2RlDQo+ID4gPiA+ICpjY21fbm9kZSkNCj4gPiA+
ID4gIAljbGtzW0lNWDdEX0VORVRfQVhJX1JPT1RfRElWXSA9DQo+ID4gPiA+IGlteF9jbGtfZGl2
aWRlcjIoImVuZXRfYXhpX3Bvc3RfZGl2IiwgImVuZXRfYXhpX3ByZV9kaXYiLCBiYXNlICsNCj4g
PiA+ID4gMHg4OTAwLCAwLA0KPiA+ID4gNik7DQo+ID4gPiA+ICAJY2xrc1tJTVg3RF9OQU5EX1VT
REhDX0JVU19ST09UX0NMS10gPQ0KPiA+ID4gPiBpbXhfY2xrX2RpdmlkZXIyKCJuYW5kX3VzZGhj
X3Jvb3RfY2xrIiwgIm5hbmRfdXNkaGNfcHJlX2RpdiIsIGJhc2UNCj4gPiA+ID4gKyAweDg5ODAs
IDAsIDYpOw0KPiA+ID4gPiAgCWNsa3NbSU1YN0RfQUhCX0NIQU5ORUxfUk9PVF9ESVZdID0NCj4g
PiA+ID4gaW14X2Nsa19kaXZpZGVyMigiYWhiX3Jvb3RfY2xrIiwgImFoYl9wcmVfZGl2IiwgYmFz
ZSArIDB4OTAwMCwgMCwgNik7DQo+ID4gPiA+IC0JY2xrc1tJTVg3RF9JUEdfUk9PVF9DTEtdID0g
aW14X2Nsa19kaXZpZGVyMigiaXBnX3Jvb3RfY2xrIiwNCj4gPiA+ID4gImFoYl9yb290X2NsayIs
IGJhc2UgKyAweDkwODAsIDAsIDIpOw0KPiA+ID4gPiArCWNsa3NbSU1YN0RfSVBHX1JPT1RfQ0xL
XSA9IGlteF9jbGtfZGl2aWRlcl9mbGFncygiaXBnX3Jvb3RfY2xrIiwNCj4gPiA+ID4gKyJhaGJf
cm9vdF9jbGsiLCBiYXNlICsgMHg5MDgwLCAwLCAyLCBDTEtfSVNfQ1JJVElDQUwgfA0KPiA+ID4g
PiArQ0xLX09QU19QQVJFTlRfRU5BQkxFIHwgQ0xLX1NFVF9SQVRFX1BBUkVOVCk7DQo+ID4gPiA+
ICAJY2xrc1tJTVg3RF9EUkFNX1JPT1RfRElWXSA9IGlteF9jbGtfZGl2aWRlcjIoImRyYW1fcG9z
dF9kaXYiLA0KPiA+ID4gPiAiZHJhbV9jZyIsIGJhc2UgKyAweDk4ODAsIDAsIDMpOw0KPiA+ID4g
PiAgCWNsa3NbSU1YN0RfRFJBTV9QSFlNX0FMVF9ST09UX0RJVl0gPQ0KPiA+ID4gPiBpbXhfY2xr
X2RpdmlkZXIyKCJkcmFtX3BoeW1fYWx0X3Bvc3RfZGl2IiwNCj4gPiA+ID4gImRyYW1fcGh5bV9h
bHRfcHJlX2RpdiIsIGJhc2UNCj4gPiA+ID4gKyAweGEwMDAsIDAsIDMpOw0KPiA+ID4gPiAgCWNs
a3NbSU1YN0RfRFJBTV9BTFRfUk9PVF9ESVZdID0NCj4gPiA+ID4gaW14X2Nsa19kaXZpZGVyMigi
ZHJhbV9hbHRfcG9zdF9kaXYiLCAiZHJhbV9hbHRfcHJlX2RpdiIsIGJhc2UgKw0KPiA+ID4gPiAw
eGEwODAsIDAsIDMpOyBAQCAtNzgzLDE3ICs3NzUsMTcgQEAgc3RhdGljIHZvaWQgX19pbml0DQo+
ID4gPiA+IGlteDdkX2Nsb2Nrc19pbml0KHN0cnVjdCBkZXZpY2Vfbm9kZSAqY2NtX25vZGUpDQo+
ID4gPiA+ICAJY2xrc1tJTVg3RF9DTEtPMV9ST09UX0RJVl0gPSBpbXhfY2xrX2RpdmlkZXIyKCJj
bGtvMV9wb3N0X2RpdiIsDQo+ID4gPiA+ICJjbGtvMV9wcmVfZGl2IiwgYmFzZSArIDB4YmQ4MCwg
MCwgNik7DQo+ID4gPiA+ICAJY2xrc1tJTVg3RF9DTEtPMl9ST09UX0RJVl0gPSBpbXhfY2xrX2Rp
dmlkZXIyKCJjbGtvMl9wb3N0X2RpdiIsDQo+ID4gPiA+ICJjbGtvMl9wcmVfZGl2IiwgYmFzZSAr
IDB4YmUwMCwgMCwgNik7DQo+ID4gPiA+DQo+ID4gPiA+IC0JY2xrc1tJTVg3RF9BUk1fQTdfUk9P
VF9DTEtdID0NCj4gaW14X2Nsa19nYXRlNCgiYXJtX2E3X3Jvb3RfY2xrIiwNCj4gPiA+ID4gImFy
bV9hN19kaXYiLCBiYXNlICsgMHg0MDAwLCAwKTsNCj4gPiA+ID4gKwljbGtzW0lNWDdEX0FSTV9B
N19ST09UX0NMS10gPQ0KPiA+ID4gPiBpbXhfY2xrX2dhdGUyX2ZsYWdzKCJhcm1fYTdfcm9vdF9j
bGsiLA0KPiA+ID4gPiArImFybV9hN19kaXYiLCBiYXNlICsgMHg0MDAwLCAwLCBDTEtfSVNfQ1JJ
VElDQUwgfA0KPiA+ID4gPiArQ0xLX09QU19QQVJFTlRfRU5BQkxFKTsNCj4gPiA+ID4gIAljbGtz
W0lNWDdEX0FSTV9NNF9ST09UX0NMS10gPQ0KPiA+IGlteF9jbGtfZ2F0ZTQoImFybV9tNF9yb290
X2NsayIsDQo+ID4gPiA+ICJhcm1fbTRfZGl2IiwgYmFzZSArIDB4NDAxMCwgMCk7DQo+ID4gPiA+
IC0JY2xrc1tJTVg3RF9NQUlOX0FYSV9ST09UX0NMS10gPQ0KPiBpbXhfY2xrX2dhdGU0KCJtYWlu
X2F4aV9yb290X2NsayIsDQo+ID4gPiA+ICJheGlfcG9zdF9kaXYiLCBiYXNlICsgMHg0MDQwLCAw
KTsNCj4gPiA+ID4gKwljbGtzW0lNWDdEX01BSU5fQVhJX1JPT1RfQ0xLXSA9DQo+ID4gPiA+ICtp
bXhfY2xrX2dhdGUyX2ZsYWdzKCJtYWluX2F4aV9yb290X2NsayIsICJheGlfcG9zdF9kaXYiLCBi
YXNlICsNCj4gPiA+ID4gKzB4NDA0MCwgMCwgQ0xLX0lTX0NSSVRJQ0FMIHwgQ0xLX09QU19QQVJF
TlRfRU5BQkxFKTsNCj4gPiA+ID4gIAljbGtzW0lNWDdEX0RJU1BfQVhJX1JPT1RfQ0xLXSA9DQo+
ID4gaW14X2Nsa19nYXRlNCgiZGlzcF9heGlfcm9vdF9jbGsiLA0KPiA+ID4gPiAiZGlzcF9heGlf
cG9zdF9kaXYiLCBiYXNlICsgMHg0MDUwLCAwKTsNCj4gPiA+ID4gIAljbGtzW0lNWDdEX0VORVRf
QVhJX1JPT1RfQ0xLXSA9DQo+ID4gaW14X2Nsa19nYXRlNCgiZW5ldF9heGlfcm9vdF9jbGsiLA0K
PiA+ID4gPiAiZW5ldF9heGlfcG9zdF9kaXYiLCBiYXNlICsgMHg0MDYwLCAwKTsNCj4gPiA+ID4g
IAljbGtzW0lNWDdEX09DUkFNX0NMS10gPSBpbXhfY2xrX2dhdGU0KCJvY3JhbV9jbGsiLA0KPiA+
ID4gPiAibWFpbl9heGlfcm9vdF9jbGsiLCBiYXNlICsgMHg0MTEwLCAwKTsNCj4gPiA+ID4gIAlj
bGtzW0lNWDdEX09DUkFNX1NfQ0xLXSA9IGlteF9jbGtfZ2F0ZTQoIm9jcmFtX3NfY2xrIiwNCj4g
PiA+ID4gImFoYl9yb290X2NsayIsIGJhc2UgKyAweDQxMjAsIDApOw0KPiA+ID4gPiAtCWNsa3Nb
SU1YN0RfRFJBTV9ST09UX0NMS10gPSBpbXhfY2xrX2dhdGU0KCJkcmFtX3Jvb3RfY2xrIiwNCj4g
PiA+ID4gImRyYW1fcG9zdF9kaXYiLCBiYXNlICsgMHg0MTMwLCAwKTsNCj4gPiA+ID4gLQljbGtz
W0lNWDdEX0RSQU1fUEhZTV9ST09UX0NMS10gPQ0KPiA+ID4gPiBpbXhfY2xrX2dhdGU0KCJkcmFt
X3BoeW1fcm9vdF9jbGsiLCAiZHJhbV9waHltX2NnIiwgYmFzZSArIDB4NDEzMCwNCj4gPiAwKTsN
Cj4gPiA+ID4gLQljbGtzW0lNWDdEX0RSQU1fUEhZTV9BTFRfUk9PVF9DTEtdID0NCj4gPiA+ID4g
aW14X2Nsa19nYXRlNCgiZHJhbV9waHltX2FsdF9yb290X2NsayIsICJkcmFtX3BoeW1fYWx0X3Bv
c3RfZGl2IiwNCj4gPiA+ID4gYmFzZQ0KPiA+ID4gPiArIDB4NDEzMCwgMCk7DQo+ID4gPiA+IC0J
Y2xrc1tJTVg3RF9EUkFNX0FMVF9ST09UX0NMS10gPQ0KPiA+ID4gaW14X2Nsa19nYXRlNCgiZHJh
bV9hbHRfcm9vdF9jbGsiLA0KPiA+ID4gPiAiZHJhbV9hbHRfcG9zdF9kaXYiLCBiYXNlICsgMHg0
MTMwLCAwKTsNCj4gPiA+ID4gKwljbGtzW0lNWDdEX0RSQU1fUk9PVF9DTEtdID0NCj4gPiBpbXhf
Y2xrX2dhdGUyX2ZsYWdzKCJkcmFtX3Jvb3RfY2xrIiwNCj4gPiA+ID4gImRyYW1fcG9zdF9kaXYi
LCBiYXNlICsgMHg0MTMwLCAwLCBDTEtfSVNfQ1JJVElDQUwgfA0KPiA+ID4gPiBDTEtfT1BTX1BB
UkVOVF9FTkFCTEUpOw0KPiA+ID4gPiArCWNsa3NbSU1YN0RfRFJBTV9QSFlNX1JPT1RfQ0xLXSA9
DQo+ID4gPiA+IGlteF9jbGtfZ2F0ZTJfZmxhZ3MoImRyYW1fcGh5bV9yb290X2NsayIsICJkcmFt
X3BoeW1fY2ciLCBiYXNlICsNCj4gPiA+ID4gMHg0MTMwLCAwLCBDTEtfSVNfQ1JJVElDQUwgfCBD
TEtfT1BTX1BBUkVOVF9FTkFCTEUpOw0KPiA+ID4gPiArCWNsa3NbSU1YN0RfRFJBTV9QSFlNX0FM
VF9ST09UX0NMS10gPQ0KPiA+ID4gPiBpbXhfY2xrX2dhdGUyX2ZsYWdzKCJkcmFtX3BoeW1fYWx0
X3Jvb3RfY2xrIiwNCj4gPiA+ID4gImRyYW1fcGh5bV9hbHRfcG9zdF9kaXYiLCBiYXNlICsgMHg0
MTMwLCAwLCBDTEtfSVNfQ1JJVElDQUwgfA0KPiA+ID4gPiBDTEtfT1BTX1BBUkVOVF9FTkFCTEUp
Ow0KPiA+ID4gPiArCWNsa3NbSU1YN0RfRFJBTV9BTFRfUk9PVF9DTEtdID0NCj4gPiA+ID4gK2lt
eF9jbGtfZ2F0ZTJfZmxhZ3MoImRyYW1fYWx0X3Jvb3RfY2xrIiwgImRyYW1fYWx0X3Bvc3RfZGl2
IiwNCj4gPiA+ID4gK2Jhc2UNCj4gPiA+ID4gKysgMHg0MTMwLCAwLCBDTEtfSVNfQ1JJVElDQUwg
fCBDTEtfT1BTX1BBUkVOVF9FTkFCTEUpOw0KPiA+ID4gPiAgCWNsa3NbSU1YN0RfT0NPVFBfQ0xL
XSA9IGlteF9jbGtfZ2F0ZTQoIm9jb3RwX2NsayIsDQo+ID4gImlwZ19yb290X2NsayIsDQo+ID4g
PiA+IGJhc2UgKyAweDQyMzAsIDApOw0KPiA+ID4gPiAgCWNsa3NbSU1YN0RfU05WU19DTEtdID0g
aW14X2Nsa19nYXRlNCgic252c19jbGsiLCAiaXBnX3Jvb3RfY2xrIiwNCj4gPiA+ID4gYmFzZSAr
IDB4NDI1MCwgMCk7DQo+ID4gPiA+ICAJY2xrc1tJTVg3RF9NVV9ST09UX0NMS10gPSBpbXhfY2xr
X2dhdGU0KCJtdV9yb290X2NsayIsDQo+ID4gPiA+ICJpcGdfcm9vdF9jbGsiLCBiYXNlICsgMHg0
MjcwLCAwKTsgQEAgLTg4Miw5ICs4NzQsNiBAQCBzdGF0aWMgdm9pZA0KPiA+ID4gPiBfX2luaXQg
aW14N2RfY2xvY2tzX2luaXQoc3RydWN0IGRldmljZV9ub2RlICpjY21fbm9kZSkNCj4gPiA+ID4g
IAljbGtfZGF0YS5jbGtfbnVtID0gQVJSQVlfU0laRShjbGtzKTsNCj4gPiA+ID4gIAlvZl9jbGtf
YWRkX3Byb3ZpZGVyKG5wLCBvZl9jbGtfc3JjX29uZWNlbGxfZ2V0LCAmY2xrX2RhdGEpOw0KPiA+
ID4gPg0KPiA+ID4gPiAtCWZvciAoaSA9IDA7IGkgPCBBUlJBWV9TSVpFKGNsa3NfaW5pdF9vbik7
IGkrKykNCj4gPiA+ID4gLQkJY2xrX3ByZXBhcmVfZW5hYmxlKGNsa3NbY2xrc19pbml0X29uW2ld
XSk7DQo+ID4gPiA+IC0NCj4gPiA+ID4gIAljbGtfc2V0X3BhcmVudChjbGtzW0lNWDdEX1BMTF9B
Uk1fTUFJTl9CWVBBU1NdLA0KPiA+ID4gPiBjbGtzW0lNWDdEX1BMTF9BUk1fTUFJTl0pOw0KPiA+
ID4gPiAgCWNsa19zZXRfcGFyZW50KGNsa3NbSU1YN0RfUExMX0RSQU1fTUFJTl9CWVBBU1NdLA0K
PiA+ID4gPiBjbGtzW0lNWDdEX1BMTF9EUkFNX01BSU5dKTsNCj4gPiA+ID4gIAljbGtfc2V0X3Bh
cmVudChjbGtzW0lNWDdEX1BMTF9TWVNfTUFJTl9CWVBBU1NdLA0KPiA+ID4gPiBjbGtzW0lNWDdE
X1BMTF9TWVNfTUFJTl0pOyBkaWZmIC0tZ2l0IGEvZHJpdmVycy9jbGsvaW14L2Nsay5oDQo+ID4g
PiA+IGIvZHJpdmVycy9jbGsvaW14L2Nsay5oIGluZGV4IDgwNzZlYzAuLjU4OTVlMjIzIDEwMDY0
NA0KPiA+ID4gPiAtLS0gYS9kcml2ZXJzL2Nsay9pbXgvY2xrLmgNCj4gPiA+ID4gKysrIGIvZHJp
dmVycy9jbGsvaW14L2Nsay5oDQo+ID4gPiA+IEBAIC0xMzcsNiArMTM3LDEzIEBAIHN0YXRpYyBp
bmxpbmUgc3RydWN0IGNsaw0KPiA+ID4gPiAqaW14X2Nsa19nYXRlX2Rpcyhjb25zdCBjaGFyICpu
YW1lLCBjb25zdCBjaGFyICpwYXJlbnQsDQo+ID4gPiA+ICAJCQlzaGlmdCwgQ0xLX0dBVEVfU0VU
X1RPX0RJU0FCTEUsICZpbXhfY2NtX2xvY2spOyAgfQ0KPiA+ID4gPg0KPiA+ID4gPiArc3RhdGlj
IGlubGluZSBzdHJ1Y3QgY2xrICppbXhfY2xrX2dhdGVfZGlzX2ZsYWdzKGNvbnN0IGNoYXINCj4g
PiA+ID4gKypuYW1lLCBjb25zdCBjaGFyDQo+ID4gPiA+ICpwYXJlbnQsDQo+ID4gPiA+ICsJCXZv
aWQgX19pb21lbSAqcmVnLCB1OCBzaGlmdCwgdW5zaWduZWQgbG9uZyBmbGFncykgew0KPiA+ID4g
PiArCXJldHVybiBjbGtfcmVnaXN0ZXJfZ2F0ZShOVUxMLCBuYW1lLCBwYXJlbnQsIGZsYWdzIHwN
Cj4gPiA+ID4gQ0xLX1NFVF9SQVRFX1BBUkVOVCwgcmVnLA0KPiA+ID4gPiArCQkJc2hpZnQsIENM
S19HQVRFX1NFVF9UT19ESVNBQkxFLCAmaW14X2NjbV9sb2NrKTsgfQ0KPiA+ID4gPiArDQo+ID4g
PiA+ICBzdGF0aWMgaW5saW5lIHN0cnVjdCBjbGsgKmlteF9jbGtfZ2F0ZTIoY29uc3QgY2hhciAq
bmFtZSwgY29uc3QNCj4gPiA+ID4gY2hhcg0KPiA+ID4gKnBhcmVudCwNCj4gPiA+ID4gIAkJdm9p
ZCBfX2lvbWVtICpyZWcsIHU4IHNoaWZ0KQ0KPiA+ID4gPiAgew0KPiA+ID4gPiAtLQ0KPiA+ID4g
PiAyLjcuNA0KDQo=
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
2018-08-13 1:15 ` Peng Fan
(?)
@ 2018-08-31 1:29 ` Stephen Boyd
-1 siblings, 0 replies; 48+ messages in thread
From: Stephen Boyd @ 2018-08-31 1:29 UTC (permalink / raw)
To: kernel, linux-arm-kernel, linux-clk, linux-kernel, mturquette,
s.hauer, shawnguo, Anson Huang, Fabio Estevam, Peng Fan,
Rob Herring
Cc: dl-linux-imx
Quoting Peng Fan (2018-08-12 18:15:41)
> Hi Anson,
>
> > > > -----Original Message-----
> > > > From: Anson Huang
> > > > Sent: 2018年8月8日 12:39
> > > > To: shawnguo@kernel.org; s.hauer@pengutronix.de;
> > > > kernel@pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > > > mturquette@baylibre.com; sboyd@kernel.org;
> > > > linux-arm-kernel@lists.infradead.org;
> > > > linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org
> > > > Cc: dl-linux-imx <linux-imx@nxp.com>
> > > > Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> > > >
> > > > Clock framework will enable those clocks registered with
> > > > CLK_IS_CRITICAL flag, so no need to have clks_init_on array during
> > > > clock
> > > initialization now.
> > >
> > > Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> > > or "init-on-arrary=<xxx>"
> > > and enable those clocks?
> >
> > Parsing the clocks arrays from dtb is another way of enabling critical clocks, but
> > for current i.MX6/7 platforms, we implement it in same way as most of other
> > SoCs, currently I did NOT see any necessity of putting them in dtb, just adding
> > flag during clock registering is more simple, if there is any special requirement
> > for different clocks set to be enabled, then we can add support to enable the
> > method of parsing critical-clocks from dtb. Just my two cents.
>
> Thinking about OP-TEE want to use one device, but it's clocks are registered
> by Linux, because there is no module in Linux side use it, it will shutdown the clock,
> which cause OP-TEE could not access the device.
>
> Then people have to modify clk code to add CLK_IS_CRITICAL flag to make sure
> the clocks are not shutdown by Linux.
>
> However adding a new property in clk node and let driver code parse the dts,
> there is no need to modify clk driver code when OP-TEE needs another device clock.
>
If OP-TEE needs linux to keep things on then why can't the OP-TEE driver
in Linux probe, acquire clocks, and keep the clks enabled forever?
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-08-31 1:29 ` Stephen Boyd
0 siblings, 0 replies; 48+ messages in thread
From: Stephen Boyd @ 2018-08-31 1:29 UTC (permalink / raw)
To: linux-arm-kernel
Quoting Peng Fan (2018-08-12 18:15:41)
> Hi Anson,
>
> > > > -----Original Message-----
> > > > From: Anson Huang
> > > > Sent: 2018?8?8? 12:39
> > > > To: shawnguo at kernel.org; s.hauer at pengutronix.de;
> > > > kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > > > mturquette at baylibre.com; sboyd at kernel.org;
> > > > linux-arm-kernel at lists.infradead.org;
> > > > linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org
> > > > Cc: dl-linux-imx <linux-imx@nxp.com>
> > > > Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> > > >
> > > > Clock framework will enable those clocks registered with
> > > > CLK_IS_CRITICAL flag, so no need to have clks_init_on array during
> > > > clock
> > > initialization now.
> > >
> > > Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> > > or "init-on-arrary=<xxx>"
> > > and enable those clocks?
> >
> > Parsing the clocks arrays from dtb is another way of enabling critical clocks, but
> > for current i.MX6/7 platforms, we implement it in same way as most of other
> > SoCs, currently I did NOT see any necessity of putting them in dtb, just adding
> > flag during clock registering is more simple, if there is any special requirement
> > for different clocks set to be enabled, then we can add support to enable the
> > method of parsing critical-clocks from dtb. Just my two cents.
>
> Thinking about OP-TEE want to use one device, but it's clocks are registered
> by Linux, because there is no module in Linux side use it, it will shutdown the clock,
> which cause OP-TEE could not access the device.
>
> Then people have to modify clk code to add CLK_IS_CRITICAL flag to make sure
> the clocks are not shutdown by Linux.
>
> However adding a new property in clk node and let driver code parse the dts,
> there is no need to modify clk driver code when OP-TEE needs another device clock.
>
If OP-TEE needs linux to keep things on then why can't the OP-TEE driver
in Linux probe, acquire clocks, and keep the clks enabled forever?
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-08-31 1:29 ` Stephen Boyd
0 siblings, 0 replies; 48+ messages in thread
From: Stephen Boyd @ 2018-08-31 1:29 UTC (permalink / raw)
To: kernel, linux-arm-kernel, linux-clk, linux-kernel, mturquette,
s.hauer, shawnguo, Anson Huang, Fabio Estevam, Peng Fan,
Rob Herring
Cc: dl-linux-imx
Quoting Peng Fan (2018-08-12 18:15:41)
> Hi Anson,
> =
> > > > -----Original Message-----
> > > > From: Anson Huang
> > > > Sent: 2018=E5=B9=B48=E6=9C=888=E6=97=A5 12:39
> > > > To: shawnguo@kernel.org; s.hauer@pengutronix.de;
> > > > kernel@pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > > > mturquette@baylibre.com; sboyd@kernel.org;
> > > > linux-arm-kernel@lists.infradead.org;
> > > > linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org
> > > > Cc: dl-linux-imx <linux-imx@nxp.com>
> > > > Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> > > >
> > > > Clock framework will enable those clocks registered with
> > > > CLK_IS_CRITICAL flag, so no need to have clks_init_on array during
> > > > clock
> > > initialization now.
> > >
> > > Will it be more flexible to parse dts saying "critical-clocks =3D <xx=
x>"
> > > or "init-on-arrary=3D<xxx>"
> > > and enable those clocks?
> > =
> > Parsing the clocks arrays from dtb is another way of enabling critical =
clocks, but
> > for current i.MX6/7 platforms, we implement it in same way as most of o=
ther
> > SoCs, currently I did NOT see any necessity of putting them in dtb, jus=
t adding
> > flag during clock registering is more simple, if there is any special r=
equirement
> > for different clocks set to be enabled, then we can add support to enab=
le the
> > method of parsing critical-clocks from dtb. Just my two cents.
> =
> Thinking about OP-TEE want to use one device, but it's clocks are registe=
red
> by Linux, because there is no module in Linux side use it, it will shutdo=
wn the clock,
> which cause OP-TEE could not access the device.
> =
> Then people have to modify clk code to add CLK_IS_CRITICAL flag to make s=
ure
> the clocks are not shutdown by Linux.
> =
> However adding a new property in clk node and let driver code parse the d=
ts,
> there is no need to modify clk driver code when OP-TEE needs another devi=
ce clock.
> =
If OP-TEE needs linux to keep things on then why can't the OP-TEE driver
in Linux probe, acquire clocks, and keep the clks enabled forever?
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
2018-08-31 1:29 ` Stephen Boyd
(?)
@ 2018-08-31 1:40 ` Anson Huang
-1 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-08-31 1:40 UTC (permalink / raw)
To: Stephen Boyd, kernel, linux-arm-kernel, linux-clk, linux-kernel,
mturquette, s.hauer, shawnguo, Fabio Estevam, Peng Fan,
Rob Herring
Cc: dl-linux-imx
Hi, Stephen
Anson Huang
Best Regards!
> -----Original Message-----
> From: Stephen Boyd <sboyd@kernel.org>
> Sent: Friday, August 31, 2018 9:29 AM
> To: kernel@pengutronix.de; linux-arm-kernel@lists.infradead.org;
> linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org;
> mturquette@baylibre.com; s.hauer@pengutronix.de; shawnguo@kernel.org;
> Anson Huang <anson.huang@nxp.com>; Fabio Estevam
> <fabio.estevam@nxp.com>; Peng Fan <peng.fan@nxp.com>; Rob Herring
> <robh@kernel.org>
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>
> Quoting Peng Fan (2018-08-12 18:15:41)
> > Hi Anson,
> >
> > > > > -----Original Message-----
> > > > > From: Anson Huang
> > > > > Sent: 2018年8月8日 12:39
> > > > > To: shawnguo@kernel.org; s.hauer@pengutronix.de;
> > > > > kernel@pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > > > > mturquette@baylibre.com; sboyd@kernel.org;
> > > > > linux-arm-kernel@lists.infradead.org;
> > > > > linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org
> > > > > Cc: dl-linux-imx <linux-imx@nxp.com>
> > > > > Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> > > > >
> > > > > Clock framework will enable those clocks registered with
> > > > > CLK_IS_CRITICAL flag, so no need to have clks_init_on array
> > > > > during clock
> > > > initialization now.
> > > >
> > > > Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> > > > or "init-on-arrary=<xxx>"
> > > > and enable those clocks?
> > >
> > > Parsing the clocks arrays from dtb is another way of enabling
> > > critical clocks, but for current i.MX6/7 platforms, we implement it
> > > in same way as most of other SoCs, currently I did NOT see any
> > > necessity of putting them in dtb, just adding flag during clock
> > > registering is more simple, if there is any special requirement for
> > > different clocks set to be enabled, then we can add support to enable the
> method of parsing critical-clocks from dtb. Just my two cents.
> >
> > Thinking about OP-TEE want to use one device, but it's clocks are
> > registered by Linux, because there is no module in Linux side use it,
> > it will shutdown the clock, which cause OP-TEE could not access the device.
> >
> > Then people have to modify clk code to add CLK_IS_CRITICAL flag to
> > make sure the clocks are not shutdown by Linux.
> >
> > However adding a new property in clk node and let driver code parse
> > the dts, there is no need to modify clk driver code when OP-TEE needs
> another device clock.
> >
>
> If OP-TEE needs linux to keep things on then why can't the OP-TEE driver in
> Linux probe, acquire clocks, and keep the clks enabled forever?
Yes, I agree with you, OP-TEE should maintain its clocks when OP-TEE is enabled.
This is ONLY a concern raised by Peng, all platforms' current clock driver does NOT consider
this case, so I think this patch should be fine for now? Thanks.
Anson.
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-08-31 1:40 ` Anson Huang
0 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-08-31 1:40 UTC (permalink / raw)
To: linux-arm-kernel
Hi, Stephen
Anson Huang
Best Regards!
> -----Original Message-----
> From: Stephen Boyd <sboyd@kernel.org>
> Sent: Friday, August 31, 2018 9:29 AM
> To: kernel at pengutronix.de; linux-arm-kernel at lists.infradead.org;
> linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org;
> mturquette at baylibre.com; s.hauer at pengutronix.de; shawnguo at kernel.org;
> Anson Huang <anson.huang@nxp.com>; Fabio Estevam
> <fabio.estevam@nxp.com>; Peng Fan <peng.fan@nxp.com>; Rob Herring
> <robh@kernel.org>
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>
> Quoting Peng Fan (2018-08-12 18:15:41)
> > Hi Anson,
> >
> > > > > -----Original Message-----
> > > > > From: Anson Huang
> > > > > Sent: 2018?8?8? 12:39
> > > > > To: shawnguo at kernel.org; s.hauer at pengutronix.de;
> > > > > kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > > > > mturquette at baylibre.com; sboyd at kernel.org;
> > > > > linux-arm-kernel at lists.infradead.org;
> > > > > linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org
> > > > > Cc: dl-linux-imx <linux-imx@nxp.com>
> > > > > Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> > > > >
> > > > > Clock framework will enable those clocks registered with
> > > > > CLK_IS_CRITICAL flag, so no need to have clks_init_on array
> > > > > during clock
> > > > initialization now.
> > > >
> > > > Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> > > > or "init-on-arrary=<xxx>"
> > > > and enable those clocks?
> > >
> > > Parsing the clocks arrays from dtb is another way of enabling
> > > critical clocks, but for current i.MX6/7 platforms, we implement it
> > > in same way as most of other SoCs, currently I did NOT see any
> > > necessity of putting them in dtb, just adding flag during clock
> > > registering is more simple, if there is any special requirement for
> > > different clocks set to be enabled, then we can add support to enable the
> method of parsing critical-clocks from dtb. Just my two cents.
> >
> > Thinking about OP-TEE want to use one device, but it's clocks are
> > registered by Linux, because there is no module in Linux side use it,
> > it will shutdown the clock, which cause OP-TEE could not access the device.
> >
> > Then people have to modify clk code to add CLK_IS_CRITICAL flag to
> > make sure the clocks are not shutdown by Linux.
> >
> > However adding a new property in clk node and let driver code parse
> > the dts, there is no need to modify clk driver code when OP-TEE needs
> another device clock.
> >
>
> If OP-TEE needs linux to keep things on then why can't the OP-TEE driver in
> Linux probe, acquire clocks, and keep the clks enabled forever?
Yes, I agree with you, OP-TEE should maintain its clocks when OP-TEE is enabled.
This is ONLY a concern raised by Peng, all platforms' current clock driver does NOT consider
this case, so I think this patch should be fine for now? Thanks.
Anson.
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-08-31 1:40 ` Anson Huang
0 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-08-31 1:40 UTC (permalink / raw)
To: Stephen Boyd, kernel, linux-arm-kernel, linux-clk, linux-kernel,
mturquette, s.hauer, shawnguo, Fabio Estevam, Peng Fan,
Rob Herring
Cc: dl-linux-imx
SGksIFN0ZXBoZW4NCg0KQW5zb24gSHVhbmcNCkJlc3QgUmVnYXJkcyENCg0KDQo+IC0tLS0tT3Jp
Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFN0ZXBoZW4gQm95ZCA8c2JveWRAa2VybmVsLm9y
Zz4NCj4gU2VudDogRnJpZGF5LCBBdWd1c3QgMzEsIDIwMTggOToyOSBBTQ0KPiBUbzoga2VybmVs
QHBlbmd1dHJvbml4LmRlOyBsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmc7DQo+
IGxpbnV4LWNsa0B2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7
DQo+IG10dXJxdWV0dGVAYmF5bGlicmUuY29tOyBzLmhhdWVyQHBlbmd1dHJvbml4LmRlOyBzaGF3
bmd1b0BrZXJuZWwub3JnOw0KPiBBbnNvbiBIdWFuZyA8YW5zb24uaHVhbmdAbnhwLmNvbT47IEZh
YmlvIEVzdGV2YW0NCj4gPGZhYmlvLmVzdGV2YW1AbnhwLmNvbT47IFBlbmcgRmFuIDxwZW5nLmZh
bkBueHAuY29tPjsgUm9iIEhlcnJpbmcNCj4gPHJvYmhAa2VybmVsLm9yZz4NCj4gQ2M6IGRsLWxp
bnV4LWlteCA8bGludXgtaW14QG54cC5jb20+DQo+IFN1YmplY3Q6IFJFOiBbUEFUQ0ggMi8yXSBj
bGs6IGlteDogaW14N2Q6IHJlbW92ZSBjbGtzX2luaXRfb24gYXJyYXkNCj4gDQo+IFF1b3Rpbmcg
UGVuZyBGYW4gKDIwMTgtMDgtMTIgMTg6MTU6NDEpDQo+ID4gSGkgQW5zb24sDQo+ID4NCj4gPiA+
ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPiA+IEZyb206IEFuc29uIEh1
YW5nDQo+ID4gPiA+ID4gU2VudDogMjAxOOW5tDjmnIg45pelIDEyOjM5DQo+ID4gPiA+ID4gVG86
IHNoYXduZ3VvQGtlcm5lbC5vcmc7IHMuaGF1ZXJAcGVuZ3V0cm9uaXguZGU7DQo+ID4gPiA+ID4g
a2VybmVsQHBlbmd1dHJvbml4LmRlOyBGYWJpbyBFc3RldmFtIDxmYWJpby5lc3RldmFtQG54cC5j
b20+Ow0KPiA+ID4gPiA+IG10dXJxdWV0dGVAYmF5bGlicmUuY29tOyBzYm95ZEBrZXJuZWwub3Jn
Ow0KPiA+ID4gPiA+IGxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZzsNCj4gPiA+
ID4gPiBsaW51eC1jbGtAdmdlci5rZXJuZWwub3JnOyBsaW51eC1rZXJuZWxAdmdlci5rZXJuZWwu
b3JnDQo+ID4gPiA+ID4gQ2M6IGRsLWxpbnV4LWlteCA8bGludXgtaW14QG54cC5jb20+DQo+ID4g
PiA+ID4gU3ViamVjdDogW1BBVENIIDIvMl0gY2xrOiBpbXg6IGlteDdkOiByZW1vdmUgY2xrc19p
bml0X29uIGFycmF5DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBDbG9jayBmcmFtZXdvcmsgd2lsbCBl
bmFibGUgdGhvc2UgY2xvY2tzIHJlZ2lzdGVyZWQgd2l0aA0KPiA+ID4gPiA+IENMS19JU19DUklU
SUNBTCBmbGFnLCBzbyBubyBuZWVkIHRvIGhhdmUgY2xrc19pbml0X29uIGFycmF5DQo+ID4gPiA+
ID4gZHVyaW5nIGNsb2NrDQo+ID4gPiA+IGluaXRpYWxpemF0aW9uIG5vdy4NCj4gPiA+ID4NCj4g
PiA+ID4gV2lsbCBpdCBiZSBtb3JlIGZsZXhpYmxlIHRvIHBhcnNlIGR0cyBzYXlpbmcgImNyaXRp
Y2FsLWNsb2NrcyA9IDx4eHg+Ig0KPiA+ID4gPiBvciAiaW5pdC1vbi1hcnJhcnk9PHh4eD4iDQo+
ID4gPiA+IGFuZCBlbmFibGUgdGhvc2UgY2xvY2tzPw0KPiA+ID4NCj4gPiA+IFBhcnNpbmcgdGhl
IGNsb2NrcyBhcnJheXMgZnJvbSBkdGIgaXMgYW5vdGhlciB3YXkgb2YgZW5hYmxpbmcNCj4gPiA+
IGNyaXRpY2FsIGNsb2NrcywgYnV0IGZvciBjdXJyZW50IGkuTVg2LzcgcGxhdGZvcm1zLCB3ZSBp
bXBsZW1lbnQgaXQNCj4gPiA+IGluIHNhbWUgd2F5IGFzIG1vc3Qgb2Ygb3RoZXIgU29DcywgY3Vy
cmVudGx5IEkgZGlkIE5PVCBzZWUgYW55DQo+ID4gPiBuZWNlc3NpdHkgb2YgcHV0dGluZyB0aGVt
IGluIGR0YiwganVzdCBhZGRpbmcgZmxhZyBkdXJpbmcgY2xvY2sNCj4gPiA+IHJlZ2lzdGVyaW5n
IGlzIG1vcmUgc2ltcGxlLCBpZiB0aGVyZSBpcyBhbnkgc3BlY2lhbCByZXF1aXJlbWVudCBmb3IN
Cj4gPiA+IGRpZmZlcmVudCBjbG9ja3Mgc2V0IHRvIGJlIGVuYWJsZWQsIHRoZW4gd2UgY2FuIGFk
ZCBzdXBwb3J0IHRvIGVuYWJsZSB0aGUNCj4gbWV0aG9kIG9mIHBhcnNpbmcgY3JpdGljYWwtY2xv
Y2tzIGZyb20gZHRiLiBKdXN0IG15IHR3byBjZW50cy4NCj4gPg0KPiA+IFRoaW5raW5nIGFib3V0
IE9QLVRFRSB3YW50IHRvIHVzZSBvbmUgZGV2aWNlLCBidXQgaXQncyBjbG9ja3MgYXJlDQo+ID4g
cmVnaXN0ZXJlZCBieSBMaW51eCwgYmVjYXVzZSB0aGVyZSBpcyBubyBtb2R1bGUgaW4gTGludXgg
c2lkZSB1c2UgaXQsDQo+ID4gaXQgd2lsbCBzaHV0ZG93biB0aGUgY2xvY2ssIHdoaWNoIGNhdXNl
IE9QLVRFRSBjb3VsZCBub3QgYWNjZXNzIHRoZSBkZXZpY2UuDQo+ID4NCj4gPiBUaGVuIHBlb3Bs
ZSBoYXZlIHRvIG1vZGlmeSBjbGsgY29kZSB0byBhZGQgQ0xLX0lTX0NSSVRJQ0FMIGZsYWcgdG8N
Cj4gPiBtYWtlIHN1cmUgdGhlIGNsb2NrcyBhcmUgbm90IHNodXRkb3duIGJ5IExpbnV4Lg0KPiA+
DQo+ID4gSG93ZXZlciBhZGRpbmcgYSBuZXcgcHJvcGVydHkgaW4gY2xrIG5vZGUgYW5kIGxldCBk
cml2ZXIgY29kZSBwYXJzZQ0KPiA+IHRoZSBkdHMsIHRoZXJlIGlzIG5vIG5lZWQgdG8gbW9kaWZ5
IGNsayBkcml2ZXIgY29kZSB3aGVuIE9QLVRFRSBuZWVkcw0KPiBhbm90aGVyIGRldmljZSBjbG9j
ay4NCj4gPg0KPiANCj4gSWYgT1AtVEVFIG5lZWRzIGxpbnV4IHRvIGtlZXAgdGhpbmdzIG9uIHRo
ZW4gd2h5IGNhbid0IHRoZSBPUC1URUUgZHJpdmVyIGluDQo+IExpbnV4IHByb2JlLCBhY3F1aXJl
IGNsb2NrcywgYW5kIGtlZXAgdGhlIGNsa3MgZW5hYmxlZCBmb3JldmVyPw0KIA0KWWVzLCBJIGFn
cmVlIHdpdGggeW91LCBPUC1URUUgc2hvdWxkIG1haW50YWluIGl0cyBjbG9ja3Mgd2hlbiBPUC1U
RUUgaXMgZW5hYmxlZC4NCg0KVGhpcyBpcyBPTkxZIGEgY29uY2VybiByYWlzZWQgYnkgUGVuZywg
YWxsIHBsYXRmb3JtcycgY3VycmVudCBjbG9jayBkcml2ZXIgZG9lcyBOT1QgY29uc2lkZXINCnRo
aXMgY2FzZSwgc28gSSB0aGluayB0aGlzIHBhdGNoIHNob3VsZCBiZSBmaW5lIGZvciBub3c/IFRo
YW5rcy4NCg0KQW5zb24uDQoNCg0K
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
2018-08-31 1:29 ` Stephen Boyd
(?)
@ 2018-08-31 8:01 ` Jerome Forissier
-1 siblings, 0 replies; 48+ messages in thread
From: Jerome Forissier @ 2018-08-31 8:01 UTC (permalink / raw)
To: Stephen Boyd, kernel, linux-arm-kernel, linux-clk, linux-kernel,
mturquette, s.hauer, shawnguo, Anson Huang, Fabio Estevam,
Peng Fan, Rob Herring
Cc: dl-linux-imx
On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> Quoting Peng Fan (2018-08-12 18:15:41)
>> Hi Anson,
>>
>>>>> -----Original Message-----
>>>>> From: Anson Huang
>>>>> Sent: 2018年8月8日 12:39
>>>>> To: shawnguo@kernel.org; s.hauer@pengutronix.de;
>>>>> kernel@pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
>>>>> mturquette@baylibre.com; sboyd@kernel.org;
>>>>> linux-arm-kernel@lists.infradead.org;
>>>>> linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org
>>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
>>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>>>>>
>>>>> Clock framework will enable those clocks registered with
>>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on array during
>>>>> clock
>>>> initialization now.
>>>>
>>>> Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
>>>> or "init-on-arrary=<xxx>"
>>>> and enable those clocks?
>>>
>>> Parsing the clocks arrays from dtb is another way of enabling critical clocks, but
>>> for current i.MX6/7 platforms, we implement it in same way as most of other
>>> SoCs, currently I did NOT see any necessity of putting them in dtb, just adding
>>> flag during clock registering is more simple, if there is any special requirement
>>> for different clocks set to be enabled, then we can add support to enable the
>>> method of parsing critical-clocks from dtb. Just my two cents.
>>
>> Thinking about OP-TEE want to use one device, but it's clocks are registered
>> by Linux, because there is no module in Linux side use it, it will shutdown the clock,
>> which cause OP-TEE could not access the device.
>>
>> Then people have to modify clk code to add CLK_IS_CRITICAL flag to make sure
>> the clocks are not shutdown by Linux.
>>
>> However adding a new property in clk node and let driver code parse the dts,
>> there is no need to modify clk driver code when OP-TEE needs another device clock.
>>
>
> If OP-TEE needs linux to keep things on then why can't the OP-TEE driver
> in Linux probe, acquire clocks, and keep the clks enabled forever?
Sounds reasonable, but how could this be done without introducing
platform-specific stuff in the OP-TEE driver?
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-08-31 8:01 ` Jerome Forissier
0 siblings, 0 replies; 48+ messages in thread
From: Jerome Forissier @ 2018-08-31 8:01 UTC (permalink / raw)
To: linux-arm-kernel
On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> Quoting Peng Fan (2018-08-12 18:15:41)
>> Hi Anson,
>>
>>>>> -----Original Message-----
>>>>> From: Anson Huang
>>>>> Sent: 2018?8?8? 12:39
>>>>> To: shawnguo at kernel.org; s.hauer at pengutronix.de;
>>>>> kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
>>>>> mturquette at baylibre.com; sboyd at kernel.org;
>>>>> linux-arm-kernel at lists.infradead.org;
>>>>> linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org
>>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
>>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>>>>>
>>>>> Clock framework will enable those clocks registered with
>>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on array during
>>>>> clock
>>>> initialization now.
>>>>
>>>> Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
>>>> or "init-on-arrary=<xxx>"
>>>> and enable those clocks?
>>>
>>> Parsing the clocks arrays from dtb is another way of enabling critical clocks, but
>>> for current i.MX6/7 platforms, we implement it in same way as most of other
>>> SoCs, currently I did NOT see any necessity of putting them in dtb, just adding
>>> flag during clock registering is more simple, if there is any special requirement
>>> for different clocks set to be enabled, then we can add support to enable the
>>> method of parsing critical-clocks from dtb. Just my two cents.
>>
>> Thinking about OP-TEE want to use one device, but it's clocks are registered
>> by Linux, because there is no module in Linux side use it, it will shutdown the clock,
>> which cause OP-TEE could not access the device.
>>
>> Then people have to modify clk code to add CLK_IS_CRITICAL flag to make sure
>> the clocks are not shutdown by Linux.
>>
>> However adding a new property in clk node and let driver code parse the dts,
>> there is no need to modify clk driver code when OP-TEE needs another device clock.
>>
>
> If OP-TEE needs linux to keep things on then why can't the OP-TEE driver
> in Linux probe, acquire clocks, and keep the clks enabled forever?
Sounds reasonable, but how could this be done without introducing
platform-specific stuff in the OP-TEE driver?
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-08-31 8:01 ` Jerome Forissier
0 siblings, 0 replies; 48+ messages in thread
From: Jerome Forissier @ 2018-08-31 8:01 UTC (permalink / raw)
To: Stephen Boyd, kernel, linux-arm-kernel, linux-clk, linux-kernel,
mturquette, s.hauer, shawnguo, Anson Huang, Fabio Estevam,
Peng Fan, Rob Herring
Cc: dl-linux-imx
On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> Quoting Peng Fan (2018-08-12 18:15:41)
>> Hi Anson,
>>
>>>>> -----Original Message-----
>>>>> From: Anson Huang
>>>>> Sent: 2018年8月8日 12:39
>>>>> To: shawnguo@kernel.org; s.hauer@pengutronix.de;
>>>>> kernel@pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
>>>>> mturquette@baylibre.com; sboyd@kernel.org;
>>>>> linux-arm-kernel@lists.infradead.org;
>>>>> linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org
>>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
>>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>>>>>
>>>>> Clock framework will enable those clocks registered with
>>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on array during
>>>>> clock
>>>> initialization now.
>>>>
>>>> Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
>>>> or "init-on-arrary=<xxx>"
>>>> and enable those clocks?
>>>
>>> Parsing the clocks arrays from dtb is another way of enabling critical clocks, but
>>> for current i.MX6/7 platforms, we implement it in same way as most of other
>>> SoCs, currently I did NOT see any necessity of putting them in dtb, just adding
>>> flag during clock registering is more simple, if there is any special requirement
>>> for different clocks set to be enabled, then we can add support to enable the
>>> method of parsing critical-clocks from dtb. Just my two cents.
>>
>> Thinking about OP-TEE want to use one device, but it's clocks are registered
>> by Linux, because there is no module in Linux side use it, it will shutdown the clock,
>> which cause OP-TEE could not access the device.
>>
>> Then people have to modify clk code to add CLK_IS_CRITICAL flag to make sure
>> the clocks are not shutdown by Linux.
>>
>> However adding a new property in clk node and let driver code parse the dts,
>> there is no need to modify clk driver code when OP-TEE needs another device clock.
>>
>
> If OP-TEE needs linux to keep things on then why can't the OP-TEE driver
> in Linux probe, acquire clocks, and keep the clks enabled forever?
Sounds reasonable, but how could this be done without introducing
platform-specific stuff in the OP-TEE driver?
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
2018-08-31 8:01 ` Jerome Forissier
(?)
@ 2018-08-31 17:57 ` Stephen Boyd
-1 siblings, 0 replies; 48+ messages in thread
From: Stephen Boyd @ 2018-08-31 17:57 UTC (permalink / raw)
To: kernel, linux-arm-kernel, linux-clk, linux-kernel, mturquette,
s.hauer, shawnguo, Anson Huang, Fabio Estevam, Jerome Forissier,
Peng Fan, Rob Herring
Cc: dl-linux-imx
Quoting Jerome Forissier (2018-08-31 01:01:44)
>
>
> On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> > Quoting Peng Fan (2018-08-12 18:15:41)
> >> Hi Anson,
> >>
> >>>>> -----Original Message-----
> >>>>> From: Anson Huang
> >>>>> Sent: 2018年8月8日 12:39
> >>>>> To: shawnguo@kernel.org; s.hauer@pengutronix.de;
> >>>>> kernel@pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> >>>>> mturquette@baylibre.com; sboyd@kernel.org;
> >>>>> linux-arm-kernel@lists.infradead.org;
> >>>>> linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org
> >>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
> >>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> >>>>>
> >>>>> Clock framework will enable those clocks registered with
> >>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on array during
> >>>>> clock
> >>>> initialization now.
> >>>>
> >>>> Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> >>>> or "init-on-arrary=<xxx>"
> >>>> and enable those clocks?
> >>>
> >>> Parsing the clocks arrays from dtb is another way of enabling critical clocks, but
> >>> for current i.MX6/7 platforms, we implement it in same way as most of other
> >>> SoCs, currently I did NOT see any necessity of putting them in dtb, just adding
> >>> flag during clock registering is more simple, if there is any special requirement
> >>> for different clocks set to be enabled, then we can add support to enable the
> >>> method of parsing critical-clocks from dtb. Just my two cents.
> >>
> >> Thinking about OP-TEE want to use one device, but it's clocks are registered
> >> by Linux, because there is no module in Linux side use it, it will shutdown the clock,
> >> which cause OP-TEE could not access the device.
> >>
> >> Then people have to modify clk code to add CLK_IS_CRITICAL flag to make sure
> >> the clocks are not shutdown by Linux.
> >>
> >> However adding a new property in clk node and let driver code parse the dts,
> >> there is no need to modify clk driver code when OP-TEE needs another device clock.
> >>
> >
> > If OP-TEE needs linux to keep things on then why can't the OP-TEE driver
> > in Linux probe, acquire clocks, and keep the clks enabled forever?
>
> Sounds reasonable, but how could this be done without introducing
> platform-specific stuff in the OP-TEE driver?
>
Why is that a goal?
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-08-31 17:57 ` Stephen Boyd
0 siblings, 0 replies; 48+ messages in thread
From: Stephen Boyd @ 2018-08-31 17:57 UTC (permalink / raw)
To: linux-arm-kernel
Quoting Jerome Forissier (2018-08-31 01:01:44)
>
>
> On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> > Quoting Peng Fan (2018-08-12 18:15:41)
> >> Hi Anson,
> >>
> >>>>> -----Original Message-----
> >>>>> From: Anson Huang
> >>>>> Sent: 2018?8?8? 12:39
> >>>>> To: shawnguo at kernel.org; s.hauer at pengutronix.de;
> >>>>> kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> >>>>> mturquette at baylibre.com; sboyd at kernel.org;
> >>>>> linux-arm-kernel at lists.infradead.org;
> >>>>> linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org
> >>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
> >>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> >>>>>
> >>>>> Clock framework will enable those clocks registered with
> >>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on array during
> >>>>> clock
> >>>> initialization now.
> >>>>
> >>>> Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> >>>> or "init-on-arrary=<xxx>"
> >>>> and enable those clocks?
> >>>
> >>> Parsing the clocks arrays from dtb is another way of enabling critical clocks, but
> >>> for current i.MX6/7 platforms, we implement it in same way as most of other
> >>> SoCs, currently I did NOT see any necessity of putting them in dtb, just adding
> >>> flag during clock registering is more simple, if there is any special requirement
> >>> for different clocks set to be enabled, then we can add support to enable the
> >>> method of parsing critical-clocks from dtb. Just my two cents.
> >>
> >> Thinking about OP-TEE want to use one device, but it's clocks are registered
> >> by Linux, because there is no module in Linux side use it, it will shutdown the clock,
> >> which cause OP-TEE could not access the device.
> >>
> >> Then people have to modify clk code to add CLK_IS_CRITICAL flag to make sure
> >> the clocks are not shutdown by Linux.
> >>
> >> However adding a new property in clk node and let driver code parse the dts,
> >> there is no need to modify clk driver code when OP-TEE needs another device clock.
> >>
> >
> > If OP-TEE needs linux to keep things on then why can't the OP-TEE driver
> > in Linux probe, acquire clocks, and keep the clks enabled forever?
>
> Sounds reasonable, but how could this be done without introducing
> platform-specific stuff in the OP-TEE driver?
>
Why is that a goal?
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-08-31 17:57 ` Stephen Boyd
0 siblings, 0 replies; 48+ messages in thread
From: Stephen Boyd @ 2018-08-31 17:57 UTC (permalink / raw)
To: kernel, linux-arm-kernel, linux-clk, linux-kernel, mturquette,
s.hauer, shawnguo, Anson Huang, Fabio Estevam, Jerome Forissier,
Peng Fan, Rob Herring
Cc: dl-linux-imx
Quoting Jerome Forissier (2018-08-31 01:01:44)
> =
> =
> On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> > Quoting Peng Fan (2018-08-12 18:15:41)
> >> Hi Anson,
> >>
> >>>>> -----Original Message-----
> >>>>> From: Anson Huang
> >>>>> Sent: 2018=E5=B9=B48=E6=9C=888=E6=97=A5 12:39
> >>>>> To: shawnguo@kernel.org; s.hauer@pengutronix.de;
> >>>>> kernel@pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> >>>>> mturquette@baylibre.com; sboyd@kernel.org;
> >>>>> linux-arm-kernel@lists.infradead.org;
> >>>>> linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org
> >>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
> >>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> >>>>>
> >>>>> Clock framework will enable those clocks registered with
> >>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on array during
> >>>>> clock
> >>>> initialization now.
> >>>>
> >>>> Will it be more flexible to parse dts saying "critical-clocks =3D <x=
xx>"
> >>>> or "init-on-arrary=3D<xxx>"
> >>>> and enable those clocks?
> >>>
> >>> Parsing the clocks arrays from dtb is another way of enabling critica=
l clocks, but
> >>> for current i.MX6/7 platforms, we implement it in same way as most of=
other
> >>> SoCs, currently I did NOT see any necessity of putting them in dtb, j=
ust adding
> >>> flag during clock registering is more simple, if there is any special=
requirement
> >>> for different clocks set to be enabled, then we can add support to en=
able the
> >>> method of parsing critical-clocks from dtb. Just my two cents.
> >>
> >> Thinking about OP-TEE want to use one device, but it's clocks are regi=
stered
> >> by Linux, because there is no module in Linux side use it, it will shu=
tdown the clock,
> >> which cause OP-TEE could not access the device.
> >>
> >> Then people have to modify clk code to add CLK_IS_CRITICAL flag to mak=
e sure
> >> the clocks are not shutdown by Linux.
> >>
> >> However adding a new property in clk node and let driver code parse th=
e dts,
> >> there is no need to modify clk driver code when OP-TEE needs another d=
evice clock.
> >>
> > =
> > If OP-TEE needs linux to keep things on then why can't the OP-TEE driver
> > in Linux probe, acquire clocks, and keep the clks enabled forever?
> =
> Sounds reasonable, but how could this be done without introducing
> platform-specific stuff in the OP-TEE driver?
> =
Why is that a goal?
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
2018-08-31 17:57 ` Stephen Boyd
(?)
@ 2018-09-03 7:20 ` Anson Huang
-1 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-09-03 7:20 UTC (permalink / raw)
To: Stephen Boyd, kernel, linux-arm-kernel, linux-clk, linux-kernel,
mturquette, s.hauer, shawnguo, Fabio Estevam, Jerome Forissier,
Peng Fan, Rob Herring
Cc: dl-linux-imx
Anson Huang
Best Regards!
> -----Original Message-----
> From: Stephen Boyd <sboyd@kernel.org>
> Sent: Saturday, September 1, 2018 1:58 AM
> To: kernel@pengutronix.de; linux-arm-kernel@lists.infradead.org;
> linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org;
> mturquette@baylibre.com; s.hauer@pengutronix.de; shawnguo@kernel.org;
> Anson Huang <anson.huang@nxp.com>; Fabio Estevam
> <fabio.estevam@nxp.com>; Jerome Forissier <jerome.forissier@linaro.org>;
> Peng Fan <peng.fan@nxp.com>; Rob Herring <robh@kernel.org>
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>
> Quoting Jerome Forissier (2018-08-31 01:01:44)
> >
> >
> > On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> > > Quoting Peng Fan (2018-08-12 18:15:41)
> > >> Hi Anson,
> > >>
> > >>>>> -----Original Message-----
> > >>>>> From: Anson Huang
> > >>>>> Sent: 2018年8月8日 12:39
> > >>>>> To: shawnguo@kernel.org; s.hauer@pengutronix.de;
> > >>>>> kernel@pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > >>>>> mturquette@baylibre.com; sboyd@kernel.org;
> > >>>>> linux-arm-kernel@lists.infradead.org;
> > >>>>> linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org
> > >>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
> > >>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> > >>>>>
> > >>>>> Clock framework will enable those clocks registered with
> > >>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on array
> > >>>>> during clock
> > >>>> initialization now.
> > >>>>
> > >>>> Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> > >>>> or "init-on-arrary=<xxx>"
> > >>>> and enable those clocks?
> > >>>
> > >>> Parsing the clocks arrays from dtb is another way of enabling
> > >>> critical clocks, but for current i.MX6/7 platforms, we implement
> > >>> it in same way as most of other SoCs, currently I did NOT see any
> > >>> necessity of putting them in dtb, just adding flag during clock
> > >>> registering is more simple, if there is any special requirement
> > >>> for different clocks set to be enabled, then we can add support to enable
> the method of parsing critical-clocks from dtb. Just my two cents.
> > >>
> > >> Thinking about OP-TEE want to use one device, but it's clocks are
> > >> registered by Linux, because there is no module in Linux side use
> > >> it, it will shutdown the clock, which cause OP-TEE could not access the
> device.
> > >>
> > >> Then people have to modify clk code to add CLK_IS_CRITICAL flag to
> > >> make sure the clocks are not shutdown by Linux.
> > >>
> > >> However adding a new property in clk node and let driver code parse
> > >> the dts, there is no need to modify clk driver code when OP-TEE needs
> another device clock.
> > >>
> > >
> > > If OP-TEE needs linux to keep things on then why can't the OP-TEE
> > > driver in Linux probe, acquire clocks, and keep the clks enabled forever?
> >
> > Sounds reasonable, but how could this be done without introducing
> > platform-specific stuff in the OP-TEE driver?
> >
>
> Why is that a goal?
I do NOT think we should consider such case in this patch series, whatever OP-TEE needs for its own
feature, it should do necessary operations either in its driver or somewhere else by adding new patch.
Anson.
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-09-03 7:20 ` Anson Huang
0 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-09-03 7:20 UTC (permalink / raw)
To: linux-arm-kernel
Anson Huang
Best Regards!
> -----Original Message-----
> From: Stephen Boyd <sboyd@kernel.org>
> Sent: Saturday, September 1, 2018 1:58 AM
> To: kernel at pengutronix.de; linux-arm-kernel at lists.infradead.org;
> linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org;
> mturquette at baylibre.com; s.hauer at pengutronix.de; shawnguo at kernel.org;
> Anson Huang <anson.huang@nxp.com>; Fabio Estevam
> <fabio.estevam@nxp.com>; Jerome Forissier <jerome.forissier@linaro.org>;
> Peng Fan <peng.fan@nxp.com>; Rob Herring <robh@kernel.org>
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: Re: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>
> Quoting Jerome Forissier (2018-08-31 01:01:44)
> >
> >
> > On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> > > Quoting Peng Fan (2018-08-12 18:15:41)
> > >> Hi Anson,
> > >>
> > >>>>> -----Original Message-----
> > >>>>> From: Anson Huang
> > >>>>> Sent: 2018?8?8? 12:39
> > >>>>> To: shawnguo at kernel.org; s.hauer at pengutronix.de;
> > >>>>> kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > >>>>> mturquette at baylibre.com; sboyd at kernel.org;
> > >>>>> linux-arm-kernel at lists.infradead.org;
> > >>>>> linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org
> > >>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
> > >>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> > >>>>>
> > >>>>> Clock framework will enable those clocks registered with
> > >>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on array
> > >>>>> during clock
> > >>>> initialization now.
> > >>>>
> > >>>> Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> > >>>> or "init-on-arrary=<xxx>"
> > >>>> and enable those clocks?
> > >>>
> > >>> Parsing the clocks arrays from dtb is another way of enabling
> > >>> critical clocks, but for current i.MX6/7 platforms, we implement
> > >>> it in same way as most of other SoCs, currently I did NOT see any
> > >>> necessity of putting them in dtb, just adding flag during clock
> > >>> registering is more simple, if there is any special requirement
> > >>> for different clocks set to be enabled, then we can add support to enable
> the method of parsing critical-clocks from dtb. Just my two cents.
> > >>
> > >> Thinking about OP-TEE want to use one device, but it's clocks are
> > >> registered by Linux, because there is no module in Linux side use
> > >> it, it will shutdown the clock, which cause OP-TEE could not access the
> device.
> > >>
> > >> Then people have to modify clk code to add CLK_IS_CRITICAL flag to
> > >> make sure the clocks are not shutdown by Linux.
> > >>
> > >> However adding a new property in clk node and let driver code parse
> > >> the dts, there is no need to modify clk driver code when OP-TEE needs
> another device clock.
> > >>
> > >
> > > If OP-TEE needs linux to keep things on then why can't the OP-TEE
> > > driver in Linux probe, acquire clocks, and keep the clks enabled forever?
> >
> > Sounds reasonable, but how could this be done without introducing
> > platform-specific stuff in the OP-TEE driver?
> >
>
> Why is that a goal?
I do NOT think we should consider such case in this patch series, whatever OP-TEE needs for its own
feature, it should do necessary operations either in its driver or somewhere else by adding new patch.
Anson.
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-09-03 7:20 ` Anson Huang
0 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-09-03 7:20 UTC (permalink / raw)
To: Stephen Boyd, kernel, linux-arm-kernel, linux-clk, linux-kernel,
mturquette, s.hauer, shawnguo, Fabio Estevam, Jerome Forissier,
Peng Fan, Rob Herring
Cc: dl-linux-imx
DQoNCkFuc29uIEh1YW5nDQpCZXN0IFJlZ2FyZHMhDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh
Z2UtLS0tLQ0KPiBGcm9tOiBTdGVwaGVuIEJveWQgPHNib3lkQGtlcm5lbC5vcmc+DQo+IFNlbnQ6
IFNhdHVyZGF5LCBTZXB0ZW1iZXIgMSwgMjAxOCAxOjU4IEFNDQo+IFRvOiBrZXJuZWxAcGVuZ3V0
cm9uaXguZGU7IGxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZzsNCj4gbGludXgt
Y2xrQHZnZXIua2VybmVsLm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZzsNCj4gbXR1
cnF1ZXR0ZUBiYXlsaWJyZS5jb207IHMuaGF1ZXJAcGVuZ3V0cm9uaXguZGU7IHNoYXduZ3VvQGtl
cm5lbC5vcmc7DQo+IEFuc29uIEh1YW5nIDxhbnNvbi5odWFuZ0BueHAuY29tPjsgRmFiaW8gRXN0
ZXZhbQ0KPiA8ZmFiaW8uZXN0ZXZhbUBueHAuY29tPjsgSmVyb21lIEZvcmlzc2llciA8amVyb21l
LmZvcmlzc2llckBsaW5hcm8ub3JnPjsNCj4gUGVuZyBGYW4gPHBlbmcuZmFuQG54cC5jb20+OyBS
b2IgSGVycmluZyA8cm9iaEBrZXJuZWwub3JnPg0KPiBDYzogZGwtbGludXgtaW14IDxsaW51eC1p
bXhAbnhwLmNvbT4NCj4gU3ViamVjdDogUmU6IFtQQVRDSCAyLzJdIGNsazogaW14OiBpbXg3ZDog
cmVtb3ZlIGNsa3NfaW5pdF9vbiBhcnJheQ0KPiANCj4gUXVvdGluZyBKZXJvbWUgRm9yaXNzaWVy
ICgyMDE4LTA4LTMxIDAxOjAxOjQ0KQ0KPiA+DQo+ID4NCj4gPiBPbiAwOC8zMS8yMDE4IDAzOjI5
IEFNLCBTdGVwaGVuIEJveWQgd3JvdGU6DQo+ID4gPiBRdW90aW5nIFBlbmcgRmFuICgyMDE4LTA4
LTEyIDE4OjE1OjQxKQ0KPiA+ID4+IEhpIEFuc29uLA0KPiA+ID4+DQo+ID4gPj4+Pj4gLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+Pj4+PiBGcm9tOiBBbnNvbiBIdWFuZw0KPiA+ID4+
Pj4+IFNlbnQ6IDIwMTjlubQ45pyIOOaXpSAxMjozOQ0KPiA+ID4+Pj4+IFRvOiBzaGF3bmd1b0Br
ZXJuZWwub3JnOyBzLmhhdWVyQHBlbmd1dHJvbml4LmRlOw0KPiA+ID4+Pj4+IGtlcm5lbEBwZW5n
dXRyb25peC5kZTsgRmFiaW8gRXN0ZXZhbSA8ZmFiaW8uZXN0ZXZhbUBueHAuY29tPjsNCj4gPiA+
Pj4+PiBtdHVycXVldHRlQGJheWxpYnJlLmNvbTsgc2JveWRAa2VybmVsLm9yZzsNCj4gPiA+Pj4+
PiBsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmc7DQo+ID4gPj4+Pj4gbGludXgt
Y2xrQHZnZXIua2VybmVsLm9yZzsgbGludXgta2VybmVsQHZnZXIua2VybmVsLm9yZw0KPiA+ID4+
Pj4+IENjOiBkbC1saW51eC1pbXggPGxpbnV4LWlteEBueHAuY29tPg0KPiA+ID4+Pj4+IFN1Ympl
Y3Q6IFtQQVRDSCAyLzJdIGNsazogaW14OiBpbXg3ZDogcmVtb3ZlIGNsa3NfaW5pdF9vbiBhcnJh
eQ0KPiA+ID4+Pj4+DQo+ID4gPj4+Pj4gQ2xvY2sgZnJhbWV3b3JrIHdpbGwgZW5hYmxlIHRob3Nl
IGNsb2NrcyByZWdpc3RlcmVkIHdpdGgNCj4gPiA+Pj4+PiBDTEtfSVNfQ1JJVElDQUwgZmxhZywg
c28gbm8gbmVlZCB0byBoYXZlIGNsa3NfaW5pdF9vbiBhcnJheQ0KPiA+ID4+Pj4+IGR1cmluZyBj
bG9jaw0KPiA+ID4+Pj4gaW5pdGlhbGl6YXRpb24gbm93Lg0KPiA+ID4+Pj4NCj4gPiA+Pj4+IFdp
bGwgaXQgYmUgbW9yZSBmbGV4aWJsZSB0byBwYXJzZSBkdHMgc2F5aW5nICJjcml0aWNhbC1jbG9j
a3MgPSA8eHh4PiINCj4gPiA+Pj4+IG9yICJpbml0LW9uLWFycmFyeT08eHh4PiINCj4gPiA+Pj4+
IGFuZCBlbmFibGUgdGhvc2UgY2xvY2tzPw0KPiA+ID4+Pg0KPiA+ID4+PiBQYXJzaW5nIHRoZSBj
bG9ja3MgYXJyYXlzIGZyb20gZHRiIGlzIGFub3RoZXIgd2F5IG9mIGVuYWJsaW5nDQo+ID4gPj4+
IGNyaXRpY2FsIGNsb2NrcywgYnV0IGZvciBjdXJyZW50IGkuTVg2LzcgcGxhdGZvcm1zLCB3ZSBp
bXBsZW1lbnQNCj4gPiA+Pj4gaXQgaW4gc2FtZSB3YXkgYXMgbW9zdCBvZiBvdGhlciBTb0NzLCBj
dXJyZW50bHkgSSBkaWQgTk9UIHNlZSBhbnkNCj4gPiA+Pj4gbmVjZXNzaXR5IG9mIHB1dHRpbmcg
dGhlbSBpbiBkdGIsIGp1c3QgYWRkaW5nIGZsYWcgZHVyaW5nIGNsb2NrDQo+ID4gPj4+IHJlZ2lz
dGVyaW5nIGlzIG1vcmUgc2ltcGxlLCBpZiB0aGVyZSBpcyBhbnkgc3BlY2lhbCByZXF1aXJlbWVu
dA0KPiA+ID4+PiBmb3IgZGlmZmVyZW50IGNsb2NrcyBzZXQgdG8gYmUgZW5hYmxlZCwgdGhlbiB3
ZSBjYW4gYWRkIHN1cHBvcnQgdG8gZW5hYmxlDQo+IHRoZSBtZXRob2Qgb2YgcGFyc2luZyBjcml0
aWNhbC1jbG9ja3MgZnJvbSBkdGIuIEp1c3QgbXkgdHdvIGNlbnRzLg0KPiA+ID4+DQo+ID4gPj4g
VGhpbmtpbmcgYWJvdXQgT1AtVEVFIHdhbnQgdG8gdXNlIG9uZSBkZXZpY2UsIGJ1dCBpdCdzIGNs
b2NrcyBhcmUNCj4gPiA+PiByZWdpc3RlcmVkIGJ5IExpbnV4LCBiZWNhdXNlIHRoZXJlIGlzIG5v
IG1vZHVsZSBpbiBMaW51eCBzaWRlIHVzZQ0KPiA+ID4+IGl0LCBpdCB3aWxsIHNodXRkb3duIHRo
ZSBjbG9jaywgd2hpY2ggY2F1c2UgT1AtVEVFIGNvdWxkIG5vdCBhY2Nlc3MgdGhlDQo+IGRldmlj
ZS4NCj4gPiA+Pg0KPiA+ID4+IFRoZW4gcGVvcGxlIGhhdmUgdG8gbW9kaWZ5IGNsayBjb2RlIHRv
IGFkZCBDTEtfSVNfQ1JJVElDQUwgZmxhZyB0bw0KPiA+ID4+IG1ha2Ugc3VyZSB0aGUgY2xvY2tz
IGFyZSBub3Qgc2h1dGRvd24gYnkgTGludXguDQo+ID4gPj4NCj4gPiA+PiBIb3dldmVyIGFkZGlu
ZyBhIG5ldyBwcm9wZXJ0eSBpbiBjbGsgbm9kZSBhbmQgbGV0IGRyaXZlciBjb2RlIHBhcnNlDQo+
ID4gPj4gdGhlIGR0cywgdGhlcmUgaXMgbm8gbmVlZCB0byBtb2RpZnkgY2xrIGRyaXZlciBjb2Rl
IHdoZW4gT1AtVEVFIG5lZWRzDQo+IGFub3RoZXIgZGV2aWNlIGNsb2NrLg0KPiA+ID4+DQo+ID4g
Pg0KPiA+ID4gSWYgT1AtVEVFIG5lZWRzIGxpbnV4IHRvIGtlZXAgdGhpbmdzIG9uIHRoZW4gd2h5
IGNhbid0IHRoZSBPUC1URUUNCj4gPiA+IGRyaXZlciBpbiBMaW51eCBwcm9iZSwgYWNxdWlyZSBj
bG9ja3MsIGFuZCBrZWVwIHRoZSBjbGtzIGVuYWJsZWQgZm9yZXZlcj8NCj4gPg0KPiA+IFNvdW5k
cyByZWFzb25hYmxlLCBidXQgaG93IGNvdWxkIHRoaXMgYmUgZG9uZSB3aXRob3V0IGludHJvZHVj
aW5nDQo+ID4gcGxhdGZvcm0tc3BlY2lmaWMgc3R1ZmYgaW4gdGhlIE9QLVRFRSBkcml2ZXI/DQo+
ID4NCj4gDQo+IFdoeSBpcyB0aGF0IGEgZ29hbD8NCiANCkkgZG8gTk9UIHRoaW5rIHdlIHNob3Vs
ZCBjb25zaWRlciBzdWNoIGNhc2UgaW4gdGhpcyBwYXRjaCBzZXJpZXMsIHdoYXRldmVyIE9QLVRF
RSBuZWVkcyBmb3IgaXRzIG93bg0KZmVhdHVyZSwgaXQgc2hvdWxkIGRvIG5lY2Vzc2FyeSBvcGVy
YXRpb25zIGVpdGhlciBpbiBpdHMgZHJpdmVyIG9yIHNvbWV3aGVyZSBlbHNlIGJ5IGFkZGluZyBu
ZXcgcGF0Y2guDQoNCkFuc29uLg0KDQo=
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
2018-09-03 7:20 ` Anson Huang
(?)
@ 2018-09-10 9:18 ` Anson Huang
-1 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-09-10 9:18 UTC (permalink / raw)
To: Stephen Boyd, kernel, linux-arm-kernel, linux-clk, linux-kernel,
mturquette, s.hauer, shawnguo, Fabio Estevam, Jerome Forissier,
Peng Fan, Rob Herring
Cc: dl-linux-imx
Gentle Ping...
Anson Huang
Best Regards!
> -----Original Message-----
> From: Anson Huang
> Sent: Monday, September 3, 2018 3:21 PM
> To: Stephen Boyd <sboyd@kernel.org>; kernel@pengutronix.de;
> linux-arm-kernel@lists.infradead.org; linux-clk@vger.kernel.org;
> linux-kernel@vger.kernel.org; mturquette@baylibre.com;
> s.hauer@pengutronix.de; shawnguo@kernel.org; Fabio Estevam
> <fabio.estevam@nxp.com>; Jerome Forissier <jerome.forissier@linaro.org>;
> Peng Fan <peng.fan@nxp.com>; Rob Herring <robh@kernel.org>
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>
>
>
> Anson Huang
> Best Regards!
>
>
> > -----Original Message-----
> > From: Stephen Boyd <sboyd@kernel.org>
> > Sent: Saturday, September 1, 2018 1:58 AM
> > To: kernel@pengutronix.de; linux-arm-kernel@lists.infradead.org;
> > linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org;
> > mturquette@baylibre.com; s.hauer@pengutronix.de;
> shawnguo@kernel.org;
> > Anson Huang <anson.huang@nxp.com>; Fabio Estevam
> > <fabio.estevam@nxp.com>; Jerome Forissier
> > <jerome.forissier@linaro.org>; Peng Fan <peng.fan@nxp.com>; Rob
> > Herring <robh@kernel.org>
> > Cc: dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> >
> > Quoting Jerome Forissier (2018-08-31 01:01:44)
> > >
> > >
> > > On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> > > > Quoting Peng Fan (2018-08-12 18:15:41)
> > > >> Hi Anson,
> > > >>
> > > >>>>> -----Original Message-----
> > > >>>>> From: Anson Huang
> > > >>>>> Sent: 2018年8月8日 12:39
> > > >>>>> To: shawnguo@kernel.org; s.hauer@pengutronix.de;
> > > >>>>> kernel@pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > > >>>>> mturquette@baylibre.com; sboyd@kernel.org;
> > > >>>>> linux-arm-kernel@lists.infradead.org;
> > > >>>>> linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org
> > > >>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
> > > >>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on
> > > >>>>> array
> > > >>>>>
> > > >>>>> Clock framework will enable those clocks registered with
> > > >>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on array
> > > >>>>> during clock
> > > >>>> initialization now.
> > > >>>>
> > > >>>> Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> > > >>>> or "init-on-arrary=<xxx>"
> > > >>>> and enable those clocks?
> > > >>>
> > > >>> Parsing the clocks arrays from dtb is another way of enabling
> > > >>> critical clocks, but for current i.MX6/7 platforms, we implement
> > > >>> it in same way as most of other SoCs, currently I did NOT see
> > > >>> any necessity of putting them in dtb, just adding flag during
> > > >>> clock registering is more simple, if there is any special
> > > >>> requirement for different clocks set to be enabled, then we can
> > > >>> add support to enable
> > the method of parsing critical-clocks from dtb. Just my two cents.
> > > >>
> > > >> Thinking about OP-TEE want to use one device, but it's clocks are
> > > >> registered by Linux, because there is no module in Linux side use
> > > >> it, it will shutdown the clock, which cause OP-TEE could not
> > > >> access the
> > device.
> > > >>
> > > >> Then people have to modify clk code to add CLK_IS_CRITICAL flag
> > > >> to make sure the clocks are not shutdown by Linux.
> > > >>
> > > >> However adding a new property in clk node and let driver code
> > > >> parse the dts, there is no need to modify clk driver code when
> > > >> OP-TEE needs
> > another device clock.
> > > >>
> > > >
> > > > If OP-TEE needs linux to keep things on then why can't the OP-TEE
> > > > driver in Linux probe, acquire clocks, and keep the clks enabled forever?
> > >
> > > Sounds reasonable, but how could this be done without introducing
> > > platform-specific stuff in the OP-TEE driver?
> > >
> >
> > Why is that a goal?
>
> I do NOT think we should consider such case in this patch series, whatever
> OP-TEE needs for its own feature, it should do necessary operations either in its
> driver or somewhere else by adding new patch.
>
> Anson.
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-09-10 9:18 ` Anson Huang
0 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-09-10 9:18 UTC (permalink / raw)
To: linux-arm-kernel
Gentle Ping...
Anson Huang
Best Regards!
> -----Original Message-----
> From: Anson Huang
> Sent: Monday, September 3, 2018 3:21 PM
> To: Stephen Boyd <sboyd@kernel.org>; kernel at pengutronix.de;
> linux-arm-kernel at lists.infradead.org; linux-clk at vger.kernel.org;
> linux-kernel at vger.kernel.org; mturquette at baylibre.com;
> s.hauer at pengutronix.de; shawnguo at kernel.org; Fabio Estevam
> <fabio.estevam@nxp.com>; Jerome Forissier <jerome.forissier@linaro.org>;
> Peng Fan <peng.fan@nxp.com>; Rob Herring <robh@kernel.org>
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>
>
>
> Anson Huang
> Best Regards!
>
>
> > -----Original Message-----
> > From: Stephen Boyd <sboyd@kernel.org>
> > Sent: Saturday, September 1, 2018 1:58 AM
> > To: kernel at pengutronix.de; linux-arm-kernel at lists.infradead.org;
> > linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org;
> > mturquette at baylibre.com; s.hauer at pengutronix.de;
> shawnguo at kernel.org;
> > Anson Huang <anson.huang@nxp.com>; Fabio Estevam
> > <fabio.estevam@nxp.com>; Jerome Forissier
> > <jerome.forissier@linaro.org>; Peng Fan <peng.fan@nxp.com>; Rob
> > Herring <robh@kernel.org>
> > Cc: dl-linux-imx <linux-imx@nxp.com>
> > Subject: Re: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> >
> > Quoting Jerome Forissier (2018-08-31 01:01:44)
> > >
> > >
> > > On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> > > > Quoting Peng Fan (2018-08-12 18:15:41)
> > > >> Hi Anson,
> > > >>
> > > >>>>> -----Original Message-----
> > > >>>>> From: Anson Huang
> > > >>>>> Sent: 2018?8?8? 12:39
> > > >>>>> To: shawnguo at kernel.org; s.hauer at pengutronix.de;
> > > >>>>> kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > > >>>>> mturquette at baylibre.com; sboyd at kernel.org;
> > > >>>>> linux-arm-kernel at lists.infradead.org;
> > > >>>>> linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org
> > > >>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
> > > >>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on
> > > >>>>> array
> > > >>>>>
> > > >>>>> Clock framework will enable those clocks registered with
> > > >>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on array
> > > >>>>> during clock
> > > >>>> initialization now.
> > > >>>>
> > > >>>> Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> > > >>>> or "init-on-arrary=<xxx>"
> > > >>>> and enable those clocks?
> > > >>>
> > > >>> Parsing the clocks arrays from dtb is another way of enabling
> > > >>> critical clocks, but for current i.MX6/7 platforms, we implement
> > > >>> it in same way as most of other SoCs, currently I did NOT see
> > > >>> any necessity of putting them in dtb, just adding flag during
> > > >>> clock registering is more simple, if there is any special
> > > >>> requirement for different clocks set to be enabled, then we can
> > > >>> add support to enable
> > the method of parsing critical-clocks from dtb. Just my two cents.
> > > >>
> > > >> Thinking about OP-TEE want to use one device, but it's clocks are
> > > >> registered by Linux, because there is no module in Linux side use
> > > >> it, it will shutdown the clock, which cause OP-TEE could not
> > > >> access the
> > device.
> > > >>
> > > >> Then people have to modify clk code to add CLK_IS_CRITICAL flag
> > > >> to make sure the clocks are not shutdown by Linux.
> > > >>
> > > >> However adding a new property in clk node and let driver code
> > > >> parse the dts, there is no need to modify clk driver code when
> > > >> OP-TEE needs
> > another device clock.
> > > >>
> > > >
> > > > If OP-TEE needs linux to keep things on then why can't the OP-TEE
> > > > driver in Linux probe, acquire clocks, and keep the clks enabled forever?
> > >
> > > Sounds reasonable, but how could this be done without introducing
> > > platform-specific stuff in the OP-TEE driver?
> > >
> >
> > Why is that a goal?
>
> I do NOT think we should consider such case in this patch series, whatever
> OP-TEE needs for its own feature, it should do necessary operations either in its
> driver or somewhere else by adding new patch.
>
> Anson.
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-09-10 9:18 ` Anson Huang
0 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-09-10 9:18 UTC (permalink / raw)
To: Stephen Boyd, kernel, linux-arm-kernel, linux-clk, linux-kernel,
mturquette, s.hauer, shawnguo, Fabio Estevam, Jerome Forissier,
Peng Fan, Rob Herring
Cc: dl-linux-imx
R2VudGxlIFBpbmcuLi4NCg0KQW5zb24gSHVhbmcNCkJlc3QgUmVnYXJkcyENCg0KDQo+IC0tLS0t
T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFuc29uIEh1YW5nDQo+IFNlbnQ6IE1vbmRh
eSwgU2VwdGVtYmVyIDMsIDIwMTggMzoyMSBQTQ0KPiBUbzogU3RlcGhlbiBCb3lkIDxzYm95ZEBr
ZXJuZWwub3JnPjsga2VybmVsQHBlbmd1dHJvbml4LmRlOw0KPiBsaW51eC1hcm0ta2VybmVsQGxp
c3RzLmluZnJhZGVhZC5vcmc7IGxpbnV4LWNsa0B2Z2VyLmtlcm5lbC5vcmc7DQo+IGxpbnV4LWtl
cm5lbEB2Z2VyLmtlcm5lbC5vcmc7IG10dXJxdWV0dGVAYmF5bGlicmUuY29tOw0KPiBzLmhhdWVy
QHBlbmd1dHJvbml4LmRlOyBzaGF3bmd1b0BrZXJuZWwub3JnOyBGYWJpbyBFc3RldmFtDQo+IDxm
YWJpby5lc3RldmFtQG54cC5jb20+OyBKZXJvbWUgRm9yaXNzaWVyIDxqZXJvbWUuZm9yaXNzaWVy
QGxpbmFyby5vcmc+Ow0KPiBQZW5nIEZhbiA8cGVuZy5mYW5AbnhwLmNvbT47IFJvYiBIZXJyaW5n
IDxyb2JoQGtlcm5lbC5vcmc+DQo+IENjOiBkbC1saW51eC1pbXggPGxpbnV4LWlteEBueHAuY29t
Pg0KPiBTdWJqZWN0OiBSRTogW1BBVENIIDIvMl0gY2xrOiBpbXg6IGlteDdkOiByZW1vdmUgY2xr
c19pbml0X29uIGFycmF5DQo+IA0KPiANCj4gDQo+IEFuc29uIEh1YW5nDQo+IEJlc3QgUmVnYXJk
cyENCj4gDQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogU3Rl
cGhlbiBCb3lkIDxzYm95ZEBrZXJuZWwub3JnPg0KPiA+IFNlbnQ6IFNhdHVyZGF5LCBTZXB0ZW1i
ZXIgMSwgMjAxOCAxOjU4IEFNDQo+ID4gVG86IGtlcm5lbEBwZW5ndXRyb25peC5kZTsgbGludXgt
YXJtLWtlcm5lbEBsaXN0cy5pbmZyYWRlYWQub3JnOw0KPiA+IGxpbnV4LWNsa0B2Z2VyLmtlcm5l
bC5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmc7DQo+ID4gbXR1cnF1ZXR0ZUBiYXls
aWJyZS5jb207IHMuaGF1ZXJAcGVuZ3V0cm9uaXguZGU7DQo+IHNoYXduZ3VvQGtlcm5lbC5vcmc7
DQo+ID4gQW5zb24gSHVhbmcgPGFuc29uLmh1YW5nQG54cC5jb20+OyBGYWJpbyBFc3RldmFtDQo+
ID4gPGZhYmlvLmVzdGV2YW1AbnhwLmNvbT47IEplcm9tZSBGb3Jpc3NpZXINCj4gPiA8amVyb21l
LmZvcmlzc2llckBsaW5hcm8ub3JnPjsgUGVuZyBGYW4gPHBlbmcuZmFuQG54cC5jb20+OyBSb2IN
Cj4gPiBIZXJyaW5nIDxyb2JoQGtlcm5lbC5vcmc+DQo+ID4gQ2M6IGRsLWxpbnV4LWlteCA8bGlu
dXgtaW14QG54cC5jb20+DQo+ID4gU3ViamVjdDogUmU6IFtQQVRDSCAyLzJdIGNsazogaW14OiBp
bXg3ZDogcmVtb3ZlIGNsa3NfaW5pdF9vbiBhcnJheQ0KPiA+DQo+ID4gUXVvdGluZyBKZXJvbWUg
Rm9yaXNzaWVyICgyMDE4LTA4LTMxIDAxOjAxOjQ0KQ0KPiA+ID4NCj4gPiA+DQo+ID4gPiBPbiAw
OC8zMS8yMDE4IDAzOjI5IEFNLCBTdGVwaGVuIEJveWQgd3JvdGU6DQo+ID4gPiA+IFF1b3Rpbmcg
UGVuZyBGYW4gKDIwMTgtMDgtMTIgMTg6MTU6NDEpDQo+ID4gPiA+PiBIaSBBbnNvbiwNCj4gPiA+
ID4+DQo+ID4gPiA+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gPj4+Pj4g
RnJvbTogQW5zb24gSHVhbmcNCj4gPiA+ID4+Pj4+IFNlbnQ6IDIwMTjlubQ45pyIOOaXpSAxMjoz
OQ0KPiA+ID4gPj4+Pj4gVG86IHNoYXduZ3VvQGtlcm5lbC5vcmc7IHMuaGF1ZXJAcGVuZ3V0cm9u
aXguZGU7DQo+ID4gPiA+Pj4+PiBrZXJuZWxAcGVuZ3V0cm9uaXguZGU7IEZhYmlvIEVzdGV2YW0g
PGZhYmlvLmVzdGV2YW1AbnhwLmNvbT47DQo+ID4gPiA+Pj4+PiBtdHVycXVldHRlQGJheWxpYnJl
LmNvbTsgc2JveWRAa2VybmVsLm9yZzsNCj4gPiA+ID4+Pj4+IGxpbnV4LWFybS1rZXJuZWxAbGlz
dHMuaW5mcmFkZWFkLm9yZzsNCj4gPiA+ID4+Pj4+IGxpbnV4LWNsa0B2Z2VyLmtlcm5lbC5vcmc7
IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5lbC5vcmcNCj4gPiA+ID4+Pj4+IENjOiBkbC1saW51eC1p
bXggPGxpbnV4LWlteEBueHAuY29tPg0KPiA+ID4gPj4+Pj4gU3ViamVjdDogW1BBVENIIDIvMl0g
Y2xrOiBpbXg6IGlteDdkOiByZW1vdmUgY2xrc19pbml0X29uDQo+ID4gPiA+Pj4+PiBhcnJheQ0K
PiA+ID4gPj4+Pj4NCj4gPiA+ID4+Pj4+IENsb2NrIGZyYW1ld29yayB3aWxsIGVuYWJsZSB0aG9z
ZSBjbG9ja3MgcmVnaXN0ZXJlZCB3aXRoDQo+ID4gPiA+Pj4+PiBDTEtfSVNfQ1JJVElDQUwgZmxh
Zywgc28gbm8gbmVlZCB0byBoYXZlIGNsa3NfaW5pdF9vbiBhcnJheQ0KPiA+ID4gPj4+Pj4gZHVy
aW5nIGNsb2NrDQo+ID4gPiA+Pj4+IGluaXRpYWxpemF0aW9uIG5vdy4NCj4gPiA+ID4+Pj4NCj4g
PiA+ID4+Pj4gV2lsbCBpdCBiZSBtb3JlIGZsZXhpYmxlIHRvIHBhcnNlIGR0cyBzYXlpbmcgImNy
aXRpY2FsLWNsb2NrcyA9IDx4eHg+Ig0KPiA+ID4gPj4+PiBvciAiaW5pdC1vbi1hcnJhcnk9PHh4
eD4iDQo+ID4gPiA+Pj4+IGFuZCBlbmFibGUgdGhvc2UgY2xvY2tzPw0KPiA+ID4gPj4+DQo+ID4g
PiA+Pj4gUGFyc2luZyB0aGUgY2xvY2tzIGFycmF5cyBmcm9tIGR0YiBpcyBhbm90aGVyIHdheSBv
ZiBlbmFibGluZw0KPiA+ID4gPj4+IGNyaXRpY2FsIGNsb2NrcywgYnV0IGZvciBjdXJyZW50IGku
TVg2LzcgcGxhdGZvcm1zLCB3ZSBpbXBsZW1lbnQNCj4gPiA+ID4+PiBpdCBpbiBzYW1lIHdheSBh
cyBtb3N0IG9mIG90aGVyIFNvQ3MsIGN1cnJlbnRseSBJIGRpZCBOT1Qgc2VlDQo+ID4gPiA+Pj4g
YW55IG5lY2Vzc2l0eSBvZiBwdXR0aW5nIHRoZW0gaW4gZHRiLCBqdXN0IGFkZGluZyBmbGFnIGR1
cmluZw0KPiA+ID4gPj4+IGNsb2NrIHJlZ2lzdGVyaW5nIGlzIG1vcmUgc2ltcGxlLCBpZiB0aGVy
ZSBpcyBhbnkgc3BlY2lhbA0KPiA+ID4gPj4+IHJlcXVpcmVtZW50IGZvciBkaWZmZXJlbnQgY2xv
Y2tzIHNldCB0byBiZSBlbmFibGVkLCB0aGVuIHdlIGNhbg0KPiA+ID4gPj4+IGFkZCBzdXBwb3J0
IHRvIGVuYWJsZQ0KPiA+IHRoZSBtZXRob2Qgb2YgcGFyc2luZyBjcml0aWNhbC1jbG9ja3MgZnJv
bSBkdGIuIEp1c3QgbXkgdHdvIGNlbnRzLg0KPiA+ID4gPj4NCj4gPiA+ID4+IFRoaW5raW5nIGFi
b3V0IE9QLVRFRSB3YW50IHRvIHVzZSBvbmUgZGV2aWNlLCBidXQgaXQncyBjbG9ja3MgYXJlDQo+
ID4gPiA+PiByZWdpc3RlcmVkIGJ5IExpbnV4LCBiZWNhdXNlIHRoZXJlIGlzIG5vIG1vZHVsZSBp
biBMaW51eCBzaWRlIHVzZQ0KPiA+ID4gPj4gaXQsIGl0IHdpbGwgc2h1dGRvd24gdGhlIGNsb2Nr
LCB3aGljaCBjYXVzZSBPUC1URUUgY291bGQgbm90DQo+ID4gPiA+PiBhY2Nlc3MgdGhlDQo+ID4g
ZGV2aWNlLg0KPiA+ID4gPj4NCj4gPiA+ID4+IFRoZW4gcGVvcGxlIGhhdmUgdG8gbW9kaWZ5IGNs
ayBjb2RlIHRvIGFkZCBDTEtfSVNfQ1JJVElDQUwgZmxhZw0KPiA+ID4gPj4gdG8gbWFrZSBzdXJl
IHRoZSBjbG9ja3MgYXJlIG5vdCBzaHV0ZG93biBieSBMaW51eC4NCj4gPiA+ID4+DQo+ID4gPiA+
PiBIb3dldmVyIGFkZGluZyBhIG5ldyBwcm9wZXJ0eSBpbiBjbGsgbm9kZSBhbmQgbGV0IGRyaXZl
ciBjb2RlDQo+ID4gPiA+PiBwYXJzZSB0aGUgZHRzLCB0aGVyZSBpcyBubyBuZWVkIHRvIG1vZGlm
eSBjbGsgZHJpdmVyIGNvZGUgd2hlbg0KPiA+ID4gPj4gT1AtVEVFIG5lZWRzDQo+ID4gYW5vdGhl
ciBkZXZpY2UgY2xvY2suDQo+ID4gPiA+Pg0KPiA+ID4gPg0KPiA+ID4gPiBJZiBPUC1URUUgbmVl
ZHMgbGludXggdG8ga2VlcCB0aGluZ3Mgb24gdGhlbiB3aHkgY2FuJ3QgdGhlIE9QLVRFRQ0KPiA+
ID4gPiBkcml2ZXIgaW4gTGludXggcHJvYmUsIGFjcXVpcmUgY2xvY2tzLCBhbmQga2VlcCB0aGUg
Y2xrcyBlbmFibGVkIGZvcmV2ZXI/DQo+ID4gPg0KPiA+ID4gU291bmRzIHJlYXNvbmFibGUsIGJ1
dCBob3cgY291bGQgdGhpcyBiZSBkb25lIHdpdGhvdXQgaW50cm9kdWNpbmcNCj4gPiA+IHBsYXRm
b3JtLXNwZWNpZmljIHN0dWZmIGluIHRoZSBPUC1URUUgZHJpdmVyPw0KPiA+ID4NCj4gPg0KPiA+
IFdoeSBpcyB0aGF0IGEgZ29hbD8NCj4gDQo+IEkgZG8gTk9UIHRoaW5rIHdlIHNob3VsZCBjb25z
aWRlciBzdWNoIGNhc2UgaW4gdGhpcyBwYXRjaCBzZXJpZXMsIHdoYXRldmVyDQo+IE9QLVRFRSBu
ZWVkcyBmb3IgaXRzIG93biBmZWF0dXJlLCBpdCBzaG91bGQgZG8gbmVjZXNzYXJ5IG9wZXJhdGlv
bnMgZWl0aGVyIGluIGl0cw0KPiBkcml2ZXIgb3Igc29tZXdoZXJlIGVsc2UgYnkgYWRkaW5nIG5l
dyBwYXRjaC4NCj4gDQo+IEFuc29uLg0KDQo=
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
2018-09-03 7:20 ` Anson Huang
@ 2018-10-08 7:40 ` Stephen Boyd
-1 siblings, 0 replies; 48+ messages in thread
From: Stephen Boyd @ 2018-10-08 7:40 UTC (permalink / raw)
To: kernel, linux-arm-kernel, linux-clk, linux-kernel, mturquette,
s.hauer, shawnguo, Anson Huang, Fabio Estevam, Jerome Forissier,
Peng Fan, Rob Herring
Cc: dl-linux-imx
Quoting Anson Huang (2018-09-03 00:20:53)
> > > On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> > > > Quoting Peng Fan (2018-08-12 18:15:41)
> > > >> Hi Anson,
> > > >>
> > > >>>>> -----Original Message-----
> > > >>>>> From: Anson Huang
> > > >>>>> Sent: 2018年8月8日 12:39
> > > >>>>> To: shawnguo@kernel.org; s.hauer@pengutronix.de;
> > > >>>>> kernel@pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > > >>>>> mturquette@baylibre.com; sboyd@kernel.org;
> > > >>>>> linux-arm-kernel@lists.infradead.org;
> > > >>>>> linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org
> > > >>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
> > > >>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> > > >>>>>
> > > >>>>> Clock framework will enable those clocks registered with
> > > >>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on array
> > > >>>>> during clock
> > > >>>> initialization now.
> > > >>>>
> > > >>>> Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> > > >>>> or "init-on-arrary=<xxx>"
> > > >>>> and enable those clocks?
> > > >>>
> > > >>> Parsing the clocks arrays from dtb is another way of enabling
> > > >>> critical clocks, but for current i.MX6/7 platforms, we implement
> > > >>> it in same way as most of other SoCs, currently I did NOT see any
> > > >>> necessity of putting them in dtb, just adding flag during clock
> > > >>> registering is more simple, if there is any special requirement
> > > >>> for different clocks set to be enabled, then we can add support to enable
> > the method of parsing critical-clocks from dtb. Just my two cents.
> > > >>
> > > >> Thinking about OP-TEE want to use one device, but it's clocks are
> > > >> registered by Linux, because there is no module in Linux side use
> > > >> it, it will shutdown the clock, which cause OP-TEE could not access the
> > device.
> > > >>
> > > >> Then people have to modify clk code to add CLK_IS_CRITICAL flag to
> > > >> make sure the clocks are not shutdown by Linux.
> > > >>
> > > >> However adding a new property in clk node and let driver code parse
> > > >> the dts, there is no need to modify clk driver code when OP-TEE needs
> > another device clock.
> > > >>
> > > >
> > > > If OP-TEE needs linux to keep things on then why can't the OP-TEE
> > > > driver in Linux probe, acquire clocks, and keep the clks enabled forever?
> > >
> > > Sounds reasonable, but how could this be done without introducing
> > > platform-specific stuff in the OP-TEE driver?
> > >
> >
> > Why is that a goal?
>
> I do NOT think we should consider such case in this patch series, whatever OP-TEE needs for its own
> feature, it should do necessary operations either in its driver or somewhere else by adding new patch.
>
Why can't we add clks to the op-tee node in DT's /firmware container?
Then any clks in there can be turned on forever and left enabled by the
linux driver?
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-10-08 7:40 ` Stephen Boyd
0 siblings, 0 replies; 48+ messages in thread
From: Stephen Boyd @ 2018-10-08 7:40 UTC (permalink / raw)
To: linux-arm-kernel
Quoting Anson Huang (2018-09-03 00:20:53)
> > > On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> > > > Quoting Peng Fan (2018-08-12 18:15:41)
> > > >> Hi Anson,
> > > >>
> > > >>>>> -----Original Message-----
> > > >>>>> From: Anson Huang
> > > >>>>> Sent: 2018?8?8? 12:39
> > > >>>>> To: shawnguo at kernel.org; s.hauer at pengutronix.de;
> > > >>>>> kernel at pengutronix.de; Fabio Estevam <fabio.estevam@nxp.com>;
> > > >>>>> mturquette at baylibre.com; sboyd at kernel.org;
> > > >>>>> linux-arm-kernel at lists.infradead.org;
> > > >>>>> linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org
> > > >>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
> > > >>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> > > >>>>>
> > > >>>>> Clock framework will enable those clocks registered with
> > > >>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on array
> > > >>>>> during clock
> > > >>>> initialization now.
> > > >>>>
> > > >>>> Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> > > >>>> or "init-on-arrary=<xxx>"
> > > >>>> and enable those clocks?
> > > >>>
> > > >>> Parsing the clocks arrays from dtb is another way of enabling
> > > >>> critical clocks, but for current i.MX6/7 platforms, we implement
> > > >>> it in same way as most of other SoCs, currently I did NOT see any
> > > >>> necessity of putting them in dtb, just adding flag during clock
> > > >>> registering is more simple, if there is any special requirement
> > > >>> for different clocks set to be enabled, then we can add support to enable
> > the method of parsing critical-clocks from dtb. Just my two cents.
> > > >>
> > > >> Thinking about OP-TEE want to use one device, but it's clocks are
> > > >> registered by Linux, because there is no module in Linux side use
> > > >> it, it will shutdown the clock, which cause OP-TEE could not access the
> > device.
> > > >>
> > > >> Then people have to modify clk code to add CLK_IS_CRITICAL flag to
> > > >> make sure the clocks are not shutdown by Linux.
> > > >>
> > > >> However adding a new property in clk node and let driver code parse
> > > >> the dts, there is no need to modify clk driver code when OP-TEE needs
> > another device clock.
> > > >>
> > > >
> > > > If OP-TEE needs linux to keep things on then why can't the OP-TEE
> > > > driver in Linux probe, acquire clocks, and keep the clks enabled forever?
> > >
> > > Sounds reasonable, but how could this be done without introducing
> > > platform-specific stuff in the OP-TEE driver?
> > >
> >
> > Why is that a goal?
>
> I do NOT think we should consider such case in this patch series, whatever OP-TEE needs for its own
> feature, it should do necessary operations either in its driver or somewhere else by adding new patch.
>
Why can't we add clks to the op-tee node in DT's /firmware container?
Then any clks in there can be turned on forever and left enabled by the
linux driver?
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
2018-10-08 7:40 ` Stephen Boyd
@ 2018-10-08 8:34 ` Anson Huang
-1 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-10-08 8:34 UTC (permalink / raw)
To: Stephen Boyd, kernel, linux-arm-kernel, linux-clk, linux-kernel,
mturquette, s.hauer, shawnguo, Fabio Estevam, Jerome Forissier,
Peng Fan, Rob Herring
Cc: dl-linux-imx
Anson Huang
Best Regards!
> -----Original Message-----
> From: Stephen Boyd <sboyd@kernel.org>
> Sent: Monday, October 8, 2018 3:41 PM
> To: kernel@pengutronix.de; linux-arm-kernel@lists.infradead.org;
> linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org;
> mturquette@baylibre.com; s.hauer@pengutronix.de; shawnguo@kernel.org;
> Anson Huang <anson.huang@nxp.com>; Fabio Estevam
> <fabio.estevam@nxp.com>; Jerome Forissier <jerome.forissier@linaro.org>;
> Peng Fan <peng.fan@nxp.com>; Rob Herring <robh@kernel.org>
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>
> Quoting Anson Huang (2018-09-03 00:20:53)
> > > > On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> > > > > Quoting Peng Fan (2018-08-12 18:15:41)
> > > > >> Hi Anson,
> > > > >>
> > > > >>>>> -----Original Message-----
> > > > >>>>> From: Anson Huang
> > > > >>>>> Sent: 2018年8月8日 12:39
> > > > >>>>> To: shawnguo@kernel.org; s.hauer@pengutronix.de;
> > > > >>>>> kernel@pengutronix.de; Fabio Estevam
> > > > >>>>> <fabio.estevam@nxp.com>; mturquette@baylibre.com;
> > > > >>>>> sboyd@kernel.org; linux-arm-kernel@lists.infradead.org;
> > > > >>>>> linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org
> > > > >>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
> > > > >>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on
> > > > >>>>> array
> > > > >>>>>
> > > > >>>>> Clock framework will enable those clocks registered with
> > > > >>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on array
> > > > >>>>> during clock
> > > > >>>> initialization now.
> > > > >>>>
> > > > >>>> Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> > > > >>>> or "init-on-arrary=<xxx>"
> > > > >>>> and enable those clocks?
> > > > >>>
> > > > >>> Parsing the clocks arrays from dtb is another way of enabling
> > > > >>> critical clocks, but for current i.MX6/7 platforms, we
> > > > >>> implement it in same way as most of other SoCs, currently I
> > > > >>> did NOT see any necessity of putting them in dtb, just adding
> > > > >>> flag during clock registering is more simple, if there is any
> > > > >>> special requirement for different clocks set to be enabled,
> > > > >>> then we can add support to enable
> > > the method of parsing critical-clocks from dtb. Just my two cents.
> > > > >>
> > > > >> Thinking about OP-TEE want to use one device, but it's clocks
> > > > >> are registered by Linux, because there is no module in Linux
> > > > >> side use it, it will shutdown the clock, which cause OP-TEE
> > > > >> could not access the
> > > device.
> > > > >>
> > > > >> Then people have to modify clk code to add CLK_IS_CRITICAL flag
> > > > >> to make sure the clocks are not shutdown by Linux.
> > > > >>
> > > > >> However adding a new property in clk node and let driver code
> > > > >> parse the dts, there is no need to modify clk driver code when
> > > > >> OP-TEE needs
> > > another device clock.
> > > > >>
> > > > >
> > > > > If OP-TEE needs linux to keep things on then why can't the
> > > > > OP-TEE driver in Linux probe, acquire clocks, and keep the clks enabled
> forever?
> > > >
> > > > Sounds reasonable, but how could this be done without introducing
> > > > platform-specific stuff in the OP-TEE driver?
> > > >
> > >
> > > Why is that a goal?
> >
> > I do NOT think we should consider such case in this patch series,
> > whatever OP-TEE needs for its own feature, it should do necessary operations
> either in its driver or somewhere else by adding new patch.
> >
>
> Why can't we add clks to the op-tee node in DT's /firmware container?
> Then any clks in there can be turned on forever and left enabled by the linux
> driver?
I did NOT run op-tee with Linux-next kernel before, can you advise more? And I think if op-tee has such requirement,
can we have another patch to cover it? I believe all other i.MX platforms also have same
requirements if considering op-tee support, so I think it should be another topic, what do you think?
Anson.
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-10-08 8:34 ` Anson Huang
0 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-10-08 8:34 UTC (permalink / raw)
To: linux-arm-kernel
Anson Huang
Best Regards!
> -----Original Message-----
> From: Stephen Boyd <sboyd@kernel.org>
> Sent: Monday, October 8, 2018 3:41 PM
> To: kernel at pengutronix.de; linux-arm-kernel at lists.infradead.org;
> linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org;
> mturquette at baylibre.com; s.hauer at pengutronix.de; shawnguo at kernel.org;
> Anson Huang <anson.huang@nxp.com>; Fabio Estevam
> <fabio.estevam@nxp.com>; Jerome Forissier <jerome.forissier@linaro.org>;
> Peng Fan <peng.fan@nxp.com>; Rob Herring <robh@kernel.org>
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>
> Quoting Anson Huang (2018-09-03 00:20:53)
> > > > On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> > > > > Quoting Peng Fan (2018-08-12 18:15:41)
> > > > >> Hi Anson,
> > > > >>
> > > > >>>>> -----Original Message-----
> > > > >>>>> From: Anson Huang
> > > > >>>>> Sent: 2018?8?8? 12:39
> > > > >>>>> To: shawnguo at kernel.org; s.hauer at pengutronix.de;
> > > > >>>>> kernel at pengutronix.de; Fabio Estevam
> > > > >>>>> <fabio.estevam@nxp.com>; mturquette at baylibre.com;
> > > > >>>>> sboyd at kernel.org; linux-arm-kernel at lists.infradead.org;
> > > > >>>>> linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org
> > > > >>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
> > > > >>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on
> > > > >>>>> array
> > > > >>>>>
> > > > >>>>> Clock framework will enable those clocks registered with
> > > > >>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on array
> > > > >>>>> during clock
> > > > >>>> initialization now.
> > > > >>>>
> > > > >>>> Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> > > > >>>> or "init-on-arrary=<xxx>"
> > > > >>>> and enable those clocks?
> > > > >>>
> > > > >>> Parsing the clocks arrays from dtb is another way of enabling
> > > > >>> critical clocks, but for current i.MX6/7 platforms, we
> > > > >>> implement it in same way as most of other SoCs, currently I
> > > > >>> did NOT see any necessity of putting them in dtb, just adding
> > > > >>> flag during clock registering is more simple, if there is any
> > > > >>> special requirement for different clocks set to be enabled,
> > > > >>> then we can add support to enable
> > > the method of parsing critical-clocks from dtb. Just my two cents.
> > > > >>
> > > > >> Thinking about OP-TEE want to use one device, but it's clocks
> > > > >> are registered by Linux, because there is no module in Linux
> > > > >> side use it, it will shutdown the clock, which cause OP-TEE
> > > > >> could not access the
> > > device.
> > > > >>
> > > > >> Then people have to modify clk code to add CLK_IS_CRITICAL flag
> > > > >> to make sure the clocks are not shutdown by Linux.
> > > > >>
> > > > >> However adding a new property in clk node and let driver code
> > > > >> parse the dts, there is no need to modify clk driver code when
> > > > >> OP-TEE needs
> > > another device clock.
> > > > >>
> > > > >
> > > > > If OP-TEE needs linux to keep things on then why can't the
> > > > > OP-TEE driver in Linux probe, acquire clocks, and keep the clks enabled
> forever?
> > > >
> > > > Sounds reasonable, but how could this be done without introducing
> > > > platform-specific stuff in the OP-TEE driver?
> > > >
> > >
> > > Why is that a goal?
> >
> > I do NOT think we should consider such case in this patch series,
> > whatever OP-TEE needs for its own feature, it should do necessary operations
> either in its driver or somewhere else by adding new patch.
> >
>
> Why can't we add clks to the op-tee node in DT's /firmware container?
> Then any clks in there can be turned on forever and left enabled by the linux
> driver?
I did NOT run op-tee with Linux-next kernel before, can you advise more? And I think if op-tee has such requirement,
can we have another patch to cover it? I believe all other i.MX platforms also have same
requirements if considering op-tee support, so I think it should be another topic, what do you think?
Anson.
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
2018-10-08 8:34 ` Anson Huang
@ 2018-10-12 19:48 ` Stephen Boyd
-1 siblings, 0 replies; 48+ messages in thread
From: Stephen Boyd @ 2018-10-12 19:48 UTC (permalink / raw)
To: kernel, linux-arm-kernel, linux-clk, linux-kernel, mturquette,
s.hauer, shawnguo, Anson Huang, Fabio Estevam, Jerome Forissier,
Peng Fan, Rob Herring
Cc: dl-linux-imx
Quoting Anson Huang (2018-10-08 01:34:59)
> > Quoting Anson Huang (2018-09-03 00:20:53)
> > > > > On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> > > > > > Quoting Peng Fan (2018-08-12 18:15:41)
> > > > > >> Hi Anson,
> > > > > >>
> > > > > >>>>> -----Original Message-----
> > > > > >>>>> From: Anson Huang
> > > > > >>>>> Sent: 2018年8月8日 12:39
> > > > > >>>>> To: shawnguo@kernel.org; s.hauer@pengutronix.de;
> > > > > >>>>> kernel@pengutronix.de; Fabio Estevam
> > > > > >>>>> <fabio.estevam@nxp.com>; mturquette@baylibre.com;
> > > > > >>>>> sboyd@kernel.org; linux-arm-kernel@lists.infradead.org;
> > > > > >>>>> linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org
> > > > > >>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
> > > > > >>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on
> > > > > >>>>> array
> > > > > >>>>>
> > > > > >>>>> Clock framework will enable those clocks registered with
> > > > > >>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on array
> > > > > >>>>> during clock
> > > > > >>>> initialization now.
> > > > > >>>>
> > > > > >>>> Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> > > > > >>>> or "init-on-arrary=<xxx>"
> > > > > >>>> and enable those clocks?
> > > > > >>>
> > > > > >>> Parsing the clocks arrays from dtb is another way of enabling
> > > > > >>> critical clocks, but for current i.MX6/7 platforms, we
> > > > > >>> implement it in same way as most of other SoCs, currently I
> > > > > >>> did NOT see any necessity of putting them in dtb, just adding
> > > > > >>> flag during clock registering is more simple, if there is any
> > > > > >>> special requirement for different clocks set to be enabled,
> > > > > >>> then we can add support to enable
> > > > the method of parsing critical-clocks from dtb. Just my two cents.
> > > > > >>
> > > > > >> Thinking about OP-TEE want to use one device, but it's clocks
> > > > > >> are registered by Linux, because there is no module in Linux
> > > > > >> side use it, it will shutdown the clock, which cause OP-TEE
> > > > > >> could not access the
> > > > device.
> > > > > >>
> > > > > >> Then people have to modify clk code to add CLK_IS_CRITICAL flag
> > > > > >> to make sure the clocks are not shutdown by Linux.
> > > > > >>
> > > > > >> However adding a new property in clk node and let driver code
> > > > > >> parse the dts, there is no need to modify clk driver code when
> > > > > >> OP-TEE needs
> > > > another device clock.
> > > > > >>
> > > > > >
> > > > > > If OP-TEE needs linux to keep things on then why can't the
> > > > > > OP-TEE driver in Linux probe, acquire clocks, and keep the clks enabled
> > forever?
> > > > >
> > > > > Sounds reasonable, but how could this be done without introducing
> > > > > platform-specific stuff in the OP-TEE driver?
> > > > >
> > > >
> > > > Why is that a goal?
> > >
> > > I do NOT think we should consider such case in this patch series,
> > > whatever OP-TEE needs for its own feature, it should do necessary operations
> > either in its driver or somewhere else by adding new patch.
> > >
> >
> > Why can't we add clks to the op-tee node in DT's /firmware container?
> > Then any clks in there can be turned on forever and left enabled by the linux
> > driver?
>
> I did NOT run op-tee with Linux-next kernel before, can you advise more?
Neither have I, so I can't advise more.
> And I think if op-tee has such requirement,
> can we have another patch to cover it?
Yes.
> I believe all other i.MX platforms also have same
> requirements if considering op-tee support, so I think it should be another topic, what do you think?
>
I'm going to drop these patches from my review queue. Please resend them
and please include the op-tee patches too.
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-10-12 19:48 ` Stephen Boyd
0 siblings, 0 replies; 48+ messages in thread
From: Stephen Boyd @ 2018-10-12 19:48 UTC (permalink / raw)
To: linux-arm-kernel
Quoting Anson Huang (2018-10-08 01:34:59)
> > Quoting Anson Huang (2018-09-03 00:20:53)
> > > > > On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> > > > > > Quoting Peng Fan (2018-08-12 18:15:41)
> > > > > >> Hi Anson,
> > > > > >>
> > > > > >>>>> -----Original Message-----
> > > > > >>>>> From: Anson Huang
> > > > > >>>>> Sent: 2018?8?8? 12:39
> > > > > >>>>> To: shawnguo at kernel.org; s.hauer at pengutronix.de;
> > > > > >>>>> kernel at pengutronix.de; Fabio Estevam
> > > > > >>>>> <fabio.estevam@nxp.com>; mturquette at baylibre.com;
> > > > > >>>>> sboyd at kernel.org; linux-arm-kernel at lists.infradead.org;
> > > > > >>>>> linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org
> > > > > >>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
> > > > > >>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on
> > > > > >>>>> array
> > > > > >>>>>
> > > > > >>>>> Clock framework will enable those clocks registered with
> > > > > >>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on array
> > > > > >>>>> during clock
> > > > > >>>> initialization now.
> > > > > >>>>
> > > > > >>>> Will it be more flexible to parse dts saying "critical-clocks = <xxx>"
> > > > > >>>> or "init-on-arrary=<xxx>"
> > > > > >>>> and enable those clocks?
> > > > > >>>
> > > > > >>> Parsing the clocks arrays from dtb is another way of enabling
> > > > > >>> critical clocks, but for current i.MX6/7 platforms, we
> > > > > >>> implement it in same way as most of other SoCs, currently I
> > > > > >>> did NOT see any necessity of putting them in dtb, just adding
> > > > > >>> flag during clock registering is more simple, if there is any
> > > > > >>> special requirement for different clocks set to be enabled,
> > > > > >>> then we can add support to enable
> > > > the method of parsing critical-clocks from dtb. Just my two cents.
> > > > > >>
> > > > > >> Thinking about OP-TEE want to use one device, but it's clocks
> > > > > >> are registered by Linux, because there is no module in Linux
> > > > > >> side use it, it will shutdown the clock, which cause OP-TEE
> > > > > >> could not access the
> > > > device.
> > > > > >>
> > > > > >> Then people have to modify clk code to add CLK_IS_CRITICAL flag
> > > > > >> to make sure the clocks are not shutdown by Linux.
> > > > > >>
> > > > > >> However adding a new property in clk node and let driver code
> > > > > >> parse the dts, there is no need to modify clk driver code when
> > > > > >> OP-TEE needs
> > > > another device clock.
> > > > > >>
> > > > > >
> > > > > > If OP-TEE needs linux to keep things on then why can't the
> > > > > > OP-TEE driver in Linux probe, acquire clocks, and keep the clks enabled
> > forever?
> > > > >
> > > > > Sounds reasonable, but how could this be done without introducing
> > > > > platform-specific stuff in the OP-TEE driver?
> > > > >
> > > >
> > > > Why is that a goal?
> > >
> > > I do NOT think we should consider such case in this patch series,
> > > whatever OP-TEE needs for its own feature, it should do necessary operations
> > either in its driver or somewhere else by adding new patch.
> > >
> >
> > Why can't we add clks to the op-tee node in DT's /firmware container?
> > Then any clks in there can be turned on forever and left enabled by the linux
> > driver?
>
> I did NOT run op-tee with Linux-next kernel before, can you advise more?
Neither have I, so I can't advise more.
> And I think if op-tee has such requirement,
> can we have another patch to cover it?
Yes.
> I believe all other i.MX platforms also have same
> requirements if considering op-tee support, so I think it should be another topic, what do you think?
>
I'm going to drop these patches from my review queue. Please resend them
and please include the op-tee patches too.
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
2018-10-12 19:48 ` Stephen Boyd
@ 2018-10-15 9:33 ` Anson Huang
-1 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-10-15 9:33 UTC (permalink / raw)
To: Stephen Boyd, kernel, linux-arm-kernel, linux-clk, linux-kernel,
mturquette, s.hauer, shawnguo, Fabio Estevam, Jerome Forissier,
Peng Fan, Rob Herring
Cc: dl-linux-imx
Hi, Stephen
Anson Huang
Best Regards!
> -----Original Message-----
> From: Stephen Boyd <sboyd@kernel.org>
> Sent: Saturday, October 13, 2018 3:48 AM
> To: kernel@pengutronix.de; linux-arm-kernel@lists.infradead.org;
> linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org;
> mturquette@baylibre.com; s.hauer@pengutronix.de; shawnguo@kernel.org;
> Anson Huang <anson.huang@nxp.com>; Fabio Estevam
> <fabio.estevam@nxp.com>; Jerome Forissier <jerome.forissier@linaro.org>;
> Peng Fan <peng.fan@nxp.com>; Rob Herring <robh@kernel.org>
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>
> Quoting Anson Huang (2018-10-08 01:34:59)
> > > Quoting Anson Huang (2018-09-03 00:20:53)
> > > > > > On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> > > > > > > Quoting Peng Fan (2018-08-12 18:15:41)
> > > > > > >> Hi Anson,
> > > > > > >>
> > > > > > >>>>> -----Original Message-----
> > > > > > >>>>> From: Anson Huang
> > > > > > >>>>> Sent: 2018年8月8日 12:39
> > > > > > >>>>> To: shawnguo@kernel.org; s.hauer@pengutronix.de;
> > > > > > >>>>> kernel@pengutronix.de; Fabio Estevam
> > > > > > >>>>> <fabio.estevam@nxp.com>; mturquette@baylibre.com;
> > > > > > >>>>> sboyd@kernel.org; linux-arm-kernel@lists.infradead.org;
> > > > > > >>>>> linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org
> > > > > > >>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
> > > > > > >>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove
> > > > > > >>>>> clks_init_on array
> > > > > > >>>>>
> > > > > > >>>>> Clock framework will enable those clocks registered with
> > > > > > >>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on
> > > > > > >>>>> array during clock
> > > > > > >>>> initialization now.
> > > > > > >>>>
> > > > > > >>>> Will it be more flexible to parse dts saying "critical-clocks =
> <xxx>"
> > > > > > >>>> or "init-on-arrary=<xxx>"
> > > > > > >>>> and enable those clocks?
> > > > > > >>>
> > > > > > >>> Parsing the clocks arrays from dtb is another way of
> > > > > > >>> enabling critical clocks, but for current i.MX6/7
> > > > > > >>> platforms, we implement it in same way as most of other
> > > > > > >>> SoCs, currently I did NOT see any necessity of putting
> > > > > > >>> them in dtb, just adding flag during clock registering is
> > > > > > >>> more simple, if there is any special requirement for
> > > > > > >>> different clocks set to be enabled, then we can add
> > > > > > >>> support to enable
> > > > > the method of parsing critical-clocks from dtb. Just my two cents.
> > > > > > >>
> > > > > > >> Thinking about OP-TEE want to use one device, but it's
> > > > > > >> clocks are registered by Linux, because there is no module
> > > > > > >> in Linux side use it, it will shutdown the clock, which
> > > > > > >> cause OP-TEE could not access the
> > > > > device.
> > > > > > >>
> > > > > > >> Then people have to modify clk code to add CLK_IS_CRITICAL
> > > > > > >> flag to make sure the clocks are not shutdown by Linux.
> > > > > > >>
> > > > > > >> However adding a new property in clk node and let driver
> > > > > > >> code parse the dts, there is no need to modify clk driver
> > > > > > >> code when OP-TEE needs
> > > > > another device clock.
> > > > > > >>
> > > > > > >
> > > > > > > If OP-TEE needs linux to keep things on then why can't the
> > > > > > > OP-TEE driver in Linux probe, acquire clocks, and keep the
> > > > > > > clks enabled
> > > forever?
> > > > > >
> > > > > > Sounds reasonable, but how could this be done without
> > > > > > introducing platform-specific stuff in the OP-TEE driver?
> > > > > >
> > > > >
> > > > > Why is that a goal?
> > > >
> > > > I do NOT think we should consider such case in this patch series,
> > > > whatever OP-TEE needs for its own feature, it should do necessary
> > > > operations
> > > either in its driver or somewhere else by adding new patch.
> > > >
> > >
> > > Why can't we add clks to the op-tee node in DT's /firmware container?
> > > Then any clks in there can be turned on forever and left enabled by
> > > the linux driver?
> >
> > I did NOT run op-tee with Linux-next kernel before, can you advise more?
>
> Neither have I, so I can't advise more.
>
> > And I think if op-tee has such requirement, can we have another patch
> > to cover it?
>
> Yes.
>
>
> > I believe all other i.MX platforms also have same requirements if
> > considering op-tee support, so I think it should be another topic, what do you
> think?
> >
>
> I'm going to drop these patches from my review queue. Please resend them
> and please include the op-tee patches too.
I do NOT know how to include the op-tee patch to meet special requirement, should
the op-tee related patch be added later when someone actually add the op-tee support for i.MX7?
It should NOT block this patch set, do you think we can add this patch set first?
Anson.
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-10-15 9:33 ` Anson Huang
0 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-10-15 9:33 UTC (permalink / raw)
To: linux-arm-kernel
Hi, Stephen
Anson Huang
Best Regards!
> -----Original Message-----
> From: Stephen Boyd <sboyd@kernel.org>
> Sent: Saturday, October 13, 2018 3:48 AM
> To: kernel at pengutronix.de; linux-arm-kernel at lists.infradead.org;
> linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org;
> mturquette at baylibre.com; s.hauer at pengutronix.de; shawnguo at kernel.org;
> Anson Huang <anson.huang@nxp.com>; Fabio Estevam
> <fabio.estevam@nxp.com>; Jerome Forissier <jerome.forissier@linaro.org>;
> Peng Fan <peng.fan@nxp.com>; Rob Herring <robh@kernel.org>
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>
> Quoting Anson Huang (2018-10-08 01:34:59)
> > > Quoting Anson Huang (2018-09-03 00:20:53)
> > > > > > On 08/31/2018 03:29 AM, Stephen Boyd wrote:
> > > > > > > Quoting Peng Fan (2018-08-12 18:15:41)
> > > > > > >> Hi Anson,
> > > > > > >>
> > > > > > >>>>> -----Original Message-----
> > > > > > >>>>> From: Anson Huang
> > > > > > >>>>> Sent: 2018?8?8? 12:39
> > > > > > >>>>> To: shawnguo at kernel.org; s.hauer at pengutronix.de;
> > > > > > >>>>> kernel at pengutronix.de; Fabio Estevam
> > > > > > >>>>> <fabio.estevam@nxp.com>; mturquette at baylibre.com;
> > > > > > >>>>> sboyd at kernel.org; linux-arm-kernel at lists.infradead.org;
> > > > > > >>>>> linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org
> > > > > > >>>>> Cc: dl-linux-imx <linux-imx@nxp.com>
> > > > > > >>>>> Subject: [PATCH 2/2] clk: imx: imx7d: remove
> > > > > > >>>>> clks_init_on array
> > > > > > >>>>>
> > > > > > >>>>> Clock framework will enable those clocks registered with
> > > > > > >>>>> CLK_IS_CRITICAL flag, so no need to have clks_init_on
> > > > > > >>>>> array during clock
> > > > > > >>>> initialization now.
> > > > > > >>>>
> > > > > > >>>> Will it be more flexible to parse dts saying "critical-clocks =
> <xxx>"
> > > > > > >>>> or "init-on-arrary=<xxx>"
> > > > > > >>>> and enable those clocks?
> > > > > > >>>
> > > > > > >>> Parsing the clocks arrays from dtb is another way of
> > > > > > >>> enabling critical clocks, but for current i.MX6/7
> > > > > > >>> platforms, we implement it in same way as most of other
> > > > > > >>> SoCs, currently I did NOT see any necessity of putting
> > > > > > >>> them in dtb, just adding flag during clock registering is
> > > > > > >>> more simple, if there is any special requirement for
> > > > > > >>> different clocks set to be enabled, then we can add
> > > > > > >>> support to enable
> > > > > the method of parsing critical-clocks from dtb. Just my two cents.
> > > > > > >>
> > > > > > >> Thinking about OP-TEE want to use one device, but it's
> > > > > > >> clocks are registered by Linux, because there is no module
> > > > > > >> in Linux side use it, it will shutdown the clock, which
> > > > > > >> cause OP-TEE could not access the
> > > > > device.
> > > > > > >>
> > > > > > >> Then people have to modify clk code to add CLK_IS_CRITICAL
> > > > > > >> flag to make sure the clocks are not shutdown by Linux.
> > > > > > >>
> > > > > > >> However adding a new property in clk node and let driver
> > > > > > >> code parse the dts, there is no need to modify clk driver
> > > > > > >> code when OP-TEE needs
> > > > > another device clock.
> > > > > > >>
> > > > > > >
> > > > > > > If OP-TEE needs linux to keep things on then why can't the
> > > > > > > OP-TEE driver in Linux probe, acquire clocks, and keep the
> > > > > > > clks enabled
> > > forever?
> > > > > >
> > > > > > Sounds reasonable, but how could this be done without
> > > > > > introducing platform-specific stuff in the OP-TEE driver?
> > > > > >
> > > > >
> > > > > Why is that a goal?
> > > >
> > > > I do NOT think we should consider such case in this patch series,
> > > > whatever OP-TEE needs for its own feature, it should do necessary
> > > > operations
> > > either in its driver or somewhere else by adding new patch.
> > > >
> > >
> > > Why can't we add clks to the op-tee node in DT's /firmware container?
> > > Then any clks in there can be turned on forever and left enabled by
> > > the linux driver?
> >
> > I did NOT run op-tee with Linux-next kernel before, can you advise more?
>
> Neither have I, so I can't advise more.
>
> > And I think if op-tee has such requirement, can we have another patch
> > to cover it?
>
> Yes.
>
>
> > I believe all other i.MX platforms also have same requirements if
> > considering op-tee support, so I think it should be another topic, what do you
> think?
> >
>
> I'm going to drop these patches from my review queue. Please resend them
> and please include the op-tee patches too.
I do NOT know how to include the op-tee patch to meet special requirement, should
the op-tee related patch be added later when someone actually add the op-tee support for i.MX7?
It should NOT block this patch set, do you think we can add this patch set first?
Anson.
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
2018-10-15 9:33 ` Anson Huang
@ 2018-10-15 16:45 ` Stephen Boyd
-1 siblings, 0 replies; 48+ messages in thread
From: Stephen Boyd @ 2018-10-15 16:45 UTC (permalink / raw)
To: kernel, linux-arm-kernel, linux-clk, linux-kernel, mturquette,
s.hauer, shawnguo, Anson Huang, Fabio Estevam, Jerome Forissier,
Peng Fan, Rob Herring
Cc: dl-linux-imx
Quoting Anson Huang (2018-10-15 02:33:35)
> > > > >
> > > >
> > > > Why can't we add clks to the op-tee node in DT's /firmware container?
> > > > Then any clks in there can be turned on forever and left enabled by
> > > > the linux driver?
> > >
> > > I did NOT run op-tee with Linux-next kernel before, can you advise more?
> >
> > Neither have I, so I can't advise more.
> >
> > > And I think if op-tee has such requirement, can we have another patch
> > > to cover it?
> >
> > Yes.
> >
> >
> > > I believe all other i.MX platforms also have same requirements if
> > > considering op-tee support, so I think it should be another topic, what do you
> > think?
> > >
> >
> > I'm going to drop these patches from my review queue. Please resend them
> > and please include the op-tee patches too.
>
>
> I do NOT know how to include the op-tee patch to meet special requirement, should
> the op-tee related patch be added later when someone actually add the op-tee support for i.MX7?
> It should NOT block this patch set, do you think we can add this patch set first?
>
Please resend the two patches. In the commit text for the second patch,
describe the plan to remove CLK_IS_CRITICAL from these clks by adding an
OP-TEE device/driver to the kernel to keep these clks enabled. My
understanding is that there isn't an OP-TEE driver right now, but these
clks are used by the firmware and can't be turned off in Linux. If in
the future we want to be able to turn them on and off, we'll need to add
them to an OP-TEE device node and have that driver manage the clks.
How that will work when a system doesn't enable the OP-TEE driver I'm
not sure. We may need to develop some system whereby clks like this are
handed from the clk controller to the consumer driver when it's enabled
for further power managment, but if they're never handed off, they're
kept on forever like is done here. Anyway, please resend with a note
about why these are marked CLK_IS_CRITICAL.
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-10-15 16:45 ` Stephen Boyd
0 siblings, 0 replies; 48+ messages in thread
From: Stephen Boyd @ 2018-10-15 16:45 UTC (permalink / raw)
To: linux-arm-kernel
Quoting Anson Huang (2018-10-15 02:33:35)
> > > > >
> > > >
> > > > Why can't we add clks to the op-tee node in DT's /firmware container?
> > > > Then any clks in there can be turned on forever and left enabled by
> > > > the linux driver?
> > >
> > > I did NOT run op-tee with Linux-next kernel before, can you advise more?
> >
> > Neither have I, so I can't advise more.
> >
> > > And I think if op-tee has such requirement, can we have another patch
> > > to cover it?
> >
> > Yes.
> >
> >
> > > I believe all other i.MX platforms also have same requirements if
> > > considering op-tee support, so I think it should be another topic, what do you
> > think?
> > >
> >
> > I'm going to drop these patches from my review queue. Please resend them
> > and please include the op-tee patches too.
>
>
> I do NOT know how to include the op-tee patch to meet special requirement, should
> the op-tee related patch be added later when someone actually add the op-tee support for i.MX7?
> It should NOT block this patch set, do you think we can add this patch set first?
>
Please resend the two patches. In the commit text for the second patch,
describe the plan to remove CLK_IS_CRITICAL from these clks by adding an
OP-TEE device/driver to the kernel to keep these clks enabled. My
understanding is that there isn't an OP-TEE driver right now, but these
clks are used by the firmware and can't be turned off in Linux. If in
the future we want to be able to turn them on and off, we'll need to add
them to an OP-TEE device node and have that driver manage the clks.
How that will work when a system doesn't enable the OP-TEE driver I'm
not sure. We may need to develop some system whereby clks like this are
handed from the clk controller to the consumer driver when it's enabled
for further power managment, but if they're never handed off, they're
kept on forever like is done here. Anyway, please resend with a note
about why these are marked CLK_IS_CRITICAL.
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
2018-10-15 16:45 ` Stephen Boyd
@ 2018-10-16 4:37 ` Anson Huang
-1 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-10-16 4:37 UTC (permalink / raw)
To: Stephen Boyd, kernel, linux-arm-kernel, linux-clk, linux-kernel,
mturquette, s.hauer, shawnguo, Fabio Estevam, Jerome Forissier,
Peng Fan, Rob Herring
Cc: dl-linux-imx
Hi, Stephen
Anson Huang
Best Regards!
> -----Original Message-----
> From: Stephen Boyd <sboyd@kernel.org>
> Sent: Tuesday, October 16, 2018 12:46 AM
> To: kernel@pengutronix.de; linux-arm-kernel@lists.infradead.org;
> linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org;
> mturquette@baylibre.com; s.hauer@pengutronix.de; shawnguo@kernel.org;
> Anson Huang <anson.huang@nxp.com>; Fabio Estevam
> <fabio.estevam@nxp.com>; Jerome Forissier <jerome.forissier@linaro.org>;
> Peng Fan <peng.fan@nxp.com>; Rob Herring <robh@kernel.org>
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>
> Quoting Anson Huang (2018-10-15 02:33:35)
> > > > > >
> > > > >
> > > > > Why can't we add clks to the op-tee node in DT's /firmware container?
> > > > > Then any clks in there can be turned on forever and left enabled
> > > > > by the linux driver?
> > > >
> > > > I did NOT run op-tee with Linux-next kernel before, can you advise more?
> > >
> > > Neither have I, so I can't advise more.
> > >
> > > > And I think if op-tee has such requirement, can we have another
> > > > patch to cover it?
> > >
> > > Yes.
> > >
> > >
> > > > I believe all other i.MX platforms also have same requirements if
> > > > considering op-tee support, so I think it should be another topic,
> > > > what do you
> > > think?
> > > >
> > >
> > > I'm going to drop these patches from my review queue. Please resend
> > > them and please include the op-tee patches too.
> >
> >
> > I do NOT know how to include the op-tee patch to meet special
> > requirement, should the op-tee related patch be added later when someone
> actually add the op-tee support for i.MX7?
> > It should NOT block this patch set, do you think we can add this patch set
> first?
> >
>
> Please resend the two patches. In the commit text for the second patch,
> describe the plan to remove CLK_IS_CRITICAL from these clks by adding an
> OP-TEE device/driver to the kernel to keep these clks enabled. My
> understanding is that there isn't an OP-TEE driver right now, but these clks are
> used by the firmware and can't be turned off in Linux. If in the future we want
> to be able to turn them on and off, we'll need to add them to an OP-TEE device
> node and have that driver manage the clks.
>
> How that will work when a system doesn't enable the OP-TEE driver I'm not
> sure. We may need to develop some system whereby clks like this are handed
> from the clk controller to the consumer driver when it's enabled for further
> power managment, but if they're never handed off, they're kept on forever like
> is done here. Anyway, please resend with a note about why these are marked
> CLK_IS_CRITICAL.
I think there is some misunderstanding here, this patch sets those critical clocks
with CLK_IS_CRITICAL flag to let clock driver keep them always ON, as they are
critical clocks and system (Linux kernel, NOT include op-tee) can NOT run normally
if anyone of them is OFF.
The question about op-tee is, there might be some special clocks needed by op-tee,
for example, currently clk A, B and C are kept always ON for Linux kernel to run normally,
but when op-tee is executing, it might need clk D to be ON, so I think the clk D is needed
ONLY for op-tee, op-tee should have a driver or firmware to runtime ON/OFF clk D as needed.
Since I do NOT know what clocks op-tee needs, so I will leave them to be added by op-tee
owner, whoever enables op-tee, he should consider where to manage its special clocks,
either in clk driver or op-tee driver/firmware.
So do we still need to mention the op-tee related info in commit text? Actually, this patch
is just to replace those always-ON clocks in clks_init_on array with CLK_IS_CRITICAL flag.
Then no need to explicitly enable clocks in clks_init_on array and just rely on common clk
framework which will enable all clocks with CLK_IS_CRITICAL flag set, it will align with all
other i.MX SoCs clk driver.
Anson.
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-10-16 4:37 ` Anson Huang
0 siblings, 0 replies; 48+ messages in thread
From: Anson Huang @ 2018-10-16 4:37 UTC (permalink / raw)
To: linux-arm-kernel
Hi, Stephen
Anson Huang
Best Regards!
> -----Original Message-----
> From: Stephen Boyd <sboyd@kernel.org>
> Sent: Tuesday, October 16, 2018 12:46 AM
> To: kernel at pengutronix.de; linux-arm-kernel at lists.infradead.org;
> linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org;
> mturquette at baylibre.com; s.hauer at pengutronix.de; shawnguo at kernel.org;
> Anson Huang <anson.huang@nxp.com>; Fabio Estevam
> <fabio.estevam@nxp.com>; Jerome Forissier <jerome.forissier@linaro.org>;
> Peng Fan <peng.fan@nxp.com>; Rob Herring <robh@kernel.org>
> Cc: dl-linux-imx <linux-imx@nxp.com>
> Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
>
> Quoting Anson Huang (2018-10-15 02:33:35)
> > > > > >
> > > > >
> > > > > Why can't we add clks to the op-tee node in DT's /firmware container?
> > > > > Then any clks in there can be turned on forever and left enabled
> > > > > by the linux driver?
> > > >
> > > > I did NOT run op-tee with Linux-next kernel before, can you advise more?
> > >
> > > Neither have I, so I can't advise more.
> > >
> > > > And I think if op-tee has such requirement, can we have another
> > > > patch to cover it?
> > >
> > > Yes.
> > >
> > >
> > > > I believe all other i.MX platforms also have same requirements if
> > > > considering op-tee support, so I think it should be another topic,
> > > > what do you
> > > think?
> > > >
> > >
> > > I'm going to drop these patches from my review queue. Please resend
> > > them and please include the op-tee patches too.
> >
> >
> > I do NOT know how to include the op-tee patch to meet special
> > requirement, should the op-tee related patch be added later when someone
> actually add the op-tee support for i.MX7?
> > It should NOT block this patch set, do you think we can add this patch set
> first?
> >
>
> Please resend the two patches. In the commit text for the second patch,
> describe the plan to remove CLK_IS_CRITICAL from these clks by adding an
> OP-TEE device/driver to the kernel to keep these clks enabled. My
> understanding is that there isn't an OP-TEE driver right now, but these clks are
> used by the firmware and can't be turned off in Linux. If in the future we want
> to be able to turn them on and off, we'll need to add them to an OP-TEE device
> node and have that driver manage the clks.
>
> How that will work when a system doesn't enable the OP-TEE driver I'm not
> sure. We may need to develop some system whereby clks like this are handed
> from the clk controller to the consumer driver when it's enabled for further
> power managment, but if they're never handed off, they're kept on forever like
> is done here. Anyway, please resend with a note about why these are marked
> CLK_IS_CRITICAL.
I think there is some misunderstanding here, this patch sets those critical clocks
with CLK_IS_CRITICAL flag to let clock driver keep them always ON, as they are
critical clocks and system (Linux kernel, NOT include op-tee) can NOT run normally
if anyone of them is OFF.
The question about op-tee is, there might be some special clocks needed by op-tee,
for example, currently clk A, B and C are kept always ON for Linux kernel to run normally,
but when op-tee is executing, it might need clk D to be ON, so I think the clk D is needed
ONLY for op-tee, op-tee should have a driver or firmware to runtime ON/OFF clk D as needed.
Since I do NOT know what clocks op-tee needs, so I will leave them to be added by op-tee
owner, whoever enables op-tee, he should consider where to manage its special clocks,
either in clk driver or op-tee driver/firmware.
So do we still need to mention the op-tee related info in commit text? Actually, this patch
is just to replace those always-ON clocks in clks_init_on array with CLK_IS_CRITICAL flag.
Then no need to explicitly enable clocks in clks_init_on array and just rely on common clk
framework which will enable all clocks with CLK_IS_CRITICAL flag set, it will align with all
other i.MX SoCs clk driver.
Anson.
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
2018-10-16 4:37 ` Anson Huang
@ 2018-10-16 22:24 ` Stephen Boyd
-1 siblings, 0 replies; 48+ messages in thread
From: Stephen Boyd @ 2018-10-16 22:24 UTC (permalink / raw)
To: kernel, linux-arm-kernel, linux-clk, linux-kernel, mturquette,
s.hauer, shawnguo, Anson Huang, Fabio Estevam, Jerome Forissier,
Peng Fan, Rob Herring
Cc: dl-linux-imx
Quoting Anson Huang (2018-10-15 21:37:31)
> Hi, Stephen
>
> Anson Huang
> Best Regards!
>
>
> > -----Original Message-----
> > From: Stephen Boyd <sboyd@kernel.org>
> > Sent: Tuesday, October 16, 2018 12:46 AM
> > To: kernel@pengutronix.de; linux-arm-kernel@lists.infradead.org;
> > linux-clk@vger.kernel.org; linux-kernel@vger.kernel.org;
> > mturquette@baylibre.com; s.hauer@pengutronix.de; shawnguo@kernel.org;
> > Anson Huang <anson.huang@nxp.com>; Fabio Estevam
> > <fabio.estevam@nxp.com>; Jerome Forissier <jerome.forissier@linaro.org>;
> > Peng Fan <peng.fan@nxp.com>; Rob Herring <robh@kernel.org>
> > Cc: dl-linux-imx <linux-imx@nxp.com>
> > Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> >
> > Quoting Anson Huang (2018-10-15 02:33:35)
> > > > > > >
> > > > > >
> > > > > > Why can't we add clks to the op-tee node in DT's /firmware container?
> > > > > > Then any clks in there can be turned on forever and left enabled
> > > > > > by the linux driver?
> > > > >
> > > > > I did NOT run op-tee with Linux-next kernel before, can you advise more?
> > > >
> > > > Neither have I, so I can't advise more.
> > > >
> > > > > And I think if op-tee has such requirement, can we have another
> > > > > patch to cover it?
> > > >
> > > > Yes.
> > > >
> > > >
> > > > > I believe all other i.MX platforms also have same requirements if
> > > > > considering op-tee support, so I think it should be another topic,
> > > > > what do you
> > > > think?
> > > > >
> > > >
> > > > I'm going to drop these patches from my review queue. Please resend
> > > > them and please include the op-tee patches too.
> > >
> > >
> > > I do NOT know how to include the op-tee patch to meet special
> > > requirement, should the op-tee related patch be added later when someone
> > actually add the op-tee support for i.MX7?
> > > It should NOT block this patch set, do you think we can add this patch set
> > first?
> > >
> >
> > Please resend the two patches. In the commit text for the second patch,
> > describe the plan to remove CLK_IS_CRITICAL from these clks by adding an
> > OP-TEE device/driver to the kernel to keep these clks enabled. My
> > understanding is that there isn't an OP-TEE driver right now, but these clks are
> > used by the firmware and can't be turned off in Linux. If in the future we want
> > to be able to turn them on and off, we'll need to add them to an OP-TEE device
> > node and have that driver manage the clks.
> >
> > How that will work when a system doesn't enable the OP-TEE driver I'm not
> > sure. We may need to develop some system whereby clks like this are handed
> > from the clk controller to the consumer driver when it's enabled for further
> > power managment, but if they're never handed off, they're kept on forever like
> > is done here. Anyway, please resend with a note about why these are marked
> > CLK_IS_CRITICAL.
>
> I think there is some misunderstanding here, this patch sets those critical clocks
> with CLK_IS_CRITICAL flag to let clock driver keep them always ON, as they are
> critical clocks and system (Linux kernel, NOT include op-tee) can NOT run normally
> if anyone of them is OFF.
Ok it sounds like OP-TEE usage completely orthogonal here? I'll go apply
these refactorings then.
^ permalink raw reply [flat|nested] 48+ messages in thread
* [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
@ 2018-10-16 22:24 ` Stephen Boyd
0 siblings, 0 replies; 48+ messages in thread
From: Stephen Boyd @ 2018-10-16 22:24 UTC (permalink / raw)
To: linux-arm-kernel
Quoting Anson Huang (2018-10-15 21:37:31)
> Hi, Stephen
>
> Anson Huang
> Best Regards!
>
>
> > -----Original Message-----
> > From: Stephen Boyd <sboyd@kernel.org>
> > Sent: Tuesday, October 16, 2018 12:46 AM
> > To: kernel at pengutronix.de; linux-arm-kernel at lists.infradead.org;
> > linux-clk at vger.kernel.org; linux-kernel at vger.kernel.org;
> > mturquette at baylibre.com; s.hauer at pengutronix.de; shawnguo at kernel.org;
> > Anson Huang <anson.huang@nxp.com>; Fabio Estevam
> > <fabio.estevam@nxp.com>; Jerome Forissier <jerome.forissier@linaro.org>;
> > Peng Fan <peng.fan@nxp.com>; Rob Herring <robh@kernel.org>
> > Cc: dl-linux-imx <linux-imx@nxp.com>
> > Subject: RE: [PATCH 2/2] clk: imx: imx7d: remove clks_init_on array
> >
> > Quoting Anson Huang (2018-10-15 02:33:35)
> > > > > > >
> > > > > >
> > > > > > Why can't we add clks to the op-tee node in DT's /firmware container?
> > > > > > Then any clks in there can be turned on forever and left enabled
> > > > > > by the linux driver?
> > > > >
> > > > > I did NOT run op-tee with Linux-next kernel before, can you advise more?
> > > >
> > > > Neither have I, so I can't advise more.
> > > >
> > > > > And I think if op-tee has such requirement, can we have another
> > > > > patch to cover it?
> > > >
> > > > Yes.
> > > >
> > > >
> > > > > I believe all other i.MX platforms also have same requirements if
> > > > > considering op-tee support, so I think it should be another topic,
> > > > > what do you
> > > > think?
> > > > >
> > > >
> > > > I'm going to drop these patches from my review queue. Please resend
> > > > them and please include the op-tee patches too.
> > >
> > >
> > > I do NOT know how to include the op-tee patch to meet special
> > > requirement, should the op-tee related patch be added later when someone
> > actually add the op-tee support for i.MX7?
> > > It should NOT block this patch set, do you think we can add this patch set
> > first?
> > >
> >
> > Please resend the two patches. In the commit text for the second patch,
> > describe the plan to remove CLK_IS_CRITICAL from these clks by adding an
> > OP-TEE device/driver to the kernel to keep these clks enabled. My
> > understanding is that there isn't an OP-TEE driver right now, but these clks are
> > used by the firmware and can't be turned off in Linux. If in the future we want
> > to be able to turn them on and off, we'll need to add them to an OP-TEE device
> > node and have that driver manage the clks.
> >
> > How that will work when a system doesn't enable the OP-TEE driver I'm not
> > sure. We may need to develop some system whereby clks like this are handed
> > from the clk controller to the consumer driver when it's enabled for further
> > power managment, but if they're never handed off, they're kept on forever like
> > is done here. Anyway, please resend with a note about why these are marked
> > CLK_IS_CRITICAL.
>
> I think there is some misunderstanding here, this patch sets those critical clocks
> with CLK_IS_CRITICAL flag to let clock driver keep them always ON, as they are
> critical clocks and system (Linux kernel, NOT include op-tee) can NOT run normally
> if anyone of them is OFF.
Ok it sounds like OP-TEE usage completely orthogonal here? I'll go apply
these refactorings then.
^ permalink raw reply [flat|nested] 48+ messages in thread