dri-devel September 2021

dri-devel@lists.freedesktop.org

348 participants
817 discussions

[PATCH net-next 0/5] brcm ASP 2.0 Ethernet controller
by Justin Chen 04 Oct '21

04 Oct '21

This patch set adds support for Broadcom's ASP 2.0 Ethernet controller. Florian Fainelli (1): dt-bindings: net: Brcm ASP 2.0 Ethernet controller Justin Chen (4): dt-bindings: net: brcm,unimac-mdio: Add asp-v2.0 net: bcmasp: Add support for ASP2.0 Ethernet controller net: phy: mdio-bcm-unimac: Add asp v2.0 support MAINTAINERS: ASP 2.0 Ethernet driver maintainers .../devicetree/bindings/net/brcm,asp-v2.0.yaml | 147 ++ .../devicetree/bindings/net/brcm,unimac-mdio.yaml | 1 + MAINTAINERS | 9 + drivers/net/ethernet/broadcom/Kconfig | 11 + drivers/net/ethernet/broadcom/Makefile | 1 + drivers/net/ethernet/broadcom/asp2/Makefile | 2 + drivers/net/ethernet/broadcom/asp2/bcmasp.c | 1351 +++++++++++++++++++ drivers/net/ethernet/broadcom/asp2/bcmasp.h | 565 ++++++++ .../net/ethernet/broadcom/asp2/bcmasp_ethtool.c | 628 +++++++++ drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c | 1414 ++++++++++++++++++++ .../net/ethernet/broadcom/asp2/bcmasp_intf_defs.h | 187 +++ drivers/net/mdio/mdio-bcm-unimac.c | 1 + 12 files changed, 4317 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/brcm,asp-v2.0.yaml create mode 100644 drivers/net/ethernet/broadcom/asp2/Makefile create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp.c create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp.h create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_ethtool.c create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c create mode 100644 drivers/net/ethernet/broadcom/asp2/bcmasp_intf_defs.h -- 2.7.4

5 16

[PATCH v2] drm/i915: Clean up disabled warnings
by Nathan Chancellor 04 Oct '21

04 Oct '21

i915 enables a wider set of warnings with '-Wall -Wextra' then disables several with cc-disable-warning. If an unknown flag gets added to KBUILD_CFLAGS when building with clang, all subsequent calls to cc-{disable-warning,option} will fail, meaning that all of these warnings do not get disabled [1]. A separate series will address the root cause of the issue by not adding these flags when building with clang [2]; however, the symptom of these extra warnings appearing can be addressed separately by just removing the calls to cc-disable-warning, which makes the build ever so slightly faster because the compiler does not need to be called as much before building. The following warnings are supported by GCC 4.9 and clang 10.0.1, which are the minimum supported versions of these compilers so the call to cc-disable-warning is not necessary. Masahiro cleaned this up for the reset of the kernel in commit 4c8dd95a723d ("kbuild: add some extra warning flags unconditionally"). * -Wmissing-field-initializers * -Wsign-compare * -Wtype-limits * -Wunused-parameter -Wunused-but-set-variable was implemented in clang 13.0.0 and -Wframe-address was implemented in clang 12.0.0 so the cc-disable-warning calls are kept for these two warnings. Lastly, -Winitializer-overrides is clang's version of -Woverride-init, which is disabled for the specific files that are problematic. clang added a compatibility alias in clang 8.0.0 so -Winitializer-overrides can be removed. [1]: https://lore.kernel.org/r/202108210311.CBtcgoUL-lkp@intel.com/ [2]: https://lore.kernel.org/r/20210824022640.2170859-1-nathan@kernel.org/ Reviewed-by: Nick Desaulniers <ndesaulniers(a)google.com> Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> --- v1 -> v2: https://lore.kernel.org/r/20210824232237.2085342-1-nathan@kernel.org/ * Rebase on drm-intel-gt-next now that the prerequisite patch series has been merged: https://lore.kernel.org/r/87wnnj13t5.fsf@intel.com/ * Add Nick's reviewed-by tag. drivers/gpu/drm/i915/Makefile | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index c584188aa15a..fd99374583d5 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -13,13 +13,11 @@ # will most likely get a sudden build breakage... Hopefully we will fix # new warnings before CI updates! subdir-ccflags-y := -Wall -Wextra -subdir-ccflags-y += $(call cc-disable-warning, unused-parameter) -subdir-ccflags-y += $(call cc-disable-warning, type-limits) -subdir-ccflags-y += $(call cc-disable-warning, missing-field-initializers) +subdir-ccflags-y += -Wno-unused-parameter +subdir-ccflags-y += -Wno-type-limits +subdir-ccflags-y += -Wno-missing-field-initializers +subdir-ccflags-y += -Wno-sign-compare subdir-ccflags-y += $(call cc-disable-warning, unused-but-set-variable) -# clang warnings -subdir-ccflags-y += $(call cc-disable-warning, sign-compare) -subdir-ccflags-y += $(call cc-disable-warning, initializer-overrides) subdir-ccflags-y += $(call cc-disable-warning, frame-address) subdir-ccflags-$(CONFIG_DRM_I915_WERROR) += -Werror base-commit: 43192617f7816bb74584c1df06f57363afd15337 -- 2.33.0

2 1

[PATCH v5 00/15] eDP: Support probing eDP panels dynamically instead of hardcoding
by Douglas Anderson 04 Oct '21

04 Oct '21

The goal of this patch series is to move away from hardcoding exact eDP panels in device tree files. As discussed in the various patches in this series (I'm not repeating everything here), most eDP panels are 99% probable and we can get that last 1% by allowing two "power up" delays to be specified in the device tree file and then using the panel ID (found in the EDID) to look up additional power sequencing delays for the panel. This patch series is the logical contiunation of a previous patch series where I proposed solving this problem by adding a board-specific compatible string [1]. In the discussion that followed it sounded like people were open to something like the solution proposed in this new series. In version 2 I got rid of the idea that we could have a "fallback" compatible string that we'd use if we didn't recognize the ID in the EDID. This simplifies the bindings a lot and the implementation somewhat. As a result of not having a "fallback", though, I'm not confident in transitioning any existing boards over to this since we'll have to fallback to very conservative timings if we don't recognize the ID from the EDID and I can't guarantee that I've seen every panel that might have shipped on an existing product. The plan is to use "edp-panel" only on new boards or new revisions of old boards where we can guarantee that every EDID that ships out of the factory has an ID in the table. Version 3 of this series now splits out all eDP panels to their own driver and adds the generic eDP panel support to this new driver. I believe this is what Sam was looking for [2]. Version 4 of this series is mostly small fixes / renames from review feedback. It's largely the same as v3. Other than naming / description / comment changes, the differences are: - Dropped the MIPS config patch as per request. - Reorder config patches first. - Added a new patch to use the panel ID scheme for quirks. - Landed the reorder of logicpd_type_28 / mitsubishi_aa070mc01 Version 5 of this series just fixes the panel ID encode macro to be cleaner and adds Jani's review tags. It could possibly be ready to land? [1] https://lore.kernel.org/r/YFKQaXOmOwYyeqvM@google.com/ [2] https://lore.kernel.org/r/YRTsFNTn%2FT8fLxyB@ravnborg.org/ Changes in v5: - Prettier encode panel ID function (thanks Andrzej!) - Probable => Probeable Changes in v4: - "u8 *edid" => "void *edid" to avoid cast. - ("Use new encoded panel id style for quirks matching") new for v4. - Don't put kmalloc() in the "if" test even if the old code did. - Don't refer to "panel-simple" in commit message. - PANEL_SIMPLE_EDP => PANEL_EDP - Remove "non-eDP" in panel-simple description. - Reordered config patches to be before code patch - decode_edid_id() => drm_edid_decode_panel_id() - drm_do_get_edid_blk0() => drm_do_get_edid_base_block() - drm_get_panel_id() => drm_edid_get_panel_id() - encode_edid_id() => drm_edid_encode_panel_id() - panel-simple-edp => panel-edp - split panel id extraction out to its own function. Changes in v3: - ("Better describe eDP panel delays") new for v3. - ("Don't re-read the EDID every time") moved to eDP only patch. - ("Non-eDP panels don't need "HPD" handling") new for v3. - Add AUO B116XAN06.1 to table. - Add Sharp LQ116M1JW10 to table. - Adjust endianness of product ID. - Change init order to we power at the end. - Decode hex product ID w/ same endianness as everyone else. - Fallback to conservative delays if panel not recognized. - Fix "prepare_to_enable" patch new for v3. - Generic "edp-panel" handled by the eDP panel driver now. - Move wayward panels patch new for v3. - Rename delays more generically so they can be reused. - Split eDP panels patch new for v3. - Split the delay structure out patch just on eDP now. Changes in v2: - Add "-ms" suffix to delays. - Don't support a "fallback" panel. Probed panels must be probed. - No longer allow fallback to panel-simple. - Not based on patch to copy "desc"--just allocate for probed panels. Douglas Anderson (15): dt-bindings: drm/panel-simple-edp: Introduce generic eDP panels drm/edid: Break out reading block 0 of the EDID drm/edid: Allow querying/working with the panel ID from the EDID drm/edid: Use new encoded panel id style for quirks matching ARM: configs: Everyone who had PANEL_SIMPLE now gets PANEL_EDP arm64: defconfig: Everyone who had PANEL_SIMPLE now gets PANEL_EDP drm/panel-edp: Split eDP panels out of panel-simple drm/panel-edp: Move some wayward panels to the eDP driver drm/panel-simple: Non-eDP panels don't need "HPD" handling drm/panel-edp: Split the delay structure out drm/panel-edp: Better describe eDP panel delays drm/panel-edp: hpd_reliable shouldn't be subtraced from hpd_absent drm/panel-edp: Fix "prepare_to_enable" if panel doesn't handle HPD drm/panel-edp: Don't re-read the EDID every time we power off the panel drm/panel-edp: Implement generic "edp-panel"s probed by EDID .../bindings/display/panel/panel-edp.yaml | 188 ++ arch/arm/configs/at91_dt_defconfig | 1 + arch/arm/configs/exynos_defconfig | 1 + arch/arm/configs/imx_v6_v7_defconfig | 1 + arch/arm/configs/lpc32xx_defconfig | 1 + arch/arm/configs/multi_v5_defconfig | 1 + arch/arm/configs/multi_v7_defconfig | 1 + arch/arm/configs/omap2plus_defconfig | 1 + arch/arm/configs/qcom_defconfig | 1 + arch/arm/configs/realview_defconfig | 1 + arch/arm/configs/sama5_defconfig | 1 + arch/arm/configs/shmobile_defconfig | 1 + arch/arm/configs/sunxi_defconfig | 1 + arch/arm/configs/tegra_defconfig | 1 + arch/arm/configs/versatile_defconfig | 1 + arch/arm/configs/vexpress_defconfig | 1 + arch/arm64/configs/defconfig | 1 + drivers/gpu/drm/drm_edid.c | 280 ++- drivers/gpu/drm/panel/Kconfig | 16 +- drivers/gpu/drm/panel/Makefile | 1 + drivers/gpu/drm/panel/panel-edp.c | 1895 +++++++++++++++++ drivers/gpu/drm/panel/panel-simple.c | 1072 +--------- include/drm/drm_edid.h | 45 + 23 files changed, 2351 insertions(+), 1162 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/panel/panel-edp.yaml create mode 100644 drivers/gpu/drm/panel/panel-edp.c -- 2.33.0.309.g3052b89438-goog

6 24

[PATCH] dt-bindings: drm/bridge: ti-sn65dsi86: Fix reg value
by Geert Uytterhoeven 04 Oct '21

04 Oct '21

make dtbs_check: arch/arm64/boot/dts/qcom/sdm850-lenovo-yoga-c630.dt.yaml: bridge@2c: reg:0:0: 45 was expected According to the datasheet, the I2C address can be either 0x2c or 0x2d, depending on the ADDR control input. Fixes: e3896e6dddf0b821 ("dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings") Signed-off-by: Geert Uytterhoeven <geert+renesas(a)glider.be> --- Also seen with the in-flight Falcon DSI display output patch: arch/arm64/boot/dts/renesas/r8a779a0-falcon.dt.yaml: sn65dsi86@2c: reg:0:0: 45 was expected --- .../devicetree/bindings/display/bridge/ti,sn65dsi86.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml index 1c2daf7c24cc0417..911564468c5e0f86 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.yaml @@ -18,7 +18,7 @@ properties: const: ti,sn65dsi86 reg: - const: 0x2d + enum: [ 0x2c, 0x2d ] enable-gpios: maxItems: 1 -- 2.25.1

4 3

[PATCH v5 0/8] drm/panfrost: drm/panfrost: Add a new submit ioctl
by Boris Brezillon 04 Oct '21

04 Oct '21

Hello, I finally got to resubmitting a new version of this series. I think I fixed all the issues reported by Steve and Daniel. Still no support for {IN,OUT}_FENCE_FD, but that can be added later if we need it. For those who didn't follow the previous iterations, this is an attempt at providing a new submit ioctl that's more Vulkan-friendly than the existing one. This ioctl 1/ allows passing several out syncobjs so we can easily update several fence/semaphore in a single ioctl() call 2/ allows passing several jobs so we don't have to have one ioctl per job-chain recorded in the command buffer 3/ supports disabling implicit dependencies as well as non-exclusive access to BOs, thus removing unnecessary synchronization I've also been looking at adding {IN,OUT}_FENCE_FD support (allowing one to pass at most one sync_file object in input and/or creating a sync_file FD embedding the render out fence), but it's not entirely clear to me when that's useful. Indeed, we can already do the sync_file <-> syncobj conversion using the SYNCOBJ_{FD_TO_HANDLE,HANDLE_TO_FD} ioctls if we have to. Note that, unlike Turnip, PanVk is using syncobjs to implement vkQueueWaitIdle(), so the syncobj -> sync_file conversion doesn't have to happen for each submission, but maybe there's a good reason to use sync_files for that too. Any feedback on that aspect would be useful I guess. Any feedback on this new ioctl is welcome, in particular, do you think other things are missing/would be nice to have for Vulkan? Regards, Boris P.S.: basic igt tests for these new ioctls re available there [1] [1]https://gitlab.freedesktop.org/bbrezillon/igt-gpu-tools/-/tree/panfrost-b… Boris Brezillon (8): drm/panfrost: Pass a job to panfrost_{acquire,attach}_object_fences() drm/panfrost: Move the mappings collection out of panfrost_lookup_bos() drm/panfrost: Add BO access flags to relax dependencies between jobs drm/panfrost: Add the ability to create submit queues drm/panfrost: Add a new ioctl to submit batches drm/panfrost: Support synchronization jobs drm/panfrost: Advertise the SYNCOBJ_TIMELINE feature drm/panfrost: Bump minor version to reflect the feature additions drivers/gpu/drm/panfrost/Makefile | 3 +- drivers/gpu/drm/panfrost/panfrost_device.h | 2 +- drivers/gpu/drm/panfrost/panfrost_drv.c | 637 +++++++++++++----- drivers/gpu/drm/panfrost/panfrost_job.c | 93 ++- drivers/gpu/drm/panfrost/panfrost_job.h | 8 +- .../gpu/drm/panfrost/panfrost_submitqueue.c | 132 ++++ .../gpu/drm/panfrost/panfrost_submitqueue.h | 26 + include/uapi/drm/panfrost_drm.h | 119 ++++ 8 files changed, 796 insertions(+), 224 deletions(-) create mode 100644 drivers/gpu/drm/panfrost/panfrost_submitqueue.c create mode 100644 drivers/gpu/drm/panfrost/panfrost_submitqueue.h -- 2.31.1

2 12

[PATCH 0/4] drm/i915: Fix older platforms
by Ville Syrjala 04 Oct '21

04 Oct '21

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Fix a div-by-zero on gen2, and make the L-shaped memory detection actually work on cl/ctg. Atm the SWIZZLE_UNKNOWN stuff just trips some GEM_BUG_ONs. This doesn't fix those but since I populate all my memory channels symmetrically I get to avoid the GEM_BUG_ONs by correctly detecting that I don't have an L-shaped memory configuration. Ville Syrjälä (4): drm/i915: Avoid div-by-zero on gen2 drm/i915: Read C0DRB3/C1DRB3 as 16 bits again drm/i915: Give C0DRB3/C1DRB3 a _BW suffix drm/i915: Rewrite CL/CTG L-shaped memory detection drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +- drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c | 19 ++++++++++--------- drivers/gpu/drm/i915/i915_debugfs.c | 16 ++++++++++++---- drivers/gpu/drm/i915/i915_reg.h | 8 ++++++-- 4 files changed, 29 insertions(+), 16 deletions(-) -- 2.26.3

3 11

[RFC 0/6] CPU + GPU synchronised priority scheduling
by Tvrtko Ursulin 04 Oct '21

04 Oct '21

From: Tvrtko Ursulin <tvrtko.ursulin(a)intel.com> This is a somewhat early sketch of one of my ideas intended for early feedback from the core scheduler experts. First and last two patches in the series are the most interesting ones for people outside of i915. (Note I did not copy everyone on all patches but just the cover letter for context and the rest should be available from the mailing list.) General idea is that current processing landscape seems to be more and more composed of pipelines where computations are done on multiple hardware devices. Furthermore some of the non-CPU devices, like in this case many GPUs supported by the i915 driver, actually support priority based scheduling which is currently rather inaccesible to the user (in terms of being able to control it from the outside). >From these two statements a question arises on how to allow for a simple, effective and consolidated user experience. In other words why user would not be able to do something like: $ nice ffmmpeg ...transcode my videos... $ my-favourite-game And have the nice hint apply to GPU parts of the transcode pipeline as well? Another reason why I started thinking about this is that I noticed Chrome browser for instance uses nice to de-prioritise background tabs. So again, having that decision propagate to the GPU rendering pipeline sounds like a big plus to the overall user experience. This RFC implements this idea with the hairy part being the notifier chain I added to enable dynamic adjustments. It is a global notifier which raises a few questions so I am very curious what experts will think here. Please see the opens in the first patch for more on this. And also the last two patches are the ones which implement a hash table in i915 so it can associate the notifier call- back with the correct GPU rendering contexts. On a more positive note the thing seems to even work as is. For instance I roughly simulated the above scenario by running a GPU hog at three nice levels and a GfxBench TRex in parallel (as a game proxy). This is what I got: GPU hog nice | TRex fps ------------------------------ 0 | 34.8 10 | 38.0 -10 | 30.8 So it is visible the feature can improve the user experience. Question is just if people are happy with this method of implementing it. Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Juri Lelli <juri.lelli(a)redhat.com> Cc: Vincent Guittot <vincent.guittot(a)linaro.org> Tvrtko Ursulin (6): sched: Add nice value change notifier drm/i915: Explicitly track DRM clients drm/i915: Make GEM contexts track DRM clients drm/i915: Track all user contexts per client drm/i915: Keep track of registered clients indexed by task struct drm/i915: Connect task and GPU scheduling priorities drivers/gpu/drm/i915/Makefile | 5 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 20 +++ .../gpu/drm/i915/gem/i915_gem_context_types.h | 6 + .../drm/i915/gt/intel_execlists_submission.c | 2 +- drivers/gpu/drm/i915/i915_drm_client.c | 129 ++++++++++++++++++ drivers/gpu/drm/i915/i915_drm_client.h | 71 ++++++++++ drivers/gpu/drm/i915/i915_drv.c | 6 + drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_gem.c | 21 ++- drivers/gpu/drm/i915/i915_request.c | 2 +- drivers/gpu/drm/i915/i915_request.h | 5 + drivers/gpu/drm/i915/i915_scheduler.c | 3 +- drivers/gpu/drm/i915/i915_scheduler.h | 14 ++ drivers/gpu/drm/i915/i915_scheduler_types.h | 8 ++ include/linux/sched.h | 5 + kernel/sched/core.c | 37 ++++- 16 files changed, 330 insertions(+), 9 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_drm_client.c create mode 100644 drivers/gpu/drm/i915/i915_drm_client.h -- 2.30.2

2 13

[PATCH v2 00/17] drm: cleanup: Use DRM_MODESET_LOCK_ALL_* helpers where possible
by Fernando Ramos 04 Oct '21

04 Oct '21

Hi all, One of the things in the DRM TODO list ("Documentation/gpu/todo.rst") was to "use DRM_MODESET_LOCAL_ALL_* helpers instead of boilerplate". That's what this patch series is about. You will find two types of changes here: - Replacing "drm_modeset_lock_all_ctx()" (and surrounding boilerplate) with "DRM_MODESET_LOCK_ALL_BEGIN()/END()" in the remaining places (as it has already been done in previous commits such as b7ea04d2) - Replacing "drm_modeset_lock_all()" with "DRM_MODESET_LOCK_ALL_BEGIN()/END()" in the remaining places (as it has already been done in previous commits such as 57037094) Most of the changes are straight forward, except for a few cases in the "amd" and "i915" drivers where some extra dancing was needed to overcome the limitation that the DRM_MODESET_LOCK_ALL_BEGIN()/END() macros can only be used once inside the same function (the reason being that the macro expansion includes *labels*, and you can not have two labels named the same inside one function) Notice that, even after this patch series, some places remain where "drm_modeset_lock_all()" and "drm_modeset_lock_all_ctx()" are still present, all inside drm core (which makes sense), except for two (in "amd" and "i915") which cannot be replaced due to the way they are being used. Changes in v2: - Fix commit message typo - Use the value returned by DRM_MODESET_LOCK_ALL_END when possible - Split drm/i915 patch into two simpler ones - Remove drm_modeset_(un)lock_all() - Fix build problems in non-x86 platforms Fernando Ramos (17): drm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/i915: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/msm: cleanup: drm_modeset_lock_all_ctx() --> DRM_MODESET_LOCK_ALL_BEGIN() drm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/vmwgfx: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/tegra: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/shmobile: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/radeon: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/omapdrm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/nouveau: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/msm: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/i915: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() part 2 drm/gma500: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm/amd: cleanup: drm_modeset_lock_all() --> DRM_MODESET_LOCK_ALL_BEGIN() drm: cleanup: remove drm_modeset_(un)lock_all() doc: drm: remove TODO entry regarding DRM_MODSET_LOCK_ALL cleanup Documentation/gpu/todo.rst | 17 ---- Documentation/locking/ww-mutex-design.rst | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 21 +++-- .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 50 +++++----- .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 25 ++--- drivers/gpu/drm/drm_client_modeset.c | 14 ++- drivers/gpu/drm/drm_crtc_helper.c | 18 ++-- drivers/gpu/drm/drm_fb_helper.c | 10 +- drivers/gpu/drm/drm_framebuffer.c | 6 +- drivers/gpu/drm/drm_modeset_lock.c | 94 +------------------ drivers/gpu/drm/gma500/psb_device.c | 18 ++-- drivers/gpu/drm/i915/display/intel_audio.c | 16 ++-- drivers/gpu/drm/i915/display/intel_display.c | 23 ++--- .../drm/i915/display/intel_display_debugfs.c | 46 +++++---- drivers/gpu/drm/i915/display/intel_overlay.c | 46 ++++----- drivers/gpu/drm/i915/display/intel_pipe_crc.c | 7 +- drivers/gpu/drm/i915/i915_drv.c | 13 ++- drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 10 +- .../gpu/drm/msm/disp/msm_disp_snapshot_util.c | 12 +-- drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 ++- drivers/gpu/drm/omapdrm/omap_fb.c | 9 +- drivers/gpu/drm/radeon/radeon_device.c | 21 +++-- drivers/gpu/drm/radeon/radeon_dp_mst.c | 10 +- drivers/gpu/drm/shmobile/shmob_drm_drv.c | 6 +- drivers/gpu/drm/tegra/dsi.c | 6 +- drivers/gpu/drm/tegra/hdmi.c | 6 +- drivers/gpu/drm/tegra/sor.c | 11 ++- drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 11 ++- drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 12 ++- include/drm/drm_modeset_lock.h | 2 - 30 files changed, 265 insertions(+), 292 deletions(-) base-commit: 6880fa6c56601bb8ed59df6c30fd390cc5f6dd8f -- 2.33.0

4 28

[PATCH 00/10] drm/gma500: Refactor GEM code
by Thomas Zimmermann 04 Oct '21

04 Oct '21

Bring GEM code up to current standards and untangle the connection to GTT helpers. The allocation and pinning helpers for struct gtt_range are located in the GTT code, but actually part of the GEM implementation. The patchset moves them to GEM code and refactors much of the implementation. Most of the GTT code is then independend from the struct gtt_range, while the GEM code does not contain GTT management. In addition to internal refiactoring, patches 2 to 4 update the rest of the driver to use the GEM interfaces for object allocation and release. Finally, rename struct gtt_range to struct psb_gem_object to designate it as a 'real' GEM object. Future work: with the GEM and GTT code separated, future patchsets can implement on-demand release of GTT entries, or remove the perma-mapping of stolen memory. Dma-buf support might also be added. Tested on Atom N2800 hardware. Thomas Zimmermann (10): drm/gma500: Move helpers for struct gtt_range from gtt.c to gem.c drm/gma500: Use to_gtt_range() everywhere drm/gma500: Reimplement psb_gem_create() drm/gma500: Allocate GTT ranges in stolen memory with psb_gem_create() drm/gma500: Rename psb_gtt_{pin,unpin}() to psb_gem_{pin,unpin}() drm/gma500: Inline psb_gtt_attach_pages() and psb_gtt_detach_pages() drm/gma500: Inline psb_gtt_{alloc,free}_range() into rsp callers drm/gma500: Set page-caching flags in GEM pin/unpin drm/gma500: Rewrite GTT page insert/remove without struct gtt_range drm/gma500: Rename struct gtt_range to struct psb_gem_object drivers/gpu/drm/gma500/framebuffer.c | 52 +--- drivers/gpu/drm/gma500/gem.c | 227 +++++++++++---- drivers/gpu/drm/gma500/gem.h | 28 +- drivers/gpu/drm/gma500/gma_display.c | 51 ++-- drivers/gpu/drm/gma500/gtt.c | 320 ++++----------------- drivers/gpu/drm/gma500/gtt.h | 29 +- drivers/gpu/drm/gma500/oaktrail_crtc.c | 3 +- drivers/gpu/drm/gma500/psb_intel_display.c | 17 +- drivers/gpu/drm/gma500/psb_intel_drv.h | 2 +- 9 files changed, 310 insertions(+), 419 deletions(-) -- 2.33.0

2 24

[PATCH v5 00/16] Add MediaTek SoC DRM (vdosys1) support for mt8195
by Nancy.Lin 04 Oct '21

04 Oct '21

The hardware path of vdosys1 with DPTx output need to go through by several modules, such as, OVL_ADAPTOR and MERGE. Add DRM and these modules support by the patches below: Changes in v5: - add mmsys reset controller reference. Changes in v4: - use merge common driver for merge1~4. - refine ovl_adaptor rdma driver. - use ovl_adaptor ddp_comp function instead of ethdr. - modify for reviewer's comment in v3. Changes in v3: - modify for reviewer's comment in v2. - add vdosys1 2 pixels align limit. - add mixer odd offset support. Changes in v2: - Merge PSEUDO_OVL and ETHDR into one DRM component. - Add mmsys config API for vdosys1 hardware setting. - Add mmsys reset control using linux reset framework. Signed-off-by: Nancy.Lin <nancy.lin(a)mediatek.com> This series are based on the following patch: [1] arm64: dts: Add Mediatek SoC MT8195 and evaluation board dts and Makefile https://patchwork.kernel.org/project/linux-mediatek/patch/20210601075350.31… [2] arm64: dts: mt8195: add IOMMU and smi nodes https://patchwork.kernel.org/project/linux-mediatek/patch/20210615173233.26… [3] [01/24] dt-bindings: mediatek: mt8195: Add binding for MM IOMMU https://patchwork.kernel.org/project/linux-mediatek/patch/20210630023504.18… [4] Add gce support for mt8195 https://patchwork.kernel.org/project/linux-mediatek/list/?series=537069 [5] Add MediaTek SoC DRM (vdosys0) support for mt8195 https://patchwork.kernel.org/project/linux-mediatek/list/?series=537225 [6] [v8,1/2] dt-bindings: reset: mt8195: add toprgu reset-controller header file https://patchwork.kernel.org/project/linux-mediatek/patch/20210806023606.16… [7] [v3,2/7] dt-bindings: mediatek: Add #reset-cells to mmsys system controller https://patchwork.kernel.org/project/linux-mediatek/patch/20210825122613.v3… [8] [v3,6/7] soc: mediatek: mmsys: Add reset controller support https://patchwork.kernel.org/project/linux-mediatek/patch/20210825122613.v3… Nancy.Lin (16): dt-bindings: mediatek: add vdosys1 RDMA definition for mt8195 dt-bindings: mediatek: add vdosys1 MERGE property for mt8195 dt-bindings: mediatek: add ethdr definition for mt8195 dt-bindings: reset: mt8195: add vdosys1 reset control bit arm64: dts: mt8195: add display node for vdosys1 soc: mediatek: add mtk-mmsys support for mt8195 vdosys1 soc: mediatek: add mtk-mmsys config API for mt8195 vdosys1 soc: mediatek: add cmdq support of mtk-mmsys config API for mt8195 vdosys1 soc: mediatek: mmsys: modify reset controller for MT8195 vdosys1 soc: mediatek: add mtk-mutex support for mt8195 vdosys1 drm/mediatek: add display MDP RDMA support for MT8195 drm/mediatek: add display merge api support for MT8195 drm/mediatek: add ETHDR support for MT8195 drm/mediatek: add ovl_adaptor support for MT8195 drm/mediatek: modify mediatek-drm for mt8195 multi mmsys support drm/mediatek: add mediatek-drm of vdosys1 support for MT8195 .../display/mediatek/mediatek,ethdr.yaml | 144 ++++++ .../display/mediatek/mediatek,mdp-rdma.yaml | 77 ++++ .../display/mediatek/mediatek,merge.yaml | 3 + arch/arm64/boot/dts/mediatek/mt8195.dtsi | 221 +++++++++ drivers/gpu/drm/mediatek/Makefile | 5 +- drivers/gpu/drm/mediatek/mtk_disp_drv.h | 29 ++ drivers/gpu/drm/mediatek/mtk_disp_merge.c | 78 +++- .../gpu/drm/mediatek/mtk_disp_ovl_adaptor.c | 408 +++++++++++++++++ drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 25 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 3 +- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 15 + drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 + drivers/gpu/drm/mediatek/mtk_drm_drv.c | 377 +++++++++++++--- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 9 +- drivers/gpu/drm/mediatek/mtk_ethdr.c | 424 ++++++++++++++++++ drivers/gpu/drm/mediatek/mtk_ethdr.h | 25 ++ drivers/gpu/drm/mediatek/mtk_mdp_rdma.c | 301 +++++++++++++ drivers/gpu/drm/mediatek/mtk_mdp_rdma.h | 37 ++ drivers/soc/mediatek/mt8195-mmsys.h | 199 ++++++++ drivers/soc/mediatek/mtk-mmsys.c | 76 +++- drivers/soc/mediatek/mtk-mmsys.h | 11 + drivers/soc/mediatek/mtk-mutex.c | 270 ++++++----- include/dt-bindings/reset/mt8195-resets.h | 12 + include/linux/soc/mediatek/mtk-mmsys.h | 22 + 24 files changed, 2574 insertions(+), 198 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,ethdr.yaml create mode 100644 Documentation/devicetree/bindings/display/mediatek/mediatek,mdp-rdma.yaml create mode 100644 drivers/gpu/drm/mediatek/mtk_disp_ovl_adaptor.c create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.c create mode 100644 drivers/gpu/drm/mediatek/mtk_ethdr.h create mode 100644 drivers/gpu/drm/mediatek/mtk_mdp_rdma.c create mode 100644 drivers/gpu/drm/mediatek/mtk_mdp_rdma.h -- 2.18.0

4 33

← Newer
1
...
17
18
19
20
21
22
23
...
82
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2021