- 15 Feb, 2016 4 commits
-
-
Tvrtko Ursulin authored
We know this never runs from interrupt context so don't need to use the flags variant. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455022343-15222-1-git-send-email-maarten.lankhorst@linux.intel.comSigned-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
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:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-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:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455048677-19882-3-git-send-email-linux@rasmusvillemoes.dk
-
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:
David Gordon <david.s.gordon@intel.com> Reviewed-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 10 commits
-
-
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: -
Haixia Shi authored
This flag is only used for drm/udl. Signed-off-by:
Haixia Shi <hshi@chromium.org> Reviewed-by:
Stéphane Marchesin <marcheu@chromium.org> Reviewed-by:
David Herrmann <dh.herrmann@gmail.com> Acked-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
-
LABBE Corentin authored
The warning message in drm_mode_parse_command_line_for_connector miss the [drm] at beginning. This patch add it and take the opportunity to convert printk(KERN_WARNING to pr_warn() Signed-off-by:
LABBE Corentin <clabbe.montjoie@gmail.com> Signed-off-by:
-
Insu Yun authored
Since drm_property_create_range can be failed in memory pressure, it needs to be checked and return -ENOMEM. Signed-off-by:
Insu Yun <wuninsu@gmail.com> Signed-off-by:
-
Mika Kahola authored
Skip DDI PLL selection if display type is DSI/MIPI. Signed-off-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
-
Lukas Wunner authored
gmux is a microcontroller built into dual GPU MacBook Pros. On pre-retina MBPs, if we're the inactive GPU, we need apple-gmux to temporarily switch DDC so that we can probe the panel's EDID. The checks for CONFIG_VGA_ARB and CONFIG_VGA_SWITCHEROO are necessary because if either of them is disabled but gmux is present, the driver would never load, even if we're the active GPU. (vga_default_device() would evaluate to NULL and vga_switcheroo_handler_flags() would evaluate to 0.) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115Signed-off-by:
-
Lukas Wunner authored
gmux is a microcontroller built into dual GPU MacBook Pros. On pre-retina MBPs, if we're the inactive GPU, we need apple-gmux to temporarily switch DDC so that we can probe the panel's EDID. The checks for CONFIG_VGA_ARB and CONFIG_VGA_SWITCHEROO are necessary because if either of them is disabled but gmux is present, the driver would never load, even if we're the active GPU. (vga_default_device() would evaluate to NULL and vga_switcheroo_handler_flags() would evaluate to 0.) Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115Tested-by:
-
Lukas Wunner authored
gmux is a microcontroller built into dual GPU MacBook Pros. On pre-retina MBPs, if we're the inactive GPU, we need apple-gmux to temporarily switch DDC so that we can probe the panel's EDID. The checks for CONFIG_VGA_ARB and CONFIG_VGA_SWITCHEROO are necessary because if either of them is disabled but gmux is present, the driver would never load, even if we're the active GPU. (vga_default_device() would evaluate to NULL and vga_switcheroo_handler_flags() would evaluate to 0.) Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=88861 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115Tested-by:
-
Lukas Wunner authored
Centralize gmux' ACPI HID in a header file and add apple_gmux_present(). This can be used by other drivers to activate quirks specific to dual GPU MacBook Pros & Mac Pros. The alternative would be to hardcode DMI or PCI IDs and amend them whenever Apple introduces a new machine. Tested-by:
Darren Hart <dvhart@linux.intel.com> Signed-off-by:
-
Lukas Wunner authored
The pre-retina MacBook Pro uses an LVDS panel and a gmux controller to switch the panel between its two GPUs. The panel mode in VBIOS is notoriously bogus on these machines. Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS if the vga_switcheroo handler is capable of temporarily switching the panel's DDC lines to the discrete GPU. This allows us to retrieve the EDID if the panel is currently muxed to the integrated GPU. This only enables EDID probing on the pre-retina MBP (2008 - 2013). The retina MBP (2012 - present) uses eDP and gmux is not capable of switching AUX separately from the main link on these models. This will be addressed in later patches. List of pre-retina MBPs with dual GPUs, one of them AMD: [MBP 8,2 2011 intel SNB + amd turks pre-retina 15"] [MBP 8,3 2011 intel SNB + amd turks pre-retina 17"] v3: Commit newly added due to introduction of drm_get_edid_switcheroo() wrapper which drivers need to opt-in to. v5: Rebase on "vga_switcheroo: Add handler flags infrastructure", i.e. call drm_get_edid_switcheroo() only if the handler indicates that DDC is switchable. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115Signed-off-by:
-
