dri-devel June 2021

dri-devel@lists.freedesktop.org

341 participants
878 discussions

[PATCH v2 1/2] pwm: Introduce single-PWM of_xlate function
by Bjorn Andersson 18 Jun '21

18 Jun '21

The existing pxa driver and the upcoming addition of PWM support in the TI sn565dsi86 DSI/eDP bridge driver both has a single PWM channel and thereby a need for a of_xlate function with the period as its single argument. Introduce a common helper function in the core that can be used as of_xlate by such drivers and migrate the pxa driver to use this. Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> --- Changes since v1: - Pick up the optional flags cell as well drivers/pwm/core.c | 26 ++++++++++++++++++++++++++ drivers/pwm/pwm-pxa.c | 16 +--------------- include/linux/pwm.h | 2 ++ 3 files changed, 29 insertions(+), 15 deletions(-) diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c index a42999f877d2..5e9c876fccc4 100644 --- a/drivers/pwm/core.c +++ b/drivers/pwm/core.c @@ -152,6 +152,32 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct of_phandle_args *args) } EXPORT_SYMBOL_GPL(of_pwm_xlate_with_flags); +struct pwm_device * +of_pwm_single_xlate(struct pwm_chip *pc, const struct of_phandle_args *args) +{ + struct pwm_device *pwm; + + if (pc->of_pwm_n_cells < 1) + return ERR_PTR(-EINVAL); + + /* validate that one cell is specified, optionally with flags */ + if (args->args_count != 1 && args->args_count != 2) + return ERR_PTR(-EINVAL); + + pwm = pwm_request_from_chip(pc, 0, NULL); + if (IS_ERR(pwm)) + return pwm; + + pwm->args.period = args->args[0]; + pwm->args.polarity = PWM_POLARITY_NORMAL; + + if (args->args_count == 2 && args->args[2] & PWM_POLARITY_INVERTED) + pwm->args.polarity = PWM_POLARITY_INVERSED; + + return pwm; +} +EXPORT_SYMBOL_GPL(of_pwm_single_xlate); + static void of_pwmchip_add(struct pwm_chip *chip) { if (!chip->dev || !chip->dev->of_node) diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c index cfb683827d32..8cd82fb54483 100644 --- a/drivers/pwm/pwm-pxa.c +++ b/drivers/pwm/pwm-pxa.c @@ -148,20 +148,6 @@ static const struct platform_device_id *pxa_pwm_get_id_dt(struct device *dev) return id ? id->data : NULL; } -static struct pwm_device * -pxa_pwm_of_xlate(struct pwm_chip *pc, const struct of_phandle_args *args) -{ - struct pwm_device *pwm; - - pwm = pwm_request_from_chip(pc, 0, NULL); - if (IS_ERR(pwm)) - return pwm; - - pwm->args.period = args->args[0]; - - return pwm; -} - static int pwm_probe(struct platform_device *pdev) { const struct platform_device_id *id = platform_get_device_id(pdev); @@ -187,7 +173,7 @@ static int pwm_probe(struct platform_device *pdev) pwm->chip.npwm = (id->driver_data & HAS_SECONDARY_PWM) ? 2 : 1; if (IS_ENABLED(CONFIG_OF)) { - pwm->chip.of_xlate = pxa_pwm_of_xlate; + pwm->chip.of_xlate = of_pwm_single_xlate; pwm->chip.of_pwm_n_cells = 1; } diff --git a/include/linux/pwm.h b/include/linux/pwm.h index 5a73251d28e3..6aff1fa4fe5d 100644 --- a/include/linux/pwm.h +++ b/include/linux/pwm.h @@ -411,6 +411,8 @@ struct pwm_device *pwm_request_from_chip(struct pwm_chip *chip, struct pwm_device *of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct of_phandle_args *args); +struct pwm_device *of_pwm_single_xlate(struct pwm_chip *pc, + const struct of_phandle_args *args); struct pwm_device *pwm_get(struct device *dev, const char *con_id); struct pwm_device *of_pwm_get(struct device *dev, struct device_node *np, -- 2.31.0

2 8

[PATCH] drm/bridge: ti-sn65dsi83: Fix null pointer dereference in remove callback
by Jonathan Liu 18 Jun '21

18 Jun '21

If attach has not been called, unloading the driver can result in a null pointer dereference in mipi_dsi_detach as ctx->dsi has not been assigned yet. Fixes: ceb515ba29ba6b ("drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver") Signed-off-by: Jonathan Liu <net147(a)gmail.com> --- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c index 750f2172ef08..8e9f45c5c7c1 100644 --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c @@ -671,8 +671,11 @@ static int sn65dsi83_remove(struct i2c_client *client) { struct sn65dsi83 *ctx = i2c_get_clientdata(client); - mipi_dsi_detach(ctx->dsi); - mipi_dsi_device_unregister(ctx->dsi); + if (ctx->dsi) { + mipi_dsi_detach(ctx->dsi); + mipi_dsi_device_unregister(ctx->dsi); + } + drm_bridge_remove(&ctx->bridge); of_node_put(ctx->host_node); -- 2.32.0

3 4

[PATCH 0/8] Introduce i915_sched_engine object
by Matthew Brost 18 Jun '21

18 Jun '21

As discussed in [1] we are breaking that large series into a several smaller ones. This series is stand alone patch part of step #4 which has no other dependencies or patches relevant to it. v2: (Daniel Vetter): - Split into several smaller patches - Add kernel doc for i915_sched_engine (Matthew Brost): - Drop wrapper functions for tasklet as eventually tasklet will be dropped v3: (Jason Ekstrand) - Address his comments, change logs in individual patches - Squash documentation patch into previous patches as needed (Checkpatch) - Fix warnings (Docs) - Fix warnings v4: (Daniele) - Update a comments / commit messages - Set queue_priority_hint v5: (CI) - Rebase and fix build error v6: - Rebase Signed-off-by: Matthew Brost <matthew.brost(a)intel.com> [1] https://patchwork.freedesktop.org/series/89844/ Matthew Brost (8): drm/i915: Move priolist to new i915_sched_engine object drm/i915: Add i915_sched_engine_is_empty function drm/i915: Reset sched_engine.no_priolist immediately after dequeue drm/i915: Move active tracking to i915_sched_engine drm/i915: Move engine->schedule to i915_sched_engine drm/i915: Add kick_backend function to i915_sched_engine drm/i915: Update i915_scheduler to operate on i915_sched_engine drm/i915: Move submission tasklet to i915_sched_engine Documentation/gpu/i915.rst | 5 + drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine.h | 16 - drivers/gpu/drm/i915/gt/intel_engine_cs.c | 72 ++-- .../gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +- drivers/gpu/drm/i915/gt/intel_engine_types.h | 49 +-- drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +- .../drm/i915/gt/intel_execlists_submission.c | 325 +++++++++++------- .../gpu/drm/i915/gt/intel_ring_submission.c | 12 +- drivers/gpu/drm/i915/gt/mock_engine.c | 17 +- drivers/gpu/drm/i915/gt/selftest_execlists.c | 34 +- drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 +- drivers/gpu/drm/i915/gt/selftest_lrc.c | 6 +- drivers/gpu/drm/i915/gt/selftest_reset.c | 2 +- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 70 ++-- drivers/gpu/drm/i915/i915_gpu_error.c | 4 +- drivers/gpu/drm/i915/i915_request.c | 42 +-- drivers/gpu/drm/i915/i915_request.h | 2 +- drivers/gpu/drm/i915/i915_scheduler.c | 168 +++++---- drivers/gpu/drm/i915/i915_scheduler.h | 47 ++- drivers/gpu/drm/i915/i915_scheduler_types.h | 89 +++++ 22 files changed, 556 insertions(+), 424 deletions(-) -- 2.28.0

1 8

[pull] drm/msm: drm-msm-next-2021-06-17 for v5.14
by Rob Clark 17 Jun '21

17 Jun '21

Hi Dave & Daniel, Here is msm-next for v5.14 Notable additions this time around: * devcoredump support for display errors * dpu: irq cleanup/refactor * dpu: dt bindings conversion to yaml * dsi: dt bindings conversion to yaml * mdp5: alpha/blend_mode/zpos support * mdp5: dynamic bandwidth management * a6xx: cached coherent buffer support * a660 support * gpu iova fault improvements: - info about which block triggered the fault, etc - generation of gpu devcoredump on fault * assortment of other cleanups and fixes The following changes since commit c4681547bcce777daf576925a966ffa824edd09d: Linux 5.13-rc3 (2021-05-23 11:42:48 -1000) are available in the Git repository at: https://gitlab.freedesktop.org/drm/msm.git drm-msm-next-2021-06-17 for you to fetch changes up to 7e0230fd096c03e9662e66150f951075dd16e496: drm/msm/mdp5: provide dynamic bandwidth management (2021-06-17 09:51:44 -0700) ---------------------------------------------------------------- Abhinav Kumar (7): drm: allow drm_atomic_print_state() to accept any drm_printer drm/msm: add support to take dpu snapshot drm/msm/dsi: add API to take DSI register snapshot drm/msm/dp: add API to take DP register snapshot drm/msm/disp/dpu1: add API to take DPU register snapshot drm/msm: add support to take dsi, dp and dpu snapshot drm/msm: add disp snapshot points across dpu driver Alexey Minnekhanov (1): drm/msm: Init mm_list before accessing it for use_vram path Arnd Bergmann (1): drm/msm/dsi: fix 32-bit clang warning Bernard Zhao (1): drm/msm: remove unneeded variable ret Bhaskar Chowdhury (3): drm/msm/dpu: Fix a typo drm/msm/dpu: Fix a typo drm/msm/dp: Fixed couple of typos Bjorn Andersson (1): drm/msm/dpu: Avoid ABBA deadlock between IRQ modules Dmitry Baryshkov (23): drm/msm: pass dump state as a function argument drm/msm: make msm_disp_state transient data struct drm/msm: get rid of msm_iomap_size drm/msm/dsi: add DSI PHY registers to snapshot data drm/msm: fix display snapshotting if DP or DSI is disabled drm/msm/dpu: merge dpu_hw_intr_get_interrupt_statuses into dpu_hw_intr_dispatch_irqs drm/msm/dpu: hw_intr: always call dpu_hw_intr_clear_intr_status_nolock drm/msm/dpu: define interrupt register names drm/msm/dpu: replace IRQ lookup with the data in hw catalog drm/msm/dpu: drop remains of old irq lookup subsystem drm/msm/dpu: simplify IRQ enabling/disabling drm/msm/dsi: print error code when MIPI DSI host registration fails drm/msm/dpu: remove unused dpu_hw_blk features drm/msm/dpu: drop dpu_hw_blk_destroy function drm/msm/dpu: use struct dpu_hw_merge_3d in dpu_hw_pingpong drm/msm/dpu: hw_blk: make dpu_hw_blk empty opaque structure drm/msm/dsi: do not enable PHYs when called for the slave DSI interface drm/msm/mdp5: use drm atomic helpers to handle base drm plane state drm/msm/mdp5: use drm_plane_state for storing alpha value drm/msm/mdp5: use drm_plane_state for pixel blend mode drm/msm/mdp5: add support for alpha/blend_mode properties drm/msm/mdp5: switch to standard zpos property drm/msm/mdp5: provide dynamic bandwidth management Guenter Roeck (2): drm/msm/dp: Drop unnecessary NULL checks after container_of drm/msm/dpu: Drop unnecessary NULL checks after container_of in dpu_encoder James Willcox (1): drm/msm/mdp5: add perf blocks for holding fudge factors Jonathan Marek (13): drm/msm: remove unnecessary mmap logic for cached BOs drm/msm: replace MSM_BO_UNCACHED with MSM_BO_WC for internal objects drm/msm: use the right pgprot when mapping BOs in the kernel drm/msm: add MSM_BO_CACHED_COHERENT drm/msm: deprecate MSM_BO_UNCACHED (map as writecombine instead) drm/msm/a6xx: update/fix CP_PROTECT initialization drm/msm/a6xx: fix incorrectly set uavflagprd_inv field for A650 drm/msm/a6xx: avoid shadow NULL reference in failure path drm/msm: remove unused icc_path/ocmem_icc_path drm/msm/a6xx: use AOP-initialized PDC for a650 drm/msm/a6xx: add GMU_CX_GMU_CX_FALNEXT_INTF write for a650 drm/msm/a6xx: add missing PC_DBG_ECO_CNTL bit for a640/a650 drm/msm/a6xx: add support for Adreno 660 GPU Jordan Crouse (3): iommu/arm-smmu: Add support for driver IOMMU fault handlers iommu/arm-smmu-qcom: Add an adreno-smmu-priv callback to get pagefault info drm/msm: Improve the a6xx page fault handler Krishna Manikandan (5): dt-bindings: msm: disp: add yaml schemas for DPU bindings dt-bindings: msm: dsi: add yaml schemas for DSI bindings dt-bindings: msm: dsi: add yaml schemas for DSI PHY bindings dt-bindings: msm/dp: Add bindings of MSM DisplayPort controller drm/msm/disp/dpu1: avoid perf update in frame done event Kuogee Hsieh (2): drm/msm/dp: handle irq_hpd with sink_count = 0 correctly drm/msm/dp: power off DP phy at suspend Lee Jones (5): drm/msm/dp/dp_display: Remove unused variable 'hpd' drm/msm/disp/dpu1/dpu_plane: Fix a couple of naming issues drm/msm/msm_gem: Demote kernel-doc abuses drm/msm/dp/dp_catalog: Correctly document param 'dp_catalog' drm/msm/dp/dp_link: Fix some potential doc-rot Rob Clark (5): Merge branch 'msm-fixes-v5.13-rc6' into msm-next drm/msm: Generated register update iommu/arm-smmu-qcom: Add stall support drm/msm: devcoredump iommu fault support drm/msm: Add debugfs to trigger shrinker Samuel Iglesias Gonsalvez (1): drm/msm: export hangcheck_period in debugfs Shaokun Zhang (1): drm/msm/dp: remove the repeated declaration Stephen Boyd (10): drm/msm/dp: Simplify aux irq handling code drm/msm/dp: Shrink locking area of dp_aux_transfer() drm/msm/dp: Handle aux timeouts, nacks, defers drm/msm: Move vblank debug prints to drm_dbg_vbl() drm/msm/dp: Drop malformed debug print drm/msm: Move FB debug prints to drm_dbg_state() drm/msm/disp: Use plane debug print helper drm/msm/disp: Move various debug logs to atomic bucket drm/msm/dsi: Stash away calculated vco frequency on recalc drm/msm: Use VERB() for extra verbose logging Yangtao Li (1): drm/msm: Convert to use resource-managed OPP API Zhen Lei (3): drm/msm: Fix error return code in msm_drm_init() drm/msm/dpu: Fix error return code in dpu_mdss_init() drm/msm/dpu: remove unused local variable 'cmd_enc' zuoqilin (1): drm/msm: Remove unneeded variable: "rc" .../bindings/display/msm/dp-controller.yaml | 146 ++ .../bindings/display/msm/dpu-sc7180.yaml | 228 ++ .../bindings/display/msm/dpu-sdm845.yaml | 212 ++ .../devicetree/bindings/display/msm/dpu.txt | 141 -- .../bindings/display/msm/dsi-controller-main.yaml | 185 ++ .../bindings/display/msm/dsi-phy-10nm.yaml | 68 + .../bindings/display/msm/dsi-phy-14nm.yaml | 66 + .../bindings/display/msm/dsi-phy-20nm.yaml | 71 + .../bindings/display/msm/dsi-phy-28nm.yaml | 68 + .../bindings/display/msm/dsi-phy-common.yaml | 40 + .../devicetree/bindings/display/msm/dsi.txt | 249 --- drivers/gpu/drm/drm_atomic.c | 28 +- drivers/gpu/drm/drm_atomic_uapi.c | 4 +- drivers/gpu/drm/drm_crtc_internal.h | 4 +- drivers/gpu/drm/msm/Makefile | 3 +- drivers/gpu/drm/msm/adreno/a2xx.xml.h | 60 +- drivers/gpu/drm/msm/adreno/a3xx.xml.h | 40 +- drivers/gpu/drm/msm/adreno/a4xx.xml.h | 38 +- drivers/gpu/drm/msm/adreno/a5xx.xml.h | 95 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 29 +- drivers/gpu/drm/msm/adreno/a5xx_power.c | 2 +- drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 4 +- drivers/gpu/drm/msm/adreno/a6xx.xml.h | 2201 ++++++++++---------- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 55 +- drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 34 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 460 +++- drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 4 +- drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 44 +- drivers/gpu/drm/msm/adreno/a6xx_hfi.c | 33 + drivers/gpu/drm/msm/adreno/adreno_common.xml.h | 30 +- drivers/gpu/drm/msm/adreno/adreno_device.c | 14 + drivers/gpu/drm/msm/adreno/adreno_gpu.c | 26 +- drivers/gpu/drm/msm/adreno/adreno_gpu.h | 13 +- drivers/gpu/drm/msm/adreno/adreno_pm4.xml.h | 119 +- drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 230 +- drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h | 43 - drivers/gpu/drm/msm/disp/dpu1/dpu_core_perf.c | 22 +- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 43 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 110 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 4 - .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 58 +- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 54 +- drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 6 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c | 139 -- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.h | 22 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 202 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 16 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_ctl.c | 6 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_dspp.c | 7 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 1508 +------------- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 132 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 6 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_lm.c | 6 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_mdss.h | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_merge3d.c | 6 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.c | 6 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_pingpong.h | 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 6 - drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c | 6 - drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 70 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 8 +- drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 8 +- drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 23 +- drivers/gpu/drm/msm/disp/dpu1/dpu_rm.c | 4 +- drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 63 +- drivers/gpu/drm/msm/disp/dpu1/dpu_vbif.c | 14 +- drivers/gpu/drm/msm/disp/mdp4/mdp4.xml.h | 34 +- drivers/gpu/drm/msm/disp/mdp5/mdp5.xml.h | 38 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 35 + drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.h | 7 + drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 56 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 119 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.h | 17 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_plane.c | 177 +- drivers/gpu/drm/msm/disp/mdp_common.xml.h | 34 +- drivers/gpu/drm/msm/disp/msm_disp_snapshot.c | 125 ++ drivers/gpu/drm/msm/disp/msm_disp_snapshot.h | 136 ++ drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c | 187 ++ drivers/gpu/drm/msm/dp/dp_aux.c | 181 +- drivers/gpu/drm/msm/dp/dp_aux.h | 8 - drivers/gpu/drm/msm/dp/dp_catalog.c | 18 +- drivers/gpu/drm/msm/dp/dp_catalog.h | 7 +- drivers/gpu/drm/msm/dp/dp_ctrl.c | 87 +- drivers/gpu/drm/msm/dp/dp_ctrl.h | 3 +- drivers/gpu/drm/msm/dp/dp_display.c | 121 +- drivers/gpu/drm/msm/dp/dp_display.h | 1 + drivers/gpu/drm/msm/dp/dp_link.c | 21 +- drivers/gpu/drm/msm/dp/dp_panel.c | 4 +- drivers/gpu/drm/msm/dp/dp_power.h | 4 +- drivers/gpu/drm/msm/dsi/dsi.c | 6 + drivers/gpu/drm/msm/dsi/dsi.h | 4 +- drivers/gpu/drm/msm/dsi/dsi.xml.h | 1722 +-------------- drivers/gpu/drm/msm/dsi/dsi_host.c | 30 +- drivers/gpu/drm/msm/dsi/dsi_manager.c | 12 +- drivers/gpu/drm/msm/dsi/dsi_phy_10nm.xml.h | 228 ++ drivers/gpu/drm/msm/dsi/dsi_phy_14nm.xml.h | 310 +++ drivers/gpu/drm/msm/dsi/dsi_phy_20nm.xml.h | 238 +++ drivers/gpu/drm/msm/dsi/dsi_phy_28nm.xml.h | 385 ++++ drivers/gpu/drm/msm/dsi/dsi_phy_28nm_8960.xml.h | 287 +++ drivers/gpu/drm/msm/dsi/dsi_phy_5nm.xml.h | 480 +++++ drivers/gpu/drm/msm/dsi/dsi_phy_7nm.xml.h | 482 +++++ drivers/gpu/drm/msm/dsi/mmss_cc.xml.h | 34 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 31 +- drivers/gpu/drm/msm/dsi/phy/dsi_phy.h | 4 + drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c | 2 + drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy_20nm.c | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm.c | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy_28nm_8960.c | 1 + drivers/gpu/drm/msm/dsi/phy/dsi_phy_7nm.c | 8 +- drivers/gpu/drm/msm/dsi/sfpb.xml.h | 34 +- drivers/gpu/drm/msm/edp/edp.xml.h | 34 +- drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 34 +- drivers/gpu/drm/msm/hdmi/qfprom.xml.h | 34 +- drivers/gpu/drm/msm/msm_debugfs.c | 31 + drivers/gpu/drm/msm/msm_drv.c | 33 +- drivers/gpu/drm/msm/msm_drv.h | 24 +- drivers/gpu/drm/msm/msm_fb.c | 8 +- drivers/gpu/drm/msm/msm_gem.c | 45 +- drivers/gpu/drm/msm/msm_gem.h | 1 + drivers/gpu/drm/msm/msm_gem_shrinker.c | 18 + drivers/gpu/drm/msm/msm_gem_submit.c | 1 + drivers/gpu/drm/msm/msm_gpu.c | 51 +- drivers/gpu/drm/msm/msm_gpu.h | 29 +- drivers/gpu/drm/msm/msm_gpummu.c | 5 + drivers/gpu/drm/msm/msm_iommu.c | 22 +- drivers/gpu/drm/msm/msm_kms.h | 9 + drivers/gpu/drm/msm/msm_mmu.h | 5 +- drivers/gpu/drm/selftests/test-drm_framebuffer.c | 1 + drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 50 + drivers/iommu/arm/arm-smmu/arm-smmu.c | 9 +- drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 + include/linux/adreno-smmu-priv.h | 38 +- include/uapi/drm/msm_drm.h | 7 +- 134 files changed, 7508 insertions(+), 6352 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/msm/dp-controller.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml delete mode 100644 Documentation/devicetree/bindings/display/msm/dpu.txt create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml create mode 100644 Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml delete mode 100644 Documentation/devicetree/bindings/display/msm/dsi.txt delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_blk.c create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot.c create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot.h create mode 100644 drivers/gpu/drm/msm/disp/msm_disp_snapshot_util.c create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy_10nm.xml.h create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy_14nm.xml.h create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy_20nm.xml.h create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy_28nm.xml.h create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy_28nm_8960.xml.h create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy_5nm.xml.h create mode 100644 drivers/gpu/drm/msm/dsi/dsi_phy_7nm.xml.h

1 0

[PATCH] drm/i915/display: Do not zero past infoframes.vsc
by Kees Cook 17 Jun '21

17 Jun '21

intel_dp_vsc_sdp_unpack() was using a memset() size (36, struct dp_sdp) larger than the destination (24, struct drm_dp_vsc_sdp), clobbering fields in struct intel_crtc_state after infoframes.vsc. Use the actual target size for the memset(). Fixes: 1b404b7dbb10 ("drm/i915/dp: Read out DP SDPs") Cc: stable(a)vger.kernel.org Signed-off-by: Kees Cook <keescook(a)chromium.org> --- drivers/gpu/drm/i915/display/intel_dp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c index 5c9222283044..6cc03b9e4321 100644 --- a/drivers/gpu/drm/i915/display/intel_dp.c +++ b/drivers/gpu/drm/i915/display/intel_dp.c @@ -2868,7 +2868,7 @@ static int intel_dp_vsc_sdp_unpack(struct drm_dp_vsc_sdp *vsc, if (size < sizeof(struct dp_sdp)) return -EINVAL; - memset(vsc, 0, size); + memset(vsc, 0, sizeof(*vsc)); if (sdp->sdp_header.HB0 != 0) return -EINVAL; -- 2.25.1

1 0

[PATCH 0/7] drm/msm/dpu: merge dpu_core_irq into dpu_hw_interrupts
by Dmitry Baryshkov 17 Jun '21

17 Jun '21

This patch series reworks DPU's irq handling code by merging dpu_core_irq into dpu_hw_intr, reworking/dropping irq-related helpers and wrappers, etc. Dependencies: https://lore.kernel.org/linux-arm-msm/20210611170003.3539059-1-bjorn.anders… ---------------------------------------------------------------- Dmitry Baryshkov (7): drm/msm/dpu: squash dpu_core_irq into dpu_hw_interrupts drm/msm/dpu: don't clear IRQ register twice drm/msm/dpu: merge struct dpu_irq into struct dpu_hw_intr drm/msm/dpu: hide struct dpu_irq_callback drm/msm/dpu: remove extra wrappers around dpu_core_irq drm/msm/dpu: get rid of dpu_encoder_helper_(un)register_irq drm/msm/dpu: remove struct dpu_encoder_irq and enum dpu_intr_idx drivers/gpu/drm/msm/Makefile | 1 - drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 256 ----------------- drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.h | 30 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 111 ++------ drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 66 +---- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 99 +++---- .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 56 ++-- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 306 ++++++++++++++++----- drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.h | 92 +------ drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 27 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 25 -- drivers/gpu/drm/msm/disp/dpu1/dpu_trace.h | 49 ++-- 12 files changed, 383 insertions(+), 735 deletions(-) delete mode 100644 drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c

2 9

[PATCH v2] drm/i915: Document the Virtual Engine uAPI
by Tvrtko Ursulin 17 Jun '21

17 Jun '21

From: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> A little bit of documentation covering the topics of engine discovery, context engine maps and virtual engines. It is not very detailed but supposed to be a starting point of giving a brief high level overview of general principles and intended use cases. v2: * Have the text in uapi header and link from there. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> Cc: Daniel Vetter <daniel(a)ffwll.ch> --- Documentation/gpu/i915.rst | 18 ++++ include/uapi/drm/i915_drm.h | 188 ++++++++++++++++++++++++++++++++++++ 2 files changed, 206 insertions(+) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 42ce0196930a..00aa55bbe0fd 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -335,6 +335,24 @@ for execution also include a list of all locations within buffers that refer to GPU-addresses so that the kernel can edit the buffer correctly. This process is dubbed relocation. +Engine Discovery uAPI +--------------------- + +.. kernel-doc:: include/uapi/drm/i915_drm.h + :doc: Engine Discovery uAPI + +Context Engine Map uAPI +----------------------- + +.. kernel-doc:: include/uapi/drm/i915_drm.h + :doc: Context Engine Map uAPI + +Virtual Engine uAPI +------------------- + +.. kernel-doc:: include/uapi/drm/i915_drm.h + :doc: Virtual Engine uAPI + Locking Guidelines ------------------ diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h index a1cb4aa035a9..2f70c48567c0 100644 --- a/include/uapi/drm/i915_drm.h +++ b/include/uapi/drm/i915_drm.h @@ -1806,6 +1806,69 @@ struct drm_i915_gem_context_param_sseu { __u32 rsvd; }; +/** + * DOC: Virtual Engine uAPI + * + * Virtual engine is a concept where userspace is able to configure a set of + * physical engines, submit a batch buffer, and let the driver execute it on any + * engine from the set as it sees fit. + * + * This is primarily useful on parts which have multiple instances of a same + * class engine, like for example GT3+ Skylake parts with their two VCS engines. + * + * For instance userspace can enumerate all engines of a certain class using the + * previously described `Engine Discovery uAPI`_. After that userspace can + * create a GEM context with a placeholder slot for the virtual engine (using + * `I915_ENGINE_CLASS_INVALID` and `I915_ENGINE_CLASS_INVALID_NONE` for class + * and instance respectively) and finally using the + * `I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE` extension place a virtual engine in + * the same reserved slot. + * + * Example of creating a virtual engine and submitting a batch buffer to it: + * + * .. code-block:: C + * + * I915_DEFINE_CONTEXT_ENGINES_LOAD_BALANCE(virtual, 2) = { + * .base.name = I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE, + * .engine_index = 0, // Place this virtual engine into engine map slot 0 + * .num_siblings = 2, + * .engines = { { I915_ENGINE_CLASS_VIDEO, 0 }, + * { I915_ENGINE_CLASS_VIDEO, 1 }, }, + * }; + * I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 1) = { + * .engines = { { I915_ENGINE_CLASS_INVALID, + * I915_ENGINE_CLASS_INVALID_NONE } }, + * .extensions = to_user_pointer(&virtual), // Chains after load_balance extension + * }; + * struct drm_i915_gem_context_create_ext_setparam p_engines = { + * .base = { + * .name = I915_CONTEXT_CREATE_EXT_SETPARAM, + * }, + * .param = { + * .param = I915_CONTEXT_PARAM_ENGINES, + * .value = to_user_pointer(&engines), + * .size = sizeof(engines), + * }, + * }; + * struct drm_i915_gem_context_create_ext create = { + * .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS, + * .extensions = to_user_pointer(&p_engines); + * }; + * + * ctx_id = gem_context_create_ext(drm_fd, &create); + * + * // Now we have created a GEM context with its engine map containing a + * // single virtual engine. Submissions to this slot can go either to + * // vcs0 or vcs1, depending on the load balancing algorithm used inside + * // the driver. The load balancing is dynamic from one batch buffer to + * // another and transparent to userspace. + * + * ... + * execbuf.rsvd1 = ctx_id; + * execbuf.flags = 0; // Submits to index 0 which is the virtual engine + * gem_execbuf(drm_fd, &execbuf); + */ + /* * i915_context_engines_load_balance: * @@ -1882,6 +1945,61 @@ struct i915_context_engines_bond { struct i915_engine_class_instance engines[N__]; \ } __attribute__((packed)) name__ +/** + * DOC: Context Engine Map uAPI + * + * Context engine map is a new way of addressing engines when submitting batch- + * buffers, replacing the existing way of using identifiers like `I915_EXEC_BLT` + * inside the flags field of `struct drm_i915_gem_execbuffer2`. + * + * To use it created GEM contexts need to be configured with a list of engines + * the user is intending to submit to. This is accomplished using the + * `I915_CONTEXT_PARAM_ENGINES` parameter and `struct + * i915_context_param_engines`. + * + * For such contexts the `I915_EXEC_RING_MASK` field becomes an index into the + * configured map. + * + * Example of creating such context and submitting against it: + * + * .. code-block:: C + * + * I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 2) = { + * .engines = { { I915_ENGINE_CLASS_RENDER, 0 }, + * { I915_ENGINE_CLASS_COPY, 0 } } + * }; + * struct drm_i915_gem_context_create_ext_setparam p_engines = { + * .base = { + * .name = I915_CONTEXT_CREATE_EXT_SETPARAM, + * }, + * .param = { + * .param = I915_CONTEXT_PARAM_ENGINES, + * .value = to_user_pointer(&engines), + * .size = sizeof(engines), + * }, + * }; + * struct drm_i915_gem_context_create_ext create = { + * .flags = I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS, + * .extensions = to_user_pointer(&p_engines); + * }; + * + * ctx_id = gem_context_create_ext(drm_fd, &create); + * + * // We have now created a GEM context with two engines in the map: + * // Index 0 points to rcs0 while index 1 points to bcs0. Other engines + * // will not be accessible from this context. + * + * ... + * execbuf.rsvd1 = ctx_id; + * execbuf.flags = 0; // Submits to index 0, which is rcs0 for this context + * gem_execbuf(drm_fd, &execbuf); + * + * ... + * execbuf.rsvd1 = ctx_id; + * execbuf.flags = 1; // Submits to index 0, which is bcs0 for this context + * gem_execbuf(drm_fd, &execbuf); + */ + struct i915_context_param_engines { __u64 extensions; /* linked chain of extension blocks, 0 terminates */ #define I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE 0 /* see i915_context_engines_load_balance */ @@ -2375,6 +2493,76 @@ struct drm_i915_query_topology_info { __u8 data[]; }; +/** + * DOC: Engine Discovery uAPI + * + * Engine discovery uAPI is a way of enumerating physical engines present in a + * GPU associated with an open i915 DRM file descriptor. This supersedes the old + * way of using `DRM_IOCTL_I915_GETPARAM` and engine identifiers like + * `I915_PARAM_HAS_BLT`. + * + * The need for this interface came starting with Icelake and newer GPUs, which + * started to establish a pattern of having multiple engines of a same class, + * where not all instances were always completely functionally equivalent. + * + * Entry point for this uapi is `DRM_IOCTL_I915_QUERY` with the + * `DRM_I915_QUERY_ENGINE_INFO` as the queried item id. + * + * Example for getting the list of engines: + * + * .. code-block:: C + * + * struct drm_i915_query_engine_info *info; + * struct drm_i915_query_item item = { + * .query_id = DRM_I915_QUERY_ENGINE_INFO; + * }; + * 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 engines. The kernel will fill out the + * // item.length for us, which is the number of bytes we need. + * // + * // Alternatively a large buffer can be allocated straight away enabling + * // querying in one pass, in which case item.length should contain the + * // length of the provided buffer. + * 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 info on all engines. + * item.data_ptr = (uintptr_t)&info, + * + * err = ioctl(fd, DRM_IOCTL_I915_QUERY, &query); + * if (err) ... + * + * // We can now access each engine in the array + * for (i = 0; i < info->num_engines; i++) { + * struct drm_i915_engine_info einfo = info->engines[i]; + * u16 class = einfo.engine.class; + * u16 instance = einfo.engine.instance; + * .... + * } + * + * free(info); + * + * Each of the enumerated engines, apart from being defined by its class and + * instance (see `struct i915_engine_class_instance`), also can have flags and + * capabilities defined as documented in i915_drm.h. + * + * For instance video engines which support HEVC encoding will have the + * `I915_VIDEO_CLASS_CAPABILITY_HEVC` capability bit set. + * + * Engine discovery only fully comes to its own when combined with the new way + * of addressing engines when submitting batch buffers using contexts with + * engine maps configured. + */ + /** * struct drm_i915_engine_info * -- 2.30.2

2 2

[PATCH] dma-buf: Document DMA_BUF_IOCTL_SYNC (v3)
by Jason Ekstrand 17 Jun '21

17 Jun '21

This adds a new "DMA Buffer ioctls" section to the dma-buf docs and adds documentation for DMA_BUF_IOCTL_SYNC. v2 (Daniel Vetter): - Fix a couple typos - Add commentary about synchronization with other devices - Use item list format for describing flags v3 (Pekka Paalanen): - Clarify stalling requirements. - Be more clear that that DMA_BUF_IOCTL_SYNC with SINC_END has to be called before more GPU work happens. Signed-off-by: Jason Ekstrand <jason(a)jlekstrand.net> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Acked-by: Christian König <christian.koenig(a)amd.com> Acked-by: Pekka Paalanen <pekka.paalanen(a)collabora.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> --- Documentation/driver-api/dma-buf.rst | 8 +++++ include/uapi/linux/dma-buf.h | 50 +++++++++++++++++++++++++++- 2 files changed, 57 insertions(+), 1 deletion(-) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 7f21425d9435a..0d4c13ec1a800 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -88,6 +88,9 @@ consider though: - The DMA buffer FD is also pollable, see `Implicit Fence Poll Support`_ below for details. +- The DMA buffer FD also supports a few dma-buf-specific ioctls, see + `DMA Buffer ioctls`_ below for details. + Basic Operation and Device DMA Access ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -106,6 +109,11 @@ Implicit Fence Poll Support .. kernel-doc:: drivers/dma-buf/dma-buf.c :doc: implicit fence polling +DMA Buffer ioctls +~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: include/uapi/linux/dma-buf.h + Kernel Functions and Structures Reference ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h index 7f30393b92c3b..8e4a2ca0bcbf7 100644 --- a/include/uapi/linux/dma-buf.h +++ b/include/uapi/linux/dma-buf.h @@ -22,8 +22,56 @@ #include <linux/types.h> -/* begin/end dma-buf functions used for userspace mmap. */ +/** + * struct dma_buf_sync - Synchronize with CPU access. + * + * When a DMA buffer is accessed from the CPU via mmap, it is not always + * possible to guarantee coherency between the CPU-visible map and underlying + * memory. To manage coherency, DMA_BUF_IOCTL_SYNC must be used to bracket + * any CPU access to give the kernel the chance to shuffle memory around if + * needed. + * + * Prior to accessing the map, the client must call DMA_BUF_IOCTL_SYNC + * with DMA_BUF_SYNC_START and the appropriate read/write flags. Once the + * access is complete, the client should call DMA_BUF_IOCTL_SYNC with + * DMA_BUF_SYNC_END and the same read/write flags. + * + * The synchronization provided via DMA_BUF_IOCTL_SYNC only provides cache + * coherency. It does not prevent other processes or devices from + * accessing the memory at the same time. If synchronization with a GPU or + * other device driver is required, it is the client's responsibility to + * wait for buffer to be ready for reading or writing before calling this + * ioctl with DMA_BUF_SYNC_START. Likewise, the client must ensure that + * follow-up work is not submitted to GPU or other device driver until + * after this ioctl has been called with DMA_BUF_SYNC_END? + * + * If the driver or API with which the client is interacting uses implicit + * synchronization, waiting for prior work to complete can be done via + * poll() on the DMA buffer file descriptor. If the driver or API requires + * explicit synchronization, the client may have to wait on a sync_file or + * other synchronization primitive outside the scope of the DMA buffer API. + */ struct dma_buf_sync { + /** + * @flags: Set of access flags + * + * DMA_BUF_SYNC_START: + * Indicates the start of a map access session. + * + * DMA_BUF_SYNC_END: + * Indicates the end of a map access session. + * + * DMA_BUF_SYNC_READ: + * Indicates that the mapped DMA buffer will be read by the + * client via the CPU map. + * + * DMA_BUF_SYNC_WRITE: + * Indicates that the mapped DMA buffer will be written by the + * client via the CPU map. + * + * DMA_BUF_SYNC_RW: + * An alias for DMA_BUF_SYNC_READ | DMA_BUF_SYNC_WRITE. + */ __u64 flags; }; -- 2.31.1

2 1

[PATCH] dma-buf: Document DMA_BUF_IOCTL_SYNC (v2)
by Jason Ekstrand 17 Jun '21

17 Jun '21

This adds a new "DMA Buffer ioctls" section to the dma-buf docs and adds documentation for DMA_BUF_IOCTL_SYNC. v2 (Daniel Vetter): - Fix a couple typos - Add commentary about synchronization with other devices - Use item list format for describing flags v2 (Pekka Paalanen): - Clarify stalling requirements. - Be more clear that that DMA_BUF_IOCTL_SYNC with SINC_END has to be called before more GPU work happens. Signed-off-by: Jason Ekstrand <jason(a)jlekstrand.net> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Acked-by: Christian König <christian.koenig(a)amd.com> Acked-by: Pekka Paalanen <pekka.paalanen(a)collabora.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> --- Documentation/driver-api/dma-buf.rst | 8 +++++ include/uapi/linux/dma-buf.h | 50 +++++++++++++++++++++++++++- 2 files changed, 57 insertions(+), 1 deletion(-) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 7f21425d9435a..0d4c13ec1a800 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -88,6 +88,9 @@ consider though: - The DMA buffer FD is also pollable, see `Implicit Fence Poll Support`_ below for details. +- The DMA buffer FD also supports a few dma-buf-specific ioctls, see + `DMA Buffer ioctls`_ below for details. + Basic Operation and Device DMA Access ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -106,6 +109,11 @@ Implicit Fence Poll Support .. kernel-doc:: drivers/dma-buf/dma-buf.c :doc: implicit fence polling +DMA Buffer ioctls +~~~~~~~~~~~~~~~~~ + +.. kernel-doc:: include/uapi/linux/dma-buf.h + Kernel Functions and Structures Reference ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/include/uapi/linux/dma-buf.h b/include/uapi/linux/dma-buf.h index 7f30393b92c3b..8e4a2ca0bcbf7 100644 --- a/include/uapi/linux/dma-buf.h +++ b/include/uapi/linux/dma-buf.h @@ -22,8 +22,56 @@ #include <linux/types.h> -/* begin/end dma-buf functions used for userspace mmap. */ +/** + * struct dma_buf_sync - Synchronize with CPU access. + * + * When a DMA buffer is accessed from the CPU via mmap, it is not always + * possible to guarantee coherency between the CPU-visible map and underlying + * memory. To manage coherency, DMA_BUF_IOCTL_SYNC must be used to bracket + * any CPU access to give the kernel the chance to shuffle memory around if + * needed. + * + * Prior to accessing the map, the client must call DMA_BUF_IOCTL_SYNC + * with DMA_BUF_SYNC_START and the appropriate read/write flags. Once the + * access is complete, the client should call DMA_BUF_IOCTL_SYNC with + * DMA_BUF_SYNC_END and the same read/write flags. + * + * The synchronization provided via DMA_BUF_IOCTL_SYNC only provides cache + * coherency. It does not prevent other processes or devices from + * accessing the memory at the same time. If synchronization with a GPU or + * other device driver is required, it is the client's responsibility to + * wait for buffer to be ready for reading or writing before calling this + * ioctl with DMA_BUF_SYNC_START. Likewise, the client must ensure that + * follow-up work is not submitted to GPU or other device driver until + * after this ioctl has been called with DMA_BUF_SYNC_END? + * + * If the driver or API with which the client is interacting uses implicit + * synchronization, waiting for prior work to complete can be done via + * poll() on the DMA buffer file descriptor. If the driver or API requires + * explicit synchronization, the client may have to wait on a sync_file or + * other synchronization primitive outside the scope of the DMA buffer API. + */ struct dma_buf_sync { + /** + * @flags: Set of access flags + * + * DMA_BUF_SYNC_START: + * Indicates the start of a map access session. + * + * DMA_BUF_SYNC_END: + * Indicates the end of a map access session. + * + * DMA_BUF_SYNC_READ: + * Indicates that the mapped DMA buffer will be read by the + * client via the CPU map. + * + * DMA_BUF_SYNC_WRITE: + * Indicates that the mapped DMA buffer will be written by the + * client via the CPU map. + * + * DMA_BUF_SYNC_RW: + * An alias for DMA_BUF_SYNC_READ | DMA_BUF_SYNC_WRITE. + */ __u64 flags; }; -- 2.31.1

1 0

Fixing problems around shared fences and RCU in DMA-buf
by Christian König 17 Jun '21

17 Jun '21

Hi everyone and especially Daniel, this is the revised patch set to fix and rework dma_buf_poll(). The new code should avoid problems with RCU and also now correctly waits for all fences in the resv object. The rest of the series is then the well known change to dma_resv_test_signaled(), nouveau and now new also msm. Then last are two patches which drop the workarounds from amdgpu, but those can wait till the next cycle. I think it would be rather good if the have at least to change to dma_buf_poll() pushed in this merge window and maybe even CC stable since this looks really broken to me. Please review, test and/or comment. Thanks, Christian.

2 8

← Newer
1
...
39
40
41
42
43
44
45
...
88
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2021