- 13 Jan, 2016 6 commits
-
-
Maarten Lankhorst authored
This fixes a spurious warning from an integer overflow on 64-bits systems. The function may return MAX_SCHEDULE_TIMEOUT which gets truncated to -1. Explicitly handling this by casting to lret fixes it. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reported-and-tested-by:
Joseph Yasi <joe.yasi@gmail.com> Tested-by:
Andreas Reis <andreas.reis@gmail.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 3c28ff22 ("i915: wait for fence in prepare_plane_fb") Link: http://patchwork.freedesktop.org/patch/msgid/5666EEC8.2000403@linux.intel.com (cherry picked from commit bcf8be27) Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Lyude authored
This fixes reprobing of display connectors on resume. After some talking with danvet on IRC, I learned that calling drm_helper_hpd_irq_event() does actually trigger a full reprobe of each connector's status. It turns out this is the actual reason reprobing on resume hasn't been working (this was observed on a T440s): - We call hpd_init() - We check each connector for a couple of things before marking connector->polled with DRM_CONNECTOR_POLL_HPD, one of which is an active encoder. Of course, a disconnected port won't have an active encoder, so we don't add the flag to any of the connectors. - We call drm_helper_hpd_irq_event() - drm_helper_irq_event() checks each connector for the DRM_CONNECTOR_POLL_HPD flag. The only one that has it is eDP-1, so we skip reprobing each connector except that one. In addition, we also now avoid setting connector->polled to DRM_CONNECTOR_POLL_HPD for MST connectors, since their reprobing is handled by the mst helpers. This is probably what was originally intended to happen here. Changes since V1: * Use the explanation of the issue as the commit message instead * Change the title of the commit, since this does more then just stop a check for an encoder now * Add "Fixes" line for the patch that introduced this regression * Don't enable DRM_CONNECTOR_POLL_HPD for mst connectors Changes since V2: * Put patch changelog above Signed-off-by * Follow Daniel Vetter's suggestion for making the code here a bit more legible Fixes: 0e32b39c ("drm/i915: add DP 1.2 MST support (v0.7)") Cc: stable@vger.kernel.org Signed-off-by:
Lyude <cpaul@redhat.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452181408-14777-1-git-send-email-cpaul@redhat.comSigned-off-by:
-
Jani Nikula authored
We still keep getting [ 4.249930] [drm:gen8_irq_handler [i915]] *ERROR* The master control interrupt lied (SDE)! This reverts commit 820da7ae Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Nov 25 16:47:23 2015 +0200 Revert "drm/i915: shut up gen8+ SDE irq dmesg noise" which in itself is a revert, so this is just doing commit 97e5ed11 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Oct 23 10:56:12 2015 +0200 drm/i915: shut up gen8+ SDE irq dmesg noise all over again. I'll stop pretending I understand what's going on like I did when I thought I'd fixed this for good in commit 6a39d7c9 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Nov 25 16:47:22 2015 +0200 drm/i915: fix the SDE irq dmesg warnings properly Reported-by:
Chris Wilson <chris@chris-wilson.co.uk> Reference: http://mid.gmane.org/20151213124945.GA5715@nuc-i3427.alporthouse.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084 Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 820da7ae ("Revert "drm/i915: shut up gen8+ SDE irq dmesg noise"") Acked-by:
-
Chris Wilson authored
Following a GPU reset, we may leave the context in a poorly defined state, and reloading from that context will leave the GPU flummoxed. For secondary contexts, this will lead to that context being banned - but currently it is also causing the default context to become banned, leading to turmoil in the shared state. This is a regression from commit 6702cf16 [v4.1] Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Mon Mar 16 16:00:58 2015 +0000 drm/i915: Initialize all contexts which quietly introduced the removal of the MI_RESTORE_INHIBIT on the default context. v2: Mark the global default context as uninitialized on GPU reset so that the context-local workarounds are reloaded upon re-enabling. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Cc: stable@vger.kernel.org [danvet: This seems to fix a gpu hand on after the first resume, resulting in any future suspend operation failing with -EIO because the gpu seems to be in a funky state. Somehow this patch fixes that.] Signed-off-by:
-
Daniel Vetter authored
They're causing massive amounts of dmesg noise and hence CI noise all over the place. Enabling them for a bit was good enough to refresh our task list of what's still needed to enable rpm by default. To make sure we're not forgetting to make this noisy again add a FIXME comment. Fixes: da5827c3 ("drm/i915: add assert_rpm_wakelock_held helper") Cc: Imre Deak <imre.deak@intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
Daniel Vetter <daniel.vetter@intel.com> (cherry picked from commit becd9ca2) Signed-off-by:
-
Michał Winiarski authored
According to PRM, some parts of HW require the addresses to be in a canonical form, where bits [63:48] == [47]. Let's convert addresses to canonical form prior to relocating and return converted offsets to userspace. We also need to make sure that userspace is using addresses in canonical form in case of softpin. v2: Whitespace fixup, gen8_canonical_addr description (Chris, Ville) v3: Rebase on top of softpin, fix a hole in relocate_entry, s/expect/require (Chris) v4: Handle softpin in validate_exec_list (Chris) v5: Convert back to canonical form at copy_to_user time (Chris) v6: Don't use struct exec_object2 in place of exec_object v7: Use sign_extend64 for converting to canonical form (Joonas), reject non-canonical and non-page-aligned offset for softpin (Chris) v8: Convert back to non-canonical form in a function, split the test for EXEC_OBJECT_PINNED (Chris) v9: s/canonial/canonical, drop accidental double newline (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:Michał Winiarski <michal.winiarski@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1451409892-13708-1-git-send-email-michal.winiarski@intel.com Testcase: igt/gem_bad_reloc/negative-reloc-blt Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92699 Cc: drm-intel-fixes@lists.freedesktop.org Reviewed-by:
-
- 22 Dec, 2015 1 commit
-
-
Chris Wilson authored
There was a silent conflict between commit 0a878716 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 15 14:23:01 2015 +0200 drm/i915: restore ggtt double-bind avoidance and commit 5bab6f60 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Oct 23 18:43:32 2015 +0100 drm/i915: Serialise updates to GGTT with access through GGTT on Braswell thankfully caught by the extra WARN safegaurd in 0a878716. Since we now override the GGTT insert_pages callback when installing the aliasing ppgtt, we assert that the callback is the original ggtt routine. However, on Braswell we now use a different insertion routine to serialise access through the GGTT with updating the PTE and hence the conflict. To avoid the conflict, move the custom insertion routine for Braswell down a level. Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by:
-
- 18 Dec, 2015 7 commits
-
-
Daniel Vetter authored
Signed-off-by: -
Mika Kuoppala authored
The workarounds for disabling hdc invalidation and also forcing context to be non coherent, are advised to be used up until rev D0. However as it was found that rev F0, without the WaForceEnableNonCoherent might system hang if the mesa tried to use coherent mode. As these two workarounds are about non coherent access, are grouped in scope and they point the same HSD, increase the scope of both to set default behaviour to non coherent access. References: HSD: gen9lp/2131413 References: http://lists.freedesktop.org/archives/mesa-dev/2015-November/101515.html Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Francisco Jerez <currojerez@riseup.net> Reviewed-by:
Francisco Jerez <currojerez@riseup.net> Signed-off-by:
-
Chris Wilson authored
Limit busywaiting only to the request currently being processed by the GPU. If the request is not currently being processed by the GPU, there is a very low likelihood of it being completed within the 2 microsecond spin timeout and so we will just be wasting CPU cycles. v2: Check for logical inversion when rebasing - we were incorrectly checking for this request being active, and instead busywaiting for when the GPU was not yet processing the request of interest. v3: Try another colour for the seqno names. v4: Another colour for the function names. v5: Remove the forced coherency when checking for the active request. On reflection and plenty of recent experimentation, the issue is not a cache coherency problem - but an irq/seqno ordering problem (timing issue). Here, we do not need the w/a to force ordering of the read with an interrupt. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Eero Tamminen <eero.t.tamminen@intel.com> Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Chris Wilson authored
When waiting for high frequency requests, the finite amount of time required to set up the irq and wait upon it limits the response rate. By busywaiting on the request completion for a short while we can service the high frequency waits as quick as possible. However, if it is a slow request, we want to sleep as quickly as possible. The tradeoff between waiting and sleeping is roughly the time it takes to sleep on a request, on the order of a microsecond. Based on measurements of synchronous workloads from across big core and little atom, I have set the limit for busywaiting as 10 microseconds. In most of the synchronous cases, we can reduce the limit down to as little as 2 miscroseconds, but that leaves quite a few test cases regressing by factors of 3 and more. The code currently uses the jiffie clock, but that is far too coarse (on the order of 10 milliseconds) and results in poor interactivity as the CPU ends up being hogged by slow requests. To get microsecond resolution we need to use a high resolution timer. The cheapest of which is polling local_clock(), but that is only valid on the same CPU. If we switch CPUs because the task was preempted, we can also use that as an indicator that the system is too busy to waste cycles on spinning and we should sleep instead. __i915_spin_request was introduced in commit 2def4ad9 [v4.2] Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 7 16:20:41 2015 +0100 drm/i915: Optimistically spin for the request completion v2: Drop full u64 for unsigned long - the timer is 32bit wraparound safe, so we can use native register sizes on smaller architectures. Mention the approximate microseconds units for elapsed time and add some extra comments describing the reason for busywaiting. v3: Raise the limit to 10us v4: Now 5us. Reported-by:
Jens Axboe <axboe@kernel.dk> Link: https://lkml.org/lkml/2015/11/12/621Reviewed-by:
-
Chris Wilson authored
The busywait in __i915_spin_request() does not respect pending signals and so may consume the entire timeslice for the task instead of returning to userspace to handle the signal. In the worst case this could cause a delay in signal processing of 20ms, which would be a noticeable jitter in cursor tracking. If a higher resolution signal was being used, for example to provide fairness of a server timeslices between clients, we could expect to detect some unfairness between clients (i.e. some windows not updating as fast as others). This issue was noticed when inspecting a report of poor interactivity resulting from excessively high __i915_spin_request usage. Fixes regression from commit 2def4ad9 [v4.2] Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Apr 7 16:20:41 2015 +0100 drm/i915: Optimistically spin for the request completion v2: Try to assess the impact of the bug Signed-off-by:
-
Imre Deak authored
pm_runtime_{use,dont_use}_autosuspend() controls whether the device's sysfs power/autosuspend_delay_ms file is writeable or returns -EIO on access to user space. Since commit 25b181b4 Author: Imre Deak <imre.deak@intel.com> Date: Thu Dec 17 13:44:56 2015 +0200 drm/i915: get a permanent RPM reference on platforms w/o RPM support this sysfs file is writeable also on platforms without RPM support, but userspace (at least IGT) depends on this file being unchangable to determine whether the device supports runtime PM at all. So restore the old behavior. This gets rid of igt/pm_rpm failures on old platforms without RPM support, where the test should be skipped. Testcase: igt/pm_rpm/basic-rte Signed-off-by:Imre Deak <imre.deak@intel.com> Reviewed-by:
David Weinehall <david.weinehall@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450371873-878-1-git-send-email-imre.deak@intel.com
-
Jani Nikula authored
Use dev_priv rather than dev pointer where applicable. Remove plenty of unnecessary temp variables. No functional changes. Reviewed-by:
-
- 17 Dec, 2015 15 commits
-
-
Matt Roper authored
If we fail to reconstruct the BIOS fb (e.g., because the FB is too large), we'll be left with plane state that indicates the primary plane is visible yet has a NULL fb. This mismatch causes problems later on (e.g., for the watermark code). Since we've failed to reconstruct the BIOS FB, the best solution is to just disable the primary plane and pretend the BIOS never had it enabled. v2: Add intel_pre_disable_primary() call (Maarten) Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Chris Wilson authored
A long time ago (before 3.14) we relied on a permanent pinning of the ifbdev to lock the fb in place inside the GGTT. However, the introduction of stealing the BIOS framebuffer and reusing its address in the GGTT for the fbdev has muddied waters and we use an inherited fb. However, the inherited fb is only pinned whilst it is active and we no longer have an explicit pin for the info->system_base mmapping used by the fbdev. The result is that after some aperture pressure the fbdev may be evicted, but we continue to write the fbcon into the same GGTT address - overwriting anything else that may be put into that offset. The effect is most pronounced across suspend/resume as intel_fbdev_set_suspend() does a full clear over the whole scanout. v2: Only unpin the intel_fb is we allocate it. If we inherit the fb from the BIOS, we do not own the pinned vma (except for the reference we add in this patch for our access via info->screen_base). v3: Finish balancing the vma pinning for the normal !preallocated case. v4: Try to simplify the pinning even further. v5: Leak the VMA (cleaned up by object-free) to avoid complicated error paths. Signed-off-by:
-
Chris Wilson authored
As we mark the preallocated objects as bound, we should also flag them correctly as being map-and-fenceable (if appropriate!) so that later users do not get confused and try and rebind the pinned vma in order to get a map-and-fenceable binding. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Daniel Vetter authored
I missed this myself when reviewing commit 237ed86c Author: Sonika Jindal <sonika.jindal@intel.com> Date: Tue Sep 15 09:44:20 2015 +0530 drm/i915: Check live status before reading edid Long sleeps like this really shouldn't waste cpu cycles spinning. Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: "Wang, Gary C" <gary.c.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449859455-32609-1-git-send-email-daniel.vetter@ffwll.chReviewed-by:
Sonika Jindal <sonika.jindal@intel.com> Signed-off-by:
-
Imre Deak authored
The device should be on for the whole duration of the update, so check for this. v2: - use the existing dev_priv directly everywhere (Ville) v3: - check also that we are in an RPM atomic section (Chris) - add the assert to i915_ggtt_insert_entries/clear_range too (Chris) Signed-off-by:
-
Imre Deak authored
In some cases we want to check whether we hold an RPM wakelock reference for the whole duration of a sequence. To achieve this add a new RPM atomic sequence counter that we increment any time the wakelock refcount drops to zero. Check whether the sequence number stays the same during the atomic section and that we hold the wakelock at the beginning of the section. Motivated by Chris. v2-v3: - unchanged v4: - swap the order of atomic_read() and assert_rpm_wakelock_held() in assert_rpm_atomic_begin() to avoid race Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450203038-5150-10-git-send-email-imre.deak@intel.com
-
Imre Deak authored
With this change we have the corresponding wake lock checks in both the rpm get and put functions. v2-v3: - unchanged v4: - keep the corresponding check in the get helper (Chris) v5: - add a note to the commit message that with this change we have the checks both in the rpm get and put functions (Joonas) Signed-off-by:
-
Imre Deak authored
Atm, we assert that the device is not suspended until the point when the device is truly put to a suspended state. This is fine, but we can catch more problems if we check that RPM refcount is non-zero. After that one drops to zero we shouldn't access the device any more, even if the actual device suspend may be delayed. Change assert_rpm_wakelock_held() accordingly to check for a non-zero RPM refcount in addition to the current device-not-suspended check. For the new asserts to work we need to annotate every place explicitly in the code where we expect that the device is powered. The places where we only assume this, but may not hold an RPM reference: - driver load We assume the device to be powered until we enable RPM. Make this explicit by taking an RPM reference around the load function. - system and runtime sudpend/resume handlers These handlers are called when the RPM reference becomes 0 and know the exact point after which the device can get powered off. Disable the RPM-reference-held check for their duration. - the IRQ, hangcheck and RPS work handlers These handlers are flushed in the system/runtime suspend handler before the device is powered off, so it's guaranteed that they won't run while the device is powered off even though they don't hold any RPM reference. Disable the RPM-reference-held check for their duration. In all these cases we still check that the device is not suspended. These explicit annotations also have the positive side effect of documenting our assumptions better. This caught additional WARNs from the atomic modeset path, those should be fixed separately. v2: - remove the redundant HAS_RUNTIME_PM check (moved to patch 1) (Ville) v3: - use a new dedicated RPM wakelock refcount to also catch cases where our own RPM get/put functions were not called (Chris) - assert also that the new RPM wakelock refcount is 0 in the RPM suspend handler (Chris) - change the assert error message to be more meaningful (Chris) - prevent false assert errors and check that the RPM wakelock is 0 in the RPM resume handler too - prevent false assert errors in the hangcheck work too - add a device not suspended assert check to the hangcheck work v4: - rename disable/enable_rpm_asserts to disable/enable_rpm_wakeref_asserts and wakelock_count to wakeref_count - disable the wakeref asserts in the IRQ handlers and RPS work too - update/clarify commit message v5: - mark places we plan to change to use proper RPM refcounting with separate DISABLE/ENABLE_RPM_WAKEREF_ASSERTS aliases (Chris) Signed-off-by:
-
Imre Deak authored
Signed-off-by:
-
Imre Deak authored
As a preparation for follow-up patches add a new helper that checks whether we hold an RPM reference, since this is what we want most of the cases. Atm this helper will only check for the HW suspended state, a follow-up patch will do the actual change to check the refcount instead. One exception is the forcewake release timer function, where it's guaranteed that the HW is on even though the RPM refcount drops to zero. This guarantee is provided by flushing the timer in the runtime suspend handler. So leave the assert_device_not_suspended check in place there. Also rename assert_device_suspended for consistency and export these helpers as a preparation for the follow-up patches. No functional change. v3: - change the assert warning message to be more meaningful (Chris) Signed-off-by:
-
Imre Deak authored
We don't really need to check this flag in the get/put/assert helpers, as on platforms without RPM support we won't ever enable RPM. That means pm.suspend will be always false and the assert will be always true. Do this to simplify the code and to let us extend the RPM asserts to all platforms for a better coverage. Motivated by Ville. v2-v3: - unchanged v4: - remove the HAS_RUNTIME_PM check from intel_runtime_pm_enable() too made possible by the previous two patches v5: - rebased on the previous new patch in the series that keeps HAS_RUNTIME_PM() in intel_runtime_pm_enable() with a permanent reference taken there Signed-off-by:
-
Imre Deak authored
Currently we disable RPM functionality on platforms that doesn't support this by not putting/getting the RPM reference we receive from the RPM core during driver loading/unloading respectively. This is somewhat obscure, so make it more explicit by keeping a reference dedicated for this particular purpose whenever the driver is loaded. This makes it possible to remove the HAS_RUNTIME_PM() special casing from every other places in the next patch. v2: - fix intel_runtime_pm_get vs. intel_runtime_pm_put in intel_power_domains_fini() v3: - take only a low level RPM reference so the ref tracking asserts continue to work (Ville) - update the commit message - move the patch earlier for bisectability Suggested-by:
-
Imre Deak authored
We can make the RPM dependency on RC6 explcit in the code by taking an actual RPM reference, instead of avoiding to drop the initial one. This will also enable us to remove the HAS_RUNTIME_PM special casing from more places in the next patch. v2: - fixed typo in commit message (Joonas) Signed-off-by:
-
Imre Deak authored
Signed-off-by:
-
Jani Nikula authored
The RVDA and RVDS (raw VBT data address and size) fields of the ASLE mailbox may specify an alternate location for VBT instead of mailbox #4. Use the alternate location if available and valid, falling back to mailbox #4 otherwise. v2: Update debug logging (Ville) Reviewed-by:
Mika Kahola <mika.kahola@intel.com> Signed-off-by:
-
- 16 Dec, 2015 11 commits
-
-
Ville Syrjälä authored
I broke AVI/HDMI/SPD infoframes on HSW+ with the register type safety changes. We were supposed to check that the infoframe data register is valid before writing the infoframe data, but the check ended up inverted, and so in practice we never wrote or enabled these infoframes. We were still sending out the GCP infoframe when the sink was deep-color capable. That and the fact that we use a single bool to track our infoframe state meant that the state checker only caught this when a HDMI sink that doesn't do deep-color was used. We really need to fix our infoframe state checking to be much more anal. But in the meantime let's just fix the regression. In fact let's just throw out the register validity check and convert some of the "unknown info frame type" debug messages into MISSING_CASE(). So far we support the same set of infoframe types on all platforms, so the silent debug messages make no sense. Cc: drm-intel-fixes@lists.freedesktop.org Fixes: f0f59a00 ("drm/i915: Type safe register read/write") Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (irc) Tested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (irc) Signed-off-by:
-
Jani Nikula authored
Slightly cleaner with early exit. Reviewed-by:
-
Jani Nikula authored
dev_priv is the new black. Or something. Reviewed-by:
-
Jani Nikula authored
Specify the maximum number of letters to print from the potentially unterminated buffer, not the minimum. While at it, use sizeof instead of a magic number. Reviewed-by:
-
Jani Nikula authored
The intel_bios.h header doesn't even need it, but other headers included from i915_drv.h do. Let's untangle the mess a bit. Reviewed-by:
-
Jani Nikula authored
Use the for_each_intel_* macros for iterating intel_encoder, intel_connector, and intel_crtc. No functional changes. Reviewed-by:
-
Jani Nikula authored
In the future the VBT might not be in mailbox #4 of the ACPI OpRegion, thus unavailable in i915_opregion, so add a separate file for the VBT. v2: Drop the locking as unneeded (Chris) v3: Rebase Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Jani Nikula authored
Hasn't been necessary since commit 115719fc Author: Williams, Dan J <dan.j.williams@intel.com> Date: Mon Oct 12 21:12:57 2015 +0000 i915: switch from acpi_os_ioremap to memremap Reviewed-by:
-
Jani Nikula authored
Because we can. It's not to be touched so tell the compiler too. Reviewed-by:
-
Jani Nikula authored
The VBT in OpRegion should fit in mailbox #4. Reviewed-by:
-
Jani Nikula authored
Make the validation function a boolean operating on a buffer of given size, removing the extra pointer dances. Move the OpRegion based VBT validation to intel_opregion_setup(), only initializing opregion->vbt if it's valid. v2: move logging about valid VBT to opregion setup too (Ville) Reviewed-by:
-
