- 27 Jan, 2023 10 commits
-
-
Alexander Usyskin authored
Add device link with i915 as consumer and mei_pxp as supplier to ensure proper ordering of power flows. V2: condition on absence of heci_pxp to filter out DG Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Alexander Usyskin authored
Asynchronous runtime resume is not possible while the system is suspending. The power management subsystem resumes the device only in the suspend phase, not in the prepare phase. Force resume device in prepare to allow drivers on mei bus to communicate in their prepare callbacks. Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Lucas De Marchi authored
PALETTE() can use _PICK_EVEN_2RANGES instead of _PICK, which reduces the size and is safer. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Anusha Srivatsa<anusha.srivatsa@intel.com> Acked-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230120193457.3295977-9-lucas.demarchi@intel.com
-
Lucas De Marchi authored
MBUS_ABOX_CTL() can use _PICK_EVEN_2RANGES instead of _PICK, which reduces the size and is safer. Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Acked-by:
-
Lucas De Marchi authored
_FIA() can use _PICK_EVEN_2RANGES instead of _PICK, which reduces the size and is safer. Signed-off-by:
-
Lucas De Marchi authored
Like done for when __var_args__ were used, but size-wise it's also benefitial to avoid _PICK() used for 3 ports/pipes: $ size build64/drivers/gpu/drm/i915/i915.o{.old,.new} text data bss dec hex filename 4026288 185703 6984 4218975 40605f build64/drivers/gpu/drm/i915/i915.o.old 4025496 185703 6984 4218183 405d47 build64/drivers/gpu/drm/i915/i915.o.new Signed-off-by: -
Lucas De Marchi authored
As done previously for pll, also convert users of _PHY3() to _PICK_EVEN_2RANGES(). Size comparison of i915.o: $ size build64/drivers/gpu/drm/i915/i915.o{.old,.new} text data bss dec hex filename 4026997 185703 6984 4219684 406324 build64/drivers/gpu/drm/i915/i915.o.old 4026288 185703 6984 4218975 40605f build64/drivers/gpu/drm/i915/i915.o.new Signed-off-by: -
Lucas De Marchi authored
Avoid the array lookup, converting the PLL macros after ICL to _PICK_EVEN_RANGES. This provides the following reduction in code size: $ size build64/drivers/gpu/drm/i915/i915.o{.old,.new} text data bss dec hex filename 4027456 185703 6984 4220143 4064ef build64/drivers/gpu/drm/i915/i915.o.old 4026997 185703 6984 4219684 406324 build64/drivers/gpu/drm/i915/i915.o.new At the same time it's safer, avoiding out-of-bounds array access. This allows to remove _MMIO_PLL3() that is now unused. Signed-off-by: -
Lucas De Marchi authored
Abide by the rules in the top of the header: 2 spaces for bitfield, prefix offsets with underscore and prefer the use of REG_BIT(). Signed-off-by:
-
Lucas De Marchi authored
It's a constant pattern in the driver to need to use 2 ranges of MMIOs based on port, phy, pll, etc. When that happens, instead of using _PICK_EVEN(), _PICK() needs to be used. Using _PICK() is discouraged due to some reasons like: 1) It increases the code size since the array is declared in each call site 2) Developers need to be careful not to incur an out-of-bounds array access 3) Developers need to be careful that the indexes match the table. For that it may be that the table needs to contain holes, making (1) even worse. Add a variant of _PICK_EVEN() that works with 2 ranges and selects which one to use depending on the index value. v2: Fix the address expansion in the example (Anusha) v3: Also rename macro to _PICK_EVEN_2RANGES() in the documentation and reword it to clarify what ranges are chosen based on the index (Jani) Signed-off-by:
-
- 26 Jan, 2023 6 commits
-
-
Jouni Högander authored
Wa_14013475917 has to be applied for all MTL steppings. Bspec: 66624 Cc: Mika Kahola <mika.kahola@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
Jouni Högander <jouni.hogander@intel.com> Reviewed-by:
-
Jouni Högander authored
Implement Wa_14014971492 and apply it for affected platforms. Bspec: 52890, 54369, 55378, 66624 v2: Adjust platforms where applied Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Mika Kahola <mika.kahola@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Jani Nikula authored
It's a bit confusing to have two cached EDIDs in struct intel_connector with slightly different purposes. Make the distinction a bit clearer by moving the EDID cached for eDP and LVDS panels at connector init time to struct intel_panel, and name it fixed_edid. That's what it is, a fixed EDID for the panels. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Simplify validation and use by converting to drm_edid. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Try to use struct drm_edid where possible, even if having to fall back to looking into struct edid down low via drm_edid_raw(). v2: Rebase Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Convert all the connectors that use cached connector edid and detect_edid to drm_edid. Since drm_get_edid() calls drm_connector_update_edid_property() while drm_edid_read*() do not, we need to call drm_edid_connector_update() separately, in part due to the EDID caching behaviour in HDMI and DP. Especially DP depends on the details parsed from EDID. (The big behavioural change conflating EDID reading with parsing and property update was done in commit 5186421c ("drm: Introduce epoch counter to drm_connector")) v6: Rebase on drm_edid_connector_add_modes() v5: Fix potential uninitialized var use (kernel test robot <lkp@intel.com>) v4: Call drm_edid_connector_update() after reading HDMI/DP EDID v3: Don't leak vga switcheroo EDID in LVDS init (Ville) v2: Don't leak opregion fallback EDID (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
- 25 Jan, 2023 24 commits
-
-
Jani Nikula authored
Replace the __builtin_strcmp() if ladder with generics. Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230118151800.3669913-4-jani.nikula@intel.com
-
Jani Nikula authored
Replace the __builtin_strcmp() if ladder with generics. Signed-off-by:
-
Jani Nikula authored
Replace the __builtin_strcmp() if ladder with generics. Signed-off-by:
-
Jani Nikula authored
Replace the __builtin_strcmp() if ladder with generics. Signed-off-by:
-
Jani Nikula authored
Move a handful of key enums to a new file intel_display_limits.h. These are the enum types, and the MAX/NUM enumerations within them, that are used in other headers. Otherwise, there's no common theme between them. Replace intel_display.h include with intel_display_limit.h where relevant, and add the intel_display.h include directly in the .c files where needed. Since intel_display.h is used almost everywhere in display/, include it from intel_display_types.h to avoid massive changes across the board. There are very few files that would need intel_display_types.h but not intel_display.h so this is neglible, and further cleanup between these headers can be left for the future. Overall this change drops the direct and indirect dependencies on intel_display.h from about 300 to about 100 compilation units, because we can drop the include from i915_drv.h. Signed-off-by:
-
Jani Nikula authored
This is the only user for the GMCH bridge device in display. Move it to GMCH code. Signed-off-by:
-
Jani Nikula authored
Prefer the contemporary naming. Signed-off-by:
-
Jani Nikula authored
The GMCH related code is a bit too low level and out of place for the high level i915_driver.c file. Split out to a separate file under soc/. Rename the functions accordingly. Signed-off-by:
-
Jani Nikula authored
Group the GMCH related members together. Signed-off-by:
-
Ville Syrjälä authored
Use explicit PCH type checks to make it more clear which platforms use which codepaths. Also reorder the branches in ibx_audio_regs_init() a bit to be more in chronological order. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
Rename the ilk stuff to ibx, as the audio logic lives in the PCH. The only exception are VLV/CHV but their audio hardware was stolen from ibx so the name still fits. Also most of the register defines also use the IBX namespace. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
Include the ELD has a hex blob in the crtc state dump. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
Have the state checker validate the ELD. For now we'll just dump it out as a hex buffer on a mismatch, maybe someone will get inspired to decode it properly at some point... Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
Read out the ELD from the hw so the state checker can verify it. v2: Check the "ELD valid" bit separately v3: Fix ELD tx rate handling during readout Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1 Reviewed-by:
-
Ville Syrjälä authored
Align the SDVO audio code with the native HDMI/DP audio and use just the "presence detect" bit for the has_audio readout. The "ELD valid" bit will be used for ELD readout soon. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
Use the precomputed crtc_state->eld for audio setup on SDVO just like we do with native HDMI. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
Read out the ELD from the hardware buffer, or from our stashed copy for the audio component, so that we can hook up the state checker to validate it. v2: Deal with the platforms using acomp Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1 Reviewed-by:
-
Ville Syrjälä authored
Currently we just print a debug message if the ELD is bogus. Maybe we should just not enable audio at all in that case? Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
Stash the ELD into the crtc_state and precompute it. This gets rid of the ugly ELD mutation during intel_audio_codec_enable(), and opens the door for the state checker. v2: Make another copy for the acomp hooks (Chaitanya) Split out the bogus ELD handling change (Jani) Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by: Jani Nikula <jani.nikula@intel.com> #v1 Reviewed-by: -
Ville Syrjälä authored
Currently we're spreading the stashed state for use of the audio component hooks all over the place. Start collecting it up into a single spot. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Ville Syrjälä authored
Since we use the audio component to transfer the ELD to the audio driver on hsw+ platforms there is no point in even programming the hardware ELD buffer. Stop doing so. The one slight caveat here is that this is not strictly legal according to the HDA spec. PD=1;ELD=0 is only documented as an intermediate state during modeset. But if there is no hardware that depends on that then I guess we're fine. Or we could perhaps set ELD=1 without actually programming the buffer? Note that the bspec sequence of PD=0;ELD=0 -> PD=1;ELD=0 -> PD=1;ELD=1 is also not strictly correct according to the HDA spec, as the only documented transition from PD=0;ELD=0 is straight to PD=1;ELD=1. Additionally on hsw/bdw the hardware buffer is tied in with the dedicated display HDA controller's power state, so currently we mostly fail at proramming the buffer anyway. When the HDA side is not sufficiently powered up the ELD address bits get stuck and the ELD data register accesses go nowhere. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Takashi Iwai <tiwai@suse.de> References: https://lore.kernel.org/intel-gfx/20221012104936.30911-1-ville.syrjala@linux.intel.com/Reviewed-by:
-
Ville Syrjälä authored
Since we use the audio component to transfer the ELD to the audio driver on ilk+ platforms there is no point in even programming the hardware ELD buffer. Stop doing so. The one slight caveat here is that this is not strictly legal according to the HDA spec. PD=1;ELD=0 is only documented as an intermediate state during modeset. But if there is no hardware that depends on that then I guess we're fine. Or we could perhaps set ELD=1 without actually programming the buffer? Note that the bspec sequence of PD=0;ELD=0 -> PD=1;ELD=0 -> PD=1;ELD=1 is also not strictly correct according to the HDA spec, as the only documented transition from PD=0;ELD=0 is straight to PD=1;ELD=1. But that is not even possible on these platforms as the bits live in different registers. Cc: Chaitanya Kumar Borah <chaitanya.kumar.borah@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Reviewed-by:
-
Jani Nikula authored
Backmerge to get the EDID handling changes. Signed-off-by: -
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for v6.3: UAPI Changes: Cross-subsystem Changes: Core Changes: * EDID: Improved mode parsing and refactoring * fbdev: Cleanups * format-helper: Add conversion from XRGB8888 to XBGR8888 and ABGR8888 Driver Changes: * accel/ivpu: Add driver for Intel VPU accelerator * bridge: Support i.MX93 LDB plus DT bindings * exynos: Fixes * panel: vtdr6130: Fixes; Support AUO A030JTN01 plus DT bindings * simpledrm: Support system-memory framebuffers plus DT bindings * ssd130x: Fix sparse warning Signed-off-by:
Dave Airlie <airlied@redhat.com> # -----BEGIN PGP SIGNATURE----- # # iQEzBAABCAAdFiEEchf7rIzpz2NEoWjlaA3BHVMLeiMFAmPQN9YACgkQaA3BHVML # eiNmmQf/bTV3oaMo55i3tYxhMCWYDtPVk+GGglDAykW7Lid8pvy6mJqJoW6uvgQF # c6CcoY+6yG2WvnVLhXyhPaACiG5weQSdu3S/DdZ2nuJCb50YCwWNNKcu3qYnLVlz # 2NQ/s0HN+Xvvy76GJFNarKlxSNADPWCNJ8wExAdBkWr7q8NiDfsWuMGrQRQORrm3 # zEkSJPKtWNHa+vmsQOO9yebD0LFx97CoU40FrVXZTtF0FugGIXjiknQwekzuFxdY # fGBiFKsI+Y3s51gAppbmRRJ0jGLj3KDF5S+5GM8FNbgJQF67Wxttl/YtY6lJGcsa # l0vpRoCe1ilhNVvoikzAu7UewkPKKA== # =GLLt # -----END PGP SIGNATURE----- # gpg: Signature made Wed 25 Jan 2023 05:56:06 AEST # gpg: using RSA key 7217FBAC8CE9CF6344A168E5680DC11D530B7A23 # gpg: Can't check signature: No public key From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/Y9A5ceDknyQixM3R@linux-uq9g
-
