Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux