Jani Nikula [Wed, 12 Jan 2022 11:03:17 +0000 (13:03 +0200)]
drm/i915/mst: read link status only when requested by sink in ESI
The link service irq vector in DPCD 0x2005 contains the link status
changed bit to indicate the status should be checked. Only read and
check the link status when requested by the sink.
This also reduces the confusion around the buffer size for the combined
ESI and link status. Alas, we still need to take into account that all
link status helpers expect a buffer of DP_LINK_STATUS_SIZE (6) while the
link status in ESI only has 4 bytes.
Jani Nikula [Wed, 12 Jan 2022 11:03:15 +0000 (13:03 +0200)]
drm/i915/mst: debug log 4 bytes of ESI right after reading
For whatever reason, the ESI link service irq vector was missing from
the debug output. Add the missing byte, clean up the debug message, and
do the logging right after reading the data.
Smaller functions make the thing easier to read. Debug log failures to
ack.
Note: Looks like we have the retry loop simply because of hysterical
raisins, dating back to the original DP MST enabling. Keep it, though I
have no idea why we have it.
Jani Nikula [Thu, 20 Jan 2022 11:33:46 +0000 (13:33 +0200)]
drm/i915: split out i915_reg_read_ioctl() to i915_ioctl.[ch]
Add new files i915_ioctl.[ch] to hold small ioctls that are out of place
everywhere else, and not big enough to warrant a file of their own. For
starters, it's just for i915_reg_read_ioctl() that's a bit high level
for a low level implementation that intel_uncore.[ch] is.
Ville Syrjälä [Wed, 22 Dec 2021 16:17:38 +0000 (18:17 +0200)]
drm/i915/hdmi: Ignore DP++ TMDS clock limit for native HDMI ports
Lots of machines these days seem to have a crappy type1 DP dual
mode adaptor chip slapped onto the motherboard. Based on the
DP dual mode spec we currently limit those to 165MHz max TMDS
clock.
Windows OTOH ignores DP dual mode adaptors when the VBT
indicates that the port is not actually DP++, so we can
perhaps assume that the vendors did intend that the 165MHz
clock limit doesn't apply here. Though it would be much
nicer if they actually declared an explicit limit through
VBT, but that doesn't seem to be happening either.
So in order to match Windows behaviour let's ignore the
DP dual mode adaptor's TMDS clock limit for ports that
don't look like DP++ in VBT.
Unfortunately many older VBTs misdelcare their DP++ ports
as just HDMI (eg. ILK Dell Latitude E5410) or DP (eg. SNB
Lenovo ThinkPad X220). So we can't really do this universally
without risking black screens. I suppose a sensible cutoff
is HSW+ since that's when 4k became a thing and one might
assume that the machines have been tested to work with higher
TMDS clock rates.
Ville Syrjälä [Fri, 17 Dec 2021 15:54:02 +0000 (17:54 +0200)]
drm/i915/bios: Nuke DEVICE_TYPE_DP_DUAL_MODE_BITS
Replace the DEVICE_TYPE_DP_DUAL_MODE_BITS stuff with just
a DP+HDMI check. The rest of the bits shouldn't really
matter anyway.
The slight change in behaviour here is that now we do look at
the DEVICE_TYPE_NOT_HDMI_OUTPUT bit (via
intel_bios_encoder_supports_hdmi()) when we previously ignored it.
The one platform we know that has problems with that bit is VLV.
But IIRC the problem was always that buggy VBTs basically never
set that bit. So that should be OK since all it would do is make
all DVI ports look like HDMI ports instead. Also can't imagine
there are many VLV machines with actual DVI ports in existence.
We still keep the rest of the dvo_port/aux_ch checks as we
can't trust that DP+HDMI device type equals DP++ due to
buggy VBTs.
Ville Syrjälä [Fri, 17 Dec 2021 15:54:01 +0000 (17:54 +0200)]
drm/i915/bios: Throw out the !has_ddi_port_info() codepaths
Now that we parse the DDI port info from the VBT on all g4x+ platforms
we can throw out all the old codepaths in intel_bios_is_port_present(),
intel_bios_is_port_edp() and intel_bios_is_port_dp_dual_mode(). None
of these should be called on pre-g4x platforms.
For good measure throw in a WARN into intel_bios_is_port_present()
should someone get the urge to call it on older platforms. The
other two functions are specific to HDMI and DP so should not need
any protection as those encoder types don't even exist on older
platforms.
Ville Syrjälä [Fri, 17 Dec 2021 15:54:00 +0000 (17:54 +0200)]
drm/i915/bios: Use i915->vbt.ports[] for all g4x+
Extend the vbt.ports[] stuff for all g4x+ platforms. We do need
to drop the version check as some elk/ctg machines may have VBTs
older than that. The oldest I know is an elk with version 142.
But the child device stuff has had the correct size since at
least version 125 (observed on my sdg), so from that angle this
should be totally safe.
This does couple of things:
- Start using the aux_ch/ddc_pin from VBT instead of just the
hardcoded defaults. Hopefully there are no VBTs with entirely
bogus information here.
- Start using i915->vbt.ports[] for intel_bios_is_port_dp_dual_mode().
Should be fine as the logic doesn't actually change.
- Start using i915->vbt.ports[] for intel_bios_is_port_edp().
The old codepath only looks at the DP DVO ports, the new codepath
looks at both DP and HDMI DVO ports. In principle that should not
matter. We also stop looking at some of the other device type bits
(eg. LVDS,MIPI,ANALOG,etc.). Hopefully no VBT is broken enough that
it sets up totally conflicting device type bits (eg. LVDS+eDP at the
same time). We also lose the "g4x->no eDP ever" hardcoding (shouldn't
be hard to re-introduce that into eg. sanitize_device_type() if needed).
Lightly smoke tested on a set of machines (one of ctg,ilk,snb,ivb each)
with both DP and HDMI (DP++). Everything still worked as it should.
Ville Syrjälä [Fri, 17 Dec 2021 15:53:59 +0000 (17:53 +0200)]
drm/i915/bios: Use i915->vbt.ports[] on CHV
CHV is currently straddling the divide by using parse_ddi_ports() stuff
for aux_ch/ddc_pin but going through all old codepaths for the rest
(intel_bios_is_port_present(), intel_bios_is_port_edp(),
intel_bios_is_port_dp_dual_mode()). Let's switch over full and use
i915->vbt.ports[] for the rest of the stuff.
dvo_port_to_port() doesn't know about DSI so we won't get into
any kind of "is port B HDMI or DSI or both?" conundrum, which
could otherwise happen on VLV/CHV due to DSI ports living in a
separate world from the other digital ports.
Including Jani's detailed analysis here for posterity:
"We stop checking for port A for CHV in intel_bios_is_port_present(), but
it's a warn and I don't recall any bug reports, so probably fine. We
could add a check in parse_ddi_port(), but meh.
Ditto for intel_bios_is_port_dp_dual_mode(), except it doesn't have a
warn.
The eDP check in intel_bios_is_port_edp() becomes slightly more
relaxed. Both the old and new check require these to be set:
It's possible we've added these just as a sanity check for broken VBTs
more than anything. I guess I'd see if actual problems arise.
Bottom line, I think the functional changes matter only for VBTs with
bogus data."
I agree that it should work assuming the VBT isn't totally insane.
Modern windows drivers also don't seem to check any of those
additional device type bits, which may or may not matter for older
devices (no idea what some old driver versions are checking).
Ville Syrjälä [Wed, 8 Dec 2021 15:00:50 +0000 (17:00 +0200)]
drm/i915: Remove zombie async flip vt-d w/a
This async flip vt-d w/a was moved to a different place in
commit 7d396cacaea6 ("drm/i195: Make the async flip VT-d workaround
dynamic") but the drm-intel-fixes cherry-pick commit b2d73debfdc1
("drm/i915: Extend the async flip VT-d w/a to skl/bxt") resurrected
the original code as well. So now we have this w/a in two places.
Remove the resurrected zombie code.
Not done as a revert to hopefully prevent any kind of
automagic stable backport.
Jani Nikula [Wed, 19 Jan 2022 11:05:28 +0000 (13:05 +0200)]
drm/i915/dpll: make intel_shared_dpll_funcs internal to intel_dpll_mgr.c
Move struct intel_shared_dpll_funcs to intel_dpll_mgr.c, as no other
place needs to have access to it. We also don't need to have kernel-doc
documentation for file internal structures, so drop them while at it.
Ville Syrjälä [Wed, 1 Dec 2021 15:25:52 +0000 (17:25 +0200)]
drm/i915: Nuke pointless middle men for skl+ plane programming
There is no real point in having this two stage
skl_program_plane*() vs. skl_plane_update*() wrapper stuff.
All we need to do is determine the correct color plane and
we're done.
Ville Syrjälä [Wed, 1 Dec 2021 15:25:42 +0000 (17:25 +0200)]
drm/i915: Sipmplify PLANE_STRIDE masking
There's no need to have separate masks for the stride bitfield
in PLANE_STRIDE for different platforms. All the extra bits
are hardcoded to zero anyway.
Also the masks we're using now don't even match the actual hardware
since the bitfield was only 10 bits on skl/derivatives, only getting
bumped to 11 bits on glk.
Jani Nikula [Wed, 12 Jan 2022 10:57:03 +0000 (12:57 +0200)]
drm/i915/dp: make intel_dp_pack_aux() static again
The last user of intel_dp_pack_aux() outside intel_dp_aux.c got removed
in commit ad26451a7902 ("drm/i915/display: Drop PSR support from HSW and
BDW"). Make the function static again.
Rename the pack/unpack functions to follow the usual naming conventions
while at it.
Rodrigo Vivi [Wed, 12 Jan 2022 17:06:51 +0000 (12:06 -0500)]
Merge tag 'gvt-next-2022-01-12' of https://github.com/intel/gvt-linux into drm-intel-next
gvt-next-2022-01-12
- Constify some pointers. (Rikard Falkeborn)
- Use list_entry to access list members. (Guenter Roeck)
- Fix cmd parser error for Passmark9. (Zhenyu Wang)
These are never modified, so make them const to allow the compiler to
put them in read-only memory. WHile at it, make the description const
char* since it is never modified.
Zhenyu Wang [Mon, 11 Oct 2021 04:33:29 +0000 (12:33 +0800)]
drm/i915/gvt: Fix cmd parser error for Passmark9
This is to add one new register required for windows guest driver
update when running Passmark9, otherwise cmd parser would complain
and fail guest workload.
Matt Roper [Tue, 11 Jan 2022 05:16:00 +0000 (21:16 -0800)]
drm/i915: Drop unused _PORT3 and _PORT4 TC phy register offsets
All MG/DKL PHY register regions are evenly spaced offset-wise (0x168000,
0x169000, 0x16A000, 0x16B000) so the _MMIO_PORT() macro we use to access
their registers only needs the first two offsets. We can drop the
_PORT3 and _PORT4 offsets which are never directly referenced.
Matt Roper [Tue, 11 Jan 2022 05:15:59 +0000 (21:15 -0800)]
drm/i915: Move TC PHY registers to their own header
Registers representing the MG/DKL TC PHYs (including the TC DPLLs which
exist inside the PHY) are only needed in a couple files and on specific
platforms; let's keep them separate from the general register pool.
Matt Roper [Tue, 11 Jan 2022 05:15:56 +0000 (21:15 -0800)]
drm/i915/gt: Move engine registers to their own header
Let's continue breaking up and cleaning up the massive i915_reg.h file
by moving all registers that are defined in relation to an engine base
to their own header.
There are probably a bunch of other "engine registers" that we haven't
moved yet (especially those that belong to the render engine in the
0x2??? range), but this is a relatively straightforward first step.
Matt Roper [Tue, 11 Jan 2022 05:15:55 +0000 (21:15 -0800)]
drm/i915: Introduce i915_reg_defs.h
We'd like to start splitting i915_reg.h into various domain-specific
register files and cleaning them up. Let's move the basic macros and
type definitions to their own header file that can be including in each
of the new split headers.
Matt Roper [Tue, 11 Jan 2022 05:15:52 +0000 (21:15 -0800)]
drm/i915: Parameterize ECOSKPD
Combine the separate render and blitter register definitions into a
single definition. We already know we have some workarounds on an
upcoming platform that will need to update the ECOSKPD register for
other engines too, so this helps pave the way for that.
Matt Roper [Tue, 11 Jan 2022 05:15:51 +0000 (21:15 -0800)]
drm/i915: Parameterize PWRCTX_MAXCNT
Rather than having separate definitions for each engine, create a single
parameterized macro that takes the engine base offset. This will also
ensure we get to the proper offset if we ever need to use these
registers on newer platforms (where the media engine offsets have
changed).
Jani Nikula [Mon, 10 Jan 2022 09:57:38 +0000 (11:57 +0200)]
drm/i915: split out vlv sideband registers from i915_reg.h
Add a dedicated file vlv_sideband_reg.h for the VLV/CHV sideband
registers. The sideband registers macros are needed by the same files
that need vlv_sideband.h, so include the definitions from there.
Anisse Astier [Wed, 29 Dec 2021 22:21:59 +0000 (23:21 +0100)]
drm/i915/opregion: add support for mailbox #5 EDID
The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
used for the embedded display. Add support for using it via by adding
the EDID to the list of available modes on the connector, and use it for
eDP when available.
If a panel's EDID is broken, there may be an override EDID set in the
ACPI OpRegion mailbox #5. Use it if available.
Andy Shevchenko [Wed, 22 Dec 2021 15:40:33 +0000 (17:40 +0200)]
drm/i915/dsi: Drop double check ACPI companion device for NULL
acpi_dev_get_resources() does perform the NULL pointer check against
ACPI companion device which is given as function parameter. Thus,
there is no need to duplicate this check in the caller.
Ville Syrjälä [Thu, 16 Dec 2021 11:08:22 +0000 (13:08 +0200)]
drm/i915/fbc: Remember to update FBC state even when not reallocating CFB
We mustn't forget to update our FBC state even if we don't have
to reallocate the CFB. Otherwise we won't refresh our notion
of what eg. the new fence or the new override CFB stride
should be. Using the wrong CFB stride in particular can cause
underruns and could even corrupt other stuff in stolen.
Jani Nikula [Wed, 22 Dec 2021 08:16:54 +0000 (10:16 +0200)]
drm/i915/bios: fix slab-out-of-bounds access
If VBT size is not a multiple of 4, the last 4-byte store will be out of
bounds of the allocated buffer. Spotted with KASAN. Round up the
allocation size.
v2: Use round_up() intead of roundup() as it's a power of 2 (Thomas)
Ville Syrjälä [Tue, 21 Dec 2021 19:37:53 +0000 (21:37 +0200)]
drm: Always include the debugfs dentry in drm_crtc
Remove the counterproductive CONFIG_DEBUG_FS ifdef and just include
the debugfs dentry in drm_crtc always. This way we don't need
annoying ifdefs in the actual code with DEBUGFS=n. Also we don't
have these ifdefs around any of the other debugfs dentries either
so can't see why drm_crtc should be special.
This fixes the i915 DEBUGFS=n build because I assumed the dentry
would always be there.
Clint Taylor [Thu, 16 Dec 2021 06:26:45 +0000 (22:26 -0800)]
drm/i915/dg1: Read OPROM via SPI controller
Read OPROM SPI through MMIO and find VBT entry since we can't use
OpRegion and PCI mapping may not work on some systems due to most BIOSes
not leaving the Option ROM mapped.
Hans de Goede [Sun, 21 Nov 2021 19:10:01 +0000 (20:10 +0100)]
drm/i915: Remove unused intel_gmbus_set_speed() function
The intel_gmbus_set_speed() function is not used anywhere, remove it.
Note drivers/gpu/drm/gma500 has its own copy called
gma_intel_gmbus_set_speed() which is used, the intel_gmbus_set_speed()
version in the i915 code is not used at all
Hans de Goede [Sun, 21 Nov 2021 11:00:32 +0000 (12:00 +0100)]
drm/i915/backlight: Make ext_pwm_disable_backlight() call intel_backlight_set_pwm_level()
At least the Bay Trail LPSS PWM controller used with DSI panels on many
Bay Trail tablets seems to leave the PWM pin in whatever state it was
(high or low) ATM that the PWM gets disabled. Combined with some panels
not having a separate backlight-enable pin this leads to the backlight
sometimes staying on while it should not (when the pin was high during
PWM-disabling).
First calling intel_backlight_set_pwm_level() will ensure that the pin
is always low (or high for inverted brightness panels) since the passed
in duty-cycle is 0% (or 100%) when the PWM gets disabled fixing the
backlight sometimes staying on.
With the exception of ext_pwm_disable_backlight() all other
foo_disable_backlight() functions call intel_backlight_set_pwm_level()
already before disabling the backlight, so this change also aligns
ext_pwm_disable_backlight() with all the other disable() functions.
Ville Syrjälä [Mon, 13 Dec 2021 13:44:49 +0000 (15:44 +0200)]
drm/i915/fbc: Introduce device info fbc_mask
Declare which FBC instances are present via a fbc_mask
in device info. For the moment there is just the one.
TODO: Need to figure out how to expose multiple FBC
instances in debugs. Just different file names, or move
the files under some subdirectory (per-crtc maybe), or
something else? This will need igt changes as well.
v2: Put the mask into device_info.display (Jani)
Put the magic pipe->fbc thing into skl_fbc_id_for_pipe() (Jani)
Ville Syrjälä [Mon, 13 Dec 2021 13:44:48 +0000 (15:44 +0200)]
drm/i915/fbc: Loop through FBC instances in various places
Convert i915->fbc into an array in preparation for
multiple FBC instances, and loop through all instances
in all places where the caller does not know which
instance(s) (if any) are relevant. This is the case
for eg. frontbuffer tracking and FIFO underrun hadling.
v2: More intel_ namespace (Jani)
Leave out debugfs for later
Jani Nikula [Mon, 13 Dec 2021 11:41:05 +0000 (13:41 +0200)]
drm/i915/cdclk: turn around i915_drv.h and intel_cdclk.h dependency
intel_cdclk.h only needs i915_drv.h for struct intel_cdclk_config. Move
the definition to intel_cdclk.h and turn the includes around to avoid
including i915_drv.h from other headers.
The intel cdclk state macros in intel_cdclk.h still reference struct
drm_i915_private, but as macros they don't strictly require the
definition until they are used.
v2: Expand on the commit message wrt cdclk state macros
Mark Brown [Mon, 13 Dec 2021 17:07:53 +0000 (17:07 +0000)]
drm/i915: Fix implicit use of struct pci_dev
intel_device_info.h references struct pci_dev but does not ensure that
the struct has been declared, causing build failures if something in
other headers changes so that the implicit dependency it is relying on
is no longer satisfied:
In file included from drivers/gpu/drm/i915/intel_device_info.h:32,
from drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h:11,
from drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c:11:
drivers/gpu/drm/i915/display/intel_display.h:643:39: error: 'struct pci_dev' declared inside parameter list will not be visible outside of this definition or declaration [-Werror]
643 | bool intel_modeset_probe_defer(struct pci_dev *pdev);
| ^~~~~~~
cc1: all warnings being treated as errors
Ville Syrjälä [Fri, 10 Dec 2021 12:27:26 +0000 (14:27 +0200)]
drm/i915: Move pipe/transcoder/abox masks under intel_device_info.display
Collect the dipslay related mask under the display sub-structure
in intel_device_info.
Note that there is a slight change in behaviour in that we zero
out .display entirely when !HAS_DISPLAY (aka. pipe_mask==0), so
now we also zero out the other masks (although cpu_transocder_mask
should already be zero of pipe_mask is zero). abox_mask is
only used by the display core init when HAS_DISPLAY is true, so
the actual behaviour of the system shouldn't change despite the
zeroing of these masks.
There is a lot more display stuff directly in device info that
could be moved over. Maybe someone else will be inspired to do it...
Hans de Goede [Tue, 5 Oct 2021 20:23:22 +0000 (22:23 +0200)]
drm/i915: Add privacy-screen support (v3)
Add support for eDP panels with a built-in privacy screen using the
new drm_privacy_screen class.
Changes in v3:
- Move drm_privacy_screen_get() call to intel_ddi_init_dp_connector()
Changes in v2:
- Call drm_connector_update_privacy_screen() from
intel_enable_ddi_dp() / intel_ddi_update_pipe_dp() instead of adding a
for_each_new_connector_in_state() loop to intel_atomic_commit_tail()
- Move the probe-deferral check to the intel_modeset_probe_defer() helper
Hans de Goede [Tue, 5 Oct 2021 20:23:21 +0000 (22:23 +0200)]
drm/i915: Add intel_modeset_probe_defer() helper
The upcoming privacy-screen support adds another check for
deferring probe till some other drivers have bound first.
Factor out the current vga_switcheroo_client_probe_defer() check
into an intel_modeset_probe_defer() helper, so that further
probe-deferral checks can be added there.
projects / linux.git / log