summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2021-09-14drm/i915/dp: Use max params for panels < eDP 1.4Kai-Heng Feng
Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure"), the screen starts to have wobbly effect. Commit a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for everything") doesn't help either, that means the affected eDP 1.2 panels only work with max params. So use max params for panels < eDP 1.4 as Windows does to solve the issue. v3: - Do the eDP rev check in intel_edp_init_dpcd() v2: - Check eDP 1.4 instead of DPCD 1.1 to apply max params Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3714 Fixes: 2bbd6dba84d4 ("drm/i915: Try to use fast+narrow link on eDP again and fall back to the old max strategy on failure") Fixes: a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for everything") Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210820075301.693099-1-kai.heng.feng@canonical.com (cherry picked from commit d7f213c131adf0bec8b731553eb82990cdac265d) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-09-14drm/i915/dp: return proper DPRX link training resultLee Shawn C
After DPRX link training, intel_dp_link_train_phy() did not return the training result properly. If link training failed, i915 driver would not run into link train fallback function. And no hotplug uevent would be received by user space application. Fixes: b30edfd8d0b4 ("drm/i915: Switch to LTTPR non-transparent mode link training") Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: William Tseng <william.tseng@intel.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210706152541.25021-1-shawn.c.lee@intel.com (cherry picked from commit dab1b47e57e053b2a02c22ead8e7449f79961335) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2021-09-14Merge drm/drm-next into drm-misc-nextMaxime Ripard
Kickstart new drm-misc-next cycle. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2021-09-13drm/i915/guc: Add GuC kernel docMatthew Brost
Add GuC kernel doc for all structures added thus far for GuC submission and update the main GuC submission section with the new interface details. v2: - Drop guc_active.lock DOC v3: - Fixup a few kernel doc comments (Daniele) v4 (Daniele): - Implement doc suggestions from John - Add kerneldoc for all members of the GuC structure and pull the file in i915.rst v5 (Daniele): - Implement new doc suggestions from John Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-24-matthew.brost@intel.com
2021-09-13drm/i915/guc: Drop guc_active move everything into guc_stateMatthew Brost
Now that we have locking hierarchy of sched_engine->lock -> ce->guc_state everything from guc_active can be moved into guc_state and protected the guc_state.lock. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-23-matthew.brost@intel.com
2021-09-13drm/i915/guc: Move fields protected by guc->contexts_lock into sub structureMatthew Brost
To make ownership of locking clear move fields (guc_id, guc_id_ref, guc_id_link) to sub structure guc_id in intel_context. Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-22-matthew.brost@intel.com
2021-09-13drm/i915/guc: Move GuC priority fields in context under guc_activeMatthew Brost
Move GuC management fields in context under guc_active struct as this is where the lock that protects theses fields lives. Also only set guc_prio field once during context init. v2: (Daniele) - set CONTEXT_SET_INIT Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-21-matthew.brost@intel.com
2021-09-13drm/i915/guc: Drop pin count check trick between sched_disable and re-pinMatthew Brost
Drop pin count check trick between a sched_disable and re-pin, now rely on the lock and counter of the number of committed requests to determine if scheduling should be disabled on the context. Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-20-matthew.brost@intel.com
2021-09-13drm/i915/guc: Proper xarray usage for contexts_lookupMatthew Brost
Lock the xarray and take ref to the context if needed. v2: (Checkpatch) - Add new line after declaration (Daniel Vetter) - Correct put / get accounting in xa_for_loops v3: (Checkpatch) - Extra new line Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-19-matthew.brost@intel.com
2021-09-13drm/i915/guc: Rework and simplify lockingMatthew Brost
Rework and simplify the locking with GuC subission. Drop sched_state_no_lock and move all fields under the guc_state.sched_state and protect all these fields with guc_state.lock . This requires changing the locking hierarchy from guc_state.lock -> sched_engine.lock to sched_engine.lock -> guc_state.lock. v2: (Daniele) - Don't check fields outside of lock during sched disable, check less fields within lock as some of the outside are no longer needed Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-18-matthew.brost@intel.com
2021-09-13drm/i915/guc: Move guc_blocked fence to struct guc_stateMatthew Brost
Move guc_blocked fence to struct guc_state as the lock which protects the fence lives there. s/ce->guc_blocked/ce->guc_state.blocked/g v2: (Daniele) - s/blocked_fence/blocked/g Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-17-matthew.brost@intel.com
2021-09-13drm/i915/guc: Release submit fence from an irq_workMatthew Brost
A subsequent patch will flip the locking hierarchy from ce->guc_state.lock -> sched_engine->lock to sched_engine->lock -> ce->guc_state.lock. As such we need to release the submit fence for a request from an IRQ to break a lock inversion - i.e. the fence must be release went holding ce->guc_state.lock and the releasing of the can acquire sched_engine->lock. v2: (Daniele) - Delete request from list before calling irq_work_queue Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-16-matthew.brost@intel.com
2021-09-13drm/i915/guc: Reset LRC descriptor if register returns -ENODEVMatthew Brost
Reset LRC descriptor if a context register returns -ENODEV as this means we are mid-reset. Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-15-matthew.brost@intel.com
2021-09-13drm/i915/guc: Don't touch guc_state.sched_state without a lockMatthew Brost
Before we did some clever tricks to not use the a lock when touching guc_state.sched_state in certain cases. Don't do that, enforce the use of the lock. v2: (kernel test robo ) - Add __maybe_unused to sched_state_is_init() v3: rebase after the unused code path removal has been moved to an earlier patch. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-14-matthew.brost@intel.com
2021-09-13drm/i915/guc: Take context ref when cancelling requestMatthew Brost
A context can get destroyed after cancelling a request, if a context or GT reset occurs, so take a reference to context when cancelling a request. Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-13-matthew.brost@intel.com
2021-09-13drm/i915/selftests: Add initial GuC selftest for scrubbing lost G2HMatthew Brost
While debugging an issue with full GT resets I went down a rabbit hole thinking the scrubbing of lost G2H wasn't working correctly. This proved to be incorrect as this was working just fine but this chase inspired me to write a selftest to prove that this works. This simple selftest injects errors dropping various G2H and then issues a full GT reset proving that the scrubbing of these G2H doesn't blow up. v2: (Daniel Vetter) - Use ifdef instead of macros for selftests v3: (Checkpatch) - A space after 'switch' statement v4: (Daniele) - A comment saying GT won't idle if G2H are lost Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-12-matthew.brost@intel.com
2021-09-13drm/i915/guc: Copy whole golden context, set engine state size of subsetMatthew Brost
When the GuC does a media reset, it copies a golden context state back into the corrupted context's state. The address of the golden context and the size of the engine state restore are passed in via the GuC ADS. The i915 had a bug where it passed in the whole size of the golden context, not the size of the engine state to restore resulting in a memory corruption. Also copy the entire golden context on init rather than just the engine state that is restored. v2 (Daniele): use defines to avoid duplicated const variables (John). Fixes: 481d458caede ("drm/i915/guc: Add golden context to GuC ADS") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-11-matthew.brost@intel.com
2021-09-13drm/i915/guc: Don't enable scheduling on a banned context, guc_id invalid, ↵Matthew Brost
not registered When unblocking a context, do not enable scheduling if the context is banned, guc_id invalid, or not registered. v2: (Daniele) - Add helper for unblock Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-10-matthew.brost@intel.com
2021-09-13drm/i915/guc: Kick tasklet after queuing a requestMatthew Brost
Kick tasklet after queuing a request so it submitted in a timely manner. Fixes: 3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for new inteface") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-9-matthew.brost@intel.com
2021-09-13Revert "drm/i915/gt: Propagate change in error status to children on unhold"Matthew Brost
Propagating errors to dependent fences is broken and can lead to errors from one client ending up in another. In commit 3761baae908a ("Revert "drm/i915: Propagate errors on awaiting already signaled fences""), we attempted to get rid of fence error propagation but missed the case added in commit 8e9f84cf5cac ("drm/i915/gt: Propagate change in error status to children on unhold"). Revert that one too. This error was found by an up-and-coming selftest which triggers a reset during request cancellation and verifies that subsequent requests complete successfully. v2: (Daniel Vetter) - Use revert v3: (Jason) - Update commit message v4 (Daniele): - fix checkpatch error in commit message. References: '3761baae908a ("Revert "drm/i915: Propagate errors on awaiting already signaled fences"")' Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-8-matthew.brost@intel.com
2021-09-13drm/i915/guc: Workaround reset G2H is received after schedule done G2HMatthew Brost
If the context is reset as a result of the request cancellation the context reset G2H is received after schedule disable done G2H which is the wrong order. The schedule disable done G2H release the waiting request cancellation code which resubmits the context. This races with the context reset G2H which also wants to resubmit the context but in this case it really should be a NOP as request cancellation code owns the resubmit. Use some clever tricks of checking the context state to seal this race until the GuC firmware is fixed. v2: (Checkpatch) - Fix typos v3: (Daniele) - State that is a bug in the GuC firmware Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-7-matthew.brost@intel.com
2021-09-13drm/i915/guc: Process all G2H message at once in work queueMatthew Brost
Rather than processing 1 G2H at a time and re-queuing the work queue if more messages exist, process all the G2H in a single pass of the work queue. Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-6-matthew.brost@intel.com
2021-09-13drm/i915/guc: Don't drop ce->guc_active.lock when unwinding contextMatthew Brost
Don't drop ce->guc_active.lock when unwinding a context after reset. At one point we had to drop this because of a lock inversion but that is no longer the case. It is much safer to hold the lock so let's do that. Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface") Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-5-matthew.brost@intel.com
2021-09-13drm/i915/guc: Unwind context requests in reverse orderMatthew Brost
When unwinding requests on a reset context, if other requests in the context are in the priority list the requests could be resubmitted out of seqno order. Traverse the list of active requests in reverse and append to the head of the priority list to fix this. Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: <stable@vger.kernel.org> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-4-matthew.brost@intel.com
2021-09-13drm/i915/guc: Fix outstanding G2H accountingMatthew Brost
A small race that could result in incorrect accounting of the number of outstanding G2H. Basically prior to this patch we did not increment the number of outstanding G2H if we encoutered a GT reset while sending a H2G. This was incorrect as the context state had already been updated to anticipate a G2H response thus the counter should be incremented. As part of this change we remove a legacy (now unused) path that was the last caller requiring a G2H response that was not guaranteed to loop. This allows us to simplify the accounting as we don't need to handle the case where the send fails due to the channel being busy. Also always use helper when decrementing this value. v2 (Daniele): update GEM_BUG_ON check, pull in dead code removal from later patch, remove loop param from context_deregister. Fixes: f4eb1f3fe946 ("drm/i915/guc: Ensure G2H response has space in buffer") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: <stable@vger.kernel.org> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-3-matthew.brost@intel.com
2021-09-13drm/i915/guc: Fix blocked context accountingMatthew Brost
Prior to this patch the blocked context counter was cleared on init_sched_state (used during registering a context & resets) which is incorrect. This state needs to be persistent or the counter can read the incorrect value resulting in scheduling never getting enabled again. Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation") Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: <stable@vger.kernel.org> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909164744.31249-2-matthew.brost@intel.com
2021-09-13drm/i915/gvt: fix the usage of ww lock in gvt scheduler.Zhi A Wang
As the APIs related to ww lock in i915 was changed recently, the usage of ww lock in GVT-g scheduler needs to be changed accrodingly. We noticed a deadlock when GVT-g scheduler submits the workload to i915. After some investigation, it seems the way of how to use ww lock APIs has been changed. Releasing a ww now requires a explicit i915_gem_ww_ctx_fini(). Fixes: 67f1120381df ("drm/i915/gvt: Introduce per object locking in GVT scheduler.") Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Zhi A Wang <zhi.a.wang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210826143834.25410-1-zhi.a.wang@intel.com Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2021-09-13drm/ttm: Try to check if new ttm man out of bounds during compilexinhui pan
Allow TTM know if vendor set new ttm mananger out of bounds by adding build_bug_on. Signed-off-by: xinhui pan <xinhui.pan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210913080950.180752-1-xinhui.pan@amd.com Signed-off-by: Christian König <christian.koenig@amd.com>
2021-09-13drm/meson: Make use of the helper function devm_platform_ioremap_resourcexxx()Cai Huoqing
Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by: Cai Huoqing <caihuoqing@baidu.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210831135644.4576-1-caihuoqing@baidu.com
2021-09-12drm/panel-orientation-quirks: add Valve Steam DeckSimon Ser
Valve's Steam Deck has a 800x1280 LCD screen. Signed-off-by: Simon Ser <contact@emersion.fr> Cc: Jared Baldridge <jrb@expunge.us> Cc: Emil Velikov <emil.l.velikov@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Hans de Goede <hdegoede@redhat.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210911102430.253986-1-contact@emersion.fr
2021-09-12drm: panel-orientation-quirks: Add quirk for the Chuwi HiBookHans de Goede
The Chuwi HiBook uses a panel which has been mounted 90 degrees rotated. Add a quirk for this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210905130501.32980-1-hdegoede@redhat.com
2021-09-10drm/i915: Get PM ref before accessing HW registerVinay Belgaumkar
Seeing these errors when GT is likely in suspend state- "RPM wakelock ref not held during HW access" Ensure GT is awake before trying to access HW registers. Avoid reading the register if that is not the case. Signed-off-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Fixes: 41e5c17ebfc2 ("drm/i915/guc/slpc: Sysfs hooks for SLPC") Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210907232704.12982-1-vinay.belgaumkar@intel.com
2021-09-10Merge tag 'drm-next-2021-09-10' of git://anongit.freedesktop.org/drm/drmLinus Torvalds
Pull drm fixes from Dave Airlie: "Just an initial bunch of fixes for the merge window, amdgpu is most of them with a few ttm fixes and an fbdev avoid multiply overflow fix. core: - Make some dma-buf config options depend on DMA_SHARED_BUFFER - Handle multiplication overflow of fbdev xres/yres in the core ttm: - Fix ttm_bo_move_memcpy() when ttm_resource is subclassed - Fix ttm deadlock if target BO isn't idle - ttm build fix - ttm docs fix dma-buf: - config option fixes fbdev: - limit resolutions to avoid int overflow i915: - stddef change. amdgpu: - Misc cleanups, typo fixes - EEPROM fix - Add some new PCI IDs - Scatter/Gather display support for Yellow Carp - PCIe DPM fix for RKL platforms - RAS fix amdkfd: - SVM fix vc4: - static function fix mgag200: - fix uninit var panfrost: - lock_region fixes" * tag 'drm-next-2021-09-10' of git://anongit.freedesktop.org/drm/drm: (36 commits) drm/ttm: Fix a deadlock if the target BO is not idle during swap fbmem: don't allow too huge resolutions dma-buf: DMABUF_SYSFS_STATS should depend on DMA_SHARED_BUFFER dma-buf: DMABUF_DEBUG should depend on DMA_SHARED_BUFFER drm/i915: use linux/stddef.h due to "isystem: trim/fixup stdarg.h and other headers" dma-buf: DMABUF_MOVE_NOTIFY should depend on DMA_SHARED_BUFFER drm/amdkfd: drop process ref count when xnack disable drm/amdgpu: enable more pm sysfs under SRIOV 1-VF mode drm/amdgpu: fix fdinfo race with process exit drm/amdgpu: Fix a deadlock if previous GEM object allocation fails drm/amdgpu: stop scheduler when calling hw_fini (v2) drm/amdgpu: Clear RAS interrupt status on aldebaran drm/amd/display: Initialize lt_settings on instantiation drm/amd/display: cleanup idents after a revert drm/amd/display: Fix memory leak reported by coverity drm/ttm: Fix ttm_bo_move_memcpy() for subclassed struct ttm_resource drm/amdgpu/swsmu: fix spelling mistake "minimun" -> "minimum" drm/amdgpu: Disable PCIE_DPM on Intel RKL Platform drm/amdgpu: show both cmd id and name when psp cmd failed drm/amd/display: setup system context for APUs ...
2021-09-10drm/i915: Use Transparent Hugepages when IOMMU is enabledTvrtko Ursulin
Usage of Transparent Hugepages was disabled in 9987da4b5dcf ("drm/i915: Disable THP until we have a GPU read BW W/A"), but since it appears majority of performance regressions reported with an enabled IOMMU can be almost eliminated by turning them on, lets just do that. To err on the side of safety we keep the current default in cases where IOMMU is not active, and only when it is default to the "huge=within_size" mode. Although there probably would be wins to enable them throughout, more extensive testing across benchmarks and platforms would need to be done. With the patch and IOMMU enabled my local testing on a small Skylake part shows OglVSTangent regression being reduced from ~14% (IOMMU on versus IOMMU off) to ~2% (same comparison but with THP on). More detailed testing done in the below referenced Gitlab issue by Eero: Skylake GT4e: Performance drops from enabling IOMMU: 30-35% SynMark CSDof 20-25% Unigine Heaven, MemBW GPU write, SynMark VSTangent ~20% GLB Egypt (1/2 screen window) 10-15% GLB T-Rex (1/2 screen window) 8-10% GfxBench T-Rex, MemBW GPU blit 7-8% SynMark DeferredAA + TerrainFly* + ZBuffer 6-7% GfxBench Manhattan 3.0 + 3.1, SynMark TexMem128 & CSCloth 5-6% GfxBench CarChase, Unigine Valley 3-5% GfxBench Vulkan & GL AztecRuins + ALU2, MemBW GPU texture, SynMark Fill*, Deferred, TerrainPan* 1-2% Most of the other tests With the patch drops become: 20-25% SynMark TexMem* 15-20% GLB Egypt (1/2 screen window) 10-15% GLB T-Rex (1/2 screen window) 4-7% GfxBench T-Rex, GpuTest Triangle 1-8% GfxBench ALU2 (offscreen 1%, onscreen 8%) 3% GfxBench Manhattan 3.0, SynMark CSDof 2-3% Unigine Heaven + Valley, MemBW GPU texture 1-3 GfxBench Manhattan 3.1 + CarChase + Vulkan & GL AztecRuins Broxton: Performance drops from IOMMU, without patch: 30% MemBW GPU write 25% SynMark ZBuffer + Fill* 20% MemBW GPU blit 15% MemBW GPU blend, GpuTest Triangle 10-15% MemBW GPU texture 10% GLB Egypt, Unigine Heaven (had hangs), SynMark TerrainFly* 7-9% GLB T-Rex, GfxBench Manhattan 3.0 + T-Rex, SynMark Deferred* + TexMem* 6-8% GfxBench CarChase, Unigine Valley, SynMark CSCloth + ShMapVsm + TerrainPan* 5-6% GfxBench Manhattan 3.1 + GL AztecRuins, SynMark CSDof + TexFilterTri 2-4% GfxBench ALU2, SynMark DrvRes + GSCloth + ShMapPcf + Batch[0-5] + TexFilterAniso, GpuTest GiMark + 32-bit Julia And with patch: 15-20% MemBW GPU texture 10% SynMark TexMem* 8-9% GLB Egypt (1/2 screen window) 4-5% GLB T-Rex (1/2 screen window) 3-6% GfxBench Manhattan 3.0, GpuTest FurMark, SynMark Deferred + TexFilterTri 3-4% GfxBench Manhattan 3.1 + T-Rex, SynMark VSInstancing 2-4% GpuTest Triangle, SynMark DeferredAA 2-3% Unigine Heaven + Valley 1-3% SynMark Terrain* 1-2% GfxBench CarChase, SynMark TexFilterAniso + ZBuffer Tigerlake-H: 20-25% MemBW GPU texture 15-20% GpuTest Triangle 13-15% SynMark TerrainFly* + DeferredAA + HdrBloom 8-10% GfxBench Manhattan 3.1, SynMark TerrainPan* + DrvRes 6-7% GfxBench Manhattan 3.0, SynMark TexMem* 4-8% GLB onscreen Fill + T-Rex + Egypt (more in onscreen than offscreen versions of T-Rex/Egypt) 4-6% GfxBench CarChase + GLES AztecRuins + ALU2, GpuTest 32-bit Julia, SynMark CSDof + DrvState 3-5% GfxBench T-Rex + Egypt, Unigine Heaven + Valley, GpuTest Plot3D 1-7% Media tests 2-3% MemBW GPU blit 1-3% Most of the rest of 3D tests With the patch: 6-8% MemBW GPU blend => the only regression in these tests (compared to IOMMU without THP) 4-6% SynMark DrvState (not impacted) + HdrBloom (improved) 3-4% GLB T-Rex ~3% GLB Egypt, SynMark DrvRes 1-3% GfxBench T-Rex + Egypt, SynMark TexFilterTri 1-2% GfxBench CarChase + GLES AztecRuins, Unigine Valley, GpuTest Triangle ~1% GfxBench Manhattan 3.0/3.1, Unigine Heaven Perf of several tests actually improved with IOMMU + THP, compared to no IOMMU / no THP: 10-15% SynMark Batch[0-3] 5-10% MemBW GPU texture, SynMark ShMapVsm 3-4% SynMark Fill* + Geom* 2-3% SynMark TexMem512 + CSCloth 1-2% SynMark TexMem128 + DeferredAA As a summary across all platforms, these are the benchmarks where enabling THP on top of IOMMU enabled brings regressions: * Skylake GT4e: 20-25% SynMark TexMem* (whereas all MemBW GPU tests either improve or are not affected) * Broxton J4205: 7% MemBW GPU texture 2-3% SynMark TexMem* * Tigerlake-H: 7% MemBW GPU blend Other benchmarks show either lowering of regressions or improvements. v2: * Add Kconfig dependency to transparent hugepages and some help text. * Move to helper for easier handling of kernel build options. v3: * Drop Kconfig. (Daniel) v4: * Add some benchmark results to commit message. v5: * Add explicit regression summary to commit message. (Eero) References: b901bb89324a ("drm/i915/gemfs: enable THP") References: 9987da4b5dcf ("drm/i915: Disable THP until we have a GPU read BW W/A") References: https://gitlab.freedesktop.org/drm/intel/-/issues/430 Co-developed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Eero Tamminen <eero.t.tamminen@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210909114448.508493-1-tvrtko.ursulin@linux.intel.com
2021-09-10drm/ttm: Fix a deadlock if the target BO is not idle during swapxinhui pan
The ret value might be -EBUSY, caller will think lru lock is still locked but actually NOT. So return -ENOSPC instead. Otherwise we hit list corruption. ttm_bo_cleanup_refs might fail too if BO is not idle. If we return 0, caller(ttm_tt_populate -> ttm_global_swapout ->ttm_device_swapout) will be stuck as we actually did not free any BO memory. This usually happens when the fence is not signaled for a long time. Signed-off-by: xinhui pan <xinhui.pan@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Fixes: ebd59851c796 ("drm/ttm: move swapout logic around v3") Link: https://patchwork.freedesktop.org/patch/msgid/20210907040832.1107747-1-xinhui.pan@amd.com Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2021-09-09drm/panel-simple: Reorder logicpd_type_28 / mitsubishi_aa070mc01Douglas Anderson
The "logicpd_type_28" panel data was splitting up the mitsubishi_aa070mc01 panel data. Reorganize it so that the panel descs and modes are kept together. This is a no-op code-cleanup change, found by code inspection. Signed-off-by: Douglas Anderson <dianders@chromium.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210901131531.v3.4.Ib2bdeceb8ce45d36c09f5d1ae62a2263276a0605@changeid
2021-09-09drm/stm: ltdc: add layer alpha supportRaphael Gallais-Pou
Android Hardware Composer supports alpha values applied to layers. Enabling non-opaque layers for the STM CRTC could help offload GPU resources for screen composition. Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Acked-by: Yannick Fertre <yannick.fertre@foss.st.com> Reviewed-by: Yannick Fertre <yannick.fertre@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210907151534.6013-1-raphael.gallais-pou@foss.st.com
2021-09-09drm/stm: ltdc: attach immutable zpos property to planesRaphael Gallais-Pou
Defines plane ordering by hard-coding an immutable Z position from the first plane, used as primary layer, to the next ones as overlay in order of instantiation. This zpos is only an information as it is not possible to modify it, blending operations are still applied from the top to the bottom layer. This patch helps to remove a warning message from the Android Hardware Composer. Signed-off-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Acked-by: Yannick Fertre <yannick.fertre@foss.st.com> Reviewed-by: Yannick Fertre <yannick.fertre@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210907151323.5850-1-raphael.gallais-pou@foss.st.com
2021-09-09drm/ttm: add some general module kerneldocChristian König
For now just a brief description of what TTM is all about. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210908132933.3269-3-christian.koenig@amd.com
2021-09-09drm/i915/dp: Add support for out-of-bound hotplug eventsHans de Goede
On some Cherry Trail devices, DisplayPort over Type-C is supported through a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed datalines between USB-3 and DP (e.g. a pi3usb30532). The kernel in this case does the PD/alt-mode negotiation itself, rather then everything being handled in firmware. So the kernel itself picks an alt-mode, tells the Type-C "dongle" to switch to DP mode and sets the mux accordingly. In this setup the HPD pin is not connected, so the i915 driver needs to respond to a software event and scan the DP port for changes manually. This commit adds support for this. Together with the recent addition of DP alt-mode support to the Type-C subsystem this makes DP over Type-C work on these devices. Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210817215201.795062-7-hdegoede@redhat.com
2021-09-09drm/i915: Associate ACPI connector nodes with connector entries (v2)Heikki Krogerus
On Intel platforms we know that the ACPI connector device node order will follow the order the driver (i915) decides. The decision is made using the custom Intel ACPI OpRegion (intel_opregion.c), though the driver does not actually know that the values it sends to ACPI there are used for associating a device node for the connectors, and assigning address for them. In reality that custom Intel ACPI OpRegion actually violates ACPI specification (we supply dynamic information to objects that are defined static, for example _ADR), however, it makes assigning correct connector node for a connector entry straightforward (it's one-on-one mapping). Changes in v2 (Hans de goede): - Take a reference on the fwnode which we assign to the connector, for ACPI nodes this is a no-op but in the future we may see software-fwnodes assigned to connectors which are ref-counted. Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Tested-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210817215201.795062-6-hdegoede@redhat.com
2021-09-09drm/i915/hdcp: reuse rx_info for mst stream type1 capability checkJuston Li
On some MST docking stations, rx_info can only be read after RepeaterAuth_Send_ReceiverID_List and the RxStatus READY bit is set otherwise the read will return -EIO. This behavior causes the mst stream type1 capability test to fail to read rx_info and determine if the topology supports type1 and fallback to type0. To fix this, check for type1 capability when we receive rx_info within the AKE flow when we read RepeaterAuth_Send_ReceiverID_List instead of an explicit read just for type1 capability checking. This does require moving where we set stream_types to after hdcp2_authenticate_sink() when we get rx_info but this occurs before we do hdcp2_propagate_stream_management_info. Also, legacy HDCP 2.0/2.1 are not type 1 capable either so check for that as well. Changes since v5: - rename intel_set_stream_types() to intel_hdcp_prepare_streams() (Anshuman) Changes since v4: - move topology_type1_capable to intel_digital_port and rename it as hdcp_mst_type1_capable (Anshuman) - make a helper function intel_set_stream_types() to set stream types in hdcp2_authenticate_and_encrypt() (Anshuman) - break on failure to set stream types and retry instead of returning - remove no longer used declaration for streams_type1_capable() Changes since v2: - Remove no longer used variables in _intel_hdcp2_enable() Signed-off-by: Juston Li <juston.li@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Tested-by: Suraj K <suraj.kandpal@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210819184835.1181323-4-juston.li@intel.com
2021-09-09drm/i915/hdcp: read RxInfo once when reading RepeaterAuth_Send_ReceiverID_ListJuston Li
When reading RepeaterAuth_Send_ReceiverID_List, RxInfo is read by itself once to retrieve the DEVICE_COUNT to calculate the size of the ReceiverID list then read a second time as a part of reading ReceiverID list. On some MST docking stations, RxInfo can only be read after the RxStatus READY bit is set otherwise the read will return -EIO. The spec states that the READY bit should be cleared as soon as RxInfo has been read. In this case, the first RxInfo read succeeds but after the READY bit is cleared, the second read fails. Fix it by reading RxInfo once and storing it before reading the rest of RepeaterAuth_Send_ReceiverID_List once we know the size. Modify get_receiver_id_list_size() to read and store RxInfo in the message buffer and also parse DEVICE_COUNT so we know the size of RepeaterAuth_Send_ReceiverID_List. Afterwards, retrieve the rest of the message at the offset for seq_num_V. Changes in v5: - Don't change the offset define for Send_ReceiverID_List When reading, update message offset to account for RxInfo being read Changes in v4: - rebase and edit commit message Changes in v3: - remove comment Changes in v2: - remove unnecessary moving of drm_i915_private from patch 1 Signed-off-by: Juston Li <juston.li@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Tested-by: Suraj K <suraj.kandpal@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210819184835.1181323-3-juston.li@intel.com
2021-09-09drm/i915/hdcp: update cp_irq_count_cached in intel_dp_hdcp2_read_msg()Juston Li
Update cp_irq_count_cached when reading messages rather than when writing a message to make sure the value is up to date and not stale from a previously handled CP_IRQ. AKE flow doesn't always respond to a read with a ACK write msg. E.g. AKE_Send_Pairing_Info will "timeout" because we received a CP_IRQ for reading AKE_Send_H_Prime but no write occurred between that and reading AKE_Send_Pairing_Info so cp_irq_count_cached is stale causing the wait to return right away rather than waiting for a new CP_IRQ. Signed-off-by: Juston Li <juston.li@intel.com> Acked-by: Anshuman Gupta <anshuman.gupta@intel.com> Reviewed-by: Ramalingam C <ramalingam.c@intel.com> Tested-by: Suraj K <suraj.kandpal@intel.com> Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210819184835.1181323-2-juston.li@intel.com
2021-09-09Merge tag 'drm-misc-next-fixes-2021-09-03' of ↵Dave Airlie
git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next-fixes for v5.15: - Fix ttm_bo_move_memcpy() when ttm_resource is subclassed. - Small fixes to panfrost, mgag200, vc4. - Small ttm compilation fixes. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/41ff5e54-0837-2226-a182-97ffd11ef01e@linux.intel.com
2021-09-09Merge tag 'amd-drm-next-5.15-2021-09-01' of ↵Dave Airlie
https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.15-2021-09-01: amdgpu: - Misc cleanups, typo fixes - EEPROM fix - Add some new PCI IDs - Scatter/Gather display support for Yellow Carp - PCIe DPM fix for RKL platforms - RAS fix amdkfd: - SVM fix Signed-off-by: Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210901214015.4488-1-alexander.deucher@amd.com
2021-09-08drm/i915: clean up inconsistent indentingColin Ian King
There is a statement that is indented one character too deeply, clean this up. Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210902215737.55570-1-colin.king@canonical.com
2021-09-08drm/i915/dsi: Read/write proper brightness value via MIPI DCS commandLee Shawn C
Driver has to swap the endian before send brightness level value to tcon. v2: Use __be16 instead of u16 to fix sparse warning. v3: Send one or two bytes brightness value depend on the precision. v4: get data length of brightness value more easily. Reported-by: kernel test robot <lkp@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: William Tseng <william.tseng@intel.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210908115607.9633-6-shawn.c.lee@intel.com
2021-09-08drm/i915/dsi: Retrieve max brightness level from VBTLee Shawn C
So far, DCS backlight driver hardcode (0xFF) for max brightness level. MIPI DCS spec allow max 0xFFFF for set_display_brightness (51h) command. And VBT brightness precision bits can support 8 ~ 16 bits. We should set correct precision bits in VBT that meet panel's request. Driver can refer to this setting then configure max brightness level in DCS backlight driver properly. v2: modify variable name brightness_precision_bits instead of max_brightness_level. v3: fix checkpatch warning. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: William Tseng <william.tseng@intel.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210908115607.9633-5-shawn.c.lee@intel.com
2021-09-08drm/i915: Get proper min cdclk if vDSC enabledLee Shawn C
VDSC engine can process only 1 pixel per Cd clock. In case VDSC is used and max slice count == 1, max supported pixel clock should be 100% of CD clock. Then do min_cdclk and pixel clock comparison to get proper min cdclk. v2: - Check for dsc enable and slice count ==1 then allow to double confirm min cdclk value. Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Cc: William Tseng <william.tseng@intel.com> Signed-off-by: Lee Shawn C <shawn.c.lee@intel.com> Reviewed-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210908115607.9633-4-shawn.c.lee@intel.com
generated by cgit (git 2.34.1) at 2025-09-20 07:18:18 +0000