Quoting Amit Nischal (2018-04-03 05:24:41)
On 2018-03-20 06:12, Stephen Boyd wrote:
> Quoting Amit Nischal (2018-03-07 23:18:15)
>> +};
>> +
>> +static struct clk_rcg2 gcc_sdcc4_apps_clk_src = {
>> + .cmd_rcgr = 0x1600c,
>> + .mnd_width = 8,
>> + .hid_width = 5,
>> + .parent_map = gcc_parent_map_0,
>> + .freq_tbl = ftbl_gcc_sdcc4_apps_clk_src,
>> + .safe_src_freq_tbl = &cxo_safe_src_f,
>
> Why does sdcc have safe src stuff? Is something turning on the sdcc clk
> outside of our control?
I will get more details on this and will get back.
Any news?
>
>> + .clkr.hw.init = &(struct clk_init_data){
>> + .name = "gcc_sdcc4_apps_clk_src",
>> + .parent_names = gcc_parent_names_0,
>> + .num_parents = 4,
>> + .flags = CLK_SET_RATE_PARENT,
>> + .ops = &clk_rcg2_shared_ops,
>> + },
>> +};
>> +
> [...]
>> +
>> +static struct clk_branch gcc_video_xo_clk = {
>> + .halt_reg = 0xb028,
>> + .halt_check = BRANCH_HALT,
>> + .clkr = {
>> + .enable_reg = 0xb028,
>> + .enable_mask = BIT(0),
>> + .hw.init = &(struct clk_init_data){
>> + .name = "gcc_video_xo_clk",
>> + .flags = CLK_IS_CRITICAL,
>> + .ops = &clk_branch2_ops,
>> +
>
> These things have no parents and we mark them critical. Why are we
> even exposing them to the kernel? Are they not on by default? Are we
> going to change these to non-critical at some point in the future?
These clocks are not enabled by default and going to video or other
multimedia cores so we are marking them as critical and need to expose
to the kernel. As of now, there is no plan to change these to
non-critical.
Ok. Can we open code enabling these branches in the driver probe then?
Still seems wasteful if nobody uses these.
Put another way, either a driver (or other clk controller) should be
toggling these gates at runtime or we should enable them once and leave
them out of the framework. If the driver approach is taken, then the
drivers should be able to turn the clks on and off to save some power.
--
To unsubscribe from this list: send the line "unsubscribe linux-clk" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html