- 25 Jan, 2023 9 commits
-
-
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:
Kai Vehmanen <kai.vehmanen@linux.intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230124144628.4649-7-ville.syrjala@linux.intel.com
-
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:Jani Nikula <jani.nikula@intel.com>
-
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
-
https://gitlab.freedesktop.org/agd5f/linuxDave Airlie authored
amd-drm-next-6.3-2023-01-20: amdgpu: - Secure display fixes - Fix scaling - Misc code cleanups - Display BW alloc logic updates - DCN 3.2 fixes - Fix power reporting on certain firmwares for CZN/RN - SR-IOV fixes - Link training cleanup and code rework - HDCP fixes - Reserved VMID fix - Documentation updates - Colorspace fixes - RAS updates - GC11.0 fixes - VCN instance harvesting fixes - DCN 3.1.4/5 workarounds for S/G displays - Add PCIe info to the INFO IOCTL amdkfd: - XNACK fix UAPI: - Add PCIe gen/lanes info to the amdgpu INFO IOCTL Nesa ultimately plans to use this to make decisions about buffer placement optimizations Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/20790Signed-off-by:
-
- 24 Jan, 2023 7 commits
-
-
Gustavo Sousa authored
The new DMC release for ADLP (v2.18) in linux-firmware adopted the new convention of using unversioned filenames, so update the driver code for that new release. Keep the latest versioned path as fallback so we do not cause regressions. Signed-off-by:
Gustavo Sousa <gustavo.sousa@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Gustavo Sousa authored
New DMC releases in linux-firmware will stop using version number in blob filenames. This new convention provides the following benefits: 1. It simplifies code maintenance, as new DMC releases for a platform using the new convention will always use the same filename for the blob. 2. It allows DMC to be loaded even if the target system does not have the most recent firmware installed. Prepare the driver by: - Using the new convention for DMC_PATH() and renaming the currently used one to make it clear it is for the legacy scheme. - Implementing a fallback mechanism for future transitions from versioned to unversioned paths so that we do not cause a regression for systems not having the most up-to-date linux-firmware files. v2: - Keep using request_firmware() instead of firmware_request_nowarn(). (Jani) v3: - Keep current DMC paths instead of directly using unversioned ones, so that we do not disturb initrd generation. (Lucas, Rodrigo) Signed-off-by: -
git://anongit.freedesktop.org/drm/drm-miscDaniel Vetter authored
drm-misc-next for $kernel-version: UAPI Changes: Cross-subsystem Changes: Core Changes: * Cleanup unneeded include statements wrt <linux/fb.h>, <drm/drm_fb_helper.h> and <drm/drm_crtc_helper.h> * Remove unused helper DRM_DEBUG_KMS_RATELIMITED() * fbdev: Remove obsolete aperture field from struct fb_device, plus driver cleanups; Remove unused flag FBINFO_MISC_FIRMWARE * MIPI-DSI: Fix brightness, plus rsp. driver updates * scheduler: Deprecate drm_sched_resubmit_jobs() * ttm: Fix MIPS build; Remove ttm_bo_wait(); Documentation fixes Driver Changes: * Remove obsolete drivers for userspace modesetting i810, mga, r128, savage, sis, tdfx, via * bridge: Support CDNS DSI J721E, plus DT bindings; lt9611: Various fixes and improvements; sil902x: Various fixes; Fixes * nouveau: Removed support for legacy ioctls; Replace zero-size array; Cleanups * panel: Fixes * radeon: Use new DRM logging helpers Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/Y8kDk5YX7Yz3eRhM@linux-uq9g
-
Daniel Vetter authored
Merge tag 'drm-intel-gt-next-2023-01-18' of git://anongit.freedesktop.org/drm/drm-intel into drm-next Driver Changes: Fixes/improvements/new stuff: - Fix workarounds on Gen2-3 (Tvrtko Ursulin) - Fix HuC delayed load memory leaks (Daniele Ceraolo Spurio) - Fix a BUG caused by impendance mismatch in dma_fence_wait_timeout and GuC (Janusz Krzysztofik) - Add DG2 workarounds Wa_18018764978 and Wa_18019271663 (Matt Atwood) - Apply recommended L3 hashing mask tuning parameters (Gen12+) (Matt Roper) - Improve suspend / resume times with VT-d scanout workaround active (Andi Shyti, Chris Wilson) - Silence misleading "mailbox access failed" warning in snb_pcode_read (Ashutosh Dixit) - Fix null pointer dereference on HSW perf/OA (Umesh Nerlige Ramappa) - Avoid trampling the ring during buffer migration (and selftests) (Chris Wilson, Matthew Auld) - Fix DG2 visual corruption on small BAR systems by not forgetting to copy CCS aux state (Matthew Auld) - More fixing of DG2 visual corruption by not forgetting to copy CCS aux state of backup objects (Matthew Auld) - Fix TLB invalidation for Gen12.50 video and compute engines (Andrzej Hajda) - Limit Wa_22012654132 to just specific steppings (Matt Roper) - Fix userspace crashes due eviction not working under lock contention after the object locking conversion (Matthew Auld) - Avoid double free is user deploys a corrupt GuC firmware (John Harrison) - Fix 32-bit builds by using "%zu" to format size_t (Nirmoy Das) - Fix a possible BUG in TTM async unbind due not reserving enough fence slots (Nirmoy Das) - Fix potential use after free by not exposing the GEM context id to userspace too early (Rob Clark) - Show clamped PL1 limit to the user (hwmon) (Ashutosh Dixit) - Workaround unreliable reset on Jasperlake (Chris Wilson) - Cover rest of SVG unit MCR registers (Gustavo Sousa) - Avoid PXP log spam on platforms which do not support the feature (Alan Previn) - Re-disable RC6p on Sandy Bridge to avoid GPU hangs and visual glitches (Sasa Dragic) Future platform enablement: - Manage uncore->lock while waiting on MCR register (Matt Roper) - Enable Idle Messaging for GSC CS (Vinay Belgaumkar) - Only initialize GSC in tile 0 (José Roberto de Souza) - Media GT and Render GT share common GGTT (Aravind Iddamsetty) - Add dedicated MCR lock (Matt Roper) - Implement recommended caching policy (PVC) (Wayne Boyer) - Add hardware-level lock for steering (Matt Roper) - Check full IP version when applying hw steering semaphore (Matt Roper) - Enable GuC GGTT invalidation from the start (Daniele Ceraolo Spurio) - MTL GSC firmware support (Daniele Ceraolo Spurio, Jonathan Cavitt) - MTL OA support (Umesh Nerlige Ramappa) - MTL initial gt workarounds (Matt Roper) Driver refactors: - Hold forcewake and MCR lock over PPAT setup (Matt Roper) - Acquire fw before loop in intel_uncore_read64_2x32 (Umesh Nerlige Ramappa) - GuC filename cleanups and use submission API version number (John Harrison) - Promote pxp subsystem to top-level of i915 (Alan Previn) - Finish proofing the code agains object size overflows (Chris Wilson, Gwan-gyeong Mun) - Start adding module oriented dmesg output (John Harrison) Miscellaneous: - Correct kerneldoc for intel_gt_mcr_wait_for_reg() (Matt Roper) - Bump up sample period for busy stats selftest (Umesh Nerlige Ramappa) - Make GuC default_lists const data (Jani Nikula) - Fix table order verification to check all FW types (John Harrison) - Remove some limited use register access wrappers (Jani Nikula) - Remove struct_member macro (Andrzej Hajda) - Remove hardcoded value with a macro (Nirmoy Das) - Use helper func to find out map type (Nirmoy Das) - Fix a static analysis warning (John Harrison) - Consolidate VMA active tracking helpers (Andrzej Hajda) - Do not cover all future platforms in TLB invalidation (Tvrtko Ursulin) - Replace zero-length arrays with flexible-array members (Gustavo A. R. Silva) - Unwind hugepages to drop wakeref on error (Chris Wilson) - Remove a couple of superfluous i915_drm.h includes (Jani Nikula) Merges: - Merge drm/drm-next into drm-intel-gt-next (Rodrigo Vivi) danvet: Fix up merge conflict in intel_uc_fw.c, we ended up with 2 copies of try_firmware_load() somehow. Signed-off-by:
-
Luca Coelho authored
The bspec has been updated and now display versions 12 and 13 support source width up to 5120 pixels, source height up to 8192 lines, destination width up to 8192 and destination height up to 8192. Update the code accordingly. BSpec: 50441 Reviewed-by:
Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by:
Luca Coelho <luciano.coelho@intel.com> Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230113113905.130405-1-luciano.coelho@intel.com
-
Javier Martinez Canillas authored
The sparse tool complains with the following warning: $ make M=drivers/gpu/drm/solomon/ C=2 CC [M] drivers/gpu/drm/solomon/ssd130x.o CHECK drivers/gpu/drm/solomon/ssd130x.c drivers/gpu/drm/solomon/ssd130x.c:363:21: warning: dubious: x & !y This seems to be a false positive in my opinion but still we can silence the tool while making the code easier to read. Let's also add a comment, to explain why the "com_seq" logical not is used rather than its value. Reported-by:
Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
-
Javier Martinez Canillas authored
This optional callback was added in the commit 1f45f9db ("fb_defio: add first_io callback") but it was never used by a driver. Let's remove it since it's unlikely that will be used after a decade that was added. Signed-off-by:
-
- 23 Jan, 2023 13 commits
-
-
Thierry Reding authored
Add XB24 and AB24 to the list of supported formats. The format helpers support conversion to these formats and they are documented in the simple-framebuffer device tree bindings. Reviewed-by:
Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230120173103.4002342-8-thierry.reding@gmail.com
-
Thierry Reding authored
Add a conversion helper for the AB24 and XB24 formats to use in drm_fb_blit(). Reviewed-by:
-
Thierry Reding authored
Simple framebuffers can be set up in system memory, which cannot be requested and/or I/O remapped using the I/O resource helpers. Add a separate code path that obtains system memory framebuffers from the reserved memory region referenced in the memory-region property. Reviewed-by:
-
Thierry Reding authored
The majority of the driver already uses struct iosys_map to encapsulate accesses to I/O remapped vs. system memory. Accesses via the screen base pointer still use __iomem annotations, which can lead to inconsistencies and conflicts with subsequent patches. Convert the screen base to a struct iosys_map as well for consistency and to avoid these issues. Reviewed-by:
-
Thierry Reding authored
Document the "framebuffer" compatible string for reserved memory nodes to annotate reserved memory regions used for framebuffer carveouts. Reviewed-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Thierry Reding authored
This is a variant of the 32-bit RGB format where the red and blue components are swapped. Reviewed-by:
-
Thierry Reding authored
In order to support framebuffers residing in system memory, allow the memory-region property to override the framebuffer memory specification in the "reg" property. Reviewed-by:
-
Jani Nikula authored
Realize that drm_edid_connector_update() and _drm_connector_update_edid_property() are now the same thing. Drop the latter. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
The original goal with drm_edid_connector_update() was to have a single call for updating the connector and adding probed modes, in this order, but that turned out to be problematic. Drivers that need to update the connector in the .detect() callback would end up updating the probed modes as well. Turns out the callback may be called so many times that the probed mode list fills up without bounds, and this is amplified by add_alternate_cea_modes() duplicating the CEA modes on every call, actually running out of memory on some machines. Kudos to Imre Deak <imre.deak@intel.com> for explaining this to me. Go back to having separate drm_edid_connector_update() and drm_edid_connector_add_modes() calls. The former may be called from .detect(), .force(), or .get_modes(), but the latter only from .get_modes(). Unlike drm_add_edid_modes(), have drm_edid_connector_add_modes() update the probed modes from the EDID property instead of the passed in EDID. This is mainly to enforce two things: 1) drm_edid_connector_update() must be called before drm_edid_connector_add_modes(). Display info and quirks are needed for parsing the modes, and we don't want to call update_display_info() again to ensure the info is available, like drm_add_edid_modes() does. 2) The same EDID is used for both updating the connector and adding the probed modes. Fortunately, the change is easy, because no driver has actually adopted drm_edid_connector_update(). Not even i915, and that's mainly because of the problem described above. Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
By moving update_display_info() out of _drm_edid_connector_update() we make the function purely about adding modes. Rename accordingly. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Jani Nikula authored
Separate the parsing of display info and modes from the HDMI VSDB. This is prerequisite work for overall better separation of the two parsing steps. The info parsing is about figuring out whether the sink supports HDMI infoframes. Since they were added in HDMI 1.4, assume the sink supports HDMI infoframes if it has the HDMI_Video_present bit set (introduced in HDMI 1.4). For details, see commit f1781e9b ("drm/edid: Allow HDMI infoframe without VIC or S3D"). The logic is not exactly the same, but since it was somewhat heuristic to begin with, assume this is close enough. v2: - Simplify to only check HDMI_Video_present bit (Ville) - Drop cea_db_raw_size() helper (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Liu Ying authored
Same to i.MX8mp LDB, i.MX93 LDB is controlled by mediamix blk-ctrl through LDB_CTRL and LVDS_CTRL registers. i.MX93 LDB supports only one LVDS channel(channel 0) and it's LVDS_CTRL register bit1 is used as LVDS_EN instead of CH1_EN. Add i.MX93 LDB support in the existing i.MX8mp LDB bridge driver by adding i.MX93 LDB compatible string and device data(to reflect different register offsets and LVDS_CTRL register bit1 definition). Reviewed-by:
Marek Vasut <marex@denx.de> Signed-off-by:
Liu Ying <victor.liu@nxp.com> Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230123021449.969243-3-victor.liu@nxp.com
-
Liu Ying authored
Same to i.MX8mp LDB, i.MX93 LDB is controlled by mediamix blk-ctrl through 'ldb' register and 'lvds' register. Also, the 'ldb' clock is required. i.MX93 LDB supports only one LVDS channel(channel 0, a.k.a, LVDS Channel-A in the device tree binding documentation), while i.MX8mp LDB supports at most two. Add i.MX93 LDB device tree binding in the existing i.MX8mp LDB device tree binding documentation. Acked-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by:
-
- 22 Jan, 2023 2 commits
-
-
Christophe Branchereau authored
Add driver for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3 24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit interface. Signed-off-by:
Christophe Branchereau <cbranchereau@gmail.com> Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230121162419.284523-3-cbranchereau@gmail.com
-
Paul Cercueil authored
Add binding for the AUO A030JTN01 panel, which is a 320x480 3.0" 4:3 24-bit TFT LCD panel with non-square pixels and a delta-RGB 8-bit interface. Signed-off-by:
-
- 20 Jan, 2023 9 commits
-
-
Imre Deak authored
Make sure that PIPEDMCs are enabled whenever the corresponding pipe is enabled. This is required at least by the latest ADLP v2.18 firmware, which adds a new handler enabled by default and running whenever the pipe is enabled at the vertical referesh rate. Bspec: 50344, 67620 Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
No good reason for these indirection cases. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230120110658.1083757-1-rodrigo.vivi@intel.com
-
Jagan Teki authored
HSA/HBP/HFP/HSE mode bits in Processor Reference Manuals specify a naming conversion as 'disable mode bit' due to its bit definition, 0 = Enable and 1 = Disable. For HSE bit, the i.MX 8M Mini/Nano/Plus Applications Processor Reference Manual named this bit as 'HseDisableMode' but the bit definition is quite opposite like 0 = Disables transfer 1 = Enables transfer which clearly states that HSE is not a disable bit. HSE is named as per the manual even though it is not a disable bit however the driver logic for handling HSE is based on the MIPI_DSI_MODE_VIDEO_HSE flag itself. Cc: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by:
Jagan Teki <jagan@amarulasolutions.com> Reviewed-by:
Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by:
-
Jagan Teki authored
HFP/HBP/HSA/EOT_PACKET modes in Exynos DSI host specifies 0 = Enable and 1 = Disable. The logic for checking these mode flags was correct before the MIPI_DSI*_NO_* mode flag conversion. This patch is trying to fix this MIPI_DSI*_NO_* mode flags handling Exynos DSI host and update the mode_flags in relevant panel drivers. Fixes: 0f3b68b6 ("drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling features") Reviewed-by:
Nicolas Boichat <drinkcat@chromium.org> Reported-by:
Sébastien Szymanski <sebastien.szymanski@armadeus.com> Signed-off-by:
-
John Stultz authored
I no longer have access to the HiKey boards, so while I'm happy to review code, I wanted to add Sumit and Yongqin to the reviewers list so they would get CC'ed on future changes and would be able to have a chance to validate and provide Tested-by: tags Cc: Xinliang Liu <xinliang.liu@linaro.org> Cc: Tian Tao <tiantao6@hisilicon.com> Cc: Yongqin Liu <yongqin.liu@linaro.org> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: kernel-team@android.com Cc: dri-devel@lists.freedesktop.org Signed-off-by:
John Stultz <jstultz@google.com> Signed-off-by:
-
Jani Nikula authored
Declutter i915_drv.h. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Acked-by:
Nirmoy Das <nirmoy.das@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230118131538.3558599-7-jani.nikula@intel.com
-
Jani Nikula authored
Declutter i915_drv.h. Signed-off-by:
-
Jani Nikula authored
Declutter i915_drv.h. Signed-off-by:
-
Jani Nikula authored
There's not that much organization with where the various HAS_FEATURE() macros are placed, but at least try to group them closer together. Signed-off-by:
-
