- 10 Jun, 2021 9 commits
-
-
Leandro Ribeiro authored
In this patch we add a section to document what userspace should do to find out the CRTC index. This is important as they may be many places in the documentation that need this, so it's better to just point to this section and avoid repetition. Signed-off-by:
Leandro Ribeiro <leandro.ribeiro@collabora.com> Reviewed-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210609230039.73307-2-leandro.ribeiro@collabora.com
-
Thomas Zimmermann authored
Backmerging to pick up the latest TTM patches plus conflict resolution. Signed-off-by:Thomas Zimmermann <tzimmermann@suse.de>
-
Christian König authored
TTMs buffer objects are based on GEM objects for quite a while and rely on initializing those fields before initializing the TTM BO. Nouveau now doesn't init the GEM object for internally allocated BOs, so make sure that we at least initialize some necessary fields. Signed-off-by:
Christian König <christian.koenig@amd.com> Tested-by:
Mikko Perttunen <mperttunen@nvidia.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Reviewed-by:
Huang Rui <ray.huang@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210609172902.1937-1-christian.koenig@amd.com
-
Vivek Kasireddy authored
If the VMM's (Qemu) memory backend is backed up by memfd + Hugepages (hugetlbfs and not THP), we have to first find the hugepage(s) where the Guest allocations are located and then extract the regular 4k sized subpages from them. v2: Ensure that the subpage and hugepage offsets are calculated correctly when the range of subpage allocations cuts across multiple hugepages. v3: Instead of repeatedly looking up the hugepage for each subpage, only do it when the subpage allocation crosses over into a different hugepage. (suggested by Gerd and DW) v4: Fix the following warning identified by checkpatch: CHECK:OPEN_ENDED_LINE: Lines should not end with a '(' Cc: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
Dongwon Kim <dongwon.kim@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210609182915.592743-1-vivek.kasireddy@intel.com [ kraxel: one more checkpatch format tweak ] Signed-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Dave Airlie authored
Merge tag 'amd-drm-next-5.14-2021-06-09' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.14-2021-06-09: amdgpu: - SR-IOV fixes - Smartshift updates - GPUVM TLB flush updates - 16bpc fixed point display fix for DCE11 - BACO cleanups and core refactoring - Aldebaran updates - Initial Yellow Carp support - RAS fixes - PM API cleanup - DC visual confirm updates - DC DP MST fixes - DC DML fixes - Misc code cleanups and bug fixes amdkfd: - Initial Yellow Carp support radeon: - memcpy_to/from_io fixes UAPI: - Add Yellow Carp chip family id Used internally in the kernel driver and by mesa Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210610031649.4006-1-alexander.deucher@amd.com
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
Cross-subsystem Changes: - x86/gpu: add JasperLake to gen11 early quirks (Although the patch lacks the Ack info, it has been Acked by Borislav) Driver Changes: - General DMC improves (Anusha) - More ADL-P enabling (Vandita, Matt, Jose, Mika, Anusha, Imre, Lucas, Jani, Manasi, Ville, Stanislav) - Introduce MBUS relative dbuf offset (Ville) - PSR fixes and improvements (Gwan, Jose, Ville) - Re-enable LTTPR non-transparent LT mode for DPCD_REV < 1.4 (Ville) - Remove duplicated declarations (Shaokun, Wan) - Check HDMI sink deep color capabilities during .mode_valid (Ville) - Fix display flicker screan related to console and FBC (Chris) - Remaining conversions of GRAPHICS_VER (Lucas) - Drop invalid FIXME (Jose) - Fix bigjoiner check in dsc_disable (Vandita) Signed-off-by:
-
Dave Airlie authored
This fixes 32-bit arm build due to lack of 64-bit divides. Fixes: cb1c8146 ("drm/ttm: flip the switch for driver allocated resources v2") Link: https://patchwork.freedesktop.org/patch/438442/Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
Drop disabling of gfxoff during VCN use. This allows gfxoff to kick in and potentially save power if the user is not using gfx for color space conversion or scaling. VCN1.0 had a bug which prevented it from working properly with gfxoff, so we disabled it while using VCN. That said, most apps today use gfx for scaling and color space conversion rather than overlay planes so it was generally in use anyway. This was fixed on VCN2+, but since we mostly use gfx for color space conversion and scaling and rapidly powering up/down gfx can negate the advantages of gfxoff, we left gfxoff disabled. As more applications use overlay planes for color space conversion and scaling, this starts to be a win, so go ahead and leave gfxoff enabled. Note that VCN1.0 uses vcn_v1_0_idle_work_handler() and vcn_v1_0_ring_begin_use() so they are not affected by this patch. Reviewed-by:
James Zhu <James.Zhu@amd.com> Acked-by:
Boyuan Zhang <Boyuan.Zhang@amd.com> Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 5.14: UAPI Changes: * drm/panfrost: Export AFBC_FEATURES register to userspace Cross-subsystem Changes: * dma-buf: Fix debug printing; Rename dma_resv_*() functions + changes in callers; Cleanups Core Changes: * Add prefetching memcpy for WC * Avoid circular dependency on CONFIG_FB * Cleanups * Documentation fixes throughout DRM * ttm: Make struct ttm_resource the base of all managers + changes in all users of TTM; Add a generic memcpy for page-based iomem; Remove use of VM_MIXEDMAP; Cleanups Driver Changes: * drm/bridge: Add TI SN65DSI83 and SN65DSI84 + DT bindings * drm/hyperv: Add DRM driver for HyperV graphics output * drm/msm: Fix module dependencies * drm/panel: KD53T133: Support rotation * drm/pl111: Fix module dependencies * drm/qxl: Fixes * drm/stm: Cleanups * drm/sun4i: Be explicit about format modifiers * drm/vc4: Use struct gpio_desc; Cleanups * drm/vgem: Cleanups * drm/vmwgfx: Use ttm_bo_move_null() if there's nothing to copy * fbdev/mach64: Cleanups * fbdev/mb862xx: Use DEVICE_ATTR_RO Signed-off-by:
-
- 09 Jun, 2021 15 commits
-
-
Lyude Paul authored
This adds support for controlling panel backlights over eDP using VESA's standard backlight control interface. Luckily, Nvidia was cool enough to never come up with their own proprietary backlight control interface (at least, not any that I or the laptop manufacturers I've talked to are aware of), so this should work for any laptop panels which support the VESA backlight control interface. Note that we don't yet provide the panel backlight frequency to the DRM DP backlight helpers. This should be fine for the time being, since it's not required to get basic backlight controls working. For reference: there's some mentions of PWM backlight values in nouveau_reg.h, but I'm not sure these are the values we would want to use. If we figure out how to get this information in the future, we'll have the benefit of more granular backlight control. Signed-off-by:
Lyude Paul <lyude@redhat.com> Reviewed-by:
Ben Skeggs <bskeggs@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Dave Airlie <airlied@gmail.com> Cc: greg.depoire@gmail.com Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-10-lyude@redhat.com
-
Lyude Paul authored
Since we're about to implement eDP backlight support in nouveau using the standard protocol from VESA, we might as well just take the code that's already written for this and move it into a set of shared DRM helpers. Note that these helpers are intended to handle DPCD related backlight control bits such as setting the brightness level over AUX, probing the backlight's TCON, enabling/disabling the backlight over AUX if supported, etc. Any PWM-related portions of backlight control are explicitly left up to the driver, as these will vary from platform to platform. The only exception to this is the calculation of the PWM frequency pre-divider value. This is because the only platform-specific information required for this is the PWM frequency of the panel, which the driver is expected to provide if available. The actual algorithm for calculating this value is standard and is defined in the eDP specification from VESA. Note that these helpers do not yet implement the full range of features the VESA backlight interface provides, and only provide the following functionality (all of which was already present in i915's DPCD backlight support): * Basic control of brightness levels * Basic probing of backlight capabilities * Helpers for enabling and disabling the backlight v3: * Split out changes to i915's backlight code to separate patches to make it easier to review v4: * Style/spelling changes from Thomas Zimmermann v5: * Start using new drm_dbg_*() functions Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-9-lyude@redhat.com
-
Lyude Paul authored
Also, stop printing the DPCD register that failed, and just describe it instead. Saves us from having to look up each register offset when reading through kernel logs (plus, DPCD dumping with drm.debug |= 0x100 will give us that anyway). Signed-off-by:
-
Lyude Paul authored
If we can't read DP_EDP_PWMGEN_BIT_COUNT in intel_dp_aux_vesa_calc_max_backlight() but do have a valid PWM frequency defined in the VBT, we'll keep going in the function until we inevitably fail on reading DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN. There's not much point in doing this, so just return early. Signed-off-by:
-
Lyude Paul authored
No functional changes, just move set_vesa_backlight_enable() closer to it's only caller: intel_dp_aux_vesa_enable_backlight(). Signed-off-by:
-
Lyude Paul authored
Since we're about to be moving this code into shared DRM helpers, we might as well start to cache certain backlight capabilities that can be determined from the EDP DPCD, and are likely to be relevant to the majority of drivers using said helpers. The main purpose of this is just to prevent every driver from having to check everything against the eDP DPCD using DP macros, which makes the code slightly easier to read (especially since the names of some of the eDP capabilities don't exactly match up with what we actually need to use them for, like DP_EDP_BACKLIGHT_BRIGHTNESS_BYTE_COUNT for instance). Signed-off-by:
-
Lyude Paul authored
Get rid of the extraneous switch case in here, and just open code edp_backlight_mode as we only ever use it once. v4: * Check that backlight mode is DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD, not DP_EDP_BACKLIGHT_CONTROL_MODE_MASK - imirkin Signed-off-by:
-
Lyude Paul authored
This is kind of an annoying aspect of DRM's DP helpers: drm_dp_dpcd_readb/writeb() return the size of bytes read/written on success, thus we want to check against that instead of checking if the return value is less than 0. I'll probably be fixing this in the near future once I start doing DP work again, also because I'd rather not mix a tree-wide refactor like that in with a patch series intended to be around introducing DP backlight helpers. So, for now let's just handle the return values from each function correctly. Signed-off-by:
-
Lyude Paul authored
Noticed this while moving all of the VESA backlight code in i915 over to DRM helpers: it would appear that we calculate the frequency value we want to write to DP_EDP_BACKLIGHT_FREQ_SET twice even though this value never actually changes during runtime. So, let's simplify things by just caching this value in intel_panel.backlight, and re-writing it as-needed. Changes since v1: * Wrap panel->backlight.edp.vesa.pwm_freq_pre_divider in DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP check - Jani Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210514181504.565252-2-lyude@redhat.com
-
Stanislav Lisovskiy authored
We currently treat same slice mask as a same DBuf state and skip updating the Dbuf slices, if we detect that. This is wrong as if we have a multi to single pipe change or vice versa, that would be treated as a same Dbuf state and thus no changes required, so we don't get Mbus updated, causing issues. Solution: check also mbus_join, in addition to slices mask. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Signed-off-by:
-
Stanislav Lisovskiy authored
CDCLK crawl feature allows to change CDCLK frequency without disabling the actual PLL and doesn't require a full modeset. v2: - Added has_cdclk_crawl as a feature flag to intel_device_info(Matt Roper) - s/gen13_cdclk_pll_crawl/adlp_cdclk_pll_crawl/ (Matt Roper) Cc: Mika Kahola <mika.kahola@intel.com> Reviewed-by:Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Signed-off-by:
-
Marek Vasut authored
Fix the following sparse warnings generated by "make C=1": drivers/gpu/drm/bridge/ti-sn65dsi83.c:429:13: warning: incorrect type in assignment (different base types) drivers/gpu/drm/bridge/ti-sn65dsi83.c:429:13: expected unsigned short [assigned] [usertype] val drivers/gpu/drm/bridge/ti-sn65dsi83.c:429:13: got restricted __le16 [usertype] drivers/gpu/drm/bridge/ti-sn65dsi83.c:432:13: warning: incorrect type in assignment (different base types) drivers/gpu/drm/bridge/ti-sn65dsi83.c:432:13: expected unsigned short [addressable] [assigned] [usertype] val drivers/gpu/drm/bridge/ti-sn65dsi83.c:432:13: got restricted __le16 [usertype] drivers/gpu/drm/bridge/ti-sn65dsi83.c:436:13: warning: incorrect type in assignment (different base types) drivers/gpu/drm/bridge/ti-sn65dsi83.c:436:13: expected unsigned short [addressable] [assigned] [usertype] val drivers/gpu/drm/bridge/ti-sn65dsi83.c:436:13: got restricted __le16 [usertype] drivers/gpu/drm/bridge/ti-sn65dsi83.c:438:13: warning: incorrect type in assignment (different base types) drivers/gpu/drm/bridge/ti-sn65dsi83.c:438:13: expected unsigned short [addressable] [assigned] [usertype] val drivers/gpu/drm/bridge/ti-sn65dsi83.c:438:13: got restricted __le16 [usertype] drivers/gpu/drm/bridge/ti-sn65dsi83.c:441:13: warning: incorrect type in assignment (different base types) drivers/gpu/drm/bridge/ti-sn65dsi83.c:441:13: expected unsigned short [addressable] [assigned] [usertype] val drivers/gpu/drm/bridge/ti-sn65dsi83.c:441:13: got restricted __le16 [usertype] Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Adam Ford <aford173@gmail.com> Cc: Douglas Anderson <dianders@chromium.org> Cc: Frieder Schrempf <frieder.schrempf@kontron.de> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Loic Poulain <loic.poulain@linaro.org> Cc: Marek Vasut <marex@denx.de> Cc: Philippe Schenker <philippe.schenker@toradex.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Stephen Boyd <swboyd@chromium.org> Cc: Valentin Raevsky <valentin@compulab.co.il> To: dri-devel@lists.freedesktop.org Signed-off-by:
Robert Foss <robert.foss@linaro.org> Reviewed-by:
-
Vandita Kulkarni authored
This change takes care of resetting the dss_ctl registers in case of dsc_disable, bigjoiner disable and also uncompressed joiner disable. v2: Fix formatting v3: Fix the typo (Mansi) Suggested-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Anshuman Gupta <anshuman.gupta@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210609065914.4454-1-vandita.kulkarni@intel.com
-
Nirmoy Das authored
Use ttm_bo_move_null() instead of ttm_bo_assign_mem(). Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Reviewed-by:
-
Colin Ian King authored
The object surf is not fully initialized and the uninitialized field surf.data is being copied by the call to qxl_bo_create via the call to qxl_gem_object_create. Set surf.data to zero to ensure garbage data from the stack is not being copied. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: f64122c1 ("drm: add new QXL driver. (v1.4)") Signed-off-by:Colin Ian King <colin.king@canonical.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210608161313.161922-1-colin.king@canonical.comSigned-off-by:
-
- 08 Jun, 2021 16 commits
-
-
Ville Syrjälä authored
AUX logic is often clocked from cdclk. Disable PSR to make sure there are no hw initiated AUX transactions in flight while we change the cdclk frequency. Cc: Mika Kahola <mika.kahola@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210608085415.515342-2-gwan-gyeong.mun@intel.com
-
Gwan-gyeong Mun authored
This introduces the following function that can exit and activate a psr source when intel_psr is already enabled. - intel_psr_pause(): Pause current PSR. It deactivates current psr state. - intel_psr_resume(): Resume paused PSR. It activates paused psr state. v2: Address Jose's review comment. - Remove unneeded changes around the intel_psr_enable(). - Add intel_psr_post_exit() which processes waiting until PSR is idle and WA for SelectiveFetch. v3: Address Jose's review comment. - Rename intel_psr_post_exit() to intel_psr_wait_exit_locked(). - Move WA_1408330847 to intel_psr_disable_locked() - If the PSR is paused by an explicit intel_psr_paused() call, make the intel_psr_flush() not to activate PSR. v4: Address Jose's review comment. - In order to avoid the scenario of PSR is not active but there is a scheduled psr->work, it changes the check routine of intel_psr_pause() for PSR's enablement from "psr->active" to "psr->enable". Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:Matt Roper <matthew.d.roper@intel.com> Reviewed-by:
-
Marek Vasut authored
There is not much value in the extra conversion step, the calculations required for the LTDC IP are different than what is used in the drm_display_mode_to_videomode(), so just do the right ones in the LTDC driver right away. Signed-off-by:
Yannick Fertré <yannick.fertre@st.com> Signed-off-by:
Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210607172457.14471-1-marex@denx.de
-
Rohit Khaire authored
This is similar to IH_RB_CNTL programming in navi10_ih_toggle_ring_interrupts Signed-off-by:
Rohit Khaire <rohit.khaire@amd.com> Acked-by:
Horace Chen <horace.chen@amd.com> Signed-off-by:
-
Aric Cyr authored
Signed-off-by:
Aric Cyr <aric.cyr@amd.com> Acked-by:
Stylon Wang <stylon.wang@amd.com> Tested-by:
Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by:
-
Wyatt Wood authored
Signed-off-by:
Wyatt Wood <wyatt.wood@amd.com> Reviewed-by:
-
Po-Ting Chen authored
[Why] To support a new visual confirm mode: swizzle to show the specific color at the screen border according to different surface swizzle mode. Currently we only support the Linear mode with red color. Signed-off-by:
Po-Ting Chen <robin.chen@amd.com> Acked-by:
-
Dingchen (David) Zhang authored
[WHY] - Commit from userspace could cause link stream to disable and hdcp auth to reset when the HDCP has already been enabled at the moment. CP should fall back to DESIRED from ENABLED in such cases. - This change was previously reverted due to a regression caused, which has now been cleared. [HOW] In hdcp display removal, change CP to DESIRED if at the moment CP is ENABLED before the auth reset and removal of linked list element. Signed-off-by:
Dingchen (David) Zhang <dingchen.zhang@amd.com> Signed-off-by:
Qingqing Zhuo <qingqing.zhuo@amd.com> Reviewed-by:
Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by:
-
Eric Bernstein authored
[Why] There is an assert in cases where transition from ODM 2:1 to ODM 1:1 (bypass) [How] Remove assert since this case is now valid. Update diags tests for ODM transitions. Signed-off-by:
Eric Bernstein <eric.bernstein@amd.com> Reviewed-by:
Dmytro Laktyushkin <Dmytro.Laktyushkin@amd.com> Acked-by:
-
Roy Chan authored
[Why] Found a use case (IPKVM) that DP-VGA active dongle does not return any EDID and the mentioned commit broke it. [How] This reverts "Disconnect non-DP with no EDID" Signed-off-by:
Roy Chan <roy.chan@amd.com> Reviewed-by:
Chris Park <Chris.Park@amd.com> Acked-by:
-
Fangzhi Zuo authored
[Why & How] Add debugfs entry to force dsc decoding at PCON when DSC capable external RX is connected. In such case, it is free to test DSC decoding at external RX or at PCON. Signed-off-by:
Fangzhi Zuo <Jerry.Zuo@amd.com> Reviewed-by:
Hersen Wu <hersenxs.wu@amd.com> Acked-by:
-
Aric Cyr authored
[Why] When calculating recout width for an MPO plane on a mode that's using ODM combine, driver can calculate a negative value, resulting in a crash. [How] For negative widths, use zero such that validation will prune the configuration correctly and disallow MPO. Signed-off-by:
Krunoslav Kovac <Krunoslav.Kovac@amd.com> Acked-by:
-
Wesley Chalmers authored
[WHY] For DCN30 and later, there is no data in DML arrays indexed by state at index num_states. Signed-off-by:
Wesley Chalmers <Wesley.Chalmers@amd.com> Reviewed-by:
-
Wesley Chalmers authored
[WHY] DISPCLK_MAX_ERRDET_CYCLES must be 7 to prevent connection loss when changing DENTIST_DISPCLK_WDIVIDER from 126 to 127 and back. Signed-off-by:
-
Wesley Chalmers authored
[WHY] HW has handed down a new sequence that requires access to these registers. v2: squash in DCN3.1 fixes (Alex) Signed-off-by:
-
Wesley Chalmers authored
[WHY] HW has handed down a new sequence which requires access to the FIFO ERRDET SW Override register. Signed-off-by:
-
