Re: [Intel-gfx] [PATCH] drm/i915: added i2c symlink to hdmi connector

On Fri, 17 May 2019, Oleg Vasilev wrote: > Currently, the i2c adapter was available only under DP connectors. Currently ... is? > This patch adds i2c adapter symlink to hdmi connector in order to make > this behaviour consistent. Please don't refer to "this patch" in commit messages. Please use

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: We don't need display's suspend/resume operations when !HAS_DISPLAY

== Series Details == Series: drm/i915: We don't need display's suspend/resume operations when !HAS_DISPLAY URL : https://patchwork.freedesktop.org/series/60839/ State : warning == Summary == $ dim checkpatch origin/drm-tip 810402289a3a drm/i915: We don't need display's suspend/resume operatio

[Intel-gfx] [PATCH 17/33] drm/i915: Move GEM domain management to its own file

Continuing the decluttering of i915_gem.c, that of the read/write domains, perhaps the biggest of GEM's follies? Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/i915_gem_domain.c| 782 +

[Intel-gfx] [PATCH 31/33] drm/i915/execlists: Preempt-to-busy

When using a global seqno, we required a precise stop-the-workd event to handle preemption and unwind the global seqno counter. To accomplish this, we would preempt to a special out-of-band context and wait for the machine to report that it was idle. Given an idle machine, we could very precisely s

[Intel-gfx] [PATCH 07/33] drm/i915: Apply an execution_mask to the virtual_engine

Allow the user to direct which physical engines of the virtual engine they wish to execute one, as sometimes it is necessary to override the load balancing algorithm. v2: Only kick the virtual engines on context-out if required Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Reviewed-by: Tvrtko

[Intel-gfx] [PATCH 25/33] drm/i915: Move object close under its own lock

Use i915_gem_object_lock() to guard the LUT and active reference to allow us to break free of struct_mutex for handling GEM_CLOSE. Testcase: igt/gem_close_race Testcase: igt/gem_exec_parallel Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 76 ++-

[Intel-gfx] [PATCH 19/33] drm/i915: Pull scatterlist utils out of i915_gem.h

Out scatterlist utility routines can be pulled out of i915_gem.h for a bit more decluttering. v2: Push I915_GTT_PAGE_SIZE out of i915_scatterlist itself and into the caller. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/Makefile | 1 + drivers

[Intel-gfx] [PATCH 18/33] drm/i915: Move more GEM objects under gem/

Continuing the theme of separating out the GEM clutter. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Makefile | 26 +-- drivers/gpu/drm/i915/Makefile.header-test | 2 - .../gpu/drm/i915/{ => gem}/i915_gem_clflush.c | 24 ++ drivers/gpu/drm/i915/gem/i9

[Intel-gfx] [PATCH 27/33] drm/i915: Keep contexts pinned until after the next kernel context switch

We need to keep the context image pinned in memory until after the GPU has finished writing into it. Since it continues to write as we signal the final breadcrumb, we need to keep it pinned until the request after it is complete. Currently we know the order in which requests execute on each engine,

[Intel-gfx] [PATCH 11/33] drm/i915: Split GEM object type definition to its own header

For convenience in avoiding inline spaghetti, keep the type definition as a separate header. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/Makefile | 1 + drivers/gpu/drm/i915/gem/Makefile.

[Intel-gfx] [PATCH 28/33] drm/i915: Stop retiring along engine

We no longer track the execution order along the engine and so no longer need to enforce ordering of retire along the engine. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c | 128 +++- 1 file changed, 52 insertions(+), 76 deletions(-) diff --git a/dr

[Intel-gfx] [PATCH 22/33] drm/i915: Move GEM object busy checking to its own file

Continuing the decluttering of i915_gem.c by moving the object busy checking into its own file. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/Makefile| 1 + drivers/gpu/drm/i915/gem/i915_gem_busy.c | 138 +++ drivers/gpu/drm/i9

[Intel-gfx] [PATCH 23/33] drm/i915: Move GEM client throttling to its own file

Continuing the decluttering of i915_gem.c by moving the client self throttling into its own file. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/Makefile| 1 + drivers/gpu/drm/i915/gem/i915_gem_throttle.c | 73 drivers/gpu/d

[Intel-gfx] [PATCH 32/33] drm/i915/execlists: Minimalistic timeslicing

If we have multiple contexts of equal priority pending execution, activate a timer to demote the currently executing context in favour of the next in the queue when that timeslice expires. This enforces fairness between contexts (so long as they allow preemption -- forced preemption, in the future,

[Intel-gfx] [PATCH 30/33] drm/i915: Flush the execution-callbacks on retiring

In the unlikely case the request completes while we regard it as not even executing on the GPU (see the next patch!), we have to flush any pending execution callbacks at retirement and ensure that we do not add any more. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c | 93 ++

[Intel-gfx] [PATCH 29/33] drm/i915: Replace engine->timeline with a plain list

To continue the onslaught of removing the assumption of a global execution ordering, another casualty is the engine->timeline. Without an actual timeline to track, it is overkill and we can replace it with a much less grand plain list. We still need a list of requests inflight, for the simple purpo

[Intel-gfx] [PATCH 04/33] drm/i915: Re-expose SINGLE_TIMELINE flags for context creation

The SINGLE_TIMELINE flag can be used to create a context such that all engine instances within that context share a common timeline. This can be useful for mixing operations between real and virtual engines, or when using a composite context for a single client API context. Signed-off-by: Chris Wi

[Intel-gfx] [PATCH 10/33] drm/i915: Allow specification of parallel execbuf

There is a desire to split a task onto two engines and have them run at the same time, e.g. scanline interleaving to spread the workload evenly. Through the use of the out-fence from the first execbuf, we can coordinate secondary execbuf to only become ready simultaneously with the first, so that w

[Intel-gfx] [PATCH 26/33] drm/i915: Rename intel_context.active to .inflight

Rename the engine this HW context is currently active upon (that we are flying upon) to disambiguate between the mixture of different active terms (and prevent conflict in future patches). Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/gt/intel_context_types.h |

[Intel-gfx] [PATCH 16/33] drm/i915: Move mmap and friends to its own file

Continuing the decluttering of i915_gem.c, now the turn of do_mmap and the faulthandlers Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/i915_gem_mman.c | 504 drivers/gpu/drm/i915/ge

[Intel-gfx] [PATCH 05/33] drm/i915: Allow userspace to clone contexts on creation

A usecase arose out of handling context recovery in mesa, whereby they wish to recreate a context with fresh logical state but preserving all other details of the original. Currently, they create a new context and iterate over which bits they want to copy across, but it would much more convenient i

[Intel-gfx] [PATCH 13/33] drm/i915: Move object->pages API to i915_gem_object.[ch]

Currently the code for manipulating the pages on an object is still residing in i915_gem.c, move it to i915_gem_object.c Signed-off-by: Chris Wilson Cc: Joonas Lahtinen Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/Makefile | 4 +- .../gpu/drm/i915/{ => gem}/i915_gem_obj

[Intel-gfx] [PATCH 15/33] drm/i915: Move phys objects to its own file

Continuing the decluttering of i915_gem.c, this time the legacy physical object. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/Makefile | 2 + drivers/gpu/drm/i915/gem/i915_gem_object.h| 11 +- .../gpu/drm/i915/gem/i915_gem_object_types.h

[Intel-gfx] [PATCH 03/33] drm/i915: Extend I915_CONTEXT_PARAM_SSEU to support local ctx->engine[]

Allow the user to specify a local engine index (as opposed to class:index) that they can use to refer to a preset engine inside the ctx->engine[] array defined by an earlier I915_CONTEXT_PARAM_ENGINES. This will be useful for setting SSEU parameters on virtual engines that are local to the context

[Intel-gfx] [PATCH 14/33] drm/i915: Move shmem object setup to its own file

Split the plain old shmem object into its own file to start decluttering i915_gem.c v2: Lose the confusing, hysterical raisins, suffix of _gtt. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/Makefile | 3 +- drivers/gpu/drm/i915/gem/i915_gem_ob

[Intel-gfx] [PATCH 02/33] drm/i915: Allow a context to define its set of engines

Over the last few years, we have debated how to extend the user API to support an increase in the number of engines, that may be sparse and even be heterogeneous within a class (not all video decoders created equal). We settled on using (class, instance) tuples to identify a specific engine, with a

[Intel-gfx] [PATCH 08/33] drm/i915: Extend execution fence to support a callback

In the next patch, we will want to configure the slave request depending on which physical engine the master request is executed on. For this, we introduce a callback from the execute fence to convey this information. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i

[Intel-gfx] [PATCH 01/33] drm/i915: Restore control over ppgtt for context creation ABI

Having hid the partially exposed new ABI from the PR, put it back again for completion of context recovery. A significant part of context recovery is the ability to reuse as much of the old context as is feasible (to avoid expensive reconstruction). The biggest chunk kept hidden at the moment is fi

[Intel-gfx] [PATCH 06/33] drm/i915: Load balancing across a virtual engine

Having allowed the user to define a set of engines that they will want to only use, we go one step further and allow them to bind those engines into a single virtual instance. Submitting a batch to the virtual engine will then forward it to any one of the set in a manner as best to distribute load.

[Intel-gfx] [PATCH 12/33] drm/i915: Pull GEM ioctls interface to its own file

Declutter i915_drv/gem.h by moving the ioctl API into its own header. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/gem/i915_gem_ioctls.h | 52 ++ drivers/gpu/drm/i915/i915_drv.c| 1 + drivers/gpu/drm/i915/i915_drv.h|

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: We don't need display's suspend/resume operations when !HAS_DISPLAY

== Series Details == Series: drm/i915: We don't need display's suspend/resume operations when !HAS_DISPLAY URL : https://patchwork.freedesktop.org/series/60839/ State : success == Summary == CI Bug Log - changes from CI_DRM_6097 -> Patchwork_13040 =

[Intel-gfx] [PATCH 09/33] drm/i915/execlists: Virtual engine bonding

Some users require that when a master batch is executed on one particular engine, a companion batch is run simultaneously on a specific slave engine. For this purpose, we introduce virtual engine bonding, allowing maps of master:slaves to be constructed to constrain which physical engines a virtual

[Intel-gfx] [PATCH 01/33] dummycon: Sprinkle locking checks

As part of trying to understand the locking (or lack thereof) in the fbcon/vt/fbdev maze, annotate everything. Signed-off-by: Daniel Vetter Cc: Bartlomiej Zolnierkiewicz Cc: Hans de Goede Cc: Daniel Vetter Cc: Greg Kroah-Hartman Cc: Kees Cook Cc: Nicolas Pitre --- drivers/video/console/dum

[Intel-gfx] [PATCH 04/33] vt: More locking checks

I honestly have no idea what the subtle differences between con_is_visible, con_is_fg (internal to vt.c) and con_is_bound are. But it looks like both vc->vc_display_fg and con_driver_map are protected by the console_lock, so probably better if we hold that when checking this. To do that I had to d

[Intel-gfx] [PATCH 05/33] fbdev/sa1100fb: Remove dead code

Motivated because it contains a struct display, which is a fbcon internal data structure that I want to rename. It seems to have been formerly used in drivers, but that's very long time ago. Signed-off-by: Daniel Vetter Cc: Daniel Vetter --- drivers/video/fbdev/sa1100fb.c | 25 -

[Intel-gfx] [PATCH 03/33] vt: might_sleep() annotation for do_blank_screen

For symmetry reasons with do_unblank_screen, except without the oops_in_progress special case. Just a drive-by annotation while I'm trying to untangle the fbcon vs. fbdev screen blank/unblank maze. Signed-off-by: Daniel Vetter Cc: Greg Kroah-Hartman Cc: Nicolas Pitre Cc: Adam Borowski Cc: Mar

[Intel-gfx] [PATCH 00/33] fbcon notifier begone!

Hi all, This patch series removes the fbcon notifier. It also contains the beginnings of trying to understand how locking in this area works. The super short summary of locking rules is that everything in fbcon needs to be protected by the monolithic console_lock, including the setup code. So not

[Intel-gfx] [PATCH 08/33] fbcon: s/struct display/struct fbcon_display/

This was formerly used in fbdev drivers (not sure why, predates most git history), but now it's entirely an fbcon internal thing. Give it a more specific name. Signed-off-by: Daniel Vetter Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Vetter Cc: Hans de Goede Cc: Greg Kroah-Hartman Cc: Kees Cook

[Intel-gfx] [PATCH 02/33] fbdev: locking check for fb_set_suspend

Just drive-by, nothing systematic yet. Signed-off-by: Daniel Vetter Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Vetter Cc: "Michał Mirosław" Cc: Peter Rosin Cc: Hans de Goede Cc: Thomas Zimmermann Cc: Manfred Schlaegl Cc: Mikulas Patocka Cc: Kees Cook --- drivers/video/fbdev/core/fbmem.c |

[Intel-gfx] [PATCH 17/33] fbcon: call fbcon_fb_bind directly

Also remove the error return value. That's all errors for either driver bugs (trying to unbind something that isn't bound), or errors of the new driver that will take over. There's nothing the outgoing driver can do about this anyway, so switch over to void. Signed-off-by: Daniel Vetter Cc: Bart

[Intel-gfx] [PATCH 12/33] fbdev/omap: sysfs files can't disappear before the device is gone

Which means lock_fb_info can never fail. Remove the error handling. Signed-off-by: Daniel Vetter Cc: Daniel Vetter --- .../video/fbdev/omap2/omapfb/omapfb-sysfs.c | 21 +++ 1 file changed, 7 insertions(+), 14 deletions(-) diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-s

[Intel-gfx] [PATCH 13/33] fbdev: sysfs files can't disappear before the device is gone

Which means lock_fb_info can never fail. Remove the error handling. Signed-off-by: Daniel Vetter Cc: Daniel Vetter Cc: Bartlomiej Zolnierkiewicz Cc: Rob Clark --- drivers/video/fbdev/core/fbsysfs.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/video/fb

[Intel-gfx] [PATCH 18/33] fbdev: make unregister/unlink functions not fail

Except for driver bugs (which we'll catch with a WARN_ON) this is only to report failures of the new driver taking over the console. There's nothing the outgoing driver can do about that, and no one ever bothered to actually look at these return values. So remove them all. Signed-off-by: Daniel Ve

[Intel-gfx] [PATCH 11/33] fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify

It's dead code, and removing it avoids me having to understand what it's doing with lock_fb_info. Signed-off-by: Daniel Vetter Cc: Daniel Vetter --- drivers/video/fbdev/sh_mobile_lcdcfb.c | 63 -- drivers/video/fbdev/sh_mobile_lcdcfb.h | 5 -- 2 files changed, 68 deleti

[Intel-gfx] [PATCH 15/33] fbdev/atyfb: lock_fb_info can't fail

It's properly protected by reboot_lock. Signed-off-by: Daniel Vetter Cc: Mikulas Patocka Cc: "David S. Miller" Cc: "Ville Syrjälä" Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Vetter --- drivers/video/fbdev/aty/atyfb_base.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/d

[Intel-gfx] [PATCH 07/33] fbdev/aty128fb: Remove dead code

Motivated because it contains a struct display, which is a fbcon internal data structure that I want to rename. It seems to have been formerly used in drivers, but that's very long time ago. Signed-off-by: Daniel Vetter Cc: Paul Mackerras Cc: linux-fb...@vger.kernel.org --- drivers/video/fbdev/

[Intel-gfx] [PATCH 16/33] fbdev: lock_fb_info cannot fail

Ever since commit c47747fde931c02455683bd00ea43eaa62f35b0e Author: Linus Torvalds Date: Wed May 11 14:58:34 2011 -0700 fbmem: make read/write/ioctl use the frame buffer at open time fbdev has gained proper refcounting for the fbinfo attached to any open files, which means that the backing

[Intel-gfx] [PATCH 14/33] staging/olpc: lock_fb_info can't fail

Simply because olpc never unregisters the damn thing. It also registers the framebuffer directly by poking around in fbdev core internals, so it's all around rather broken. Signed-off-by: Daniel Vetter Cc: Jens Frederich Cc: Daniel Drake Cc: Jon Nettleton --- drivers/staging/olpc_dcon/olpc_dc

[Intel-gfx] [PATCH 20/33] fbdev/sh_mob: Remove fb notifier callback

This seems to be entirely defunct: - The FB_EVEN_SUSPEND/RESUME events are only sent out by fb_set_suspend. Which is supposed to be called by drivers in their suspend/resume hooks, and not itself call into drivers. Luckily sh_mob doesn't call fb_set_suspend, so this seems to do nothing use

[Intel-gfx] [PATCH 06/33] fbdev/cyber2000: Remove struct display

Entirely unused. Signed-off-by: Daniel Vetter Cc: Russell King Cc: linux-arm-ker...@lists.infradead.org --- drivers/video/fbdev/cyber2000fb.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/video/fbdev/cyber2000fb.c b/drivers/video/fbdev/cyber2000fb.c index 9a5751cb4e16..452ef07b3a0

[Intel-gfx] [PATCH 10/33] fbcon: call fbcon_fb_(un)registered directly

With commit 6104c37094e729f3d4ce65797002112735d49cd1 Author: Daniel Vetter Date: Tue Aug 1 17:32:07 2017 +0200 fbcon: Make fbcon a built-time depency for fbdev we have a static dependency between fbcon and fbdev, and we can replace the indirection through the notifier chain with a functio

[Intel-gfx] [PATCH 09/33] fbcon: Remove fbcon_has_exited

This is unused code since commit 6104c37094e729f3d4ce65797002112735d49cd1 Author: Daniel Vetter Date: Tue Aug 1 17:32:07 2017 +0200 fbcon: Make fbcon a built-time depency for fbdev when fbcon was made a compile-time static dependency of fbdev. We can't exit fbcon anymore without exiting f

[Intel-gfx] [PATCH 23/33] fbdev: Call fbcon_get_requirement directly

Pretty simple case really. v2: Forgot to remove a break; Signed-off-by: Daniel Vetter Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Vetter Cc: Hans de Goede Cc: "Steven Rostedt (VMware)" Cc: Prarit Bhargava Cc: Kees Cook Cc: Yisheng Xie Cc: "Michał Mirosław" Cc: Peter Rosin Cc: Mikulas Patoc

[Intel-gfx] [PATCH 22/33] fbcon: Call fbcon_mode_deleted/new_modelist directly

I'm not entirely clear on what new_modelist actually does, it seems exclusively for a sysfs interface. Which in the end does amount to a normal fb_set_par to check the mode, but then takes a different path in both fbmem.c and fbcon.c. I have no idea why these 2 paths are different, but then I also

[Intel-gfx] [PATCH 27/33] fbdev: remove FBINFO_MISC_USEREVENT around fb_blank

With the recursion broken in the previous patch we can drop the FBINFO_MISC_USEREVENT flag around calls to fb_blank - recursion prevention was it's only job. Signed-off-by: Daniel Vetter Cc: Daniel Vetter Cc: Bartlomiej Zolnierkiewicz Cc: Hans de Goede Cc: Yisheng Xie Cc: "Michał Mirosław" C

[Intel-gfx] [PATCH 19/33] fbdev: unify unlink_framebufer paths

For some reasons the pm_vt_switch_unregister call was missing from the direct unregister_framebuffer path. Fix this. v2: fbinfo->dev is used to decided whether unlink_framebuffer has been called already. I botched that in v1. Make this all clearer by inlining __unlink_framebuffer. Signed-off-by:

[Intel-gfx] [PATCH 24/33] Revert "backlight/fbcon: Add FB_EVENT_CONBLANK"

This reverts commit 994efacdf9a087b52f71e620b58dfa526b0cf928. The justification is that if hw blanking fails (i.e. fbops->fb_blank) fails, then we still want to shut down the backlight. Which is exactly _not_ what fb_blank() does and so rather inconsistent if we end up with different behaviour bet

[Intel-gfx] [PATCH 25/33] fbcon: directly call fbcon_fb_blanked

We cant remove FB_EVENT_BLANK because that's still used by the backlight and lcd code, but that's kinda fine: No recursion between fbdev core code and fbcon code possible for that case. Signed-off-by: Daniel Vetter Cc: Daniel Vetter Cc: Bartlomiej Zolnierkiewicz Cc: Hans de Goede Cc: Yisheng X

[Intel-gfx] [PATCH 28/33] fb: Flatten control flow in fb_set_var

Instead of wiring almost everything down to the very last line using goto soup (but not consistently, where would the fun be otherwise) drop out early when checks fail. This allows us to flatten the huge indent levels to just 1. Aside: If a driver doesn't set ->fb_check_var, then FB_ACTIVATE_NOW d

[Intel-gfx] [PATCH 29/33] fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct calls

Create a new wrapper function for this, feels like there's some refactoring room here between the two modes. Signed-off-by: Daniel Vetter Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Vetter Cc: Hans de Goede Cc: Yisheng Xie Cc: "Michał Mirosław"

Re: [Intel-gfx] [PATCH v7 3/6] drm/i915/dp: Program VSC Header and DB for Pixel Encoding/Colorimetry Format

On Fri, 2019-05-17 at 15:36 +0200, Maarten Lankhorst wrote: > Op 10-05-2019 om 03:53 schreef Gwan-gyeong Mun: > > Function intel_pixel_encoding_setup_vsc handles vsc header and data > > block > > setup for pixel encoding / colorimetry format. > > > > Setup VSC header and data block in function > >

[Intel-gfx] [PATCH 31/33] fbcon: Call con2fb_map functions directly

These are actually fbcon ioctls which just happen to be exposed through /dev/fb*. They completely ignore which fb_info they're called on, and I think the userspace tool even hardcodes to /dev/fb0. Hence just forward the entire thing to fbcon.c wholesale. Note that this patch drops the fb_lock/unl

[Intel-gfx] [PATCH 30/33] vgaswitcheroo: call fbcon_remap_all directly

While at it, clean up the interface a bit and push the console locking into fbcon.c. Signed-off-by: Daniel Vetter Cc: Lukas Wunner Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: Bartlomiej Zolnierkiewicz Cc: Hans de Goede Cc: Yisheng Xie Cc:

[Intel-gfx] [PATCH 21/33] fbdev: directly call fbcon_suspended/resumed

With the sh_mobile notifier removed we can just directly call the fbcon code here. v2: Remove now unused local variable. Signed-off-by: Daniel Vetter Cc: Bartlomiej Zolnierkiewicz Cc: Daniel Vetter Cc: Hans de Goede Cc: Greg Kroah-Hartman Cc: Prarit Bhargava Cc: Kees Cook Cc: Konstantin Kh

[Intel-gfx] [PATCH 33/33] staging/olpc_dcon: Add drm conversion to TODO

this driver is pretty horrible from a design pov, and needs a complete overhaul. Concrete thing that annoys me is that it looks at registered_fb, which is an internal thing to fbmem.c and fbcon.c. And ofc it gets the lifetime rules all wrong (it should at least use get/put_fb_info). Looking at the

[Intel-gfx] [PATCH 26/33] fbmem: pull fbcon_fb_blanked out of fb_blank

There's a callchain of: fbcon_fb_blaned -> do_(un)blank_screen -> consw->con_blank -> fbcon_blank -> fb_blank Things don't go horribly wrong because the BKL console_lock safes the day, but that's about it. And the seeming recursion is broken in 2 ways: - Starting from the fbdev ioctl we s

[Intel-gfx] [PATCH 32/33] fbcon: Document what I learned about fbcon locking

It's not pretty. Signed-off-by: Daniel Vetter Cc: Daniel Vetter Cc: Bartlomiej Zolnierkiewicz Cc: Hans de Goede Cc: Yisheng Xie --- drivers/video/fbdev/core/fbcon.c | 19 +++ 1 file changed, 19 insertions(+) diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev

[Intel-gfx] [PATCH 2/2] drm/i915/icl: Add WaDisableBankHangMode

From: Tvrtko Ursulin Disable GPU hang by default on unrecoverable ECC cache errors. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++ drivers/gpu/drm/i915/i915_reg.h | 3 +++ 2 files changed, 9 insertions(+) diff --git a/drivers/gpu/drm/i915

[Intel-gfx] [PATCH 1/2] drm/i915/selftests: Add live_context_workarounds

From: Tvrtko Ursulin Test context workarounds have been correctly applied in a newly created context. To accomplish this the existing engine_wa_list_verify helper is extended to take in a context from which reading of the workaround list will be done. Signed-off-by: Tvrtko Ursulin --- drivers

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for fbcon notifier begone!

== Series Details == Series: fbcon notifier begone! URL : https://patchwork.freedesktop.org/series/60843/ State : warning == Summary == $ dim checkpatch origin/drm-tip 055b00c0fe75 dummycon: Sprinkle locking checks -:45: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch

Re: [Intel-gfx] [PATCH 10/33] fbcon: call fbcon_fb_(un)registered directly

Hi Am 20.05.19 um 10:21 schrieb Daniel Vetter: ... > diff --git a/drivers/video/fbdev/core/fbmem.c > b/drivers/video/fbdev/core/fbmem.c > index fc3d34a8ea5b..ae2db31eeba7 100644 > --- a/drivers/video/fbdev/core/fbmem.c > +++ b/drivers/video/fbdev/core/fbmem.c > @@ -1660,7 +1660,6 @@ MODULE_PARM_D

Re: [Intel-gfx] [PATCH 10/33] fbcon: call fbcon_fb_(un)registered directly

Hi Am 20.05.19 um 10:33 schrieb Thomas Zimmermann: > Hi > > Am 20.05.19 um 10:21 schrieb Daniel Vetter: > ... >> diff --git a/drivers/video/fbdev/core/fbmem.c >> b/drivers/video/fbdev/core/fbmem.c >> index fc3d34a8ea5b..ae2db31eeba7 100644 >> --- a/drivers/video/fbdev/core/fbmem.c >> +++ b/drive

[Intel-gfx] ✗ Fi.CI.BAT: failure for fbcon notifier begone!

== Series Details == Series: fbcon notifier begone! URL : https://patchwork.freedesktop.org/series/60843/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6097 -> Patchwork_13041 Summary --- **FAILURE** Serious unkno

Re: [Intel-gfx] [PATCH 1/2] drm/i915/selftests: Add live_context_workarounds

Quoting Tvrtko Ursulin (2019-05-20 09:28:15) > From: Tvrtko Ursulin > > Test context workarounds have been correctly applied in a newly created > context. > > To accomplish this the existing engine_wa_list_verify helper is extended > to take in a context from which reading of the workaround list

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for fbcon notifier begone!

== Series Details == Series: fbcon notifier begone! URL : https://patchwork.freedesktop.org/series/60843/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: dummycon: Sprinkle locking checks Okay! Commit: fbdev: locking check for fb_set_suspend Okay! Com

Re: [Intel-gfx] [PATCH 30/33] vgaswitcheroo: call fbcon_remap_all directly

On Mon, May 20, 2019 at 10:22:13AM +0200, Daniel Vetter wrote: > --- a/drivers/video/fbdev/core/fbcon.c > +++ b/drivers/video/fbdev/core/fbcon.c > @@ -3146,16 +3146,16 @@ void fbcon_fb_unregistered(struct fb_info *info) > } > > /* called with console_lock held */ > -static void fbcon_remap_all(

Re: [Intel-gfx] [PATCH 11/33] fbdev/sh_mobile: remove sh_mobile_lcdc_display_notify

On Mon, May 20, 2019 at 10:25 AM Daniel Vetter wrote: > It's dead code, and removing it avoids me having to understand > what it's doing with lock_fb_info. > > Signed-off-by: Daniel Vetter Reviewed-by: Geert Uytterhoeven Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven

Re: [Intel-gfx] [PATCH 20/33] fbdev/sh_mob: Remove fb notifier callback

On Mon, May 20, 2019 at 10:22 AM Daniel Vetter wrote: > This seems to be entirely defunct: > > - The FB_EVEN_SUSPEND/RESUME events are only sent out by > fb_set_suspend. Which is supposed to be called by drivers in their > suspend/resume hooks, and not itself call into drivers. Luckily > sh_

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/selftests: Add live_context_workarounds

== Series Details == Series: series starting with [1/2] drm/i915/selftests: Add live_context_workarounds URL : https://patchwork.freedesktop.org/series/60846/ State : success == Summary == CI Bug Log - changes from CI_DRM_6097 -> Patchwork_13042 ===

Re: [Intel-gfx] [RFC 1/3] kbuild: add support for ensuring headers are self-contained

On Sat, 18 May 2019, Masahiro Yamada wrote: > On Fri, May 17, 2019 at 4:48 AM Jani Nikula wrote: >> >> Sometimes it's useful to be able to explicitly ensure certain headers >> remain self-contained, i.e. that they are compilable as standalone >> units, by including and/or forward declaring everyt

Re: [Intel-gfx] [PATCH 20/33] fbdev/sh_mob: Remove fb notifier callback

On Mon, May 20, 2019 at 11:06 AM Geert Uytterhoeven wrote: > > On Mon, May 20, 2019 at 10:22 AM Daniel Vetter wrote: > > This seems to be entirely defunct: > > > > - The FB_EVEN_SUSPEND/RESUME events are only sent out by > > fb_set_suspend. Which is supposed to be called by drivers in their > >

[Intel-gfx] [PATCH v8 4/6] drm/i915/dp: Add a support of YCBCR 4:2:0 to DP MSA

When YCBCR 4:2:0 outputs is used for DP, we should program YCBCR 4:2:0 to MSA and VSC SDP. As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color Encoding Format and Content Color Gamut] while sending YCBCR 420 signals we should program MSA MISC1 fields which indicate VSC SDP for t

[Intel-gfx] [PATCH v8 5/6] drm/i915/dp: Change a link bandwidth computation for DP

Data M/N calculations were assumed a bpp as RGB format. But when we are using YCbCr 4:2:0 output format on DP, we should change bpp calculations as YCbCr 4:2:0 format. The pipe_bpp value was assumed RGB format, therefore, it was multiplied with 3. But YCbCr 4:2:0 requires a multiplier value to 1.5.

[Intel-gfx] [PATCH 33/33] drm/i915/execlists: Force preemption

If the preempted context takes too long to relinquish control, e.g. it is stuck inside a shader with arbitration disabled, evict that context with an engine reset. This ensures that preemptions are reasonably responsive, providing a tighter QoS for the more important context at the cost of flagging

[Intel-gfx] [PATCH v8 6/6] drm/i915/dp: Support DP ports YUV 4:2:0 output to GEN11

Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and HDMI ports. v2: Minor style fix. Signed-off-by: Gwan-gyeong Mun Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_dp.c | 3 +++ 1 fi

[Intel-gfx] [PATCH v8 0/6] drm/i915/dp: Support for DP YCbCr4:2:0 outputs

On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP. In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0 to MSA and VSC SDP. And Link M/N values are calculated and applied based on the Full Clock forYCbCr4

[Intel-gfx] [PATCH 24/33] drm/i915: Drop the deferred active reference

An old optimisation to reduce the number of atomics per batch sadly relies on struct_mutex for coordination. In order to remove struct_mutex from serialising object/context closing, always taking and releasing an active reference on first use / last use greatly simplifies the locking. Signed-off-b

[Intel-gfx] [PATCH 20/33] drm/i915: Move GEM object domain management from struct_mutex to local

Use the per-object local lock to control the cache domain of the individual GEM objects, not struct_mutex. This is a huge leap forward for us in terms of object-level synchronisation; execbuffers are coordinated using the ww_mutex and pread/pwrite is finally fully serialised again. Signed-off-by:

[Intel-gfx] [PATCH v8 1/6] drm/i915/dp: Add a config function for YCBCR420 outputs

This patch checks a support of YCBCR420 outputs on an encoder level. If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420 output, else it continues with RGB output mode. It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using a pipe scaler as RGB to YCbCr 4:4:4.

[Intel-gfx] [PATCH v8 2/6] drm: Rename struct edp_vsc_psr to struct dp_sdp

VSC SDP Payload for PSR is one of data block type of SDP (Secondaray Data Packet). In order to generalize SDP packet structure name, it renames struct edp_vsc_psr to struct dp_sdp. And each SDP data blocks have different usages, each SDP type has different reserved data blocks and Video_Stream_Conf

[Intel-gfx] [PATCH 21/33] drm/i915: Move GEM object waiting to its own file

Continuing the decluttering of i915_gem.c by moving the object wait decomposition into its own file. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/i915_gem_object.h | 8 + drivers/gpu/drm/i915/gem/i915_g

[Intel-gfx] [PATCH v8 3/6] drm/i915/dp: Program VSC Header and DB for Pixel Encoding/Colorimetry Format

Function intel_pixel_encoding_setup_vsc handles vsc header and data block setup for pixel encoding / colorimetry format. Setup VSC header and data block in function intel_pixel_encoding_setup_vsc for pixel encoding / colorimetry format as per dp 1.4a spec, section 2.2.5.7.1, table 2-119: VSC SDP H

Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: Add WaDisableBankHangMode

Quoting Tvrtko Ursulin (2019-05-20 09:28:16) > From: Tvrtko Ursulin > > Disable GPU hang by default on unrecoverable ECC cache errors. uint32_t l3cr; anv_pack_struct(&l3cr, GENX(L3CNTLREG), .SLMEnable = has_slm, #if GEN_GEN == 11 /* WA_1406697149: Bit 9 "Error Detecti

Re: [Intel-gfx] [PATCH 2/2] drm/i915/icl: Add WaDisableBankHangMode

Quoting Chris Wilson (2019-05-20 10:22:36) > Quoting Tvrtko Ursulin (2019-05-20 09:28:16) > > From: Tvrtko Ursulin > > > > Disable GPU hang by default on unrecoverable ECC cache errors. > >uint32_t l3cr; >anv_pack_struct(&l3cr, GENX(L3CNTLREG), >.SLMEnable = has_slm,

Re: [Intel-gfx] [PATCH v2] drm/i915/huc: Don't try to check HuC status if it's not loaded

Quoting Michal Wajdeczko (2019-05-19 22:50:43) > If we never attempted to load HuC firmware, or we already wedged > or reset GuC/HuC, then there is no reason to wake up the device > to check one bit in the register that will be for sure cleared. > > v2: check if HuC was enabled; subtle change in A

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: We don't need display's suspend/resume operations when !HAS_DISPLAY

== Series Details == Series: drm/i915: We don't need display's suspend/resume operations when !HAS_DISPLAY URL : https://patchwork.freedesktop.org/series/60839/ State : success == Summary == CI Bug Log - changes from CI_DRM_6097_full -> Patchwork_13040_full ===

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Support for DP YCbCr4:2:0 outputs (rev3)

== Series Details == Series: drm/i915/dp: Support for DP YCbCr4:2:0 outputs (rev3) URL : https://patchwork.freedesktop.org/series/60404/ State : success == Summary == CI Bug Log - changes from CI_DRM_6097 -> Patchwork_13043 Summary ---

[Intel-gfx] [PATCH v2 1/2] drm/i915/selftests: Verify context workarounds

From: Tvrtko Ursulin Test context workarounds have been correctly applied in newly created contexts. To accomplish this the existing engine_wa_list_verify helper is extended to take in a context from which reading of the workaround list will be done. Context workaround verification is done from

[Intel-gfx] [PATCH v2 2/2] drm/i915/icl: Add WaDisableBankHangMode

From: Tvrtko Ursulin Disable GPU hang by default on unrecoverable ECC cache errors. v2: * Rebase. Fixes: cc38cae7c4e9 ("drm/i915/icl: Introduce initial Icelake Workarounds") Signed-off-by: Tvrtko Ursulin Acked-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 6 ++ driv

[Intel-gfx] [PATCH v2] drm/i915: add i2c symlink under hdmi connector

Currently, the i2c adapter is available only under DP connectors. Add i2c symlink under hdmi connector pointing to i2c adapter in order to make this behaviour consistent. The initial motivation was to make igt i2c subtest patch [1] work on all connectors. [1]: https://patchwork.freedesktop.org/s

  1   2   >