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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
