aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2014-03-12drm/radeon/cik: stop the sdma engines in the enable() functionAlex Deucher
We always stop the rings when disabling the engines so just call the stop functions directly from the sdma enable function. This way the rings' status is set correctly on suspend so there are no problems on resume. Fixes resume failures that result in acceleration getting disabled. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2014-03-12drm/radeon/cik: properly set sdma ring status on disableAlex Deucher
When we disable the rings, set the status properly. If not other code pathes may try and use the rings which are not functional at this point. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2014-03-12drm/radeon: fix runpm disabling on non-PX harderAlex Deucher
Make sure runtime pm is disabled on non-PX hardware. Should fix powerdown problems without displays attached. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2014-03-12drm/ttm: don't oops if no invalidate_caches()Rob Clark
A few of the simpler TTM drivers (cirrus, ast, mgag200) do not implement this function. Yet can end up somehow with an evicted bo: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [< (null)>] (null) PGD 16e761067 PUD 16e6cf067 PMD 0 Oops: 0010 [#1] SMP Modules linked in: bnep bluetooth rfkill fuse ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw iptable_filter ip_tables sg btrfs zlib_deflate raid6_pq xor dm_queue_length iTCO_wdt iTCO_vendor_support coretemp kvm dcdbas dm_service_time microcode serio_raw pcspkr lpc_ich mfd_core i7core_edac edac_core ses enclosure ipmi_si ipmi_msghandler shpchp acpi_power_meter mperf nfsd auth_rpcgss nfs_acl lockd uinput sunrpc dm_multipath xfs libcrc32c ata_generic pata_acpi sr_mod cdrom sd_mod usb_storage mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit lpfc drm_kms_helper ttm crc32c_intel ata_piix bfa drm ixgbe libata i2c_core mdio crc_t10dif ptp crct10dif_common pps_core scsi_transport_fc dca scsi_tgt megaraid_sas bnx2 dm_mirror dm_region_hash dm_log dm_mod CPU: 16 PID: 2572 Comm: X Not tainted 3.10.0-86.el7.x86_64 #1 Hardware name: Dell Inc. PowerEdge R810/0H235N, BIOS 0.3.0 11/14/2009 task: ffff8801799dabc0 ti: ffff88016c884000 task.ti: ffff88016c884000 RIP: 0010:[<0000000000000000>] [< (null)>] (null) RSP: 0018:ffff88016c885ad8 EFLAGS: 00010202 RAX: ffffffffa04e94c0 RBX: ffff880178937a20 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000240004 RDI: ffff880178937a00 RBP: ffff88016c885b60 R08: 00000000000171a0 R09: ffff88007cf171a0 R10: ffffea0005842540 R11: ffffffff810487b9 R12: ffff880178937b30 R13: ffff880178937a00 R14: ffff88016c885b78 R15: ffff880179929400 FS: 00007f81ba2ef980(0000) GS:ffff88007cf00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000016e763000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Stack: ffffffffa0306fae ffff8801799295c0 0000000000260004 0000000000000001 ffff88016c885b60 ffffffffa0307669 00ff88007cf17738 ffff88017cf17700 ffff880178937a00 ffff880100000000 ffff880100000000 0000000079929400 Call Trace: [<ffffffffa0306fae>] ? ttm_bo_handle_move_mem+0x54e/0x5b0 [ttm] [<ffffffffa0307669>] ? ttm_bo_mem_space+0x169/0x340 [ttm] [<ffffffffa0307bd7>] ttm_bo_move_buffer+0x117/0x130 [ttm] [<ffffffff81130001>] ? perf_event_init_context+0x141/0x220 [<ffffffffa0307cb1>] ttm_bo_validate+0xc1/0x130 [ttm] [<ffffffffa04e7377>] mgag200_bo_pin+0x87/0xc0 [mgag200] [<ffffffffa04e56c4>] mga_crtc_cursor_set+0x474/0xbb0 [mgag200] [<ffffffff811971d2>] ? __mem_cgroup_commit_charge+0x152/0x3b0 [<ffffffff815c4182>] ? mutex_lock+0x12/0x2f [<ffffffffa0201433>] drm_mode_cursor_common+0x123/0x170 [drm] [<ffffffffa0205231>] drm_mode_cursor_ioctl+0x41/0x50 [drm] [<ffffffffa01f5ca2>] drm_ioctl+0x502/0x630 [drm] [<ffffffff815cbab4>] ? __do_page_fault+0x1f4/0x510 [<ffffffff8101cb68>] ? __restore_xstate_sig+0x218/0x4f0 [<ffffffff811b4445>] do_vfs_ioctl+0x2e5/0x4d0 [<ffffffff8124488e>] ? file_has_perm+0x8e/0xa0 [<ffffffff811b46b1>] SyS_ioctl+0x81/0xa0 [<ffffffff815d05d9>] system_call_fastpath+0x16/0x1b Code: Bad RIP value. RIP [< (null)>] (null) RSP <ffff88016c885ad8> CR2: 0000000000000000 Signed-off-by: Rob Clark <rclark@redhat.com> Reviewed-by: Jérôme Glisse <jglisse@redhat.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Cc: stable@vger.kernel.org
2014-03-12drm/i915: Don't enable display error interrupts from the startDaniel Vetter
We need to enable interrupt processing before all the modeset state is set up. But that means we can fall over when we get a pipe underrun. This shouldn't happen as long as the bios works correctly but as usual this turns out to be wishful thinking. So disable error interrupts at irq install time and rely on the re-enabling code in the modeset functions to take care of this. Note that due to the SDE interrupt handling race we must uncondtionally enable all interrupt sources in SDEIER, hence no need to enable the SERR bit specifically. On gmch platforms we don't have an explicit enable/mask bit for fifo underruns. Fixing this up would require a bit of software tracking, hence is material for a separate patch. To make this possible we need to switch all gmch platforms to the new pipestat interrupt handling scheme Imre implemented for vlv, and then also add a safe form of sw state checking to __cpu_fifo_underrun_reporting_enabled a bit. v2: Also handle the ilk/snb cpu fifo underrun bits accordingly. Spotted by Ville. v3: Also handle the south interrupt underrun bits on ibx. Again spotted by Ville. Reported-by: Rob Clark <robdclark@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-03-12drm/i915: Show cursor status in debugfs/i915_display_infoChris Wilson
I have the occasional absent cursor on i845 and I want to know why. This should help by revealing the last known cursor state. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-12drm/i915: Fix scanline counter fixup on BDWVille Syrjälä
The display interrupts changed on BDW, so the current ILK-HSW specific code in ilk_pipe_in_vblank_locked() doesn't work there. Add the required bits for BDW, and while at it, change the existing code to use nicer looking vblank status bit macros. Also remove the now stale __raw_i915_read16() definition which was left over from the failed gen2 ISR experiment. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73962 Tested-by: Lu Hua <huax.lu@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-03-12drm/i915: Reduce the time we hold struct mutex in intel_pipe_set_base()Ville Syrjälä
We don't need to hold struct_mutex all through intel_pipe_set_base(), just need to hold it while pinning/unpinning the buffers. So reduce the struct_mutext usage in intel_pipe_set_base() just like we did for the sprite code in: commit 82284b6becdbef6d8cd3fb43e8698510833a5129 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Oct 1 18:02:12 2013 +0300 drm/i915: Reduce the time we hold struct mutex in sprite update_plane code The FBC and PSR locking is still entirely fubar. That stuff was previouly done while holding struct_mutex, so leave it there for now. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-12drm/i915: Add a workaround for HSW scanline counter weirdnessVille Syrjälä
On HSW the scanline counter seems to behave differently depending on the output type. eDP on port A does what you would expect an the normal +1 fixup is sufficient to cover it. But on HDMI outputs we seem to need a +2 fixup. Just assume we always need the +2 fixup and accept the slight inaccuracy on eDP. This fixes a regression introduced in: commit 8072bfa6045a264d3913102a35fab125b06603a2 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Oct 28 21:22:52 2013 +0200 drm/radeon: Move the early vblank IRQ fixup to radeon_get_crtc_scanoutpos() That commit removed the heuristic that tried to fix up the timestamps for vblank interrupts that fire a bit too early. Since then the vblank timestamp code would treat some vblank interrupts as spurious since the scanline counter would indicate that vblank_start wasn't reached yet. That in turn lead to incorrect vblank event sequence numbers being reported to userspace, which lead to unsteady framerate in applications such as XBMC which uses them for timing purposes. v2: Remember to call ilk_pipe_in_vblank_locked() on HSW too (Mika) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75725 Tested-by: bugzilla1@gmx.com Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-03-12drm/i915: warn if ring is active before sync flushNaresh Kumar Kachhi
Based on Bspec the command parser must be stopped prior to issuing sync flush. This should be done by the caller of intel_ring_setup_status_page. Patch adds a warning if it is not done. v2: rebased based on new patch (wait for ring to become idle) Signed-off-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-12drm/i915: wait for rings to become idle once disabledNaresh Kumar Kachhi
make sure we wait for rings to become idle once they are disabled. In case of timeout print an error message Signed-off-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> [danvet: Frob patch as suggested by Chris.] Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-12drm/i915: disable rings before HW status page setupNaresh Kumar Kachhi
Rings should be idle before issuing sync_flush (in intel_ring_setup_status_page). This patch moves the ring disabling before doing the HW status page setup. Signed-off-by: Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-12drm/ttm: Work around performance regression with VM_PFNMAPThomas Hellstrom
A performance regression was introduced in TTM in linux 3.13 when we started using VM_PFNMAP for shared mappings. In theory this should've been faster due to less page book-keeping but it appears like VM_PFNMAP + x86 PAT + write-combine is a particularly cpu-hungry combination, as seen by largely increased cpu-usage on r200 GL video playback. Until we've sorted out why, revert to always use VM_MIXEDMAP. Reference: freedesktop.org bugzilla bug #75719 Reported-and-tested-by: <smoki00790@gmail.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Cc: stable@vger.kernel.org
2014-03-11drm/i915: Correct PPGTT total sizeBen Widawsky
Our code allows have a PPGTT that is smaller than the maximum size for GEN6-GEN7. Though I don't think this actually ever occurs, the code may as well work properly and more importantly look correct by using the variable size instead of the HW max. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-11drm/i915/bdw: Use scratch page table for GEN8 PPGTTBen Widawsky
I'm not clear if the hardware is still subject to the same prefetching issues that made us use a scratch page in the first place. In either case, we're using garbage with the current code (we will end up using offset 0). This may be the cause of our current gem_cpu_reloc regression with PPGTT. I cannot test it at the moment. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-10drm/i915: fix typo in display IRQ mask when disabling IRQsImre Deak
Introduced in commit e0e33f8ff6f0b6d286afc314802be4993341bd47 Author: Imre Deak <imre.deak@intel.com> Date: Tue Mar 4 19:23:07 2014 +0200 The impact was luckily minimal, due to the extra check we do against a software pipestat IRQ mask. Caught by Fengguang's 0-day tester. Cc: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-10drm/i915: Allow HDMI+HDMI cloning on g4xVille Syrjälä
BSpec is a bit unclear whether HDMI+HDMI cloning should work on g4x. Tests on real hardware say that it does. Since g4x can't send infoframes to more than one HDMI port anyway, we don't lose anything by allow it. For PCH platforms BSpec explicitly forbids HDMI+HDMI cloning. Whether HDMI+HDMI cloning might also work on VLV is a bit unclear, but since we'd at least lose the capability of sending infoframes to more than one cloned HDMI port, it doesn't seem like a good idea to allow it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73850 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-10drm/i915: Allow HDMI+VGA cloningVille Syrjälä
HDMI+VGA cloning should be supported on all platforms. The only real obstacle is the 1.5x clock adjustment for 12bpc HDMI, but that is now taken care of, so we can allow HDMI+VGA cloning. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73850 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-10drm/i915: Don't use HDMI 12bpc when cloning with other encoder typesVille Syrjälä
When cloning HDMI with other output types, we can't use 12bpc since the clocks for the other encoder types would be off. So have intel_hdmi_compute_config() check if there are other encoders besides HDMI being fed from the same pipe, and if so, pick 8bpc insted if 12bpc. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-10Merge tag 'v3.14-rc6' into drm-intel-next-queuedDaniel Vetter
Linux 3.14-rc6 I need the hdmi/dvi-dual link fixes in 3.14 to avoid ugly conflicts when merging Ville's new hdmi cloning support into my -next tree Conflicts: drivers/gpu/drm/i915/Makefile drivers/gpu/drm/i915/intel_dp.c Makefile cleanup conflicts with an acpi build fix, intel_dp.c is trivial. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-10drm/i915: Make encoder cloning more flexibleVille Syrjälä
Currently we allow encoders to indicate whether they can be part of a cloned set with just one flag. That's not flexible enough to describe the actual hardware capabilities. Instead make it a bitmask of encoder types with which the current encoder can be cloned. For now we set the bitmask to allow DVO+DVO and DVO+VGA, which should match what the old boolean flag allowed. We will add some more cloning options in the future. Note that this patch also removes the encoder.possible_clones setting from encoder setup code - we compute this dynamically. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Add Ville's explanation why removing the encoder possible_clones is save.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-10drm/i915: move dev_priv->suspend aroundDaniel Vetter
When adding new gunk, _always_ think of a good place. Start/end usually just means that this didn't happen, and on top of that results in needless conflicts with other patches doing the same. Introduced in commit 62d5d69b49b6fea9905e36e67cc6c4fc5a17d75f Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Tue Feb 25 17:11:28 2014 +0200 drm/i915: Add suspend count to error state Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-10drm/i915: Avoid requesting a zero-sized stolen objectChris Wilson
The stolen allocator objects loudly if the caller requests a zero-sized object. This is a useful verbose check as in most cases the request should have been pruned much early. Here we just want to silently return before attempting the allocation. Regression from commit 484b41dd70a9fbea894632d8926bbb93f05021c7 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Mar 7 08:57:55 2014 -0800 drm/i915: remove early fb allocation dependency on CONFIG_FB v2 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75963 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-10drm/i915: Prevent use-after-free of inherited framebufferChris Wilson
During KMS takeover, we try to capture the current configuration and preserve it across our initialisation. For a variety of reasons, we may fail this, for example if the current mode was using the legacy VGA plane. Under such circumstances, we discard the fb in the plane config and tried to find a matching fb on another CRTC. This obviously also failed, leaving the plane config fb dangling, pointing to the freed block. Regression from commit 484b41dd70a9fbea894632d8926bbb93f05021c7 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Mar 7 08:57:55 2014 -0800 drm/i915: remove early fb allocation dependency on CONFIG_FB v2 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75963 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-08drm/i915: remove early fb allocation dependency on CONFIG_FB v2Jesse Barnes
By stuffing the fb allocation into the crtc, we get mode set lifetime refcounting for free, but have to handle the initial pin & fence slightly differently. It also means we can move the shared fb handling into the core rather than leaving it out in the fbdev code. v2: null out crtc->fb on error (Daniel) take fbdev fb ref and remove unused error path (Daniel) Requested-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-08drm/i915: Wrap the preallocated BIOS framebuffer and preserve for KMS fbcon v12Jesse Barnes
Retrieve current framebuffer config info from the regs and create an fb object for the buffer the BIOS or boot loader left us. This should allow for smooth transitions to userspace apps once we finish the initial configuration construction. v2: check for non-native modes and adjust (Jesse) fixup aperture and cmap frees (Imre) use unlocked unref if init_bios fails (Jesse) fix curly brace around DSPADDR check (Imre) comment failure path for pin_and_fence (Imre) v3: fixup fixup of aperture frees (Chris) v4: update to current bits (locking & pin_and_fence hack) (Jesse) v5: move fb config fetch to display code (Jesse) re-order hw state readout on initial load to suit fb inherit (Jesse) re-add pin_and_fence in fbdev code to make sure we refcount properly (Je v6: rename to plane_config (Daniel) check for valid object when initializing BIOS fb (Jesse) split from plane_config readout and other display changes (Jesse) drop use_bios_fb option (Chris) update comments (Jesse) rework fbdev_init_bios for clarity (Jesse) drop fb obj ref under lock (Chris) v7: use fb object from plane_config instead (Ville) take ref on fb object (Jesse) v8: put under i915_fastboot option (Jesse) fix fb ptr checking (Jesse) inform drm_fb_helper if we fail to enable a connector (Jesse) drop unnecessary enabled[] modifications in failure cases (Chris) split from BIOS connector config readout (Daniel) don't memset the fb buffer if preallocated (Chris) alloc ifbdev up front and pass to init_bios (Chris) check for bad ifbdev in restore_mode too (Chris) v9: fix up !fastboot bpp setting (Jesse) fix up !fastboot helper alloc (Jesse) make sure BIOS fb is sufficient for biggest active pipe (Jesse) v10:fix up size calculation for proposed fbs (Chris) go back to two pass pipe fb assignment (Chris) add warning for active pipes w/o fbs (Chris) clean up num_pipes checks in fbdev_init and fbdev_restore_mode (Chris) move i915.fastboot into fbdev_init (Chris) v11:make BIOS connector config usage unconditional (Daniel) v12:fix up fb vs pipe size checking (Chris) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-08drm/i915: get_plane_config support for ILK+ v3Jesse Barnes
This should allow BIOS fb inheritance to work on ILK+ machines too. v2: handle tiled BIOS fbs (Kristian) split out common bits (Jesse) v3: alloc fb obj out in _init Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-08drm/i915: get_plane_config for i9xx v13Jesse Barnes
Read out the current plane configuration at init time into a new plane_config structure. This allows us to track any existing framebuffers attached to the plane and potentially re-use them in our fbdev code for a smooth handoff. v2: update for new pitch_for_width function (Jesse) comment how get_plane_config works with shared fbs (Jesse) v3: s/ARGB/XRGB (Ville) use pipesrc width/height (Ville) fix fourcc comment (Bob) use drm_format_plane_cpp (Ville) v4: use fb for tracking fb data object (Ville) v5: fix up gen2 pitch limits (Ville) v6: read out stride as well (Daniel) v7: split out init ordering changes (Daniel) don't fetch config if !CONFIG_FB v8: use proper height in get_plane_config (Chris) v9: fix CONFIG_FB check for modular configs (Jani) v10: add comment about stolen allocation stomping v11: drop hw state readout hunk (Daniel) v12: handle tiled BIOS fbs (Kristian) pull out common bits (Jesse) v13: move fb obj alloc out to _init Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-08drm/i915: add plane_config fetching infrastructure v2Jesse Barnes
Early at init time, we can try to read out the plane config structure and try to preserve it if possible. v2: alloc fb obj at init time after fetching plane config Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-08drm/i915: Do not force non-caching copies for pwrite along shmem pathChris Wilson
We don't always want to write into main memory with pwrite. The shmem fast path in particular is used for memory that is cacheable - under such circumstances forcing the cache eviction is undesirable. As we will always flush the cache when targeting incoherent buffers, we can rely on that second pass to apply the cache coherency rules and so benefit from in-cache copies otherwise. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-08drm/i915: Process page flags once rather than per pwrite/preadChris Wilson
We used to lock individual pages inside the buffer object and so needed to update the page flags every time. However, we now pin the pages into the object for the duration of the pwrite/pread (and hopefully much longer) and so we can forgo the flag updates until we release all the pages. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Brad Volkin <bradley.d.volkin@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: Go OCD on the MakefileDaniel Vetter
Chris suggested to split things up a bit into the different parts of the driver and also sort it all correctly, with the hope that we're trying to organize things a bit better eventually. It should also help newcomers to orient themselves a bit better. v2: - Move intel_pm.c to the core - to make things perfect we should split out the modeset related pm features (psr/fbc) into a separate file. Maybe something Rodrigo can do once the PSR patches have settled. - Split the modesetting sections into core and encoders/outputs. intel_ddi.c is a bit funky since it has core hsw+ support and ddi output support. Whatever. v3: Failed to git add ... v4: Really go ocd, i.e. spelling fix in a comment from Jani. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: Implement command buffer parsing logicBrad Volkin
The command parser scans batch buffers submitted via execbuffer ioctls before the driver submits them to hardware. At a high level, it looks for several things: 1) Commands which are explicitly defined as privileged or which should only be used by the kernel driver. The parser generally rejects such commands, with the provision that it may allow some from the drm master process. 2) Commands which access registers. To support correct/enhanced userspace functionality, particularly certain OpenGL extensions, the parser provides a whitelist of registers which userspace may safely access (for both normal and drm master processes). 3) Commands which access privileged memory (i.e. GGTT, HWS page, etc). The parser always rejects such commands. See the overview comment in the source for more details. This patch only implements the logic. Subsequent patches will build the tables that drive the parser. v2: Don't set the secure bit if the parser succeeds Fail harder during init Makefile cleanup Kerneldoc cleanup Clarify module param description Convert ints to bools in a few places Move client/subclient defs to i915_reg.h Remove the bits_count field OTC-Tracker: AXIA-4631 Change-Id: I50b98c71c6655893291c78a2d1b8954577b37a30 Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: Appease checkpatch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: Refactor shmem pread setupBrad Volkin
The command parser is going to need the same synchronization and setup logic, so factor it out for reuse. v2: Add a check that the object is backed by shmem Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: Avoid div by zero when pixel clock is largeVille Syrjälä
Make sure the line_time_us isn't zero in the gmch watermarks code as that would cause a div by zero. This can be triggered by specifying a very fast pixel clock for the mode. At some point we should probably just switch over to using the same math we use on PCH platforms which avoids such intermediate rounded results. Also we should verify the user provided mode much more rigorously. At the moment we accept pretty much anything. Note that "very fast mode" here means above 74.25 GHz. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Add Ville's clarification of what "very fast" means.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: power domains: add vlv power wellsImre Deak
Based on an early draft from Jesse. Add support for powering on/off the dynamic power wells on VLV by registering its display and dpio dynamic power wells with the power domain framework. For now power on all PHY TX lanes regardless of the actual lane configuration. Later this can be optimized when the PHY side setup enables only the required lanes. Atm, it enables all lanes in all cases. v2: - undef function local COND macro after its last use (Ville) - Take dev_priv->irq_lock around the whole sequence of intel_set_cpu_fifo_underrun_reporting_nolock() and valleyview_disable_display_irqs(). They are short and releasing the lock in between only makes proving correctness more difficult. - sanitize local var names in vlv_power_well_enabled() v3: - rebase on latest -nightly Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Resolve conflict due to my changes in the previous patch. Also throw in an assert_spin_locked for safety. And finally appease checkpatch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: factor out intel_set_cpu_fifo_underrun_reporting_nolockImre Deak
Needed by the next patch, wanting to set the underrun reporting as part of a bigger dev_priv->irq_lock'ed sequence. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Use more customary __ prefix instead of _nolock postfix.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: vlv: factor out valleyview_display_irq_installImre Deak
We'll need to disable/re-enable the display-side IRQs when turning off/on the VLV display power well. Factor out the helper functions for this. For now keep the display IRQs enabled by default, so the functionality doesn't change. This will be changed to enable/disable the IRQs on-demand when adding support for VLV power wells in an upcoming patch. v2: - take the irq spin lock for the whole enable/disable sequence as these can be called with interrupts enabled Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: sanity check power well sw state against hw stateImre Deak
Suggested by Daniel. v2: - sanitize the state checking condition, the original was rather confusing (partly due to the unfortunate naming of i915.disable_power_well) (Ville) - simpler message+backtrace generation by using WARN instead of WARN_ON (Ville) - check if always-on power wells are truly on all the time Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: factor out reset_vblank_counterImre Deak
We need to do the same for other platforms in upcoming patches. v2: - s/p/pipe (Ville) - Call the new helper with the vbl_lock already held. The part it protects is short, so releasing it between pipes only makes proving correctness more difficult. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Resolve conflict with Damien's s/p/pipe/ change.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: sanitize PUNIT register macro definitionsImre Deak
In the upcoming patches we'll need to access the rest of the fields in the punit power gating register, so prepare for that. v2: - add doc reference for the power well subsystem IDs (Jesse) - remove IDs for non-existant DPIO_RX[23] subsystems (Jesse) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: vlv: keep first level vblank IRQs maskedImre Deak
This is a left-over from commit b7e634cc8dcd320123199a18bae0937b40dc28b8 Author: Imre Deak <imre.deak@intel.com> Date: Tue Feb 4 21:35:45 2014 +0200 drm/i915: vlv: don't unmask IIR[DISPLAY_PIPE_A/B_VBLANK] interrupt where we stopped unmasking the vblank IRQs, but left them enabled in the IER register. Disable them in IER too. v2: - remove comment becoming stale after this change (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: check pipe power domain when reading its hw stateImre Deak
We can read out the pipe HW state only if the required power domain is on. If not we consider the pipe to be off. v2: - no change v3: - push down the power domain checks into the specific crtc get_pipe_config handlers (Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Appease checkpatch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: check port power domain when reading the encoder hw stateImre Deak
Since the encoder is tied to its port, we need to make sure the power domain for that port is on before reading out the encoder HW state. Note that this also covers also all connector get_hw_state handlers, since all those just call the corresponding encoder get_hw_state handler, which checks - after this change - for all power domains the connector needs. v2: - no change v3: - push down the power domain checks into the specific encoder get_hw_state handlers (Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: get port power domain in connector detect handlersImre Deak
The connector detect and get_mode handlers need to access the port specific HW blocks to read the EDID etc. Get/put the port power domains around these handlers. v2: - get port power domain for HDMI too (Ville) - get port power domain for the DP,HDMI audio detect handlers (Jesse) - Leave the intel_runtime_pm_get/put in the DP detect function in place. Instead of just removing them, these should be moved to the appropriate power_well enable/disable handlers. We can do this after Paulo's 'Merge PC8 with runtime PM, v2' patchset. v3: - rebased on latest -nightly Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: add port power domainsImre Deak
Parts that poke port specific HW blocks like the encoder HW state readout or connector hotplug detect code need a way to check whether required power domains are on or enable/disable these. For this purpose add a set of power domains that refer to the port HW blocks. Get the proper port power domains during modeset. For now when requesting the power domain for a DDI port get it for a 4 lane configuration. This can be optimized later to request only the 2 lane power domain, when proper support is added on the VLV PHY side for this. Atm, the PHY setup code assumes a 4 lane config in all cases. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: add noop power well handlers instead of NULL checking themImre Deak
Reading code free of special cases wins over the small overhead of calling a noop handler. Suggested by Jesse. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: split power well 'set' handler to separate enable/disable/sync_hwImre Deak
Split the 'set' power well handler into an 'enable', 'disable' and 'sync_hw' handler. This maps more conveniently to higher level operations, for example it allows us to push the hsw package c8 handling into the corresponding hsw/bdw enable/disable handlers and the hsw BIOS hand-over setting into the hsw/bdw sync_hw handler. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Appease checkpatch's whitespace complaints.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: add init power domain to always-on power wellsImre Deak
Whenever we request a power domain it has to guarantee that all HW resources are enabled that are needed to access a HW register associated with that power domain. In case a register is on an always-on power well this won't result in turning on a power well, but it may require enabling some other HW resource. One such resource is the HSW/BDW device D0 state that is required for all register accesses and thus for all power wells/power domains. So far the init power domain (guaranteeing access to all HW registers) was part of the default i9xx always-on power well, but not the HSW/BDW always-on power wells. Add the domain to the latter power wells too. Atm, all the always-on power wells have noop handlers, so this doesn't change the functionality. v2: - clarify semantics of always-on power wells (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: move power domain macros to intel_pm.cImre Deak
These macros are used only locally, so move them to the .c file. No functional change. v2: - add init power domain to always-on power wells in the following - separate - patch (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2026-01-19 06:59:49 +0000