- 25 Aug, 2016 1 commit
-
-
Chris Wilson authored
A side effect of removing the midlayer from driver loading was the loss of a useful message announcing to userspace that i915 had successfully started, e.g.: [drm] Initialized i915 1.6.0 20160425 for 0000:00:02.0 on minor 0 Reported-by:
Timo Aaltonen <tjaalton@ubuntu.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Fixes: 8f460e2c ("drm/i915: Demidlayer driver loading") Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Link: http://patchwork.freedesktop.org/patch/msgid/20160825072314.17402-1-chris@chris-wilson.co.ukReviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 24 Aug, 2016 11 commits
-
-
Chris Wilson authored
In order for the RC6 autoenable worker to take any action, RC6 first must be disabled. Upon resume or reset, the sw state may be stale and so we require a forced restore. Fixes: b7137e0c ("drm/i915: Defer enabling rc6 til after we submit...") Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com>
-
Chris Wilson authored
The D_COMP (render decompression) register write is followed by a status check and another error (either that the decompression shutdown or the lpll is enabled). Since we are followed by another, more pertinent, error we can reduce the pcode timeout to a debug and squelch a sporadic error message during suspend. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97465Signed-off-by:
Matthew Auld <matthew.auld@intel.com>
-
Chris Wilson authored
This reverts commit 8678fdaf ("drm/i915/fbc: Allow on unfenced surfaces, for recent gen") as Skylake has issues with unfenced FBC tracking (and yes Skylake doesn't even enable FBC yet). Paulo would like to do a full review of all existing workarounds to see if any more are missing prior to allowing FBC on unfenced surfaces. In the meantime lets hope that all framebuffers are idle and naturally fit within the mappable aperture. Requested-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Fixes: 8678fdaf ("drm/i915/fbc: Allow on unfenced surfaces..."); Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160824180053.24239-1-chris@chris-wilson.co.ukSigned-off-by:
-
Pandiyan, Dhinakaran authored
No functional change, just clean up. Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1470897673-29292-3-git-send-email-dhinakaran.pandiyan@intel.com
-
Pandiyan, Dhinakaran authored
A full dump of link status can be handy in debugging link training failures. Let's add that to the debug messages when link training fails. v2: Removing unrelated clean up (Jani) Signed-off-by:
-
Pandiyan, Dhinakaran authored
Currently we do not print the training pattern used in any of the DP link training stages. Including this piece of information in debug messages will help debugging. Also, use the wrapper intel_dp_program_link_training_pattern() in intel_dp_enable_port() instead of implementing it. v2: Downgraded log level from error to debug (Chris) Signed-off-by:
-
Matthew Auld authored
We need to free the allocated intel_fb in the error path, not intel_fb->base. Otherwise we risk calling kfree with a non-kmalloc'd address, which is bound to give us grief at some point. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1471964444-24460-1-git-send-email-matthew.auld@intel.com
-
Chris Wilson authored
If we hit the error path, we have never called drm_encoder_init() and so have nothing to cleanup. Doing so hits a null dereference: [ 10.066261] BUG: unable to handle kernel NULL pointer dereference at 00000104 [ 10.066273] IP: [<c16054b4>] mutex_lock+0xa/0x15 [ 10.066287] *pde = 00000000 [ 10.066295] Oops: 0002 [#1] [ 10.066302] Modules linked in: i915(+) video i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm iTCO_wdt iTCO_vendor_support ppdev evdev snd_intel8x0 snd_ac97_codec ac97_bus psmouse snd_pcm snd_timer snd pcspkr uhci_hcd ehci_pci soundcore sr_mod ehci_hcd serio_raw i2c_i801 usbcore i2c_smbus cdrom lpc_ich mfd_core rng_core e100 mii floppy parport_pc parport acpi_cpufreq button processor usb_common eeprom lm85 hwmon_vid autofs4 [ 10.066378] CPU: 0 PID: 132 Comm: systemd-udevd Not tainted 4.8.0-rc3-00013-gef0e1ea8 #34 [ 10.066389] Hardware name: MicroLink /D865GLC , BIOS BF86510A.86A.0077.P25.0508040031 08/04/2005 [ 10.066401] task: f62db800 task.stack: f5970000 [ 10.066409] EIP: 0060:[<c16054b4>] EFLAGS: 00010286 CPU: 0 [ 10.066417] EIP is at mutex_lock+0xa/0x15 [ 10.066424] EAX: 00000104 EBX: 00000104 ECX: 00000000 EDX: 80000000 [ 10.066432] ESI: 00000000 EDI: 00000104 EBP: f5be8000 ESP: f5971b58 [ 10.066439] DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068 [ 10.066446] CR0: 80050033 CR2: 00000104 CR3: 35945000 CR4: 000006d0 [ 10.066453] Stack: [ 10.066459] f503d740 f824dddf 00000000 f61170c0 f61170c0 f82371ae f850f40e 00000001 [ 10.066476] f61170c0 f5971bcc f5be8000 f9c2d401 00000001 f8236fcc 00000001 00000000 [ 10.066491] f5144014 f5be8104 00000008 f9c5267c 00000007 f61170c0 f5144400 f9c4ff00 [ 10.066507] Call Trace: [ 10.066526] [<f824dddf>] ? drm_modeset_lock_all+0x27/0xb3 [drm] [ 10.066545] [<f82371ae>] ? drm_encoder_cleanup+0x1a/0x132 [drm] [ 10.066559] [<f850f40e>] ? drm_atomic_helper_connector_reset+0x3f/0x5c [drm_kms_helper] [ 10.066644] [<f9c2d401>] ? intel_dvo_init+0x569/0x788 [i915] [ 10.066663] [<f8236fcc>] ? drm_encoder_init+0x43/0x20b [drm] [ 10.066734] [<f9bf1fce>] ? intel_modeset_init+0x1436/0x17dd [i915] [ 10.066791] [<f9b37636>] ? i915_driver_load+0x85a/0x15d3 [i915] [ 10.066846] [<f9b3603d>] ? i915_driver_open+0x5/0x5 [i915] [ 10.066857] [<c14af4d0>] ? firmware_map_add_entry.part.2+0xc/0xc [ 10.066868] [<c1343daf>] ? pci_device_probe+0x8e/0x11c [ 10.066878] [<c140cec8>] ? driver_probe_device+0x1db/0x62e [ 10.066888] [<c120c010>] ? kernfs_new_node+0x29/0x9c [ 10.066897] [<c13438e0>] ? pci_match_device+0xd9/0x161 [ 10.066905] [<c120c48b>] ? kernfs_create_dir_ns+0x42/0x88 [ 10.066914] [<c140d401>] ? __driver_attach+0xe6/0x11b [ 10.066924] [<c1303b13>] ? kobject_add_internal+0x1bb/0x44f [ 10.066933] [<c140d31b>] ? driver_probe_device+0x62e/0x62e [ 10.066941] [<c140a2d2>] ? bus_for_each_dev+0x46/0x7f [ 10.066950] [<c140c502>] ? driver_attach+0x1a/0x34 [ 10.066958] [<c140d31b>] ? driver_probe_device+0x62e/0x62e [ 10.066966] [<c140b758>] ? bus_add_driver+0x217/0x32a [ 10.066975] [<f8403000>] ? 0xf8403000 [ 10.066982] [<c140de27>] ? driver_register+0x5f/0x108 [ 10.066991] [<c1000493>] ? do_one_initcall+0x49/0x1f6 [ 10.067000] [<c1082299>] ? pick_next_task_fair+0x14b/0x2a3 [ 10.067008] [<c1603c8d>] ? __schedule+0x15c/0x4fe [ 10.067016] [<c1604104>] ? preempt_schedule_common+0x19/0x3c [ 10.067027] [<c11051de>] ? do_init_module+0x17/0x230 [ 10.067035] [<c1604139>] ? _cond_resched+0x12/0x1a [ 10.067044] [<c116f9aa>] ? kmem_cache_alloc+0x8f/0x11f [ 10.067052] [<c11051de>] ? do_init_module+0x17/0x230 [ 10.067060] [<c11703dd>] ? kfree+0x137/0x203 [ 10.067068] [<c110523d>] ? do_init_module+0x76/0x230 [ 10.067078] [<c10cadf3>] ? load_module+0x2a39/0x333f [ 10.067087] [<c10cb8b2>] ? SyS_finit_module+0x96/0xd5 [ 10.067096] [<c1132231>] ? vm_mmap_pgoff+0x79/0xa0 [ 10.067105] [<c1001e96>] ? do_fast_syscall_32+0xb5/0x1b0 [ 10.067114] [<c16086a6>] ? sysenter_past_esp+0x47/0x75 [ 10.067121] Code: c8 f7 76 c1 e8 8e cc d2 ff e9 45 fe ff ff 66 90 66 90 66 90 66 90 90 ff 00 7f 05 e8 4e 0c 00 00 c3 53 89 c3 e8 75 ec ff ff 89 d8 <ff> 08 79 05 e8 fa 0a 00 00 5b c3 53 89 c3 85 c0 74 1b 8b 03 83 [ 10.067180] EIP: [<c16054b4>] mutex_lock+0xa/0x15 SS:ESP 0068:f5971b58 [ 10.067190] CR2: 0000000000000104 [ 10.067222] ---[ end trace 049f1f09da45a856 ]--- Reported-by:
Meelis Roos <mroos@linux.ee> Fixes: 580d8ed5 ("drm/i915: Give encoders useful names") Reviewed-by:
David Weinehall <david.weinehall@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160823092558.14931-1-chris@chris-wilson.co.uk
-
Maarten Lankhorst authored
Instead of iterating overthe connectors manually, run the last part of DDI disabling inside the crt post disable function. This was meant to be addressed before submitting the other commit, but I missed the review comments. Fixes: fd6bbda9 ("drm/i915: Pass crtc_state and connector_state to encoder functions") Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1471961888-10771-2-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by:
-
Maarten Lankhorst authored
This makes the code in intel_sanitize_encoder slightly more readable. This was meant to be addressed in fd6bbda9, but I missed that review comment. Fixes: fd6bbda9 ("drm/i915: Pass crtc_state and connector_state to encoder functions") Signed-off-by:
-
Daniel Vetter authored
Somehow architectures can't agree on this. And for good measure make sure we have a fallback which should work everywhere (fingers crossed). v2: Make it compile properly, needs a defined() for the #elif. Fixes: ac96b556 ("io-mapping.h: s/PAGE_KERNEL_IO/PAGE_KERNEL/") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: linux-mm@kvack.org Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20160823202233.4681-1-daniel.vetter@ffwll.ch
-
- 23 Aug, 2016 17 commits
-
-
Chris Wilson authored
PAGE_KERNEL_IO is an x86-ism. Though it is used to define the pgprot_t used for the iomapped region, it itself is just PAGE_KERNEL. On all other arches, PAGE_KERNEL_IO is undefined so in a general header we must refrain from using it. v2: include pgtable for pgprot_combine() Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Fixes: cafaf14a ("io-mapping: Always create a struct to hold metadata about the io-mapping") Signed-off-by:
-
Lyude authored
Thanks to Ville for suggesting this as a potential solution to pipe underruns on Skylake. On Skylake all of the registers for configuring planes, including the registers for configuring their watermarks, are double buffered. New values written to them won't take effect until said registers are "armed", which is done by writing to the PLANE_SURF (or in the case of cursor planes, the CURBASE register) register. With this in mind, up until now we've been updating watermarks on skl like this: non-modeset { - calculate (during atomic check phase) - finish_atomic_commit: - intel_pre_plane_update: - intel_update_watermarks() - {vblank happens; new watermarks + old plane values => underrun } - drm_atomic_helper_commit_planes_on_crtc: - start vblank evasion - write new plane registers - end vblank evasion } or modeset { - calculate (during atomic check phase) - finish_atomic_commit: - crtc_enable: - intel_update_watermarks() - {vblank happens; new watermarks + old plane values => underrun } - drm_atomic_helper_commit_planes_on_crtc: - start vblank evasion - write new plane registers - end vblank evasion } Now we update watermarks atomically like this: non-modeset { - calculate (during atomic check phase) - finish_atomic_commit: - intel_pre_plane_update: - intel_update_watermarks() (wm values aren't written yet) - drm_atomic_helper_commit_planes_on_crtc: - start vblank evasion - write new plane registers - write new wm values - end vblank evasion } modeset { - calculate (during atomic check phase) - finish_atomic_commit: - crtc_enable: - intel_update_watermarks() (actual wm values aren't written yet) - drm_atomic_helper_commit_planes_on_crtc: - start vblank evasion - write new plane registers - write new wm values - end vblank evasion } So this patch moves all of the watermark writes into the right place; inside of the vblank evasion where we update all of the registers for each plane. While this patch doesn't fix everything, it does allow us to update the watermark values in the way the hardware expects us to. Changes since original patch series: - Remove mutex_lock/mutex_unlock since they don't do anything and we're not touching global state - Move skl_write_cursor_wm/skl_write_plane_wm functions into intel_pm.c, make externally visible - Add skl_write_plane_wm calls to skl_update_plane - Fix conditional for for loop in skl_write_plane_wm (level < max_level should be level <= max_level) - Make diagram in commit more accurate to what's actually happening - Add Fixes: Changes since v1: - Use IS_GEN9() instead of IS_SKYLAKE() since these fixes apply to more then just Skylake - Update description to make it clear this patch doesn't fix everything - Check if pipes were actually changed before writing watermarks Changes since v2: - Write PIPE_WM_LINETIME during vblank evasion Changes since v3: - Rebase against new SAGV patch changes Changes since v4: - Add a parameter to choose what skl_wm_values struct to use when writing new plane watermarks Changes since v5: - Remove cursor ddb entry write in skl_write_cursor_wm(), defer until patch 6 - Write WM_LINETIME in intel_begin_crtc_commit() Changes since v6: - Remove redundant dirty_pipes check in skl_write_plane_wm (we check this in all places where we call this function, and it was supposed to have been removed earlier anyway) - In i9xx_update_cursor(), use dev_priv->info.gen >= 9 instead of IS_GEN9(dev_priv). We do this everywhere else and I'd imagine this needs to be done for gen10 as well Changes since v7: - Fix rebase fail (unused variable obj) - Make struct skl_wm_values *wm const - Fix indenting - Use INTEL_GEN() instead of dev_priv->info.gen Changes since v8: - Don't forget calls to skl_write_plane_wm() when disabling planes - Use INTEL_GEN(), not INTEL_INFO()->gen in intel_begin_crtc_commit() Fixes: 2d41c0b5 ("drm/i915/skl: SKL Watermark Computation") Signed-off-by:Lyude <cpaul@redhat.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Cc: stable@vger.kernel.org Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Maarten Lankhorst authored
crtc_state is already passed around, use it instead of crtc->config. Signed-off-by:
-
Maarten Lankhorst authored
Slightly less straightforward. Some of the drrs calls are done from workers or from intel_ddi.c, pass along crtc_state when we can, or crtc->config when we can't. Signed-off-by:
-
Maarten Lankhorst authored
Signed-off-by:
-
Maarten Lankhorst authored
Signed-off-by:
-
-
Maarten Lankhorst authored
Signed-off-by:
-
-
-
Maarten Lankhorst authored
Now that conn_state is passed in as argument to compute_config, it's guaranteed that there is a connector for the argument. The code that looks for the connector is now dead, and completely unused. Delete it. Signed-off-by:
-
Maarten Lankhorst authored
Some places iterate over connector_state to find the right connector, pass it along as argument. Signed-off-by:
-
Maarten Lankhorst authored
This is mostly code churn, with exception of a few places: - intel_display.c has changes in intel_sanitize_encoder - intel_ddi.c has intel_ddi_fdi_disable calling intel_ddi_post_disable, and required a function change. Also affects intel_display.c - intel_dp_mst.c passes a NULL crtc_state and conn_state to intel_ddi_post_disable for shutting down the real encoder. If we would pass conn_state, then conn_state->connector != intel_dig_port->connector and conn_state->best_encoder != to_intel_encoder(intel_dig_port). We also shouldn't pass crtc_state, because in that case the disabling sequence may potentially be different depending on which crtc is disabled last. Nice way to introduce bugs. No other functional changes are done, diff stat is already huge. Each encoder type will need to be fixed to use the atomic states separately. Signed-off-by:
-
Maarten Lankhorst authored
This cleans up another possible use of the connector list, encoder->crtc is legacy state and should not be used. With the atomic state as argument it's easy to find the encoder from the connector it belongs to. intel_opregion_notify_encoder is a noop for !HAS_DDI, so it's harmless to unconditionally include it in encoder enable/disable. Signed-off-by:
-
-
Maarten Lankhorst authored
This is required for supporting nonblocking modesets. Iterating over the connector list will no longer be allowed when we don't hold connection_mutex, so we have to use the atomic state. Fix disable_noatomic by populating the minimal state required to disable a connector. Signed-off-by:
-
Maarten Lankhorst authored
No idea if it supports it, but this is the minimum required from get_dpll. Signed-off-by:
-
- 22 Aug, 2016 11 commits
-
-
Chris Wilson authored
As we do many register reads within a very short period of time, hold the GMBUS powerwell from start to finish. Signed-off-by:
-
Chris Wilson authored
An unlikely ABBA deadlock in debugfs that no one has reported. [ 284.922349] ====================================================== [ 284.922355] [ INFO: possible circular locking dependency detected ] [ 284.922361] 4.8.0-rc2+ #430 Tainted: G W [ 284.922366] ------------------------------------------------------- [ 284.922371] cat/1197 is trying to acquire lock: [ 284.922376] (&dev->filelist_mutex){+.+...}, at: [<ffffffffa0055ba2>] i915_ppgtt_info+0x82/0x390 [i915] [ 284.922423] [ 284.922423] but task is already holding lock: [ 284.922429] (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0055b55>] i915_ppgtt_info+0x35/0x390 [i915] [ 284.922465] [ 284.922465] which lock already depends on the new lock. [ 284.922465] [ 284.922471] [ 284.922471] the existing dependency chain (in reverse order) is: [ 284.922477] -> #1 (&dev->struct_mutex){+.+.+.}: [ 284.922493] [<ffffffff81087710>] lock_acquire+0x60/0x80 [ 284.922505] [<ffffffff8143e96f>] mutex_lock_nested+0x5f/0x360 [ 284.922520] [<ffffffffa004f877>] print_context_stats+0x37/0xf0 [i915] [ 284.922549] [<ffffffffa00535f5>] i915_gem_object_info+0x265/0x490 [i915] [ 284.922581] [<ffffffff81144491>] seq_read+0xe1/0x3b0 [ 284.922592] [<ffffffff811f77b3>] full_proxy_read+0x83/0xb0 [ 284.922604] [<ffffffff8111ba03>] __vfs_read+0x23/0x110 [ 284.922616] [<ffffffff8111c9b9>] vfs_read+0x89/0x110 [ 284.922626] [<ffffffff8111dbf4>] SyS_read+0x44/0xa0 [ 284.922636] [<ffffffff81442be9>] entry_SYSCALL_64_fastpath+0x1c/0xac [ 284.922648] -> #0 (&dev->filelist_mutex){+.+...}: [ 284.922667] [<ffffffff810871fc>] __lock_acquire+0x10fc/0x1270 [ 284.922678] [<ffffffff81087710>] lock_acquire+0x60/0x80 [ 284.922689] [<ffffffff8143e96f>] mutex_lock_nested+0x5f/0x360 [ 284.922701] [<ffffffffa0055ba2>] i915_ppgtt_info+0x82/0x390 [i915] [ 284.922729] [<ffffffff81144491>] seq_read+0xe1/0x3b0 [ 284.922739] [<ffffffff811f77b3>] full_proxy_read+0x83/0xb0 [ 284.922750] [<ffffffff8111ba03>] __vfs_read+0x23/0x110 [ 284.922761] [<ffffffff8111c9b9>] vfs_read+0x89/0x110 [ 284.922771] [<ffffffff8111dbf4>] SyS_read+0x44/0xa0 [ 284.922781] [<ffffffff81442be9>] entry_SYSCALL_64_fastpath+0x1c/0xac [ 284.922793] [ 284.922793] other info that might help us debug this: [ 284.922793] [ 284.922809] Possible unsafe locking scenario: [ 284.922809] [ 284.922818] CPU0 CPU1 [ 284.922825] ---- ---- [ 284.922831] lock(&dev->struct_mutex); [ 284.922842] lock(&dev->filelist_mutex); [ 284.922854] lock(&dev->struct_mutex); [ 284.922865] lock(&dev->filelist_mutex); [ 284.922875] [ 284.922875] *** DEADLOCK *** [ 284.922875] [ 284.922888] 3 locks held by cat/1197: [ 284.922895] #0: (debugfs_srcu){......}, at: [<ffffffff811f7730>] full_proxy_read+0x0/0xb0 [ 284.922919] #1: (&p->lock){+.+.+.}, at: [<ffffffff811443e8>] seq_read+0x38/0x3b0 [ 284.922942] #2: (&dev->struct_mutex){+.+.+.}, at: [<ffffffffa0055b55>] i915_ppgtt_info+0x35/0x390 [i915] [ 284.922983] Fixes: 1d2ac403 ("drm: Protect dev->filelist with its own mutex") Signed-off-by: -
Chris Wilson authored
If the engine isn't being retired (worker starvation?) then it is possible for us to repeatedly observe that between consecutive hangchecks the seqno on the ring to be the same and there remain unretired requests. Ignore these completely and only regard the engine as busy for the purpose of hang detection (not stall detection) if there are outstanding breadcrumbs. In recent history we have looked at using both the request and seqno as indication of activity on the engine, but that was reduced to just inspecting seqno in commit cffa781e ("drm/i915: Simplify check for idleness in hangcheck"). However, in commit dcff85c8 ("drm/i915: Enable i915_gem_wait_for_idle() without holding struct_mutex"), I made the decision to use the new common lockless function, under the assumption that request retirement was more frequent than hangcheck and so we would not have a stuck busy check. The flaw there was in forgetting that we accumulate the hang score, and so successive checks seeing a stuck request, albeit with the GPU advancing elsewhere and so not necessary the same stuck request, would eventually trigger the hang. Fixes: dcff85c8 ("drm/i915: Enable i915_gem_wait_for_idle()...") Signed-off-by:
-
Chris Wilson authored
As we never need to directly access the pages we allocate for scratch and the pagetables, and always remap them into the GTT through the dma remapper, we do not need to limit the allocations to lowmem i.e. we can pass in the __GFP_HIGHMEM flag to the page allocation. For backwards compatibility, e.g. certain old GPUs not liking highmem for certain functions that may be accidentally mapped to the scratch page by userspace, keep the GMCH probe as only allocating from DMA32. Signed-off-by:
-
Chris Wilson authored
As the scratch page is no longer shared between all VM, and each has their own, forgo the small allocation and simply embed the scratch page struct into the i915_address_space. Signed-off-by:
-
David Weinehall authored
Just like with sysfs, we do some major overhaul. Pass dev_priv instead of dev to all feature macros (IS_, HAS_, INTEL_, etc.). This has the side effect that a bunch of functions now get dev_priv passed instead of dev. All calls to INTEL_INFO()->gen have been replaced with INTEL_GEN(). We want access to to_i915(node->minor->dev) in a lot of places, so add the node_to_i915() helper to accommodate for this. Finally, we have quite a few cases where we get a void * pointer, and need to cast it to drm_device *, only to run to_i915() on it. Add cast_to_i915() to do this. v2: Don't introduce extra dev (Chris) v3: Make pipe_crc_info have a pointer to drm_i915_private instead of drm_device. This saves a bit of space, since we never use drm_device anywhere in these functions. Also some minor fixup that I missed in the previous version. v4: Changed the code a bit so that dev_priv is passed directly to various functions, thus removing the need for the cast_to_i915() helper. Also did some additional cleanup. v5: Additional cleanup of newly introduced changes. v6: Rebase again because of conflict. Signed-off-by: -
David Weinehall authored
In an effort to simplify things for a future push of dev_priv instead of dev wherever possible, always take pdev via dev_priv where feasible, eliminating the direct access from dev. Right now this only eliminates a few cases of dev, but it also obviates that we pass dev into a lot of functions where dev_priv would be the more obvious choice. v2: Fixed one more place missing in the previous patch set Signed-off-by:
-
David Weinehall authored
Various cleanup for i915_sysfs.c; we now use dev_priv whenever possible. The kdev_to_drm_minor() helper function has been replaced by one that converts from struct device * to struct drm_i915_private *. We already have a seemingly identical helper (kdev_to_i915()) in i915_drv.h. But that one cannot be used here. Unlike the version in i915_drv.h, this helper reaches i915 through drm_minor. v2: Rename kdev_to_i915_dm() to kdev_minor_to_i915() (Chris) Signed-off-by:
-
David Weinehall authored
We currently have a mix of struct device *device, struct device *kdev, and struct device *dev (the latter forcing us to refer to struct drm_device as something else than the normal dev). To simplify things, always use kdev when referring to struct device. v2: Replace the dev_to_drm_minor() macro with the inline function kdev_to_drm_minor(). Signed-off-by: -
David Weinehall authored
Fix minor whitespace issues plus a typo. Signed-off-by:
-
Maarten Lankhorst authored
Merge commit 5e580523 reverts the version bumping parts of commit 4aa7fb9c. Bump the versions again and request the specific firmware version. The currently recommended versions are: SKL 1.26, KBL 1.01 and BXT 1.07. Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97242 Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 5e580523 ("Backmerge tag 'v4.7' into drm-next") Signed-off-by:
Imre Deak <imre.deak@intel.com>
-
