- 23 2月, 2022 2 次提交
-
-
由 Tejas Upadhyay 提交于
Add the PCH ID for ADL-N. Signed-off-by: NTejas Upadhyay <tejaskumarx.surendrakumar.upadhyay@intel.com> Reviewed-by: NAnusha Srivatsa <anusha.srivatsa@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220127103520.348015-1-tejaskumarx.surendrakumar.upadhyay@intel.com
-
由 Manasi Navare 提交于
With some VRR panels, user can turn VRR ON/OFF on the fly from the panel settings. When VRR is turned OFF ,sends a long HPD to the driver clearing the Ignore MSA bit in the DPCD. Currently the driver parses that onevery HPD but fails to reset the corresponding VRR Capable Connector property. Hence the userspace still sees this as VRR Capable panel which is incorrect. Fix this by explicitly resetting the connector property. v2: Reset vrr capable if status == connector_disconnected v3: Use i915 and use bool vrr_capable (Jani Nikula) v4: Move vrr_capable to after update modes call (Jani N) Remove the redundant comment (Jan N) Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: NManasi Navare <manasi.d.navare@intel.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220215202601.22943-1-manasi.d.navare@intel.com
-
- 22 2月, 2022 1 次提交
-
-
由 Imre Deak 提交于
Add display workaround # 1309179469 , which fixes a PHY hang when switching from TBT mode to DP-alt/legacy mode. The workaround also requires an IFWI/PHY firmware change, before that this change has no effect (the DKL_PCS_DW5/SOFTRESET flag is always cleared). HSDES: 18018237866 HSDES: 16014473319 Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218122611.767974-1-imre.deak@intel.com
-
- 21 2月, 2022 5 次提交
-
-
由 Jani Nikula 提交于
Always use forward declarations instead of includes in headers if possible. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220214173644.2097124-1-jani.nikula@intel.com
-
由 Jani Nikula 提交于
The ICL DSI registers have fairly isolated usage. Split the register macros to a separate file. Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220217224023.3994777-4-jani.nikula@intel.com
-
由 Jani Nikula 提交于
The VLV (including CHV, BXT, and GLK) DSI registers have fairly isolated usage. Split the register macros to separated files. Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220217224023.3994777-3-jani.nikula@intel.com
-
由 Jani Nikula 提交于
Having a separate definition will be useful for splitting VLV and ICL register files. Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220217224023.3994777-2-jani.nikula@intel.com
-
由 Jani Nikula 提交于
The VBT DSI video transfer mode field values have been defined in terms of the VLV MIPI_VIDEO_MODE_FORMAT register. The ICL DSI code maps that to ICL DSI_TRANS_FUNC_CONF() register. The values are the same, though the shift is different. Make a clean break and disassociate the values from each other. Assume the values can be different, and translate the VBT value to VLV and ICL register values as needed. Use the existing macros from intel_bios.h. This will be useful in splitting the DSI register macros to files by DSI implementation. Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220217224023.3994777-1-jani.nikula@intel.com
-
- 20 2月, 2022 2 次提交
-
-
由 Lucas De Marchi 提交于
First the simplest ones: - iosys_map_memset(): when abstracting system and I/O memory, just like the memcpy() use case, memset() also has dedicated functions to be called for using IO memory. - iosys_map_memcpy_from(): we may need to copy data from I/O memory, not only to. In certain situations it's useful to be able to read or write to an offset that is calculated by having the memory layout given by a struct declaration. Usually we are going to read/write a u8, u16, u32 or u64. As a pre-requisite for the implementation, add iosys_map_memcpy_from() to be the equivalent of iosys_map_memcpy_to(), but in the other direction. Then add 2 pairs of macros: - iosys_map_rd() / iosys_map_wr() - iosys_map_rd_field() / iosys_map_wr_field() The first pair takes the C-type and offset to read/write. The second pair uses a struct describing the layout of the mapping in order to calculate the offset and size being read/written. We could use readb, readw, readl, readq and the write* counterparts, however due to alignment issues this may not work on all architectures. If alignment needs to be checked to call the right function, it's not possible to decide at compile-time which function to call: so just leave the decision to the memcpy function that will do exactly that. Finally, in order to use the above macros with a map derived from another, add another initializer: IOSYS_MAP_INIT_OFFSET(). v2: - Rework IOSYS_MAP_INIT_OFFSET() so it doesn't rely on aliasing rules within the union - Add offset to both iosys_map_rd_field() and iosys_map_wr_field() to allow the struct itself to be at an offset from the mapping - Add documentation to iosys_map_rd_field() with example and expected memory layout v3: - Drop kernel.h include as it's not needed anymore Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Mauro Carvalho Chehab <mchehab@kernel.org> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: NMauro Carvalho Chehab <mchehab@kernel.org> Reviewed-by: NMatt Atwood <matthew.s.atwood@intel.com> Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220216174147.3073235-3-lucas.demarchi@intel.com
-
由 Lucas De Marchi 提交于
In certain situations it's useful to be able to write to an offset of the mapping. Add a dst_offset to iosys_map_memcpy_to(). Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Christian König <christian.koenig@amd.com> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: NChristian König <christian.koenig@amd.com> Reviewed-by: NThomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220216174147.3073235-2-lucas.demarchi@intel.com
-
- 19 2月, 2022 7 次提交
-
-
由 Matt Roper 提交于
DG2 supports a 5th display output which the hardware refers to as "TC1," even though it isn't a Type-C output. This behaves similarly to the TC1 on past platforms with just a couple minor differences: * DG2's TC1 bit in SDEISR is at bit 25 rather than 24 as it is on ICP/TGP/ADP. * DG2 doesn't need the hpd inversion setting that we had to use on DG1 v2: intel_ddi_init(dev_priv, PORT_TC1); [Matt] Cc: Swathi Dhanavanthri <swathi.dhanavanthri@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NRamalingam C <ramalingam.c@intel.com> Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218010328.183423-3-lucas.demarchi@intel.com
-
由 Matt Roper 提交于
Our early understanding of DG2 was incorrect; since the 5th display isn't actually a Type-C output, 38.4 MHz input clocks are never used on this platform and we can drop the corresponding MPLLB tables. Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NRamalingam C <ramalingam.c@intel.com> Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: NUma Shankar <uma.shankar@intel.com> Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218010328.183423-2-lucas.demarchi@intel.com
-
由 Jouni Högander 提交于
Currently ICL_PHY_MISC macro is returning offset 0x64C10 for PHY_E. The PORT_TC1 port is not yet enabled properly in the driver, but intel_phy_snps.c is relying on intel_phy_is_snps() to filter out unavailable phys. That function was already considering the last phy as available. Just correct the offset of the last phy to 0x64C14 as the rest of the support for it is coming on next commits. Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Signed-off-by: NJouni Högander <jouni.hogander@intel.com> Signed-off-by: NRamalingam C <ramalingam.c@intel.com> Reviewed-by: NUma Shankar <uma.shankar@intel.com> Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com> Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218010328.183423-1-lucas.demarchi@intel.com
-
由 Ville Syrjälä 提交于
Add some debugs on what exactly we're doing to the QGV point mask in the icl+ sagv pre/post plane update hooks. Currently we're just guessing. v2: s/u32/u16/ for consistency with the mask sizes (Stan) Reviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-5-ville.syrjala@linux.intel.com
-
由 Ville Syrjälä 提交于
To further reduce the confusion between the pre-icl vs. icl+ SAGV codepaths let's do a full split. Reviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-4-ville.syrjala@linux.intel.com
-
由 Ville Syrjälä 提交于
If the only thing that is changing is SAGV vs. no SAGV but the number of active planes and the total data rates end up unchanged we currently bail out of intel_bw_atomic_check() early and forget to actually compute the new WGV point mask and thus won't actually enable/disable SAGV as requested. This ends up poorly if we end up running with SAGV enabled when we shouldn't. Usually ends up in underruns. To fix this let's go through the QGV point mask computation if either the data rates/number of planes, or the state of SAGV is changing. v2: Check more carefully if things are changing to avoid the extra calculations/debugs from introducing unwanted overhead Cc: stable@vger.kernel.org Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> #v1 Fixes: 20f505f2 ("drm/i915: Restrict qgv points which don't have enough bandwidth.") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-3-ville.syrjala@linux.intel.com
-
由 Ville Syrjälä 提交于
When changing between SAGV vs. no SAGV on tgl+ we have to update the use_sagv_wm flag for all the crtcs or else an active pipe not already in the state will end up using the wrong watermarks. That is especially bad when we end up with the tighter non-SAGV watermarks with SAGV enabled. Usually ends up in underruns. Cc: stable@vger.kernel.org Reviewed-by: NStanislav Lisovskiy <stanislav.lisovskiy@intel.com> Fixes: 7241c57d ("drm/i915: Add TGL+ SAGV support") Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220218064039.12834-2-ville.syrjala@linux.intel.com
-
- 18 2月, 2022 13 次提交
-
-
由 Ville Syrjälä 提交于
Reading the PIPECONF enable bit out from the hardware in i9xx_set_pipeconf() on i830 is pointless as the bit should always be set since we keep both pipes constantly running on i830. Drop the pointless read and just always keep the bit set. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220202111616.1579-4-ville.syrjala@linux.intel.comReviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
-
由 Ville Syrjälä 提交于
The CHV CGM CSC registers are single buffered and so we may have to write them from the vblank worker, which imposes very tight dealines. Drop the pointless locking for the register accessess to reduce the overhead. All the other registers we bash from the vblank worker (LUTs) were already made lockless earlier. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220202111616.1579-3-ville.syrjala@linux.intel.comReviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
-
由 Ville Syrjälä 提交于
The pipe/output CSC register writes don't need to be locked since all the registers are suitably isolated to their own cachelines. So eliminate the locks to reduce the overhead during the vblank evade critical section. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220202111616.1579-2-ville.syrjala@linux.intel.comReviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
-
由 Ville Syrjälä 提交于
We don't want any RMWs in the part of the commit that happens under vblank evasion. Eventually we want to use the DSB to handle that and it can't read registers at all. Also reads are just slowing us down needlessly. Let's move the whole PIPE_CHICKEN stuff out from the critical section since we don't have anything there that needs to be syncrhonized with other plane/pipe registers. If we ever need to add such things then we have to move it back, but without doing any reads. TODO: should look into eliminating the RMW anyway... Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220202111616.1579-1-ville.syrjala@linux.intel.comReviewed-by: NJuha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
-
由 José Roberto de Souza 提交于
PSR2 workaround required when mode has delayed vblank. BSpec: 52890 BSpec: 49421 Cc: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: NJouni Högander <jouni.hogander@intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220210185223.95399-2-jose.souza@intel.com
-
由 José Roberto de Souza 提交于
Grouping inside of the same if all the programing sequences and workarounds of PSR2. The order of programing changed in intel_psr_enable_source() but it will not affect PSR2 as at this point PSR2_ENABLE is still disabled. Cc: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Reviewed-by: NJouni Högander <jouni.hogander@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220210185223.95399-1-jose.souza@intel.com
-
由 José Roberto de Souza 提交于
A new programming step was added to combo and TC PLL sequences. If override_AFC_startup is set in VBT, driver should overwrite AFC_startup value to 0x0 or 0x7 in PLL's div0 register. The current understating is that only TGL needs this and all other display 12 and newer platforms will have a older VBT or a newer VBT with override_AFC_startup set to 0 but in any case there is a drm_warn_on_once() to let us know if this is not true. v2: - specification updated, now AFC can be override to 0x0 or 0x7 - not using a union for div0 (Imre) - following previous wrong vbt naming: bits instead of bytes (Imre) BSpec: 49204 BSpec: 20122 BSpec: 49968 BSpec: 71360 Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220216134059.25348-1-jose.souza@intel.com
-
由 Imre Deak 提交于
BIOS may leave a TypeC PHY in a connected state even though the corresponding port is disabled. This will prevent any hotplug events from being signalled (after the monitor deasserts and then reasserts its HPD) until the PHY is disconnected and so the driver will not detect a connected sink. Rebooting with the PHY in the connected state also results in a system hang. Fix the above by disconnecting TypeC PHYs on disabled ports. Before commit 64851a32 the PHY connected state was read out even for disabled ports and later the PHY got disconnected as a side effect of a tc_port_lock/unlock() sequence (during connector probing), hence recovering the port's hotplug functionality. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5014 Fixes: 64851a32 ("drm/i915/tc: Add a mode for the TypeC PHY's disconnected state") Cc: <stable@vger.kernel.org> # v5.16+ Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NJosé Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220217152237.670220-1-imre.deak@intel.com
-
由 Jani Nikula 提交于
The variable should obviously be local, not static. Fixes: a421d8a9 ("drm/i915/dp: rewrite DP 2.0 128b/132b link training based on errata") Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NLucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220217083938.3587465-1-jani.nikula@intel.com
-
由 Ville Syrjälä 提交于
Use REG_GENMASK() & co. for ilk+ watermark registers. v2: Stick to the current bitmask sizes (Jani) Fix "watermarm" typo (Jani) Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220216232806.6194-4-ville.syrjala@linux.intel.com
-
由 Ville Syrjälä 提交于
No reason the high level intel_update_crtc() needs to know that there is something magical about the commit order of planes between different platforms. So let's hide that detail even better. In order to keep to somewhat consistent naming between things we shall call this intel_crtc_planes_update_arm() to match the plane->update_arm() vfunc naming convention. And let's rename the noarm counterpart to intel_crtc_planes_update_noarm() to more clearly associate it with the plane->update_noarm() vfunc. v2: Change the naming convention a bit Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220216232806.6194-2-ville.syrjala@linux.intel.com
-
由 Ville Syrjälä 提交于
Give names to the SSKPD/MLTR fields, and use the REG_GENMASK* and REG_FIELD_GET*. Also drop the bogus non-mirrored SSKP register define. v2: Rebase due to intel_mchbar_regs.h Leave gen6_check_mch_setup() in place for the moment Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220216232806.6194-3-ville.syrjala@linux.intel.com
-
由 Matt Roper 提交于
We need to use phy_name() to convert the PHY value into a human-readable character in the error message. Fixes: a6a12811 ("drm/i915/dg2: Wait for SNPS PHY calibration during display init") Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NSwathi Dhanavanthri <swathi.dhanavanthri@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220215163545.2175730-1-matthew.d.roper@intel.com
-
- 17 2月, 2022 10 次提交
-
-
由 Jani Nikula 提交于
Prefer forward declarations over includes if possible. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220214173810.2108975-2-jani.nikula@intel.com
-
由 Jani Nikula 提交于
Move the static inline next to the only caller. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220214173810.2108975-1-jani.nikula@intel.com
-
由 Jani Nikula 提交于
As all access to struct intel_fbdev guts is nicely stowed away in intel_fbdev.c, we can hide the struct definition there too. Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220215122957.2755529-2-jani.nikula@intel.com
-
由 Jani Nikula 提交于
Wrap accessing struct intel_fbdev guts in a helper. v2: s/intel_fbdev_to_framebuffer/intel_fbdev_framebuffer/g (Ville) Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220215122957.2755529-1-jani.nikula@intel.com
-
由 Tong Zhang 提交于
drm/i915 adds some extra cflags, namely -Wall, which causes instances of -Wformat-security to appear when building with clang, even though this warning is turned off kernel-wide in the main Makefile: drivers/gpu/drm/i915/gt/intel_gt.c:983:2: error: format string is not a string literal (potentially insecure) [-Werror,-Wformat-security] GEM_TRACE("ERROR\n"); ^~~~~~~~~~~~~~~~~~~~ ./drivers/gpu/drm/i915/i915_gem.h:76:24: note: expanded from macro 'GEM_TRACE' #define GEM_TRACE(...) trace_printk(__VA_ARGS__) ^~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/kernel.h:369:3: note: expanded from macro 'trace_printk' do_trace_printk(fmt, ##__VA_ARGS__); \ ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/kernel.h:383:30: note: expanded from macro 'do_trace_printk' __trace_bprintk(_THIS_IP_, trace_printk_fmt, ##args); \ ^~~~~~~~~~~~~~~~ drivers/gpu/drm/i915/gt/intel_gt.c:983:2: note: treat the string as an argument to avoid this This does not happen with GCC because it does not enable -Wformat-security with -Wall. Disable -Wformat-security within the i915 Makefile so that these warnings do not show up with clang. Signed-off-by: NTong Zhang <ztong0001@gmail.com> Reviewed-by: NNathan Chancellor <nathan@kernel.org> Signed-off-by: NJani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220214195821.29809-1-ztong0001@gmail.com
-
由 Jani Nikula 提交于
As the excessive #includes from i915_drv.h were axed, kvmgt.c build started failing. Add the necessary #include where needed. Reported-by: NStephen Rothwell <sfr@canb.auug.org.au> Fixes: 14da21cc ("drm/i915: axe lots of unnecessary includes from i915_drv.h") Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: Zhi Wang <zhi.a.wang@intel.com> Cc: intel-gvt-dev@lists.freedesktop.org Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-by: NZhi Wang <zhi.a.wang@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220215122030.2741656-1-jani.nikula@intel.com
-
由 Matt Roper 提交于
The new header from the previous commit didn't get added after a conflict resolution...let's add it now. Fixes: e30e6c7b ("drm/i915: Move MCHBAR registers to their own header") Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220215061342.2055952-2-matthew.d.roper@intel.com
-
由 Matt Roper 提交于
Registers that exist within the MCH BAR and are mirrored into the GPU's MMIO space are a good candidate to separate out into their own header. For reference, the mirror of the MCH BAR starts at the following locations in the graphics MMIO space (the end of the MCHBAR range differs slightly on each platform): * Pre-gen6: 0x10000 * Gen6-Gen11 + RKL: 0x140000 v2: - Create separate patch to swtich a few register definitions to be relative to the MCHBAR mirror base. - Drop upper bound of MCHBAR mirror from commit message; there are too many different combinations between various platforms to list out, and the documentation is spotty for the older pre-gen6 platforms anyway. Bspec: 134, 51771 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220215061342.2055952-2-matthew.d.roper@intel.com
-
由 Matt Roper 提交于
A few of our MCH registers are defined with absolute register offsets. For consistency, let's switch their definitions to be relative offsets from MCHBAR_MIRROR_BASE. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220215061342.2055952-1-matthew.d.roper@intel.com
-
由 Matt Roper 提交于
The random order of register definitions we have today causes a lot of confusion and unintentional duplication when new registers/bits are added to the driver. Let's order the GT register file by MMIO offset A couple duplicated/unused register definitions are dropped while doing this re-order: GEN11_GT_INTR_DW{0,1}, GEN11_IIR_REG{0,1}_SELECTOR, and GEN11_INTR_IDENTITY_REG{0,1} aren't used anywhere in the driver because we have other parameterized macros referencing those registers. Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NMatt Atwood <matthew.s.atwood@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220209051140.1599643-7-matthew.d.roper@intel.com
-