dri-devel June 2020

dri-devel@lists.freedesktop.org

315 participants
731 discussions

[PATCH] drm/mgag200: Enable caching for SHMEM pages
by Thomas Zimmermann 23 Jun '20

23 Jun '20

We've had reports about performance regressions after switching mgag200 from VRAM helpers to SHMEM helpers. SHMEM pages use writecombine caching by default, but can also use the platform's default page caching. Doing so improves the performance of I/O on the framebuffer. Mgag200's hardware does not access framebuffer pages directly (i.e., via DMA), so enabling caching does not have an effect on consistency of the framebuffer memory or the displayed data. Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de> Fixes: 913ec479bb5c ("drm/mgag200: Replace VRAM helpers with SHMEM helpers") Cc: Thomas Zimmermann <tzimmermann(a)suse.de> Cc: Emil Velikov <emil.velikov(a)collabora.com> Cc: Dave Airlie <airlied(a)redhat.com> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Krzysztof Kozlowski <krzk(a)kernel.org> Cc: Gerd Hoffmann <kraxel(a)redhat.com> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: Rong Chen <rong.a.chen(a)intel.com> Cc: John Donnelly <john.p.donnelly(a)Oracle.com> Link: https://lore.kernel.org/dri-devel/20200617092252.GA5279@shao2-debian/ --- drivers/gpu/drm/mgag200/mgag200_drv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c b/drivers/gpu/drm/mgag200/mgag200_drv.c index e19660f4a637..7189c7745baf 100644 --- a/drivers/gpu/drm/mgag200/mgag200_drv.c +++ b/drivers/gpu/drm/mgag200/mgag200_drv.c @@ -36,6 +36,7 @@ static struct drm_driver mgag200_driver = { .major = DRIVER_MAJOR, .minor = DRIVER_MINOR, .patchlevel = DRIVER_PATCHLEVEL, + .gem_create_object = drm_gem_shmem_create_object_cached, DRM_GEM_SHMEM_DRIVER_OPS, }; -- 2.27.0

2 3

[PATCH 6/6] drm/i915/dp_mst: Ensure the DPCD ACT sent flag is cleared before waiting for it
by Imre Deak 23 Jun '20

23 Jun '20

Atm, we clear the ACT sent flag in the sink's DPCD before updating the sink's payload table, along clearing the payload table updated flag. The sink is supposed to set this flag once it detects that the source has completed the ACT sequence (after detecting the 4 required ACT MTPH symbols sent by the source). As opposed to this 2 DELL monitors I have set the flag already along the payload table updated flag, which is not quite correct. To be sure that the sink has detected the ACT MTPH symbols before continuing enabling the encoder, clear the ACT sent flag before enabling or disabling the transcoder VC payload allocation (which is what starts the ACT sequence). Cc: Lyude Paul <lyude(a)redhat.com> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: dri-devel(a)lists.freedesktop.org Signed-off-by: Imre Deak <imre.deak(a)intel.com> --- drivers/gpu/drm/drm_dp_mst_topology.c | 31 +++++++++++++++++++-- drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 ++ include/drm/drm_dp_mst_helper.h | 2 ++ 3 files changed, 33 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index b2f5a84b4cfb..e3bf8c9c8267 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -4377,6 +4377,34 @@ void drm_dp_mst_deallocate_vcpi(struct drm_dp_mst_topology_mgr *mgr, } EXPORT_SYMBOL(drm_dp_mst_deallocate_vcpi); +/** + * drm_dp_clear_payload_status() - Clears the payload table status flags + * @mgr: manager to use + * + * Clears the payload table ACT handled and table updated flags in the MST hub's + * DPCD. This function must be called before updating the payload table or + * starting the ACT sequence and waiting for the corresponding flags to get + * set by the hub. + * + * Returns: + * 0 if the flag got cleared successfully, otherwise a negative error code. + */ +int drm_dp_clear_payload_status(struct drm_dp_mst_topology_mgr *mgr) +{ + int ret; + + ret = drm_dp_dpcd_writeb(mgr->aux, DP_PAYLOAD_TABLE_UPDATE_STATUS, + DP_PAYLOAD_ACT_HANDLED); + if (ret < 0) { + DRM_DEBUG_DRIVER("Can't clear the ACT sent flag (%d)\n", ret); + return ret; + } + WARN_ON(ret != 1); + + return 0; +} +EXPORT_SYMBOL(drm_dp_clear_payload_status); + static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr, int id, struct drm_dp_payload *payload) { @@ -4384,8 +4412,7 @@ static int drm_dp_dpcd_write_payload(struct drm_dp_mst_topology_mgr *mgr, int ret; int retries = 0; - drm_dp_dpcd_writeb(mgr->aux, DP_PAYLOAD_TABLE_UPDATE_STATUS, - DP_PAYLOAD_TABLE_UPDATED); + drm_dp_clear_payload_status(mgr); payload_alloc[0] = id; payload_alloc[1] = payload->start_slot; diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c b/drivers/gpu/drm/i915/display/intel_dp_mst.c index 9308b5920780..3c4b0fb10d8b 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c @@ -323,6 +323,8 @@ static void clear_act_sent(struct intel_dp *intel_dp) intel_de_write(i915, intel_dp->regs.dp_tp_status, DP_TP_STATUS_ACT_SENT); + + drm_dp_clear_payload_status(&intel_dp->mst_mgr); } static void wait_for_act_sent(struct intel_dp *intel_dp) diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h index 8b9eb4db3381..2facb87624bf 100644 --- a/include/drm/drm_dp_mst_helper.h +++ b/include/drm/drm_dp_mst_helper.h @@ -763,6 +763,8 @@ int drm_dp_find_vcpi_slots(struct drm_dp_mst_topology_mgr *mgr, int pbn); +int drm_dp_clear_payload_status(struct drm_dp_mst_topology_mgr *mgr); + int drm_dp_update_payload_part1(struct drm_dp_mst_topology_mgr *mgr); -- 2.23.1

3 8

XDC 2020: Registration & Call for Proposals now open!
by Szwichtenberg, Radoslaw 23 Jun '20

23 Jun '20

Hello! Registration & Call for Proposals are now open for XDC 2020, which will take place at the Gdańsk University of Technology in Gdańsk, Poland on September 16-18, 2020. Thanks to LWN.net for hosting the website again this year! https://xdc2020.x.org As usual, the conference is free of charge and open to the general public. If you plan on attending, please make sure to register as early as possible! However, don't book any travel or hotel until the organization decides if we keep the conference as it is or there is any change. Please read this message on the website for more information: https://xdc2020.x.org/event/9/page/78-covid-19 In order to register as attendee, you will therefore need to register via the XDC website. However, as XDC is sharing the same Indico infrastructure as LPC, if you previously registered on the LPC website (linuxplumbersconference.org) or on the XDC 2019 website (xdc2019.x.org), then you already have an active account and can use the same username & password to login! https://xdc2020.x.org/event/9/registrations/7/ In addition to registration, the CfP is now open for talks, workshops and demos at XDC 2020. While any serious proposal will be gratefully considered, topics of interest to X.Org and freedesktop.org developers are encouraged. The program focus is on new development, ongoing challenges and anything else that will spark discussions among attendees in the hallway track. We are open to talks across all layers of the graphics stack, from the kernel to desktop environments / graphical applications and about how to make things better for the developers who build them. Head to the CfP page to learn more: https://xdc2020.x.org/event/9/abstracts/ The deadline for submissions is Sunday, 5 July 2020. Notice that the event may end up being postponed, converted to a fully online conference, or even a hybrid one (physical event + some remote talks). It depends on how COVID-19 situation evolves in the different countries and the restrictions we will have at that time. Also, some people may decide to skip the physical conference to avoid any risk of infection. Because of that, please indicate in your talk submission if you prefer to give a remote talk in the case that XDC keeps being a physical event this year. Similarly, if you think that your talk makes no sense if XDC ends up being a fully-virtual conference, please indicate that in the notes of the talk submission. If COVID-19 situation allows it, we are looking forward to seeing you in Gdańsk! If you have any questions, please send me an email to radoslaw.szwichtenberg(a)intel.com, adding on CC the X.org board (board at foundation.x.org). And don't forget, you can follow us on Twitter for all the latest updates and to stay connected: https://twitter.com/xdc2020 Best, Radek

2 1

[PATCH] drm/omap: Remove aggregate initialization of new_mode in omap_connector_mode_valid
by Nathan Chancellor 23 Jun '20

23 Jun '20

After commit 42acb06b01b1 ("drm: pahole struct drm_display_mode"), clang warns: drivers/gpu/drm/omapdrm/omap_connector.c:92:39: warning: braces around scalar initializer [-Wbraced-scalar-init] struct drm_display_mode new_mode = { { 0 } }; ^~~~~~ 1 warning generated. After the struct was shuffled, the second set of braces is no longer needed because we are not initializing a structure (struct list_head) but a regular integer (int clock). However, looking into it further, this initialization is pointless because new_mode is used as the destination of drm_mode_copy, where the members of new_mode will just be completely overwritten with the members of mode. Just remove the initialization of new_mode so that there is no more warning and we don't need to worry about updating the initialization if the structure ever get shuffled again. Link: https://github.com/ClangBuiltLinux/linux/issues/1059 Suggested-by: Nick Desaulniers <ndesaulniers(a)google.com> Signed-off-by: Nathan Chancellor <natechancellor(a)gmail.com> --- drivers/gpu/drm/omapdrm/omap_connector.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c b/drivers/gpu/drm/omapdrm/omap_connector.c index 528764566b17..ce4da1511920 100644 --- a/drivers/gpu/drm/omapdrm/omap_connector.c +++ b/drivers/gpu/drm/omapdrm/omap_connector.c @@ -89,7 +89,7 @@ static enum drm_mode_status omap_connector_mode_valid(struct drm_connector *conn struct drm_display_mode *mode) { struct omap_connector *omap_connector = to_omap_connector(connector); - struct drm_display_mode new_mode = { { 0 } }; + struct drm_display_mode new_mode; enum drm_mode_status status; status = omap_connector_mode_fixup(omap_connector->output, mode, base-commit: 27f11fea33608cbd321a97cbecfa2ef97dcc1821 -- 2.27.0

1 0

linux-next: manual merge of the drm-intel tree with Linus' tree
by Stephen Rothwell 23 Jun '20

23 Jun '20

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: drivers/gpu/drm/i915/i915_drv.h between commit: 7fb81e9d8073 ("drm/i915: Use drmm_add_final_kfree") from Linus' tree and commit: 8a25c4be583d ("drm/i915/params: switch to device specific parameters") from the drm-intel tree. I fixed it up (see below) and can carry the fix as necessary. This is now fixed as far as linux-next is concerned, but any non trivial conflicts should be mentioned to your upstream maintainer when your tree is submitted for merging. You may also want to consider cooperating with the maintainer of the conflicting tree to minimise any particularly complex conflicts. -- Cheers, Stephen Rothwell diff --cc drivers/gpu/drm/i915/i915_drv.h index adb9bf34cf97,2697960f15a9..000000000000 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@@ -826,9 -827,9 +827,12 @@@ struct i915_selftest_stash struct drm_i915_private { struct drm_device drm; + /* i915 device parameters */ + struct i915_params params; + + /* FIXME: Device release actions should all be moved to drmm_ */ + bool do_release; + const struct intel_device_info __info; /* Use INTEL_INFO() to access. */ struct intel_runtime_info __runtime; /* Use RUNTIME_INFO() to access. */ struct intel_driver_caps caps;

1 0

[PATCH v1 0/11] support cmdq helper function on mt6779 platform
by Dennis YC Hsieh 23 Jun '20

23 Jun '20

This patch support cmdq helper function on mt6779 platform, based on "support gce on mt6779 platform" patchset. Dennis YC Hsieh (11): soc: mediatek: cmdq: add address shift in jump soc: mediatek: cmdq: add assign function soc: mediatek: cmdq: add write_s function soc: mediatek: cmdq: add write_s_mask function soc: mediatek: cmdq: add read_s function soc: mediatek: cmdq: add write_s value function soc: mediatek: cmdq: add write_s_mask value function soc: mediatek: cmdq: export finalize function soc: mediatek: cmdq: add jump function soc: mediatek: cmdq: add clear option in cmdq_pkt_wfe api soc: mediatek: cmdq: add set event function drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +- drivers/soc/mediatek/mtk-cmdq-helper.c | 159 +++++++++++++++++++++-- include/linux/mailbox/mtk-cmdq-mailbox.h | 8 +- include/linux/soc/mediatek/mtk-cmdq.h | 124 +++++++++++++++++- 4 files changed, 280 insertions(+), 14 deletions(-) -- 2.18.0

4 25

[PATCH 1/2] drm/shmem: add support for per object dma api operations
by Gurchetan Singh 22 Jun '20

22 Jun '20

This is useful for the next patch. Also, should we only unmap the amount entries that we mapped with the dma-api? Signed-off-by: Gurchetan Singh <gurchetansingh(a)chromium.org> --- drivers/gpu/drm/drm_gem_shmem_helper.c | 16 +++++++++++----- include/drm/drm_gem_shmem_helper.h | 10 ++++++++++ 2 files changed, 21 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c index 0a7e3b664bc2..d439074ad7b5 100644 --- a/drivers/gpu/drm/drm_gem_shmem_helper.c +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c @@ -124,8 +124,10 @@ void drm_gem_shmem_free_object(struct drm_gem_object *obj) drm_prime_gem_destroy(obj, shmem->sgt); } else { if (shmem->sgt) { - dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl, - shmem->sgt->nents, DMA_BIDIRECTIONAL); + if (!shmem->skip_dma_api) + dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl, + shmem->dma_map_count, + DMA_BIDIRECTIONAL); sg_free_table(shmem->sgt); kfree(shmem->sgt); } @@ -422,8 +424,9 @@ void drm_gem_shmem_purge_locked(struct drm_gem_object *obj) WARN_ON(!drm_gem_shmem_is_purgeable(shmem)); - dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl, - shmem->sgt->nents, DMA_BIDIRECTIONAL); + if (!shmem->skip_dma_api) + dma_unmap_sg(obj->dev->dev, shmem->sgt->sgl, + shmem->dma_map_count, DMA_BIDIRECTIONAL); sg_free_table(shmem->sgt); kfree(shmem->sgt); shmem->sgt = NULL; @@ -695,7 +698,10 @@ struct sg_table *drm_gem_shmem_get_pages_sgt(struct drm_gem_object *obj) goto err_put_pages; } /* Map the pages for use by the h/w. */ - dma_map_sg(obj->dev->dev, sgt->sgl, sgt->nents, DMA_BIDIRECTIONAL); + if (!shmem->skip_dma_api) + shmem->dma_map_count = dma_map_sg(obj->dev->dev, sgt->sgl, + sgt->nents, + DMA_BIDIRECTIONAL); shmem->sgt = sgt; diff --git a/include/drm/drm_gem_shmem_helper.h b/include/drm/drm_gem_shmem_helper.h index 5381f0c8cf6f..2669d87cbfdd 100644 --- a/include/drm/drm_gem_shmem_helper.h +++ b/include/drm/drm_gem_shmem_helper.h @@ -101,6 +101,16 @@ struct drm_gem_shmem_object { * @map_cached: map object cached (instead of using writecombine). */ bool map_cached; + + /** + * @skip_dma_api: skip using dma api in certain places. + */ + bool skip_dma_api; + + /** + * @skip_dma_api: number of pages mapped by dma-api. + */ + bool dma_map_count; }; #define to_drm_gem_shmem_obj(obj) \ -- 2.25.1

4 8

valgrind-mmt: rebased against latest upstream valgrind release v3.16.1
by Rhys Kidd 22 Jun '20

22 Jun '20

As an update to the nouveau development community, the downstream fork of Valgrind with a mmap tracing tool ("mmt") we maintain has been rebased against the latest upstream release of Valgrind, v3.16.1 Code branch: https://github.com/envytools/valgrind/tree/mmt-3.16.1 Features of upstream Valgrind 3.16.x: https://www.valgrind.org/docs/manual/dist.news.html In selected highlights, the benefits of tracking the latest version of Valgrind is added support for AArch64 v8.1 and reduced memcheck false positive rate on highly optimised code. There are, as ever, many smaller refinements and bug fixes. v3.16.1 includes two bugs fixed after 3.16.0 was frozen. As our downstream valgrind-mmt was last released against v3.14, we also get the benefit of all bug fixes and features since then, including that the RDRAND and F16C insn set extensions are now supported. For anyone unfamiliar with valgrind-mmt, it is a userspace mmio tracer that assists nouveau reverse engineering efforts by tracing the commands sent to the card. There is an accompanying demmt tool within the enytools repo to better understand these trace logs. I would like to thank all the other nouveau developers who have worked on mmt over many years, including specifically airlied, mslusarz and kherbst. Best, Rhys

1 0

[PATCH][next] drm/mm/selftests: fix unsigned comparison with less than zero
by Colin King 22 Jun '20

22 Jun '20

From: Colin Ian King <colin.king(a)canonical.com> Function get_insert_time can return error values that are cast to a u64. The checks of insert_time1 and insert_time2 check for the errors but because they are u64 variables the check for less than zero can never be true. Fix this by casting the value to s64 to allow of the negative error check to succeed. Addresses-Coverity: ("Unsigned compared against 0, no effect") Fixes: 6e60d5ded06b ("drm/mm: add ig_frag selftest") Signed-off-by: Colin Ian King <colin.king(a)canonical.com> --- drivers/gpu/drm/selftests/test-drm_mm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c b/drivers/gpu/drm/selftests/test-drm_mm.c index 3846b0f5bae3..671a152a6df2 100644 --- a/drivers/gpu/drm/selftests/test-drm_mm.c +++ b/drivers/gpu/drm/selftests/test-drm_mm.c @@ -1124,12 +1124,12 @@ static int igt_frag(void *ignored) insert_time1 = get_insert_time(&mm, insert_size, nodes + insert_size, mode); - if (insert_time1 < 0) + if ((s64)insert_time1 < 0) goto err; insert_time2 = get_insert_time(&mm, (insert_size * 2), nodes + insert_size * 2, mode); - if (insert_time2 < 0) + if ((s64)insert_time2 < 0) goto err; pr_info("%s fragmented insert of %u and %u insertions took %llu and %llu nsecs\n", -- 2.27.0.rc0

5 5

[PATCH] drm/msm: Fix up the rest of the messed up address sizes
by Jordan Crouse 22 Jun '20

22 Jun '20

msm_gem_address_space_create() changed to take a start/length instead of a start/end for the iova space but all of the callers were just cut and pasted from the old usage. Most of the mistakes have been fixed up so just catch up the rest. Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization") Signed-off-by: Jordan Crouse <jcrouse(a)codeaurora.org> --- drivers/gpu/drm/msm/adreno/a2xx_gpu.c | 2 +- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 2 +- drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 2 +- drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c index 60f6472a3e58..6021f8d9efd1 100644 --- a/drivers/gpu/drm/msm/adreno/a2xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a2xx_gpu.c @@ -408,7 +408,7 @@ a2xx_create_address_space(struct msm_gpu *gpu, struct platform_device *pdev) struct msm_gem_address_space *aspace; aspace = msm_gem_address_space_create(mmu, "gpu", SZ_16M, - SZ_16M + 0xfff * SZ_64K); + 0xfff * SZ_64K); if (IS_ERR(aspace) && !IS_ERR(mmu)) mmu->funcs->destroy(mmu); diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c index 096be97ce9f9..21e77d67151f 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c @@ -1121,7 +1121,7 @@ static int a6xx_gmu_memory_probe(struct a6xx_gmu *gmu) return -ENODEV; mmu = msm_iommu_new(gmu->dev, domain); - gmu->aspace = msm_gem_address_space_create(mmu, "gmu", 0x0, 0x7fffffff); + gmu->aspace = msm_gem_address_space_create(mmu, "gmu", 0x0, 0x80000000); if (IS_ERR(gmu->aspace)) { iommu_domain_free(domain); return PTR_ERR(gmu->aspace); diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c index b8615d4fe8a3..680527e28d09 100644 --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c @@ -780,7 +780,7 @@ static int _dpu_kms_mmu_init(struct dpu_kms *dpu_kms) mmu = msm_iommu_new(dpu_kms->dev->dev, domain); aspace = msm_gem_address_space_create(mmu, "dpu1", - 0x1000, 0xfffffff); + 0x1000, 0x100000000 - 0x1000); if (IS_ERR(aspace)) { mmu->funcs->destroy(mmu); diff --git a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c index 08897184b1d9..fc6a3f8134c7 100644 --- a/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c +++ b/drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c @@ -514,7 +514,7 @@ struct msm_kms *mdp4_kms_init(struct drm_device *dev) config->iommu); aspace = msm_gem_address_space_create(mmu, - "mdp4", 0x1000, 0xffffffff); + "mdp4", 0x1000, 0x100000000 - 0x1000); if (IS_ERR(aspace)) { if (!IS_ERR(mmu)) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c index 54631fbd9389..8586d2cf1d94 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c @@ -641,7 +641,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev) mmu = msm_iommu_new(iommu_dev, config->platform.iommu); aspace = msm_gem_address_space_create(mmu, "mdp5", - 0x1000, 0xffffffff); + 0x1000, 0x100000000 - 0x1000); if (IS_ERR(aspace)) { if (!IS_ERR(mmu)) -- 2.17.1

1 0

← Newer
1
...
34
35
36
37
38
39
40
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2020