On Tue, Jul 4, 2017 at 11:27 PM, Rajendra Nayak <rnayak@xxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
