Re: [PATCH v1 07/10] drm/mediatek: add pseudo ovl support for MT8195

2021-07-19 Thread CK Hu
Hi, Nancy: On Sat, 2021-07-17 at 17:04 +0800, Nancy.Lin wrote: > Add pseudo ovl module files: > Pseudo ovl is an encapsulated module and designed for simplified > DRM control flow. This module is composed of 8 RDMAs and 4 MERGEs. > Two RDMAs merge into one layer, so this module support 4 >

[PATCH v3] Fixes: a6b7c98afdca(drm/mediatek: add mtk_dither_set_common() function)

2021-07-19 Thread Yongqiang Niu
dither 6 setting is missed in a6b7c98afdca bit 1 is lfsr_en( "Enables LFSR-type dithering"), need enable bit 2 is rdither_en(Enables running order dithering), need disable Signed-off-by: Yongqiang Niu --- drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 ++ 1 file changed, 2 insertions(+) diff

[PATCH v3] Fixes: a6b7c98afdca(drm/mediatek: add mtk_dither_set_common() function)

2021-07-19 Thread Yongqiang Niu
Change since v2: - add fixes tag and modify commit message Yongqiang Niu (1): Fixes: a6b7c98afdca(drm/mediatek: add mtk_dither_set_common() function) drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 2 ++ 1 file changed, 2 insertions(+) -- 1.8.1.1.dirty

[PATCH] drivers/gpu/drm/nouveau/dispnv50/headc57d.c: mark headc57d_olut() as static

2021-07-19 Thread zhaoxiao
Fixes the following W=1 kernel build warning(s): drivers/gpu/drm/nouveau/dispnv50/headc57d.c:173:1: warning: no previous prototype for ‘headc57d_olut’ [-Wmissing-prototypes] headc57d_olut(struct nv50_head *head, struct nv50_head_atom *asyh, int size) And no header file define a prototype for

Re: [PATCH v2] drm/mediatek: add dither 6 setting

2021-07-19 Thread Hsin-Yi Wang
On Mon, Jul 19, 2021 at 4:24 PM Yongqiang Niu wrote: > > in the first version dither patch > https://patchwork.kernel.org/project/linux-mediatek/patch/1553667561-25447-13-git-send-email-yongqiang@mediatek.com/ > dither 6 setting is included in that patch I think you don't need to link the

Re: [PATCH 06/51] drm/i915/guc: Implement GuC context operations for new inteface

2021-07-19 Thread Matthew Brost
On Mon, Jul 19, 2021 at 05:51:46PM -0700, Daniele Ceraolo Spurio wrote: > > > On 7/16/2021 1:16 PM, Matthew Brost wrote: > > Implement GuC context operations which includes GuC specific operations > > alloc, pin, unpin, and destroy. > > > > v2: > > (Daniel Vetter) > >- Use

Re: [PATCH 12/51] drm/i915/guc: Ensure request ordering via completion fences

2021-07-19 Thread Matthew Brost
On Mon, Jul 19, 2021 at 07:48:17PM -0700, Matthew Brost wrote: > On Mon, Jul 19, 2021 at 04:46:57PM -0700, Daniele Ceraolo Spurio wrote: > > > > > > On 7/16/2021 1:16 PM, Matthew Brost wrote: > > > If two requests are on the same ring, they are explicitly ordered by the > > > HW. So, a

Re: [PATCH 12/51] drm/i915/guc: Ensure request ordering via completion fences

2021-07-19 Thread Matthew Brost
On Mon, Jul 19, 2021 at 04:46:57PM -0700, Daniele Ceraolo Spurio wrote: > > > On 7/16/2021 1:16 PM, Matthew Brost wrote: > > If two requests are on the same ring, they are explicitly ordered by the > > HW. So, a submission fence is sufficient to ensure ordering when using > > the new GuC

Re: [PATCH 06/51] drm/i915/guc: Implement GuC context operations for new inteface

2021-07-19 Thread Matthew Brost
On Mon, Jul 19, 2021 at 05:23:55PM -0700, John Harrison wrote: > On 7/16/2021 13:16, Matthew Brost wrote: > > Implement GuC context operations which includes GuC specific operations > > alloc, pin, unpin, and destroy. > > > > v2: > > (Daniel Vetter) > >- Use msleep_interruptible rather than

Re: [PATCH 17/51] drm/i915/guc: Add several request trace points

2021-07-19 Thread Matthew Brost
On Mon, Jul 19, 2021 at 06:27:06PM -0700, John Harrison wrote: > On 7/16/2021 13:16, Matthew Brost wrote: > > Add trace points for request dependencies and GuC submit. Extended > > existing request trace points to include submit fence value,, guc_id, > Still has misplaced commas. > > Also, Tvrtko

Re: [Intel-gfx] [PATCH 24/47] drm/i915/guc: Add several request trace points

2021-07-19 Thread Matthew Brost
On Tue, Jul 13, 2021 at 10:06:17AM +0100, Tvrtko Ursulin wrote: > > On 24/06/2021 08:04, Matthew Brost wrote: > > Add trace points for request dependencies and GuC submit. Extended > > existing request trace points to include submit fence value,, guc_id, > > and ring tail value. > > > > Cc: John

Re: [PATCH 20/51] drm/i915: Track 'serial' counts for virtual engines

2021-07-19 Thread Matthew Brost
On Mon, Jul 19, 2021 at 06:28:47PM -0700, John Harrison wrote: > On 7/16/2021 13:16, Matthew Brost wrote: > > From: John Harrison > > > > The serial number tracking of engines happens at the backend of > > request submission and was expecting to only be given physical > > engines. However, in

Re: [PATCH 15/51] drm/i915/guc: Update intel_gt_wait_for_idle to work with GuC

2021-07-19 Thread Matthew Brost
On Mon, Jul 19, 2021 at 06:03:05PM -0700, John Harrison wrote: > On 7/16/2021 13:16, Matthew Brost wrote: > > When running the GuC the GPU can't be considered idle if the GuC still > > has contexts pinned. As such, a call has been added in > > intel_gt_wait_for_idle to idle the UC and in turn the

Re: [PATCH 20/51] drm/i915: Track 'serial' counts for virtual engines

2021-07-19 Thread John Harrison
On 7/16/2021 13:16, Matthew Brost wrote: From: John Harrison The serial number tracking of engines happens at the backend of request submission and was expecting to only be given physical engines. However, in GuC submission mode, the decomposition of virtual to physical engines does not happen

Re: [PATCH 17/51] drm/i915/guc: Add several request trace points

2021-07-19 Thread John Harrison
On 7/16/2021 13:16, Matthew Brost wrote: Add trace points for request dependencies and GuC submit. Extended existing request trace points to include submit fence value,, guc_id, Still has misplaced commas. Also, Tvrtko has a bunch of comments/questions on the previous version that need to be

Re: [PATCH] drm/lima: Convert to clk_bulk API

2021-07-19 Thread Qiang Yu
On Tue, Jul 20, 2021 at 12:03 AM Madhurkiran Harikrishnan wrote: > > Hi, > > I had created a patch sometimes ago to test on our platform. That is correct, > we have three clocks going to gp,pp0 and pp1 (Although all are at same rate). > DVFS is not supported primarily because at zynqmp clocks

Re: [PATCH 16/51] drm/i915/guc: Update GuC debugfs to support new GuC

2021-07-19 Thread John Harrison
On 7/16/2021 13:16, Matthew Brost wrote: Update GuC debugfs to support the new GuC structures. v2: (John Harrison) - Remove intel_lrc_reg.h include from i915_debugfs.c (Michal) - Rename GuC debugfs functions Signed-off-by: John Harrison Signed-off-by: Matthew Brost Reviewed-by:

Re: [PATCH 15/51] drm/i915/guc: Update intel_gt_wait_for_idle to work with GuC

2021-07-19 Thread John Harrison
On 7/16/2021 13:16, Matthew Brost wrote: When running the GuC the GPU can't be considered idle if the GuC still has contexts pinned. As such, a call has been added in intel_gt_wait_for_idle to idle the UC and in turn the GuC by waiting for the number of unpinned contexts to go to zero. v2:

Re: [PATCH 06/51] drm/i915/guc: Implement GuC context operations for new inteface

2021-07-19 Thread Daniele Ceraolo Spurio
On 7/16/2021 1:16 PM, Matthew Brost wrote: Implement GuC context operations which includes GuC specific operations alloc, pin, unpin, and destroy. v2: (Daniel Vetter) - Use msleep_interruptible rather than cond_resched in busy loop (Michal) - Remove C++ style comment

[PATCH v3 2/4] drm/amd/display: Add FPU event trace

2021-07-19 Thread Rodrigo Siqueira
We don't have any mechanism for tracing FPU operations inside the display core, making the debug work a little bit tricky. This commit introduces a trace mechanism inside our DC_FP_START/END macros for trying to alleviate this problem. Changes since V2: - Make sure that we compile FPU operation

[PATCH v3 1/4] drm/amd/display: Introduce FPU directory inside DC

2021-07-19 Thread Rodrigo Siqueira
The display core files rely on FPU, which requires to be compiled with special flags. Ideally, we don't want these FPU operations spread around the DC code; nevertheless, it happens in the current source. This commit introduces a new directory named fpu_operations that intends to centralize all

[PATCH v3 4/4] drm/amd/display: Add DC_FP helper to check FPU state

2021-07-19 Thread Rodrigo Siqueira
To fully isolate FPU operations in a single place, we must avoid situations where compilers spill FP values to registers due to FP enable in a specific C file. Note that even if we isolate all FPU functions in a single file and call its interface from other files, the compiler might enable the use

[PATCH v3 3/4] drm/amd/display: Add control mechanism for FPU utilization

2021-07-19 Thread Rodrigo Siqueira
DC invokes DC_FPU_START/END in multiple parts of the code; this can create a situation where we invoke this FPU operation in a nested way or exit too early. For avoiding this situation, this commit adds a mechanism where dc_fpu_begin/end manages the access to kernel_fpu_begin/end. Change since

[PATCH v3 0/4] Base changes for isolating FPU operation in a single place

2021-07-19 Thread Rodrigo Siqueira
Hi, In the display core, we utilize floats and doubles units for calculating modesetting parameters. One side effect of our approach to use double-precision is the fact that we spread multiple FPU access across our driver, which means that we can accidentally clobber user space FPU state. #

Re: [PATCH 13/51] drm/i915/guc: Disable semaphores when using GuC scheduling

2021-07-19 Thread John Harrison
On 7/16/2021 13:16, Matthew Brost wrote: Semaphores are an optimization and not required for basic GuC submission to work properly. Disable until we have time to do the implementation to enable semaphores and tune them for performance. Also long direction is just to delete semaphores from the

Re: [PATCH 04/51] drm/i915/guc: Implement GuC submission tasklet

2021-07-19 Thread John Harrison
On 7/19/2021 15:55, Matthew Brost wrote: On Mon, Jul 19, 2021 at 04:01:56PM -0700, John Harrison wrote: On 7/16/2021 13:16, Matthew Brost wrote: Implement GuC submission tasklet for new interface. The new GuC interface uses H2G to submit contexts to the GuC. Since H2G use a single channel, a

Re: [PATCH 06/51] drm/i915/guc: Implement GuC context operations for new inteface

2021-07-19 Thread John Harrison
On 7/16/2021 13:16, Matthew Brost wrote: Implement GuC context operations which includes GuC specific operations alloc, pin, unpin, and destroy. v2: (Daniel Vetter) - Use msleep_interruptible rather than cond_resched in busy loop (Michal) - Remove C++ style comment Signed-off-by:

Re: [PATCH 12/51] drm/i915/guc: Ensure request ordering via completion fences

2021-07-19 Thread Daniele Ceraolo Spurio
On 7/16/2021 1:16 PM, Matthew Brost wrote: If two requests are on the same ring, they are explicitly ordered by the HW. So, a submission fence is sufficient to ensure ordering when using the new GuC submission interface. Conversely, if two requests share a timeline and are on the same

Re: [PATCH 19/51] drm/i915/guc: GuC virtual engines

2021-07-19 Thread Matthew Brost
On Mon, Jul 19, 2021 at 04:42:50PM -0700, Daniele Ceraolo Spurio wrote: > > > On 7/19/2021 4:27 PM, Matthew Brost wrote: > > On Mon, Jul 19, 2021 at 04:33:56PM -0700, Daniele Ceraolo Spurio wrote: > > > > > > On 7/16/2021 1:16 PM, Matthew Brost wrote: > > > > Implement GuC virtual engines.

Re: [PATCH 19/51] drm/i915/guc: GuC virtual engines

2021-07-19 Thread Daniele Ceraolo Spurio
On 7/19/2021 4:27 PM, Matthew Brost wrote: On Mon, Jul 19, 2021 at 04:33:56PM -0700, Daniele Ceraolo Spurio wrote: On 7/16/2021 1:16 PM, Matthew Brost wrote: Implement GuC virtual engines. Rather simple implementation, basically just allocate an engine, setup context enter / exit function

Re: [PATCH 19/51] drm/i915/guc: GuC virtual engines

2021-07-19 Thread Matthew Brost
On Mon, Jul 19, 2021 at 04:33:56PM -0700, Daniele Ceraolo Spurio wrote: > > > On 7/16/2021 1:16 PM, Matthew Brost wrote: > > Implement GuC virtual engines. Rather simple implementation, basically > > just allocate an engine, setup context enter / exit function to virtual > > engine specific

Re: [PATCH 19/51] drm/i915/guc: GuC virtual engines

2021-07-19 Thread Daniele Ceraolo Spurio
On 7/16/2021 1:16 PM, Matthew Brost wrote: Implement GuC virtual engines. Rather simple implementation, basically just allocate an engine, setup context enter / exit function to virtual engine specific functions, set all other variables / functions to guc versions, and set the engine mask to

Re: [PATCH 04/51] drm/i915/guc: Implement GuC submission tasklet

2021-07-19 Thread Matthew Brost
On Mon, Jul 19, 2021 at 04:01:56PM -0700, John Harrison wrote: > On 7/16/2021 13:16, Matthew Brost wrote: > > Implement GuC submission tasklet for new interface. The new GuC > > interface uses H2G to submit contexts to the GuC. Since H2G use a single > > channel, a single tasklet submits is used

Re: [PATCH 04/51] drm/i915/guc: Implement GuC submission tasklet

2021-07-19 Thread John Harrison
On 7/16/2021 13:16, Matthew Brost wrote: Implement GuC submission tasklet for new interface. The new GuC interface uses H2G to submit contexts to the GuC. Since H2G use a single channel, a single tasklet submits is used for the submission path. This still needs fixing - 'a single tasklet submits

Re: [PATCH v4 06/13] include/linux/mm.h: helpers to check zone device generic type

2021-07-19 Thread Zeng, Oak
Regards, Oak On 2021-07-17, 3:22 PM, "amd-gfx on behalf of Alex Sierra" wrote: Two helpers added. One checks if zone device page is generic type. The other if page is either private or generic type. Signed-off-by: Alex Sierra --- include/linux/mm.h | 8

Re: [PATCH] fbmem: Convert from atomic_t to refcount_t on fb_info->count

2021-07-19 Thread Sam Ravnborg
Hi Xiyu, Xin, On Mon, Jul 19, 2021 at 01:59:45PM +0800, Xiyu Yang wrote: > refcount_t type and corresponding API can protect refcounters from > accidental underflow and overflow and further use-after-free situations. > > Signed-off-by: Xiyu Yang > Signed-off-by: Xin Tan Looks like a nice

Re: [PATCH] fbdev: simplefb: limit its use to DRM_SIMPLEDRM=n

2021-07-19 Thread Randy Dunlap
On 7/19/21 1:06 AM, Geert Uytterhoeven wrote: > Hi Randy, > > On Mon, Jul 19, 2021 at 4:34 AM Randy Dunlap wrote: >> When DRM_SIMPLEDRM=m, all of FB_CFB_{FILLRECT,COPYAREA,IMAGEBLIT} are =m, > > Why does that happen? > FB_SIMPLE does select FB_CFB_*, so all of the latter should be builtin? > Do

Re: [PATCH] dt-bindings: display: Fix graph 'unevaluatedProperties' related warnings

2021-07-19 Thread Sam Ravnborg
Hi Rob, On Mon, Jul 19, 2021 at 01:50:01PM -0600, Rob Herring wrote: > The graph schema doesn't allow custom properties on endpoint nodes for > '#/properties/port' and '#/$defs/port-base' should be used instead. This > doesn't matter until 'unevaluatedProperties' support is implemented. > > Cc:

Re: [PATCH 4/4] drm/i915/uapi: reject set_domain for discrete

2021-07-19 Thread Jason Ekstrand
On Mon, Jul 19, 2021 at 4:10 AM Matthew Auld wrote: > > On Fri, 16 Jul 2021 at 16:23, Jason Ekstrand wrote: > > > > On Fri, Jul 16, 2021 at 9:52 AM Tvrtko Ursulin > > wrote: > > > > > > > > > On 15/07/2021 11:15, Matthew Auld wrote: > > > > The CPU domain should be static for discrete, and on

[PATCH] dt-bindings: display: Fix graph 'unevaluatedProperties' related warnings

2021-07-19 Thread Rob Herring
The graph schema doesn't allow custom properties on endpoint nodes for '#/properties/port' and '#/$defs/port-base' should be used instead. This doesn't matter until 'unevaluatedProperties' support is implemented. Cc: David Airlie Cc: Daniel Vetter Cc: Rob Clark Cc: Sean Paul Cc: Marek Vasut

Re: [PATCH resend 0/5] video: fbdev: ssd1307fb: Optimizations and improvements

2021-07-19 Thread Sam Ravnborg
Hi Geert, On Wed, Jul 14, 2021 at 04:57:59PM +0200, Geert Uytterhoeven wrote: > Hi all, > > This patch series optimizes console operations on ssd1307fb, after the > customary fixes and cleanups. > > Currently, each screen update triggers an I2C transfer of all screen > data, up to 1 KiB

Re: [PATCH 4/6] drm/ttm: Force re-init if ttm_global_init() fails

2021-07-19 Thread Christian König
Am 19.07.21 um 20:30 schrieb Jason Ekstrand: If we have a failure, decrement the reference count so that the next call to ttm_global_init() will actually do something instead of assume everything is all set up. Signed-off-by: Jason Ekstrand Fixes: 62b53b37e4b1 ("drm/ttm: use a static

Re: [PATCH resend 4/5] video: fbdev: ssd1307fb: Optimize screen updates

2021-07-19 Thread Sam Ravnborg
Hi Geert, On Wed, Jul 14, 2021 at 04:58:03PM +0200, Geert Uytterhoeven wrote: > Currently, each screen update triggers an I2C transfer of all screen > data, up to 1 KiB of data for a 128x64 display, which takes at least 20 > ms in Fast mode. > > Reduce the amount of transferred data by only

Re: [PATCH resend 3/5] video: fbdev: ssd1307fb: Extract ssd1307fb_set_address_range()

2021-07-19 Thread Sam Ravnborg
Hi Geert, On Wed, Jul 14, 2021 at 04:58:02PM +0200, Geert Uytterhoeven wrote: > Extract the code to set the column and page ranges into a helper > function. > > Signed-off-by: Geert Uytterhoeven > --- > drivers/video/fbdev/ssd1307fb.c | 61 +++-- > 1 file changed,

Re: [PATCH resend 2/5] video: fbdev: ssd1307fb: Simplify ssd1307fb_update_display()

2021-07-19 Thread Sam Ravnborg
Hi Geert, On Wed, Jul 14, 2021 at 04:58:01PM +0200, Geert Uytterhoeven wrote: > Simplify the nested loops to handle conversion from linear frame buffer > to ssd1307 page layout: > 1. Move last page handling one level up, as the value of "m" is the > same inside a page, > 2. array->data[]

Re: [PATCH v5 10/15] drm/i915/pxp: interfaces for using protected objects

2021-07-19 Thread Rodrigo Vivi
On Thu, Jul 15, 2021 at 09:10:29PM -0700, Daniele Ceraolo Spurio wrote: > This api allow user mode to create protected buffers and to mark > contexts as making use of such objects. Only when using contexts > marked in such a way is the execution guaranteed to work as expected. > > Contexts can

Re: [PATCH v2] video: fbdev: kyro: fix a DoS bug by restricting user input

2021-07-19 Thread Sam Ravnborg
Hi Zheyu, On Wed, Jul 14, 2021 at 04:09:22AM +, Zheyu Ma wrote: > The user can pass in any value to the driver through the 'ioctl' > interface. The driver dost not check, which may cause DoS bugs. > > The following log reveals it: > > divide error: [#1] PREEMPT SMP KASAN PTI > RIP:

Re: [Intel-gfx] [PATCH 41/51] drm/i915/guc: Add golden context to GuC ADS

2021-07-19 Thread Matthew Brost
On Mon, Jul 19, 2021 at 11:25:55AM -0700, John Harrison wrote: > On 7/19/2021 10:24, Matthew Brost wrote: > > On Fri, Jul 16, 2021 at 01:17:14PM -0700, Matthew Brost wrote: > > > From: John Harrison > > > > > > The media watchdog mechanism involves GuC doing a silent reset and > > > continue of

[PATCH 5/6] drm/ttm: Initialize debugfs from ttm_global_init()

2021-07-19 Thread Jason Ekstrand
We create a bunch of debugfs entries as a side-effect of ttm_global_init() and then never clean them up. This isn't usually a problem because we free the whole debugfs directory on module unload. However, if the global reference count ever goes to zero and then ttm_global_init() is called again,

[PATCH 6/6] drm/i915: Make the kmem slab for i915_buddy_block a global

2021-07-19 Thread Jason Ekstrand
There's no reason that I can tell why this should be per-i915_buddy_mm and doing so causes KMEM_CACHE to throw dmesg warnings because it tries to create a debugfs entry with the name i915_buddy_block multiple times. We could handle this by carefully giving each slab its own name but that brings

[PATCH 4/6] drm/ttm: Force re-init if ttm_global_init() fails

2021-07-19 Thread Jason Ekstrand
If we have a failure, decrement the reference count so that the next call to ttm_global_init() will actually do something instead of assume everything is all set up. Signed-off-by: Jason Ekstrand Fixes: 62b53b37e4b1 ("drm/ttm: use a static ttm_bo_global instance") Cc: Christian König ---

[PATCH 3/6] drm/i915: Always call i915_globals_exit() from i915_exit()

2021-07-19 Thread Jason Ekstrand
If the driver was not fully loaded, we may still have globals lying around. If we don't tear those down in i915_exit(), we'll leak a bunch of memory slabs. This can happen two ways: use_kms = false and if we've run mock selftests. In either case, we have an early exit from i915_init which

[PATCH 1/6] drm/i915: Call i915_globals_exit() after i915_pmu_exit()

2021-07-19 Thread Jason Ekstrand
We should tear down in the opposite order we set up. Signed-off-by: Jason Ekstrand Reviewed-by: Daniel Vetter Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_pci.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_pci.c

[PATCH 2/6] drm/i915: Call i915_globals_exit() if pci_register_device() fails

2021-07-19 Thread Jason Ekstrand
In the unlikely event that pci_register_device() fails, we were tearing down our PMU setup but not globals. This leaves a bunch of memory slabs lying around. Signed-off-by: Jason Ekstrand Fixes: 32eb6bcfdda9 ("drm/i915: Make request allocation caches global") Cc: Daniel Vetter ---

[PATCH 0/6] Fix the debugfs splat from mock selftests

2021-07-19 Thread Jason Ekstrand
This patch series fixes a miscellaneous collection of bugs that all add up to all our mock selftests throwing dmesg warnings in CI. As can be seen from "drm/i915: Always call i915_globals_exit() from i915_exit()", it's especially fun since those warnings don't always show up in the selftests but

Re: [Intel-gfx] [PATCH 41/51] drm/i915/guc: Add golden context to GuC ADS

2021-07-19 Thread John Harrison
On 7/19/2021 10:24, Matthew Brost wrote: On Fri, Jul 16, 2021 at 01:17:14PM -0700, Matthew Brost wrote: From: John Harrison The media watchdog mechanism involves GuC doing a silent reset and continue of the hung context. This requires the i915 driver provide a golden context to GuC in the

Re: [PATCH 5.12 237/242] drm/ast: Remove reference to struct drm_device.pdev

2021-07-19 Thread Xiaotian Feng
On Fri, Jul 16, 2021 at 5:13 AM Greg Kroah-Hartman wrote: > > From: Thomas Zimmermann > > commit 0ecb51824e838372e01330752503ddf9c0430ef7 upstream. > > Using struct drm_device.pdev is deprecated. Upcast with to_pci_dev() > from struct drm_device.dev to get the PCI device structure. > > v9: >

[PATCH] Fix cursor plane didn't update

2021-07-19 Thread jason-jh . lin
The cursor plane should use the current plane state in atomic_async_update because it would not be the new plane state in the global atomic state since _swap_state happened when those hook are run. Fix cursor plane issue by below modification: 1. Remove plane_helper_funcs->atomic_update(plane,

[PATCH v2 0/1] Fix cursor plane didn't update

2021-07-19 Thread jason-jh . lin
Change in v2: Fix typo in patch message. jason-jh.lin (1): Fix cursor plane didn't update drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 1 - drivers/gpu/drm/mediatek/mtk_drm_plane.c | 60 ++-- 2 files changed, 34 insertions(+), 27 deletions(-) -- 2.18.0

[PATCH v2 1/1] Fix cursor plane didn't update

2021-07-19 Thread jason-jh . lin
The cursor plane should use the current plane state in atomic_async_update because it would not be the new plane state in the global atomic state since _swap_state happened when those hook are run. Fix cursor plane issue by below modification: 1. Remove plane_helper_funcs->atomic_update(plane,

RE: [PATCH] drm/lima: Convert to clk_bulk API

2021-07-19 Thread Jianqiang Chen
Add Mads. Thanks, Jason > -Original Message- > From: Michal Simek > Sent: Monday, July 19, 2021 12:53 AM > To: Qiang Yu ; Marek Vasut ; > Jianqiang Chen > Cc: dri-devel ; l...@lists.freedesktop.org; > Michal Simek ; Michal Simek > Subject: Re: [PATCH] drm/lima: Convert to clk_bulk API

Re: [PATCH 5.12 237/242] drm/ast: Remove reference to struct drm_device.pdev

2021-07-19 Thread Xiaotian Feng
On Mon, Jul 19, 2021 at 7:23 PM Greg Kroah-Hartman wrote: > > On Mon, Jul 19, 2021 at 05:57:30PM +0800, Xiaotian Feng wrote: > > On Fri, Jul 16, 2021 at 5:13 AM Greg Kroah-Hartman > > wrote: > > > > > > From: Thomas Zimmermann > > > > > > commit 0ecb51824e838372e01330752503ddf9c0430ef7

Re: [PATCH] drm/lima: Convert to clk_bulk API

2021-07-19 Thread Madhurkiran Harikrishnan
Hi, I had created a patch sometimes ago to test on our platform. That is correct, we have three clocks going to gp,pp0 and pp1 (Although all are at same rate). DVFS is not supported primarily because at zynqmp clocks are shared, for example it could come from VPLL or IOPLL. All zynqmp

Re: [Intel-gfx] [PATCH 41/51] drm/i915/guc: Add golden context to GuC ADS

2021-07-19 Thread Matthew Brost
On Fri, Jul 16, 2021 at 01:17:14PM -0700, Matthew Brost wrote: > From: John Harrison > > The media watchdog mechanism involves GuC doing a silent reset and > continue of the hung context. This requires the i915 driver provide a > golden context to GuC in the ADS. > > Signed-off-by: John

[PATCH 5.12 029/292] drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms()

2021-07-19 Thread Greg Kroah-Hartman
From: José Roberto de Souza commit 24ff3dc18b99c4b912ab1746e803ddb3be5ced4c upstream. Commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by ports in stale topology") added to calls to drm_dbg_kms() but it missed the first parameter, the drm device breaking the build. Fixes:

[PATCH 5.12 027/292] drm/dp_mst: Do not set proposed vcpi directly

2021-07-19 Thread Greg Kroah-Hartman
From: Wayne Lin commit 35d3e8cb35e75450f87f87e3d314e2d418b6954b upstream. [Why] When we receive CSN message to notify one port is disconnected, we will implicitly set its corresponding num_slots to 0. Later on, we will eventually call drm_dp_update_payload_part1() to arrange down streams. In

[PATCH 5.13 036/351] drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms()

2021-07-19 Thread Greg Kroah-Hartman
From: José Roberto de Souza commit 24ff3dc18b99c4b912ab1746e803ddb3be5ced4c upstream. Commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by ports in stale topology") added to calls to drm_dbg_kms() but it missed the first parameter, the drm device breaking the build. Fixes:

[PATCH 5.13 034/351] drm/dp_mst: Do not set proposed vcpi directly

2021-07-19 Thread Greg Kroah-Hartman
From: Wayne Lin commit 35d3e8cb35e75450f87f87e3d314e2d418b6954b upstream. [Why] When we receive CSN message to notify one port is disconnected, we will implicitly set its corresponding num_slots to 0. Later on, we will eventually call drm_dp_update_payload_part1() to arrange down streams. In

[PATCH 5.10 020/243] Revert "drm/ast: Remove reference to struct drm_device.pdev"

2021-07-19 Thread Greg Kroah-Hartman
From: Greg Kroah-Hartman This reverts commit fcb041ca5c7787b096aafc899e45f93583e66cbd which is commit 0ecb51824e838372e01330752503ddf9c0430ef7 upstream. Turns out this was incomplete, as it is missing a dependancy, so drop it from the tree. Link:

[PATCH 5.10 017/243] drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms()

2021-07-19 Thread Greg Kroah-Hartman
From: José Roberto de Souza commit 24ff3dc18b99c4b912ab1746e803ddb3be5ced4c upstream. Commit 3769e4c0af5b ("drm/dp_mst: Avoid to mess up payload table by ports in stale topology") added to calls to drm_dbg_kms() but it missed the first parameter, the drm device breaking the build. Fixes:

[PATCH 5.10 015/243] drm/dp_mst: Do not set proposed vcpi directly

2021-07-19 Thread Greg Kroah-Hartman
From: Wayne Lin commit 35d3e8cb35e75450f87f87e3d314e2d418b6954b upstream. [Why] When we receive CSN message to notify one port is disconnected, we will implicitly set its corresponding num_slots to 0. Later on, we will eventually call drm_dp_update_payload_part1() to arrange down streams. In

[Bug 213779] Screen stays blank on resume. from hibernate

2021-07-19 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=213779 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC|

Re: [PATCH 12/13] vfio/gvt: Fix open/close when multiple device FDs are open

2021-07-19 Thread Cornelia Huck
On Wed, Jul 14 2021, Jason Gunthorpe wrote: > The user can open multiple device FDs if it likes, however the open > function calls vfio_register_notifier() on device global state. Calling > vfio_register_notifier() twice will trigger a WARN_ON from > notifier_chain_register() and the first close

Re: [PATCH 10/13] vfio/mbochs: Fix close when multiple device FDs are open

2021-07-19 Thread Cornelia Huck
On Wed, Jul 14 2021, Jason Gunthorpe wrote: > mbochs_close() iterates over global device state and frees it. Currently > this is done every time a device FD is closed, but if multiple device FDs > are open this could corrupt other still active FDs. > > Change this to use close_device() so it

Re: [Linaro-mm-sig] [PATCH 00/11] drm/msm: drm scheduler conversion and cleanups

2021-07-19 Thread Christian König
Am 19.07.21 um 16:21 schrieb Rob Clark: On Mon, Jul 19, 2021 at 1:40 AM Christian König wrote: Am 17.07.21 um 22:29 schrieb Rob Clark: From: Rob Clark Conversion to gpu_scheduler, and bonus removal of drm_gem_object_put_locked() Oh yes please! If I'm not completely mistaken that was the

Re: [PATCH 11/13] vfio/ap,ccw: Fix open/close when multiple device FDs are open

2021-07-19 Thread Cornelia Huck
On Wed, Jul 14 2021, Jason Gunthorpe wrote: > The user can open multiple device FDs if it likes, however these open() > functions call vfio_register_notifier() on some device global > state. Calling vfio_register_notifier() twice in will trigger a WARN_ON > from notifier_chain_register() and the

Re: [PATCH 5.12 237/242] drm/ast: Remove reference to struct drm_device.pdev

2021-07-19 Thread Thomas Zimmermann
hi Am 19.07.21 um 13:23 schrieb Greg Kroah-Hartman: On Mon, Jul 19, 2021 at 05:57:30PM +0800, Xiaotian Feng wrote: On Fri, Jul 16, 2021 at 5:13 AM Greg Kroah-Hartman wrote: From: Thomas Zimmermann commit 0ecb51824e838372e01330752503ddf9c0430ef7 upstream. Using struct drm_device.pdev is

Re: [Linaro-mm-sig] [PATCH 00/11] drm/msm: drm scheduler conversion and cleanups

2021-07-19 Thread Rob Clark
On Mon, Jul 19, 2021 at 1:40 AM Christian König wrote: > > Am 17.07.21 um 22:29 schrieb Rob Clark: > > From: Rob Clark > > > > Conversion to gpu_scheduler, and bonus removal of > > drm_gem_object_put_locked() > > Oh yes please! > > If I'm not completely mistaken that was the last puzzle piece

Re: [PATCH] drm/stm: dsi: compute the transition time from LP to HS and back

2021-07-19 Thread Philippe CORNU
On 7/13/21 6:47 PM, Philippe CORNU wrote: Hi Antonio, On 7/13/21 4:49 PM, Antonio Borneo wrote: The driver uses a conservative set of hardcoded values for the maximum time delay of the transitions between LP and HS, either for data and clock lanes. By using the info in STM32MP157

Re: [PATCH] drm/stm: ltdc: Silence -EPROBE_DEFER till bridge attached

2021-07-19 Thread Philippe CORNU
On 7/13/21 6:43 PM, Philippe CORNU wrote: Hi Jagan, On 7/4/21 3:59 PM, Jagan Teki wrote: As dw-mipi-dsi supported all possible ways to find the DSI devices. It can take multiple iterations for ltdc to find all components attached to the DSI bridge. The current ltdc driver failed to find

Re: [PATCH 5/7] drm/i915/gem/ttm: Respect the objection region in placement_from_obj

2021-07-19 Thread Matthew Auld
On Fri, 16 Jul 2021 at 20:49, Jason Ekstrand wrote: > > On Fri, Jul 16, 2021 at 1:45 PM Matthew Auld > wrote: > > > > On Fri, 16 Jul 2021 at 18:39, Jason Ekstrand wrote: > > > > > > On Fri, Jul 16, 2021 at 11:00 AM Matthew Auld > > > wrote: > > > > > > > > On Fri, 16 Jul 2021 at 16:52, Matthew

[Bug 213201] [KAVERI] memory leak - unreferenced object 0xffff8881700cf988 (size 56)

2021-07-19 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=213201 --- Comment #10 from Erhard F. (erhar...@mailbox.org) --- Created attachment 297925 --> https://bugzilla.kernel.org/attachment.cgi?id=297925=edit kernel .config (5.14-rc2, AMD A10-8750) -- You may reply to this email to add a comment. You

[Bug 213201] [KAVERI] memory leak - unreferenced object 0xffff8881700cf988 (size 56)

2021-07-19 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=213201 --- Comment #9 from Erhard F. (erhar...@mailbox.org) --- Created attachment 297923 --> https://bugzilla.kernel.org/attachment.cgi?id=297923=edit kernel dmesg (5.14-rc2, AMD A10-8750) -- You may reply to this email to add a comment. You are

[Bug 213201] [KAVERI] memory leak - unreferenced object 0xffff8881700cf988 (size 56)

2021-07-19 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=213201 --- Comment #8 from Erhard F. (erhar...@mailbox.org) --- Created attachment 297921 --> https://bugzilla.kernel.org/attachment.cgi?id=297921=edit output of /sys/kernel/debug/kmemleak (kernel 5.14-rc2) Looking slightly different on kernel

Re: [PATCH v2 1/3] drm/loongson: Add DRM Driver for Loongson 7A1000 bridge chip

2021-07-19 Thread Dan Carpenter
On Thu, Jul 15, 2021 at 09:58:07AM +0800, lichenyang wrote: > +int loongson_crtc_init(struct loongson_device *ldev, int index) > +{ > + struct loongson_crtc *lcrtc; > + u32 ret; This should be "int ret;" > + > + lcrtc = kzalloc(sizeof(struct loongson_crtc), GFP_KERNEL); > + if

Patch "drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms()" has been added to the 5.13-stable tree

2021-07-19 Thread gregkh
This is a note to let you know that I've just added the patch titled drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms() to the 5.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The

Patch "drm/dp_mst: Do not set proposed vcpi directly" has been added to the 5.13-stable tree

2021-07-19 Thread gregkh
This is a note to let you know that I've just added the patch titled drm/dp_mst: Do not set proposed vcpi directly to the 5.13-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

Patch "drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms()" has been added to the 5.12-stable tree

2021-07-19 Thread gregkh
This is a note to let you know that I've just added the patch titled drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms() to the 5.12-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The

Patch "drm/dp_mst: Do not set proposed vcpi directly" has been added to the 5.12-stable tree

2021-07-19 Thread gregkh
This is a note to let you know that I've just added the patch titled drm/dp_mst: Do not set proposed vcpi directly to the 5.12-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

Patch "Revert "drm/ast: Remove reference to struct drm_device.pdev"" has been added to the 5.10-stable tree

2021-07-19 Thread gregkh
This is a note to let you know that I've just added the patch titled Revert "drm/ast: Remove reference to struct drm_device.pdev" to the 5.10-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch

Patch "drm/dp_mst: Do not set proposed vcpi directly" has been added to the 5.10-stable tree

2021-07-19 Thread gregkh
This is a note to let you know that I've just added the patch titled drm/dp_mst: Do not set proposed vcpi directly to the 5.10-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The filename of the patch is:

Patch "drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms()" has been added to the 5.10-stable tree

2021-07-19 Thread gregkh
This is a note to let you know that I've just added the patch titled drm/dp_mst: Add missing drm parameters to recently added call to drm_dbg_kms() to the 5.10-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary The

Re: [PATCH 5.12 237/242] drm/ast: Remove reference to struct drm_device.pdev

2021-07-19 Thread Greg Kroah-Hartman
On Mon, Jul 19, 2021 at 07:43:39PM +0800, Xiaotian Feng wrote: > On Mon, Jul 19, 2021 at 7:23 PM Greg Kroah-Hartman > wrote: > > > > On Mon, Jul 19, 2021 at 05:57:30PM +0800, Xiaotian Feng wrote: > > > On Fri, Jul 16, 2021 at 5:13 AM Greg Kroah-Hartman > > > wrote: > > > > > > > > From: Thomas

Re: [PATCH 03/13] vfio: Provide better generic support for open/release vfio_device_ops

2021-07-19 Thread Jason Gunthorpe
On Mon, Jul 19, 2021 at 10:01:31AM -0300, Jason Gunthorpe wrote: > On Mon, Jul 19, 2021 at 02:58:58PM +0200, Cornelia Huck wrote: > > > - ret = device->ops->open(device); > > > - if (ret) { > > > - module_put(device->dev->driver->owner); > > > - vfio_device_put(device); > > > -

Re: [PATCH 04/13] vfio/samples: Delete useless open/close

2021-07-19 Thread Cornelia Huck
On Wed, Jul 14 2021, Jason Gunthorpe wrote: > The core code no longer requires these ops to be defined, so delete these > empty functions and leave the op as NULL. mtty's functions only log a > pointless message, delete that entirely. > > Signed-off-by: Yishai Hadas > Signed-off-by: Jason

Re: [PATCH 03/13] vfio: Provide better generic support for open/release vfio_device_ops

2021-07-19 Thread Jason Gunthorpe
On Mon, Jul 19, 2021 at 02:58:58PM +0200, Cornelia Huck wrote: > > - ret = device->ops->open(device); > > - if (ret) { > > - module_put(device->dev->driver->owner); > > - vfio_device_put(device); > > - return ret; > > + mutex_lock(>dev_set->lock); > > +

Re: [PATCH 03/13] vfio: Provide better generic support for open/release vfio_device_ops

2021-07-19 Thread Cornelia Huck
On Wed, Jul 14 2021, Jason Gunthorpe wrote: > Currently the driver ops have an open/release pair that is called once > each time a device FD is opened or closed. Add an additional set of > open/close_device() ops which are called when the device FD is opened for > the first time and closed for

Re: [PATCH 02/13] vfio: Introduce a vfio_uninit_group_dev() API call

2021-07-19 Thread Cornelia Huck
On Mon, Jul 19 2021, Jason Gunthorpe wrote: > On Mon, Jul 19, 2021 at 02:11:38PM +0200, Cornelia Huck wrote: >> On Wed, Jul 14 2021, Jason Gunthorpe wrote: >> >> > From: Max Gurtovoy >> > >> > This pairs with vfio_init_group_dev() and allows undoing any state that is >> > stored in the

Re: [PATCH 02/13] vfio: Introduce a vfio_uninit_group_dev() API call

2021-07-19 Thread Jason Gunthorpe
On Mon, Jul 19, 2021 at 02:11:38PM +0200, Cornelia Huck wrote: > On Wed, Jul 14 2021, Jason Gunthorpe wrote: > > > From: Max Gurtovoy > > > > This pairs with vfio_init_group_dev() and allows undoing any state that is > > stored in the vfio_device unrelated to registration. Add appropriately > >

Re: [PATCH 02/13] vfio: Introduce a vfio_uninit_group_dev() API call

2021-07-19 Thread Cornelia Huck
On Wed, Jul 14 2021, Jason Gunthorpe wrote: > From: Max Gurtovoy > > This pairs with vfio_init_group_dev() and allows undoing any state that is > stored in the vfio_device unrelated to registration. Add appropriately > placed calls to all the drivers. > > The following patch will use this to

  1   2   >