Move fw_info out of struct intel_package_header to allow it to grow more
easily in future. To make a cleaner move, let's also extract a function to
search the header for the dmc_offset.
While reviewing this code I wondered why we continued the search even
after finding a suitable firmware. Add a comment to explain we will
continue to try to find a more specific firmware version, even if this
is not required by the spec.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190607091230.1489-3-lucas.demarchi@intel.com
While loading the DMC firmware we were double checking the headers made
sense, but in no place we checked that we were actually reading memory
we were supposed to. This could be wrong in case the firmware file is
truncated or malformed.
Before this patch:
# ls -l /lib/firmware/i915/icl_dmc_ver1_07.bin
-rw-r--r-- 1 root root 25716 Feb 1 12:26 icl_dmc_ver1_07.bin
# truncate -s 25700 /lib/firmware/i915/icl_dmc_ver1_07.bin
# modprobe i915
# dmesg| grep -i dmc
[drm:intel_csr_ucode_init [i915]] Loading i915/icl_dmc_ver1_07.bin
[drm] Finished loading DMC firmware i915/icl_dmc_ver1_07.bin (v1.7)
i.e. it loads random data. Now it fails like below:
[drm:intel_csr_ucode_init [i915]] Loading i915/icl_dmc_ver1_07.bin
[drm:csr_load_work_fn [i915]] *ERROR* Truncated DMC firmware, rejecting.
i915 0000:00:02.0: Failed to load DMC firmware i915/icl_dmc_ver1_07.bin. Disabling runtime power management.
i915 0000:00:02.0: DMC firmware homepage: https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/i915
Before reading any part of the firmware file, validate the input first.
Fixes: eb805623d8 ("drm/i915/skl: Add support to load SKL CSR firmware.")
Cc: stable@vger.kernel.org
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190605235535.17791-1-lucas.demarchi@intel.com
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
v2: Add function argument names to fix checkpatch warning
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/44ceebca0206de9c40dc6794b660d84b8994f700.1554461791.git.jani.nikula@intel.com
The majority of runtime-pm operations are bounded and scoped within a
function; these are easy to verify that the wakeref are handled
correctly. We can employ the compiler to help us, and reduce the number
of wakerefs tracked when debugging, by passing around cookies provided
by the various rpm_get functions to their rpm_put counterpart. This
makes the pairing explicit, and given the required wakeref cookie the
compiler can verify that we pass an initialised value to the rpm_put
(quite handy for double checking error paths).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190114142129.24398-16-chris@chris-wilson.co.uk
Move max firmware size to the same if ladder with firmware name and
required version. This allows us to detect the missing max size for a
platform without actually loading the firmware, and makes the whole
thing easier to maintain.
We need to move the power get earlier to allow for early return in the
missing platform case. While at it, extend the comment on why we return
with the reference held on errors.
We also need to move the module parameter override later to reuse the
max firmware size, which is independent of the override.
v2: Add comment on why we leak the wakeref on errors (Chris)
v3: Rebase
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180926133414.22073-2-jani.nikula@intel.com
This patch resolves the DMC FW loading issue.
Earlier DMC FW package have only one DMC FW for one stepping. But as such
there is no such restriction from Package side.
For ICL icl_dmc_ver1_07.bin binary package has DMC FW for 2 steppings.
So while reading the dmc_offset from package header, for 1st stepping
offset used to come 0x0 and was working fine till now.
But for second stepping and other steppings, offset is non zero number
and is in dwords. So we need to convert into bytes to fetch correct DMC
FW from correct place.
v2 : Added check for DMC FW max size for various gen. (Imre Deak)
v3 : Corrected naming convention for various gen. (Imre Deak)
v4 : Initialized max_fw_size to 0
v5 : Corrected DMC FW MAX_SIZE for various gen. (Imre Deak)
v6 : Fixed the typo issues.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jyoti Yadav <jyoti.r.yadav@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1535695223-4648-1-git-send-email-jyoti.r.yadav@intel.com
The case where the firmware isn't specified for a platform (although
runtime PM works only with DMC on this platform) is the same case where
the firmware is specified but can't be loaded for some reason. Hence we
need to get a display init power domain ref in the first case too to
keep the refcount bookkeeping in balance.
Also convert the related log message to be a debug one, since it's a
valid scenario for a new platform, where we need to have
dev_info->has_csr=1 set, but add support for actually loading the
firmware only later.
v2:
- In addition to the debug log, WARN on non-alpha support platforms,
since then the first case isn't valid scenario. (Chris)
References: https://bugs.freedesktop.org/show_bug.cgi?id=107382
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180815131038.24446-1-imre.deak@intel.com
As the Geminilake firmware is now merged to linux-firmware.git
use MODUE_FIRMWARE to load the firmware.
This removes the error message in the dmesg log:
i915 0000:00:02.0: Direct firmware load for
i915/glk_dmc_ver1_04.bin failed with error -2
i915 0000:00:02.0: Failed to load DMC firmware
i915/glk_dmc_ver1_04.bin. Disabling runtime power management.
i915 0000:00:02.0: DMC firmware homepage:
https://01.org/linuxgraphics/downloads/firmware
and now shows that the firmware has correctly loaded:
[drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4)
Signed-off-by: Ian W MORRISON <ianwmorrison@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180411044213.383-1-ianwmorrison@gmail.com
Currently we're doing:
1. acquire lock
2. write word to hardware
3. release lock
4. repeat from 1
to load the DMC firmware. Due to the cost of acquiring/releasing a lock,
and the size of the DMC firmware, this slows down DMC loading a lot.
This patch simply acquires the lock, writes the entire firmware,
then releases the lock. Testing shows resume speedups
in the order of 10ms on platforms with DMC firmware (GEN9+).
v2: Per feedback from Chris & Ville there's no need to do the whole
forcewake dance, so lose that bit (Chris, Ville)
v3: Actually send the new version of the patch...
v4: Don't acquire the uncore lock. Disable preempt. (Chris)
Signed-off-by: David Weinehall <david.weinehall@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170905131050.11655-1-david.weinehall@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Two warnings are produced by gcc (tested with gcc 6.2.1):
drivers/gpu/drm/i915/intel_csr.c: In function ‘csr_load_work_fn’:
drivers/gpu/drm/i915/intel_csr.c:400:5: error: ‘fw’ is used
uninitialized in this function [-Werror=uninitialized]
if (fw)
^
and
In file included from drivers/gpu/drm/i915/i915_drv.h:47:0,
from drivers/gpu/drm/i915/intel_guc_loader.c:30:
drivers/gpu/drm/i915/intel_guc_loader.c: In function ‘intel_guc_init’:
./include/drm/drmP.h:228:2: error: ‘fw’ may be used uninitialized in this
function -Werror=maybe-uninitialized]
drm_printk(KERN_DEBUG, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
^~~~~~~~~~
drivers/gpu/drm/i915/intel_guc_loader.c:595:25: note: ‘fw’ was declared here
const struct firmware *fw;
^~
When CONFIG_DRM_I915_WERROR is set, those warnings break the build.
Initializing fw pointer to NULL in both cases removes the warnings.
Signed-off-by: Jérémy Lefaure <jeremy.lefaure@lse.epita.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20161128234319.20800-1-jeremy.lefaure@lse.epita.fr
