dri-devel April 2021

dri-devel@lists.freedesktop.org

317 participants
715 discussions

[PATCH 1/2] drm: Rename DP_PSR_SELECTIVE_UPDATE to better mach eDP spec
by José Roberto de Souza 23 Apr '21

23 Apr '21

DP_PSR_EN_CFG bit 5 aka "Selective Update Region Scan Line Capture Indication" in eDP spec has a ambiguous name, so renaming to better match specification. While at it, replacing bit shit by BIT() macro and adding the version some registers were added to eDP specification. Cc: <dri-devel(a)lists.freedesktop.org> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Jani Nikula <jani.nikula(a)intel.com> Cc: Gwan-gyeong Mun <gwan-gyeong.mun(a)intel.com> Signed-off-by: José Roberto de Souza <jose.souza(a)intel.com> --- include/drm/drm_dp_helper.h | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 1e85c2021f2f..d6f6a084a190 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -687,14 +687,14 @@ struct drm_device; #define DP_DSC_ENABLE 0x160 /* DP 1.4 */ # define DP_DECOMPRESSION_EN (1 << 0) -#define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ -# define DP_PSR_ENABLE (1 << 0) -# define DP_PSR_MAIN_LINK_ACTIVE (1 << 1) -# define DP_PSR_CRC_VERIFICATION (1 << 2) -# define DP_PSR_FRAME_CAPTURE (1 << 3) -# define DP_PSR_SELECTIVE_UPDATE (1 << 4) -# define DP_PSR_IRQ_HPD_WITH_CRC_ERRORS (1 << 5) -# define DP_PSR_ENABLE_PSR2 (1 << 6) /* eDP 1.4a */ +#define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ +# define DP_PSR_ENABLE BIT(0) +# define DP_PSR_MAIN_LINK_ACTIVE BIT(1) +# define DP_PSR_CRC_VERIFICATION BIT(2) +# define DP_PSR_FRAME_CAPTURE BIT(3) +# define DP_PSR_SU_REGION_SCANLINE_CAPTURE BIT(4) /* eDP 1.4a */ +# define DP_PSR_IRQ_HPD_WITH_CRC_ERRORS BIT(5) /* eDP 1.4a */ +# define DP_PSR_ENABLE_PSR2 BIT(6) /* eDP 1.4a */ #define DP_ADAPTER_CTRL 0x1a0 # define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE (1 << 0) -- 2.31.1

4 3

[PATCH 00/40] [Set 16] Rid W=1 warnings from GPU!
by Lee Jones 23 Apr '21

23 Apr '21

This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. Lee Jones (40): drm/nouveau/nvkm/subdev/bios/init: Demote obvious abuse of kernel-doc drm/nouveau/dispnv50/disp: Remove unused variable 'ret' drm/msm/dp/dp_display: Remove unused variable 'hpd' include: drm: drm_atomic: Make use of 'new_plane_state' drm/nouveau/nvkm/subdev/volt/gk20a: Demote non-conformant kernel-doc headers drm/nouveau/nvkm/engine/gr/gf100: Demote non-conformant kernel-doc header drm/nouveau/nouveau_bo: Remove unused variables 'dev' drm/nouveau/nouveau_display: Remove set but unused variable 'width' drm/nouveau/dispnv04/crtc: Demote non-conforming kernel-doc headers drm/nouveau/dispnv50/disp: Remove unused variable 'ret' from function returning void drm/nouveau/dispnv50/headc57d: Make local function 'headc57d_olut' static drm/nouveau/nv50_display: Remove superfluous prototype for local static functions drm/nouveau/dispnv50/disp: Include header containing our prototypes drm/nouveau/nouveau_ioc32: File headers are not good candidates for kernel-doc drm/nouveau/nouveau_svm: Remove unused variable 'ret' from void function drm/nouveau/nouveau_ioc32: Demote kernel-doc abuse to standard comment block gpu: host1x: bus: Remove superfluous param description 'key' drm/omapdrm/omap_irq: Fix a couple of incorrectly documented functions drm/omapdrm/omap_gem: Properly document omap_gem_dumb_map_offset() drm/xlnx/zynqmp_disp: Fix incorrectly documented enum 'zynqmp_disp_id' drm/xlnx/zynqmp_dp: Fix a little potential doc-rot drm/ttm/ttm_tt: Demote non-conformant kernel-doc header drm/ttm/ttm_bo: Fix incorrectly documented function 'ttm_bo_cleanup_refs' drm/scheduler/sched_entity: Fix some function name disparity drm/radeon/radeon_device: Provide function name in kernel-doc header drm/amd/amdgpu/amdgpu_device: Remove unused variable 'r' drm/ttm/ttm_device: Demote kernel-doc abuses drm/panel/panel-raspberrypi-touchscreen: Demote kernel-doc abuse drm/amd/amdgpu/amdgpu_fence: Provide description for 'sched_score' drm/vgem/vgem_drv: Demote kernel-doc abuse drm/amd/amdgpu/amdgpu_gart: Correct a couple of function names in the docs drm/amd/amdgpu/amdgpu_ttm: Fix incorrectly documented function 'amdgpu_ttm_copy_mem_to_mem()' drm/amd/amdgpu/amdgpu_ring: Provide description for 'sched_score' drm/exynos/exynos_drm_fimd: Realign function name with its header drm/amd/amdgpu/amdgpu_cs: Repair some function naming disparity drm/exynos/exynos7_drm_decon: Realign function name with its header drm/panel/panel-sitronix-st7701: Demote kernel-doc format abuse drm/exynos/exynos_drm_ipp: Fix some function name disparity issues drm/sti/sti_hdmi: Provide kernel-doc headers with function names drm/mediatek/mtk_disp_ccorr: Demote less than half-populated struct header drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 6 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 +- drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_gart.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 1 + drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +- drivers/gpu/drm/exynos/exynos7_drm_decon.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 2 +- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 4 +- drivers/gpu/drm/mediatek/mtk_disp_ccorr.c | 2 +- drivers/gpu/drm/msm/dp/dp_display.c | 3 - drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 +- drivers/gpu/drm/nouveau/dispnv50/disp.c | 10 +- drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 2 +- drivers/gpu/drm/nouveau/nouveau_bo.c | 4 - drivers/gpu/drm/nouveau/nouveau_display.c | 8 +- drivers/gpu/drm/nouveau/nouveau_ioc32.c | 4 +- drivers/gpu/drm/nouveau/nouveau_svm.c | 5 +- drivers/gpu/drm/nouveau/nv50_display.h | 3 - .../gpu/drm/nouveau/nvkm/engine/gr/gf100.c | 2 +- .../gpu/drm/nouveau/nvkm/subdev/bios/init.c | 204 ++++++------------ .../gpu/drm/nouveau/nvkm/subdev/volt/gk20a.c | 4 +- drivers/gpu/drm/omapdrm/omap_gem.c | 2 +- drivers/gpu/drm/omapdrm/omap_irq.c | 4 +- .../drm/panel/panel-raspberrypi-touchscreen.c | 2 +- drivers/gpu/drm/panel/panel-sitronix-st7701.c | 2 +- drivers/gpu/drm/radeon/radeon_device.c | 3 +- drivers/gpu/drm/scheduler/sched_entity.c | 6 +- drivers/gpu/drm/sti/sti_hdmi.c | 18 +- drivers/gpu/drm/ttm/ttm_bo.c | 2 +- drivers/gpu/drm/ttm/ttm_device.c | 4 +- drivers/gpu/drm/ttm/ttm_tt.c | 2 +- drivers/gpu/drm/vgem/vgem_drv.c | 2 +- drivers/gpu/drm/xlnx/zynqmp_disp.c | 2 +- drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +- drivers/gpu/host1x/bus.c | 1 - include/drm/drm_atomic.h | 3 +- 37 files changed, 130 insertions(+), 207 deletions(-) Cc: Adam Jackson <ajax(a)redhat.com> Cc: Ajay Kumar <ajaykumar.rs(a)samsung.com> Cc: Akshu Agarwal <akshua(a)gmail.com> Cc: Alex Deucher <alexander.deucher(a)amd.com> Cc: amd-gfx(a)lists.freedesktop.org Cc: Benjamin Gaignard <benjamin.gaignard(a)linaro.org> Cc: Ben Skeggs <bskeggs(a)redhat.com> Cc: Ben Widawsky <ben(a)bwidawsk.net> Cc: Christian Koenig <christian.koenig(a)amd.com> Cc: "Christian König" <christian.koenig(a)amd.com> Cc: Chun-Kuang Hu <chunkuang.hu(a)kernel.org> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: David Airlie <airlied(a)linux.ie> Cc: dri-devel(a)lists.freedesktop.org Cc: Eric Anholt <eric(a)anholt.net> Cc: freedreno(a)lists.freedesktop.org Cc: Huang Rui <ray.huang(a)amd.com> Cc: Hyun Kwon <hyun.kwon(a)xilinx.com> Cc: Inki Dae <inki.dae(a)samsung.com> Cc: Jagan Teki <jagan(a)amarulasolutions.com> Cc: Jeremy Kolb <jkolb(a)brandeis.edu> Cc: Jerome Glisse <glisse(a)freedesktop.org> Cc: Joonyoung Shim <jy0922.shim(a)samsung.com> Cc: Krzysztof Kozlowski <krzysztof.kozlowski(a)canonical.com> Cc: Kuogee Hsieh <khsieh(a)codeaurora.org> Cc: Kyungmin Park <kyungmin.park(a)samsung.com> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: linaro-mm-sig(a)lists.linaro.org Cc: linux-arm-kernel(a)lists.infradead.org Cc: linux-arm-msm(a)vger.kernel.org Cc: linux-mediatek(a)lists.infradead.org Cc: linux-media(a)vger.kernel.org Cc: linux-samsung-soc(a)vger.kernel.org Cc: linux-tegra(a)vger.kernel.org Cc: Lyude Paul <lyude(a)redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Marek Szyprowski <m.szyprowski(a)samsung.com> Cc: Matthias Brugger <matthias.bgg(a)gmail.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: Michal Simek <michal.simek(a)xilinx.com> Cc: Nirmoy Das <nirmoy.das(a)amd.com> Cc: nouveau(a)lists.freedesktop.org Cc: Philipp Zabel <p.zabel(a)pengutronix.de> Cc: Rob Clark <rob.clark(a)linaro.org> Cc: Rob Clark <robdclark(a)gmail.com> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: Sean Paul <sean(a)poorly.run> Cc: Seung-Woo Kim <sw0312.kim(a)samsung.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Thierry Reding <thierry.reding(a)gmail.com> Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Tomi Valkeinen <tomba(a)kernel.org> Cc: Vincent Abriou <vincent.abriou(a)st.com> -- 2.27.0

9 84

[RFC PATCH 1/3] dt-bindings: display: simple: Add the panel on sc7180-trogdor-pompom
by Douglas Anderson 23 Apr '21

23 Apr '21

The sc7180-trogdor-pompom board might be attached to any number of a pile of eDP panels. At the moment I'm told that the list might include: - KD KD116N21-30NV-A010 - KD KD116N09-30NH-A016 - Starry 2081116HHD028001-51D - Sharp LQ116M1JW10 It should be noted that while the EDID programmed in the first 3 panels indicates that they should run with exactly the same timing (to keep things simple), the 4th panel not only needs different timing but has a different resolution. As is true in general with eDP panels, we can figure out which panel we have and all the info needed to drive its pixel clock by reading the EDID. However, we can do this only after we've powered the panel on. Powering on the panels requires following the timing diagram in each panel's datasheet which specifies delays between certain actions. This means that, while we can be quite dynamic about handling things we can't just totally skip out on describing the panel like we could do if it was connected to an external-facing DP port. While the different panels have slightly different delays, it's possible to come up with a set of unified delays that will work on all the panels. From reading the datasheets: * KD KD116N21-30NV-A010 and KD KD116N09-30NH-A016 - HPD absent delay: 200 ms - Unprepare delay: 150 ms (datasheet is confusing, might be 500 ms) * Starry 2081116HHD028001-51D - HPD absent delay: 100 ms - Enable delay: (link training done till enable BL): 200 ms - Unprepare delay: 500 ms * Sharp LQ116M1JW10 - HPD absent delay: 200 ms - Unprepare delay: 500 ms - Prepare to enable delay (power on till backlight): 100 ms Unified: - HPD absent delay: 200 ms - Unprepare delay: 500 ms - Enable delay: 200 ms NOTE: in theory the only thing that we _really_ need unity on is the "HPD absent delay" since once the panel asserts HPD we can read the EDID and could make per-panel decisions if we wanted. Let's create a definition of "a panel that can be attached to pompom" as a panel that provides a valid EDID and can work with the standard pompom power sequencing. If more panels are later attached to pompom then it's fine as long as they work in a compatible way. One might ask why we can't just use a generic string here and provide the timings directly in the device tree file. As I understand it, trying to describe generic power sequencing in the device tree is frowned upon and the one instance (SD/MMC) is regarded as a mistake that shouldn't be repeated. Specifying a power sequence per board (or per board class) feels like a reasonable compromise. We're not trying to define fully generic power sequence bindings but we can also take advantage of the semi-probable properties of the attached device. NOTE: I believe that past instances of supporting this type of thing have used the "white lie" approach. One representative panel was listed in the device tree. The power sequencings of this representative panel were OK to use across all panels that might be attached and other differences were handled by EDID. This patch attempts to set a new precedent and avoid the need for the white lie. Signed-off-by: Douglas Anderson <dianders(a)chromium.org> --- .../devicetree/bindings/display/panel/panel-simple.yaml | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 62b0d54d87b7..9807dbc1cceb 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -140,6 +140,10 @@ properties: - giantplus,gpg48273qs5 # GiantPlus GPM940B0 3.0" QVGA TFT LCD panel - giantplus,gpm940b0 + # A panel connected to a google,pompom board. Panel is guaranteed to + # confirm to google,pompom-panel power sequencing requirements and then + # the specific panel will be probed via EDID. + - google,pompom-panel # HannStar Display Corp. HSD070PWW1 7.0" WXGA TFT LCD panel - hannstar,hsd070pww1 # HannStar Display Corp. HSD100PXN1 10.1" XGA LVDS panel -- 2.31.0.rc2.261.g7f71774620-goog

8 19

[PATCH] drm/i915: Fix docbook descriptions for i915_cmd_parser
by Maarten Lankhorst 23 Apr '21

23 Apr '21

Fixes the following htmldocs warnings: drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'jump_whitelist' not described in 'intel_engine_cmd_parser' drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'shadow_map' not described in 'intel_engine_cmd_parser' drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Function parameter or member 'batch_map' not described in 'intel_engine_cmd_parser' drivers/gpu/drm/i915/i915_cmd_parser.c:1420: warning: Excess function parameter 'trampoline' description in 'intel_engine_cmd_parser' Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au> Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> --- drivers/gpu/drm/i915/i915_cmd_parser.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c index e6f1e93abbbb..afb9b7516999 100644 --- a/drivers/gpu/drm/i915/i915_cmd_parser.c +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c @@ -1369,6 +1369,18 @@ static int check_bbstart(u32 *cmd, u32 offset, u32 length, return 0; } +/** + * intel_engine_cmd_parser_alloc_jump_whitelist() - preallocate jump whitelist for intel_engine_cmd_parser() + * @batch_length: length of the commands in batch_obj + * @trampoline: Whether jump trampolines are used. + * + * Preallocates a jump whitelist for parsing the cmd buffer in intel_engine_cmd_parser(). + * This has to be preallocated, because the command parser runs in signaling context, + * and may not allocate any memory. + * + * Return: NULL or pointer to a jump whitelist, or ERR_PTR() on failure. Use + * IS_ERR() to check for errors. Must bre freed() with kfree(). + */ unsigned long *intel_engine_cmd_parser_alloc_jump_whitelist(u32 batch_length, bool trampoline) { @@ -1401,7 +1413,9 @@ unsigned long *intel_engine_cmd_parser_alloc_jump_whitelist(u32 batch_length, * @batch_offset: byte offset in the batch at which execution starts * @batch_length: length of the commands in batch_obj * @shadow: validated copy of the batch buffer in question - * @trampoline: whether to emit a conditional trampoline at the end of the batch + * @jump_whitelist: buffer preallocated with intel_engine_cmd_parser_alloc_jump_whitelist() + * @shadow_map: mapping to @shadow vma + * @batch_map: mapping to @batch vma * * Parses the specified batch buffer looking for privilege violations as * described in the overview. -- 2.31.0

3 4

[PATCH v2] drm/bridge: nwl-dsi: Get MIPI DSI controller and PHY ready in ->mode_set()
by Liu Ying 23 Apr '21

23 Apr '21

Some MIPI DSI panel drivers like 'raydium,rm68200' send MIPI_DCS_SET_DISPLAY_ON commands in panel_funcs->prepare(), which requires the MIPI DSI controller and PHY to be ready beforehand. Without this patch, the nwl-dsi driver gets the MIPI DSI controller and PHY ready in bridge_funcs->pre_enable(), which happens after the panel_funcs->prepare(). So, this patch shifts the bridge operation ealier from bridge_funcs->pre_enable() to bridge_funcs->mode_set(). This way, more MIPI DSI panels can connect to this nwl-dsi bridge. Care is taken to make sure bridge_funcs->mode_set()/atomic_disable() are called in pairs, which includes removing a check on unchanged HS clock rate and forcing a full modeset when only connector's DPMS is brought out of "Off" status. Cc: Andrzej Hajda <a.hajda(a)samsung.com> Cc: Neil Armstrong <narmstrong(a)baylibre.com> Cc: Robert Foss <robert.foss(a)linaro.org> Cc: Laurent Pinchart <Laurent.pinchart(a)ideasonboard.com> Cc: Jonas Karlman <jonas(a)kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec(a)siol.net> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: Guido Günther <agx(a)sigxcpu.org> Cc: Robert Chiras <robert.chiras(a)nxp.com> Cc: NXP Linux Team <linux-imx(a)nxp.com> Signed-off-by: Liu Ying <victor.liu(a)nxp.com> --- v1->v2: * Fix commit message typo - s/unchange/unchanged/ drivers/gpu/drm/bridge/nwl-dsi.c | 86 +++++++++++++++++++++------------------- 1 file changed, 46 insertions(+), 40 deletions(-) diff --git a/drivers/gpu/drm/bridge/nwl-dsi.c b/drivers/gpu/drm/bridge/nwl-dsi.c index be6bfc5..229f0b1 100644 --- a/drivers/gpu/drm/bridge/nwl-dsi.c +++ b/drivers/gpu/drm/bridge/nwl-dsi.c @@ -21,6 +21,7 @@ #include <linux/sys_soc.h> #include <linux/time64.h> +#include <drm/drm_atomic_state_helper.h> #include <drm/drm_bridge.h> #include <drm/drm_mipi_dsi.h> #include <drm/drm_of.h> @@ -661,7 +662,7 @@ static irqreturn_t nwl_dsi_irq_handler(int irq, void *data) return IRQ_HANDLED; } -static int nwl_dsi_enable(struct nwl_dsi *dsi) +static int nwl_dsi_mode_set(struct nwl_dsi *dsi) { struct device *dev = dsi->dev; union phy_configure_opts *phy_cfg = &dsi->phy_cfg; @@ -748,7 +749,9 @@ static int nwl_dsi_disable(struct nwl_dsi *dsi) return 0; } -static void nwl_dsi_bridge_disable(struct drm_bridge *bridge) +static void +nwl_dsi_bridge_atomic_disable(struct drm_bridge *bridge, + struct drm_bridge_state *old_bridge_state) { struct nwl_dsi *dsi = bridge_to_dsi(bridge); int ret; @@ -809,17 +812,6 @@ static int nwl_dsi_get_dphy_params(struct nwl_dsi *dsi, return 0; } -static bool nwl_dsi_bridge_mode_fixup(struct drm_bridge *bridge, - const struct drm_display_mode *mode, - struct drm_display_mode *adjusted_mode) -{ - /* At least LCDIF + NWL needs active high sync */ - adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC); - adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC); - - return true; -} - static enum drm_mode_status nwl_dsi_bridge_mode_valid(struct drm_bridge *bridge, const struct drm_display_info *info, @@ -837,6 +829,29 @@ nwl_dsi_bridge_mode_valid(struct drm_bridge *bridge, return MODE_OK; } +static int nwl_dsi_bridge_atomic_check(struct drm_bridge *bridge, + struct drm_bridge_state *bridge_state, + struct drm_crtc_state *crtc_state, + struct drm_connector_state *conn_state) +{ + struct drm_display_mode *adjusted_mode = &crtc_state->adjusted_mode; + + /* At least LCDIF + NWL needs active high sync */ + adjusted_mode->flags |= (DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC); + adjusted_mode->flags &= ~(DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC); + + /* + * Do a full modeset if crtc_state->active is changed to be true. + * This ensures our ->mode_set() is called to get the DSI controller + * and the PHY ready to send DCS commands, when only the connector's + * DPMS is brought out of "Off" status. + */ + if (crtc_state->active_changed && crtc_state->active) + crtc_state->mode_changed = true; + + return 0; +} + static void nwl_dsi_bridge_mode_set(struct drm_bridge *bridge, const struct drm_display_mode *mode, @@ -852,13 +867,6 @@ nwl_dsi_bridge_mode_set(struct drm_bridge *bridge, if (ret < 0) return; - /* - * If hs clock is unchanged, we're all good - all parameters are - * derived from it atm. - */ - if (new_cfg.mipi_dphy.hs_clk_rate == dsi->phy_cfg.mipi_dphy.hs_clk_rate) - return; - phy_ref_rate = clk_get_rate(dsi->phy_ref_clk); DRM_DEV_DEBUG_DRIVER(dev, "PHY at ref rate: %lu\n", phy_ref_rate); /* Save the new desired phy config */ @@ -866,14 +874,8 @@ nwl_dsi_bridge_mode_set(struct drm_bridge *bridge, memcpy(&dsi->mode, adjusted_mode, sizeof(dsi->mode)); drm_mode_debug_printmodeline(adjusted_mode); -} -static void nwl_dsi_bridge_pre_enable(struct drm_bridge *bridge) -{ - struct nwl_dsi *dsi = bridge_to_dsi(bridge); - int ret; - - pm_runtime_get_sync(dsi->dev); + pm_runtime_get_sync(dev); if (clk_prepare_enable(dsi->lcdif_clk) < 0) return; @@ -883,27 +885,29 @@ static void nwl_dsi_bridge_pre_enable(struct drm_bridge *bridge) /* Step 1 from DSI reset-out instructions */ ret = reset_control_deassert(dsi->rst_pclk); if (ret < 0) { - DRM_DEV_ERROR(dsi->dev, "Failed to deassert PCLK: %d\n", ret); + DRM_DEV_ERROR(dev, "Failed to deassert PCLK: %d\n", ret); return; } /* Step 2 from DSI reset-out instructions */ - nwl_dsi_enable(dsi); + nwl_dsi_mode_set(dsi); /* Step 3 from DSI reset-out instructions */ ret = reset_control_deassert(dsi->rst_esc); if (ret < 0) { - DRM_DEV_ERROR(dsi->dev, "Failed to deassert ESC: %d\n", ret); + DRM_DEV_ERROR(dev, "Failed to deassert ESC: %d\n", ret); return; } ret = reset_control_deassert(dsi->rst_byte); if (ret < 0) { - DRM_DEV_ERROR(dsi->dev, "Failed to deassert BYTE: %d\n", ret); + DRM_DEV_ERROR(dev, "Failed to deassert BYTE: %d\n", ret); return; } } -static void nwl_dsi_bridge_enable(struct drm_bridge *bridge) +static void +nwl_dsi_bridge_atomic_enable(struct drm_bridge *bridge, + struct drm_bridge_state *old_bridge_state) { struct nwl_dsi *dsi = bridge_to_dsi(bridge); int ret; @@ -948,14 +952,16 @@ static void nwl_dsi_bridge_detach(struct drm_bridge *bridge) } static const struct drm_bridge_funcs nwl_dsi_bridge_funcs = { - .pre_enable = nwl_dsi_bridge_pre_enable, - .enable = nwl_dsi_bridge_enable, - .disable = nwl_dsi_bridge_disable, - .mode_fixup = nwl_dsi_bridge_mode_fixup, - .mode_set = nwl_dsi_bridge_mode_set, - .mode_valid = nwl_dsi_bridge_mode_valid, - .attach = nwl_dsi_bridge_attach, - .detach = nwl_dsi_bridge_detach, + .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state, + .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state, + .atomic_reset = drm_atomic_helper_bridge_reset, + .atomic_check = nwl_dsi_bridge_atomic_check, + .atomic_enable = nwl_dsi_bridge_atomic_enable, + .atomic_disable = nwl_dsi_bridge_atomic_disable, + .mode_set = nwl_dsi_bridge_mode_set, + .mode_valid = nwl_dsi_bridge_mode_valid, + .attach = nwl_dsi_bridge_attach, + .detach = nwl_dsi_bridge_detach, }; static int nwl_dsi_parse_dt(struct nwl_dsi *dsi) -- 2.7.4

2 4

[PATCH] gpu: drm: Use devm_platform_ioremap_resource_byname
by dingsenjie＠163.com 23 Apr '21

23 Apr '21

From: dingsenjie <dingsenjie(a)yulong.com> Use the devm_platform_ioremap_resource_byname() helper instead of calling platform_get_resource_byname() and devm_ioremap_resource() separately. Signed-off-by: dingsenjie <dingsenjie(a)yulong.com> --- drivers/gpu/drm/zte/zx_vou.c | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c index 904f62f..ba50ddf 100644 --- a/drivers/gpu/drm/zte/zx_vou.c +++ b/drivers/gpu/drm/zte/zx_vou.c @@ -764,7 +764,6 @@ static int zx_crtc_bind(struct device *dev, struct device *master, void *data) struct platform_device *pdev = to_platform_device(dev); struct drm_device *drm = data; struct zx_vou_hw *vou; - struct resource *res; int irq; int ret; @@ -772,16 +771,14 @@ static int zx_crtc_bind(struct device *dev, struct device *master, void *data) if (!vou) return -ENOMEM; - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "osd"); - vou->osd = devm_ioremap_resource(dev, res); + vou->osd = devm_platform_ioremap_resource_byname(pdev, "osd"); if (IS_ERR(vou->osd)) { ret = PTR_ERR(vou->osd); DRM_DEV_ERROR(dev, "failed to remap osd region: %d\n", ret); return ret; } - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "timing_ctrl"); - vou->timing = devm_ioremap_resource(dev, res); + vou->timing = devm_platform_ioremap_resource_byname(pdev, "timing_ctrl"); if (IS_ERR(vou->timing)) { ret = PTR_ERR(vou->timing); DRM_DEV_ERROR(dev, "failed to remap timing_ctrl region: %d\n", @@ -789,16 +786,14 @@ static int zx_crtc_bind(struct device *dev, struct device *master, void *data) return ret; } - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "dtrc"); - vou->dtrc = devm_ioremap_resource(dev, res); + vou->dtrc = devm_platform_ioremap_resource_byname(pdev, "dtrc"); if (IS_ERR(vou->dtrc)) { ret = PTR_ERR(vou->dtrc); DRM_DEV_ERROR(dev, "failed to remap dtrc region: %d\n", ret); return ret; } - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "vou_ctrl"); - vou->vouctl = devm_ioremap_resource(dev, res); + vou->vouctl = devm_platform_ioremap_resource_byname(pdev, "vou_ctrl"); if (IS_ERR(vou->vouctl)) { ret = PTR_ERR(vou->vouctl); DRM_DEV_ERROR(dev, "failed to remap vou_ctrl region: %d\n", @@ -806,8 +801,7 @@ static int zx_crtc_bind(struct device *dev, struct device *master, void *data) return ret; } - res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "otfppu"); - vou->otfppu = devm_ioremap_resource(dev, res); + vou->otfppu = devm_platform_ioremap_resource_byname(pdev, "otfppu"); if (IS_ERR(vou->otfppu)) { ret = PTR_ERR(vou->otfppu); DRM_DEV_ERROR(dev, "failed to remap otfppu region: %d\n", ret); -- 1.9.1

1 0

[PATCH RESEND] drm: bridge: adv7511: Support I2S IEC958 encoded PCM format
by Sia Jee Heng 23 Apr '21

23 Apr '21

Support IEC958 encoded PCM format for ADV7511 so that ADV7511 HDMI audio driver can accept the IEC958 data from the I2S input. Signed-off-by: Sia Jee Heng <jee.heng.sia(a)intel.com> Reviewed-by: Robert Foss <robert.foss(a)linaro.org> --- drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 + drivers/gpu/drm/bridge/adv7511/adv7511_audio.c | 6 ++++++ 2 files changed, 7 insertions(+) diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h b/drivers/gpu/drm/bridge/adv7511/adv7511.h index a9bb734366ae..05e3abb5a0c9 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511.h +++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h @@ -191,6 +191,7 @@ #define ADV7511_I2S_FORMAT_I2S 0 #define ADV7511_I2S_FORMAT_RIGHT_J 1 #define ADV7511_I2S_FORMAT_LEFT_J 2 +#define ADV7511_I2S_IEC958_DIRECT 3 #define ADV7511_PACKET(p, x) ((p) * 0x20 + (x)) #define ADV7511_PACKET_SDP(x) ADV7511_PACKET(0, x) diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c index 45838bd08d37..61f4a38e7d2b 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_audio.c @@ -101,6 +101,10 @@ static int adv7511_hdmi_hw_params(struct device *dev, void *data, case 20: len = ADV7511_I2S_SAMPLE_LEN_20; break; + case 32: + if (fmt->bit_fmt != SNDRV_PCM_FORMAT_IEC958_SUBFRAME_LE) + return -EINVAL; + fallthrough; case 24: len = ADV7511_I2S_SAMPLE_LEN_24; break; @@ -112,6 +116,8 @@ static int adv7511_hdmi_hw_params(struct device *dev, void *data, case HDMI_I2S: audio_source = ADV7511_AUDIO_SOURCE_I2S; i2s_format = ADV7511_I2S_FORMAT_I2S; + if (fmt->bit_fmt == SNDRV_PCM_FORMAT_IEC958_SUBFRAME_LE) + i2s_format = ADV7511_I2S_IEC958_DIRECT; break; case HDMI_RIGHT_J: audio_source = ADV7511_AUDIO_SOURCE_I2S; base-commit: e488b1023a4a4eab15b905871cf8e81f00336ed7 -- 2.18.0

2 1

[PATCH v6 1/4] mfd: rt4831: Adds support for Richtek RT4831
by cy_huang 23 Apr '21

23 Apr '21

From: ChiYuan Huang <cy_huang(a)richtek.com> This adds support Richtek RT4831 core. It includes four channel WLED driver and Display Bias Voltage outputs. Signed-off-by: ChiYuan Huang <cy_huang(a)richtek.com> --- The RT4831 regulator patches are already on main stream, and can be referred to 9351ab8b0cb6 regulator: rt4831: Adds support for Richtek RT4831 DSV regulator 934b05e81862 regulator: rt4831: Adds DT binding document for Richtek RT4831 DSV regulator since v6 - Respin the date from 2020 to 2021. - Rmove the shutdown routine. - Change the macro OF_MFD_CELL to MFD_CELL_OF. since v5 - Rename file name from rt4831-core.c to rt4831.c - Change RICHTEK_VID to RICHTEK_VENDOR_ID. - Change gpio_desc nameing from 'enable' to 'enable_gpio' in probe. - Change variable 'val' to the meaningful name 'chip_id'. - Refine the error log when vendor id is not matched. - Remove of_match_ptr. since v2 - Refine Kconfig descriptions. - Add copyright. - Refine error logs in probe. - Refine comment lines in remove and shutdown. --- drivers/mfd/Kconfig | 10 +++++ drivers/mfd/Makefile | 1 + drivers/mfd/rt4831.c | 115 +++++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 126 insertions(+) create mode 100644 drivers/mfd/rt4831.c diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig index b74efa4..3f43834 100644 --- a/drivers/mfd/Kconfig +++ b/drivers/mfd/Kconfig @@ -1065,6 +1065,16 @@ config MFD_RDC321X southbridge which provides access to GPIOs and Watchdog using the southbridge PCI device configuration space. +config MFD_RT4831 + tristate "Richtek RT4831 four channel WLED and Display Bias Voltage" + depends on I2C + select MFD_CORE + select REGMAP_I2C + help + This enables support for the Richtek RT4831 that includes 4 channel + WLED driving and Display Bias Voltage. It's commonly used to provide + power to the LCD display and LCD backlight. + config MFD_RT5033 tristate "Richtek RT5033 Power Management IC" depends on I2C diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile index 834f546..5986914 100644 --- a/drivers/mfd/Makefile +++ b/drivers/mfd/Makefile @@ -235,6 +235,7 @@ obj-$(CONFIG_MFD_MENF21BMC) += menf21bmc.o obj-$(CONFIG_MFD_HI6421_PMIC) += hi6421-pmic-core.o obj-$(CONFIG_MFD_HI655X_PMIC) += hi655x-pmic.o obj-$(CONFIG_MFD_DLN2) += dln2.o +obj-$(CONFIG_MFD_RT4831) += rt4831.o obj-$(CONFIG_MFD_RT5033) += rt5033.o obj-$(CONFIG_MFD_SKY81452) += sky81452.o diff --git a/drivers/mfd/rt4831.c b/drivers/mfd/rt4831.c new file mode 100644 index 00000000..b169781 --- /dev/null +++ b/drivers/mfd/rt4831.c @@ -0,0 +1,115 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (c) 2021 Richtek Technology Corp. + * + * Author: ChiYuan Huang <cy_huang(a)richtek.com> + */ + +#include <linux/gpio/consumer.h> +#include <linux/i2c.h> +#include <linux/kernel.h> +#include <linux/mfd/core.h> +#include <linux/module.h> +#include <linux/regmap.h> + +#define RT4831_REG_REVISION 0x01 +#define RT4831_REG_ENABLE 0x08 +#define RT4831_REG_I2CPROT 0x15 + +#define RICHTEK_VENDOR_ID 0x03 +#define RT4831_VID_MASK GENMASK(1, 0) +#define RT4831_RESET_MASK BIT(7) +#define RT4831_I2CSAFETMR_MASK BIT(0) + +static const struct mfd_cell rt4831_subdevs[] = { + MFD_CELL_OF("rt4831-backlight", NULL, NULL, 0, 0, "richtek,rt4831-backlight"), + MFD_CELL_NAME("rt4831-regulator") +}; + +static bool rt4831_is_accessible_reg(struct device *dev, unsigned int reg) +{ + if (reg >= RT4831_REG_REVISION && reg <= RT4831_REG_I2CPROT) + return true; + return false; +} + +static const struct regmap_config rt4831_regmap_config = { + .reg_bits = 8, + .val_bits = 8, + .max_register = RT4831_REG_I2CPROT, + + .readable_reg = rt4831_is_accessible_reg, + .writeable_reg = rt4831_is_accessible_reg, +}; + +static int rt4831_probe(struct i2c_client *client) +{ + struct gpio_desc *enable_gpio; + struct regmap *regmap; + unsigned int chip_id; + int ret; + + enable_gpio = devm_gpiod_get_optional(&client->dev, "enable", GPIOD_OUT_HIGH); + if (IS_ERR(enable_gpio)) { + dev_err(&client->dev, "Failed to get 'enable' GPIO\n"); + return PTR_ERR(enable_gpio); + } + + regmap = devm_regmap_init_i2c(client, &rt4831_regmap_config); + if (IS_ERR(regmap)) { + dev_err(&client->dev, "Failed to initialize regmap\n"); + return PTR_ERR(regmap); + } + + ret = regmap_read(regmap, RT4831_REG_REVISION, &chip_id); + if (ret) { + dev_err(&client->dev, "Failed to get H/W revision\n"); + return ret; + } + + if ((chip_id & RT4831_VID_MASK) != RICHTEK_VENDOR_ID) { + dev_err(&client->dev, "Chip vendor ID 0x%02x not matched\n", chip_id); + return -ENODEV; + } + + /* + * Used to prevent the abnormal shutdown. + * If SCL/SDA both keep low for one second to reset HW. + */ + ret = regmap_update_bits(regmap, RT4831_REG_I2CPROT, RT4831_I2CSAFETMR_MASK, + RT4831_I2CSAFETMR_MASK); + if (ret) { + dev_err(&client->dev, "Failed to enable I2C safety timer\n"); + return ret; + } + + return devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_AUTO, rt4831_subdevs, + ARRAY_SIZE(rt4831_subdevs), NULL, 0, NULL); +} + +static int rt4831_remove(struct i2c_client *client) +{ + struct regmap *regmap = dev_get_regmap(&client->dev, NULL); + + /* Disable WLED and DSV outputs */ + return regmap_update_bits(regmap, RT4831_REG_ENABLE, RT4831_RESET_MASK, RT4831_RESET_MASK); +} + +static const struct of_device_id __maybe_unused rt4831_of_match[] = { + { .compatible = "richtek,rt4831", }, + {} +}; +MODULE_DEVICE_TABLE(of, rt4831_of_match); + +static struct i2c_driver rt4831_driver = { + .driver = { + .name = "rt4831", + .of_match_table = rt4831_of_match, + }, + .probe_new = rt4831_probe, + .remove = rt4831_remove, +}; +module_i2c_driver(rt4831_driver); + +MODULE_AUTHOR("ChiYuan Huang <cy_huang(a)richtek.com>"); +MODULE_LICENSE("GPL v2"); -- 2.7.4

4 13

[PATCH 1/2] coda: fix reference counting in coda_file_mmap error path
by Christian König 23 Apr '21

23 Apr '21

mmap_region() now calls fput() on the vma->vm_file. So we need to drop the extra reference on the coda file instead of the host file. Signed-off-by: Christian König <christian.koenig(a)amd.com> Fixes: 1527f926fd04 ("mm: mmap: fix fput in error path v2") CC: stable(a)vger.kernel.org # 5.11+ --- fs/coda/file.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/fs/coda/file.c b/fs/coda/file.c index 128d63df5bfb..ef5ca22bfb3e 100644 --- a/fs/coda/file.c +++ b/fs/coda/file.c @@ -175,10 +175,10 @@ coda_file_mmap(struct file *coda_file, struct vm_area_struct *vma) ret = call_mmap(vma->vm_file, vma); if (ret) { - /* if call_mmap fails, our caller will put coda_file so we - * should drop the reference to the host_file that we got. + /* if call_mmap fails, our caller will put host_file so we + * should drop the reference to the coda_file that we got. */ - fput(host_file); + fput(coda_file); kfree(cvm_ops); } else { /* here we add redirects for the open/close vm_operations */ -- 2.25.1

3 7

[PATCH v4] drm/doc/rfc: i915 DG1 uAPI
by Matthew Auld 23 Apr '21

23 Apr '21

Add an entry for the new uAPI needed for DG1. Also add the overall upstream plan, including some notes for the TTM conversion. v2(Daniel): - include the overall upstreaming plan - add a note for mmap, there are differences here for TTM vs i915 - bunch of other suggestions from Daniel v3: (Daniel) - add a note for set/get caching stuff - add some more docs for existing query and extensions stuff - add an actual code example for regions query - bunch of other stuff (Jason) - uAPI change(!): - try a simpler design with the placements extension - rather than have a generic setparam which can cover multiple use cases, have each extension be responsible for one thing only v4: (Daniel) - add some more notes for ttm conversion - bunch of other stuff (Jason) - uAPI change(!): - drop all the extra rsvd members for the region_query and region_info, just keep the bare minimum needed for padding Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Thomas Hellström <thomas.hellstrom(a)linux.intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio(a)intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin(a)linux.intel.com> Cc: Jon Bloomfield <jon.bloomfield(a)intel.com> Cc: Jordan Justen <jordan.l.justen(a)intel.com> Cc: Daniel Vetter <daniel.vetter(a)intel.com> Cc: Kenneth Graunke <kenneth(a)whitecape.org> Cc: Jason Ekstrand <jason(a)jlekstrand.net> Cc: Dave Airlie <airlied(a)gmail.com> Cc: dri-devel(a)lists.freedesktop.org Cc: mesa-dev(a)lists.freedesktop.org Acked-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- Documentation/gpu/rfc/i915_gem_lmem.h | 212 ++++++++++++++++++++++++ Documentation/gpu/rfc/i915_gem_lmem.rst | 130 +++++++++++++++ Documentation/gpu/rfc/index.rst | 4 + 3 files changed, 346 insertions(+) create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.h create mode 100644 Documentation/gpu/rfc/i915_gem_lmem.rst diff --git a/Documentation/gpu/rfc/i915_gem_lmem.h b/Documentation/gpu/rfc/i915_gem_lmem.h new file mode 100644 index 000000000000..7ed59b6202d5 --- /dev/null +++ b/Documentation/gpu/rfc/i915_gem_lmem.h @@ -0,0 +1,212 @@ +/** + * enum drm_i915_gem_memory_class - Supported memory classes + */ +enum drm_i915_gem_memory_class { + /** @I915_MEMORY_CLASS_SYSTEM: System memory */ + I915_MEMORY_CLASS_SYSTEM = 0, + /** @I915_MEMORY_CLASS_DEVICE: Device local-memory */ + I915_MEMORY_CLASS_DEVICE, +}; + +/** + * struct drm_i915_gem_memory_class_instance - Identify particular memory region + */ +struct drm_i915_gem_memory_class_instance { + /** @memory_class: See enum drm_i915_gem_memory_class */ + __u16 memory_class; + + /** @memory_instance: Which instance */ + __u16 memory_instance; +}; + +/** + * struct drm_i915_memory_region_info - Describes one region as known to the + * driver. + * + * Note that we reserve some stuff here for potential future work. As an example + * we might want expose the capabilities(see @caps) for a given region, which + * could include things like if the region is CPU mappable/accessible, what are + * the supported mapping types etc. + * + * Note this is using both struct drm_i915_query_item and struct drm_i915_query. + * For this new query we are adding the new query id DRM_I915_QUERY_MEMORY_REGIONS + * at &drm_i915_query_item.query_id. + */ +struct drm_i915_memory_region_info { + /** @region: The class:instance pair encoding */ + struct drm_i915_gem_memory_class_instance region; + + /** @pad: MBZ */ + __u32 pad; + + /** @caps: MBZ */ + __u64 caps; + + /** @probed_size: Memory probed by the driver (-1 = unknown) */ + __u64 probed_size; + + /** @unallocated_size: Estimate of memory remaining (-1 = unknown) */ + __u64 unallocated_size; +}; + +/** + * struct drm_i915_query_memory_regions + * + * The region info query enumerates all regions known to the driver by filling + * in an array of struct drm_i915_memory_region_info structures. + * + * Example for getting the list of supported regions: + * + * .. code-block:: C + * + * struct drm_i915_query_memory_regions *info; + * struct drm_i915_query_item item = { + * .query_id = DRM_I915_QUERY_MEMORY_REGIONS; + * }; + * struct drm_i915_query query = { + * .num_items = 1, + * .items_ptr = (uintptr_t)&item, + * }; + * int err, i; + * + * // First query the size of the blob we need, this needs to be large + * // enough to hold our array of regions. The kernel will fill out the + * // item.length for us, which is the number of bytes we need. + * err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query); + * if (err) ... + * + * info = calloc(1, item.length); + * // Now that we allocated the required number of bytes, we call the ioctl + * // again, this time with the data_ptr pointing to our newly allocated + * // blob, which the kernel can then populate with the all the region info. + * item.data_ptr = (uintptr_t)&info, + * + * err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query); + * if (err) ... + * + * // We can now access each region in the array + * for (i = 0; i < info->num_regions; i++) { + * struct drm_i915_memory_region_info mr = info->regions[i]; + * u16 class = mr.region.class; + * u16 instance = mr.region.instance; + * + * .... + * } + * + * free(info); + */ +struct drm_i915_query_memory_regions { + /** @num_regions: Number of supported regions */ + __u32 num_regions; + + /** @pad: MBZ */ + __u32 pad; + + /** @regions: Info about each supported region */ + struct drm_i915_memory_region_info regions[]; +}; + +#define DRM_I915_GEM_CREATE_EXT 0xdeadbeaf +#define DRM_IOCTL_I915_GEM_CREATE_EXT DRM_IOWR(DRM_COMMAND_BASE + DRM_I915_GEM_CREATE_EXT, struct drm_i915_gem_create_ext) + +/** + * struct drm_i915_gem_create_ext - Existing gem_create behaviour, with added + * extension support using struct i915_user_extension. + * + * Note that in the future we want to have our buffer flags here, at least for + * the stuff that is immutable. Previously we would have two ioctls, one to + * create the object with gem_create, and another to apply various parameters, + * however this creates some ambiguity for the params which are considered + * immutable. Also in general we're phasing out the various SET/GET ioctls. + */ +struct drm_i915_gem_create_ext { + /** + * @size: Requested size for the object. + * + * The (page-aligned) allocated size for the object will be returned. + * + * Note that for some devices we have might have further minimum + * page-size restrictions(larger than 4K), like for device local-memory. + * However in general the final size here should always reflect any + * rounding up, if for example using the I915_GEM_CREATE_EXT_MEMORY_REGIONS + * extension to place the object in device local-memory. + */ + __u64 size; + /** + * @handle: Returned handle for the object. + * + * Object handles are nonzero. + */ + __u32 handle; + /** @flags: MBZ */ + __u32 flags; + /** + * @extensions: The chain of extensions to apply to this object. + * + * This will be useful in the future when we need to support several + * different extensions, and we need to apply more than one when + * creating the object. See struct i915_user_extension. + * + * If we don't supply any extensions then we get the same old gem_create + * behaviour. + * + * For I915_GEM_CREATE_EXT_MEMORY_REGIONS usage see + * struct drm_i915_gem_create_ext_memory_regions. + */ +#define I915_GEM_CREATE_EXT_MEMORY_REGIONS 0 + __u64 extensions; +}; + +/** + * struct drm_i915_gem_create_ext_memory_regions - The + * I915_GEM_CREATE_EXT_MEMORY_REGIONS extension. + * + * Set the object with the desired set of placements/regions in priority + * order. Each entry must be unique and supported by the device. + * + * This is provided as an array of struct drm_i915_gem_memory_class_instance, or + * an equivalent layout of class:instance pair encodings. See struct + * drm_i915_query_memory_regions and DRM_I915_QUERY_MEMORY_REGIONS for how to + * query the supported regions for a device. + * + * As an example, on discrete devices, if we wish to set the placement as + * device local-memory we can do something like: + * + * .. code-block:: C + * + * struct drm_i915_gem_memory_class_instance region_lmem = { + * .memory_class = I915_MEMORY_CLASS_DEVICE, + * .memory_instance = 0, + * }; + * struct drm_i915_gem_create_ext_memory_regions regions = { + * .base = { .name = I915_GEM_CREATE_EXT_MEMORY_REGIONS }, + * .regions = (uintptr_t)&region_lmem, + * .num_regions = 1, + * }; + * struct drm_i915_gem_create_ext create_ext = { + * .size = 16 * PAGE_SIZE, + * .extensions = (uintptr_t)&regions, + * }; + * + * int err = ioctl(fd, DRM_IOCTL_I915_GEM_CREATE_EXT, &create_ext); + * if (err) ... + * + * At which point we get the object handle in &drm_i915_gem_create_ext.handle, + * along with the final object size in &drm_i915_gem_create_ext.size, which + * should account for any rounding up, if required. + */ +struct drm_i915_gem_create_ext_memory_regions { + /** @base: Extension link. See struct i915_user_extension. */ + struct i915_user_extension base; + + /** @pad: MBZ */ + __u32 pad; + /** @num_regions: Number of elements in the @regions array. */ + __u32 num_regions; + /** + * @regions: The regions/placements array. + * + * An array of struct drm_i915_gem_memory_class_instance. + */ + __u64 regions; +}; diff --git a/Documentation/gpu/rfc/i915_gem_lmem.rst b/Documentation/gpu/rfc/i915_gem_lmem.rst new file mode 100644 index 000000000000..462f1efd9003 --- /dev/null +++ b/Documentation/gpu/rfc/i915_gem_lmem.rst @@ -0,0 +1,130 @@ +========================= +I915 DG1/LMEM RFC Section +========================= + +Upstream plan +============= +For upstream the overall plan for landing all the DG1 stuff and turning it for +real, with all the uAPI bits is: + +* Merge basic HW enabling of DG1(still without pciid) +* Merge the uAPI bits behind special CONFIG_BROKEN(or so) flag + * At this point we can still make changes, but importantly this lets us + start running IGTs which can utilize local-memory in CI +* Convert over to TTM, make sure it all keeps working. Some of the work items: + * TTM shrinker for discrete + * dma_resv_lockitem for full dma_resv_lock, i.e not just trylock + * Use TTM CPU pagefault handler + * Route shmem backend over to TTM SYSTEM for discrete + * TTM purgeable object support + * Move i915 buddy allocator over to TTM + * MMAP ioctl mode(see `I915 MMAP`_) + * SET/GET ioctl caching(see `I915 SET/GET CACHING`_) +* Add pciid for DG1 and turn on uAPI for real + +New object placement and region query uAPI +========================================== +Starting from DG1 we need to give userspace the ability to allocate buffers from +device local-memory. Currently the driver supports gem_create, which can place +buffers in system memory via shmem, and the usual assortment of other +interfaces, like dumb buffers and userptr. + +To support this new capability, while also providing a uAPI which will work +beyond just DG1, we propose to offer three new bits of uAPI: + +DRM_I915_QUERY_MEMORY_REGIONS +----------------------------- +New query ID which allows userspace to discover the list of supported memory +regions(like system-memory and local-memory) for a given device. We identify +each region with a class and instance pair, which should be unique. The class +here would be DEVICE or SYSTEM, and the instance would be zero, on platforms +like DG1. + +Side note: The class/instance design is borrowed from our existing engine uAPI, +where we describe every physical engine in terms of its class, and the +particular instance, since we can have more than one per class. + +In the future we also want to expose more information which can further +describe the capabilities of a region. + +.. kernel-doc:: Documentation/gpu/rfc/i915_gem_lmem.h + :functions: drm_i915_gem_memory_class drm_i915_gem_memory_class_instance drm_i915_memory_region_info drm_i915_query_memory_regions + +GEM_CREATE_EXT +-------------- +New ioctl which is basically just gem_create but now allows userspace to +provide a chain of possible extensions. Note that if we don't provide any +extensions then we get the exact same behaviour as gem_create. + +Side note: We also need to support PXP[1] in the near future, which is also +applicable to integrated platforms, and adds its own gem_create_ext extension, +which basically lets userspace mark a buffer as "protected". + +.. kernel-doc:: Documentation/gpu/rfc/i915_gem_lmem.h + :functions: drm_i915_gem_create_ext + +I915_GEM_CREATE_EXT_MEMORY_REGIONS +---------------------------------- +Implemented as an extension for gem_create_ext, we would now allow userspace to +optionally provide an immutable list of preferred placements at creation time, +in priority order, for a given buffer object. For the placements we expect +them each to use the class/instance encoding, as per the output of the regions +query. Having the list in priority order will be useful in the future when +placing an object, say during eviction. + +.. kernel-doc:: Documentation/gpu/rfc/i915_gem_lmem.h + :functions: drm_i915_gem_create_ext_memory_regions + +One fair criticism here is that this seems a little over-engineered[2]. If we +just consider DG1 then yes, a simple gem_create.flags or something is totally +all that's needed to tell the kernel to allocate the buffer in local-memory or +whatever. However looking to the future we need uAPI which can also support +upcoming Xe HP multi-tile architecture in a sane way, where there can be +multiple local-memory instances for a given device, and so using both class and +instance in our uAPI to describe regions is desirable, although specifically +for DG1 it's uninteresting, since we only have a single local-memory instance. + +Existing uAPI issues +==================== +Some potential issues we still need to resolve. + +I915 MMAP +--------- +In i915 there are multiple ways to MMAP GEM object, including mapping the same +object using different mapping types(WC vs WB), i.e multiple active mmaps per +object. TTM expects one MMAP at most for the lifetime of the object. If it +turns out that we have to backpedal here, there might be some potential +userspace fallout. + +I915 SET/GET CACHING +-------------------- +In i915 we have set/get_caching ioctl. TTM doesn't let us to change this, but +DG1 doesn't support non-snooped pcie transactions, so we can just always +allocate as WB for smem-only buffers. If/when our hw gains support for +non-snooped pcie transactions then we must fix this mode at allocation time as +a new GEM extension. + +This is related to the mmap problem, because in general (meaning, when we're +not running on intel cpus) the cpu mmap must not, ever, be inconsistent with +allocation mode. + +Possible idea is to let the kernel picks the mmap mode for userspace from the +following table: + +smem-only: WB. Userspace does not need to call clflush. + +smem+lmem: We allocate uncached memory, and give userspace a WC mapping +for when the buffer is in smem, and WC when it's in lmem. GPU does snooped +access, which is a bit inefficient. + +lmem only: always WC + +This means on discrete you only get a single mmap mode, all others must be +rejected. That's probably going to be a new default mode or something like +that. + +Links +===== +[1] https://patchwork.freedesktop.org/series/86798/ + +[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5599#note_553791 diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index a8621f7dab8b..05670442ca1b 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -15,3 +15,7 @@ host such documentation: * Once the code has landed move all the documentation to the right places in the main core, helper or driver sections. + +.. toctree:: + + i915_gem_lmem.rst -- 2.26.3

2 1

← Newer
1
...
30
31
32
33
34
35
36
...
72
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2021