[Intel-gfx] [PATCH 06/16] drm/i915: Don't call modeset related functions when display is disabled
Chris Wilson
chris at chris-wilson.co.uk
Sat Aug 24 09:51:23 UTC 2019
Quoting Chris Wilson (2019-04-08 21:50:28)
> Quoting Jani Nikula (2018-10-22 10:00:39)
> > On Mon, 22 Oct 2018, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > > Quoting Jani Nikula (2018-10-22 09:25:45)
> > >> On Fri, 12 Oct 2018, José Roberto de Souza <jose.souza at intel.com> wrote:
> > >> > Display features should not be initialized or deinitialized when
> > >> > display is disabled.
> > >
> > > I completely disagree with this assertion. If the display is disabled,
> > > so must all the associated hw so that we can power down the entire
> > > chipset when idle. That means we have to complete the probe (so we
> > > continue to rely on fuses and in place of accurate fuses pci-id quirks
> > > for the infamous chipsets) and switch it off.
> >
> > That actually doesn't contradict with what I said about
> > HAS_DISPLAY(). In many cases I think the early return on no display is
> > the right thing to do. However, no display isn't the same as display
> > disabled by module parameter (or whatnot)... which does require probe
> > before disable to achieve the power down.
> >
> > But is the power down on display disable by module parameter a
> > requirement for us?
>
> We still see this error in BAT roughly every day:
>
> <7> [557.273023] [drm:intel_power_well_enable [i915]] enabling display
> <7> [557.273553] [drm:i915_redisable_vga_power_on [i915]] Something enabled VGA plane, disabling it
> <4> [557.274207] ------------[ cut here ]------------
> <4> [557.274420] Unclaimed write to register 0x44200
> <4> [557.274637] WARNING: CPU: 2 PID: 370 at drivers/gpu/drm/i915/intel_uncore.c:1034 __unclaimed_reg_debug+0x40/0x50 [i915]
> <4> [557.274643] Modules linked in: i915(+) amdgpu gpu_sched ttm vgem snd_hda_codec_hdmi coretemp btusb crct10dif_pclmul btrtl crc32_pclmul btbcm btintel ghash_clmulni_intel bluetooth cdc_ether usbnet r8152 mii ecdh_generic snd_hda_codec snd_hwdep snd_hda_core snd_pcm prime_numbers pinctrl_cherryview lpc_ich [last unloaded: i915]
> <4> [557.274686] CPU: 2 PID: 370 Comm: rngd Tainted: G U 5.1.0-rc4-CI-CI_DRM_5891+ #1
> <4> [557.274690] Hardware name: GOOGLE Cyan/Cyan, BIOS MrChromebox 02/15/2018
> <4> [557.274829] RIP: 0010:__unclaimed_reg_debug+0x40/0x50 [i915]
> <4> [557.274836] Code: 74 05 5b 5d 41 5c c3 45 84 e4 48 c7 c0 2b 6a 7b a0 48 c7 c6 21 6a 7b a0 48 0f 44 f0 89 ea 48 c7 c7 34 6a 7b a0 e8 b0 a3 a1 e0 <0f> 0b 83 2d 97 46 1b 00 01 5b 5d 41 5c c3 66 90 41 56 41 55 41 89
> <4> [557.274841] RSP: 0018:ffff888079903e30 EFLAGS: 00010082
> <4> [557.274847] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
> <4> [557.274851] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00000000ffffffff
> <4> [557.274856] RBP: 0000000000044200 R08: 0000000000000000 R09: 0000000000000001
> <4> [557.274860] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> <4> [557.274865] R13: ffff88806d820eb0 R14: 0000000000000006 R15: 0000000000000000
> <4> [557.274870] FS: 00007f7c805d2740(0000) GS:ffff888079900000(0000) knlGS:0000000000000000
> <4> [557.274875] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> <4> [557.274879] CR2: 00005647db5bc7d8 CR3: 000000006476c000 CR4: 00000000001006e0
> <4> [557.274884] Call Trace:
> <4> [557.274891] <IRQ>
> <4> [557.275026] fwtable_write32+0x25f/0x2c0 [i915]
> <4> [557.275149] cherryview_irq_handler+0x180/0x210 [i915]
> <4> [557.275170] __handle_irq_event_percpu+0x41/0x2d0
> <4> [557.275177] ? handle_irq_event+0x27/0x50
> <4> [557.275188] handle_irq_event_percpu+0x2b/0x70
> <4> [557.275197] handle_irq_event+0x2f/0x50
> <4> [557.275207] handle_edge_irq+0xee/0x1a0
> <4> [557.275216] handle_irq+0x67/0x160
> <4> [557.275229] do_IRQ+0x5e/0x130
> <4> [557.275240] common_interrupt+0xf/0xf
>
> Precisely because the display is not powered down on request.
We still see this. Every day.
-Chris
More information about the Intel-gfx
mailing list