Architectures others than x86 have a stub implementation calling
WARN_ON_ONCE(). The appropriate headers need to be included, otherwise
the header-test target will fail with:
HDRTEST drivers/gpu/drm/i915/i915_mm.h
In file included from <command-line>:
./drivers/gpu/drm/i915/i915_mm.h: In function ‘remap_io_mapping’:
./drivers/gpu/drm/i915/i915_mm.h:26:2: error: implicit declaration of function ‘WARN_ON_ONCE’ [-Werror=implicit-function-declaration]
26 | WARN_ON_ONCE(1);
| ^~~~~~~~~~~~
v2: Do not include <linux/printk.h> since call to pr_err() has been
removed
Fixes: 67c430bbaa ("drm/i915: Skip remap_io_mapping() for non-x86 platforms")
Cc: Siva Mullati <siva.mullati@intel.com>
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Siva Mullati <siva.mullati@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220131165926.3230642-3-lucas.demarchi@intel.com
Several of our i915 header files, have been including i915_reg.h. This
means that any change to i915_reg.h will trigger a full rebuild of
pretty much every file of the driver, even those that don't have any
kind of register access. Let's delete the i915_reg.h include from all
headers and add an explicit include from the .c files that truly
need the register definitions; those that need a definition of
i915_reg_t for a function definition can get it from i915_reg_defs.h
instead.
We also remove two non-register #define's (VLV_DISPLAY_BASE and
GEN12_SFC_DONE_MAX) into i915_reg_defs.h to allow us to drop the
i915_reg.h include from a couple of headers.
There's probably a lot more header dependency optimization possible, but
the changes here roughly cut the number of files compiled after 'touch
i915_reg.h' in half --- a good first step.
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220127234334.4016964-7-matthew.d.roper@intel.com
The various MI_PREDICATE registers have per-engine instances. Today we
only utilize the RCS0 instance of each, but that will likely change in
the future; switch to parameterized register definitions to make these
easier to work with going forward.
Of special note is MI_PREDICATE_RESULT_2; we only use it in one place in
the driver today in HSW-specific code. It turns out that the bspec
(page 94) lists two different offsets for this register on HSW; one is
in the standard location shared by all other platforms (base + 0x3bc)
and the other is an unusual location (0x2214). We're using the second,
non-standard offset in i915 today; that offset doesn't exist on any
other platforms (and it's not even 100% clear that it's correct for HSW)
so I've renamed the current non-standard definition to
HSW_MI_PREDICATE_RESULT_2; the new cross-platform parameterized macro
(which is still unused at the moment) uses the standard offset.
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220127234334.4016964-5-matthew.d.roper@intel.com
Let's use 'struct i915_range' to express sets of b-counter and mux
registers in the perf code. This makes the code more similar to how we
handle things like multicast register ranges, forcewake tables, shadow
tables, etc. and also lets us avoid needing symbolic register name
definitions for the various range end points. With this change, many of
the OA register definitions are no longer used in the code, so we can
drop their #define's for simplicity.
v2: Drop 'inline' from reg_in_range_table(). (Jani)
v3: Split the first range in gen12_oa_mux_regs[] so that 0xd08 isn't
whitelisted. (Umesh)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220127234334.4016964-3-matthew.d.roper@intel.com
Make life simpler by always programming DP M2/N2 with a consistent
value. This will lets use do state readout+chec unconditionally.
I was first going to just set M2/N2=M1/N1 but then it occurred
to me that it might interfere with fastboot on account of BIOS
likely leaving the registers zeroed. So let's zero out the values
instead (except TU where a zero register value actually means '1').
Still not sure that's the best approach but lets go with it for
now.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-14-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Currently we allow DRRS on IVB PCH ports, but we're missing a
few programming steps meaning it is guaranteed to not work.
And on HSW DRRS is not supported on anything but port A ever
as only transcoder EDP has the M2/N2 registers (though I'm
not sure if HSW ever has eDP on any other port).
Starting from BDW all transcoders have the dynamically
reprogrammable M/N registers so DRRS could work on any
port.
Stop initializing DRRS on ports where it cannot possibly work.
Cc: stable@vger.kernel.org
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-11-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Make things a bit more explicit by splitting
intel_cpu_transcoder_set_m_n() into separate variants for M1/N1 vs.
M2/N2. Makes the DRRS M/N programming at least more obvious.
Note that for the MST and DRRS cases we don't need to call the
M2/N2 variant at all since the transcoders that support those
do not have the M2/N2 registers.
Same could be said for i9xx_crtc_enable() but I want to do a
higher level code sharing between that valleyview_crtc_enable()
later in which case we do need the M2/N2 variant. This is also
why I keep the transcoder_has_m2_n2() in intel_cpu_transcoder_set_m2_n2()
so the caller doesn't have necessarily care what the chosen
transcoder supports.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220128103757.22461-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Catch-up with 5.17-rc2 and trying to align with drm-intel-gt-next
for a possible topic branch for merging the split of i915_regs...
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Pull drm fixes from Dave Airlie:
"This week's regular normal fixes. amdgpu and msm make up the bulk of
it, with a scattering of fixes elsewhere.
atomic:
- fix CRTC handling during modeset
privcy-screen:
- honor acpi=off
ttm:
- build fix for um
panel:
- add orientation quirk for 1NetBook OneXPlayer
amdgpu:
- Proper fix for otg synchronization logic regression
- DCN3.01 fixes
- Filter out secondary radeon PCI IDs
- udelay fixes
- Fix a memory leak in an error path
msm:
- parameter check fixes
- put_device balancing
- idle/suspend fixes
etnaviv:
- relax submit size checks
vc4:
- fix potential deadlock in DSI code
ast:
- revert 1600x900 mode change"
* tag 'drm-fixes-2022-01-28' of git://anongit.freedesktop.org/drm/drm: (25 commits)
drm/privacy-screen: honor acpi=off in detect_thinkpad_privacy_screen
Revert "drm/ast: Support 1600x900 with 108MHz PCLK"
drm/amdgpu/display: Remove t_srx_delay_us.
drm/amd/display: Wrap dcn301_calculate_wm_and_dlg for FPU.
drm/amd/display: Fix FP start/end for dcn30_internal_validate_bw.
drm/amd/display/dc/calcs/dce_calcs: Fix a memleak in calculate_bandwidth()
drm/amdgpu/display: use msleep rather than udelay for long delays
drm/amdgpu/display: adjust msleep limit in dp_wait_for_training_aux_rd_interval
drm/amdgpu: filter out radeon secondary ids as well
drm/amd/display: change FIFO reset condition to embedded display only
drm/amd/display: Correct MPC split policy for DCN301
drm/amd/display: Fix for otg synchronization logic
drm/etnaviv: relax submit size limits
drm/msm/gpu: Cancel idle/boost work on suspend
drm/msm/gpu: Wait for idle before suspending
drm/atomic: Add the crtc to affected crtc only if uapi.enable = true
drm/msm/dsi: invalid parameter check in msm_dsi_phy_enable
drm/msm/a6xx: Add missing suspend_count increment
drm/msm: Fix wrong size calculation
drm/msm/dpu: invalid parameter check in dpu_setup_dspp_pcc
...
Use REG_GENMASK() & co. for the M/N register values. There are
also a lot of weird unused defines (eg. *_OFFSET) we can just
throw out.
Also let's mask out the unused bits during readout for good
measure. Previously we only masked out the TU_SIZE from one
of the registers, which was a bit too inconsistent for my
taste.
v2: Mention the readout masking in the commit msg (Jani)
Deal wth gvt
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220127120219.20143-1-ville.syrjala@linux.intel.com
A failing usercopy of the fence_rep object will lead to a stale entry in
the file descriptor table as put_unused_fd() won't release it. This
enables userland to refer to a dangling 'file' object through that still
valid file descriptor, leading to all kinds of use-after-free
exploitation scenarios.
Fix this by deferring the call to fd_install() until after the usercopy
has succeeded.
Fixes: c906965dee ("drm/vmwgfx: Add export fence to file descriptor support")
Signed-off-by: Mathias Krause <minipli@grsecurity.net>
Signed-off-by: Zack Rusin <zackr@vmware.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Use REG_GENMASK() & co. when dealing with PIPESRC.
Note that i9xx_get_initial_plane_config() will now use the
full 16 bit mask whereas previously it used 12 bits only.
But intel_get_pipe_src_size() already used the full 16 bits
on all platforms anyway, so at least we're consistent now.
The high bits beyond the max supported pipe source size
should not be set in any case so this seems fine.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211112193813.8224-7-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Since tgl PIPE_DSL has 20 bits for the scanline. Let's bump our
definition to match. And while at it let's also add the define
for the current field readback.
We can also get rid of the gen2 vs. gen3+ nonsense since none
of the extra bits ever did anything and just always read
as zero. And now we extend all platforms to use the tgl+
20 bits deinition, but again that is fine since all the bits
used to be mbz and always read as zero on all the platforms.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20211112193813.8224-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
