- 07 Dec, 2015 3 commits
-
-
Maarten Lankhorst authored
This removes pre/post_wm_update from intel_crtc->atomic, and creates atomic state for it in intel_crtc. Changes since v1: - Rebase on top of wm changes. Changes since v2: - Split disable_cxsr into a separate patch. Changes since v3: - Move some of the changes to intel_wm_need_update. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/56603A49.5000507@linux.intel.comReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Maarten Lankhorst authored
intel_crtc->atomic will be removed later on, move this member to intel_crtc_state. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447945645-32005-2-git-send-email-maarten.lankhorst@linux.intel.comReviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
-
Zeng Zhaoxiu authored
i915: Replace "hweight8(dev_priv->info.subslice_7eu[i]) != 1" with "!is_power_of_2(dev_priv->info.subslice_7eu[i])" Signed-off-by: Zeng Zhaoxiu <zhaoxiu.zeng@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449397590-14292-1-git-send-email-zhaoxiu.zeng@gmail.com
-
- 04 Dec, 2015 9 commits
-
-
Daniel Vetter authored
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Mika Kuoppala authored
Add Skylake Intel Graphics GT4 PCI IDs v2: Rebase Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446811876-303-1-git-send-email-mika.kuoppala@intel.com
-
Daniel Vetter authored
This reverts commit 6d65ba94. Mika Kuoppala traced down a use-after-free crash in module unload to this commit, because ring->last_context is leaked beyond when the context gets destroyed. Mika submitted a quick fix to patch that up in the context destruction code, but that's too much of a hack. The right fix is instead for the ring to hold a full reference onto it's last context, like we do for legacy contexts. Since this is causing a regression in BAT it gets reverted before we can close this. Cc: Nick Hoath <nicholas.hoath@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Gordon <david.s.gordon@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Alex Dai <yu.dai@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93248Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Deepak M authored
The reference clock for BXT is 19.2 MHz not 19.5 MHz, updating the correct value here. Signed-off-by: Deepak M <m.deepak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449238659-12473-2-git-send-email-m.deepak@intel.com
-
Daniel Vetter authored
This was broken in commit 6a8beeff Author: Wayne Boyer <wayne.boyer@intel.com> Date: Wed Dec 2 13:28:14 2015 -0800 drm/i915: Clean up device info structure definitions and I didn't spot this while reviewing. We really need that CI farm up asap! Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Wayne Boyer <wayne.boyer@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Chris Wilson authored
In commit 2e1b8730 [v4.2] Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Apr 27 13:41:22 2015 +0100 drm/i915: Convert RPS tracking to a intel_rps_client struct we converted the __i915_wait_request() to take a new intel_rps_client struct (rather than having to pass fake drm_i915_file_private structs). However, due to use of passing a void pointer, I didn't spot one callsite in wait-ioctl was passing the wrong pointer. Fwiw, the impact of this bug is zero. Along the rps path, we always first call list_empty(rps) which when we pass in the wrong pointer always evaluates to false and we return early and never chase the invalid pointers. The user visible impact is then wait-ioctl doesn't get the same waitboosting as the other interfaces (set-domain, throttle), which is a performance concern for the *very* few users of the wait interface. There is also a libdrm_intel patch to use the wait-ioctl for drm_intel_bo_wait_rendering() if anyone feels inclined to review libdrm_intel patches. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> [danvet: Add Chris' explanation for why the impact of this is pretty close to 0.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
This reverts commit 89f41f4f. It's possible that ->crtc is NULL in here. Noticed by Ville. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
-
Wayne Boyer authored
Beginning with gen7, newer devices repetitively redefine values for the device info structure members. This patch simplifies the structure definitions by grouping member value definitions into the existing GEN7_FEATURES #define and into the new GEN7_LP_FEATURES and HSW_FEATURES #defines. Specifically, GEN_DEFAULT_PIPEOFFSETS and IVB_CURSOR_OFFSETS are added to GEN7_FEATURES and subsequent IVB definitions are simplified. VLV_FEATURES is defined to differentiate and simplify the gen7 low power (LP) devices. HSW_FEATURES is defined and used to simplify all HSW+ devices except for LP. v2: Use VLV_FEATURES for the gen7 low power devices. (Jani) Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Wayne Boyer <wayne.boyer@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449091694-7681-1-git-send-email-wayne.boyer@intel.com
-
Takashi Iwai authored
to_intel_crtc() always returns a non-NULL pointer. Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1448986198-3488-2-git-send-email-tiwai@suse.de
-
- 03 Dec, 2015 16 commits
-
-
Maarten Lankhorst authored
As the comment indicates this can only fail gracefully when called from compute_config. Fortunately this is now what's happening, so the fixme can be removed and the DRM_ERROR downgraded. Link: http://patchwork.freedesktop.org/patch/msgid/1448360945-5723-3-git-send-email-maarten.lankhorst@linux.intel.comSigned-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
-
Alex Goins authored
In intel_prepare_plane_fb, if fb is backed by dma-buf, wait for exclusive fence v2: First commit v3: Remove object_name_lock acquire Move wait from intel_atomic_commit() to intel_prepare_plane_fb() v4: Wait only on exclusive fences, interruptible with no timeout v5: Style tweaks to more closely match rest of file v6: Properly handle interrupted waits v7: No change v8: No change Link: https://patchwork.kernel.org/patch/7704181/Signed-off-by: Alex Goins <agoins@nvidia.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Alex Goins authored
If a buffer is backed by dmabuf, wait on its reservation object's exclusive fence before flipping. v2: First commit v3: Remove object_name_lock acquire v4: Move wait ahead of mark_page_flip_active Use crtc->primary->fb to get GEM object instead of pending_flip_obj use_mmio_flip() return true when exclusive fence is attached Wait only on exclusive fences, interruptible with no timeout v5: Move wait from do_mmio_flip to mmio_flip_work_func Style tweaks to more closely match rest of file v6: Change back to unintteruptible wait to match __i915_wait_request due to inability to properly handle interrupted wait. Warn on error code from waiting. v7: No change v8: Test for !reservation_object_signaled_rcu(test_all=FALSE) instead of obj->base.dma_buf->resv->fence_excl Link: https://patchwork.kernel.org/patch/7704181/Signed-off-by: Alex Goins <agoins@nvidia.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
Nick Hoath authored
Use the first retired request on a new context to unpin the old context. This ensures that the hw context remains bound until it has been written back to by the GPU. Now that the context is pinned until later in the request/context lifecycle, it no longer needs to be pinned from context_queue to retire_requests. This fixes an issue with GuC submission where the GPU might not have finished writing back the context before it is unpinned. This results in a GPU hang. v2: Moved the new pin to cover GuC submission (Alex Dai) Moved the new unpin to request_retire to fix coverage leak v3: Added switch to default context if freeing a still pinned context just in case the hw was actually still using it v4: Unwrapped context unpin to allow calling without a request v5: Only create a switch to idle context if the ring doesn't already have a request pending on it (Alex Dai) Rename unsaved to dirty to avoid double negatives (Dave Gordon) Changed _no_req postfix to __ prefix for consistency (Dave Gordon) Split out per engine cleanup from context_free as it was getting unwieldy Corrected locking (Dave Gordon) v6: Removed some bikeshedding (Mika Kuoppala) Added explanation of the GuC hang that this fixes (Daniel Vetter) v7: Removed extra per request pinning from ring reset code (Alex Dai) Added forced ring unpin/clean in error case in context free (Alex Dai) Signed-off-by: Nick Hoath <nicholas.hoath@intel.com> Issue: VIZ-4277 Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: David Gordon <david.s.gordon@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Alex Dai <yu.dai@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Alex Dai <yu.dai@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Alex Dai authored
For now, remove the spinlocks that protected the GuC's statistics block and work queue; they are only accessed by code that already holds the global struct_mutex, and so are redundant (until the big struct_mutex rewrite!). The specific problem that the spinlocks caused was that if the work queue was full, the driver would try to spinwait for one jiffy, but with interrupts disabled the jiffy count would not advance, leading to a system hang. The issue was found using test case igt/gem_close_race. The new version will usleep() instead, still holding the struct_mutex but without any spinlocks. v4: Reorganize commit message (Dave Gordon) v3: Remove unnecessary whitespace churn v2: Clean up wq_lock too v1: Clean up host2guc lock as well Signed-off-by: Alex Dai <yu.dai@intel.com> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449104189-27591-1-git-send-email-yu.dai@intel.comSigned-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
There's no need to stop and restart FBC, which is quite expensive as we have to revalidate the CRTC state. After flushing a drawing operation we know the CRTC state hasn't changed, so a nuke (recompress) should be fine. v2: Make it simpler (Chris). v3: Rewrite the patch again due to patch order changes. v4: Rewrite commit message (Chris). Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/
-
Paulo Zanoni authored
When running Cinnamon I see way too many pairs of these messages: many per second. Get rid of them as they're just telling us FBC is working as expected. We already have the messages for enable/disable, so we don't really need messages for activation/deactivation. v2: Rebase after changing the patch order. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/
-
Paulo Zanoni authored
Directly call intel_fbc_calculate_cfb_size() in the only place that actually needs it, and use the proper check before removing the stolen node. IMHO, this change makes our code easier to understand. v2: Use drm_mm_node_allocated() (Chris). Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/
-
Paulo Zanoni authored
This was already on my TODO list, and was requested both by Chris and Ville, for different reasons. The advantages are avoiding a frequent malloc/free pair, and the locality of having the work structure embedded in dev_priv. The maximum used memory is also smaller since previously we could have multiple allocated intel_fbc_work structs at the same time, and now we'll always have a single one - the one embedded on dev_priv. Of course, we're now using a little more memory on the cases where there's nothing scheduled. The biggest challenge here is to keep everything synchronized the way it was before. Currently, when we try to activate FBC, we allocate a new intel_fbc_work structure. Then later when we conclude we must delay the FBC activation a little more, we allocate a new intel_fbc_work struct, and then adjust dev_priv->fbc.fbc_work to point to the new struct. So when the old work runs - at intel_fbc_work_fn() - it will check that dev_priv->fbc.fbc_work points to something else, so it does nothing. Everything is also protected by fbc.lock. Just cancelling the old delayed work doesn't work because we might just cancel it after the work function already started to run, but while it is still waiting to grab fbc.lock. That's why we use the "dev_priv->fbc.fbc_work == work" check described in the paragraph above. So now that we have a single work struct we have to introduce a new way to synchronize everything. So we're making the work function a normal work instead of a delayed work, and it will be responsible for sleeping the appropriate amount of time itself. This way, after it wakes up it can grab the lock, ask "were we delayed or cancelled?" and then go back to sleep, enable FBC or give up. v2: - Spelling fixes. - Rebase after changing the patch order. - Fix ms/jiffies confusion. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/
-
Paulo Zanoni authored
This moves the pre-gen4 check from update() to enable(). The HAS_DDI in the original code is not needed since only gen 2/3 have the plane swapping code. v2: Rebase. v3: Extract fbc_on_plane_a_only() (Chris). Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/
-
Paulo Zanoni authored
One of the problems with the current code is that it frees the CFB and releases its drm_mm node as soon as we flip FBC's enable bit. This is bad because after we disable FBC the hardware may still use the CFB for the rest of the frame, so in theory we should only release the drm_mm node one frame after we disable FBC. Otherwise, a stolen memory allocation done right after an FBC disable may result in either corrupted memory for the new owner of that memory region or corrupted screen/underruns in case the new owner changes it while the hardware is still reading it. This case is not exactly easy to reproduce since we currently don't do a lot of stolen memory allocations, but I see patches on the mailing list trying to expose stolen memory to user space, so races will be possible. I thought about three different approaches to solve this, and they all have downsides. The first approach would be to simply use multiple drm_mm nodes and freeing the unused ones only after a frame has passed. The problem with this approach is that since stolen memory is rather small, there's a risk we just won't be able to allocate a new CFB from stolen if the previous one was not freed yet. This could happen in case we quickly disable FBC from pipe A and decide to enable it on pipe B, or just if we change pipe A's fb stride while FBC is enabled. The second approach would be similar to the first one, but maintaining a single drm_mm node and keeping track of when it can be reused. This would remove the disadvantage of not having enough space for two nodes, but would create the new problem where we may not be able to enable FBC at the point intel_fbc_update() is called, so we would have to add more code to retry updating FBC after the time has passed. And that can quickly get too complex since we can get invalidate, flush, disable and other calls in the middle of the wait. Both solutions above - and also the current code - have the problem that we unnecessarily free+realloc FBC during invalidate+flush operations even if the CFB size doesn't change. The third option would be to move the allocation/deallocation to enable/disable. This makes sure that the pipe is always disabled when we allocate/deallocate the CFB, so there's no risk that the FBC hardware may read or write to the memory right after it is freed from drm_mm. The downside is that it is possible for user space to change the buffer stride without triggering a disable/enable - only deactivate/activate -, so we'll have to handle this case somehow - see igt's kms_frontbuffer_tracking test, fbc-stridechange subtest. It could be possible to implement a way to free+alloc the CFB during said stride change, but it would involve a lot of book-keeping - exactly as mentioned above - just for on case, so for now I'll keep it simple and just deactivate FBC. Besides, we may not even need to disable FBC since we do CFB over-allocation. Note from Chris: "Starting a fullscreen client that covers a single monitor in a multi-monitor setup will trigger a change in stride on one of the CRTCs (the monitors will be flipped independently).". It shouldn't be a huge problem if we lose FBC on multi-monitor setups since these setups already have problems reaching deep PC states anyway. v2: Rebase after changing the patch order. v3: - Remove references to the stride change case being "uncommon" and paste Chris' example. - Rebase after a change in a previous patch. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/
-
Paulo Zanoni authored
The goal is to call FBC enable/disable only once per modeset, while activate/deactivate/update will be called multiple times. The enable() function will be responsible for deciding if a CRTC will have FBC on it and then it will "lock" FBC on this CRTC: it won't be possible to change FBC's CRTC until disable(). With this, all checks and resource acquisition that only need to be done once per modeset can be moved from update() to enable(). And then the update(), activate() and deactivate() code will also get simpler since they won't need to worry about the CRTC being changed. The disable() function will do the reverse operation of enable(). One of its features is that it should only be called while the pipe is already off. This guarantees that FBC is stopped and nothing is using the CFB. With this, the activate() and deactivate() functions just start and temporarily stop FBC. They are the ones touching the hardware enable bit, so HW state reflects dev_priv->crtc.active. The last function remaining is update(). A lot of times I thought about renaming update() to activate() or try_to_activate() since it's called when we want to activate FBC. The thing is that update() may not only decide to activate FBC, but also deactivate or keep it on the same state, so I'll leave this name for now. Moving code to enable() and disable() will also help in case we decide to move FBC to pipe_config or something else later. The current patch only puts the very basic code on enable() and disable(). The next commits will take care of moving more stuff from update() to the new functions. v2: - Rebase. - Improve commit message (Chris). v3: Rebase after changing the patch order. v4: Rebase again after upstream changes. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/
-
Paulo Zanoni authored
The long term goal is to have enable/disable as the higher level functions and activate/deactivate as the lower level functions, just like we do for PSR and for the CRTC. This way, we'll run enable and disable once per modeset, while update, activate and deactivate will be run many times. With this, we can move the checks and code that need to run only once per modeset to enable(), making the code simpler and possibly a little faster. This patch is just the first step on the conversion: it starts by converting the current low level functions from enable/disable to activate/deactivate. This patch by itself has no benefits other than making review and rebase easier. Please see the next patches for more details on the conversion. v2: - Rebase. - Improve commit message (Chris). v3: Rebase after changing the patch order. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/
-
Paulo Zanoni authored
There's no need to reevaluate the status of every single crtc when a single crtc changes its state. With this, we're cutting the case where due to a change in pipe B, intel_fbc_update() is called, then intel_fbc_find_crtc() concludes FBC should be enabled on pipe A, then it completely rechecks the state of pipe A only to conclude FBC should remain enabled on pipe A. If any change on pipe A triggers a need to recompute whether FBC is valid on pipe A, then at some point someone is going to call intel_fbc_update(PIPE_A). The addition of intel_fbc_deactivate() is necessary so we keep track of the previously selected CRTC when we do invalidate/flush. We're also going to continue the enable/disable/activate/deactivate concept in the next patches. v2: Rebase. v3: Rebase after changing the patch order. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/
-
Paulo Zanoni authored
This thing where we need to get the crtc either from the work structure or the fbc structure itself is confusing and unnecessary. Set fbc.crtc right when scheduling the enable work so we can always use it. The problem is not what gets passed and how to retrieve it. The problem is that when we're in the other parts of the code we always have to keep in mind that if FBC is already enabled we have to get the CRTC from place A, if FBC is scheduled we have to get the CRTC from place B, and if it's disabled there's no CRTC. Having a single place to retrieve the CRTC from allows us to treat the "is enabled" and "is scheduled" cases as the same case, reducing the mistake surface. I guess I should add this to the commit message. Besides the immediate advantages, this is also going to make one of the next commits much simpler. And even later, when we introduce enable/disable + activate/deactivate, this will be even simpler as we'll set the CRTC at enable time. So all the activate/deactivate/update code can just look at the single CRTC variable regardless of the current state. v2: Improve commit message (Chris). v3: Rebase after changing the patch order. Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/
-
Paulo Zanoni authored
In function find_compression_threshold() we try to over-allocate CFB space in order to reduce reallocations and fragmentation, and we're not considering that at the CFB size check. Consider it. There is also a longer-term plan to kill dev_priv->fbc.uncompressed_size, but this will come later. v2: Use drm_mm_node_allocated() (Chris). Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/
-
- 02 Dec, 2015 12 commits
-
-
Jani Nikula authored
Choose between i2c bit banging and gmbus in a new higher level function, and let the i2c core retry the first time we fall back to bit banging. The i2c core imposes a timeout on -EAGAIN, but it defaults to 1 second, and shouldn't be a problem for us. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448980166-23055-2-git-send-email-jani.nikula@intel.com
-
Jani Nikula authored
Shorter, easier to follow code with no functional changes. In all cases, the return value ultimately comes from gmbus_wait_hw_status() anyway. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448980166-23055-1-git-send-email-jani.nikula@intel.com
-
Ville Syrjälä authored
While not technically needed on the last case in the switch statement, the 'break' makes it look better IMO. v2: Fixed a typo in the commit message (Paulo) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449005527-15617-1-git-send-email-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
Unfortunatey there appear to quite a few HSW/BDW machines (eg. NUCs, Brix Pro) in the wild with LPT/WPT-H that have no physical CRT connector and non-working FDI. FDI training fails every single time on these machines. Dunno, maybe they just didn't bother wiring it up or something? Unfortunately all the fuse bits and whatnot are telling us that the CRT connector is present. And so what we get from this is tons of false positives from the CI systems due to VGA connector forcing. I've not found any way to detect this purely from hardware, so we have to resort to looking at the VBT int_crt_support bit. We used to check this bit on all platforms, but that broke all the old machines, so the check was then restricted to VLV only in commit 84b4e042 ("drm/i915: only apply crt_present check on VLV") Considering HSW and VLV VBT probably got defined around the same time, it should be reasonably safe to assume that the bits is sane for HSW/BDW as well. At least I have one copy of some VBT spec here that says it's meant for both VLV and HSW, and it knows about the bit (lists it being valid from version 155 onwards). Also I have two desktop machines with actual CRT ports and both have int_crt_support==1 in their VBTs. Also we already trust VBT >= 155 to tell us various details about the DDI ports, so trusting it a bit more seems reasonable. As far as VLV goes, the added VBT version check should be fine. Even if someone has some weird VLV machine with a very old VBT version, it just means they'll end up with a shadow CRT connector. IIRC the reason for eliminating the shadow CRT connector on VLV was to speed up display probing rather than fixing something more serious. v2: Move the platform checks into the VBT parsing code Also check that the VBT version is at least 155 v3: Improve commit message (Paulo) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449005493-15487-1-git-send-email-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
On HSW/BDW DDI A and E share 2 lanes, so when DDI A requires the shared lanes DDI E can't be used. The lanes are not supposed to be dynamically switched between the two uses, so there's no point in registering the CRT connector when DDI E has no lanes. v2: Fix typos in the commit message (Paulo) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449005396-15319-1-git-send-email-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
LPT-H has a strap bit for fused off CRT block. Check it to see if we should register the CRT connector or not. Supposedly this also forces the ADAP enable bit to 0, so the detection we added in commit 6c03a6bd ("drm/i915: Don't register CRT connector when it's fused off") should already catch it, but checking the fuse bit should at least do no harm. v2: Use HAS_PCH_LPT_H() (Paulo) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449005335-15192-1-git-send-email-ville.syrjala@linux.intel.com
-
Ville Syrjälä authored
No need to read out cdclk from the hardware, we have it already cached in dev_priv. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448893432-6978-7-git-send-email-ville.syrjala@linux.intel.comReviewed-by: Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Currently we round the AUX clock divider down on g4x, to closest on HSW/BDW port A, and up everywhere else. We are supposed to get as close to 2MHz as we can, so round to closest seems like the best option. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448893432-6978-6-git-send-email-ville.syrjala@linux.intel.comReviewed-by: Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Somehow we accumulated a duplicated .get_display_clock_speed() assignment for PNV in commit 34edce2f ("drm/i915: Add cdclk extraction for g33, g965gm and g4x") No real harm on having two, we just never reach the second one, so simply kill it. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448893432-6978-5-git-send-email-ville.syrjala@linux.intel.comReviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
We have HAS_PCH_LPT_LP() already, so add HAS_PCH_LPT_H() and use it where appropriate. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448893432-6978-4-git-send-email-ville.syrjala@linux.intel.comReviewed-by: Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
CTG uses hrawclk for backlight, so calculate the max based on that instead of cdclk. Fixes: aa17cdb4 ("drm/i915: initialize backlight max from VBT") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448893432-6978-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by: Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Convert the MHz number coming from intel_rawclk() into Hz in i9xx_hz_to_pwm() on PNV. Otherwise we'll get something totally bogus as a result. Fixes: aa17cdb4 ("drm/i915: initialize backlight max from VBT") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448893432-6978-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: Jani Nikula <jani.nikula@intel.com>
-