- 16 Feb, 2016 1 commit
-
-
Maarten Lankhorst authored
Instead of duplicating the functionality now that we no longer need to preserve dpll state we can move to using the upstream suspend helper. Changes since v1: - Call hw readout with all mutexes held. - Rework intel_display_suspend to only assign modeset_restore_state on success. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/56C2E686.5060803@linux.intel.comReviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com>
-
- 15 Feb, 2016 12 commits
-
-
Ben Widawsky authored
This behavior of checking for a shmem backed GEM object was introduced here: commit 4c914c0c Author: Brad Volkin <bradley.d.volkin@intel.com> Date: Tue Feb 18 10:15:45 2014 -0800 drm/i915: Refactor shmem pread setup It is possible for an object to not be a shmem backed GEM object (for example userptr objects). An example of how we hit this failure can be found through copy_batch() in the command parser because we allocate a userptr object for the batch which contains privileged instructions. Userptr calls drm_gem_private_object_init() which explicitly sets the filp to none. NOTE: I manually retyped this from a test machine. So I haven't even compiled this exact patch. v2: Use same logic as from a2a4f916c2f (Kristian, Dave Gordon) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Kristian Høgsberg <krh@bitplanet.net> Cc: Dave Gordon <david.s.gordon@intel.com> Signed-off-by:
Ben Widawsky <benjamin.widawsky@intel.com> Tested-by: Jordan Justen <jordan.l.justen@intel.com> (v1) Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> (v1) Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455047053-2644-1-git-send-email-benjamin.widawsky@intel.com
-
Chris Wilson authored
Unknown parameters, especially structure padding, are expected to invoke rejection with -EINVAL. v2: similar issue exists for context-create Testcase: igt/gem_ctx_create/invalid-pad Testcase: igt/gem_ctx_bad_destroy/invalid-pad Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89602 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93999Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Ville Syrjälä authored
intel_digital_port_connected() lacks one 'else'. There's no actual harm in not having it since each branch has an unconditional return, so it can't accidentally end up in taking two branches instead of just the one. But let's be consistent and add the 'else' anyway. Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Looks like g4x hpd live status bits actually agree with the spec. At least they do on the machine I have, and apparently on Nick Bowler's g4x as well. So gm45 may be the only platform where they don't agree. At least that seems to be the case based on the (somewhat incomplete) logs/dumps in [1], and Daniel has also tested this on his gm45 sometime in the past. So let's change the bits to match the spec on g4x. That actually makes the g4x bits identical to vlv/chv so we can just share the code between those platforms, leaving gm45 as the special case. [1] https://bugzilla.kernel.org/show_bug.cgi?id=52361 Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Nick Bowler <nbowler@draconx.ca> References: https://lists.freedesktop.org/archives/dri-devel/2016-February/100382.htmlReported-by:
Nick Bowler <nbowler@draconx.ca> Cc: stable@vger.kernel.org Fixes: 237ed86c ("drm/i915: Check live status before reading edid") Signed-off-by:
-
Tvrtko Ursulin authored
Code does read-modify-write but the read was outside the lock. It is fine since the caller holds struct mutex, but if we correct this we open up the opportunity for decreasing the mutex duration time since the call to ironlake_enable_drps does not need it any longer since it is covered by the mchdev_lock lock. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
Tvrtko Ursulin authored
It does not look like this code needs to wait atomically? Higher in the call chain it calls the GEM API and I do not see that the section is under any spin locks or such. Signed-off-by:
Dave Gordon <david.s.gordon@intel.com>
-
Tvrtko Ursulin authored
RPS lock must be taken before the struct_mutex to avoid locking inversion. So stop grabbing it for the whole powersave initialization and instead only take it during the sections which need it. Also, struct_mutex is not needed any more since dedicated RPS lock was added in: commit 4fc688ce Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Nov 2 11:14:01 2012 -0700 drm/i915: protect RPS/RC6 related accesses (including PCU) with a new mutex Based on prototype patch by Chris Wilson and a subsequent mailing list discussion involving Ville, Imre, Chris and Daniel. v2: More details in the commit. v3: Use drm_gem_object_unreference_unlocked. (Chris Wilson) Signed-off-by:
-
Tvrtko Ursulin authored
VMA creation and GEM list management need the big lock. v2: Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall) Not to mention drm_gem_object_unreference was there in existing code with no mutex held. v3: Some callers of i915_gem_object_create_stolen_for_preallocated already hold the lock so move the mutex into the other caller as well. v4: Changed to lockdep_assert_held. (Chris Wilson) Signed-off-by:
-
Tvrtko Ursulin authored
We know this never runs from interrupt context so don't need to use the flags variant. Signed-off-by:
-
Maarten Lankhorst authored
Atomic resume was preserving the dpll state because it was required for clearing pll state correctly. If we look at the old_crtc_state for pll to clear this is not needed and the hack can be removed. Changes since v1: - Rename dpll variable to old_dpll. (Ville) Reviewed-by:
-
Daniel Vetter authored
This reverts commit 1b39a917. Chris retracted his reviewed-by (which I failed to notice) and somehow it blows up (I did it again!) as reported by Mika with the below backtrace on module reload: [ 58.170374] IP: [<ffffffffa00e04d3>] intel_logical_ring_cleanup+0x83/0x100 [i915] ... [ 58.170469] Call Trace: [ 58.170479] [<ffffffffa00d0ed4>] i915_gem_cleanup_engines+0x34/0x60 [i915] [ 58.170493] [<ffffffffa0154520>] i915_driver_unload+0x140/0x220 [i915] [ 58.170497] [<ffffffff8154a4f4>] drm_dev_unregister+0x24/0xa0 [ 58.170501] [<ffffffff8154aace>] drm_put_dev+0x1e/0x60 [ 58.170506] [<ffffffffa00912a0>] i915_pci_remove+0x10/0x20 [i915] [ 58.170510] [<ffffffff814766e4>] pci_device_remove+0x34/0xb0 [ 58.170514] [<ffffffff8156e7d5>] __device_release_driver+0x95/0x140 [ 58.170518] [<ffffffff8156e97c>] driver_detach+0xbc/0xc0 [ 58.170521] [<ffffffff8156d883>] bus_remove_driver+0x53/0xd0 [ 58.170525] [<ffffffff8156f3a7>] driver_unregister+0x27/0x50 [ 58.170528] [<ffffffff81475725>] pci_unregister_driver+0x25/0x70 [ 58.170531] [<ffffffff8154c274>] drm_pci_exit+0x74/0x90 [ 58.170543] [<ffffffffa0154cb0>] i915_exit+0x20/0x1aa [i915] [ 58.170548] [<ffffffff8111846f>] SyS_delete_module+0x18f/0x1f0 Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Gordon <david.s.gordon@intel.com> Cc: Nick Hoath <nicholas.hoath@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Chris Wilson authored
intel_rcs_ctx_init() can be interrupted by a signal (if it has to wait upon a full ring to advance). Don't emit an error for this. Testcase: igt/gem_concurrent_blit Signed-off-by:
-
- 14 Feb, 2016 1 commit
-
-
Daniel Vetter authored
Signed-off-by:
-
- 12 Feb, 2016 2 commits
-
-
Abhay Kumar authored
Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12) if this time is already spent in suspend/poweron time. v2: Use CLOCK_BOOTTIME and remove jiffies for panel power cycle delay calculation(Ville). v3: Addressed below comments 1. Tracking time from where last powercycle is initiated. 2. Used ktime_get_bootime() wrapper for boottime clock. 3. Used ktime_ms_delta() to get time difference. v4: Updated v3 change log in detail. v5: Removed static from panel_power_on_time(Stéphane). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:Abhay Kumar <abhay.kumar@intel.com> Reviewed-by:
-
Daniel Vetter authored
Backmerge to get at the new encoder_mask support in atomic helpers. Signed-off-by:
-
- 11 Feb, 2016 14 commits
-
-
Arnd Bergmann authored
After the drm_device_is_unplugged() was removed, the 'dev' variable is now unused, and we get a warning for that: drivers/gpu/drm/msm/msm_fbdev.c: In function 'msm_fbdev_mmap': drivers/gpu/drm/msm/msm_fbdev.c:65:21: error: unused variable 'dev' [-Werror=unused-variable] This removes the variable as well. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Fixes: e9f8250f ("drm/msm: remove the drm_device_is_unplugged check") Signed-off-by:
-
Daniel Vetter authored
The fake agp driver for the intel graphics gart is only needed for ums support. And we ditched that a long time ago: commit 03dae59c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Jul 23 16:27:25 2014 +0200 drm/i915: Ditch UMS config option With this there's no longer the problem that 2 drivers (fake agp driver and the drm/i915 driver) fight over the same piece, which fixes apparent dma leaks detected by CONFIG_DMA_API_DEBUG. Note that the leak isn't real since intel-gtt refcounts and will tear down eventually. But the debug code assumes that when the i915 driver unbinds from the pci device everything should be gone. Which isn't the case if we have intel-agp enabled - userspace might need it. But by ditching this intel-gtt setup and teardown is completely tied to the livetime of the "real" driver. While at it untangle the init ordering a bit - the fake agp wouldn't be initialized correctly if i915.ko loads first. Which isn't a problem since when i915 loads in kms mode you won't need the fake agp support needed by the ums driver ... Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93793Signed-off-by:
-
Mika Kahola authored
It is possible the we request to have a mode that has higher pixel clock than our HW can support. This patch checks if requested pixel clock is lower than the one supported by the HW. The requested mode is discarded if we cannot support the requested pixel clock. This patch applies to TV. V2: - removed computation for max pixel clock V3: - cleanup by removing unnecessary lines V4: - max_pixclk variable renamed as max_dotclk Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
-
Mika Kahola authored
It is possible the we request to have a mode that has higher pixel clock than our HW can support. This patch checks if requested pixel clock is lower than the one supported by the HW. The requested mode is discarded if we cannot support the requested pixel clock. This patch applies to CRT. V2: - removed computation for max pixel clock V3: - cleanup by removing unnecessary lines V4: - max_pixclk variable renamed as max_dotclk Signed-off-by:
-
Mika Kahola authored
It is possible the we request to have a mode that has higher pixel clock than our HW can support. This patch checks if requested pixel clock is lower than the one supported by the HW. The requested mode is discarded if we cannot support the requested pixel clock. This patch applies to SDVO. V2: - removed computation for max pixel clock V3: - cleanup by removing unnecessary lines V4: - max_pixclk variable renamed as max_dotclk Signed-off-by:
-
Mika Kahola authored
It is possible the we request to have a mode that has higher pixel clock than our HW can support. This patch checks if requested pixel clock is lower than the one supported by the HW. The requested mode is discarded if we cannot support the requested pixel clock. This patch applies to DisplayPort MST. V2: - removed computation for max pixel clock V3: - cleanup by removing unnecessary lines V4: - max_pixclk variable renamed as max_dotclk Signed-off-by:
-
Mika Kahola authored
It is possible the we request to have a mode that has higher pixel clock than our HW can support. This patch checks if requested pixel clock is lower than the one supported by the HW. The requested mode is discarded if we cannot support the requested pixel clock. This patch applies to HDMI. V2: - removed computation for max dot clock V3: - cleanup by removing unnecessary lines V4: - max_pixclk variable renamed as max_dotclk - check for stereo mode added Signed-off-by:
-
Mika Kahola authored
It is possible the we request to have a mode that has higher pixel clock than our HW can support. This patch checks if requested pixel clock is lower than the one supported by the HW. The requested mode is discarded if we cannot support the requested pixel clock. This patch applies to DisplayPort. V2: - removed computation for max DOT clock V3: - cleanup by removing unnecessary lines V4: - max_pixclk renamed as max_dotclk Signed-off-by:
-
Carlos Palminha authored
Other bridge drivers don't implement this optional function. Removed dummy code from dw-hdmi brigde driver. Signed-off-by:
Carlos Palminha <palminha@synopsys.com> Signed-off-by:
-
Carlos Palminha authored
Removed dummy mode_fixup. Signed-off-by:
-
Carlos Palminha authored
Removed dummy mode_fixup. Signed-off-by:
-
Lukas Wunner authored
The DRM drivers i915, nouveau and radeon may be compiled with CONFIG_ACPI not set, in which case acpi_dev_present() is undefined. Add a no-op stub for apple_gmux_present() which is used if CONFIG_APPLE_GMUX is not enabled to avoid build breakage. (CONFIG_APPLE_GMUX depends on CONFIG_ACPI.) Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Lukas Wunner <lukas@wunner.de> Signed-off-by:
-
Carlos Palminha authored
Avoids null crash when encoders don't implement mode_fixup. Signed-off-by:
-
Daniele Ceraolo Spurio authored
While running some tests on the scheduler patches with rpm enabled I came across a corruption in the ringbuffer, which was root-caused to the GPU being suspended while commands were being emitted to the ringbuffer. The access to memory was failing because the GPU needs to be awake when accessing stolen memory (where my ringbuffer was located). Since we have this constraint it looks like a sensible idea to check that we hold a refcount when we access the rungbuffer. v2: move the check from ring_begin to ringbuffer iomap time (Chris) v3: update comment (Chris) Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
- 10 Feb, 2016 9 commits
-
-
Carlos Palminha authored
Avoid i2c slave encoder drivers to copy/paste code to implement functions that will only return true. Signed-off-by:
-
Rasmus Villemoes authored
This fails to undo the setup for pin==0; moreover, something interesting happens if the setup failed already at pin==0. Signed-off-by:
Rasmus Villemoes <linux@rasmusvillemoes.dk> Fixes: f899fc64 ("drm/i915: use GMBUS to manage i2c links") Cc: stable@vger.kernel.org Signed-off-by:
-
Daniel Vetter authored
The AGP_INTEL driver provides an interface for very old userspace to control the GART (though the GART itself was only ever emulated on Intel systems). The pci bridge discovery code is also used by the i915.ko driver to set up the GTT on old systems, but it does not require the old userspace interface. When i915.ko selects the old interface, it binds another user to the core GTT routines, and in particular creates a second reference to the scratch pages allocated. This hinders resource leak debugging for when we unload i915.ko as we want to assert that all DMA pages have been released, but we appear to leak because of the secondary interface which persists after i915.ko unloads. All i915.ko users do not require the old /dev/agpgart interface so stop selecting it and simplify our debugging by dropping the historical baggage. Note that by selecting AGP=n it was already possible to unselect AGP_INTEL. But since we've dropped support for any of the AGP stuff long ago there's really no point for this any more. Also note that we still need INTEL_GTT, which is the underlying, shared, driver for the graphics GART on gen1-5. v2: Entirely new commit message (Chris, Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniel Vetter authored
Recently discovered by enabling CONFIG_DMA_API_DEBUG in our CI. By the looks of it broken since forever. v2: Don't forget to set the scratch page back to wb (Chris). Reuse intel_gtt_teardown_scratch_page for that (and fix it up to treat needs_dmar y/n correctly). Cc: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93793Signed-off-by:
-
Arun Siluvery authored
Revision id along with device id is useful in better identification of the HW and its limitations so include this detail in error state. v2: make it clear that it is PCI revision and We might as well dump PCI subsystem details while we update this (Ville, Chris). Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by:
-
Nick Hoath authored
Swap the order of context & engine cleanup, so that contexts are cleaned up first, and *then* engines. This is a more sensible order anyway, but in particular has become necessary since the 'intel_ring_initialized() must be simple and inline' patch, which now uses ring->dev as an 'initialised' flag, so it can now be NULL after engine teardown. This in turn can cause a problem in the context code, which (used to) check the ring->dev->struct_mutex -- causing a fault if ring->dev was NULL. Also rename the cleanup function to reflect what it actually does (cleanup engines, not a ringbuffer), and fix an annoying whitespace issue. v2: Also make the fix in i915_load_modeset_init, not just in i915_driver_unload (Chris Wilson) v3: Had extra stuff in it. v4: Reverted extra stuff (so we're back to v2). Rebased and updated commentary above (Dave Gordon). Signed-off-by:Nick Hoath <nicholas.hoath@intel.com> Signed-off-by:
-
Gabriel Feceoru authored
Some Gen7/8 production parts may have the Display Pipe C fused off. In this case, the display hardware will prevent the enable bit in PIPE_CONF register (for Pipe C) from being set to 1. Fixed by adjusting pipe_count to reflect this. v2: Rename HSW_PIPE_C_DISABLE to IVB_PIPE_C_DISABLE as it already exists on ivybridge (Ville) v3: Remove unnecessary MMIO read, correct the description (Damien) v4: Be more specific in description (Patrick) Signed-off-by:Gabriel Feceoru <gabriel.feceoru@intel.com> Reviewed-by:
Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by:
-
Lyude authored
We accidentally point both cfgcr registers for the second shared DPLL to the same location in i915_reg.h. This results in a lot of hw pipe state mismatches whenever we try to do a modeset that requires allocating the DPLL to a CRTC: [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr1 (expected 0x80000168, found 0x000004a5) [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in base.adjusted_mode.crtc_clock (expected 108000, found 49500) [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock (expected 108000, found 49500) This usually ends up causing blank monitors, since the DPLL never can get set to the right clock. Fixes: 086f8e84 ("drm/i915: Prefix raw register defines with underscore") Signed-off-by:
Lyude <cpaul@redhat.com> Cc: drm-intel-fixes@lists.freedesktop.org Reviewed-by:
-
Rasmus Villemoes authored
The current code fails to call i2c_del_adapter on dev_prev->gmbus[0].adapter, and if the for loop above failed already at i==0, all hell breaks loose when we do the loop body for i = -1,-2,... Signed-off-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
- 09 Feb, 2016 1 commit
-
-
Ville Syrjälä authored
Add a few helpers to get the dimensions of the chroma plane(s). v2: Add kernel-doc (Daniel) v3: Fix kerneldoc "Returns:" style (Daniel) Uninline the functions and check for num_planes (Daniel) v4: Add the required EXPORT_SYMBOL()s Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
