summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2024-04-10drm/xe/xe2hpm: Add initial set of workaroundsGustavo Sousa2-0/+36
Define the initial set of workarounds for Xe2_HPM. Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408170545.3769566-12-balasubramani.vivekanandan@intel.com
2024-04-10drm/xe/xe2hpg: Introduce performance tuning changes for Xe2_HPG.Shekhar Chauhan1-3/+3
Introduces performance tuning guide changes for Xe_HPG. v2: Switched to open upper bound for "Tuning: L3 Cache" setting. BSpec: 72161 Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408170545.3769566-11-balasubramani.vivekanandan@intel.com
2024-04-10drm/xe/xe2hpg: Add initial GT workaroundsHaridhar Kalvala2-2/+70
Add the initial set of Xe2_HPG gt/engine/lrc workarounds. v2: Removed WA_16020183090 which is no more applicable Extended WA_18033852989,18034896535 also to xe2hpg Signed-off-by: Haridhar Kalvala <haridhar.kalvala@intel.com> Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by: Gustavo Sousa <gustavo.sousa@intel.com> Signed-off-by: Dnyaneshar Bhadane <dnyaneshwar.bhadane@intel.com> Signed-off-by: Shekhar Chauhan <shekhar.chauhan@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408170545.3769566-10-balasubramani.vivekanandan@intel.com
2024-04-10drm/xe/xe2: Add workaround 18034896535Bommu Krishnaiah1-0/+5
Add 18034896535 as driver permanent workaround. v2: 18034896535 and 16021540221 are two independent workarounds that just happen to have the same implementation, hence keeping it. Signed-off-by: Bommu Krishnaiah <krishnaiah.bommu@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408170545.3769566-9-balasubramani.vivekanandan@intel.com
2024-04-10drm/xe/xe2hpg: Remove extra allocation of CCS pages for dgfxAkshata Jahagirdar1-0/+3
On Xe2 dGPU, compression is only supported with VRAM. When copying from VRAM -> system memory the KMD uses mapping with uncompressed PAT so the copy in system memory is guaranteed to be uncompressed. When restoring such buffers from system memory -> VRAM the KMD can't easily know which pages were originally compressed, so we always use uncompressed -> uncompressed here. so this means that there's no need for extra CCS storage on such platforms. v2: More description added to commit message Signed-off-by: Akshata Jahagirdar <akshata.jahagirdar@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408170545.3769566-8-balasubramani.vivekanandan@intel.com
2024-04-10drm/xe/xe2hpg: Determine flat ccs offset for vramHimal Prasad Ghimiray2-2/+42
on Xe2 dgfx platform determine the offset using Flat CCS size bitfield of XE2_FLAT_CCS_BASE_RANGE_[UPPER/LOWER] mcr registers. v2: function argument tile_size changed from pass by reference to pass by value Bspec: 68023 Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Signed-off-by: Akshata Jahagirdar <akshata.jahagirdar@intel.com> Signed-off-by: Matthew Auld <matthew.auld@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408170545.3769566-7-balasubramani.vivekanandan@intel.com
2024-04-10drm/xe/bmg: Program an additional discrete-specific PAT settingMatt Roper1-0/+7
Discrete Xe2 platforms require programming of one additional row of PAT settings which controls the access characteristics for PPGTT and LMTT page tables. Integrated GPUs do not need this programming and will leave the register at its hardware default value. Bspec: 71582 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408170545.3769566-6-balasubramani.vivekanandan@intel.com
2024-04-10drm/xe/bmg: Add BMG mocs tableBalasubramani Vivekanandan1-0/+1
BMG uses the same MOCS table as LNL. Bpsec: 71582 CC: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408170545.3769566-5-balasubramani.vivekanandan@intel.com
2024-04-10drm/xe/bmg: Add BMG platform definitionMatt Roper3-0/+8
BMG is a discrete GPU based on the Xe2 architecture. No device ids are bound to the BMG platform descriptor yet. BMG device ids will be added once we have all the basic required platform enabling patches landed. v2: Removed device ids, deferring it to a later patch v3: Squash in compat header IS_BATTLEMAGE() patch. (Lucas) Bspec: 68090 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408170545.3769566-4-balasubramani.vivekanandan@intel.com
2024-04-09drm/xe/xe2: Recognize Xe2_HPM IPMatt Roper1-1/+2
Xe2_HPM uses the same general feature flags as Xe2_LPM. Xe2_HPM is identified as version 13.01 in the GMD_ID register. Bspec: 68090, 67163 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408170545.3769566-3-balasubramani.vivekanandan@intel.com
2024-04-09drm/xe/xe2: Recognize Xe2_HPG IPMatt Roper1-1/+2
Xe2_HPG uses the same general feature flags as Xe2_LPG. Xe2_HPG is identified as version 20.01 in the GMD_ID register. Bspec: 68090 Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408170545.3769566-2-balasubramani.vivekanandan@intel.com
2024-04-09drm/xe/hwmon: Cast result to output precision on left shift of operandKarthik Poosa1-2/+2
Address potential overflow in result of left shift of a lower precision (u32) operand before assignment to higher precision (u64) variable. v2: - Update commit message. (Himal) Fixes: 4446fcf220ce ("drm/xe/hwmon: Expose power1_max_interval") Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Reviewed-by: Anshuman Gupta <anshuman.gupta@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405130127.1392426-5-karthik.poosa@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-04-09drm/xe/hwmon: Update xe_hwmon_get_reg to return struct xe_regKarthik Poosa1-21/+26
Return struct xe_reg instead of reg.raw from xe_hwmon_get_reg to have abstracted usage of struct xe_reg. v2: - Use xe_reg_is_valid function instead of XE_REG_IS_VALID macro as it is removed. Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405130127.1392426-3-karthik.poosa@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-04-09drm/xe: Define xe_reg_is_validKarthik Poosa1-0/+5
Add a function to check if struct xe_reg has valid address. v2: - Rebase. - Make xe_reg_is_valid as inline function instead of a macro. (Badal). - Update commit msg. Signed-off-by: Karthik Poosa <karthik.poosa@intel.com> Suggested-by: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: Badal Nilawar <badal.nilawar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405130127.1392426-2-karthik.poosa@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-04-09drm/xe/lnl: Enable GuC Wa_14019882105Badal Nilawar3-7/+39
Enable GuC Wa_14019882105 to block interrupts during C6 flow when the memory path has been blocked v2: Make helper function generic and name it as guc_waklv_enable_simple (John Harrison) v3: Make warning descriptive (John Harrison) v4: s/drm_WARN/xe_gt_WARN/ (Michal) Cc: John Harrison <john.harrison@intel.com> Signed-off-by: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405084231.3620848-3-badal.nilawar@intel.com
2024-04-09drm/xe/guc: Add support for workaround KLVsBadal Nilawar3-3/+66
To prevent running out of bits, new workaround (w/a) enable flags are being added via a KLV system instead of a 32 bit flags word. v2: GuC version check > 70.10 is not needed as base line xe doesnot support anything below < 70.19 v3: Use 64 bit ggtt address for future compatibility (John Harrison/Daniele) v4: %s/PAGE_SIZE/SZ_4K/ (Michal) Cc: John Harrison <John.C.Harrison@intel.com> Signed-off-by: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: John Harrison <John.C.Harrison@Intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405084231.3620848-2-badal.nilawar@intel.com
2024-04-09drm/xe: Capture GuC CT snapshot when stoppedMatthew Brost1-1/+1
It is useful capture the GuC CT snapshot if the GuC CT has been forcefully put into the stopped state. Enable snapshot capture when in this state. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405211632.223568-3-matthew.brost@intel.com
2024-04-09drm/xe: Always capture exec queues on snapshotMatthew Brost3-25/+6
Always capture exec queues on snapshot regardless if exec queue has pending jobs or not. Having jobs or not does indicate whether the exec queue capture is useful. Example bugs that would not be easily detected by skipping capture when pending job list is empty: - Jobs pending on exec queue have dependencies - Leaking exec queue refs - GuC protocol issues (i.e. losing G2H) In addition to above bugs, in general it just useful to see every exec queue registered with the GuC and its state. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405211632.223568-2-matthew.brost@intel.com
2024-04-08drm/xe/uapi: Restore flags VM_BIND_FLAG_READONLY and VM_BIND_FLAG_IMMEDIATEFrancois Dugast3-2/+23
The commit 84a1ed5e6756 ("drm/xe/uapi: Remove unused flags") is partially reverted. At the time, flags not used by user space were removed during cleanup. Some flags now needed by the compute runtime are brought back in this commit: - DRM_XE_VM_BIND_FLAG_READONLY is used to write protect kernel ISA thus preventing accidental overwrites. - DRM_XE_VM_BIND_FLAG_IMMEDIATE is used to trigger mapping at the time of binding in order to prevent faulting at execution time. The changes in the compute runtime are ready and approved, see link below. v2: Include a link to the PR in the commit message (Matthew Brost) v3: Update kernel doc and improve commit message (Lucas De Marchi) Cc: Mateusz Jablonski <mateusz.jablonski@intel.com> Cc: Michal Mrozek <michal.mrozek@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://github.com/intel/compute-runtime/pull/717 Signed-off-by: Francois Dugast <francois.dugast@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240329124403.7-1-francois.dugast@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-04-08drm/xe: Remove dead clock codeLucas De Marchi2-6/+1
xe_gt_clock_cycles_to_ns() is not called from anywhere after PMU handling was removed in commit 90a8b23f9b85 ("drm/xe/pmu: Remove PMU from Xe till uapi is finalized"). Drop it. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408151312.2100304-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-04-08drm: bridge: cdns-mhdp8546: Fix possible null pointer dereferenceAleksandr Mishin1-0/+3
In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is assigned to mhdp_state->current_mode, and there is a dereference of it in drm_mode_set_name(), which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Fix this bug add a check of mhdp_state->current_mode. Fixes: fb43aa0acdfd ("drm: bridge: Add support for Cadence MHDP8546 DPI/DP bridge") Signed-off-by: Aleksandr Mishin <amishin@t-argos.ru> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240408125810.21899-1-amishin@t-argos.ru
2024-04-08drm/xe: Label RING_CONTEXT_CONTROL as maskedAshutosh Dixit2-4/+3
RING_CONTEXT_CONTROL is a masked register. v2: Also clean up setting register value (Lucas) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404161256.3852502-1-ashutosh.dixit@intel.com
2024-04-08drm/xe: Remove debug message from migrate_clear()José Roberto de Souza1-3/+0
This messages is printed a lot and from my understanding it do not bring any value, so here dropping it. Signed-off-by: José Roberto de Souza <jose.souza@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405153849.44906-1-jose.souza@intel.com
2024-04-08drm/xe/display: Fix double mutex initializationLucas De Marchi1-5/+0
All of these mutexes are already initialized by the display side since commit 3fef3e6ff86a ("drm/i915: move display mutex inits to display code"), so the xe shouldn´t initialize them. Fixes: 44e694958b95 ("drm/xe/display: Implement display support") Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Arun R Murthy <arun.r.murthy@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405200711.2041428-1-lucas.demarchi@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-04-08drm/xe/vf: Mark supported firmwares as preloadedMichal Wajdeczko3-3/+19
On current platforms supported firmwares, like GuC and HuC, must be loaded by the PF driver. Mark those firmwares as 'preloaded' so we will skip fetching and loading them on the VF drivers but still correctly report them as 'running'. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404173814.715-1-michal.wajdeczko@intel.com
2024-04-08drm/xe/vf: Don't try to read legacy GuC MMIO notification if VFMichal Wajdeczko1-0/+3
Legacy SOFT_SCRATCH registers are not accessible from the VF. Any G2H notification posted there will be handled by the PF driver. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405133936.891-4-michal.wajdeczko@intel.com
2024-04-08drm/xe/vf: Don't try to program MOCS if VFMichal Wajdeczko1-0/+3
VFs drivers don't have access to MOCS registers. It is a PF driver responsibility to program MOCS according to the HW team guidelines. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405133936.891-3-michal.wajdeczko@intel.com
2024-04-08drm/xe/vf: Don't emit access to Global HWSP if VFMichal Wajdeczko1-4/+7
VFs can't access Global HWSP, don't emit questionable MI_FLUSH_DW while processing a migration job. Bspec: 52398 Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Piotr Piórkowski <piotr.piorkowski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405133936.891-2-michal.wajdeczko@intel.com
2024-04-08drm/xe/guc: Initialize GuC ID manager soonerMichal Wajdeczko1-9/+5
The GuC submission cleanup code may depend on the GuC ID manager, thus we can't initialize it after registering a submission cleanup action, as reverse cleanup sequence will destroy GuC ID manager prior to a call to guc_submit_fini(). Move GuC ID manager initialization up, right after managed mutex initialization, to have it available during guc_submit_fini(). Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240406143946.979-2-michal.wajdeczko@intel.com
2024-04-08drm/xe/guc: Use drm_device-managed version of mutex_init()Michal Wajdeczko1-2/+4
This is safer approach and will help resolve a cleanup ordering conflict related to the GuC ID manager. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240406143946.979-1-michal.wajdeczko@intel.com
2024-04-08dt-bindings: display: bridge: it6505: Add #sound-dai-cellsChen-Yu Tsai1-1/+7
The ITE IT6505 display bridge can take one I2S input and transmit it over the DisplayPort link. Add #sound-dai-cells (= 0) to the binding for it. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240327085250.3427496-1-wenst@chromium.org
2024-04-08drm-panel: If drm_panel_dp_aux_backlight() fails, don't fail panel probeDouglas Anderson2-3/+14
If we're using the AUX channel for eDP backlight and it fails to probe for some reason, let's _not_ fail the panel probe. At least one case where we could fail to init the backlight is because of a dead or physically missing panel. As talked about in detail in the earlier patch in this series, ("drm/panel-edp: If we fail to powerup/get EDID, use conservative timings"), this can cause the entire system's display pipeline to fail to come up and that's non-ideal. If we fail to init the backlight for some transitory reason, we should dig in and see if there's a way to fix this (perhaps retries?). Even in that case, though, having a panel whose backlight is stuck at 100% (the default, at least in the panel Samsung ATNA33XC20 I tested) is better than having no panel at all. Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240325145626.3.I552e8af0ddb1691cc0fe5d27ea3d8020e36f7006@changeid
2024-04-08drm/panel-edp: If we fail to powerup/get EDID, use conservative timingsDouglas Anderson1-5/+7
If at boot we fail to power up the eDP panel (most often happens if the eDP panel never asserts HPD to us) or if we are unable to read the EDID at bootup to figure out the panel's ID then let's use the conservative eDP panel powerup/powerdown timings but _not_ fail the probe. It might seem strange to _not_ fail the probe in this case since we were unable to powerup the panel and confirm it's there. However, there is a reason to do this. Specifically, if we fail to probe the panel then it really throws the whole display pipeline for loop. Most DRM subsystems are written so that they wait until all components (including the panel) have probed before they set everything up. When the panel doesn't come up then this never happens. As a side effect of not setting everything up then other display adapters don't get initialized. As a practical example, I can see that if I open up a sc7180-trogdor based Chromebook that's using the generic "edp-panel" and unplug the eDP panel that it causes the _external_ DP monitor not to function. This is obviously bad because it means that a device with a dead eDP panel becomes e-waste when it could instead still be given useful life with an external display. NOTES: - When we fail to probe like this, boot is a bit slow because we try several times to power the panel up. This doesn't feel horrible because it'll eventually work and the retries are known to help bring some panels up. - In the case where we hit the condition of failing to power up, the display will likely _never_ have a chance to work again until reboot. Once the panel-edp pm_runtime resume function fails it doesn't ever seem to retry. This is probably for the best given that we don't have any real timing/modes. eDP isn't expected to be "hotplugged" so this makes some sense. - It turns out that this makes panel-edp behave more similarly for users of the generic "edp-panel" compatible string and the old fixed panel compatible string. With the old fixed panel compatible string we don't talk to the panel during probe so we'd actually behave much the same way that we'll now behave for the generic "edp-panel". Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240325145626.2.Ia7a55a9657b0b6aa4644fd497a0bc595a771258c@changeid
2024-04-08drm/panel-edp: Abstract out function to set conservative timingsDouglas Anderson1-20/+20
If we're using the generic "edp-panel" compatible string and we fail to detect an eDP panel then we fall back to conservative timings for powering up and powering down the panel. Abstract out the function for setting these timings so it can be used in future patches. No functional change expected--just code movement. Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240325145626.1.I659b2517d9f619d09e804e071591ecab76335dfb@changeid
2024-04-07Merge tag 'drm-misc-next-2024-04-05' of ↵Dave Airlie32-460/+356
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next drm-misc-next for v6.10: Core Changes: - Fix DRM_DISPLAY_DP_HELPER dependencies. Driver Changes: - i2c and polling fixes to ast. - Small fixes to panthor. - Allow IRQ to share GPIO pins in bridge/adv7511. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/2ad89d5a-4096-4cc5-badb-4ad61ff1df7d@linux.intel.com
2024-04-05drm/xe: Drop xe_vm_assert_held() macro definition from xe_bo.hMichal Wajdeczko1-8/+0
It is already defined in xe_vm.h and shouldn't be duplicated. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405113844.803-1-michal.wajdeczko@intel.com
2024-04-05drm/xe: Move PTE/PDE bit definitions to proper headerMichal Wajdeczko6-21/+25
We already have dedicated header for GGTT/PPGTT definitions. It's also cleaner to separate them from implementation macros. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405123520.847-1-michal.wajdeczko@intel.com
2024-04-05accel/qaic: Add fifo queued debugfsJeffrey Hugo3-0/+41
When debugging functional issues with workload input processing, it is useful to know if requests are backing up in the fifo, or perhaps getting stuck elsewhere. To answer the question of how many requests are in the fifo, implement a "queued" debugfs entry per-dbc that returns the number of pending requests when read. Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240322175730.3855440-4-quic_jhugo@quicinc.com
2024-04-05accel/qaic: Add fifo size debugfsJeffrey Hugo1-0/+35
Each DMA Bridge Channel (dbc) has a unique configured fifo size which is specified by the userspace client of that dbc. Since the fifo is circular, it is useful to know the configured size when debugging issues. Add a per-dbc subdirectory in debugfs and in each subdirectory add a fifo_size entry that will display the size of that dbc's fifo when read. Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240322175730.3855440-3-quic_jhugo@quicinc.com
2024-04-05accel/qaic: Add bootlog debugfsJeffrey Hugo5-1/+317
During the boot process of AIC100, the bootloaders (PBL and SBL) log messages to device RAM. During SBL, if the host opens the QAIC_LOGGING channel, SBL will offload the contents of the log buffer to the host, and stream any new messages that SBL logs. This log of the boot process can be very useful for an initial triage of any boot related issues. For example, if SBL rejects one of the runtime firmware images for a validation failure, SBL will log a reason why. Add the ability of the driver to open the logging channel, receive the messages, and store them. Also define a debugfs entry called "bootlog" by hooking into the DRM debugfs framework. When the bootlog debugfs entry is read, the current contents of the log that the host is caching is displayed to the user. The driver will retain the cache until it detects that the device has rebooted. At that point, the cache will be freed, and the driver will wait for a new log. With this scheme, the driver will only have a cache of the log from the current device boot. Note that if the driver initializes a device and it is already in the runtime state (QSM), no bootlog will be available through this mechanism because the driver and SBL have not communicated. Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Reviewed-by: Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by: Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by: Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240322175730.3855440-2-quic_jhugo@quicinc.com
2024-04-05drm/xe: fix multicast support for Xe_LP platformsAndrzej Hajda1-1/+6
Xe_LP has six sublices per slice. v2: fixed commit message and subject (Matt) Bspec: 66696 Fixes: bde5d76785bc ("drm/xe: Add helper macro to loop each DSS") Signed-off-by: Andrzej Hajda <andrzej.hajda@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240405-mcr_adlp-v2-1-2fd1e4325ef2@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
2024-04-05drm/bridge: dw-hdmi: Make DRM_DW_HDMI selectableMaxime Ripard1-1/+1
Commit c0e0f139354c ("drm: Make drivers depends on DRM_DW_HDMI") turned select dependencies into depends on ones. However, DRM_DW_HDMI was not manually selectable which resulted in no way to enable the drivers that were now depending on it. Fixes: 4fc8cb47fcfd ("drm/display: Move HDMI helpers into display-helper module") Reported-by: Mark Brown <broonie@kernel.org> Reported-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240403-fix-dw-hdmi-kconfig-v1-2-afbc4a835c38@kernel.org
2024-04-05drm/display: Select DRM_KMS_HELPER for DP helpersMaxime Ripard1-0/+1
The DisplayPort helpers rely on some (__drm_atomic_helper_private_obj_duplicate_state, drm_kms_helper_hotplug_event) helpers found in files compiled by DRM_KMS_HELPER. Prior to commit d674858ff979 ("drm/display: Make all helpers visible and switch to depends on"), DRM_DISPLAY_DP_HELPER was only selectable so it wasn't really a big deal. However, since that commit, it's now something that can be enabled as is, and since there's no expressed dependency with DRM_KMS_HELPER, it can break too. Since DRM_KMS_HELPER is a selectable option for now, let's select it for DRM_DISPLAY_DP_HELPER. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202404021556.0JVcNC13-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202404021700.LbyYZGFd-lkp@intel.com/ Fixes: d674858ff979 ("drm/display: Make all helpers visible and switch to depends on") Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240403-fix-dw-hdmi-kconfig-v1-1-afbc4a835c38@kernel.org
2024-04-05drm/xe/guc: Reuse code while debugging GuC paramsMichal Wajdeczko1-10/+11
There is no need to duplicate code to print GuC parameters. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404155046.627-2-michal.wajdeczko@intel.com
2024-04-05drm/xe/guc: Prefer GT oriented logs for GuC messagesMichal Wajdeczko1-43/+36
A platform can have more than one GuC, so we should use GT-oriented logs to correctly identify the source of the message. Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240404155046.627-1-michal.wajdeczko@intel.com
2024-04-05Merge tag 'drm-misc-next-2024-03-28' of ↵Dave Airlie152-817/+15894
https://gitlab.freedesktop.org/drm/misc/kernel into drm-next Two misc-next in one. drm-misc-next for v6.10-rc1: The deal of a lifetime! You get ALL of the previous drm-misc-next-2024-03-21-1 tag!! But WAIT, there's MORE! Cross-subsystem Changes: - Assorted DT binding updates. Core Changes: - Clarify how optional wait_hpd_asserted is. - Shuffle Kconfig names around. Driver Changes: - Assorted build fixes for panthor, imagination, - Add AUO B120XAN01.0 panels. - Assorted small fixes to panthor, panfrost. drm-misc-next for v6.10: UAPI Changes: - Move some nouveau magic constants to uapi. Cross-subsystem Changes: - Move drm-misc to gitlab and freedesktop hosting. - Add entries for panfrost. Core Changes: - Improve placement for TTM bo's in idle/busy handling. - Improve drm/bridge init ordering. - Add CONFIG_DRM_WERROR, and use W=1 for drm. - Assorted documentation updates. - Make more (drm and driver) headers self-contained and add header guards. - Grab reservation lock in pin/unpin callbacks. - Fix reservation lock handling for vmap. - Add edp and edid panel matching, use it to fix a nearly identical panel. Driver Changes: - Add drm/panthor driver and assorted fixes. - Assorted small fixes to xlnx, panel-edp, tidss, ci, nouveau, panel and bridge drivers. - Add Samsung s6e3fa7, BOE NT116WHM-N44, CMN N116BCA-EA1, CrystalClear CMT430B19N00, Startek KD050HDFIA020-C020A, powertip PH128800T006-ZHC01 panels. - Fix console for omapdrm. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/bea310a6-6ff6-477e-9363-f9f053cfd12a@linux.intel.com
2024-04-04drm/xe/xe_hw_engine_class_sysfs: use sysfs_emit() for attr's _show()Bommu Krishnaiah1-18/+18
sprintf() is deprecated for sysfs, use preferred sysfs_emit() instead. v2: used sysfs_emit instand of sprintf Signed-off-by: Bommu Krishnaiah <krishnaiah.bommu@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231209235949.54524-3-krishnaiah.bommu@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-04-04drm/xe: prefer snprintf over sprintfBommu Krishnaiah5-11/+11
since the sprintf() function lacks built-in protection against buffer overflows using the snprintf() function. v2: Removed hard coded values and used sizeof() Signed-off-by: Bommu Krishnaiah <krishnaiah.bommu@intel.com> Cc: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Cc: Tejas Upadhyay <tejas.upadhyay@intel.com> Reviewed-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20231209235949.54524-2-krishnaiah.bommu@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-04-04drm/xe: Protect devcoredump access after unbindRodrigo Vivi2-3/+4
While we don't have the full flow protection when devcoredump is accessed after device unbind. Let's at least for now protect against null dereference: [ 422.766508] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] [ 423.119584] RIP: 0010:xe_vm_snapshot_free+0x30/0x180 [xe] While at it, I also fixed a non-standard code-declaration block on the similar function of xe_guc_submit. v2: - Use IS_ERR_OR_NULL (Nirmoy) - Expand to other functions Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: Nirmoy Das <nirmoy.das@intel.com> Reviewed-by: José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240403195044.239766-1-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2024-04-04drm: fix DRM_DISPLAY_DP_HELPER dependenciesArnd Bergmann2-2/+2
Both the exynos and rockchip drivers ran into link failures after a Kconfig cleanup: aarch64-linux-ld: drivers/gpu/drm/exynos/exynos_dp.o: in function `exynos_dp_resume': exynos_dp.c:(.text+0xc0): undefined reference to `analogix_dp_resume' aarch64-linux-ld: drivers/gpu/drm/exynos/exynos_dp.o: in function `exynos_dp_suspend': exynos_dp.c:(.text+0xf4): undefined reference to `analogix_dp_suspend' x86_64-linux-ld: drivers/gpu/drm/rockchip/cdn-dp-core.o: in function `cdn_dp_connector_mode_valid': cdn-dp-core.c:(.text+0x13a): undefined reference to `drm_dp_bw_code_to_link_rate' x86_64-linux-ld: cdn-dp-core.c:(.text+0x148): undefined reference to `drm_dp_bw_code_to_link_rate' x86_64-linux-ld: drivers/gpu/drm/rockchip/cdn-dp-core.o: in function `cdn_dp_check_link_status': cdn-dp-core.c:(.text+0x1396): undefined reference to `drm_dp_channel_eq_ok' In both cases, the problem is that ROCKCHIP_CDN_DP and DRM_EXYNOS_DP are 'bool' symbols that depend on the the 'tristate' DRM_DISPLAY_HELPER symbol, but end up not working when the SoC specific part is built-in but the helper is in a loadable module. Use the same trick that DRM_ROCKCHIP already uses for the EXTCON dependency and disallow DP support when it would not work. Fixes: 0323287de87d ("drm: Switch DRM_DISPLAY_DP_HELPER to depends on") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240404124101.2988099-1-arnd@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-02 21:47:57 +0300