Re: [PATCH 3/4] drm/hisilicon/hibmc: Implement hibmc_dumb_create() with generic helpers

Hi thanks for the review. Am 23.11.19 um 09:56 schrieb Sam Ravnborg: > Hi Thomas. > > Change looks good. If you spin this could you move the > changes to generic drm code to a separate patch? > As it is now it is hidden for most. > But then there are also no users of

Re: [PATCH 3/4] drm/hisilicon/hibmc: Implement hibmc_dumb_create() with generic helpers

Hi Am 25.11.19 um 10:14 schrieb Daniel Vetter: > On Fri, Nov 22, 2019 at 09:30:43AM +0100, Thomas Zimmermann wrote: >> The hibmc driver aligns scanlines to 16 bytes. Adding the pitch alignment >> as an argument to drm_gem_vram_fill_create_dumb() allows to use the generic >> implementation with

[PATCH 2/4] drm/mgag200: Store flags from PCI driver data in device structure

The flags field in struct mga_device has been unused so far. We now use it to store flag bits from the PCI driver. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/mgag200/mgag200_drv.h | 8 drivers/gpu/drm/mgag200/mgag200_main.c | 1 + 2 files changed, 9 insertions(+) diff --git

[PATCH 4/4] drm/mgag200: Add module parameter to pin all buffers at offset 0

For hardware that does not interpret the startadd field correctly, add the module parameter 'hw_bug_no_startadd', which enables the workaround. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/mgag200/mgag200_drv.c | 8 1 file changed, 8 insertions(+) diff --git

[PATCH 0/4] drm/mgag200: Workaround HW bug with non-0 offset

We found an MGA chip that does not interpret the scanout offset correctly. This patch works around the problem by placing all buffer objects at offset 0 on this system. There's a new module parameter 'hw_bug_no_startadd' that enables and disables the offset-0 placement. Default is auto-detection.

[PATCH 3/4] drm/mgag200: Add workaround for HW that does not support 'startadd'

There's at least one system that does not interpret the value of the device's 'startadd' field correctly, which leads to incorrectly displayed scanout buffers. Always placing the active scanout buffer at offset 0 works around the problem. Signed-off-by: Thomas Zimmermann Reported-by: John

[PATCH 1/4] drm/mgag200: Extract device type from flags

Adds a conversion function that extracts the device type from the PCI id-table flags. Allows for storing additional information in the other flag bits. Signed-off-by: Thomas Zimmermann --- drivers/gpu/drm/mgag200/mgag200_drv.h | 7 +++ drivers/gpu/drm/mgag200/mgag200_main.c | 2 +- 2 files

[PATCH 6/7] drm/mediatek: support CMDQ interface in ddp component

The CMDQ (Command Queue) in MT8183 is used to help update all relevant display controller registers with critical time limation. This patch add cmdq interface in ddp_comp interface, let all ddp_comp interface can support cpu/cmdq function at the same time. Signed-off-by: YT Shen Signed-off-by:

[PATCH 7/7] drm/mediatek: apply CMDQ control flow

Unlike other SoCs, MT8183 does not have "shadow" registers for performaing an atomic video mode set or page flip at vblank/vsync. The CMDQ (Commend Queue) in MT8183 is used to help update all relevant display controller registers with critical time limation. Signed-off-by: YT Shen

[PATCH 0/7] drm/mediatek: fix cursor issue and apply CMDQ in

The CMDQ (Command Queue) in MT8183 is used to help update all relevant display controller registers with critical time limation. This patch add cmdq interface in ddp_comp interface, let all ddp_comp interface can support cpu/cmdq function at the same time. These patches also can fixup cursor

[PATCH 1/7] drm/mediatek: fix atomic_state reference counting

The DRM core takes care of all atomic state refcounting. However, mediatek drm defers some work that accesses planes and plane_states in drm_atomic_state, and must therefore keep its own atomic state references until this work complete. We take the atomic_state reference in atomic_fulsh() and

[PATCH 4/7] drm/mediatek: handle events when enabling/disabling crtc

The driver currently handles vblank events only when updating planes on an already enabled CRTC. The atomic update API however allows requesting an event when enabling or disabling a CRTC. This currently leads to event objects being leaked in the kernel and to events not being sent out. Fix it.

[PATCH 3/7] drm/mediatek: use DRM core's atomic commit helper

The DRM core atomic helper now supports asynchronous commits natively. The custom drm implementation isn't needed anymore, remove it. Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 92 +- drivers/gpu/drm/mediatek/mtk_drm_drv.h | 7 -- 2 files

[PATCH 2/7] drm/mediatek: put "event" in critical section

The state->base.event variable would be access by thread context in mtk_drm_crtc_atomic_begin() or by interrupt context in mtk_drm_crtc_finish_page_flip(), so each part should be a critical section. Fix it. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")

[PATCH 5/7] drm/mediatek: update cursors by using async atomic update

Support to async updates of cursors by using the new atomic interface for that. Signed-off-by: Bibby Hsieh --- drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 41 ++- drivers/gpu/drm/mediatek/mtk_drm_crtc.h | 3 ++ drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++

[PATCH 3/5] udmabuf: add a pointer to the miscdevice in dma-buf private data

Will be used later. v2: rename 'udmabuf_misc' to 'device' (kraxel) Signed-off-by: Gurchetan Singh --- drivers/dma-buf/udmabuf.c | 12 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index

[PATCH 2/5] udmabuf: allow userspace to set map attributes

The main use for udmabuf is sending guest memory pages to the host. It's generally a bad idea to have to separate mappings with different attributes. For example, a WC mapping the guest kernel and cached mapping on the host is problematic. v2: Cache attribute flags instead of read/write flags

[PATCH 1/5] udmabuf: use cache_sgt_mapping option

The GEM prime helpers do it, so should we. It's also possible to make it optional later. Signed-off-by: Gurchetan Singh --- drivers/dma-buf/udmabuf.c | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index

[PATCH 4/5] udmabuf: separate out creating/destroying scatter-table

These are nice functions and can be re-used. Signed-off-by: Gurchetan Singh --- drivers/dma-buf/udmabuf.c | 26 +++--- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/drivers/dma-buf/udmabuf.c b/drivers/dma-buf/udmabuf.c index 9e6fdd2bc979..67e89bb034c5 100644

[PATCH 5/5] udmabuf: implement begin_cpu_access/end_cpu_access hooks

With the misc device, we should end up using the result of get_arch_dma_ops(..) or dma-direct ops. This can allow us to have WC mappings in the guest after synchronization. Signed-off-by: Gurchetan Singh --- drivers/dma-buf/udmabuf.c | 40 +++ 1 file

Re: [PATCH 05/15] drm/armada: Delete dma_buf->k(un)map implemenation

On Mon, Nov 25, 2019 at 10:44:43PM +0100, Daniel Vetter wrote: > On Mon, Nov 18, 2019 at 11:35:26AM +0100, Daniel Vetter wrote: > > It's a dummy anyway. > > > > Signed-off-by: Daniel Vetter > > Cc: Russell King > > I merged the entire series except this one and the final patch, sill > waiting

Re: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

Christian asked to submit it to drm-misc instead of our drm-next to avoid later conflicts with Steven's patch which he mentioned in this thread which is not in drm-next yet. Christian, Alex, once this merged to drm-misc I guess we need to pull all latest changes from there to drm-next so the

[PATCH v2 17/19] powerpc: book3s64: convert to pin_user_pages() and put_user_page()

1. Convert from get_user_pages() to pin_user_pages(). 2. As required by pin_user_pages(), release these pages via put_user_page(). In this case, do so via put_user_pages_dirty_lock(). That has the side effect of calling set_page_dirty_lock(), instead of set_page_dirty(). This is probably more

[PATCH v2 18/19] mm/gup_benchmark: use proper FOLL_WRITE flags instead of hard-coding "1"

Fix the gup benchmark flags to use the symbolic FOLL_WRITE, instead of a hard-coded "1" value. Also, clean up the filtering of gup flags a little, by just doing it once before issuing any of the get_user_pages*() calls. This makes it harder to overlook, instead of having little "gup_flags & 1"

[PATCH v2 15/19] media/v4l2-core: pin_user_pages (FOLL_PIN) and put_user_page() conversion

1. Change v4l2 from get_user_pages() to pin_user_pages(). 2. Because all FOLL_PIN-acquired pages must be released via put_user_page(), also convert the put_page() call over to put_user_pages_dirty_lock(). Acked-by: Hans Verkuil Cc: Ira Weiny Signed-off-by: John Hubbard ---

[PATCH v2 16/19] vfio, mm: pin_user_pages (FOLL_PIN) and put_user_page() conversion

1. Change vfio from get_user_pages_remote(), to pin_user_pages_remote(). 2. Because all FOLL_PIN-acquired pages must be released via put_user_page(), also convert the put_page() call over to put_user_pages_dirty_lock(). Note that this effectively changes the code's behavior in

[PATCH v2 19/19] mm, tree-wide: rename put_user_page*() to unpin_user_page*()

In order to provide a clearer, more symmetric API for pinning and unpinning DMA pages. This way, pin_user_pages*() calls match up with unpin_user_pages*() calls, and the API is a lot closer to being self-explanatory. Reviewed-by: Jan Kara Signed-off-by: John Hubbard ---

[PATCH v2 01/19] mm/gup: factor out duplicate code from four routines

There are four locations in gup.c that have a fair amount of code duplication. This means that changing one requires making the same changes in four places, not to mention reading the same code four times, and wondering if there are subtle differences. Factor out the common code into static

[PATCH v2 03/19] mm: Cleanup __put_devmap_managed_page() vs ->page_free()

From: Dan Williams After the removal of the device-public infrastructure there are only 2 ->page_free() call backs in the kernel. One of those is a device-private callback in the nouveau driver, the other is a generic wakeup needed in the DAX case. In the hopes that all ->page_free() callbacks

[PATCH v2 05/19] mm: fix get_user_pages_remote()'s handling of FOLL_LONGTERM

As it says in the updated comment in gup.c: current FOLL_LONGTERM behavior is incompatible with FAULT_FLAG_ALLOW_RETRY because of the FS DAX check requirement on vmas. However, the corresponding restriction in get_user_pages_remote() was slightly stricter than is actually required: it forbade all

[PATCH v2 13/19] net/xdp: set FOLL_PIN via pin_user_pages()

Convert net/xdp to use the new pin_longterm_pages() call, which sets FOLL_PIN. Setting FOLL_PIN is now required for code that requires tracking of pinned pages. In partial anticipation of this work, the net/xdp code was already calling put_user_page() instead of put_page(). Therefore, in order to

[PATCH v2 07/19] mm/gup: introduce pin_user_pages*() and FOLL_PIN

Introduce pin_user_pages*() variations of get_user_pages*() calls, and also pin_longterm_pages*() variations. For now, these are placeholder calls, until the various call sites are converted to use the correct get_user_pages*() or pin_user_pages*() API. These variants will eventually all set

[PATCH v2 11/19] drm/via: set FOLL_PIN via pin_user_pages_fast()

Convert drm/via to use the new pin_user_pages_fast() call, which sets FOLL_PIN. Setting FOLL_PIN is now required for code that requires tracking of pinned pages, and therefore for any code that calls put_user_page(). In partial anticipation of this work, the drm/via driver was already calling

[PATCH v2 14/19] media/v4l2-core: set pages dirty upon releasing DMA buffers

After DMA is complete, and the device and CPU caches are synchronized, it's still required to mark the CPU pages as dirty, if the data was coming from the device. However, this driver was just issuing a bare put_page() call, without any set_page_dirty*() call. Fix the problem, by calling

[PATCH v2 09/19] IB/{core, hw, umem}: set FOLL_PIN via pin_user_pages*(), fix up ODP

Convert infiniband to use the new pin_user_pages*() calls. Also, revert earlier changes to Infiniband ODP that had it using put_user_page(). ODP is "Case 3" in Documentation/core-api/pin_user_pages.rst, which is to say, normal get_user_pages() and put_page() is the API to use there. The new

[PATCH v2 02/19] mm/gup: move try_get_compound_head() to top, fix minor issues

An upcoming patch uses try_get_compound_head() more widely, so move it to the top of gup.c. Also fix a tiny spelling error and a checkpatch.pl warning. Reviewed-by: Christoph Hellwig Reviewed-by: Jan Kara Reviewed-by: Ira Weiny Signed-off-by: John Hubbard --- mm/gup.c | 29

[PATCH v2 10/19] mm/process_vm_access: set FOLL_PIN via pin_user_pages_remote()

Convert process_vm_access to use the new pin_user_pages_remote() call, which sets FOLL_PIN. Setting FOLL_PIN is now required for code that requires tracking of pinned pages. Also, release the pages via put_user_page*(). Also, rename "pages" to "pinned_pages", as this makes for easier reading of

[PATCH v2 08/19] goldish_pipe: convert to pin_user_pages() and put_user_page()

1. Call the new global pin_user_pages_fast(), from pin_goldfish_pages(). 2. As required by pin_user_pages(), release these pages via put_user_page(). In this case, do so via put_user_pages_dirty_lock(). That has the side effect of calling set_page_dirty_lock(), instead of set_page_dirty(). This

[PATCH v2 12/19] fs/io_uring: set FOLL_PIN via pin_user_pages()

Convert fs/io_uring to use the new pin_user_pages() call, which sets FOLL_PIN. Setting FOLL_PIN is now required for code that requires tracking of pinned pages, and therefore for any code that calls put_user_page(). In partial anticipation of this work, the io_uring code was already calling

[PATCH v2 00/19] pin_user_pages(): reduced-risk series for Linux 5.5

n the last patch (instead of put_user_page() ). * Rebased onto today's linux-next: c165016bac27 ("Add linux-next specific files for 20191125") Here is a set of well-reviewed (expect for one patch), lower-ris

[PATCH v2 04/19] goldish_pipe: rename local pin_user_pages() routine

1. Avoid naming conflicts: rename local static function from "pin_user_pages()" to "goldfish_pin_pages()". An upcoming patch will introduce a global pin_user_pages() function. Reviewed-by: Jan Kara Reviewed-by: Jérôme Glisse Reviewed-by: Ira Weiny Signed-off-by: John Hubbard ---

[PATCH v2 06/19] vfio: fix FOLL_LONGTERM use, simplify get_user_pages_remote() call

Update VFIO to take advantage of the recently loosened restriction on FOLL_LONGTERM with get_user_pages_remote(). Also, now it is possible to fix a bug: the VFIO caller is logically a FOLL_LONGTERM user, but it wasn't setting FOLL_LONGTERM. Also, remove an unnessary pair of calls that were

Re: [PATCH 05/15] drm/armada: Delete dma_buf->k(un)map implemenation

On Mon, Nov 18, 2019 at 11:35:26AM +0100, Daniel Vetter wrote: > It's a dummy anyway. > > Signed-off-by: Daniel Vetter > Cc: Russell King I merged the entire series except this one and the final patch, sill waiting a bit more for an ack on this perhaps. -Daniel > --- >

RE: [PATCH v4] drm/scheduler: Avoid accessing freed bad job.

[AMD Official Use Only - Internal Distribution Only] Hi Andrey, Seems you didn't submit this patch? Best wishes Emily Deng >-Original Message- >From: Andrey Grodzovsky >Sent: Monday, November 25, 2019 12:51 PM >Cc: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org;

Re: [RFC 06/13] drm/i915/svm: Page table mirroring support

On Mon, Nov 25, 2019 at 11:33:27AM -0500, Jerome Glisse wrote: On Fri, Nov 22, 2019 at 11:33:12PM +, Jason Gunthorpe wrote: On Fri, Nov 22, 2019 at 12:57:27PM -0800, Niranjana Vishwanathapura wrote: [...] > +static int > +i915_range_fault(struct i915_svm *svm, struct hmm_range *range) >

RE: [PATCH v4] drm: Add support for DP 1.4 Compliance edid corruption test 4.2.2.6

Please kindly give a review on my latest revision. Thanks a lot. Regards, Jerry -Original Message- From: Jerry (Fangzhi) Zuo Sent: November 5, 2019 11:38 AM To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org Cc: ly...@redhat.com; manasi.d.nav...@intel.com; Wentland,

Re: [PATCH] Revert "drm/fbdev: Fallback to non tiled mode if all tiles not present"

On Mon, Nov 25, 2019 at 05:07:26PM +0200, Jani Nikula wrote: > On Sat, 23 Nov 2019, Uma Shankar wrote: > > This reverts commit f25c7a006cd1c07254780e3406e45cee4842b933. > > > > 2p2c display configuration blows up dmesg when one connector is > > disconnected, causing issues in CI. > > > > Below

[PATCH v4] drm/scheduler: Avoid accessing freed bad job.

Problem: Due to a race between drm_sched_cleanup_jobs in sched thread and drm_sched_job_timedout in timeout work there is a possiblity that bad job was already freed while still being accessed from the timeout thread. Fix: Instead of just peeking at the bad job in the mirror list remove it from

Re: [PATCH 17/19] powerpc: book3s64: convert to pin_user_pages() and put_user_page()

On 11/25/19 12:59 AM, Jan Kara wrote: > On Sun 24-11-19 20:20:09, John Hubbard wrote: >> 1. Convert from get_user_pages() to pin_user_pages(). >> >> 2. As required by pin_user_pages(), release these pages via >> put_user_page(). In this case, do so via put_user_pages_dirty_lock(). >> >> That has

Re: [PATCH 07/19] mm/gup: introduce pin_user_pages*() and FOLL_PIN

ote to help > improve the system. BTW, we also suggest to use '--base' option to specify the > base tree in git format-patch, please see > https://stackoverflow.com/a/37406982] > > url: > https://github.com/0day-ci/linux/commits/John-Hubbard/pin_user_pages-reduced-risk-series-for-Li

Re: [PATCH] drm/edid: Add modes from CTA-861-G

On Fri, Nov 22, 2019 at 09:50:53PM -0800, Thomas Anderson wrote: > The new modes are needed for exotic displays such as 8K. Verified that > modes like 8K60 and 4K120 are properly obtained from a Samsung Q900R. 978f6b0693c7 ("drm/edid: Add CTA-861-G modes with VIC < 128") and

Re: [PATCH] drm/edid: Add modes from CTA-861-G

Reviewed-by: Bhawanpreet Lakha On 2019-11-25 1:14 p.m., Harry Wentland wrote: +Bhawan who has been looking at this from our side. Harry On 2019-11-23 12:50 a.m., Thomas Anderson wrote: The new modes are needed for exotic displays such as 8K. Verified that modes like 8K60 and 4K120 are

Re: [PATCH 0/5] drm/udl: Convert to GEM framebuffer helpers

Hi Thomas. On Thu, Nov 14, 2019 at 03:10:20PM +0100, Thomas Zimmermann wrote: > Udl uses struct udl_framebuffer for representing its framebuffer. The > type can be replaced by the standard DRM framebuffer structure. > > Patches 1 to 4 prepare the driver for the conversion. Patch 5 replaces > the

Re: [PATCH] drm/edid: Add modes from CTA-861-G

+Bhawan who has been looking at this from our side. Harry On 2019-11-23 12:50 a.m., Thomas Anderson wrote: > The new modes are needed for exotic displays such as 8K. Verified that > modes like 8K60 and 4K120 are properly obtained from a Samsung Q900R. > > Signed-off-by: Thomas Anderson > --- >

Re: [Intel-gfx] [PATCH 3/7] drm: Extract page_flip_{internal, atomic}()

On Mon, Nov 25, 2019 at 4:05 PM Ville Syrjälä wrote: > > On Mon, Nov 25, 2019 at 10:02:38AM +0100, Daniel Vetter wrote: > > On Fri, Nov 22, 2019 at 08:35:13PM +0200, Ville Syrjälä wrote: > > > On Tue, Nov 19, 2019 at 11:14:43AM +0100, Daniel Vetter wrote: > > > > On Fri, Nov 15, 2019 at

[Bug 205649] New: Daisy Chain (MST) Session Crash after Screen Lock Resume

https://bugzilla.kernel.org/show_bug.cgi?id=205649 Bug ID: 205649 Summary: Daisy Chain (MST) Session Crash after Screen Lock Resume Product: Drivers Version: 2.5 Kernel Version: 5.4 Hardware: Intel OS:

Re: [PATCH v3 2/2] drm/scheduler: Avoid accessing freed bad job.

On 25/11/2019 14:10, Andrey Grodzovsky wrote: > Problem: > Due to a race between drm_sched_cleanup_jobs in sched thread and > drm_sched_job_timedout in timeout work there is a possiblity that > bad job was already freed while still being accessed from the > timeout thread. > > Fix: > Instead of

Re: [Intel-gfx] [RFC 03/13] drm/i915/svm: Runtime (RT) allocator support

On Mon, Nov 25, 2019 at 09:59:37AM +, Chris Wilson wrote: Quoting Niranjana Vishwanathapura (2019-11-22 20:57:24) Shared Virtual Memory (SVM) runtime allocator support allows binding a shared virtual address to a buffer object (BO) in the device page table through an ioctl call. The ioctl

Re: [PATCH v3 1/2] drm/sched: Avoid job cleanup if sched thread is parked.

On 25/11/2019 14:10, Andrey Grodzovsky wrote: > When the sched thread is parked we assume ring_mirror_list is > not accessed from here. FWIW I don't think this is necessary. kthread_park() will wait until the thread is parked, at which point the thread is stuck in kthread_parkme() until unparked.

Re: [RFC 06/13] drm/i915/svm: Page table mirroring support

On Mon, Nov 25, 2019 at 01:24:18PM +, Jason Gunthorpe wrote: On Sun, Nov 24, 2019 at 01:12:47PM -0800, Niranjan Vishwanathapura wrote: > > > Using a temporary range is the pattern from nouveau, is it really > > > necessary in this driver? > > > > Yah, not required. In my local build I

Re: [RFC 06/13] drm/i915/svm: Page table mirroring support

On Mon, Nov 25, 2019 at 01:24:18PM +, Jason Gunthorpe wrote: > On Sun, Nov 24, 2019 at 01:12:47PM -0800, Niranjan Vishwanathapura wrote: > > > > > > Using a temporary range is the pattern from nouveau, is it really > > > > > necessary in this driver? > > > > > > > > Yah, not required. In my

Re: [RFC 06/13] drm/i915/svm: Page table mirroring support

On Fri, Nov 22, 2019 at 11:33:12PM +, Jason Gunthorpe wrote: > On Fri, Nov 22, 2019 at 12:57:27PM -0800, Niranjana Vishwanathapura wrote: [...] > > +static int > > +i915_range_fault(struct i915_svm *svm, struct hmm_range *range) > > +{ > > + long ret; > > + > > + range->default_flags =

drm/edid: Add modes from CTA-861-G

Everything looks good. but one concern I have is that shouldn't the aspect ratio be 16:9 for some of them (See below). Unless I missed something? VIC 109 1280x720=*16:9* VIC 110 1680x720=*7:3* VIC 112 1920x1080=*16:9* VIC 116 3840x2160=*16:9* VIC

Re: [PATCH -next] drm/amd/powerplay: remove set but not used variable 'stretch_amount2'

On Mon, Nov 25, 2019 at 10:00 AM YueHaibing wrote: > > drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c: > In function vegam_populate_clock_stretcher_data_table: > drivers/gpu/drm/amd/amdgpu/../powerplay/smumgr/vegam_smumgr.c:1489:29: > warning: variable stretch_amount2 set but not

Re: [PATCH -next] drm/amd/display: remove set but not used variable 'msg_out'

On Mon, Nov 25, 2019 at 10:00 AM YueHaibing wrote: > > drivers/gpu/drm/amd/amdgpu/../display/modules/hdcp/hdcp_psp.c: In function > mod_hdcp_hdcp2_enable_encryption: > drivers/gpu/drm/amd/amdgpu/../display/modules/hdcp/hdcp_psp.c:633:77: > warning: variable msg_out set but not used

Re: [PATCH] Revert "drm/fbdev: Fallback to non tiled mode if all tiles not present"

On Sat, 23 Nov 2019, Uma Shankar wrote: > This reverts commit f25c7a006cd1c07254780e3406e45cee4842b933. > > 2p2c display configuration blows up dmesg when one connector is > disconnected, causing issues in CI. > > Below are the sample errors thrown in logs: > > [IGT] core_getversion: executing >

Re: [Intel-gfx] [PATCH 3/7] drm: Extract page_flip_{internal, atomic}()

On Mon, Nov 25, 2019 at 10:02:38AM +0100, Daniel Vetter wrote: > On Fri, Nov 22, 2019 at 08:35:13PM +0200, Ville Syrjälä wrote: > > On Tue, Nov 19, 2019 at 11:14:43AM +0100, Daniel Vetter wrote: > > > On Fri, Nov 15, 2019 at 09:42:00PM +0200, Ville Syrjala wrote: > > > > From: Ville Syrjälä > > >

Re: [PATCH] drm/radeon: remove redundant assignment to variable ret

On Fri, Nov 22, 2019 at 6:15 PM Colin King wrote: > > From: Colin Ian King > > The variable ret is being initialized with a value that is never > read and it is being updated later with a new value. The > initialization is redundant and can be removed. > > Addresses-Coverity: ("Unused value") >

Re: [PATCH] drm/amdgpu: Ensure ret is always initialized when using SOC15_WAIT_ON_RREG

On Mon, Nov 25, 2019 at 3:07 AM Nathan Chancellor wrote: > > Commit b0f3cd3191cd ("drm/amdgpu: remove unnecessary JPEG2.0 code from > VCN2.0") introduced a new clang warning in the vcn_v2_0_stop function: > > ../drivers/gpu/drm/amd/amdgpu/vcn_v2_0.c:1082:2: warning: variable 'r' > is used

Re: [PATCH] drm/amd/powerplay: remove redundant assignment to variables HiSidd and LoSidd

On Fri, Nov 22, 2019 at 6:04 PM Colin King wrote: > > From: Colin Ian King > > The variables HiSidd and LoSidd are being initialized with values that > are never read and are being updated a little later with a new value. > The initialization is redundant and can be removed. > >

Re: [PATCH libdrm v4] modetest: Add support for setting mode having floating vertical refresh rate

On Mon, Nov 25, 2019 at 07:34:37AM +, Devarsh Thakkar wrote: > Ping. Just wanted to confirm if the patch is applied or anything still > pending from my side ? Seems to work -> pushed. One thing I noticed is that we still print the modes with an integer vrefresh so it's a bit hard to know

Re: [PATCH] drm/amd/display: Use NULL for pointer assignment in copy_stream_update_to_stream

On 2019-11-23 2:36 p.m., Nathan Chancellor wrote: > Clang warns: > > ../drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:1965:26: warning: > expression which evaluates to zero treated as a null pointer constant of > type 'struct dc_dsc_config *' [-Wnon-literal-null-conversion] >

[PATCH v3 1/2] drm/sched: Avoid job cleanup if sched thread is parked.

When the sched thread is parked we assume ring_mirror_list is not accessed from here. Signed-off-by: Andrey Grodzovsky Reviewed-by: Christian König --- drivers/gpu/drm/scheduler/sched_main.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git

[PATCH v3 2/2] drm/scheduler: Avoid accessing freed bad job.

Problem: Due to a race between drm_sched_cleanup_jobs in sched thread and drm_sched_job_timedout in timeout work there is a possiblity that bad job was already freed while still being accessed from the timeout thread. Fix: Instead of just peeking at the bad job in the mirror list remove it from

Re: [PATCH] drm/amd: Fix Kconfig indentation

Applied. Thanks! Alex On Thu, Nov 21, 2019 at 11:13 AM Deucher, Alexander wrote: > > Reviewed-by: Alex Deucher > > From: Krzysztof Kozlowski > Sent: Thursday, November 21, 2019 8:29 AM > To: linux-ker...@vger.kernel.org > Cc: Krzysztof Kozlowski ; Deucher,

[PATCH 3/4] ARM: dts: dra76-evm: add HDMI output

Add DRA76 EVM HDMI output for the base board. Signed-off-by: Tomi Valkeinen --- arch/arm/boot/dts/dra76-evm.dts | 66 + 1 file changed, 66 insertions(+) diff --git a/arch/arm/boot/dts/dra76-evm.dts b/arch/arm/boot/dts/dra76-evm.dts index

[PATCH 4/4] ARM: dts: am57xx-idk-common: add HDMI to the common dtsi

AM571x/AM572x/AM574x IDK base boards have HDMI output. Add DT nodes to am57xx-idk-common.dtsi to enable HDMI. Signed-off-by: Tomi Valkeinen --- arch/arm/boot/dts/am57xx-idk-common.dtsi | 59 1 file changed, 59 insertions(+) diff --git

[PATCH 2/4] ARM: dts: am437x-epos-evm: add HDMI support

From: Jyri Sarha Add HDMI support for AM43x EPOS EVM. The HDMI uses SiI9022 HDMI encoder for audio and display, and it is mutually exclusive with the LCD and analogue audio. The choice between LCD + analogue audio and HDMI + HDMI-audio is made by booting either with am43x-epos-evm.dtb or

[PATCH 1/4] ARM: dts: am437x-gp-evm: add HDMI support

Add HDMI support for AM437x GP EVM. The HDMI uses SiI9022 HDMI encoder, and is mutually exclusive with the LCD. The choice between LCD and HDMI is made by booting either with am437x-gp-evm.dtb or am437x-gp-evm-hdmi.dtb. Signed-off-by: Tomi Valkeinen --- arch/arm/boot/dts/Makefile

Re: [PATCH v2] video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.

: i386-randconfig-b003-20191125 (attached as .config) compiler: gcc-7 (Debian 7.4.0-14) 7.4.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed

[Bug 110795] Unable to install on latest Ubuntu (19.04)

https://bugs.freedesktop.org/show_bug.cgi?id=110795 --- Comment #40 from phoenixsamp...@gmail.com --- CRITICAL ERROR: Loading new amdgpu-19.30-934563 DKMS files... Building for 5.3.0-20-generic Building for architecture x86_64 Building initial module for 5.3.0-20-generic ERROR (dkms apport):

Re: [PATCH v1 08/29] dt-bindings: interconnect: tegra: Add initial IDs

On Thu, Nov 21, 2019 at 08:14:35PM +0300, Dmitry Osipenko wrote: > 19.11.2019 19:56, Dmitry Osipenko пишет: > > 19.11.2019 09:25, Thierry Reding пишет: > >> On Mon, Nov 18, 2019 at 11:02:26PM +0300, Dmitry Osipenko wrote: > >>> Define interconnect IDs for memory controller (MC), external memory >

Re: [PATCH 08/15] drm/tegra: Remove dma_buf->k(un)map

On Mon, Nov 18, 2019 at 11:35:29AM +0100, Daniel Vetter wrote: > No in-tree users left. > > Signed-off-by: Daniel Vetter > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: linux-te...@vger.kernel.org > --- > drivers/gpu/drm/tegra/gem.c | 12 > 1 file changed, 12 deletions(-) Same

Re: [PATCH 02/15] drm/tegra: Delete host1x_bo_ops->k(un)map

On Mon, Nov 18, 2019 at 11:35:23AM +0100, Daniel Vetter wrote: > It doesn't have any callers anymore. > > Aside: The ->mmap/munmap hooks have a bit a confusing name, they don't > do userspace mmaps, but a kernel vmap. I think most places use vmap > for this, except ttm, which uses kmap for vmap

Re: [PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing

On Mon, Nov 18, 2019 at 11:35:22AM +0100, Daniel Vetter wrote: > A few reasons to drop kmap: > > - For native objects all we do is look at obj->vaddr anyway, so might > as well not call functions for every page. > > - Reloc-processing on dma-buf is ... questionable. > > - Plus most dma-buf

Re: [PATCH v3 RESEND] drm/bridge/synopsys: dsi: driver-specific configuration of phy timings

Am Montag, 25. November 2019, 11:09:39 CET schrieb Neil Armstrong: > Hi, > > On 25/11/2019 10:31, Heiko Stuebner wrote: > > From: Heiko Stuebner > > > > The timing values for dw-dsi are often dependent on the used display and > > according to Philippe Cornu will most likely also depend on the

[PATCH v4] drm/bridge/synopsys: dsi: driver-specific configuration of phy timings

From: Heiko Stuebner The timing values for dw-dsi are often dependent on the used display and according to Philippe Cornu will most likely also depend on the used phy technology in the soc-specific implementation. To solve this and allow specific implementations to define them as needed add a

Re: [PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing

On Mon, Nov 25, 2019 at 10:58:56AM +0100, Daniel Vetter wrote: > On Mon, Nov 18, 2019 at 11:35:22AM +0100, Daniel Vetter wrote: > > A few reasons to drop kmap: > > > > - For native objects all we do is look at obj->vaddr anyway, so might > > as well not call functions for every page. > > > > -

Re: [PATCH] drm/tegra: vic: Export module device table

On Mon, Nov 25, 2019 at 10:56:29AM +0100, Daniel Vetter wrote: > On Fri, Nov 22, 2019 at 02:32:15PM +0100, Thierry Reding wrote: > > From: Thierry Reding > > > > Export the module device table to ensure the VIC compatible strings are > > listed in the module's aliases table. This in turn causes

Re: [PATCH v4 11/13] ARM: shmobile_defconfig: Enable support for panels from EDT

On Tue, Nov 19, 2019 at 1:12 AM Laurent Pinchart wrote: > On Wed, Nov 13, 2019 at 03:51:30PM +, Fabrizio Castro wrote: > > The iwg20d comes with an LCD panel from Emerging Display > > Technologies Corporation (EDT), therefore enable what's > > required to support it. > > > > Signed-off-by:

Re: [PATCH v4 10/13] ARM: dts: iwg20d-q7-common: Add LCD support

On Tue, Nov 19, 2019 at 1:10 AM Laurent Pinchart wrote: > On Wed, Nov 13, 2019 at 03:51:29PM +, Fabrizio Castro wrote: > > The iwg20d comes with a 7" capacitive touch screen, therefore > > add support for it. > > > > Signed-off-by: Fabrizio Castro > > Acked-by: Laurent Pinchart > > I expect

Re: [PATCH v3 RESEND] drm/bridge/synopsys: dsi: driver-specific configuration of phy timings

Hi, On 25/11/2019 10:31, Heiko Stuebner wrote: > From: Heiko Stuebner > > The timing values for dw-dsi are often dependent on the used display and > according to Philippe Cornu will most likely also depend on the used phy > technology in the soc-specific implementation. > > To solve this and

Re: [Intel-gfx] [RFC 03/13] drm/i915/svm: Runtime (RT) allocator support

Quoting Niranjana Vishwanathapura (2019-11-22 20:57:24) > Shared Virtual Memory (SVM) runtime allocator support allows > binding a shared virtual address to a buffer object (BO) in the > device page table through an ioctl call. The ioctl though is not svm specific, it is to do with "bulk

Re: [PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing

On Mon, Nov 18, 2019 at 11:35:22AM +0100, Daniel Vetter wrote: > A few reasons to drop kmap: > > - For native objects all we do is look at obj->vaddr anyway, so might > as well not call functions for every page. > > - Reloc-processing on dma-buf is ... questionable. > > - Plus most dma-buf

Re: [PATCH] drm/tegra: vic: Export module device table

On Fri, Nov 22, 2019 at 02:32:15PM +0100, Thierry Reding wrote: > From: Thierry Reding > > Export the module device table to ensure the VIC compatible strings are > listed in the module's aliases table. This in turn causes the driver to > be automatically loaded on boot if VIC is the only

[Bug 108514] heavy screen flickering with Mobility Radeon X1600 and kernel version 3.15rc2 onward

https://bugs.freedesktop.org/show_bug.cgi?id=108514 Michel Dänzer changed: What|Removed |Added URL|https://statuslife.in/ | -- You are receiving this mail

[PATCH 4/4] drm/vc4: Use dma_resv locking wrappers

I'll add more fancy logic to them soon, so everyone really has to use them. Plus they already provide some nice additional debug infrastructure on top of direct ww_mutex usage for the fences tracked by dma_resv. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/vc4/vc4_gem.c | 11 +-- 1

[PATCH 0/4] consistently use dma_resv locking wrappers

Hi all, This is prep work for some dma_resv series I'm tinkering with, but I figured good to split this out since good idea to land this no matter what exactly I'll end up creating in dma_resv. With these everything in drivers/gpu nicely goes through either the dma_resv or drm_modeset_lock

[PATCH 2/4] drm/i915: Use dma_resv locking wrappers

I'll add more fancy logic to them soon, so everyone really has to use them. Plus they already provide some nice additional debug infrastructure on top of direct ww_mutex usage for the fences tracked by dma_resv. Aside: We might want to create wrappers for i915_vma locking of the ->resv like we

[PATCH 1/4] drm/etnaviv: Use dma_resv locking wrappers

I'll add more fancy logic to them soon, so everyone really has to use them. Plus they already provide some nice additional debug infrastructure on top of direct ww_mutex usage for the fences tracked by dma_resv. Signed-off-by: Daniel Vetter Cc: Lucas Stach Cc: Russell King Cc: Christian

  1   2   >