On Mon, May 07, 2018 at 05:09:21PM +0200, Daniel Vetter wrote: > On Mon, May 07, 2018 at 02:33:25PM +0100, Chris Wilson wrote: > > Quoting Feng Tang (2018-05-07 22:26:34) > > > Hi Chris, > > > > > > Thanks for the prompt review! > > > > > > 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. Thank you both for the suggestion! Will try to make the probing async first, though I'm not familiar with the whole drm yet :) - Feng _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
