dri-devel March 2020

dri-devel@lists.freedesktop.org

328 participants
771 discussions

Re: [PATCH] drm/edid: Distribute switch variables for initialization
by Kees Cook 03 Mar '20

03 Mar '20

On Wed, Feb 19, 2020 at 10:22:29PM -0800, Kees Cook wrote: > Variables declared in a switch statement before any case statements > cannot be automatically initialized with compiler instrumentation (as > they are not part of any execution flow). With GCC's proposed automatic > stack variable initialization feature, this triggers a warning (and they > don't get initialized). Clang's automatic stack variable initialization > (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also > doesn't initialize such variables[1]. Note that these warnings (or silent > skipping) happen before the dead-store elimination optimization phase, > so even when the automatic initializations are later elided in favor of > direct initializations, the warnings remain. > > To avoid these problems, move such variables into the "case" where > they're used or lift them up into the main function body. > > drivers/gpu/drm/drm_edid.c: In function ‘drm_edid_to_eld’: > drivers/gpu/drm/drm_edid.c:4395:9: warning: statement will never be executed [-Wswitch-unreachable] > 4395 | int sad_count; > | ^~~~~~~~~ > > [1] https://bugs.llvm.org/show_bug.cgi?id=44916 > > Signed-off-by: Kees Cook <keescook(a)chromium.org> Ping. Can someone pick this up, please? Thanks! -Kees > --- > drivers/gpu/drm/drm_edid.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > index 805fb004c8eb..2941b65b427f 100644 > --- a/drivers/gpu/drm/drm_edid.c > +++ b/drivers/gpu/drm/drm_edid.c > @@ -4392,9 +4392,9 @@ static void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid) > dbl = cea_db_payload_len(db); > > switch (cea_db_tag(db)) { > - int sad_count; > + case AUDIO_BLOCK: { > > - case AUDIO_BLOCK: > + int sad_count; > /* Audio Data Block, contains SADs */ > sad_count = min(dbl / 3, 15 - total_sad_count); > if (sad_count >= 1) > @@ -4402,6 +4402,7 @@ static void drm_edid_to_eld(struct drm_connector *connector, struct edid *edid) > &db[1], sad_count * 3); > total_sad_count += sad_count; > break; > + } > case SPEAKER_BLOCK: > /* Speaker Allocation Data Block */ > if (dbl >= 1) > -- Kees Cook

3 2

[PATCH v3 0/2] msm/gpu/a6xx: use the DMA-API for GMU memory allocations
by Jordan Crouse 03 Mar '20

03 Mar '20

When CONFIG_INIT_ON_ALLOC_DEFAULT_ON the GMU memory allocator runs afoul of cache coherency issues because it is mapped as write-combine without clearing the cache after it was zeroed. Rather than duplicate the hacky workaround we use in the GEM allocator for the same reason it turns out that we don't need to have a bespoke memory allocator for the GMU anyway. It uses a flat, global address space and there are only two relatively minor allocations anyway. In short, this is essentially what the DMA API was created for so replace a bunch of memory management code with two calls to allocate and free DMA memory and we're fine. In a previous version of this series I added the dma-ranges property to the device tree file for the GMU and updated the bindings to YAML. Rob correctly pointed out that we should set the dma mask instead of using dma-ranges so I removed that bit, but I'm still pushing the YAML conversion because it is good and we'll eventually need it anyway. v3: Fix YAML description per RobH and remove dma-ranges and replace it with the correct DMA mask in the GMU device. Convert the iova type to a dma_attr_t to make it 32 bit friendly. v2: Fix the example bindings for dma-ranges - the third item is the size Pass false to of_dma_configure so that it fails probe if the DMA region is not set up. Jordan Crouse (2): dt-bindings: display: msm: Convert GMU bindings to YAML drm/msm/a6xx: Use the DMA API for GMU memory objects .../devicetree/bindings/display/msm/gmu.txt | 116 ------------------- .../devicetree/bindings/display/msm/gmu.yaml | 123 +++++++++++++++++++++ drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 115 +++---------------- drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 7 +- 4 files changed, 138 insertions(+), 223 deletions(-) delete mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.yaml -- 2.7.4

5 10

Re: Etnaviv issues on i.MX8M-Mini
by Schrempf Frieder 03 Mar '20

03 Mar '20

On 25.02.20 09:13, Frieder Schrempf wrote: > Hi Lucas, > > On 24.02.20 12:08, Lucas Stach wrote: >> On Mo, 2020-02-24 at 10:53 +0000, Schrempf Frieder wrote: >>> Hi Lucas, >>> >>> On 24.02.20 11:37, Lucas Stach wrote: >>>> Hi Frieder, >>>> >>>> On Mo, 2020-02-24 at 10:28 +0000, Schrempf Frieder wrote: >>>>> On 20.02.20 19:58, Chris Healy wrote: >>>>>> For the jerkey transitions, can you determine if this is a symptom of >>>>>> a low framerate or dropped frames or something else? >>>>>> >>>>>> Perhaps you can start your app with >>>>>> "GALLIUM_HUD=fps,cpu,draw-calls,frametime". This may give some >>>>>> clues. >>>>> >>>>> The framerate seems ok. I get something between 50 and 70 FPS. >>>>> >>>>> I have a Qt demo app with a menu and an animated 'ball' that moves >>>>> across the screen. When the menu is visible, the ball movement is >>>>> really >>>>> jerky (ball seems to 'jump back and forth' instead of moving >>>>> linearly). >>>>> >>>>> As soon as I hide the menu and show the animation fullscreen, the >>>>> movements are perfectly smooth. >>>>> >>>>> Running the same app with software rendering, everything looks >>>>> good, too. >>>>> >>>>> No idea what that means, though. I probably need to look at the >>>>> code of >>>>> the app and do some more experiments to get a better idea of what >>>>> might >>>>> cause the distortion. >>>>> >>>>> Unless some of the graphics experts here already have an idea of what >>>>> can cause and/or how to debug such an issue!? >>>> >>>> Which driver is used for the display side? It seems like the display >>>> side doesn't properly handle the dma fences used to synchronize scanout >>>> and rendering. >>> >>> I ported/picked the drivers for the LCDIF and DSI controllers from >>> development branch of the 5.4-based vendor kernel [1] to our own >>> v5.4-based kernel [2]. So it is quite probable, that something could be >>> wrong here. >> >> Please just use DRM_MXSFB for the display side, instead of the >> downstream driver. > > Hm, good idea. I somehow forgot about the fact, that there is an > upstream driver for the LCDIF controller. On first try I couldn't get it > to run on the i.MX8MM, but I suspect that's due to some reset, > power-domain or clock setup, that is missing upstream. I will see if I > can get any further with this. So I had a closer look and while the DRM_MXSFB looks ok on its own, I have some problem with the rest of the i.MX8MM display subsystem. The vendor stack, that I'm currently using integrates into the imx-drm master/core driver [1] that binds all the components of the display subsystem, such as the LCDIF driver and the integrated SEC_DSIM DSI bridge. And because of my lack of DRM skills, I have no idea how to get the DRM_MXSFB driver to bind to the imx-drm core, instead of running separately and connecting directly to some panel as it is done for i.MX23/28 and i.MX6SX/UL. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/dri…

3 6

[RFC 0/8] MIPS: CI20: add HDMI out support
by H. Nikolaus Schaller 03 Mar '20

03 Mar '20

This patch series adds HDMI output to the jz4780/CI20 board. It is based on taking the old 3.18 vendor kernel and trying to achieve the same with modern DTS setup and new/modified drivers. Unfortunately, in this first RFC, only EDID and creation of /dev/fb0 are working. Also, HDMI hot plugging is detected. But there is no HDMI output signal. So some tiny piece seems to be missing to enable/configure the Synposys HDMI controller. We need help from the community to fix this. Note: device tree bindings are from 2015 and still seem to fit - except they are not in yaml format. Original authors of most patches are * Paul Boddie <paul(a)boddie.org.uk> * Zubair Lutfullah Kakakhel <Zubair.Kakakhel(a)imgtec.com> H. Nikolaus Schaller (2): drm: ingenic-drm: add MODULE_DEVICE_TABLE MIPS: CI20: defconfig: configure for DRM_DW_HDMI_JZ4780 Paul Boddie (4): drm: ingenic: add jz4780 Synopsys HDMI driver. pinctrl: ingenic: add hdmi-ddc pin control group MIPS: DTS: jz4780: account for Synopsys HDMI driver and LCD controller MIPS: DTS: CI20: add HDMI setup Zubair Lutfullah Kakakhel (2): dt-bindings: video: Add jz4780-lcd binding dt-bindings: video: Add jz4780-hdmi binding .../bindings/display/ingenic-jz4780-hdmi.txt | 41 ++++++ .../bindings/display/ingenic-jz4780-lcd.txt | 39 ++++++ arch/mips/boot/dts/ingenic/ci20.dts | 64 ++++++++++ arch/mips/boot/dts/ingenic/jz4780.dtsi | 32 +++++ arch/mips/configs/ci20_defconfig | 3 + drivers/gpu/drm/ingenic/Kconfig | 8 ++ drivers/gpu/drm/ingenic/Makefile | 1 + drivers/gpu/drm/ingenic/dw_hdmi-jz4780.c | 120 ++++++++++++++++++ drivers/gpu/drm/ingenic/ingenic-drm.c | 2 + drivers/pinctrl/pinctrl-ingenic.c | 7 + 10 files changed, 317 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/ingenic-jz4780-hdmi.txt create mode 100644 Documentation/devicetree/bindings/display/ingenic-jz4780-lcd.txt create mode 100644 drivers/gpu/drm/ingenic/dw_hdmi-jz4780.c -- 2.23.0

3 16

[PATCH 00/12] drm/i915: Gamma cleanups
by Ville Syrjala 03 Mar '20

03 Mar '20

From: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Some polishings and at least one minor fix for the gamma stuff. Ville Syrjälä (12): drm: Inline drm_color_lut_extract() drm/i915: Polish CHV .load_luts() a bit drm/i915: Polish CHV CGM CSC loading drm/i915: Add i9xx_lut_8() drm/i915: Clean up i9xx_load_luts_internal() drm/i915: Split i9xx_read_lut_8() to gmch vs. ilk variants drm/i915: s/blob_data/lut/ drm/i915: s/chv_read_cgm_lut/chv_read_cgm_gamma/ drm/i915: Clean up integer types in color code drm/i915: Refactor LUT read functions drm/i915: Fix readout of PIPEGCMAX drm/i915: Pass the crtc to the low level read_lut() funcs drivers/gpu/drm/drm_color_mgmt.c | 24 -- drivers/gpu/drm/i915/display/intel_color.c | 435 +++++++++++---------- drivers/gpu/drm/i915/i915_reg.h | 1 - include/drm/drm_color_mgmt.h | 23 +- 4 files changed, 258 insertions(+), 225 deletions(-) -- 2.23.0

6 22

[PATCH 0/4] drm/bridge: dw-hdmi: Various updates
by Jernej Skrabec 03 Mar '20

03 Mar '20

This series fixes multiple issues I found out. Patch 1 fixes reporting colorimetry in AVI frame. Patch 2 fixes color space conversion detection. At the moment it doesn't change anything, but it would needlessly enable CSC unit when conversion is not needed. Patch 3 sets scan mode to underscan which is in line with most other hdmi drivers. Patch 4 aligns RGB quantization to CEA 861 standard. Please take a look. Best regards, Jernej Jernej Skrabec (3): drm/bridge: dw-hdmi: fix AVI frame colorimetry drm/bridge: dw-hdmi: Fix color space conversion detection drm/bridge: dw-hdmi: Add support for RGB limited range Jonas Karlman (1): drm/bridge: dw-hdmi: do not force "none" scan mode drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 87 ++++++++++++++++------- 1 file changed, 62 insertions(+), 25 deletions(-) -- 2.25.1

4 15

[PATCH] drm/simple-kms: Fix documentation for drm_simple_encoder_init()
by Thomas Zimmermann 03 Mar '20

03 Mar '20

Brings the documentation of drm_simple_encoder_init() in sync with the function's signature. Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: 63170ac6f2e8 ("drm/simple-kms: Add drm_simple_encoder_{init,create}()") Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org --- drivers/gpu/drm/drm_simple_kms_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c b/drivers/gpu/drm/drm_simple_kms_helper.c index 5a2abe2dea3e..2fab80aaf52e 100644 --- a/drivers/gpu/drm/drm_simple_kms_helper.c +++ b/drivers/gpu/drm/drm_simple_kms_helper.c @@ -40,7 +40,7 @@ static const struct drm_encoder_funcs drm_simple_encoder_funcs_cleanup = { /** * drm_simple_encoder_init - Initialize a preallocated encoder * @dev: drm device - * @funcs: callbacks for this encoder + * @encoder: the encoder to initialize * @encoder_type: user visible type of the encoder * * Initialises a preallocated encoder that has no further functionality. -- 2.25.1

2 3

[PATCH v10 0/5] arm/arm64: mediatek: Fix mt8173 mmsys device probing
by Enric Balletbo i Serra 03 Mar '20

03 Mar '20

Dear all, Those patches are intended to solve an old standing issue on some Mediatek devices (mt8173, mt2701 and mt2712 are affected by this issue). Up to now both drivers, clock and drm are probed with the same device tree compatible. But only the first driver gets probed, which in effect breaks graphics on those devices. The MMSYS (Multimedia subsystem) in Mediatek SoCs has some registers to control clock gates (which is used in the clk driver) and some registers to set the routing and enable the differnet blocks of the display and MDP (Media Data Path) subsystem. On this series the clk driver is not a pure clock controller but a system controller that can provide access to the shared registers between the different drivers that need it (mediatek-drm and mediatek-mdp). Hence the MMSYS clk driver was moved to drivers/soc/mediatek and is the entry point (parent) which will trigger the probe of the corresponding mediatek-drm driver. **IMPORTANT** This series only fixes the issue on mt8173 to make it simple and as is the only platform I can test. Similar changes should be applied for mt2701 and mt2712 to have display working. For reference, here are the links to the old discussions: * v9: https://patchwork.kernel.org/project/linux-clk/list/?series=247591 * v8: https://patchwork.kernel.org/project/linux-mediatek/list/?series=244891 * v7: https://patchwork.kernel.org/project/linux-mediatek/list/?series=241217 * v6: https://patchwork.kernel.org/project/linux-mediatek/list/?series=213219 * v5: https://patchwork.kernel.org/project/linux-mediatek/list/?series=44063 * v4: * https://patchwork.kernel.org/patch/10530871/ * https://patchwork.kernel.org/patch/10530883/ * https://patchwork.kernel.org/patch/10530885/ * https://patchwork.kernel.org/patch/10530911/ * https://patchwork.kernel.org/patch/10530913/ * v3: * https://patchwork.kernel.org/patch/10367857/ * https://patchwork.kernel.org/patch/10367861/ * https://patchwork.kernel.org/patch/10367877/ * https://patchwork.kernel.org/patch/10367875/ * https://patchwork.kernel.org/patch/10367885/ * https://patchwork.kernel.org/patch/10367883/ * https://patchwork.kernel.org/patch/10367889/ * https://patchwork.kernel.org/patch/10367907/ * https://patchwork.kernel.org/patch/10367909/ * https://patchwork.kernel.org/patch/10367905/ * v2: No relevant discussion, see v3 * v1: * https://patchwork.kernel.org/patch/10016497/ * https://patchwork.kernel.org/patch/10016499/ * https://patchwork.kernel.org/patch/10016505/ * https://patchwork.kernel.org/patch/10016507/ Best regards, Enric Changes in v10: - Update the binding documentation for the mmsys system controller. - Renamed to be generic mtk-mmsys - Add driver data support to be able to support diferent SoCs - Introduced a new patch to move routing control into mmsys driver. - Removed the patch to use regmap as is not needed anymore. - Match driver data to get display routing. Changes in v9: - Move mmsys to drivers/soc/mediatek (CK) - Do not move the display routing from the drm driver (CK) Changes in v8: - Be a builtin_platform_driver like other mediatek mmsys drivers. - New patch introduced in this series. Changes in v7: - Free clk_data->clks as well - Get rid of private data structure Enric Balletbo i Serra (3): dt-bindings: mediatek: Update mmsys binding to reflect it is a system controller soc / drm: mediatek: Move routing control to mmsys device soc / drm: mediatek: Fix mediatek-drm device probing Matthias Brugger (2): drm/mediatek: Omit warning on probe defers soc: mediatek: Move mt8173 MMSYS to platform driver .../bindings/arm/mediatek/mediatek,mmsys.txt | 7 +- drivers/clk/mediatek/clk-mt8173.c | 104 ----- drivers/gpu/drm/mediatek/mtk_disp_color.c | 5 +- drivers/gpu/drm/mediatek/mtk_disp_ovl.c | 5 +- drivers/gpu/drm/mediatek/mtk_disp_rdma.c | 5 +- drivers/gpu/drm/mediatek/mtk_dpi.c | 12 +- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 13 +- drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 259 +---------- drivers/gpu/drm/mediatek/mtk_drm_ddp.h | 7 - drivers/gpu/drm/mediatek/mtk_drm_drv.c | 44 +- drivers/gpu/drm/mediatek/mtk_dsi.c | 8 +- drivers/gpu/drm/mediatek/mtk_hdmi.c | 4 +- drivers/soc/mediatek/Kconfig | 7 + drivers/soc/mediatek/Makefile | 1 + drivers/soc/mediatek/mtk-mmsys.c | 435 ++++++++++++++++++ include/linux/soc/mediatek/mtk-mmsys.h | 19 + 16 files changed, 529 insertions(+), 406 deletions(-) create mode 100644 drivers/soc/mediatek/mtk-mmsys.c create mode 100644 include/linux/soc/mediatek/mtk-mmsys.h -- 2.25.0

3 15

[PATCH] drm/vblank: Fix documentation of VBLANK timestamp helper
by Thomas Zimmermann 03 Mar '20

03 Mar '20

Per-CRTC VBLANK information used to be addressed by device and pipe index. A call drm_crtc_vblank_helper_get_vblank_timestamp_internal() receives a pointer to the CRTC instead. Fix the documentation. Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Reported-by: Daniel Vetter <daniel(a)ffwll.ch> Fixes: f1e2b6371c12 ("drm: Add get_scanout_position() to struct drm_crtc_helper_funcs") Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Cc: Maxime Ripard <mripard(a)kernel.org> Cc: David Airlie <airlied(a)linux.ie> Cc: Daniel Vetter <daniel(a)ffwll.ch> Cc: dri-devel(a)lists.freedesktop.org --- drivers/gpu/drm/drm_vblank.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index 47fc4339ec7f..da7b0b0c1090 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/drivers/gpu/drm/drm_vblank.c @@ -592,8 +592,7 @@ EXPORT_SYMBOL(drm_calc_timestamping_constants); /** * drm_crtc_vblank_helper_get_vblank_timestamp_internal - precise vblank * timestamp helper - * @dev: DRM device - * @pipe: index of CRTC whose vblank timestamp to retrieve + * @crtc: CRTC whose vblank timestamp to retrieve * @max_error: Desired maximum allowable error in timestamps (nanosecs) * On return contains true maximum error of timestamp * @vblank_time: Pointer to time which should receive the timestamp -- 2.25.1

2 1

[PATCH 1/2] drm/virtgpu: plumb fix for virtgpu_drm.h / virtio_gpu.h discrepancy
by Gurchetan Singh 03 Mar '20

03 Mar '20

virglrenderer has logic to validate both stride and layer_stride, but both are always zero. The fallback for that case is: stride = width * bytes_per_pixel layer_stride = stride * num_layers However, this assumption causes trouble in the following cases: 1) When allocating host-compatible buffers for the planned wayland integration. 2) Certain YUV buffers, which Gallium imports as 3 R8 buffers with variable strides. For example, HAL_PIXEL_FORMAT_YV12 requires that the chroma planes are aligned to 16 bytes. This commit doesn't fix the discrepancy, but adds the necessary plumbing so we don't forget. Signed-off-by: Gurchetan Singh <gurchetansingh(a)chromium.org> --- drivers/gpu/drm/virtio/virtgpu_drv.h | 2 ++ drivers/gpu/drm/virtio/virtgpu_ioctl.c | 9 ++++++--- drivers/gpu/drm/virtio/virtgpu_vq.c | 6 ++++++ 3 files changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h b/drivers/gpu/drm/virtio/virtgpu_drv.h index 314e02f94d9c..c1c9a9b8e25c 100644 --- a/drivers/gpu/drm/virtio/virtgpu_drv.h +++ b/drivers/gpu/drm/virtio/virtgpu_drv.h @@ -312,12 +312,14 @@ void virtio_gpu_cmd_submit(struct virtio_gpu_device *vgdev, void virtio_gpu_cmd_transfer_from_host_3d(struct virtio_gpu_device *vgdev, uint32_t ctx_id, uint64_t offset, uint32_t level, + uint32_t stride, uint32_t layer_stride, struct virtio_gpu_box *box, struct virtio_gpu_object_array *objs, struct virtio_gpu_fence *fence); void virtio_gpu_cmd_transfer_to_host_3d(struct virtio_gpu_device *vgdev, uint32_t ctx_id, uint64_t offset, uint32_t level, + uint32_t stride, uint32_t layer_stride, struct virtio_gpu_box *box, struct virtio_gpu_object_array *objs, struct virtio_gpu_fence *fence); diff --git a/drivers/gpu/drm/virtio/virtgpu_ioctl.c b/drivers/gpu/drm/virtio/virtgpu_ioctl.c index 9af1ec62434f..98b72dead962 100644 --- a/drivers/gpu/drm/virtio/virtgpu_ioctl.c +++ b/drivers/gpu/drm/virtio/virtgpu_ioctl.c @@ -324,8 +324,10 @@ static int virtio_gpu_transfer_from_host_ioctl(struct drm_device *dev, ret = -ENOMEM; goto err_unlock; } + + /* TODO: add the correct stride / layer_stride. */ virtio_gpu_cmd_transfer_from_host_3d - (vgdev, vfpriv->ctx_id, offset, args->level, + (vgdev, vfpriv->ctx_id, offset, args->level, 0, 0, &box, objs, fence); dma_fence_put(&fence->f); return 0; @@ -369,10 +371,11 @@ static int virtio_gpu_transfer_to_host_ioctl(struct drm_device *dev, void *data, if (!fence) goto err_unlock; + /* TODO: add the correct stride / layer_stride. */ virtio_gpu_cmd_transfer_to_host_3d (vgdev, - vfpriv ? vfpriv->ctx_id : 0, offset, - args->level, &box, objs, fence); + vfpriv ? vfpriv->ctx_id : 0, offset, args->level, + 0, 0, &box, objs, fence); dma_fence_put(&fence->f); } return 0; diff --git a/drivers/gpu/drm/virtio/virtgpu_vq.c b/drivers/gpu/drm/virtio/virtgpu_vq.c index 80176f379ad5..9fb3c8c3b687 100644 --- a/drivers/gpu/drm/virtio/virtgpu_vq.c +++ b/drivers/gpu/drm/virtio/virtgpu_vq.c @@ -965,6 +965,7 @@ virtio_gpu_cmd_resource_create_3d(struct virtio_gpu_device *vgdev, void virtio_gpu_cmd_transfer_to_host_3d(struct virtio_gpu_device *vgdev, uint32_t ctx_id, uint64_t offset, uint32_t level, + uint32_t stride, uint32_t layer_stride, struct virtio_gpu_box *box, struct virtio_gpu_object_array *objs, struct virtio_gpu_fence *fence) @@ -990,6 +991,8 @@ void virtio_gpu_cmd_transfer_to_host_3d(struct virtio_gpu_device *vgdev, cmd_p->box = *box; cmd_p->offset = cpu_to_le64(offset); cmd_p->level = cpu_to_le32(level); + cmd_p->stride = cpu_to_le32(stride); + cmd_p->layer_stride = cpu_to_le32(layer_stride); virtio_gpu_queue_fenced_ctrl_buffer(vgdev, vbuf, &cmd_p->hdr, fence); } @@ -997,6 +1000,7 @@ void virtio_gpu_cmd_transfer_to_host_3d(struct virtio_gpu_device *vgdev, void virtio_gpu_cmd_transfer_from_host_3d(struct virtio_gpu_device *vgdev, uint32_t ctx_id, uint64_t offset, uint32_t level, + uint32_t stride, uint32_t layer_stride, struct virtio_gpu_box *box, struct virtio_gpu_object_array *objs, struct virtio_gpu_fence *fence) @@ -1016,6 +1020,8 @@ void virtio_gpu_cmd_transfer_from_host_3d(struct virtio_gpu_device *vgdev, cmd_p->box = *box; cmd_p->offset = cpu_to_le64(offset); cmd_p->level = cpu_to_le32(level); + cmd_p->stride = cpu_to_le32(stride); + cmd_p->layer_stride = cpu_to_le32(layer_stride); virtio_gpu_queue_fenced_ctrl_buffer(vgdev, vbuf, &cmd_p->hdr, fence); } -- 2.23.0.444.g18eeb5a265-goog

3 7

← Newer
1
...
68
69
70
71
72
73
74
...
78
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel March 2020