summaryrefslogtreecommitdiffstats
path: root/drivers/gpu
Commit message (Collapse)AuthorAgeFilesLines
...
| | * | drm/i915: save/restore GMBUS freq across suspend/resume on gen4Jesse Barnes2014-12-113-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Should probably just init this in the GMbus code all the time, based on the cdclk and HPLL like we do on newer platforms. Ville has code for that in a rework branch, but until then we can fix this bug fairly easily. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76301 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Nikolay <mar.kolya@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * | drm/i915: Remove '& 0xffff' from the mask given to WA_REG()Damien Lespiau2014-12-101-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We may be hidding bugs by doing that, so let remove it and have the actual mask value shine through, for better or worse. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * | drm/i915: Invert the mask and val arguments in wa_add() and WA_REG()Damien Lespiau2014-12-101-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While trying to unify the order of those arguments throughout the driver, Daniel noticed what we were inverting them in this part of the code. Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * | drm/i915/bdw: Fix the write setting up the WIZ hashing modeDamien Lespiau2014-12-103-8/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I was playing with clang and oh surprise! a warning trigerred by -Wshift-overflow (gcc doesn't have this one): WA_SET_BIT_MASKED(GEN7_GT_MODE, GEN6_WIZ_HASHING_MASK | GEN6_WIZ_HASHING_16x4); drivers/gpu/drm/i915/intel_ringbuffer.c:786:2: warning: signed shift result (0x28002000000) requires 43 bits to represent, but 'int' only has 32 bits [-Wshift-overflow] WA_SET_BIT_MASKED(GEN7_GT_MODE, ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/intel_ringbuffer.c:737:15: note: expanded from macro 'WA_SET_BIT_MASKED' WA_REG(addr, _MASKED_BIT_ENABLE(mask), (mask) & 0xffff) Turned out GEN6_WIZ_HASHING_MASK was already shifted by 16, and we were trying to shift it a bit more. The other thing is that it's not the usual case of setting WA bits here, we need to have separate mask and value. To fix this, I've introduced a new _MASKED_FIELD() macro that takes both the (unshifted) mask and the desired value and the rest of the patch ripples through from it. This bug was introduced when reworking the WA emission in: Commit 7225342ab501befdb64bcec76ded41f5897c0855 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Tue Oct 7 17:21:26 2014 +0300 drm/i915: Build workaround list in ring initialization v2: Invert the order of the mask and value arguments (Daniel Vetter) Rewrite _MASKED_BIT_ENABLE() and _MASKED_BIT_DISABLE() with _MASKED_FIELD() (Jani Nikula) Make sure we only evaluate 'a' once in _MASKED_BIT_ENABLE() (Dave Gordon) Add check to ensure the value is within the mask boundaries (Chris Wilson) v3: Ensure the the value and mask are 16 bits (Dave Gordon) Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * | drm/i915: Don't complain about stolen conflicts on gen3Daniel Vetter2014-12-101-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Apparently stuff works that way on those machines. I agree with Chris' concern that this is a bit risky but imo worth a shot in -next just for fun. Afaics all these machines have the pci resources allocated like that by the BIOS, so I suspect that it's all ok. This regression goes back to commit eaba1b8f3379b5d100bd146b9a41d28348bdfd09 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jul 4 12:28:35 2013 +0100 drm/i915: Verify that our stolen memory doesn't conflict Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=76983 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71031 Tested-by: lu hua <huax.lu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Paul Menzel <paulepanter@users.sourceforge.net> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * | drm/i915: resume MST after reading back hw stateDave Airlie2014-12-081-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise the MST resume paths can hit DPMS paths which hit state checker paths, which hit WARN_ON, because the state checker is inconsistent with the hw. This fixes a bunch of WARN_ON's on resume after undocking. Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * | drm/i915: Handle inaccurate time conversion issuesDaniel Vetter2014-12-051-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So apparently jiffies<->nsec<->ktime isn't accurate or something. At elast if we timeout there's occasionally still a few hundred us left (in a 2 second timeout). Stuff I've tried and thrown out again: - Sampling the before timestamp before jiffies. Doesn't improve test path rate at all. - Using jiffies. Way to inaccurate, which means way too much drift with signals plus automatic ioctl restarting in userspace. In hindsight we should have used an absolute timeout, but hey we need something for v3 of the i915 gem wait interfaces ;-) - Trying to figure out where accuracy gets lost. gl testcase really don't care all that much about this (as long as isn't not massively off), it's just that the testcase gets a bit upset if it receives an EITME with timeout > 0. So as long as we're in the ballbark it's good enough. So patch everything up if we're at most one jiffies off. I get's me a solid test again. This regression is probably introduced in commit 5ed0bdf21a85d78e04f89f15ccf227562177cbd9 Author: Thomas Gleixner <tglx@linutronix.de> Date: Wed Jul 16 21:05:06 2014 +0000 drm: i915: Use nsec based interfaces Use ktime_get_raw_ns() and get rid of the back and forth timespec conversions. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: John Stultz <john.stultz@linaro.org> Probably because I'm too lazy to confirm myself and still waiting for QA ;-) Cc: Thomas Gleixner <tglx@linutronix.de> Cc: John Stultz <john.stultz@linaro.org> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82749 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * | drm/i915: compute wait_ioctl timeout correctlyDaniel Vetter2014-12-052-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We've lost the +1 required for correct timeouts in commit 5ed0bdf21a85d78e04f89f15ccf227562177cbd9 Author: Thomas Gleixner <tglx@linutronix.de> Date: Wed Jul 16 21:05:06 2014 +0000 drm: i915: Use nsec based interfaces Use ktime_get_raw_ns() and get rid of the back and forth timespec conversions. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: John Stultz <john.stultz@linaro.org> So fix this up by reinstating our handrolled _timeout function. While at it bother with handling MAX_JIFFIES. v2: Convert to usecs (we don't care about the accuracy anyway) first to avoid overflow issues Dave Gordon spotted. v3: Drop the explicit MAX_JIFFY_OFFSET check, usecs_to_jiffies should take care of that already. It might be a bit too enthusiastic about it though. v4: Chris has a much nicer color, so use his implementation. This requires to export nsec_to_jiffies from time.c. Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dave Gordon <david.s.gordon@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82749 Cc: Thomas Gleixner <tglx@linutronix.de> Cc: John Stultz <john.stultz@linaro.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: John Stultz <john.stultz@linaro.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| | * | drm/i915: don't always do full mode sets when infoframes are enabledJesse Barnes2014-12-051-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Partial revert of commit 206645910b9796bff13fcdb67bdca166b724ba62 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Nov 5 14:26:09 2014 -0800 drm/i915: check for audio and infoframe changes across mode sets v2 References: https://bugs.freedesktop.org/show_bug.cgi?id=86683 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Li Xu <li.l.xu@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * | | Merge tag 'topic/core-stuff-2014-12-10' of ↵Dave Airlie2014-12-114-18/+41
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next Merge drm core fixes from Daniel. * tag 'topic/core-stuff-2014-12-10' of git://anongit.freedesktop.org/drm-intel: drm: Zero out DRM object memory upon cleanup drm: fix a typo in a comment drm: fix a word repetition in a comment drm: Fix memory leak at error path of drm_read() drm/Documentation: Fix rowspan value in drm-kms-properties drm/edid: Restore kerneldoc consistency drm/edid: new drm_edid_block_checksum helper function V3 drm/edid: shorten log output in case of all zeroes edid block drm/edid: move drm_edid_is_zero to top, make edid argument const
| | * | | drm: Zero out DRM object memory upon cleanupThierry Reding2014-12-101-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Drivers where the DRM objects have a lifetime that extends beyond that of the DRM device need to zero out the DRM object memory to void stale data such as properties. The DRM core code expects to operate on newly allocated and zeroed out objects and will behave unexpectedly, such as add duplicate properties, otherwise. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm: fix a typo in a commentMartin Peres2014-12-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Spotted while reviewing the DRM changes in Linux 3.18 for LinuxFR. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm: fix a word repetition in a commentMartin Peres2014-12-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Spotted while reviewing the DRM changes in Linux 3.18 for LinuxFR. CC: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Martin Peres <martin.peres@free.fr> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm: Fix memory leak at error path of drm_read()Takashi Iwai2014-12-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Note that the read manpages explicitly states that the read position is undefined on error. Since EFAULT is just a userspace bug we are therefore fine with just dropping the event on the floor. Signed-off-by: Takashi Iwai <tiwai@suse.de> [danvet: Add note that just dropping the event is ok.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/edid: Restore kerneldoc consistencyThierry Reding2014-12-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 18df89fef2d5 ("drm: Decouple EDID parsing from I2C adapter") renamed the adapter parameter of the drm_do_probe_ddc_edid function to data but didn't update the kerneldoc accordingly. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/edid: new drm_edid_block_checksum helper function V3Stefan Brüns2014-12-011-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function will also be used by a later patch, so factor it out. V2: make raw_edid const, define/declare before first use V3: fix erroneuos removal of csum variable Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/edid: shorten log output in case of all zeroes edid blockStefan Brüns2014-12-011-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no need to dump the whole EDID block in case it contains no information. Just print a single line stating the block is empty instead of 8 lines containing only zeroes. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | drm/edid: move drm_edid_is_zero to top, make edid argument constStefan Brüns2014-12-011-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drm_edid_is_zero will be used by drm_edid_block valid, move it up. raw_edid argument can be const. Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | | drm/fb: add support for tiled monitor configurations. (v2)Dave Airlie2014-12-092-23/+122
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds fbdev/con support for tiled monitors, so that we only set a mode on the correct half of the monitor, or span the two halves if needed. v2: remove unneeded ERROR, fix | vs || Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | | drm/tile: expose the tile property to userspace (v3)Dave Airlie2014-12-093-0/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This takes the tiling info from the connector and exposes it to userspace, as a blob object in a connector property. The contents of the blob is ABI. v2: add property + function documentation. v3: move property setup from previous patch. add boilerplate + fix long line (Daniel) Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | | drm/connector: store tile information from displayid (v3)Dave Airlie2014-12-092-3/+146
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This creates a tile group from DisplayID block, and stores the pieces of parsed info from the DisplayID block into the connector. v2: add missing signoff, add new connector bits to docs. v3: remove some debugging. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | | drm/mst: cached EDID for logical ports (v2)Dave Airlie2014-12-092-3/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Logical ports are never going to have EDID changes, they are used for the internal ports on MST monitors. We cache the EDIDs from these to save time at MST probe. v2: drop misplace tile property line, meant for other patch. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | | drm: add tile_group support. (v3)Dave Airlie2014-12-091-0/+99
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A tile group is an identifier shared by a single monitor, DisplayID topology has 8 bytes we can use for this, just use those for now until something else comes up in the future. We assign these to an idr and use the idr to tell userspace what connectors are in the same tile group. DisplayID v1.3 says the serial number must be unique for displays from the same manufacturer. v2: destroy idr (dvdhrm) add docbook (danvet) airlied:- not sure how to make docbook add fns to tile group section. v3: fix missing unlock. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | | drm/dp-mst: Remove branches before dropping the referenceDaniel Vetter2014-12-091-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we unplug a dp mst branch we unreference the entire tree from the root towards the leaves. Which is ok, since that's the way the pointers and so also the refcounts go. But when we drop the reference we must make sure that we remove the branches/ports from the lists/pointers before dropping the reference. Otherwise the get_validated functions will still return it instead of returning NULL (which indicates a potentially on-going unplug). The mst branch destroy gets this right for ports: First it deletes the port from the ports list, then it unrefs. But the ports destroy function gets it wrong: First it unrefs, then it drops the ref. Which means a zombie mst branch can still be validate with get_validated_mstb_ref when it shouldn't. Fix this. This should address a backtrace Dave dug out somewhere on unplug: [<ffffffffa00cc262>] drm_dp_mst_get_validated_mstb_ref_locked+0x92/0xa0 [drm_kms_helper] [<ffffffffa00cc211>] drm_dp_mst_get_validated_mstb_ref_locked+0x41/0xa0 [drm_kms_helper] [<ffffffffa00cc2aa>] drm_dp_get_validated_mstb_ref+0x3a/0x60 [drm_kms_helper] [<ffffffffa00cc2fb>] drm_dp_payload_send_msg.isra.14+0x2b/0x100 [drm_kms_helper] [<ffffffffa00cc547>] drm_dp_update_payload_part1+0x177/0x360 [drm_kms_helper] [<ffffffffa015c52e>] intel_mst_disable_dp+0x3e/0x80 [i915] [<ffffffffa013d60b>] haswell_crtc_disable+0x1cb/0x340 [i915] [<ffffffffa0136739>] intel_crtc_control+0x49/0x100 [i915] [<ffffffffa0136857>] intel_crtc_update_dpms+0x67/0x80 [i915] [<ffffffffa013fa59>] intel_connector_dpms+0x59/0x70 [i915] [<ffffffffa015c752>] intel_dp_destroy_mst_connector+0x32/0xc0 [i915] [<ffffffffa00cb44b>] drm_dp_destroy_port+0x6b/0xa0 [drm_kms_helper] [<ffffffffa00cb588>] drm_dp_destroy_mst_branch_device+0x108/0x130 [drm_kms_helper] [<ffffffffa00cb3cd>] drm_dp_port_teardown_pdt+0x3d/0x50 [drm_kms_helper] [<ffffffffa00cdb79>] drm_dp_mst_handle_up_req+0x499/0x540 [drm_kms_helper] [<ffffffff810d9ead>] ? trace_hardirqs_on_caller+0x15d/0x200 [<ffffffffa00cdc73>] drm_dp_mst_hpd_irq+0x53/0xa00 [drm_kms_helper] [<ffffffffa00c7dfb>] ? drm_dp_dpcd_read+0x1b/0x20 [drm_kms_helper] [<ffffffffa0153ed8>] ? intel_dp_dpcd_read_wake+0x38/0x70 [i915] [<ffffffffa015a225>] intel_dp_check_mst_status+0xb5/0x250 [i915] [<ffffffffa015ac71>] intel_dp_hpd_pulse+0x181/0x210 [i915] [<ffffffffa01104f6>] i915_digport_work_func+0x96/0x120 [i915] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | | drm/fb_helper: move deferred fb checking into restore mode (v2)Dave Airlie2014-12-091-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On MST systems the monitors don't appear when we set the fb up, but plymouth opens the drm device and holds it open while they come up, when plymouth finishes and lastclose gets called we don't do the delayed fb probe, so the monitor never appears on the console. Fix this by moving the delayed checking into the mode restore. v2: Daniel suggested that ->delayed_hotplug is set under the mode_config mutex, so we should check it under that as well, while we are in the area. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | | drm/dp: retry AUX transactions 32 times (v1.1)Dave Airlie2014-12-091-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At least on two MST devices I've tested with, when they are link training downstream, they are totally unable to handle aux ch msgs, so they defer like nuts. I tried 16, it wasn't enough, 32 seems better. This fixes one Dell 4k monitor and one of the MST hubs. v1.1: fixup comment (Tom). Acked-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
| * | | | Merge branch 'drm_iommu_v15' of ↵Dave Airlie2014-12-0814-0/+3111
| |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://github.com/markyzq/kernel-drm-rockchip into drm-next Merge rockchip GPU support. This has a branch in common with the iommu tree, hopefully the process works. * 'drm_iommu_v15' of https://github.com/markyzq/kernel-drm-rockchip: dt-bindings: video: Add documentation for rockchip vop dt-bindings: video: Add for rockchip display subsytem drm: rockchip: Add basic drm driver dt-bindings: iommu: Add documentation for rockchip iommu iommu/rockchip: rk3288 iommu driver
| | * | | | drm: rockchip: Add basic drm driverMark Yao2014-12-0214-0/+3111
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the basic structure of a DRM Driver for Rockchip Socs. Signed-off-by: Mark Yao <mark.yao@rock-chips.com> Signed-off-by: Daniel Kurtz <djkurtz@chromium.org> Acked-by: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Rob Clark <robdclark@gmail.com>
| * | | | | Merge branch 'amdkfd-next-3.19' of ↵Dave Airlie2014-12-081-1/+12
| |\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~gabbayo/linux into drm-next As discussed on irc, I'm sending a pull request with one important change: - Disable support for 32-bit user processes. This is done due to AMD's decision to remove support for 32-bit user processes on Linux for its HSA stack. * 'amdkfd-next-3.19' of git://people.freedesktop.org/~gabbayo/linux: amdkfd: Disable support for 32-bit user processes
| | * | | | | amdkfd: Disable support for 32-bit user processesOded Gabbay2014-12-051-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch checks if the process that opens the /dev/kfd device is 32-bit process. If so, it returns -EPERM and prints a warning message in dmesg. This is done to prevent 32-bit user processes from using amdkfd, and hence, HSA features. AMD's HSA userspace stack will also support only 64-bit processes on Linux. Reviewed-by: Alexey Skidanov <alexey.skidanov@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>
| * | | | | | Merge tag 'v3.18' into drm-nextDave Airlie2014-12-0812-50/+92
| |\ \ \ \ \ \ | | |/ / / / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux 3.18 Backmerge Linus tree into -next as we had conflicts in i915/radeon/nouveau, and everyone was solving them individually. * tag 'v3.18': (57 commits) Linux 3.18 watchdog: s3c2410_wdt: Fix the mask bit offset for Exynos7 uapi: fix to export linux/vm_sockets.h i2c: cadence: Set the hardware time-out register to maximum value i2c: davinci: generate STP always when NACK is received ahci: disable MSI on SAMSUNG 0xa800 SSD context_tracking: Restore previous state in schedule_user slab: fix nodeid bounds check for non-contiguous node IDs lib/genalloc.c: export devm_gen_pool_create() for modules mm: fix anon_vma_clone() error treatment mm: fix swapoff hang after page migration and fork fat: fix oops on corrupted vfat fs ipc/sem.c: fully initialize sem_array before making it visible drivers/input/evdev.c: don't kfree() a vmalloc address cxgb4: Fill in supported link mode for SFP modules xen-netfront: Remove BUGs on paged skb data which crosses a page boundary mm/vmpressure.c: fix race in vmpressure_work_fn() mm: frontswap: invalidate expired data on a dup-store failure mm: do not overwrite reserved pages counter at show_mem() drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6 ... Conflicts: drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/nouveau/nouveau_drm.c drivers/gpu/drm/radeon/radeon_cs.c
| * | | | | | Merge tag 'drm-intel-next-fixes-2014-12-04' of ↵Dave Airlie2014-12-059-93/+230
| |\ \ \ \ \ \ | | | |_|_|/ / | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next Fixes for 3.20. I did stick the gen3/4 reset work from Ville in because we have an awful lot of gen4 mesa hangs, and with this reset should also work on vintage i965g/gm (we already have reset for g4x/gen4.5). So should help to appease users suffering from these hangs. Otherwise all over. This is the last 3.20 pull from me, from here on Jani will take over. By Ville Syrjälä (8) and others * tag 'drm-intel-next-fixes-2014-12-04' of git://anongit.freedesktop.org/drm-intel: drm/i915: Reject modeset when the same digital port is used more than once drm/i915: mask RPS IRQs properly when disabling RPS drm/i915: Tune down spurious CRC interrupt warning drm/i915: Fix context object leak for legacy contexts drm/i915/skl: Update in Gen9 multi-engine forcewake range drm/i915/eDP: When enabling panel VDD cancel pending disable worker drm/i915: Handle runtime pm in the CRC setup code drm/i915: Disable crtcs gracefully before GPU reset on gen3/4 drm/i915: Grab modeset locks for GPU rest on pre-ctg drm/i915: Implement GPU reset for g33 drm/i915: Implement GPU reset for 915/945 drm/i915: Restore the display config after a GPU reset on gen4 drm/i915: Fix gen4 GPU reset drm/i915: Stop gathering error states for CS error interrupts drm/i915: Disallow pin ioctl completely for kms drivers drm/i915: Only warn the first time we attempt to mmio whilst suspended drm/i915/chv: Enable AVI, SPD and HDMI infoframes for CHV. drm/i915: Don't clobber crtc->new_config when nothing changes
| | * | | | | drm/i915: Reject modeset when the same digital port is used more than onceVille Syrjälä2014-12-031-0/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On pre-HSW we have two encoders per digital port: one HDMI, one DP. However they are the same physical port in hardware and we can't enable both at the same time. Reject the modeset if the user attempts this. So far we've been saved by the fact that we never see both HDMI and DP connectors as connected. But if the user decides to force a mode anyway, all kinds of funny stuff might happen. Unfortunately we don't seem to have any way to inform userspace that such configurations are invalid except by returning an error from setcrtc. possible_clones only covers real cloning situations, and looking at the connector names doesn't work either since we don't always register both connectors for the same port. I suppose the only way to fix that would be to expose only a single encoder per digital port like we do on HSW+ but that would be a fairly large undertaking for little gain. kms_setmode hits this since it forces modes on non-connected VGA and HDMI connectors. Previosuly it just resulted in weirdness such as failed link training. With this patch it will now get an error back from the kernel and will die with an assert since it thinks that the configuration should be fine. v2: Deal with INTEL_OUTPUT_UNKNOWN (Paulo) Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | | drm/i915: mask RPS IRQs properly when disabling RPSImre Deak2014-12-031-7/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Atm, igt/gem_reset_stats can trigger the recently added WARN on left-over PM_IIR bits in gen6_enable_rps_interrupts(). There are two reasons for this: 1. we call intel_enable_gt_powersave() without a preceeding intel_disable_gt_powersave() 2. gen6_disable_rps_interrupts() doesn't mask interrupts in PM_IMR 1. means RPS interrupts will remain enabled and can be serviced during the HW initialization after a GPU reset. 2. means even if we called gen6_disable_rps_interrupts() any new RPS interrupt during RPS initialization would still propagate to PM_IIR too early (though wouldn't be serviced). This patch solves the 2. issue by also masking interrupts in PM_IMR, the following patch fixes 1. getting rid of the WARN. This also makes intel_enable_gt_powersave() and intel_disable_gt_powersave() more symmetric. Since gen6_disable_rps_interrupts() is called during driver loading with i915 interrupts disabled add a new version of gen6_disable_pm_irq() that doesn't WARN for this. Also while at it, get the irq_lock around the whole PM_IMR/IER/IIR programming sequence and make sure that any queued PM_IIR bit is also cleared. The WARN was caught by PRTS after I sent my previous RPS sanitizing patchset and I could easily reproduce it on HSW. To actually fix it we also need the next patch. Reported-by: He, Shuang <shuang.he@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | | drm/i915: Tune down spurious CRC interrupt warningDaniel Vetter2014-12-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't really synchronously turn them off from debugfs. We try to avoid hitting them too badly by waiting one vblank, but apparently the irq handler can still race through that gap. Since this isn't really all that important for testcases, only for debugging CRC issues let's tune it down to a debug message. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82602 Cc: Damien Lespiau <damien.lespiau@intel.com> Acked-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| | * | | | | drm/i915: Fix context object leak for legacy contextsThomas Daniel2014-12-031-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Dynamic context pinning for LRCs introduced a leak in legacy mode. Reinstate context unreference in i915_gem_free_request for legacy contexts. Leak reported by i-g-t/drv_module_reload fixed by this patch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86507 Signed-off-by: Thomas Daniel <thomas.daniel@intel.com> Reviewed-by: John Harrison<John.C.Harrison@Intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | | drm/i915/skl: Update in Gen9 multi-engine forcewake rangeAkash Goel2014-12-031-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Updates in forcewake range for Render/Media/Common power wells for Gen9. Signed-off-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Zhe Wang <zhe1.wang@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | | drm/i915/eDP: When enabling panel VDD cancel pending disable workerEgbert Eich2014-12-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before testing if the panel VDD is enabled on eDP cancel any pending disable worker. This makes sure the worker will be triggered with a delay from the last time edp_panel_vdd_schedule_off() is called, not the first time. This avoids unnecessary overhead. https://bugs.freedesktop.org/show_bug.cgi?id=86201 v2: use cancel_delayed_work() instead of cancel_delayed_work_sync() as the pps_mutexes will provide the required serialization with edp_panel_vdd_work() while the sync variant may deadlock. Suggested by Ville Syrjälä <ville.syrjala@linux.intel.com>. Made commit message a bit clearer. Signed-off-by: Egbert Eich <eich@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | | drm/i915: Handle runtime pm in the CRC setup codeDaniel Vetter2014-12-031-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The crc code doesn't handle anything really that could drop the register state (by design so that we have less complexity). Which means userspace may only start crc capture once the pipe is fully set up. With an i-g-t patch this will be the case, but there's still the problem that this results in obscure unclaimed register write failures. Which is a pain to debug. So instead make sure we don't have the basic unclaimed register write failure by grabbing runtime pm references. And reject completely invalid requests with -EIO. This is still racy of course, but for a test library we don't really care - if userspace shuts down the pipe right afterwards the entire setup will be lost anyway. v2: Put instead of get, spotted by Damien. Also explain the runtime pm dance. v3: There's really no need for rpm get/put since power_is_enabled only checks software state (Damien). References: https://bugs.freedesktop.org/show_bug.cgi?id=86092 Cc: Damien Lespiau <damien.lespiau@intel.com> (v2) Tested-by: lu hua <huax.lu@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| | * | | | | drm/i915: Disable crtcs gracefully before GPU reset on gen3/4Ville Syrjälä2014-12-032-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GPU reset also resets the display on gen3/4. The g33 docs say we should disable all planes before flipping the reset switch. Just disable all the crtcs instead. That seems a nicer thing to do anyway. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | | drm/i915: Grab modeset locks for GPU rest on pre-ctgVille Syrjälä2014-12-034-37/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On gen4 and earlier the GPU reset also resets the display, so we should protect against concurrent modeset operations. Grab all the modeset locks around the entire GPU reset dance, remebering first ti dislogde any pending page flip to make sure we don't deadlock. Any pageflip coming in between these two steps should fail anyway due to reset_in_progress, so this should be safe. This fixes a lot of failed asserts in the modeset code when there's a modeset racing with the reset. Naturally the asserts aren't happy when the expected state has disappeared. v2: Drop UMS checks, complete pending flips after the reset (Daniel) Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | | drm/i915: Implement GPU reset for g33Ville Syrjälä2014-12-032-3/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | g33 seems to sit somewhere between the 915/945/965 style and the g4x style. The bits look like g4x, but we still need to do a full reset including display. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | | drm/i915: Implement GPU reset for 915/945Ville Syrjälä2014-12-033-14/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 915/945 have the same reset registers as 965, so share the code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | | drm/i915: Restore the display config after a GPU reset on gen4Ville Syrjälä2014-12-031-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On pre-ctg GPU reset also resets the display hardware. Force a mode restore after the GPU reset, and also re-init clock gating. v2: Use intel_modeset_init_hw() instead of intel_init_clock_gating() in case more relevant stuff gets added there at some point Restore interrupts after the reset as well Tested-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | | drm/i915: Fix gen4 GPU resetVille Syrjälä2014-12-032-27/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On pre-ctg the reset bit directly controls the reset signal. We must assert it for >=20usec and then deassert it. Bit 1 is a RO status bit which should also go down when the reset is no longer asserted. Tested-by: Kenneth Graunke <kenneth@whitecape.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | | drm/i915: Stop gathering error states for CS error interruptsDaniel Vetter2014-12-031-18/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's quite a few bug reports with error states where the error reasons makes just about no sense at all. Like dying on tlbs for a display plane that's not even there. Also users don't really report a lot of bad side effects generally, just the error states. Furthermore we don't even enable these interrupts any more on gen5+ (though the handling code is still there). So this mostly concerns old platforms. Given all that lets make our lives a bit easier and stop capturing error states, in the hopes that we can just ignore them. In case that's not true and the gpu indeed dies the hangcheck should eventually kick in. And I've left some debug log in to make this case noticeble. Referenced bug is just an example. v2: Fix missing \n Jani spotted. References: https://bugs.freedesktop.org/show_bug.cgi?id=82095 References: https://bugs.freedesktop.org/show_bug.cgi?id=85944 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | | drm/i915: Disallow pin ioctl completely for kms driversDaniel Vetter2014-12-031-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem here is that SNA pins batchbuffers to etch out a bit more performance. Iirc it started out as a w/a for i830M (which we've implemented in the kernel since a long time already). The problem is that the pin ioctl wasn't added in commit d23db88c3ab233daed18709e3a24d6c95344117f Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri May 23 08:48:08 2014 +0200 drm/i915: Prevent negative relocation deltas from wrapping Fix this by simply disallowing pinning from userspace so that the kernel is in full control of batch placement again. Especially since distros are moving towards running X as non-root, so most users won't even be able to see any benefits. UMS support is dead now, but we need this minimal patch for backporting. Follow-up patch will remove the pin ioctl code completely. Note to backporters: You must have both commit b45305fce5bb1abec263fcff9d81ebecd6306ede Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Dec 17 16:21:27 2012 +0100 drm/i915: Implement workaround for broken CS tlb on i830/845 which laned in 3.8 and commit c4d69da167fa967749aeb70bc0e94a457e5d00c1 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Sep 8 14:25:41 2014 +0100 drm/i915: Evict CS TLBs between batches which is also marked cc: stable. Otherwise this could introduce a regression by disabling the userspace w/a without the kernel w/a being fully functional on i830/45. References: https://bugs.freedesktop.org/show_bug.cgi?id=76554#c116 Cc: stable@vger.kernel.org # requires c4d69da167fa967749a and v3.8 Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| | * | | | | drm/i915: Only warn the first time we attempt to mmio whilst suspendedChris Wilson2014-12-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In all likelihood we will do a few hundred errnoneous register operations if we do a single invalid register access whilst the device is suspended. As each instance causes a WARN, this floods the system logs and can make the system unresponsive. The warning was first introduced in commit b2ec142cb0101f298f8e091c7d75b1ec5b809b65 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Feb 21 13:52:25 2014 -0300 drm/i915: call assert_device_not_suspended at gen6_force_wake_work and despite the claims the WARN is still encountered in the wild today. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | | drm/i915/chv: Enable AVI, SPD and HDMI infoframes for CHV.Clint Taylor2014-12-031-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CHV infoframes were not being enabled. Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| | * | | | | drm/i915: Don't clobber crtc->new_config when nothing changesVille Syrjälä2014-12-031-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When doing a nop modeset we currently leave crtc->new_config point at the already freed temporary pipe_config. That will anger the sanity checks in intel_modeset_update_state() when the nop modeset gets followed by a GPU reset on gen3/4 where the display block gets fully reinitialized during the reset. So leave crtc->new_config alone until we know a modeset is actually required. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
OpenPOWER on IntegriCloud