aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-10-27drm/i915/audio: Read ELD buffer size from hardwareVille Syrjälä1-7/+45
We currently read the ELD buffer size from hardware on g4x, but on ilk+ we just hardcode it to 84 bytes. Let's unify this and just do the hardware readout on all platforms, in case the size changes in the future or something. TODO: should perhaps do the readout during driver init and stash the results somewhere so that we could check that the connector's ELD actually fits and not even try to enable audio in that case... v2: Document the size is in dwords (Jani) Cc: Chaitanya Kumar Borah <[email protected]> Cc: Kai Vehmanen <[email protected]> Cc: Takashi Iwai <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-27drm/i915/audio: Nuke intel_eld_uptodate()Ville Syrjälä1-33/+0
No idea why we do this ELD comparions on g4x before loading the new ELD. Seems entirely pointless so just get rid of it. Cc: Chaitanya Kumar Borah <[email protected]> Cc: Kai Vehmanen <[email protected]> Cc: Takashi Iwai <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-27drm/i915/audio: Protect singleton register with a lockVille Syrjälä1-0/+7
On the "ilk" platforms AUD_CNTL_ST2 is a singleton. Protect it with the audio mutex in case we ever want to do parallel RMW access to it. Currently that should not happen since we only do audio enable/disable from full modesets, and those are fully serialized. But we probably want to think about toggling audio on/off from fastsets too. The hsw codepaths already have the same locking. g4x should not need it since it can only do audio to a single port at a time, which means it's actually broken in more ways than this atm. Cc: Chaitanya Kumar Borah <[email protected]> Cc: Kai Vehmanen <[email protected]> Cc: Takashi Iwai <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-27drm/i915/audio: Unify register bit namingVille Syrjälä2-7/+7
Rename a few g4x bits to match the ibx+ bits. Cc: Chaitanya Kumar Borah <[email protected]> Cc: Kai Vehmanen <[email protected]> Cc: Takashi Iwai <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-27drm/i915/audio: Use REG_BIT() & co.Ville Syrjälä2-51/+45
Switch the audio registers to REG_BIT() & co. Cc: Chaitanya Kumar Borah <[email protected]> Cc: Kai Vehmanen <[email protected]> Cc: Takashi Iwai <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-27drm/i915/audio: Extract struct ilk_audio_regsVille Syrjälä1-42/+43
The "ilk" audio codec codepaths have some duplicated code to figure out the correct registers to use on each platform. Extrat that into a single place. Cc: Chaitanya Kumar Borah <[email protected]> Cc: Kai Vehmanen <[email protected]> Cc: Takashi Iwai <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-27drm/i915/audio: Remove CL/BLC audio stuffVille Syrjälä2-25/+6
We don't use the audio code on crestline (CL) since it doesn't support native HDMI output, and SDVO has it's own way of doing audio. And Bearlake-C (BLC) doesn't even exist in the real world, so no point it trying to deal with it. Cc: Chaitanya Kumar Borah <[email protected]> Cc: Kai Vehmanen <[email protected]> Cc: Takashi Iwai <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-27drm/i915/audio: Nuke leftover ROUNDING_FACTORVille Syrjälä1-2/+0
Remove some leftovers I missed in commit 2dd43144e824 ("drm/i915: Streamline the artihmetic") Cc: Chaitanya Kumar Borah <[email protected]> Cc: Kai Vehmanen <[email protected]> Cc: Takashi Iwai <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-27drm/i915/audio: s/dev_priv/i915/Ville Syrjälä2-197/+196
Rename the 'dev_priv' variables to 'i915' in the audio code to match modern style conventions. v2: Drop some needless braces in intel_audio_hooks_init() Cc: Chaitanya Kumar Borah <[email protected]> Cc: Kai Vehmanen <[email protected]> Cc: Takashi Iwai <[email protected]> Reviewed-by: Jani Nikula <[email protected]> Reviewed-by: Kai Vehmanen <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-27drm/i915: Fix CFI violations in gt_sysfsNathan Chancellor3-258/+220
When booting with CONFIG_CFI_CLANG, there are numerous violations when accessing the files under /sys/devices/pci0000:00/0000:00:02.0/drm/card0/gt/gt0: $ cd /sys/devices/pci0000:00/0000:00:02.0/drm/card0/gt/gt0 $ grep . * id:0 punit_req_freq_mhz:350 rc6_enable:1 rc6_residency_ms:214934 rps_act_freq_mhz:1300 rps_boost_freq_mhz:1300 rps_cur_freq_mhz:350 rps_max_freq_mhz:1300 rps_min_freq_mhz:350 rps_RP0_freq_mhz:1300 rps_RP1_freq_mhz:350 rps_RPn_freq_mhz:350 throttle_reason_pl1:0 throttle_reason_pl2:0 throttle_reason_pl4:0 throttle_reason_prochot:0 throttle_reason_ratl:0 throttle_reason_status:0 throttle_reason_thermal:0 throttle_reason_vr_tdc:0 throttle_reason_vr_thermalert:0 $ sudo dmesg &| grep "CFI failure at" [ 214.595903] CFI failure at kobj_attr_show+0x19/0x30 (target: id_show+0x0/0x70 [i915]; expected type: 0xc527b809) [ 214.596064] CFI failure at kobj_attr_show+0x19/0x30 (target: punit_req_freq_mhz_show+0x0/0x40 [i915]; expected type: 0xc527b809) [ 214.596407] CFI failure at kobj_attr_show+0x19/0x30 (target: rc6_enable_show+0x0/0x40 [i915]; expected type: 0xc527b809) [ 214.596528] CFI failure at kobj_attr_show+0x19/0x30 (target: rc6_residency_ms_show+0x0/0x270 [i915]; expected type: 0xc527b809) [ 214.596682] CFI failure at kobj_attr_show+0x19/0x30 (target: act_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809) [ 214.596792] CFI failure at kobj_attr_show+0x19/0x30 (target: boost_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809) [ 214.596893] CFI failure at kobj_attr_show+0x19/0x30 (target: cur_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809) [ 214.596996] CFI failure at kobj_attr_show+0x19/0x30 (target: max_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809) [ 214.597099] CFI failure at kobj_attr_show+0x19/0x30 (target: min_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809) [ 214.597198] CFI failure at kobj_attr_show+0x19/0x30 (target: RP0_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809) [ 214.597301] CFI failure at kobj_attr_show+0x19/0x30 (target: RP1_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809) [ 214.597405] CFI failure at kobj_attr_show+0x19/0x30 (target: RPn_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809) [ 214.597538] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809) [ 214.597701] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809) [ 214.597836] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809) [ 214.597952] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809) [ 214.598071] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809) [ 214.598177] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809) [ 214.598307] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809) [ 214.598439] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809) [ 214.598542] CFI failure at kobj_attr_show+0x19/0x30 (target: throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809) With kCFI, indirect calls are validated against their expected type versus actual type and failures occur when the two types do not match. The ultimate issue is that these sysfs functions are expecting to be called via dev_attr_show() but they may also be called via kobj_attr_show(), as certain files are created under two different kobjects that have two different sysfs_ops in intel_gt_sysfs_register(), hence the warnings above. When accessing the gt_ files under /sys/devices/pci0000:00/0000:00:02.0/drm/card0, which are using the same sysfs functions, there are no violations, meaning the functions are being called with the proper type. To make everything work properly, adjust certain functions to match the type of the ->show() and ->store() members in 'struct kobj_attribute'. Add a macro to generate functions for that can be called via both dev_attr_{show,store}() or kobj_attr_{show,store}() so that they can be called through both kobject locations without violating kCFI and adjust the attribute groups to account for this. Link: https://github.com/ClangBuiltLinux/linux/issues/1716 Reviewed-by: Andi Shyti <[email protected]> Reviewed-by: Andrzej Hajda <[email protected]> Reviewed-by: Kees Cook <[email protected]> Signed-off-by: Nathan Chancellor <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-27drm/bridge: it6505: Fix return value check for pm_runtime_get_syncPin-yen Lin1-1/+1
`pm_runtime_get_sync` may return 1 on success. Fix the `if` statement here to make the code less confusing, even though additional calls to `it6505_poweron` doesn't break anything when it's already powered. This was reported by Dan Carpenter <[email protected]> in https://lore.kernel.org/all/Y1fMCs6VnxbDcB41@kili/ Fixes: 10517777d302 ("drm/bridge: it6505: Adapt runtime power management framework") Signed-off-by: Pin-yen Lin <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-27i915/i915_gem_context: Remove debug message in i915_gem_context_create_ioctlKarolina Drobnik1-1/+0
We know that as long as GEM context create ioctl succeeds, a context was created. There is no need to write about it, especially when such a message heavily pollutes dmesg and makes debugging actual errors harder. Since commit baa89ba3f1fe ("drm/i915/gem: initial conversion to new logging macros using coccinelle"), the logging for creating a new user context was moved under the driver debug output (for lack of a means for per-user logs, and a lack of user-focused drm.debug parameter). This only reveals how obnoxious having that spam be part of the driver debug logs, so remove it. [ from Chris Wilson ] Suggested-by: Chris Wilson <[email protected]> Signed-off-by: Karolina Drobnik <[email protected]> Cc: Andi Shyti <[email protected]> Reviewed-by: Andi Shyti <[email protected]> Signed-off-by: Andi Shyti <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-27drm/ttm: rework on ttm_resource to use size_t typeSomalapuram Amaranath37-80/+78
Change ttm_resource structure from num_pages to size_t size in bytes. v1 -> v2: change PFN_UP(dst_mem->size) to ttm->num_pages v1 -> v2: change bo->resource->size to bo->base.size at some places v1 -> v2: remove the local variable v1 -> v2: cleanup cmp_size_smaller_first() v2 -> v3: adding missing PFN_UP in ttm_bo_vm_fault_reserved Signed-off-by: Somalapuram Amaranath <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Christian König <[email protected]> Signed-off-by: Christian König <[email protected]>
2022-10-27drm/i915: stop abusing swiotlb_max_segmentRobert Beckett5-32/+29
swiotlb_max_segment used to return either the maximum size that swiotlb could bounce, or for Xen PV PAGE_SIZE even if swiotlb could bounce buffer larger mappings. This made i915 on Xen PV work as it bypasses the coherency aspect of the DMA API and can't cope with bounce buffering and this avoided bounce buffering for the Xen/PV case. So instead of adding this hack back, check for Xen/PV directly in i915 for the Xen case and otherwise use the proper DMA API helper to query the maximum mapping size. Replace swiotlb_max_segment() calls with dma_max_mapping_size(). In i915_gem_object_get_pages_internal() no longer consider max_segment only if CONFIG_SWIOTLB is enabled. There can be other (iommu related) causes of specific max segment sizes. Fixes: a2daa27c0c61 ("swiotlb: simplify swiotlb_max_segment") Reported-by: Marek Marczykowski-Górecki <[email protected]> Signed-off-by: Robert Beckett <[email protected]> Signed-off-by: Christoph Hellwig <[email protected]> [hch: added the Xen hack, rewrote the changelog] Reviewed-by: Tvrtko Ursulin <[email protected]> Signed-off-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-27Revert "drm/i915/uapi: expose GTT alignment"Matthew Auld2-28/+2
The process for merging uAPI is to have UMD side ready and reviewed and merged before merging. Revert for now until that is ready. This reverts commit d54576a074a29d4901d0a693cd84e1a89057f694. Reported-by: Joonas Lahtinen <[email protected]> Signed-off-by: Matthew Auld <[email protected]> Cc: Lionel Landwerlin <[email protected]> Cc: Michal Mrozek <[email protected]> Cc: Thomas Hellström <[email protected]> Cc: Stuart Summers <[email protected]> Cc: Jordan Justen <[email protected]> Cc: Yang A Shi <[email protected]> Cc: Nirmoy Das <[email protected]> Cc: Niranjana Vishwanathapura <[email protected]> Reviewed-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-27Merge tag 'drm-next-20221025' of git://linuxtv.org/pinchartl/media into drm-nextDave Airlie12-888/+1325
Xilinx ZynqMP DisplayPort bridge support Signed-off-by: Dave Airlie <[email protected]> From: Laurent Pinchart <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915/guc: Remove intel_context:number_committed_requests counterAlan Previn2-25/+0
With the introduction of the delayed disable-sched behavior, we use the GuC's xarray of valid guc-id's as a way to identify if new requests had been added to a context when the said context is being checked for closure. Additionally that prior change also closes the race for when a new incoming request fails to cancel the pending delayed disable-sched worker. With these two complementary checks, we see no more use for intel_context:guc_state:number_committed_requests. Signed-off-by: Alan Previn <[email protected]> Reviewed-by: John Harrison <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915/guc: Delay disabling guc_id scheduling for better hysteresisMatthew Brost7-27/+274
Add a delay, configurable via debugfs (default 34ms), to disable scheduling of a context after the pin count goes to zero. Disable scheduling is a costly operation as it requires synchronizing with the GuC. So the idea is that a delay allows the user to resubmit something before doing this operation. This delay is only done if the context isn't closed and less than a given threshold (default is 3/4) of the guc_ids are in use. Alan Previn: Matt Brost first introduced this patch back in Oct 2021. However no real world workload with measured performance impact was available to prove the intended results. Today, this series is being republished in response to a real world workload that benefited greatly from it along with measured performance improvement. Workload description: 36 containers were created on a DG2 device where each container was performing a combination of 720p 3d game rendering and 30fps video encoding. The workload density was configured in a way that guaranteed each container to ALWAYS be able to render and encode no less than 30fps with a predefined maximum render + encode latency time. That means the totality of all 36 containers and their workloads were not saturating the engines to their max (in order to maintain just enough headrooom to meet the min fps and max latencies of incoming container submissions). Problem statement: It was observed that the CPU core processing the i915 soft IRQ work was experiencing severe load. Using tracelogs and an instrumentation patch to count specific i915 IRQ events, it was confirmed that the majority of the CPU cycles were caused by the gen11_other_irq_handler() -> guc_irq_handler() code path. The vast majority of the cycles was determined to be processing a specific G2H IRQ: i.e. INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_DONE. These IRQs are sent by GuC in response to i915 KMD sending H2G requests: INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_SET. Those H2G requests are sent whenever a context goes idle so that we can unpin the context from GuC. The high CPU utilization % symptom was limiting density scaling. Root Cause Analysis: Because the incoming execution buffers were spread across 36 different containers (each with multiple contexts) but the system in totality was NOT saturated to the max, it was assumed that each context was constantly idling between submissions. This was causing a thrashing of unpinning contexts from GuC at one moment, followed quickly by repinning them due to incoming workload the very next moment. These event-pairs were being triggered across multiple contexts per container, across all containers at the rate of > 30 times per sec per context. Metrics: When running this workload without this patch, we measured an average of ~69K INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_DONE events every 10 seconds or ~10 million times over ~25+ mins. With this patch, the count reduced to ~480 every 10 seconds or about ~28K over ~10 mins. The improvement observed is ~99% for the average counts per 10 seconds. Design awareness: Selftest impact. As temporary WA disable this feature for the selftests. Selftests are very timing sensitive and any change in timing can cause failure. A follow up patch will fixup the selftests to understand this delay. Design awareness: Race between guc_request_alloc and guc_context_close. If a context close is issued while there is a request submission in flight and a delayed schedule disable is pending, guc_context_close and guc_request_alloc will race to cancel the delayed disable. To close the race, make sure that guc_request_alloc waits for guc_context_close to finish running before checking any state. Design awareness: GT Reset event. If a gt reset is triggered, as preparation steps, add an additional step to ensure all contexts that have a pending delay-disable-schedule task be flushed of it. Move them directly into the closed state after cancelling the worker. This is okay because the existing flow flushes all yet-to-arrive G2H's dropping them anyway. Signed-off-by: Matthew Brost <[email protected]> Signed-off-by: Alan Previn <[email protected]> Signed-off-by: Daniele Ceraolo Spurio <[email protected]> Reviewed-by: John Harrison <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915/guc: Fix GuC error capture sizing estimation and reportingAlan Previn2-14/+21
During GuC error capture initialization, we estimate the amount of size we need for the error-capture-region of the shared GuC-log-buffer. This calculation was incorrect so fix that. With the fixed calculation we can reduce the allocation of error-capture region from 4MB to 1MB (see note2 below for reasoning). Additionally, switch from drm_notice to drm_debug for the 3X spare size check since that would be impossible to hit without redesigning gpu_coredump framework to hold multiple captures. NOTE1: Even for 1x the min size estimation case, actually running out of space is a corner case because it can only occur if all engine instances get reset all at once and i915 isn't able extract the capture data fast enough within G2H handler worker. NOTE2: With the corrected calculation, a DG2 part required ~77K and a PVC required ~115K (1X min-est-size that is calculated as one-shot all-engine- reset scenario). Fixes: d7c15d76a554 ("drm/i915/guc: Check sizing of guc_capture output") Cc: Alan Previn <[email protected]> Cc: Matthew Brost <[email protected]> Cc: Lucas De Marchi <[email protected]> Cc: John Harrison <[email protected]> Cc: Umesh Nerlige Ramappa <[email protected]> Cc: Balasubramani Vivekanandan <[email protected]> Cc: Matt Roper <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Joonas Lahtinen <[email protected]> Cc: Chris Wilson <[email protected]> Signed-off-by: Alan Previn <[email protected]> Reviewed-by: John Harrison <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915/slpc: Use platform limits for min/max frequencyVinay Belgaumkar4-9/+53
GuC will set the min/max frequencies to theoretical max on ATS-M. This will break kernel ABI, so limit min/max frequency to RP0(platform max) instead. Also modify the SLPC selftest to update the min frequency when we have a server part so that we can iterate between platform min and max. v2: Check softlimits instead of platform limits (Riana) v3: More review comments (Ashutosh) v4: No need to use saved_min_freq and other comments (Ashutosh) Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/7030 Acked-by: Nirmoy Das <[email protected]> Reviewed-by: Riana Tauro <[email protected]> Signed-off-by: Vinay Belgaumkar <[email protected]> Reviewed-by: Ashutosh Dixit <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915/display: Move squash_ctl register programming to its own functionAnusha Srivatsa1-9/+14
No functional change. Introduce dg2_cdclk_squash_program and move squash_ctl register programming bits to this. v2: s/dg2_cdclk_squash_programming/dg2_cdclk_squash_program (Jani) Cc: Jani Nikula <[email protected]> Cc: Balasubramani Vivekanandan <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Anusha Srivatsa <[email protected]> Reviewed-by: Balasubramani Vivekanandan <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915/display: Move chunks of code out of bxt_set_cdclk()Anusha Srivatsa1-15/+24
No functional change. Moving segments out to simplify bxt_set_cdlck() v2: s/bxt_cdclk_pll/bxt_cdclk_pll_update (Jani) Cc: Jani Nikula <[email protected]> Cc: Balasubramani Vivekanandan <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Anusha Srivatsa <[email protected]> Reviewed-by: Balasubramani Vivekanandan <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915/display: Introduce HAS_CDCLK_SQUASH macroAnusha Srivatsa4-10/+8
Driver had discrepancy in how cdclk squash and crawl support were checked. Like crawl, add squash as a 1 bit feature flag to the display section of DG2. Cc: Balasubramani Vivekanandan <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Anusha Srivatsa <[email protected]> Reviewed-by: Balasubramani Vivekanandan <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915/display: Change terminology for cdclk actionsAnusha Srivatsa1-8/+8
No functional changes. Changing terminology in some print statements. s/has_cdclk_squasher/has_cdclk_squash, s/crawler/crawl and s/squasher/squash. Cc: Balasubramani Vivekanandan <[email protected]> Cc: Ville Syrjälä <[email protected]> Signed-off-by: Anusha Srivatsa <[email protected]> Reviewed-by: Balasubramani Vivekanandan <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915/slpc: Optmize waitboost for SLPCVinay Belgaumkar1-1/+7
Waitboost (when SLPC is enabled) results in a H2G message. This can result in thousands of messages during a stress test and fill up an already full CTB. There is no need to request for boost if min softlimit is equal or greater than it. v2: Add the tracing back, and check requested freq in the worker thread (Tvrtko) v3: Check requested freq in dec_waiters as well v4: Only check min_softlimit against boost_freq. Limit this optimization for server parts for now. v5: min_softlimit can be greater than boost (Ashutosh) Reviewed-by: Ashutosh Dixit <[email protected]> Signed-off-by: Vinay Belgaumkar <[email protected]> Signed-off-by: John Harrison <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915/xelp: Add Wa_1806527549Gustavo Sousa2-0/+7
Workaround to be applied to platforms using XE_LP graphics. BSpec: 52890 Signed-off-by: Gustavo Sousa <[email protected]> Reviewed-by: Lucas De Marchi <[email protected]> Signed-off-by: Matt Roper <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915/tgl+: Sanitize DKL PHY register definitionsImre Deak6-152/+159
Not all Dekel PHY registers have a lane instance, so having to specify this when using them is awkward. It makes more sense to define each PHY register with its full internal PHY offset where bits 15:12 is the lane for lane-instanced PHY registers and just a register bank index for other PHY registers. This way lane-instanced registers can be referred to with the (tc_port, lane) parameters, while other registers just with a tc_port parameter. An additional benefit of this change is to prevent passing a Dekel register to a generic MMIO access function or vice versa. v2: - Fix parameter reuse in the DKL_REG_MMIO definition. v3: - Rebase on latest patchset version. Cc: Jani Nikula <[email protected]> Acked-by: Jani Nikula <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915/tgl+: Move DKL PHY register definitions to intel_dkl_phy_regs.hImre Deak7-179/+198
Move the TypeC DKL PHY register definitions to intel_dkl_phy_regs.h. No functional changes. v2: - Move the definitions to a new intel_dkl_phy_regs.h file. (Jani). v3: - Rebase on latest patchset version. Cc: Jani Nikula <[email protected]> Acked-by: Jani Nikula <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915: Rename intel_tc_phy_regs.h to intel_mg_phy_regs.hImre Deak4-6/+6
An upcoming patch moves the DKL PHY register definitions to intel_dkl_phy_regs.h, so for consistency rename intel_tc_phy_regs.h containing only MG PHY register definitions to intel_mg_phy_regs.h. Suggested-by: Jani Nikula <[email protected]> Cc: Jani Nikula <[email protected]> Acked-by: Jani Nikula <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915/tgl+: Add locking around DKL PHY register accessesImre Deak9-76/+204
Accessing the TypeC DKL PHY registers during modeset-commit, -verification, DP link-retraining and AUX power well toggling is racy due to these code paths being concurrent and the PHY register bank selection register (HIP_INDEX_REG) being shared between PHY instances (aka TC ports) and the bank selection being not atomic wrt. the actual PHY register access. Add the required locking around each PHY register bank selection-> register access sequence. Kudos to Ville for noticing the race conditions. v2: - Add the DKL PHY register accessors to intel_dkl_phy.[ch]. (Jani) - Make the DKL_REG_TC_PORT macro independent of PHY internals. - Move initing the DKL PHY lock to a more logical place. v3: - Fix parameter reuse in the DKL_REG_TC_PORT definition. - Document the usage of phy_lock. v4: - Fix adding TC_PORT_1 offset in the DKL_REG_TC_PORT definition. Cc: Ville Syrjälä <[email protected]> Cc: Jani Nikula <[email protected]> Cc: <[email protected]> # v5.5+ Acked-by: Jani Nikula <[email protected]> Signed-off-by: Imre Deak <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/edid: convert to device specific loggingJani Nikula1-60/+77
Convert to drm_kms_dbg/drm_err where possible, and reference the connector using [CONNECTOR:%d:%s]. Pass connectors around a bit more to enable this. Where this is not possible, unify the rest of the debugs to DRM_DEBUG_KMS. Rewrite tile debug logging to one line while at it. v2: - Use [CONNECTOR:%d:%s] throughout (Ville) - Tile debug logging revamp - Pass connector around a bit more Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/e48346bfe09a632d5a5faa55e3c161b196cf21e8.1666614699.git.jani.nikula@intel.com
2022-10-26drm/edid: add [CONNECTOR:%d:%s] to debug loggingJani Nikula1-13/+25
Reference the connector using [CONNECTOR:%d:%s] in existing device based debug logging. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Simon Ser <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/5884410682bcbc032de4d3af8562c0b271edaa7f.1666614699.git.jani.nikula@intel.com
2022-10-26drm/edid/firmware: convert to drm device specific loggingJani Nikula1-4/+8
Conform to device specific logging. v2: Include [CONNECTOR:%d:%s] (Ville) Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/14f3a1e55729c9157aae93fc45320d05cc4cc7bc.1666614699.git.jani.nikula@intel.com
2022-10-26drm/edid: move edid load declarations to internal headerJani Nikula3-9/+14
The EDID loader is internal to drm, not for drivers. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/d58a59fede286caa8766e0813f4be492a7200287.1666614699.git.jani.nikula@intel.com
2022-10-26drm/edid: use struct drm_edid for override/firmware EDIDJani Nikula3-86/+36
There's a lot going on here, but the main thing is switching the firmware EDID loader to use struct drm_edid. Unfortunately, it's difficult to reasonably split to smaller pieces. Convert the EDID loader to struct drm_edid. There's a functional change in validation; it no longer tries to fix errors or filter invalid blocks. It's stricter in this sense. Hopefully this will not be an issue. As a by-product, this change also allows HF-EEODB extended EDIDs to be passed via override/firmware EDID. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/e64267c28eca483e83c802bc06ddd149bdcdfc66.1666614699.git.jani.nikula@intel.com
2022-10-26drm/edid/firmware: rename drm_load_edid_firmware() to drm_edid_load_firmware()Jani Nikula3-8/+8
Follow the usual naming convention by file name. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/d6714ae737d789764bd2bdb6e7c9a5f56c99eef3.1666614699.git.jani.nikula@intel.com
2022-10-26drm/edid/firmware: drop redundant connector_name variable/parameterJani Nikula1-9/+7
Stop passing around something that's readily available in connector->name. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/befa53a33f2ea83094027a0e88d155779ad096e1.1666614699.git.jani.nikula@intel.com
2022-10-26drm/edid: detach debugfs EDID override from EDID property updateJani Nikula3-41/+49
Having the EDID override debugfs directly update the EDID property is problematic. The update is partial only. The driver has no way of knowing it's been updated. Mode list is not updated. It's an inconsistent state. Detach debugfs EDID override from the property update completely. Only set and reset a separate override EDID copy from debugfs, and have it take effect only at detect (via EDID read). The copy is at connector->edid_override, protected by connector->edid_override_mutex. This also brings override EDID closer to firmware EDID in behaviour. Add validation of the override EDID which we completely lacked. Note that IGT already forces a detect whenever tests update the override EDID. v2: Add locking (Ville) Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/4c875f8e06c4499f498fcf876e1233cbb155ec8a.1666614699.git.jani.nikula@intel.com
2022-10-26drm/edid: add function for checking drm_edid validityJani Nikula2-0/+31
We've lacked a function for immutable validity check on drm_edid. Add one. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/f96188f64e9f7f3deff348d08296609353b12316.1666614699.git.jani.nikula@intel.com
2022-10-26drm/edid: split drm_edid block count helperJani Nikula1-4/+11
Split the drm_edid block count helper to a base version that reports the block count indicated by EDID contents, and another on top that limits the block count based on size allocated for the EDID. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/a7d63878c7fb3dd6f3b987f5257897113797b94f.1666614699.git.jani.nikula@intel.com
2022-10-26drm/edid: rename drm_add_override_edid_modes() to ↵Jani Nikula3-5/+5
drm_edid_override_connector_update() Follow the naming of both EDID override functions as well as drm_edid_connector_update(). This also matches better what the function does; a combination of EDID property update and add modes. Indeed it should later be converted to call drm_edid_connector_update(). Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ba12957e0488654e8db010a3ff1534079caec972.1666614699.git.jani.nikula@intel.com
2022-10-26drm/edid: abstract debugfs override EDID show betterJani Nikula3-8/+15
Add a function to dump the override EDID in debugfs. This hides the override EDID management better in drm_edid.c. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/74defa7b595f51e6c1f2eacd9c799d567d29f053.1666614699.git.jani.nikula@intel.com
2022-10-26drm/edid: debug log EDID override set/resetJani Nikula1-0/+6
It's useful debugging information to know if and when an override EDID was set or reset. Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/ae352f542b4d69398c0965e33fb2e6e34156cbfb.1666614699.git.jani.nikula@intel.com
2022-10-26drm/amd/display: stop using connector->override_edidJani Nikula1-3/+0
The connector->override_edid flag is strictly for EDID override debugfs management, and drivers have no business using it. Cc: Alex Deucher <[email protected]> Cc: Christian König <[email protected]> Cc: Xinhui Pan <[email protected]> Cc: [email protected] Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Harry Wentland <[email protected]> Acked-by: Alex Deucher <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/c901869ff8a4e3aebc4abec99c7dd7b4c224f6e6.1666614699.git.jani.nikula@intel.com
2022-10-26drm/i915/hdmi: stop using connector->override_edidJani Nikula1-4/+1
The connector->override_edid flag is strictly for EDID override debugfs management, and drivers have no business using it. The check for override_edid was added in commit 301906290553 ("drm/i915: Ignore TMDS clock limit for DP++ when EDID override is set") to facilitate mode list cross-checking against modes in override EDID when the connector in question isn't even connected. The dual mode detect fallback would do VBT based limiting in this case. Instead of override EDID, check for connector forcing in the fallback. v2: Simply use !connector->force (Ville) Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/c8b45867cf37134ab40be23e22825ca45adc6041.1666614699.git.jani.nikula@intel.com
2022-10-26drm/i915/hdmi: do dual mode detect only if connectedJani Nikula1-10/+7
For normal connector detect, there's really no point in trying dual mode detect if the connector is disconnected. We can simplify the detect sequence by skipping it. Since intel_hdmi_dp_dual_mode_detect() is only called when EDID is present, we can drop the has_edid parameter. The functional effect is speeding up disconnected connector detection ever so slightly, and, combined with firmware EDID, also stop logging about assuming dual mode adaptor. It's a bit subtle, but this will also skip dual mode detect if the connector is force connected and a) there's no EDID of any kind, normal or override/firmware or b) there's EDID but it does not indicate digital. These are corner cases no matter what, and arguably forcing should not be limited by dual mode detect. Cc: Ville Syrjälä <[email protected]> Signed-off-by: Jani Nikula <[email protected]> Reviewed-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/f8f2a4a147e1c87ba93269a607f71fc29c4b59f6.1666614699.git.jani.nikula@intel.com
2022-10-26drm/nouveau: Remove unused variableZack Rusin1-1/+0
Trivial removal of an unused variable. Not sure how it snuck by me and build bots in the 7c99616e3fe7. Fixes: 7c99616e3fe7 ("drm: Remove drm_mode_config::fb_base") Reported-by: Stephen Rothwell <[email protected]> Cc: Laurent Pinchart <[email protected]> Cc: Thomas Zimmermann <[email protected]> Cc: Christian König <[email protected]> Cc: Ben Skeggs <[email protected]> Cc: Karol Herbst <[email protected]> Cc: Lyude Paul <[email protected]> Reviewed-by: Lyude Paul <[email protected]> Signed-off-by: Zack Rusin <[email protected]> Signed-off-by: Lyude Paul <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dave Airlie <[email protected]>
2022-10-26drm/i915: Stop loading linear degamma LUT on glk needlesslyVille Syrjälä1-23/+3
Make glk_load_luts() a bit lighter for the common case where neither the degamma LUT nor pipe CSC are enabled by not loading the linear degamma LUT. Making .load_luts() as lightweight as possible is a good idea since it may need to execute from a vblank worker under tight deadlines. My earlier reasoning for always loading the linear degamma LUT was to avoid an extra LUT load when just enabling/disabling the pipe CSC, but that is nonsense since we load the LUTs on every flagged color management change/modeset anyway (either of which is needed for a pipe CSC toggle). We can also get rid of the glk_can_preload_luts() special case since the presence of the degamma LUT will now always match csc_enable. v2: Fix typos (Uma) Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915: Get rid of glk_load_degamma_lut_linear()Ville Syrjälä5-42/+82
Since we now have a place (pre_csc_lut) to stuff a purely internal LUT we can replace glk_load_degamma_lut_linear() with such a thing and just rely on the normal glk_load_degamma_lut() to load it as well. drm_mode_config_cleanup() will clean this up for us. v2: Pass on the error pointer Drop a hint about this into the state dump Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-10-26drm/i915: Assert {pre,post}_csc_lut were assigned sensiblyVille Syrjälä3-0/+23
Since we now have the extra step from hw.(de)gamma_lut into {pre,post}_csc_lut let's make sure we didn't forget to assign them appropriately. Ie. basically making sure intel_color_check() was called when necessary (and that it did its job suitable well). Reviewed-by: Uma Shankar <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.