Re: [RFC] clk: inherit display clocks enabled by bootloader

2017-07-05 Thread Rajendra Nayak


On 07/04/2017 11:21 PM, Rob Clark wrote:
> The goal here is to support inheriting a display setup by bootloader,
> although there may also be some non-display related use-cases.
> 
> Rough idea is to add a flag for clks and power domains that might
> already be enabled when kernel starts, and make corresponding fixups
> to clk enable/prepare_count and power-domain state so that these are
> not automatically disabled late in boot.
> 
> If bootloader is enabling display, and kernel is using efifb before
> real display driver is loaded (potentially from kernel module after
> userspace starts, in a typical distro kernel), we don't want to kill
> the clocks and power domains that are used by the display before
> userspace starts.
> 
> Second part will be (*waves hands*) for drm/msm to check if display
> related clocks are enabled when it is loaded, and if so use drm
> atomic framework's hooks to read back hw state to sync existing
> display state w/ software state, and skip the initial clk_enable.
> Therefore inheriting the enable done by bootloader.
> 
> Obviously this should be split up into multiple patches and many
> TODOs addressed.  But I guess this is enough for now to start
> discussing the approach, and in particular how drm and clock/pd
> drivers work together to handle handover from bootloader.
> 
> The CLK_INHERIT_BOOTLOADER and related gsdc flag should only be set
> on leaf nodes.
> ---
> A bit hacky right now, but display survives clk_disable_unused()
> and genpd_power_off_unused().  It hangs just after that late in
> boot, which I'm still debugging (might be unrelated shenanigans).
> And haven't started on the drm/msm side of this.  But I figured
> it was half baked enough to send out for comments/ideas, or to
> see if anyone had some different idea about how to solve this.

Another RFC proposed around to handle similar situations is
https://lkml.org/lkml/2017/6/28/188

That one though, I guess deals with only regulator supplies for now.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC] clk: inherit display clocks enabled by bootloader

2017-07-05 Thread Rob Clark
On Tue, Jul 4, 2017 at 11:27 PM, Rajendra Nayak  wrote:
>
>
> On 07/04/2017 11:21 PM, Rob Clark wrote:
>> The goal here is to support inheriting a display setup by bootloader,
>> although there may also be some non-display related use-cases.
>>
>> Rough idea is to add a flag for clks and power domains that might
>> already be enabled when kernel starts, and make corresponding fixups
>> to clk enable/prepare_count and power-domain state so that these are
>> not automatically disabled late in boot.
>>
>> If bootloader is enabling display, and kernel is using efifb before
>> real display driver is loaded (potentially from kernel module after
>> userspace starts, in a typical distro kernel), we don't want to kill
>> the clocks and power domains that are used by the display before
>> userspace starts.
>>
>> Second part will be (*waves hands*) for drm/msm to check if display
>> related clocks are enabled when it is loaded, and if so use drm
>> atomic framework's hooks to read back hw state to sync existing
>> display state w/ software state, and skip the initial clk_enable.
>> Therefore inheriting the enable done by bootloader.
>>
>> Obviously this should be split up into multiple patches and many
>> TODOs addressed.  But I guess this is enough for now to start
>> discussing the approach, and in particular how drm and clock/pd
>> drivers work together to handle handover from bootloader.
>>
>> The CLK_INHERIT_BOOTLOADER and related gsdc flag should only be set
>> on leaf nodes.
>> ---
>> A bit hacky right now, but display survives clk_disable_unused()
>> and genpd_power_off_unused().  It hangs just after that late in
>> boot, which I'm still debugging (might be unrelated shenanigans).
>> And haven't started on the drm/msm side of this.  But I figured
>> it was half baked enough to send out for comments/ideas, or to
>> see if anyone had some different idea about how to solve this.
>
> Another RFC proposed around to handle similar situations is
> https://lkml.org/lkml/2017/6/28/188
>
> That one though, I guess deals with only regulator supplies for now.

Interesting.. although I do prefer it not being a static thing.  Ie.
depending on lk version and 'fastboot oem' params it may or may not
light up the display.  So detecting whether something is on at boot
is, imo, important.

(I haven't looked at regulators yet.. looks like it is all power
domains, at least on 8x16, not sure about others..)

BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC] clk: inherit display clocks enabled by bootloader

2017-07-04 Thread Rob Clark
On Tue, Jul 4, 2017 at 2:45 PM, Geert Uytterhoeven  wrote:
> On Tue, Jul 4, 2017 at 7:51 PM, Rob Clark  wrote:
>> The goal here is to support inheriting a display setup by bootloader,
>> although there may also be some non-display related use-cases.
>>
>> Rough idea is to add a flag for clks and power domains that might
>> already be enabled when kernel starts, and make corresponding fixups
>> to clk enable/prepare_count and power-domain state so that these are
>> not automatically disabled late in boot.
>>
>> If bootloader is enabling display, and kernel is using efifb before
>> real display driver is loaded (potentially from kernel module after
>> userspace starts, in a typical distro kernel), we don't want to kill
>> the clocks and power domains that are used by the display before
>> userspace starts.
>>
>> Second part will be (*waves hands*) for drm/msm to check if display
>> related clocks are enabled when it is loaded, and if so use drm
>> atomic framework's hooks to read back hw state to sync existing
>> display state w/ software state, and skip the initial clk_enable.
>> Therefore inheriting the enable done by bootloader.
>>
>> Obviously this should be split up into multiple patches and many
>> TODOs addressed.  But I guess this is enough for now to start
>> discussing the approach, and in particular how drm and clock/pd
>> drivers work together to handle handover from bootloader.
>>
>> The CLK_INHERIT_BOOTLOADER and related gsdc flag should only be set
>> on leaf nodes.
>
> Cfr. Documentation/devicetree/bindings/display/simple-framebuffer.txt?
>

which afaict doesn't help for efifb.. which we have no bindings for
(and would seem like a strange thing to have bindings for)

BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


Re: [RFC] clk: inherit display clocks enabled by bootloader

2017-07-04 Thread Geert Uytterhoeven
On Tue, Jul 4, 2017 at 7:51 PM, Rob Clark  wrote:
> The goal here is to support inheriting a display setup by bootloader,
> although there may also be some non-display related use-cases.
>
> Rough idea is to add a flag for clks and power domains that might
> already be enabled when kernel starts, and make corresponding fixups
> to clk enable/prepare_count and power-domain state so that these are
> not automatically disabled late in boot.
>
> If bootloader is enabling display, and kernel is using efifb before
> real display driver is loaded (potentially from kernel module after
> userspace starts, in a typical distro kernel), we don't want to kill
> the clocks and power domains that are used by the display before
> userspace starts.
>
> Second part will be (*waves hands*) for drm/msm to check if display
> related clocks are enabled when it is loaded, and if so use drm
> atomic framework's hooks to read back hw state to sync existing
> display state w/ software state, and skip the initial clk_enable.
> Therefore inheriting the enable done by bootloader.
>
> Obviously this should be split up into multiple patches and many
> TODOs addressed.  But I guess this is enough for now to start
> discussing the approach, and in particular how drm and clock/pd
> drivers work together to handle handover from bootloader.
>
> The CLK_INHERIT_BOOTLOADER and related gsdc flag should only be set
> on leaf nodes.

Cfr. Documentation/devicetree/bindings/display/simple-framebuffer.txt?

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[RFC] clk: inherit display clocks enabled by bootloader

2017-07-04 Thread Rob Clark
The goal here is to support inheriting a display setup by bootloader,
although there may also be some non-display related use-cases.

Rough idea is to add a flag for clks and power domains that might
already be enabled when kernel starts, and make corresponding fixups
to clk enable/prepare_count and power-domain state so that these are
not automatically disabled late in boot.

If bootloader is enabling display, and kernel is using efifb before
real display driver is loaded (potentially from kernel module after
userspace starts, in a typical distro kernel), we don't want to kill
the clocks and power domains that are used by the display before
userspace starts.

Second part will be (*waves hands*) for drm/msm to check if display
related clocks are enabled when it is loaded, and if so use drm
atomic framework's hooks to read back hw state to sync existing
display state w/ software state, and skip the initial clk_enable.
Therefore inheriting the enable done by bootloader.

Obviously this should be split up into multiple patches and many
TODOs addressed.  But I guess this is enough for now to start
discussing the approach, and in particular how drm and clock/pd
drivers work together to handle handover from bootloader.

The CLK_INHERIT_BOOTLOADER and related gsdc flag should only be set
on leaf nodes.
---
A bit hacky right now, but display survives clk_disable_unused()
and genpd_power_off_unused().  It hangs just after that late in
boot, which I'm still debugging (might be unrelated shenanigans).
And haven't started on the drm/msm side of this.  But I figured
it was half baked enough to send out for comments/ideas, or to
see if anyone had some different idea about how to solve this.

 drivers/clk/clk.c  | 18 ++
 drivers/clk/qcom/common.c  | 28 
 drivers/clk/qcom/gcc-msm8916.c | 15 ---
 drivers/clk/qcom/gdsc.c|  9 +
 drivers/clk/qcom/gdsc.h|  1 +
 include/linux/clk-provider.h   |  1 +
 include/linux/clk.h|  9 +
 7 files changed, 74 insertions(+), 7 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index fc58c52..7c84e8d 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -796,6 +796,24 @@ static void clk_disable_unused_subtree(struct clk_core 
*core)
clk_core_disable_unprepare(core->parent);
 }
 
+/* clock and it's parents are already prepared/enabled from bootloader,
+ * so simply record the fact.
+ */
+static void __clk_inherit_enabled(struct clk_core *core)
+{
+   core->enable_count++;
+   core->prepare_count++;
+if (core->hw->init->name) // XXX hack.. something funny with xo/xo_board..
+   if (core->parent)
+   __clk_inherit_enabled(core->parent);
+}
+
+void clk_inherit_enabled(struct clk *clk)
+{
+   __clk_inherit_enabled(clk->core);
+}
+EXPORT_SYMBOL_GPL(clk_inherit_enabled);
+
 static bool clk_ignore_unused;
 static int __init clk_ignore_unused_setup(char *__unused)
 {
diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
index d523991..90b698c 100644
--- a/drivers/clk/qcom/common.c
+++ b/drivers/clk/qcom/common.c
@@ -11,6 +11,7 @@
  * GNU General Public License for more details.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -258,6 +259,33 @@ int qcom_cc_really_probe(struct platform_device *pdev,
if (ret)
return ret;
 
+   /* Check which of clocks that we inherit state from bootloader
+* are enabled, and fixup enable/prepare state (as well as that
+* of it's parents).
+*
+* TODO can we assume that parents coming from another clk
+* driver are already registered?
+*/
+   for (i = 0; i < num_clks; i++) {
+   struct clk_hw *hw;
+
+   if (!rclks[i])
+   continue;
+
+   hw = &rclks[i]->hw;
+
+   if (!(hw->init->flags & CLK_INHERIT_BOOTLOADER))
+   continue;
+
+   if (!clk_is_enabled_regmap(hw))
+   continue;
+
+   dev_dbg(dev, "%s is enabled from bootloader!\n",
+ hw->init->name);
+
+   clk_inherit_enabled(hw->clk);
+   }
+
reset = &cc->reset;
reset->rcdev.of_node = dev->of_node;
reset->rcdev.ops = &qcom_reset_ops;
diff --git a/drivers/clk/qcom/gcc-msm8916.c b/drivers/clk/qcom/gcc-msm8916.c
index 628e6ca..eca64f7 100644
--- a/drivers/clk/qcom/gcc-msm8916.c
+++ b/drivers/clk/qcom/gcc-msm8916.c
@@ -2467,7 +2467,7 @@ static struct clk_branch gcc_mdss_ahb_clk = {
"pcnoc_bfdcd_clk_src",
},
.num_parents = 1,
-   .flags = CLK_SET_RATE_PARENT,
+   .flags = CLK_SET_RATE_PARENT | CLK_INHERIT_BOOTLOADER,
.ops = &clk_branch2_ops,
},
},
@@ -2484,7 +2484,7 @@ static struct clk_branch gcc_mds