[Intel-gfx] v4.3-rc4: i915: ThinkPad Yoga 12: *ERROR* The master control interrupt lied (SDE)!
The Debian 3.16.0 kernel does not emit the error, but I have not attempted a bisection. The warning was added by: 38cc46d drm/i915/bdw: Ack interrupts before handling them (GEN8) 2014-06-18 (1 year, 4 months ago), Oscar Mateo Follows: v3.15-rc8 Preceedes: 3.17-rc1 This is not present in v3.16, so perhaps not present in the Debian kernel and this is not a regression, but just reporting the condition as intended. Linux Version: v4.3-rc4 Platform: Lenovo ThinkPad Yoga 12 OS: Debian 8.2 $ dmesg | grep -i drm [ 10.918367] [drm] Initialized drm 1.1.0 20060810 [ 11.235005] [drm] Memory usable by graphics device = 4096M [ 11.235009] fb: switching to inteldrmfb from simple [ 11.235093] [drm] Replacing VGA console driver [ 11.241160] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [ 11.241162] [drm] Driver supports precise vblank timestamp query. [ 11.256249] [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0! [ 11.326946] [drm] GMBUS [i915 gmbus dpb] timed out, falling back to bit banging on pin 5 [ 11.344097] [drm] Initialized i915 1.6.0 20150731 for :00:02.0 on minor 0 [ 11.344913] fbcon: inteldrmfb (fb0) is primary device [ 12.462509] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 12.466498] i915 :00:02.0: fb0: inteldrmfb frame buffer device [ 12.794359] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 13.869733] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 13.869894] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 13.870058] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 22.656986] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 257.506246] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 257.506415] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 257.506584] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 257.506746] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 278.722570] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 278.722744] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 278.722908] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 1857.776390] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 1857.776549] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 1857.776710] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! [ 4057.592685] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! -- Darren Hart Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] v4.3-rc4: i915: ThinkPad Yoga 12: *ERROR* The master control interrupt lied (SDE)!
On Mon, Oct 12, 2015 at 10:02:06AM +0300, Jani Nikula wrote: > On Sat, 10 Oct 2015, Darren Hart wrote: > > The Debian 3.16.0 kernel does not emit the error, but I have not attempted a > > bisection. > > > > The warning was added by: > > 38cc46d drm/i915/bdw: Ack interrupts before handling them (GEN8) > > 2014-06-18 (1 year, 4 months ago), Oscar Mateo > > But we don't start hitting the warning right away with that commit, do > we? There's a bug about this with a bisected bad commit [1], please > let's track this there. I did a google search and didn't find any relevant hits for this error. So I reported it here. I should ahve searched the bug list also. I'll do that next time. -- Darren Hart Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 00/12] Enable GPU switching on pre-retina MacBook Pro
On Mon, Jan 11, 2016 at 08:09:20PM +0100, Lukas Wunner wrote: > Enable GPU switching on the pre-retina MacBook Pro (2008 - 2013), v5. > > The main obstacle on these machines is that the panel mode in VBIOS > is bogus. Fortunately gmux can switch DDC independently from the > display, thereby allowing the inactive GPU to probe the panel's EDID. > > In short, vga_switcheroo and apple-gmux are amended with hooks to > switch DDC, DRM core is amended with a drm_get_edid_switcheroo() helper, > and relevant drivers are amended to call that for LVDS outputs. > > The retina MacBook Pro (2012 - present) uses eDP and cannot switch > AUX independently from the main link. The main obstacle there is link > training, I'm currently working on this, it will be addressed in a > future patch set. > > This series is also reviewable on GitHub: > https://github.com/l1k/linux/commits/mbp_switcheroo_v5 > > Changes: > > * New patch [01/12]: vga_switcheroo handler flags > Alex Deucher asked if this series might regress on non-Apple laptops. > To address this concern, I let handlers declare their capabilities in > a bitmask. DRM drivers call drm_get_edid_switcheroo() only if the > handler has set the VGA_SWITCHEROO_CAN_SWITCH_DDC flag. > Currently just one other flag is defined which is used on retinas. > > * Changed patch [02/12]: vga_switcheroo DDC locking > Rename ddc_lock to mux_hw_lock, suggested by Daniel Vetter. > > * New patch [03/12]: track switch state of apple-gmux > Fixes a bug in previous versions of this series which occurred if > the system was suspended while DDC was temporarily switched: > On resume DDC was switched to the wrong GPU. > > * New patches [09/12 - 12/12]: deferred probing > Previously I used connector reprobing if the inactive GPU's driver > loaded before gmux. I've ditched that in favor of deferred driver > probing, which is much simpler. Thanks to Daniel Vetter for the > suggestion. > > Caution: Patch [09/12] depends on a new acpi_dev_present() API which > will land in 4.5 via Rafael J. Wysocki's tree. > > I would particularly be interested in feedback on the handler flags > patch [01/12]. I'm not 100% happy with the number of characters > required to query the flags (e.g.: if (vga_switcheroo_handler_flags() & > VGA_SWITCHEROO_CAN_SWITCH_DDC)), but failed to come up with something > shorter. Thierry Reding used a struct of bools instead of a bitmask > for his recent drm_dp_link_caps patches. Maybe use that instead? > http://lists.freedesktop.org/archives/dri-devel/2015-December/097025.html No objection from the platform-driver-x86 side. I can pull these separately once the core is in, or these can be included with that core (preferred) with my Reviewed-by for 1, 3, 4, and 9. Reviewed-by: Darren Hart -- Darren Hart Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/vlv: reset VLV media force wake request register
On 5/9/14, 5:41, "Jani Nikula" wrote: >Media force wake get hangs the machine when the system is booted without >displays attached. The assumption is that (at least some versions of) >the firmware has skipped some initialization in that case. > >Empirical evidence suggests we need to reset the media force wake >request register in addition to the render one to avoid hangs. > >Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75895 >Reported-by: Imre Deak >Reported-by: Darren Hart >Cc: sta...@vger.kernel.org >Signed-off-by: Jani Nikula Applied to 3.14.2 and tested on MinnowBoardMax A0 hardware (BayTrail-I, Atom E3825). * With no display connected, the boot no longer hangs and DRM prints sensible messages during boot: [5.968837] [drm] GMBUS [i915 gmbus vga] timed out, falling back to bit banging on pin 2 [5.988037] i915 :00:02.0: No connectors reported connected with modes [5.995744] [drm] Cannot find any crtc or sizes - going 1024x768 [6.004716] fbcon: inteldrmfb (fb0) is primary device [6.013066] Console: switching to colour frame buffer device 128x48 [6.034147] i915 :00:02.0: fb0: inteldrmfb frame buffer device [6.041168] i915 :00:02.0: registered panic notifier [6.049820] ACPI: Video Device [GFX0] (multi-head: yes rom: no post: no) [6.058788] acpi device:30: registered as cooling_device3 [6.065111] input: Video Bus as /devices/LNXSYSTM:00/device:00/PNP0A08:00/LNXVIDEO:00/input/input4 [6.075370] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 * If a display is subsequently connected and X is restarted, it behaves as expected. * Booting with a display connected continue to work as expected. Tested-by: Darren Hart Thank you very much Jani! -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/vlv: remove wait for previous GFX clk disable request
Jesse Barnes virtuousgeek.org> writes: > Looks like it was introduced in: > > commit 650ad970a39f8b6164fe8613edc150f585315289 > Author: Imre Deak intel.com> > Date: Fri Apr 18 16:35:02 2014 +0300 > > drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending > force-of > > but I'm not sure why. It has caused problems for us in the past (see > 85250ddff7a603dfe0ec0503a9e6395f79424f61 and > 8d4eee9cd7a170342dc6fbc2ee19ae77031a8cd5) and doesn't seem to be > required, so let's just drop it. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=89611 > Signed-off-by: Jesse Barnes virtuousgeek.org> Thanks Jesse, With this and 1/2 applied I was able to suspend/resume twice in a row successfully on a MinnowBoard MAX dual-core (E3825) with the 0.78 firmware. Tested-by: Darren Hart ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
