* [PATCH] drm/dp: add module parameter for the dpcd access max retries @ 2018-05-07 10:36 Feng Tang 2018-05-07 10:40 ` Chris Wilson ` (2 more replies) 0 siblings, 3 replies; 18+ messages in thread From: Feng Tang @ 2018-05-07 10:36 UTC (permalink / raw) To: dri-devel, Gustavo Padovan, Maarten Lankhorst, Sean Paul, David Airlie, Jani Nikula, intel-gfx Cc: Feng Tang 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. This patch makes no functional change, but make the max retries adjustable, so that concerned users/platforms can have an option to short the wait time. On a Intel Atom Processor A3960 based NUC, the i915_init() time could be reduced from 450ms to 200ms. retries = 3: [ 0.457806] calling i915_init+0x0/0x51 @ 1 [ 0.662307] initcall i915_init+0x0/0x51 returned 0 after 199694 usecs retries = 32: [ 0.465818] calling i915_init+0x0/0x51 @ 1 [ 0.925831] initcall i915_init+0x0/0x51 returned 0 after 449219 usecs Signed-off-by: Feng Tang <feng.tang@intel.com> --- drivers/gpu/drm/drm_dp_helper.c | 22 +++++++++++++++------- 1 file changed, 15 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index ffe14ec..6054067 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -171,6 +171,20 @@ EXPORT_SYMBOL(drm_dp_bw_code_to_link_rate); #define AUX_RETRY_INTERVAL 500 /* us */ +/* + * The specification doesn't give any recommendation on how often to + * retry native transactions. We used to retry 7 times like for + * aux i2c transactions but real world devices this wasn't + * sufficient, bump to 32 which makes Dell 4k monitors happier. + * + * Since the retry may take quite some boot time, we make it a + * adjustable parameter for possible shorter retry time. + */ +static int dp_dpcd_max_retries __read_mostly = 32; +module_param_unsafe(dp_dpcd_max_retries, int, 0644); +MODULE_PARM_DESC(dp_dpcd_max_retries, + "Max retry number for DPCD access (default 32)"); + /** * DOC: dp helpers * @@ -198,13 +212,7 @@ static int drm_dp_dpcd_access(struct drm_dp_aux *aux, u8 request, mutex_lock(&aux->hw_mutex); - /* - * The specification doesn't give any recommendation on how often to - * retry native transactions. We used to retry 7 times like for - * aux i2c transactions but real world devices this wasn't - * sufficient, bump to 32 which makes Dell 4k monitors happier. - */ - for (retry = 0; retry < 32; retry++) { + for (retry = 0; retry < dp_dpcd_max_retries; retry++) { if (ret != 0 && ret != -ETIMEDOUT) { usleep_range(AUX_RETRY_INTERVAL, AUX_RETRY_INTERVAL + 100); -- 2.7.4 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/dp: add module parameter for the dpcd access max retries 2018-05-07 10:36 [PATCH] drm/dp: add module parameter for the dpcd access max retries Feng Tang @ 2018-05-07 10:40 ` Chris Wilson 2018-05-07 21:26 ` Feng Tang 2018-05-07 11:08 ` ✗ Fi.CI.BAT: failure for " Patchwork 2018-05-10 9:33 ` ✗ Fi.CI.BAT: failure for drm/dp: add module parameter for the dpcd access max retries (rev2) Patchwork 2 siblings, 1 reply; 18+ messages in thread From: Chris Wilson @ 2018-05-07 10:40 UTC (permalink / raw) To: dri-devel, Gustavo Padovan, Maarten Lankhorst, Sean Paul, David Airlie, Jani Nikula, intel-gfx Cc: Feng Tang 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. > This patch makes no functional change, but make the max retries > adjustable, so that concerned users/platforms can have an option > to short the wait time. > > On a Intel Atom Processor A3960 based NUC, the i915_init() time could > be reduced from 450ms to 200ms. > > retries = 3: > [ 0.457806] calling i915_init+0x0/0x51 @ 1 > [ 0.662307] initcall i915_init+0x0/0x51 returned 0 after 199694 usecs > > retries = 32: > [ 0.465818] calling i915_init+0x0/0x51 @ 1 > [ 0.925831] initcall i915_init+0x0/0x51 returned 0 after 449219 usecs Why is this synchronous anyway? -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/dp: add module parameter for the dpcd access max retries 2018-05-07 10:40 ` Chris Wilson @ 2018-05-07 21:26 ` Feng Tang 2018-05-07 13:33 ` Chris Wilson 0 siblings, 1 reply; 18+ messages in thread From: Feng Tang @ 2018-05-07 21:26 UTC (permalink / raw) To: Chris Wilson; +Cc: David Airlie, intel-gfx, dri-devel 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. > > > This patch makes no functional change, but make the max retries > > adjustable, so that concerned users/platforms can have an option > > to short the wait time. > > > > On a Intel Atom Processor A3960 based NUC, the i915_init() time could > > be reduced from 450ms to 200ms. > > > > retries = 3: > > [ 0.457806] calling i915_init+0x0/0x51 @ 1 > > [ 0.662307] initcall i915_init+0x0/0x51 returned 0 after 199694 usecs > > > > retries = 32: > > [ 0.465818] calling i915_init+0x0/0x51 @ 1 > > [ 0.925831] initcall i915_init+0x0/0x51 returned 0 after 449219 usecs > > Why is this synchronous anyway? I don't know the reason, maybe some of kernel components depends on the GFX module. But even we can put it to async, it is still the longest init one on our platform. Thanks, Feng _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/dp: add module parameter for the dpcd access max retries 2018-05-07 21:26 ` Feng Tang @ 2018-05-07 13:33 ` Chris Wilson 2018-05-07 15:09 ` Daniel Vetter 0 siblings, 1 reply; 18+ messages in thread From: Chris Wilson @ 2018-05-07 13:33 UTC (permalink / raw) To: Feng Tang; +Cc: David Airlie, intel-gfx, dri-devel 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. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/dp: add module parameter for the dpcd access max retries 2018-05-07 13:33 ` Chris Wilson @ 2018-05-07 15:09 ` Daniel Vetter 2018-05-07 23:19 ` Feng Tang 2018-05-08 19:03 ` Feng Tang 0 siblings, 2 replies; 18+ messages in thread From: Daniel Vetter @ 2018-05-07 15:09 UTC (permalink / raw) To: Chris Wilson; +Cc: David Airlie, Feng Tang, intel-gfx, dri-devel 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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/dp: add module parameter for the dpcd access max retries 2018-05-07 15:09 ` Daniel Vetter @ 2018-05-07 23:19 ` Feng Tang 2018-05-08 19:03 ` Feng Tang 1 sibling, 0 replies; 18+ messages in thread From: Feng Tang @ 2018-05-07 23:19 UTC (permalink / raw) To: Daniel Vetter; +Cc: David Airlie, intel-gfx, dri-devel 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/dp: add module parameter for the dpcd access max retries 2018-05-07 15:09 ` Daniel Vetter 2018-05-07 23:19 ` Feng Tang @ 2018-05-08 19:03 ` Feng Tang 2018-05-08 11:33 ` [Intel-gfx] " Chris Wilson 1 sibling, 1 reply; 18+ messages in thread From: Feng Tang @ 2018-05-08 19:03 UTC (permalink / raw) To: Daniel Vetter, Chris Wilson; +Cc: David Airlie, intel-gfx, feng.tang, dri-devel 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. 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 But both of them will trigger kernel panic (log msg pasted in the end), did I made some mistakes, or maybe the i915 codes following these functions has dependency over them? IIUC the dpcd access first happens in i915_driver_load --> i915_load_modeset_init --> intel_modeset_init --> intel_setup_outputs --> intel_ddi_init --> intel_edp_init_connector --> intel_edp_init_dpcd (to check if DPCD exist) Should we postpone it to later phase or even after user space kick in? Thanks, Feng --- Error msg for my async experiment: [ 0.715706] No backend configured for hyper_dmabuf in kernel config [ 0.716079] Hyper_dmabuf: no backend found [ 0.736361] intel_powerclamp: CPU does not support MWAIT [ 0.737643] [drm:wait_panel_status] *ERROR* PPS state mismatch [ 0.741381] genirq: Setting trigger mode 3 for irq 127 failed (intel_gpio_irq_type+0x0/0x110) [ 0.743244] dmi-sysfs: dmi entry is absent. [ 0.765116] [edp_panel_vdd_on()]: exit [ 0.765360] BUG: unable to handle kernel NULL pointer dereference at (null) [ 0.765809] IP: (null) [ 0.766005] PGD 0 P4D 0 [ 0.766168] Oops: 0010 [#1] PREEMPT SMP [ 0.766401] Modules linked in: [ 0.766592] CPU: 0 PID: 28 Comm: kworker/u8:1 Tainted: G U W 4.14.39-sos+ #26 [ 0.767075] Workqueue: events_unbound async_run_entry_fn [ 0.767392] task: ffff88027433c240 task.stack: ffff880274340000 [ 0.767743] RIP: 0010: (null) [ 0.767969] RSP: 0000:ffff880274343ab8 EFLAGS: 00010246 [ 0.768281] RAX: 0000000000000000 RBX: 000000002d4003ff RCX: 0000000000000001 [ 0.768701] RDX: 0000000080000000 RSI: 0000000000000000 RDI: ffff880272f21100 [ 0.769121] RBP: 0000000000000000 R08: 000000002d4003ff R09: 0000000000000001 [ 0.769541] R10: ffff880274343a60 R11: ffffffff82e7fe0d R12: 0000000000000001 [ 0.769961] R13: ffff880273038000 R14: 0000000000000004 R15: ffff880272f21100 [ 0.770383] FS: 0000000000000000(0000) GS:ffff88027dc00000(0000) knlGS:0000000000000000 [ 0.770858] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.771199] CR2: 0000000000000000 CR3: 0000000002613000 CR4: 00000000003426f0 [ 0.771619] Call Trace: [ 0.771779] ? intel_dp_aux_ch+0x1a7/0x770 [ 0.772031] ? remove_wait_queue+0x60/0x60 [ 0.772281] ? intel_dp_aux_transfer+0xa6/0x200 [ 0.772556] ? drm_dp_dpcd_access+0x9d/0x150 [ 0.772815] ? drm_dp_dpcd_read+0x2c/0x60 [ 0.773059] ? drm_dp_read_desc+0x43/0xf0 [ 0.773303] ? intel_dp_detect+0x346/0x6a0 [ 0.773554] ? drm_helper_probe_single_connector_modes+0xcd/0x6b0 [ 0.773920] ? _raw_spin_unlock+0x14/0x30 [ 0.774165] ? vt_console_print+0x22a/0x3d0 [ 0.774420] ? preempt_count_add+0x56/0xa0 [ 0.774669] ? _raw_spin_lock_irqsave+0x32/0x40 [ 0.774944] ? drm_setup_crtcs+0x143/0x9e0 [ 0.775195] ? __drm_fb_helper_initial_config_and_unlock+0x3f/0x410 [ 0.775567] ? mutex_lock+0x1c/0x40 [ 0.775783] ? intel_fbdev_initial_config+0x14/0x30 [ 0.776076] ? async_run_entry_fn+0x39/0x160 [ 0.776335] ? process_one_work+0x14a/0x3c0 [ 0.776588] ? worker_thread+0x4d/0x3e0 [ 0.776823] ? kthread+0x10a/0x140 [ 0.777031] ? process_one_work+0x3c0/0x3c0 [ 0.777284] ? kthread_create_on_node+0x40/0x40 [ 0.777557] ? ret_from_fork+0x3a/0x50 [ 0.777785] Code: Bad RIP value. [ 0.777995] RIP: (null) RSP: ffff880274343ab8 [ 0.778305] CR2: 0000000000000000 [ 0.778508] ---[ end trace f4e157ae338a4060 ]--- [ 0.778786] Kernel panic - not syncing: Fatal exception [ 0.779160] Kernel Offset: disabled [ 0.779376] Rebooting in 10 seconds.. _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries 2018-05-08 19:03 ` Feng Tang @ 2018-05-08 11:33 ` Chris Wilson 2018-05-08 12:00 ` Daniel Vetter 0 siblings, 1 reply; 18+ messages in thread From: Chris Wilson @ 2018-05-08 11:33 UTC (permalink / raw) To: Daniel Vetter; +Cc: David Airlie, intel-gfx, feng.tang, dri-devel Quoting Feng Tang (2018-05-08 20:03:15) > > 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. > > 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? -Chris _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/dp: add module parameter for the dpcd access max retries 2018-05-08 11:33 ` [Intel-gfx] " Chris Wilson @ 2018-05-08 12:00 ` Daniel Vetter 2018-05-08 23:08 ` [Intel-gfx] " Feng Tang 0 siblings, 1 reply; 18+ messages in thread From: Daniel Vetter @ 2018-05-08 12:00 UTC (permalink / raw) To: Chris Wilson; +Cc: David Airlie, Feng Tang, intel-gfx, dri-devel On Tue, May 8, 2018 at 1:33 PM, Chris Wilson <chris@chris-wilson.co.uk> wrote: > Quoting Feng Tang (2018-05-08 20:03:15) >> >> 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. >> >> 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. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries 2018-05-08 12:00 ` Daniel Vetter @ 2018-05-08 23:08 ` Feng Tang 2018-05-08 19:30 ` Jani Nikula 0 siblings, 1 reply; 18+ messages in thread From: Feng Tang @ 2018-05-08 23:08 UTC (permalink / raw) To: Daniel Vetter; +Cc: David Airlie, intel-gfx, feng.tang, dri-devel >> > > > 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 :) [ 0.545231] [drm:intel_bios_init] Set default to SSC at 100000 kHz [ 0.545237] [drm:intel_bios_init] VBT signature "$VBT BROXTON ", BDB version 207 [ 0.545241] [drm:intel_bios_init] BDB_GENERAL_FEATURES int_tv_support 0 int_crt_support 0 lvds_use_ssc 0 lvds_ssc_freq 120000 display_clock_mode 1 fdi_rx_polarity_inverted 0 [ 0.545245] [drm:intel_bios_init] crt_ddc_bus_pin: 2 [ 0.545255] [drm:intel_opregion_get_panel_type] Failed to get panel details from OpRegion (-19) [ 0.545257] [drm:intel_bios_init] Panel type: 0 (VBT) [ 0.545260] [drm:intel_bios_init] DRRS supported mode is seamless [ 0.545275] [drm:intel_bios_init] Found panel mode in BIOS VBT tables: [ 0.545281] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 0 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x8 0xa [ 0.545292] [drm:intel_bios_init] VBT backlight PWM modulation frequency 200 Hz, active high, min brightness 0, level 180, controller 1 [ 0.545301] [drm:intel_bios_init] Unsupported child device size for SDVO mapping. [ 0.545305] [drm:intel_bios_init] Expected child device config size for VBT version 207 not known; assuming 38 [ 0.545323] [drm:intel_bios_init] DRRS State Enabled:1 [ 0.545334] [drm:intel_bios_init] Port A VBT info: DP:1 HDMI:0 DVI:0 EDP:1 CRT:0 [ 0.545338] [drm:intel_bios_init] VBT HDMI level shift for port A: 0 [ 0.545341] [drm:intel_bios_init] Port B VBT info: DP:0 HDMI:1 DVI:1 EDP:0 CRT:0 [ 0.545344] [drm:intel_bios_init] VBT HDMI level shift for port B: 8 [ 0.545347] [drm:intel_bios_init] Port C VBT info: DP:0 HDMI:1 DVI:1 EDP:0 CRT:0 [ 0.545350] [drm:intel_bios_init] VBT HDMI level shift for port C: 8 [ 0.546076] [drm:gen9_set_dc_state] Setting DC state from 00 to 00 [ 0.546091] [drm:intel_power_well_enable] enabling power well 1 [ 0.546126] [drm:gvt_service_thread] gvt: core: service thread start [ 0.546174] [drm:intel_update_cdclk] Current CD clock rate: 19200 kHz, VCO: 0 kHz, ref: 19200 kHz [ 0.546176] [drm:bxt_init_cdclk] Sanitizing cdclk programmed by pre-os [ 0.546339] [drm:intel_update_cdclk] Current CD clock rate: 144000 kHz, VCO: 1152000 kHz, ref: 19200 kHz [ 0.546357] [drm:intel_power_well_enable] enabling always-on [ 0.546360] [drm:intel_power_well_enable] enabling DC off [ 0.546364] [drm:gen9_set_dc_state] Setting DC state from 00 to 00 [ 0.546372] [drm:intel_power_well_enable] enabling power well 2 [ 0.546386] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem [ 0.546396] [drm:intel_power_well_enable] enabling dpio-common-a [ 0.546488] [drm:intel_power_well_enable] enabling dpio-common-bc [ 0.546844] [drm:intel_csr_ucode_init] Loading i915/bxt_dmc_ver1_07.bin [ 0.546854] [drm:drm_irq_install] irq=124 [ 0.546906] i915 0000:00:02.0: Direct firmware load for i915/bxt_dmc_ver1_07.bin failed with error -2 [ 0.546909] i915 0000:00:02.0: Falling back to user helper [ 0.547098] [drm:__bxt_hpd_detection_setup] Invert bit setting: hp_ctl:18001818 hp_port:38 [ 0.547425] [drm:intel_fbc_init] Sanitized enable_fbc value: 1 [ 0.547445] [drm:intel_print_wm_latency] Gen9 Plane WM0 latency 7 (7.0 usec) [ 0.547447] [drm:intel_print_wm_latency] Gen9 Plane WM1 latency 7 (7.0 usec) [ 0.547450] [drm:intel_print_wm_latency] Gen9 Plane WM2 latency 8 (8.0 usec) [ 0.547453] [drm:intel_print_wm_latency] Gen9 Plane WM3 latency 22 (22.0 usec) [ 0.547455] [drm:intel_print_wm_latency] Gen9 Plane WM4 latency 22 (22.0 usec) [ 0.547458] [drm:intel_print_wm_latency] Gen9 Plane WM5 latency 22 (22.0 usec) [ 0.547460] [drm:intel_print_wm_latency] Gen9 Plane WM6 latency 22 (22.0 usec) [ 0.547462] [drm:intel_print_wm_latency] Gen9 Plane WM7 latency 22 (22.0 usec) [ 0.547466] [drm:intel_modeset_init] 3 display pipes available. [ 0.548182] [drm:intel_update_cdclk] Current CD clock rate: 144000 kHz, VCO: 1152000 kHz, ref: 19200 kHz [ 0.548393] [drm:intel_update_max_cdclk] Max CD clock rate: 624000 kHz [ 0.548395] [drm:intel_modeset_init] Max dotclock rate: 624000 kHz [ 0.549124] [intel_setup_outputs()]: enter [ 0.549522] [drm:intel_ddi_init] BXT BIOS forgot to set DDI_A_4_LANES for port A; fixing [ 0.549531] [drm:intel_dp_init_connector] Adding eDP connector on port A [ 0.549538] [drm:intel_dp_init_connector] using AUX A for port A (VBT) [ 0.549552] [drm:intel_pps_dump_state] cur t1_t3 0 t8 0 t9 0 t10 0 t11_t12 0 [ 0.549556] [drm:intel_pps_dump_state] vbt t1_t3 2000 t8 10 t9 2000 t10 500 t11_t12 6000 [ 0.549560] [drm:intel_dp_init_panel_power_sequencer.part.19] panel power up delay 200, power down delay 50, power cycle delay 600 [ 0.549563] [drm:intel_dp_init_panel_power_sequencer.part.19] backlight on delay 1, off delay 200 [ 0.549569] [drm:intel_dp_init_panel_power_sequencer_registers] panel power sequencer register settings: PP_ON 0x7d00001, PP_OFF 0x1f40001, PP_DIV 0x60 [ 0.549577] [drm:edp_panel_vdd_on] Turning eDP port A VDD on [ 0.549580] [drm:wait_panel_power_cycle] Wait for panel power cycle [ 0.601112] [drm:wait_panel_status] mask b800000f value 00000000 status 00000000 control 00000062 [ 0.601116] [drm:wait_panel_status] Wait complete [ 0.601121] [drm:edp_panel_vdd_on] PP_STATUS: 0x00000000 PP_CONTROL: 0x0000006a [ 0.601125] [drm:edp_panel_vdd_on] eDP port A panel power wasn't enabled [ 0.636720] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.645328] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.653926] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.662531] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.671132] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.679767] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.688366] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.696969] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.705572] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.714173] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.722770] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.731378] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.739983] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.748590] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.757210] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.765808] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.774422] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.783039] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.791642] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.800252] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.808859] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.817481] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.826086] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.834722] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.843335] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.851944] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.860552] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.869160] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.877767] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.886429] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.895045] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.903658] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff [ 0.903665] [drm:drm_dp_dpcd_access] Too many retries, giving up. First error: -110 [ 0.903666] [drm] failed to retrieve link info, disabling eDP [ 0.903671] [drm:edp_panel_vdd_off_sync] Turning eDP port A VDD off [ 0.903676] [drm:edp_panel_vdd_off_sync] PP_STATUS: 0x00000000 PP_CONTROL: 0x00000062 [ 0.903695] [drm:intel_hdmi_init_connector] Adding HDMI connector on port B [ 0.903702] [drm:intel_hdmi_init_connector] Using DDC pin 0x1 for port B (VBT) [ 0.903720] [drm:intel_hdmi_init_connector] Adding HDMI connector on port C [ 0.903724] [drm:intel_hdmi_init_connector] Using DDC pin 0x2 for port C (VBT) [ 0.903728] [drm:intel_dsi_init] [ 0.903733] [drm:acrngt_dom0_ready] gvt: core: acrngt: Dom 0 ready to accept Dom U guests Thanks, Feng _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries 2018-05-08 23:08 ` [Intel-gfx] " Feng Tang @ 2018-05-08 19:30 ` Jani Nikula 2018-05-09 6:31 ` Feng Tang 0 siblings, 1 reply; 18+ messages in thread From: Jani Nikula @ 2018-05-08 19:30 UTC (permalink / raw) To: Daniel Vetter; +Cc: David Airlie, intel-gfx, feng.tang, dri-devel On Wed, 09 May 2018, Feng Tang <feng.tang@intel.com> 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. As to vbt, please send me /sys/kernel/debug/dri/0/i915_vbt. BR, Jani. > > [ 0.545231] [drm:intel_bios_init] Set default to SSC at 100000 kHz > [ 0.545237] [drm:intel_bios_init] VBT signature "$VBT BROXTON ", BDB version 207 > [ 0.545241] [drm:intel_bios_init] BDB_GENERAL_FEATURES int_tv_support 0 int_crt_support 0 lvds_use_ssc 0 lvds_ssc_freq 120000 display_clock_mode 1 fdi_rx_polarity_inverted 0 > [ 0.545245] [drm:intel_bios_init] crt_ddc_bus_pin: 2 > [ 0.545255] [drm:intel_opregion_get_panel_type] Failed to get panel details from OpRegion (-19) > [ 0.545257] [drm:intel_bios_init] Panel type: 0 (VBT) > [ 0.545260] [drm:intel_bios_init] DRRS supported mode is seamless > [ 0.545275] [drm:intel_bios_init] Found panel mode in BIOS VBT tables: > [ 0.545281] [drm:drm_mode_debug_printmodeline] Modeline 0:"1920x1080" 0 148500 1920 2008 2052 2200 1080 1084 1089 1125 0x8 0xa > [ 0.545292] [drm:intel_bios_init] VBT backlight PWM modulation frequency 200 Hz, active high, min brightness 0, level 180, controller 1 > [ 0.545301] [drm:intel_bios_init] Unsupported child device size for SDVO mapping. > [ 0.545305] [drm:intel_bios_init] Expected child device config size for VBT version 207 not known; assuming 38 > [ 0.545323] [drm:intel_bios_init] DRRS State Enabled:1 > [ 0.545334] [drm:intel_bios_init] Port A VBT info: DP:1 HDMI:0 DVI:0 EDP:1 CRT:0 > [ 0.545338] [drm:intel_bios_init] VBT HDMI level shift for port A: 0 > [ 0.545341] [drm:intel_bios_init] Port B VBT info: DP:0 HDMI:1 DVI:1 EDP:0 CRT:0 > [ 0.545344] [drm:intel_bios_init] VBT HDMI level shift for port B: 8 > [ 0.545347] [drm:intel_bios_init] Port C VBT info: DP:0 HDMI:1 DVI:1 EDP:0 CRT:0 > [ 0.545350] [drm:intel_bios_init] VBT HDMI level shift for port C: 8 > [ 0.546076] [drm:gen9_set_dc_state] Setting DC state from 00 to 00 > [ 0.546091] [drm:intel_power_well_enable] enabling power well 1 > [ 0.546126] [drm:gvt_service_thread] gvt: core: service thread start > [ 0.546174] [drm:intel_update_cdclk] Current CD clock rate: 19200 kHz, VCO: 0 kHz, ref: 19200 kHz > [ 0.546176] [drm:bxt_init_cdclk] Sanitizing cdclk programmed by pre-os > [ 0.546339] [drm:intel_update_cdclk] Current CD clock rate: 144000 kHz, VCO: 1152000 kHz, ref: 19200 kHz > [ 0.546357] [drm:intel_power_well_enable] enabling always-on > [ 0.546360] [drm:intel_power_well_enable] enabling DC off > [ 0.546364] [drm:gen9_set_dc_state] Setting DC state from 00 to 00 > [ 0.546372] [drm:intel_power_well_enable] enabling power well 2 > [ 0.546386] i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem > [ 0.546396] [drm:intel_power_well_enable] enabling dpio-common-a > [ 0.546488] [drm:intel_power_well_enable] enabling dpio-common-bc > [ 0.546844] [drm:intel_csr_ucode_init] Loading i915/bxt_dmc_ver1_07.bin > [ 0.546854] [drm:drm_irq_install] irq=124 > [ 0.546906] i915 0000:00:02.0: Direct firmware load for i915/bxt_dmc_ver1_07.bin failed with error -2 > [ 0.546909] i915 0000:00:02.0: Falling back to user helper > [ 0.547098] [drm:__bxt_hpd_detection_setup] Invert bit setting: hp_ctl:18001818 hp_port:38 > [ 0.547425] [drm:intel_fbc_init] Sanitized enable_fbc value: 1 > [ 0.547445] [drm:intel_print_wm_latency] Gen9 Plane WM0 latency 7 (7.0 usec) > [ 0.547447] [drm:intel_print_wm_latency] Gen9 Plane WM1 latency 7 (7.0 usec) > [ 0.547450] [drm:intel_print_wm_latency] Gen9 Plane WM2 latency 8 (8.0 usec) > [ 0.547453] [drm:intel_print_wm_latency] Gen9 Plane WM3 latency 22 (22.0 usec) > [ 0.547455] [drm:intel_print_wm_latency] Gen9 Plane WM4 latency 22 (22.0 usec) > [ 0.547458] [drm:intel_print_wm_latency] Gen9 Plane WM5 latency 22 (22.0 usec) > [ 0.547460] [drm:intel_print_wm_latency] Gen9 Plane WM6 latency 22 (22.0 usec) > [ 0.547462] [drm:intel_print_wm_latency] Gen9 Plane WM7 latency 22 (22.0 usec) > [ 0.547466] [drm:intel_modeset_init] 3 display pipes available. > [ 0.548182] [drm:intel_update_cdclk] Current CD clock rate: 144000 kHz, VCO: 1152000 kHz, ref: 19200 kHz > [ 0.548393] [drm:intel_update_max_cdclk] Max CD clock rate: 624000 kHz > [ 0.548395] [drm:intel_modeset_init] Max dotclock rate: 624000 kHz > [ 0.549124] [intel_setup_outputs()]: enter > [ 0.549522] [drm:intel_ddi_init] BXT BIOS forgot to set DDI_A_4_LANES for port A; fixing > [ 0.549531] [drm:intel_dp_init_connector] Adding eDP connector on port A > [ 0.549538] [drm:intel_dp_init_connector] using AUX A for port A (VBT) > [ 0.549552] [drm:intel_pps_dump_state] cur t1_t3 0 t8 0 t9 0 t10 0 t11_t12 0 > [ 0.549556] [drm:intel_pps_dump_state] vbt t1_t3 2000 t8 10 t9 2000 t10 500 t11_t12 6000 > [ 0.549560] [drm:intel_dp_init_panel_power_sequencer.part.19] panel power up delay 200, power down delay 50, power cycle delay 600 > [ 0.549563] [drm:intel_dp_init_panel_power_sequencer.part.19] backlight on delay 1, off delay 200 > [ 0.549569] [drm:intel_dp_init_panel_power_sequencer_registers] panel power sequencer register settings: PP_ON 0x7d00001, PP_OFF 0x1f40001, PP_DIV 0x60 > [ 0.549577] [drm:edp_panel_vdd_on] Turning eDP port A VDD on > [ 0.549580] [drm:wait_panel_power_cycle] Wait for panel power cycle > [ 0.601112] [drm:wait_panel_status] mask b800000f value 00000000 status 00000000 control 00000062 > [ 0.601116] [drm:wait_panel_status] Wait complete > [ 0.601121] [drm:edp_panel_vdd_on] PP_STATUS: 0x00000000 PP_CONTROL: 0x0000006a > [ 0.601125] [drm:edp_panel_vdd_on] eDP port A panel power wasn't enabled > [ 0.636720] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.645328] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.653926] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.662531] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.671132] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.679767] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.688366] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.696969] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.705572] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.714173] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.722770] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.731378] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.739983] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.748590] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.757210] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.765808] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.774422] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.783039] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.791642] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.800252] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.808859] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.817481] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.826086] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.834722] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.843335] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.851944] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.860552] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.869160] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.877767] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.886429] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.895045] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.903658] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d4003ff > [ 0.903665] [drm:drm_dp_dpcd_access] Too many retries, giving up. First error: -110 > [ 0.903666] [drm] failed to retrieve link info, disabling eDP > [ 0.903671] [drm:edp_panel_vdd_off_sync] Turning eDP port A VDD off > [ 0.903676] [drm:edp_panel_vdd_off_sync] PP_STATUS: 0x00000000 PP_CONTROL: 0x00000062 > [ 0.903695] [drm:intel_hdmi_init_connector] Adding HDMI connector on port B > [ 0.903702] [drm:intel_hdmi_init_connector] Using DDC pin 0x1 for port B (VBT) > [ 0.903720] [drm:intel_hdmi_init_connector] Adding HDMI connector on port C > [ 0.903724] [drm:intel_hdmi_init_connector] Using DDC pin 0x2 for port C (VBT) > [ 0.903728] [drm:intel_dsi_init] > [ 0.903733] [drm:acrngt_dom0_ready] gvt: core: acrngt: Dom 0 ready to accept Dom U guests > > Thanks, > Feng > > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/dp: add module parameter for the dpcd access max retries 2018-05-08 19:30 ` Jani Nikula @ 2018-05-09 6:31 ` Feng Tang 2018-05-09 7:53 ` Jani Nikula 0 siblings, 1 reply; 18+ messages in thread From: Feng Tang @ 2018-05-09 6:31 UTC (permalink / raw) To: Jani Nikula; +Cc: David Airlie, intel-gfx, dri-devel [-- Attachment #1: Type: text/plain, Size: 3692 bytes --] On Tue, May 08, 2018 at 10:30:19PM +0300, Jani Nikula wrote: > On Wed, 09 May 2018, Feng Tang <feng.tang@intel.com> 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 #2: apl_nuc_i915_vbt --] [-- Type: application/octet-stream, Size: 6656 bytes --] [-- Attachment #3: Type: text/plain, Size: 160 bytes --] _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/dp: add module parameter for the dpcd access max retries 2018-05-09 6:31 ` Feng Tang @ 2018-05-09 7:53 ` Jani Nikula 2018-05-09 7:56 ` Feng Tang 0 siblings, 1 reply; 18+ messages in thread From: Jani Nikula @ 2018-05-09 7:53 UTC (permalink / raw) To: Feng Tang; +Cc: David Airlie, intel-gfx, dri-devel On Wed, 09 May 2018, Feng Tang <feng.tang@intel.com> wrote: > On Tue, May 08, 2018 at 10:30:19PM +0300, Jani Nikula wrote: >> On Wed, 09 May 2018, Feng Tang <feng.tang@intel.com> wrote: >> >> 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 Your VBT claims the device has an eDP panel. Does it have one or not? BR, Jani. -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH] drm/dp: add module parameter for the dpcd access max retries 2018-05-09 7:53 ` Jani Nikula @ 2018-05-09 7:56 ` Feng Tang 2018-05-09 9:28 ` [Intel-gfx] " Jani Nikula 0 siblings, 1 reply; 18+ messages in thread From: Feng Tang @ 2018-05-09 7:56 UTC (permalink / raw) To: Jani Nikula; +Cc: feng.tang, David Airlie, intel-gfx, dri-devel, fei.jiang On Wed, May 09, 2018 at 10:53:53AM +0300, Jani Nikula wrote: > On Wed, 09 May 2018, Feng Tang <feng.tang@intel.com> wrote: > > On Tue, May 08, 2018 at 10:30:19PM +0300, Jani Nikula wrote: > >> On Wed, 09 May 2018, Feng Tang <feng.tang@intel.com> wrote: > >> >> 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 > > Your VBT claims the device has an eDP panel. Does it have one or not? After asking around, our platform (BXT NUC) does have a eDP interface (someone has tested with a eDP screen), but most of our platforms are connected with 2 HDMI LCD monitors. Thanks, Feng _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries 2018-05-09 7:56 ` Feng Tang @ 2018-05-09 9:28 ` Jani Nikula 2018-05-10 9:21 ` Feng Tang 0 siblings, 1 reply; 18+ messages in thread From: Jani Nikula @ 2018-05-09 9:28 UTC (permalink / raw) Cc: feng.tang, David Airlie, intel-gfx, dri-devel, fei.jiang On Wed, 09 May 2018, Feng Tang <feng.tang@intel.com> wrote: > On Wed, May 09, 2018 at 10:53:53AM +0300, Jani Nikula wrote: >> On Wed, 09 May 2018, Feng Tang <feng.tang@intel.com> wrote: >> > On Tue, May 08, 2018 at 10:30:19PM +0300, Jani Nikula wrote: >> >> On Wed, 09 May 2018, Feng Tang <feng.tang@intel.com> wrote: >> >> >> 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 >> >> Your VBT claims the device has an eDP panel. Does it have one or not? > > After asking around, our platform (BXT NUC) does have a eDP interface (someone > has tested with a eDP screen), but most of our platforms are connected > with 2 HDMI LCD monitors. Sounds like you should have a different VBT for the cases where you ship with/without eDP connected. As you've noticed, we generally try pretty hard to talk to the panel if VBT says it's there, to avoid black screens which are a much worse scenario than delays in detection. BR, Jani. > > Thanks, > Feng -- Jani Nikula, Intel Open Source Technology Center _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [Intel-gfx] [PATCH] drm/dp: add module parameter for the dpcd access max retries 2018-05-09 9:28 ` [Intel-gfx] " Jani Nikula @ 2018-05-10 9:21 ` Feng Tang 0 siblings, 0 replies; 18+ messages in thread From: Feng Tang @ 2018-05-10 9:21 UTC (permalink / raw) To: Jani Nikula; +Cc: feng.tang, David Airlie, intel-gfx, dri-devel, fei.jiang On Wed, May 09, 2018 at 12:28:15PM +0300, Jani Nikula wrote: > On Wed, 09 May 2018, Feng Tang <feng.tang@intel.com> wrote: > > On Wed, May 09, 2018 at 10:53:53AM +0300, Jani Nikula wrote: > >> On Wed, 09 May 2018, Feng Tang <feng.tang@intel.com> wrote: > >> > On Tue, May 08, 2018 at 10:30:19PM +0300, Jani Nikula wrote: > >> >> On Wed, 09 May 2018, Feng Tang <feng.tang@intel.com> wrote: > >> >> >> 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 > >> > >> Your VBT claims the device has an eDP panel. Does it have one or not? > > > > After asking around, our platform (BXT NUC) does have a eDP interface (someone > > has tested with a eDP screen), but most of our platforms are connected > > with 2 HDMI LCD monitors. > > Sounds like you should have a different VBT for the cases where you ship > with/without eDP connected. As you've noticed, we generally try pretty Yep, this is a good idea. Currently I'm not able to change VBT, so I hacked the code to simulating a no-eDP VBT like: --- a/drivers/gpu/drm/i915/intel_bios.c +++ b/drivers/gpu/drm/i915/intel_bios.c @@ -1261,7 +1261,8 @@ static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port, is_crt = child->device_type & DEVICE_TYPE_ANALOG_OUTPUT; is_hdmi = is_dvi && (child->device_type & DEVICE_TYPE_NOT_HDMI_OUTPUT) == 0; - is_edp = is_dp && (child->device_type & DEVICE_TYPE_INTERNAL_CONNECTOR); + is_edp = 0; And it does cut the boottime a lot!! as avoiding the dpcd access. And later i915_hpd_poll_init_work() will still call intel_dp_detect() and call the time-eater drm_dp_dpcd_access() finally, but the situation is better as it runs in an async way at this point. Thanks, Feng _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel ^ permalink raw reply [flat|nested] 18+ messages in thread
* ✗ Fi.CI.BAT: failure for drm/dp: add module parameter for the dpcd access max retries 2018-05-07 10:36 [PATCH] drm/dp: add module parameter for the dpcd access max retries Feng Tang 2018-05-07 10:40 ` Chris Wilson @ 2018-05-07 11:08 ` Patchwork 2018-05-10 9:33 ` ✗ Fi.CI.BAT: failure for drm/dp: add module parameter for the dpcd access max retries (rev2) Patchwork 2 siblings, 0 replies; 18+ messages in thread From: Patchwork @ 2018-05-07 11:08 UTC (permalink / raw) To: Feng Tang; +Cc: intel-gfx == Series Details == Series: drm/dp: add module parameter for the dpcd access max retries URL : https://patchwork.freedesktop.org/series/42803/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4150 -> Patchwork_8925 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_8925 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_8925, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/42803/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_8925: === IGT changes === ==== Possible regressions ==== igt@drv_module_reload@basic-reload: fi-ilk-650: PASS -> DMESG-WARN +2 == Known issues == Here are the changes found in Patchwork_8925 that come from known issues: === IGT changes === ==== Issues hit ==== igt@debugfs_test@read_all_entries: fi-snb-2520m: PASS -> INCOMPLETE (fdo#103713) igt@gem_ringfill@basic-default-hang: fi-pnv-d510: NOTRUN -> DMESG-WARN (fdo#101600) igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b: fi-glk-j4005: PASS -> DMESG-WARN (fdo#106235) ==== Possible fixes ==== igt@kms_flip@basic-flip-vs-wf_vblank: fi-skl-guc: FAIL (fdo#103928) -> PASS igt@kms_frontbuffer_tracking@basic: fi-hsw-4200u: DMESG-FAIL (fdo#102614, fdo#106103) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-b: fi-skl-6700k2: FAIL (fdo#104724, fdo#103191) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-glk-j4005: DMESG-WARN (fdo#106097) -> PASS fdo#101600 https://bugs.freedesktop.org/show_bug.cgi?id=101600 fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#103928 https://bugs.freedesktop.org/show_bug.cgi?id=103928 fdo#104724 https://bugs.freedesktop.org/show_bug.cgi?id=104724 fdo#106097 https://bugs.freedesktop.org/show_bug.cgi?id=106097 fdo#106103 https://bugs.freedesktop.org/show_bug.cgi?id=106103 fdo#106235 https://bugs.freedesktop.org/show_bug.cgi?id=106235 == Participating hosts (38 -> 37) == Additional (2): fi-kbl-7560u fi-pnv-d510 Missing (3): fi-ctg-p8600 fi-ilk-m540 fi-skl-6700hq == Build changes == * Linux: CI_DRM_4150 -> Patchwork_8925 CI_DRM_4150: 93d32416ba4b1dae9451fec28aaa71915d770f51 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4463: 91b5a3ef5516b29584ea4567b0f5ffa18219b29f @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_8925: 20cc4fb19e8fad3e982aa5df72506553f9fe36ab @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4463: 33e58d5583eb7ed3966a1b905f875a1dfa959f6b @ git://anongit.freedesktop.org/piglit == Linux commits == 20cc4fb19e8f drm/dp: add module parameter for the dpcd access max retries == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8925/issues.html _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 18+ messages in thread
* ✗ Fi.CI.BAT: failure for drm/dp: add module parameter for the dpcd access max retries (rev2) 2018-05-07 10:36 [PATCH] drm/dp: add module parameter for the dpcd access max retries Feng Tang 2018-05-07 10:40 ` Chris Wilson 2018-05-07 11:08 ` ✗ Fi.CI.BAT: failure for " Patchwork @ 2018-05-10 9:33 ` Patchwork 2 siblings, 0 replies; 18+ messages in thread From: Patchwork @ 2018-05-10 9:33 UTC (permalink / raw) To: Feng Tang; +Cc: intel-gfx == Series Details == Series: drm/dp: add module parameter for the dpcd access max retries (rev2) URL : https://patchwork.freedesktop.org/series/42803/ State : failure == Summary == Applying: drm/dp: add module parameter for the dpcd access max retries error: corrupt patch at line 9 error: could not build fake ancestor Patch failed at 0001 drm/dp: add module parameter for the dpcd access max retries The copy of the patch that failed is found in: .git/rebase-apply/patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2018-05-10 9:33 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-05-07 10:36 [PATCH] drm/dp: add module parameter for the dpcd access max retries Feng Tang 2018-05-07 10:40 ` Chris Wilson 2018-05-07 21:26 ` Feng Tang 2018-05-07 13:33 ` Chris Wilson 2018-05-07 15:09 ` Daniel Vetter 2018-05-07 23:19 ` Feng Tang 2018-05-08 19:03 ` Feng Tang 2018-05-08 11:33 ` [Intel-gfx] " Chris Wilson 2018-05-08 12:00 ` Daniel Vetter 2018-05-08 23:08 ` [Intel-gfx] " Feng Tang 2018-05-08 19:30 ` Jani Nikula 2018-05-09 6:31 ` Feng Tang 2018-05-09 7:53 ` Jani Nikula 2018-05-09 7:56 ` Feng Tang 2018-05-09 9:28 ` [Intel-gfx] " Jani Nikula 2018-05-10 9:21 ` Feng Tang 2018-05-07 11:08 ` ✗ Fi.CI.BAT: failure for " Patchwork 2018-05-10 9:33 ` ✗ Fi.CI.BAT: failure for drm/dp: add module parameter for the dpcd access max retries (rev2) Patchwork
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.