dri-devel August 2019

dri-devel@lists.freedesktop.org

318 participants
2338 discussions

Re: turn hmm migrate_vma upside down v3
by Jason Gunthorpe 16 Aug '19

16 Aug '19

On Fri, Aug 16, 2019 at 08:51:41AM +0200, Christoph Hellwig wrote: > Jason, > > are you going to look into picking this up? Unfortunately there is > a hole pile in this area still pending, including the kvmppc secure > memory driver from Bharata that depends on the work. > > mm folks: migrate.c is mostly a classic MM file except for the hmm > additions. Do you want to also look over this or just let it pass? Yes, after you explained the functions were hmm ones, it seems OK to go to hmm.git. I was waiting for the dust to settle, I see Ralph tested-by, are we good now? Jason

1 0

[GIT PULL] etnaviv-next for 5.4
by Lucas Stach 16 Aug '19

16 Aug '19

Hi Daniel, Dave, after some pretty slow cycles we finally have a bit more exciting work ready for upstream. Most importantly per-process address spaces on GPUs that are capable of providing proper isolation has finished baking. This is the base for our softpin implementation, which allows us to support the texture descriptor buffers used by GC7000 series GPUs without a major UAPI extension/rework. Shortlog of notable changes: - code cleanup from Fabio - fix performance counters on GC880 and GC2000 GPUs from Christian - drmP.h header removal from Sam - per process address space support on MMUv2 GPUs from me - softpin support from me Regards, Lucas The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b: Linus 5.3-rc1 (2019-07-21 14:05:38 -0700) are available in the Git repository at: https://git.pengutronix.de/git/lst/linux etnaviv/next for you to fetch changes up to 088880ddc0b20086b71bb87b805fb63ff07c35f2: drm/etnaviv: implement softpin (2019-08-15 12:07:47 +0200) ---------------------------------------------------------------- Christian Gmeiner (2): etnaviv: fix whitespace errors etnaviv: perfmon: fix total and idle HI cyleces readout Fabio Estevam (1): drm/etnaviv: Use devm_platform_ioremap_resource() Lucas Stach (16): drm/etnaviv: clean up includes drm/etnaviv: fix etnaviv_cmdbuf_suballoc_new return value drm/etnaviv: remove unused function etnaviv_gem_mapping_reference drm/etnaviv: dump only failing submit drm/etnaviv: pass mmu pointer to etnaviv_core_dump_mmu drm/etnaviv: simplify unbind checks drm/etnaviv: split out cmdbuf mapping into address space drm/etnaviv: share a single cmdbuf suballoc region across all GPUs drm/etnaviv: replace MMU flush marker with flush sequence drm/etnaviv: rework MMU handling drm/etnaviv: split out starting of FE idle loop drm/etnaviv: provide MMU context to etnaviv_gem_mapping_get drm/etnaviv: implement per-process address spaces on MMUv2 drm/etnaviv: skip command stream validation on PPAS capable GPUs drm/etnaviv: allow to request specific virtual address for gem mapping drm/etnaviv: implement softpin Sam Ravnborg (1): drm/etnaviv: drop use of drmP.h drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 93 ++++++++++---- drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.c | 58 +++++---- drivers/gpu/drm/etnaviv/etnaviv_cmdbuf.h | 15 ++- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 68 ++++++++-- drivers/gpu/drm/etnaviv/etnaviv_drv.h | 27 ++-- drivers/gpu/drm/etnaviv/etnaviv_dump.c | 65 ++++------ drivers/gpu/drm/etnaviv/etnaviv_dump.h | 4 +- drivers/gpu/drm/etnaviv/etnaviv_gem.c | 56 ++++---- drivers/gpu/drm/etnaviv/etnaviv_gem.h | 8 +- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 2 + drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 45 ++++++- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 158 ++++++++++++----------- drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 11 +- drivers/gpu/drm/etnaviv/etnaviv_iommu.c | 165 +++++++++++------------- drivers/gpu/drm/etnaviv/etnaviv_iommu.h | 20 --- drivers/gpu/drm/etnaviv/etnaviv_iommu_v2.c | 284 ++++++++++++++++++----------------------- drivers/gpu/drm/etnaviv/etnaviv_mmu.c | 326 ++++++++++++++++++++++++++++++++--------------- drivers/gpu/drm/etnaviv/etnaviv_mmu.h | 114 ++++++++++++----- drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 48 +++++-- drivers/gpu/drm/etnaviv/etnaviv_sched.c | 4 +- include/uapi/drm/etnaviv_drm.h | 10 +- 21 files changed, 922 insertions(+), 659 deletions(-) delete mode 100644 drivers/gpu/drm/etnaviv/etnaviv_iommu.h

1 0

[Bug 109380] [CI][BAT] igt@kms_chamelium@*- warn/fail - Last errno: 113, No route to host
by bugzilla-daemon＠freedesktop.org 16 Aug '19

16 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=109380 --- Comment #5 from Arek Hiler <arkadiusz.hiler(a)intel.com> --- https://patchwork.freedesktop.org/patch/324290/ -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH 1/4] dma-fence: Propagate errors to dma-fence-array container
by Chris Wilson 16 Aug '19

16 Aug '19

When one of the array of fences is signaled, propagate its errors to the parent fence-array (keeping the first error to be raised). v2: Opencode cmpxchg_local to avoid compiler freakout. Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Gustavo Padovan <gustavo(a)padovan.org> --- drivers/dma-buf/dma-fence-array.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/drivers/dma-buf/dma-fence-array.c b/drivers/dma-buf/dma-fence-array.c index 12c6f64c0bc2..d90675bb4fcc 100644 --- a/drivers/dma-buf/dma-fence-array.c +++ b/drivers/dma-buf/dma-fence-array.c @@ -13,6 +13,12 @@ #include <linux/slab.h> #include <linux/dma-fence-array.h> +static void fence_set_error_once(struct dma_fence *fence, int error) +{ + if (!fence->error && error) + dma_fence_set_error(fence, error); +} + static const char *dma_fence_array_get_driver_name(struct dma_fence *fence) { return "dma_fence_array"; @@ -38,6 +44,13 @@ static void dma_fence_array_cb_func(struct dma_fence *f, container_of(cb, struct dma_fence_array_cb, cb); struct dma_fence_array *array = array_cb->array; + /* + * Propagate the first error reported by any of our fences, but only + * before we ourselves are signaled. + */ + if (atomic_read(&array->num_pending) > 0) + fence_set_error_once(&array->base, f->error); + if (atomic_dec_and_test(&array->num_pending)) irq_work_queue(&array->work); else @@ -63,6 +76,8 @@ static bool dma_fence_array_enable_signaling(struct dma_fence *fence) dma_fence_get(&array->base); if (dma_fence_add_callback(array->fences[i], &cb[i].cb, dma_fence_array_cb_func)) { + fence_set_error_once(&array->base, + array->fences[i]->error); dma_fence_put(&array->base); if (atomic_dec_and_test(&array->num_pending)) return false; -- 2.23.0.rc1

5 28

[Bug 109380] [CI][BAT] igt@kms_chamelium@*- warn/fail - Last errno: 113, No route to host
by bugzilla-daemon＠freedesktop.org 16 Aug '19

16 Aug '19

https://bugs.freedesktop.org/show_bug.cgi?id=109380 Arek Hiler <arkadiusz.hiler(a)intel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|medium |high --- Comment #4 from Arek Hiler <arkadiusz.hiler(a)intel.com> --- Other than occasional flukes here and there the biggest offender seems to be *after-suspend* family of subtest. The most representative scenario looks like that: 1. schedule something on chamelium 2. got to sleep 3. scheduled thing triggers 4. wake up 5. check whether we see the changes reflected through DRM and pass 6. exit triggring chamelium cleanup During 6 we have a failed RPC because network is not up yet after waking up, which overwrites the test results to WARN. Solution: introduce chamelium_wait_online(int timeout) that pings the device and bails out after timeout. Always call it after waking up. Everything else looks like sporadic network issues, but we have seen it just a few times in the last months. We can investigate them further once we will get rid of the main source of the noise. Impact on users: none, it's a CI/test issue. Impact on testing: potentially huge, as some of the tests may leave us with chamelium ports unplugged adding to the flip-flopping of the 2x tests. Bumping priority to high, as it is easy to solve and important for keeping the CI noise down. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH] dma-buf: fix a memory leak bug
by Wenwen Wang 16 Aug '19

16 Aug '19

In sync_file_merge(), 'fences' is firstly allocated through kcalloc(). Later on, if the size is not sufficient, krealloc() is invoked to reallocate 'nfences', which is assigned to 'fences'. However, if krealloc() fails, 'fences' is not deallocated, leading to a memory leak bug. To fix the above issue, free 'fences' before go to the 'err' label. Signed-off-by: Wenwen Wang <wenwen(a)cs.uga.edu> --- drivers/dma-buf/sync_file.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c index ee4d1a9..6e2b2d3 100644 --- a/drivers/dma-buf/sync_file.c +++ b/drivers/dma-buf/sync_file.c @@ -272,8 +272,10 @@ static struct sync_file *sync_file_merge(const char *name, struct sync_file *a, if (num_fences > i) { nfences = krealloc(fences, i * sizeof(*fences), GFP_KERNEL); - if (!nfences) + if (!nfences) { + kfree(fences); goto err; + } fences = nfences; } -- 2.7.4

1 0

[PATCH 0/1] drm/hisilicon/hibmc: Make CONFIG_DRM_HISI_HIBMC depend on ARM64
by Matthew Ruffell 16 Aug '19

16 Aug '19

Hi, amd64 based Huawei servers have problems where the display output of their iBMC chips is broken, resulting in a "blurry" screen when viewed from their in house remote kvm-like console. Example: https://launchpadlibrarian.net/365907668/creen_picture_for_blur.png The issue is caused by the hibmc_drm kernel module being loaded. The PCI ID for the iBMC chips on amd64 hardware is the same as arm64 hardware, but the hibmc_drm driver was developed only for use on arm64 hardware, most notably for the Huawei D05 development board. The impact to Huawei is that their customers cannot use Ubuntu server install media as the screen goes "blurry" when the d-i install media or subuqity installer loads the hibmc_drm kernel module after language selection. The only workaround for their customers is to press the "E" key during the very first installer menu and adding "modprobe.blacklist=hibmc_drm" to the kernel command line in the grub menu. This is not good for customer experience with their servers. Huawei help site on the matter: https://support.huawei.com/enterprise/en/knowledge/EKB1100015521 Other problems exist for the hibmc_drm driver on amd64, such as working on bios, but not uefi, and not being wayland compatible, making the screen "blurry" whenever a desktop session is started and gdm loaded. More information about the above can be found on Launchpad: https://bugs.launchpad.net/bugs/1762940 Huawei have asked us to remove hibmc_drm from all architectures except arm64, and this aligns with advice from Hisilicon. Hibmc maintainers, can you please review the status of hibmc_drm on amd64 and confirm that these issues exist, and consider merging the patch to update Kconfig to set CONFIG_DRM_HISI_HIBMC arm64 only. Matthew Ruffell (1): drm/hisilicon/hibmc: Make CONFIG_DRM_HISI_HIBMC depend on ARM64 drivers/gpu/drm/hisilicon/hibmc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.20.1

2 2

Re: [PATCH 0/6] drm+dma: cache support for arm, etc
by Koenig, Christian 15 Aug '19

15 Aug '19

Sorry if the style is messed up, replying from my phone. Am 15.08.2019 20:27 schrieb Christoph Hellwig <hch(a)lst.de>: On Thu, Aug 15, 2019 at 06:21:00PM +0000, Koenig, Christian wrote: > > (2) Add support for DMA_ATTR_NO_KERNEL_MAPPING to this new API instead > > of dma_alloc_attrs. The initial difference with that flag is just > > that we allow highmem, but in the future we could also unmap this > > memory from the kernel linear mapping entirely on architectures > > where we can easily do that. > > Mhm, why would we want to do this? To avoid the CPU misspeculating into this memory. For example NVMe SSDs have a feature called host memory buffer that is a lot like your stolen main ram for the GPU case. We currently hand the SSD a DMA_ATTR_NO_KERNEL_MAPPING allocation if it requests such a buffer. If possible we'd really like to make sure no speculative execution bug (or intentional attacker with a kernel exploit for that matter) can easily access that memory. Well, for the graphics case I absolutely need to keep the linear kernel mapping. Because for certain use cases the memory is accessed by the kernel all the time as well. Why should accessing uncached memory be more of a security problem than accessing cached? Regards, Christian

1 0

[RFC] drm: Bump encoder limit from 32 to 64
by Lyude Paul 15 Aug '19

15 Aug '19

Assuming that GPUs would never have even close to 32 separate video encoders is quite honestly a pretty reasonable assumption. Unfortunately we do not live in a reasonable world, as it looks like it is actually possible to find devices that will create more drm_encoder objects then this. Case in point: the ThinkPad P71's discrete GPU, which exposes 1 eDP port and 5 DP ports. On the P71, nouveau attempts to create one encoder for the eDP port, and two encoders for each DP++/USB-C port along with 4 MST encoders for each DP port. This comes out to 35 different encoders. Unfortunately, this can't really be optimized to make less encoders either. So, what if we bumped the limit to 64? Unfortunately this has one very awkward drawback: we already expose 32-bit bitmasks for encoders to userspace in drm_encoder->possible_clones. Yikes. Luckily for us however, the year is 2019 and modern hardware that supports cloning is basically non-existent. So, let's try to compromise here: allow encoders with indexes <32 to have non-zero values in drm_encoder->possible_clones, and don't allow encoders with higher indexes to set drm_encoder->possible_clones to a non-zero value. This allows us to avoid breaking UAPI, while still being able to bump up the encoder limit. This also fixes driver probing for nouveau on the ThinkPad P71. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: nouveau(a)lists.freedesktop.org --- drivers/gpu/drm/drm_atomic.c | 2 +- drivers/gpu/drm/drm_encoder.c | 10 ++++++++-- include/drm/drm_crtc.h | 2 +- include/drm/drm_encoder.h | 20 +++++++++++++++----- 4 files changed, 25 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 419381abbdd1..27ce988ef0cc 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -392,7 +392,7 @@ static void drm_atomic_crtc_print_state(struct drm_printer *p, drm_printf(p, "\tcolor_mgmt_changed=%d\n", state->color_mgmt_changed); drm_printf(p, "\tplane_mask=%x\n", state->plane_mask); drm_printf(p, "\tconnector_mask=%x\n", state->connector_mask); - drm_printf(p, "\tencoder_mask=%x\n", state->encoder_mask); + drm_printf(p, "\tencoder_mask=%llx\n", state->encoder_mask); drm_printf(p, "\tmode: " DRM_MODE_FMT "\n", DRM_MODE_ARG(&state->mode)); if (crtc->funcs->atomic_print_state) diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c index 7fb47b7b8b44..e4b8f675aa81 100644 --- a/drivers/gpu/drm/drm_encoder.c +++ b/drivers/gpu/drm/drm_encoder.c @@ -112,8 +112,14 @@ int drm_encoder_init(struct drm_device *dev, { int ret; - /* encoder index is used with 32bit bitmasks */ - if (WARN_ON(dev->mode_config.num_encoder >= 32)) + /* + * Since possible_clones has been exposed to userspace as a 32bit + * bitmask, we don't allow creating encoders with an index >=32 which + * are capable of cloning. + */ + if (WARN_ON(dev->mode_config.num_encoder >= 64) || + WARN_ON(dev->mode_config.num_encoder >= 32 && + encoder->possible_clones)) return -EINVAL; ret = drm_mode_object_add(dev, &encoder->base, DRM_MODE_OBJECT_ENCODER); diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index 7d14c11bdc0a..fd0b2438c3d5 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -210,7 +210,7 @@ struct drm_crtc_state { * @encoder_mask: Bitmask of drm_encoder_mask(encoder) of encoders * attached to this CRTC. */ - u32 encoder_mask; + u64 encoder_mask; /** * @adjusted_mode: diff --git a/include/drm/drm_encoder.h b/include/drm/drm_encoder.h index 70cfca03d812..3f9cb65694e1 100644 --- a/include/drm/drm_encoder.h +++ b/include/drm/drm_encoder.h @@ -159,7 +159,15 @@ struct drm_encoder { * encoders can be used in a cloned configuration, they both should have * each another bits set. * - * In reality almost every driver gets this wrong. + * In reality almost every driver gets this wrong, and most modern + * display hardware does not have support for cloning. As well, while we + * expose this mask to userspace as 32bits long, we do sure purely to + * avoid breaking pre-existing UAPI since the limitation on the number + * of encoders has been increased from 32 bits to 64 bits. In order to + * maintain functionality for drivers which do actually support cloning, + * we only allow cloning with encoders that have an index <32. Encoders + * with indexes higher than 32 are not allowed to specify a non-zero + * value here. * * Note that since encoder objects can't be hotplugged the assigned indices * are stable and hence known before registering all objects. @@ -198,13 +206,15 @@ static inline unsigned int drm_encoder_index(const struct drm_encoder *encoder) } /** - * drm_encoder_mask - find the mask of a registered ENCODER + * drm_encoder_mask - find the mask of a registered encoder * @encoder: encoder to find mask for * - * Given a registered encoder, return the mask bit of that encoder for an - * encoder's possible_clones field. + * Returns: + * A bit mask with the nth bit set, where n is the index of the encoder. Take + * care when using this, as the DRM UAPI only allows for 32 bit encoder masks + * while internally encoder masks are 64 bits. */ -static inline u32 drm_encoder_mask(const struct drm_encoder *encoder) +static inline u64 drm_encoder_mask(const struct drm_encoder *encoder) { return 1 << drm_encoder_index(encoder); } -- 2.21.0

2 1

Re: [PATCH 0/6] drm+dma: cache support for arm, etc
by Koenig, Christian 15 Aug '19

15 Aug '19

Am 15.08.19 um 19:53 schrieb Christoph Hellwig: > On Thu, Aug 15, 2019 at 06:54:39AM -0700, Rob Clark wrote: >> On Wed, Aug 14, 2019 at 11:51 PM Christoph Hellwig <hch(a)lst.de> wrote: >>> As said before I don't think these low-level helpers are the >>> right API to export, but even if they did you'd just cover a tiny >>> subset of the architectures. >> Are you thinking instead something like: >> >> void dma_sync_sg_for_{cpu,device}(struct device *dev, struct scatterlist *sgl, >> int nents, enum dma_data_direction dir) >> { >> for_each_sg(sgl, sg, nents, i) { >> arch_sync_dma_for_..(dev, sg_phys(sg), sg->length, dir); >> } >> } >> EXPORT_SYMBOL_GPL(dma_sync_sg_for_..) >> >> or did you have something else in mind? > No. We really need an interface thay says please give me uncached > memory (for some definition of uncached that includes that grapics > drivers call write combine), and then let the architecture do the right > thing. Basically dma_alloc_coherent with DMA_ATTR_NO_KERNEL_MAPPING > is superficially close to what you want, except that the way the drm > drivers work you can't actually use it. The terminology graphics driver use is USWC (Uncached Speculative Write Combine). Essentially it is a leftover from the AGP days where the graphics devices couldn't snoop the CPU caches. Nowadays they either don't want to snoop the CPU caches for performance reasons. Or because of special requirements that certain areas of system memory are not cached for certain functionality. For example the "VRAM" on AMD GPUs which are integrated into the CPU is just stolen system memory. Then you can scanout your picture to the display from this memory or "normal" system memory, but only if the system memory is mapped as USWC. > The reason for that is if we can we really need to not create another > uncachable alias, but instead change the page attributes in place. > On x86 we can and must do that for example, and based on the > conversation with Will arm64 could do that fairly easily. arm32 can > right now only do that for CMA, though. > > The big question is what API do we want. I had a pretty similar > discussion with Christian on doing such an allocation for amdgpu, > where the device normally is cache coherent, but they actually want > to turn it into non-coherent by using PCIe unsnooped transactions. > > Here is my high level plan, which still has a few lose end: > > (1) provide a new API: > > struct page *dma_alloc_pages(struct device *dev, unsigned nr_pages, > gfp_t gfp, unsigned long flags); > void dma_free_pages(struct device *dev, unsigned nr_pages, > unsigned long flags); > > These give you back page backed memory that is guaranteed to be > addressable by the device (no swiotlb or similar). The memory can > then be mapped using dma_map*, including unmap and dma_sync to > bounce ownership around. This is the replacement for the current > dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT API, that is rather > badly defined. > > (2) Add support for DMA_ATTR_NO_KERNEL_MAPPING to this new API instead > of dma_alloc_attrs. The initial difference with that flag is just > that we allow highmem, but in the future we could also unmap this > memory from the kernel linear mapping entirely on architectures > where we can easily do that. Mhm, why would we want to do this? > > (3) Add a dma_pages_map/dma_pages_unmap or similar API that allows you > to get a kernel mapping for parts or all of a > DMA_ATTR_NO_KERNEL_MAPPING allocation. This is to replace things > like your open-coded vmap in msm (or similarly elsewhere in dma-buf > providers). > > (4) Add support for a DMA_ATTR_UNCACHABLE flags (or similar) to the new > API, that maps the pages as uncachable iff they have a kernel > mapping, including invalidating the caches at time of this page > attribute change (or creation of a new mapping). This API will fail > if the architecture does not allow in-place remapping. Note that for > arm32 we could always dip into the CMA pool if one is present to not > fail. We'll also need some helper to map from the DMA_ATTR_* flags > to a pgprot for mapping the page to userspace. There is also a few > other weird bits here, e.g. on architectures like mips that use an > uncached segment we'll have to fail use with the plain > DMA_ATTR_UNCACHABLE flag, but it could be supported with > DMA_ATTR_UNCACHABLE | DMA_ATTR_NO_KERNEL_MAPPING. > > I was hoping to get most of this done for this merge window, but I'm > probably lucky if I get at least parts done. Too much distraction. Thanks again for taking care of this, Christian. > >> Hmm, not entirely sure why.. you should be on the cc list for each >> individual patch. > They finally made it, although even with the delay they only ended up > in the spam mailbox. I still can't see them on the various mailing > lists.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2019