dri-devel July 2021

dri-devel@lists.freedesktop.org

321 participants
829 discussions

Re: [PATCH v2 0/9] PCI/VGA: Rework default VGA device selection
by Daniel Vetter 27 Jul '21

27 Jul '21

On Fri, Jul 23, 2021 at 06:51:59AM +0100, Christoph Hellwig wrote: > On Thu, Jul 22, 2021 at 04:29:11PM -0500, Bjorn Helgaas wrote: > > From: Bjorn Helgaas <bhelgaas(a)google.com> > > > > This is a little bit of rework and extension of Huacai's nice work at [1]. > > > > It moves the VGA arbiter to the PCI subsystem, fixes a few nits, and breaks > > a few pieces off Huacai's patch to make the main patch a little smaller. > > > > That last patch is still not very small, and it needs a commit log, as I > > mentioned at [2]. > > FYI, I have a bunch of changes to this code that the drm maintainers > picked up. They should show up in the next linux-next I think. Yeah I think for merging I think there'll be two options: - We also merge this series through drm-misc-next to avoid conflicts, but anything after that will (i.e. from 5.16-rc1 onwards) will go in through the pci tree. - You also merge Christoph's series, and we tell Linus to ignore the vgaarb changes that also come in through drm-next pull. It's a non-rebasing tree so taking them out isn't an option, and reverting feels silly. Either of the above is fine with me. Also I just noticed that the scrip has gone wrong for drm-misc-next and it's not actually yet in linux-next. I'll sort that out. Ok I just did sort that out while I forgot this reply draft here, one of our committers pushed a patch to the wrong branch. Luckily it was a broken one and the right fix is in the right branch (and already in Linus' tree), so a hard reset was all it took. So should be all in linux-next on the next update. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

2 2

[PATCH v5 00/15] drm/i915: Introduce Intel PXP
by Daniele Ceraolo Spurio 27 Jul '21

27 Jul '21

PXP (Protected Xe Path) is an i915 component, available on GEN12+, that helps to establish the hardware protected session and manage the status of the alive software session, as well as its life cycle. The main changes in v5 are: - Rebased to new proto_ctx implementation. - Squashed all uapi changes in a single patch and slightly updated docs. - Now handling mei_pxp loading after i915 Tested with: https://patchwork.freedesktop.org/series/87570/ Cc: Gaurav Kumar <kumar.gaurav(a)intel.com> Cc: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Rodrigo Vivi <rodrigo.vivi(a)intel.com> Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com> Cc: Juston Li <juston.li(a)intel.com> Cc: Alan Previn <alan.previn.teres.alexis(a)intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin(a)intel.com> Cc: Jason Ekstrand <jason(a)jlekstrand.net> Cc: Daniel Vetter <daniel.vetter(a)intel.com> Anshuman Gupta (2): drm/i915/pxp: Add plane decryption support drm/i915/pxp: black pixels on pxp disabled Daniele Ceraolo Spurio (7): drm/i915/pxp: Define PXP component interface drm/i915/pxp: define PXP device flag and kconfig drm/i915/pxp: allocate a vcs context for pxp usage drm/i915/pxp: set KCR reg init drm/i915/pxp: interfaces for using protected objects drm/i915/pxp: start the arb session on demand drm/i915/pxp: enable PXP for integrated Gen12 Huang, Sean Z (5): drm/i915/pxp: Implement funcs to create the TEE channel drm/i915/pxp: Create the arbitrary session after boot drm/i915/pxp: Implement arb session teardown drm/i915/pxp: Implement PXP irq handler drm/i915/pxp: Enable PXP power management Vitaly Lubart (1): mei: pxp: export pavp client to me client bus drivers/gpu/drm/i915/Kconfig | 11 + drivers/gpu/drm/i915/Makefile | 9 + .../gpu/drm/i915/display/intel_atomic_plane.c | 25 ++ drivers/gpu/drm/i915/display/intel_display.c | 4 + .../drm/i915/display/intel_display_types.h | 6 + .../drm/i915/display/skl_universal_plane.c | 49 +++- drivers/gpu/drm/i915/gem/i915_gem_context.c | 68 ++++- drivers/gpu/drm/i915/gem/i915_gem_context.h | 18 ++ .../gpu/drm/i915/gem/i915_gem_context_types.h | 2 + drivers/gpu/drm/i915/gem/i915_gem_create.c | 26 ++ .../gpu/drm/i915/gem/i915_gem_execbuffer.c | 42 ++- drivers/gpu/drm/i915/gem/i915_gem_object.c | 6 + drivers/gpu/drm/i915/gem/i915_gem_object.h | 12 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 13 + drivers/gpu/drm/i915/gt/intel_engine.h | 2 + drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 22 +- drivers/gpu/drm/i915/gt/intel_gt.c | 5 + drivers/gpu/drm/i915/gt/intel_gt_irq.c | 7 + drivers/gpu/drm/i915/gt/intel_gt_pm.c | 15 +- drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 + drivers/gpu/drm/i915/i915_drv.c | 2 + drivers/gpu/drm/i915/i915_drv.h | 4 + drivers/gpu/drm/i915/i915_pci.c | 2 + drivers/gpu/drm/i915/i915_reg.h | 48 ++++ drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/pxp/intel_pxp.c | 268 ++++++++++++++++++ drivers/gpu/drm/i915/pxp/intel_pxp.h | 67 +++++ drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c | 141 +++++++++ drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h | 15 + drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 100 +++++++ drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 32 +++ drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 40 +++ drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 23 ++ drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 172 +++++++++++ drivers/gpu/drm/i915/pxp/intel_pxp_session.h | 15 + drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 170 +++++++++++ drivers/gpu/drm/i915/pxp/intel_pxp_tee.h | 17 ++ .../drm/i915/pxp/intel_pxp_tee_interface.h | 37 +++ drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 55 ++++ drivers/misc/mei/Kconfig | 2 + drivers/misc/mei/Makefile | 1 + drivers/misc/mei/pxp/Kconfig | 13 + drivers/misc/mei/pxp/Makefile | 7 + drivers/misc/mei/pxp/mei_pxp.c | 233 +++++++++++++++ drivers/misc/mei/pxp/mei_pxp.h | 18 ++ include/drm/i915_component.h | 1 + include/drm/i915_pxp_tee_interface.h | 45 +++ include/uapi/drm/i915_drm.h | 58 +++- 48 files changed, 1917 insertions(+), 15 deletions(-) create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_cmd.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_irq.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_pm.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_session.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_session.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.c create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_tee_interface.h create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_types.h create mode 100644 drivers/misc/mei/pxp/Kconfig create mode 100644 drivers/misc/mei/pxp/Makefile create mode 100644 drivers/misc/mei/pxp/mei_pxp.c create mode 100644 drivers/misc/mei/pxp/mei_pxp.h create mode 100644 include/drm/i915_pxp_tee_interface.h -- 2.32.0

4 25

[PATCH] drm: document drm_mode_get_property
by Simon Ser 27 Jul '21

27 Jul '21

It's not obvious what the fields mean and how they should be used. The most important detail is the link to drm_property.flags, which describes how property types work. Signed-off-by: Simon Ser <contact(a)emersion.fr> Cc: Pekka Paalanen <pekka.paalanen(a)collabora.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Leandro Ribeiro <leandro.ribeiro(a)collabora.com> --- include/uapi/drm/drm_mode.h | 52 ++++++++++++++++++++++++++++++++++--- 1 file changed, 48 insertions(+), 4 deletions(-) diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index 98bf130feda5..dfdb595875aa 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -546,17 +546,61 @@ struct drm_mode_property_enum { char name[DRM_PROP_NAME_LEN]; }; +/** + * struct drm_mode_get_property - Get property metadata. + * + * User-space can perform a GETPROPERTY ioctl to retrieve information about a + * property. + * + * The meaning of the @values_ptr field changes depending on the property type. + * See &drm_property.flags for more details. + * + * The @enum_blob_ptr and @count_enum_blobs fields are only meaningful when the + * property has the type &DRM_MODE_PROP_ENUM or &DRM_MODE_PROP_BITMASK. For + * backwards compatibility, the kernel will always set @count_enum_blobs to + * zero when the property has the type &DRM_MODE_PROP_BLOB. User-space must + * ignore these two fields if the property has a different type. + * + * User-space is expected to retrieve values and enums by performing this ioctl + * at least twice: the first time to retrieve the number of elements, the + * second time to retrieve the elements themselves. + * + * To retrieve the number of elements, set @count_values and @count_enum_blobs + * to zero, then call the ioctl. @count_values will be updated with the number + * of elements. If the property has the type &DRM_MODE_PROP_ENUM or + * &DRM_MODE_PROP_BITMASK, @count_enum_blobs will be updated as well. + * + * To retrieve the elements themselves, allocate an array for @values_ptr and + * set @count_values to its capacity. If the property has the type + * &DRM_MODE_PROP_ENUM or &DRM_MODE_PROP_BITMASK, allocate an array for + * @enum_blob_ptr and set @count_enum_blobs to its capacity. Calling the ioctl + * again will fill the arrays. + */ struct drm_mode_get_property { - __u64 values_ptr; /* values and blob lengths */ - __u64 enum_blob_ptr; /* enum and blob id ptrs */ + /** @values_ptr: Pointer to a ``__u64`` array. */ + __u64 values_ptr; + /** @enum_blob_ptr: Pointer to a struct drm_mode_property_enum array. */ + __u64 enum_blob_ptr; + /** + * @prop_id: Object ID of the property which should be retrieved. Set + * by the caller. + */ __u32 prop_id; + /** + * @flags: ``DRM_MODE_PROP_*`` bitfield. See &drm_property.flags for + * a definition of the flags. + */ __u32 flags; + /** + * @name: Symbolic property name. User-space should use this field to + * recognize properties. + */ char name[DRM_PROP_NAME_LEN]; + /** @count_values: Number of elements in @values_ptr. */ __u32 count_values; - /* This is only used to count enum values, not blobs. The _blobs is - * simply because of a historical reason, i.e. backwards compat. */ + /** @count_enum_blobs: Number of elements in @enum_blob_ptr. */ __u32 count_enum_blobs; }; -- 2.32.0

3 5

[PATCH] drm/panel-sony-acx424akp: Modernize backlight handling
by Linus Walleij 27 Jul '21

27 Jul '21

This converts the internal backlight in the Sony ACX424AKP driver to do it the canonical way: - Assign the panel->backlight during probe. - Let the panel framework handle the backlight. - Make the backlight .set_brightness() turn the backlight off completely if blank. - Fix some dev_err_probe() use cases along the way. Tested on the U8500 HREF520 reference design. Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org> --- drivers/gpu/drm/panel/panel-sony-acx424akp.c | 84 +++++++------------- 1 file changed, 28 insertions(+), 56 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-sony-acx424akp.c b/drivers/gpu/drm/panel/panel-sony-acx424akp.c index 95659a4d15e9..163f0e0cee1c 100644 --- a/drivers/gpu/drm/panel/panel-sony-acx424akp.c +++ b/drivers/gpu/drm/panel/panel-sony-acx424akp.c @@ -40,7 +40,6 @@ struct acx424akp { struct drm_panel panel; struct device *dev; - struct backlight_device *bl; struct regulator *supply; struct gpio_desc *reset_gpio; bool video_mode; @@ -102,6 +101,20 @@ static int acx424akp_set_brightness(struct backlight_device *bl) u8 par; int ret; + + if (backlight_is_blank(bl)) { + /* Disable backlight */ + par = 0x00; + ret = mipi_dsi_dcs_write(dsi, MIPI_DCS_WRITE_CONTROL_DISPLAY, + &par, 1); + if (ret) { + dev_err(acx->dev, "failed to disable display backlight (%d)\n", ret); + return ret; + } + return 0; + } + + /* Calculate the PWM duty cycle in n/256's */ pwm_ratio = max(((duty_ns * 256) / period_ns) - 1, 1); pwm_div = max(1, @@ -172,6 +185,12 @@ static const struct backlight_ops acx424akp_bl_ops = { .update_status = acx424akp_set_brightness, }; +static const struct backlight_properties acx424akp_bl_props = { + .type = BACKLIGHT_PLATFORM, + .brightness = 512, + .max_brightness = 1023, +}; + static int acx424akp_read_id(struct acx424akp *acx) { struct mipi_dsi_device *dsi = to_mipi_dsi_device(acx->dev); @@ -310,8 +329,6 @@ static int acx424akp_prepare(struct drm_panel *panel) } } - acx->bl->props.power = FB_BLANK_NORMAL; - return 0; err_power_off: @@ -323,18 +340,8 @@ static int acx424akp_unprepare(struct drm_panel *panel) { struct acx424akp *acx = panel_to_acx424akp(panel); struct mipi_dsi_device *dsi = to_mipi_dsi_device(acx->dev); - u8 par; int ret; - /* Disable backlight */ - par = 0x00; - ret = mipi_dsi_dcs_write(dsi, MIPI_DCS_WRITE_CONTROL_DISPLAY, - &par, 1); - if (ret) { - dev_err(acx->dev, "failed to disable display backlight (%d)\n", ret); - return ret; - } - ret = mipi_dsi_dcs_set_display_off(dsi); if (ret) { dev_err(acx->dev, "failed to turn display off (%d)\n", ret); @@ -350,36 +357,10 @@ static int acx424akp_unprepare(struct drm_panel *panel) msleep(85); acx424akp_power_off(acx); - acx->bl->props.power = FB_BLANK_POWERDOWN; - - return 0; -} - -static int acx424akp_enable(struct drm_panel *panel) -{ - struct acx424akp *acx = panel_to_acx424akp(panel); - - /* - * The backlight is on as long as the display is on - * so no use to call backlight_enable() here. - */ - acx->bl->props.power = FB_BLANK_UNBLANK; return 0; } -static int acx424akp_disable(struct drm_panel *panel) -{ - struct acx424akp *acx = panel_to_acx424akp(panel); - - /* - * The backlight is on as long as the display is on - * so no use to call backlight_disable() here. - */ - acx->bl->props.power = FB_BLANK_NORMAL; - - return 0; -} static int acx424akp_get_modes(struct drm_panel *panel, struct drm_connector *connector) @@ -409,10 +390,8 @@ static int acx424akp_get_modes(struct drm_panel *panel, } static const struct drm_panel_funcs acx424akp_drm_funcs = { - .disable = acx424akp_disable, .unprepare = acx424akp_unprepare, .prepare = acx424akp_prepare, - .enable = acx424akp_enable, .get_modes = acx424akp_get_modes, }; @@ -458,25 +437,18 @@ static int acx424akp_probe(struct mipi_dsi_device *dsi) /* This asserts RESET by default */ acx->reset_gpio = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH); - if (IS_ERR(acx->reset_gpio)) { - ret = PTR_ERR(acx->reset_gpio); - if (ret != -EPROBE_DEFER) - dev_err(dev, "failed to request GPIO (%d)\n", ret); - return ret; - } + if (IS_ERR(acx->reset_gpio)) + return dev_err_probe(dev, PTR_ERR(acx->reset_gpio), + "failed to request GPIO\n"); drm_panel_init(&acx->panel, dev, &acx424akp_drm_funcs, DRM_MODE_CONNECTOR_DSI); - acx->bl = devm_backlight_device_register(dev, "acx424akp", dev, acx, - &acx424akp_bl_ops, NULL); - if (IS_ERR(acx->bl)) { - dev_err(dev, "failed to register backlight device\n"); - return PTR_ERR(acx->bl); - } - acx->bl->props.max_brightness = 1023; - acx->bl->props.brightness = 512; - acx->bl->props.power = FB_BLANK_POWERDOWN; + acx->panel.backlight = devm_backlight_device_register(dev, "acx424akp", dev, acx, + &acx424akp_bl_ops, &acx424akp_bl_props); + if (IS_ERR(acx->panel.backlight)) + return dev_err_probe(dev, PTR_ERR(acx->panel.backlight), + "failed to register backlight device\n"); drm_panel_add(&acx->panel); -- 2.31.1

2 1

[PATCH v4 0/7] drm/panfrost: drm/panfrost: Add a new submit ioctl
by Boris Brezillon 27 Jul '21

27 Jul '21

Hello, 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… Changes in v4: * Replace the desc strides by a version field * Change the submitqueue_create() prototype to return the queue id directly * Implement the old submit ioctl() as a simple wrapper around panfrost_submit_job() Changes in v3: * Fix a deadlock in the submitqueue logic * Limit the number of submitqueue per context to 16 *** BLURB HERE *** Boris Brezillon (7): 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: 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 | 611 +++++++++++++----- drivers/gpu/drm/panfrost/panfrost_job.c | 89 ++- drivers/gpu/drm/panfrost/panfrost_job.h | 10 +- .../gpu/drm/panfrost/panfrost_submitqueue.c | 132 ++++ .../gpu/drm/panfrost/panfrost_submitqueue.h | 26 + include/uapi/drm/panfrost_drm.h | 112 ++++ 8 files changed, 766 insertions(+), 219 deletions(-) create mode 100644 drivers/gpu/drm/panfrost/panfrost_submitqueue.c create mode 100644 drivers/gpu/drm/panfrost/panfrost_submitqueue.h -- 2.31.1

4 13

[PATCH v4 0/4] drm/amd/display: Introduce FPU directory inside DC
by Rodrigo Siqueira 27 Jul '21

27 Jul '21

Hi, In the display core, we utilize floats and doubles units for calculating modesetting parameters. One side effect of our approach to use double-precision is the fact that we spread multiple FPU access across our driver, which means that we can accidentally clobber user space FPU state. # Challenges 1. Keep in mind that this FPU code is ingrained in our display driver and performs several crucial tasks. Additionally, we already have multiple architectures available in the kernel and a large set of users; in other words, we prefer to avoid a radical approach that might break our user's system. 2. We share our display code with other OSs; thus, we need to maintain the interoperability between these two systems. 3. We need a mechanism for identifying which function uses FPU registers; fortunately, Peter Zijlstra wrote a series a couple of months ago where he introduced an FPU check for objtool. I used the following command for identifying the potential FPU usage: ./tools/objtool/objtool check -Ffa "drivers/gpu/drm/amd/display/dc/ANY_FILE.o" 4. Since our code heavily relies on FPU and the fact that we spread kernel_fpu_begin/end across multiple functions, we can have some complex scenarios that will require code refactoring. However, we want to avoid complicated changes since this is a formula to introduce regressions; we want something that allows us to fix it in small, safe, and reliable steps. 5. Unfortunately, for legacy reasons, we have some problems in how we program our FPU access, which in some weird scenarios can generate situations where we try to enter in the fpu mode multiple times or exit too early. # Our approach For trying to solve this problem, we came up with the following strategy: 1. Keep in mind that we are using kernel_fpu_begin/end spread in various areas and sometimes across multiple functions. If we try to move some of the functions to an isolated place, we can generate a situation where we can call the FPU protection more than once, causing multiple warnings. We can deal with this problem by adding a thin management layer around the kernel_fpu_begin/end used inside the display. 2. We will need a trace mechanism for this FPU management inside our display code. 3. After we get the thin layer that manages FPU, we can start to move each function that uses FPU to a centralized place. Our DQE runs multiple tests in different ASICs every week; we can take advantage of this to ensure that our FPU patches work does not introduce any regression. The idea is to work on a specific part of the code every week (e.g., week 1: DCN2, week 1: DCN2.1, etc.). 4. Finally, after we can isolate the FPU operations in a single place, we can altogether remove the FPU flags from other files and eliminate an unnecessary code introduced to deal with this problem. We can also remove the thin layer added in the step 3. # This series To maintain the interoperability between multiple OSes, we already have a define named DC_FP_START/END, which is a straightforward wrapper to kernel_fpu_begin/end in the Linux side. In this series, I decided to expand the scope of this DC_FP_* wrapper to trace FPU entrance and exit in the display code, but I also add a mechanism for managing the entrance and exit of kernel_fpu_begin/end. You can see the details on how I did that in the last two patches. I also isolate a simple function that requires FPU access to demonstrate my strategy for isolating this FPU access in a single place. If this series gets accepted, the following steps consist of moving all FPU functions weekly until we isolate everything in the DML folder. Cc: Harry Wentland <harry.wentland(a)amd.com> Cc: Anson Jacob <Anson.Jacob(a)amd.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: Hersen Wu <hersenxs.wu(a)amd.com> Cc: Aric Cyr <aric.cyr(a)amd.com> Cc: Jun Lei <jun.lei(a)amd.com> Cc: Dmytro Laktyushkin <dmytro.laktyushkin(a)amd.com> Cc: Qingqing Zhuo <qingqing.zhuo(a)amd.com> Change Since V3: - Use DML as the FPU folder instead create a new folder - Add a proper guard to x86 and PPC64 Change Since V2: - Make sure to compile FPU operation only when DCN is enabled (officially, we only enable it for x86). - Check cross-compile with ARM and x86_32. Everything looks fine. - Avoid call this_cpu_* operations between get/put_cpu_ptr. - Fix GCC warnings. - Update documentation. - Update our assert mechanism. - Remove unnecessary wrappers. Changes since V1: - Use a better name for variables. - Update documentation. - Avoid preemption. * See update details per commit message Rodrigo Siqueira (4): drm/amd/display: Move specific DCN2x code that uses FPU to DML drm/amd/display: Add control mechanism for FPU drm/amd/display: Add control mechanism for FPU utilization drm/amd/display: Add DC_FP helper to check FPU state .../gpu/drm/amd/display/amdgpu_dm/Makefile | 4 + .../amd/display/amdgpu_dm/amdgpu_dm_trace.h | 24 +++ .../gpu/drm/amd/display/amdgpu_dm/dc_fpu.c | 144 ++++++++++++++++++ .../gpu/drm/amd/display/amdgpu_dm/dc_fpu.h | 34 +++++ drivers/gpu/drm/amd/display/dc/dc_trace.h | 3 + .../drm/amd/display/dc/dcn20/dcn20_resource.c | 41 +---- .../drm/amd/display/dc/dcn20/dcn20_resource.h | 2 - .../drm/amd/display/dc/dcn21/dcn21_resource.c | 2 + drivers/gpu/drm/amd/display/dc/dml/Makefile | 4 + .../gpu/drm/amd/display/dc/dml/dcn2x/dcn2x.c | 102 +++++++++++++ .../gpu/drm/amd/display/dc/dml/dcn2x/dcn2x.h | 34 +++++ drivers/gpu/drm/amd/display/dc/os_types.h | 35 +---- 12 files changed, 358 insertions(+), 71 deletions(-) create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.c create mode 100644 drivers/gpu/drm/amd/display/amdgpu_dm/dc_fpu.h create mode 100644 drivers/gpu/drm/amd/display/dc/dml/dcn2x/dcn2x.c create mode 100644 drivers/gpu/drm/amd/display/dc/dml/dcn2x/dcn2x.h -- 2.25.1

2 8

[PATCH 00/30] Remove CNL support
by Lucas De Marchi 27 Jul '21

27 Jul '21

Patches 1 and 2 are already being reviewed elsewhere. Discussion on 2nd patch made me revive something I started after comment from Ville at https://patchwork.freedesktop.org/patch/428168/?series=88988&rev=1#comment_… This removes CNL completely from the driver, while trying to rename functions and macros where appropriate (usually to GLK when dealing with display or with ICL otherwise). It starts with display, which is more straightforward, and then proceed to the rest of i915. diff stat removing 1600 lines of dead code seems to pay the pain of doing this. Lucas De Marchi (30): drm/i915: fix not reading DSC disable fuse in GLK drm/i915/display: split DISPLAY_VER 9 and 10 in intel_setup_outputs() drm/i915/display: remove PORT_F workaround for CNL drm/i915/display: remove explicit CNL handling from intel_cdclk.c drm/i915/display: remove explicit CNL handling from intel_color.c drm/i915/display: remove explicit CNL handling from intel_combo_phy.c drm/i915/display: remove explicit CNL handling from intel_crtc.c drm/i915/display: remove explicit CNL handling from intel_ddi.c drm/i915/display: remove explicit CNL handling from intel_display_debugfs.c drm/i915/display: remove explicit CNL handling from intel_dmc.c drm/i915/display: remove explicit CNL handling from intel_dp.c drm/i915/display: remove explicit CNL handling from intel_dpll_mgr.c drm/i915/display: remove explicit CNL handling from intel_vdsc.c drm/i915/display: remove explicit CNL handling from skl_universal_plane.c drm/i915/display: remove explicit CNL handling from intel_display_power.c drm/i915/display: remove CNL ddi buf translation tables drm/i915/display: rename CNL references in skl_scaler.c drm/i915: remove explicit CNL handling from i915_irq.c drm/i915: remove explicit CNL handling from intel_pm.c drm/i915: remove explicit CNL handling from intel_mocs.c drm/i915: remove explicit CNL handling from intel_pch.c drm/i915: remove explicit CNL handling from intel_wopcm.c drm/i915/gt: remove explicit CNL handling from intel_sseu.c drm/i915: rename CNL references in intel_dram.c drm/i915/gt: rename CNL references in intel_engine.h drm/i915: finish removal of CNL drm/i915: remove GRAPHICS_VER == 10 drm/i915: rename/remove CNL registers drm/i915: replace random CNL comments drm/i915: switch num_scalers/num_sprites to consider DISPLAY_VER drivers/gpu/drm/i915/display/intel_bios.c | 8 +- drivers/gpu/drm/i915/display/intel_cdclk.c | 72 +- drivers/gpu/drm/i915/display/intel_color.c | 5 +- .../gpu/drm/i915/display/intel_combo_phy.c | 106 +-- drivers/gpu/drm/i915/display/intel_crtc.c | 2 +- drivers/gpu/drm/i915/display/intel_ddi.c | 266 +------- .../drm/i915/display/intel_ddi_buf_trans.c | 616 +++++------------- .../drm/i915/display/intel_ddi_buf_trans.h | 4 +- drivers/gpu/drm/i915/display/intel_display.c | 3 +- .../drm/i915/display/intel_display_debugfs.c | 2 +- .../drm/i915/display/intel_display_power.c | 289 -------- .../drm/i915/display/intel_display_power.h | 2 - drivers/gpu/drm/i915/display/intel_dmc.c | 9 - drivers/gpu/drm/i915/display/intel_dp.c | 35 +- drivers/gpu/drm/i915/display/intel_dp_aux.c | 1 - drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 586 +++-------------- drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 1 - drivers/gpu/drm/i915/display/intel_vbt_defs.h | 2 +- drivers/gpu/drm/i915/display/intel_vdsc.c | 5 +- drivers/gpu/drm/i915/display/skl_scaler.c | 10 +- .../drm/i915/display/skl_universal_plane.c | 14 +- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 1 - drivers/gpu/drm/i915/gt/debugfs_gt_pm.c | 10 +- drivers/gpu/drm/i915/gt/intel_engine.h | 2 +- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 - drivers/gpu/drm/i915/gt/intel_ggtt.c | 4 +- .../gpu/drm/i915/gt/intel_gt_clock_utils.c | 10 +- drivers/gpu/drm/i915/gt/intel_gtt.c | 6 +- drivers/gpu/drm/i915/gt/intel_lrc.c | 42 +- drivers/gpu/drm/i915/gt/intel_mocs.c | 2 +- drivers/gpu/drm/i915/gt/intel_rc6.c | 2 +- drivers/gpu/drm/i915/gt/intel_rps.c | 4 +- drivers/gpu/drm/i915/gt/intel_sseu.c | 79 --- drivers/gpu/drm/i915/gt/intel_sseu.h | 2 +- drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 6 +- drivers/gpu/drm/i915/gvt/gtt.c | 2 +- drivers/gpu/drm/i915/i915_debugfs.c | 6 +- drivers/gpu/drm/i915/i915_drv.h | 13 +- drivers/gpu/drm/i915/i915_irq.c | 7 +- drivers/gpu/drm/i915/i915_pci.c | 23 +- drivers/gpu/drm/i915/i915_perf.c | 22 +- drivers/gpu/drm/i915/i915_reg.h | 245 ++----- drivers/gpu/drm/i915/intel_device_info.c | 23 +- drivers/gpu/drm/i915/intel_device_info.h | 4 +- drivers/gpu/drm/i915/intel_dram.c | 32 +- drivers/gpu/drm/i915/intel_pch.c | 5 +- drivers/gpu/drm/i915/intel_pm.c | 41 +- drivers/gpu/drm/i915/intel_wopcm.c | 10 +- 48 files changed, 516 insertions(+), 2128 deletions(-) -- 2.31.1

4 64

[PATCH] fbcon: Out-Of-Bounds write in sys_imageblit, add range check
by tcs_kernel(腾讯云内核开发者) 27 Jul '21

27 Jul '21

yres and vyres can be controlled by user mode paramaters, and cause p->vrows to become a negative value. While this value be passed to real_y function, the ypos will be out of screen range. This is an out-of-bounds write bug. diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c index 22bb3892f6bd..0970de46782f 100644 --- a/drivers/video/fbdev/core/fbcon.c +++ b/drivers/video/fbdev/core/fbcon.c @@ -1956,11 +1956,12 @@ static void updatescrollmode(struct fbcon_display *p, int yres = FBCON_SWAP(ops->rotate, info->var.yres, info->var.xres); int vyres = FBCON_SWAP(ops->rotate, info->var.yres_virtual, info->var.xres_virtual); + int rows = vc->vc_rows; p->vrows = vyres/fh; - if (yres > (fh * (vc->vc_rows + 1))) - p->vrows -= (yres - (fh * vc->vc_rows)) / fh; - if ((yres % fh) && (vyres % fh < yres % fh)) + if ((yres > (fh * (rows + 1))) && (vyres >= (yres - (fh * rows))) && p->vrows) + p->vrows -= (yres - (fh * rows)) / fh; + if ((yres % fh) && (vyres % fh < yres % fh) && p->vrows) p->vrows--; }

3 4

[PATCH] drm/msm: Fix display fault handling
by Rob Clark 27 Jul '21

27 Jul '21

From: Rob Clark <robdclark(a)chromium.org> It turns out that when the display is enabled by the bootloader, we can get some transient iommu faults from the display. Which doesn't go over too well when we install a fault handler that is gpu specific. To avoid this, defer installing the fault handler until we get around to setting up per-process pgtables (which is adreno_smmu specific). The arm-smmu fallback error reporting is sufficient for reporting display related faults (and in fact was all we had prior to f8f934c180f629bb927a04fd90d) Reported-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> Reported-by: Yassine Oudjana <y.oudjana(a)protonmail.com> Fixes: 2a574cc05d38 ("drm/msm: Improve the a6xx page fault handler") Signed-off-by: Rob Clark <robdclark(a)chromium.org> Tested-by: John Stultz <john.stultz(a)linaro.org> --- drivers/gpu/drm/msm/msm_iommu.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c index eed2a762e9dd..bcaddbba564d 100644 --- a/drivers/gpu/drm/msm/msm_iommu.c +++ b/drivers/gpu/drm/msm/msm_iommu.c @@ -142,6 +142,9 @@ static const struct iommu_flush_ops null_tlb_ops = { .tlb_add_page = msm_iommu_tlb_add_page, }; +static int msm_fault_handler(struct iommu_domain *domain, struct device *dev, + unsigned long iova, int flags, void *arg); + struct msm_mmu *msm_iommu_pagetable_create(struct msm_mmu *parent) { struct adreno_smmu_priv *adreno_smmu = dev_get_drvdata(parent->dev); @@ -157,6 +160,13 @@ struct msm_mmu *msm_iommu_pagetable_create(struct msm_mmu *parent) if (!ttbr1_cfg) return ERR_PTR(-ENODEV); + /* + * Defer setting the fault handler until we have a valid adreno_smmu + * to avoid accidentially installing a GPU specific fault handler for + * the display's iommu + */ + iommu_set_fault_handler(iommu->domain, msm_fault_handler, iommu); + pagetable = kzalloc(sizeof(*pagetable), GFP_KERNEL); if (!pagetable) return ERR_PTR(-ENOMEM); @@ -300,7 +310,6 @@ struct msm_mmu *msm_iommu_new(struct device *dev, struct iommu_domain *domain) iommu->domain = domain; msm_mmu_init(&iommu->base, dev, &funcs, MSM_MMU_IOMMU); - iommu_set_fault_handler(domain, msm_fault_handler, iommu); atomic_set(&iommu->pagetables, 0); -- 2.31.1

4 3

[PATCH 0/2] Add support for querying hw info that UMDs need
by John.C.Harrison＠Intel.com 27 Jul '21

27 Jul '21

From: John Harrison <John.C.Harrison(a)Intel.com> Various UMDs require hardware configuration information about the current platform. A bunch of static information is available in a fixed table that can be retrieved from the GuC. Test-with: 20210727002812.43469-2-John.C.Harrison(a)Intel.com UMD: https://github.com/intel/compute-runtime/pull/432/files Signed-off-by: John Harrison <John.C.Harrison(a)Intel.com> John Harrison (1): drm/i915/guc: Add fetch of hwconfig table Rodrigo Vivi (1): drm/i915/uapi: Add query for hwconfig table drivers/gpu/drm/i915/Makefile | 1 + .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 + .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 4 + drivers/gpu/drm/i915/gt/uc/intel_guc.c | 3 +- drivers/gpu/drm/i915/gt/uc/intel_guc.h | 2 + .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 156 ++++++++++++++++++ .../gpu/drm/i915/gt/uc/intel_guc_hwconfig.h | 19 +++ drivers/gpu/drm/i915/gt/uc/intel_uc.c | 6 + drivers/gpu/drm/i915/i915_query.c | 23 +++ include/uapi/drm/i915_drm.h | 1 + 10 files changed, 215 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.h -- 2.25.1

1 2

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2021