On Tue, May 08, 2018 at 10:30:19PM +0300, Jani Nikula wrote: > On Wed, 09 May 2018, Feng Tang <feng.tang@xxxxxxxxx> wrote: > > >> > > > On Mon, May 07, 2018 at 11:40:45AM +0100, Chris Wilson wrote: > >> >> > > > > Quoting Feng Tang (2018-05-07 11:36:09) > >> >> > > > > > To fulfil the Dell 4K monitor, the dpcd max retries has been bumped > >> >> > > > > > from 7 to 32, which may hurt the boot/init time for some platforms, > >> >> > > > > > as the 32 retries may take hundreds of ms. > >> >> > > > > > >> >> > > > > If we need that many retries, so be it. No modparam, the driver just has > >> >> > > > > to work. > >> >> > > > > >> >> > > > I understand your point. The retry numer was originally 7, and worked > >> >> > > > fine untill the Dell 4K monitor which changes to 32. According to my test, > >> >> > > > each retry will take about 8ms on the A3960 based NUC. > >> >> > > > > >> >> > > > One of our product need to boot up within a given time limit, this > >> >> > > > 32 retries will take about 1/3 of the budget (about 270ms), that's > >> >> > > > why I would try to make it a parameter. > >> >> > > > >> >> > > The essence is that probing whether a monitor is connected should not be > >> >> > > blocking boot. If an async probe tries and fails to find a monitor, > >> >> > > fine - no one will notice. If it does take 270ms to find a monitor, it > >> >> > > turns on 200ms after userspace kicks in, just like any other hotplug. > >> >> > > >> >> > Yeah, the fix here is to get the probing out of the driver load path, not > >> >> > to break the driver for some funky monitors. And definitely not using a > >> >> > modparam. > >> >> > >> >> Hi Chris and Daniel, > >> >> > >> >> After reading the i915 modeset init code, I did some experiments: > >> >> 1. make the intel_modeset_init() function async (here async means > >> >> creating a async func wrapper and call async_schedul() for it) > >> >> 2. make the intel_setup_outpus()+intel_modeset_setup_hw_state() async > >> > > >> > You could just set i915_pci_driver.driver.prove_type = > >> > PROBE_PREFER_ASYNCHRONOUS for the same result, or set i915.async_probe=1 > >> > for testing. > >> > > >> > However, if it's blocking on async_synchronize_full(), that will be no > >> > improvement. So if it is only an existing async_sychronize_full() > >> > causing the fbdev config to be waited on before userspace, we need to > >> > stop using the async mechanism and just use an ordinary worker and > >> > manual flushing. If it's the fbdev probing blocking you, why are you > >> > using fbdev? > >> > >> Well if it's edp probing, then atm we do need to block since we have > >> no support for panel hotplugging. And userspace generally no > >> expectations that built-in panels come&go. async_synchronize_full > >> making our fbdev code less async than desired is kinda a different > >> story I think here. First step would be trying to figure out why we > >> even bother with edp probing on this platform, when the thing isn't > >> there. Sounds like broken VBT. > > > > Hi Daniel, > > > > Here are some of the VBT and DPCD related logs on my A3900 (bxt + GEN9 LP) > > based NUC. but I don't have the knowledge to tell if the VBT is broken :) > > Please run current upstream drm-tip when you're suggesting changes to > upstream code. Looks like you're running at most v4.14. This can't be > emphasized enough. We can't and won't merge the changes unless they make > sense with current code. Yes, I understand, the patch posted was created right after git-pulling Linus' tree, and back-ported to test with 4.14 kernel. > > As to vbt, please send me /sys/kernel/debug/dri/0/i915_vbt. Sure. as attached Thanks, Feng
Attachment:
apl_nuc_i915_vbt
Description: Binary data
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
