[Intel-gfx] [PATCH 54/62] drm/i915: Store owning file on the i915_address_space

For the global GTT (and aliasing GTT), the address space is owned by the device (it is a global resource) and so the per-file owner field is NULL. For per-process GTT (where we create an address space per context), each is owned by the opening file. We can use this ownership information to both

[Intel-gfx] [PATCH 55/62] drm/i915: i915_vma_move_to_active prep patch

This patch is broken out of the next just to remove the code motion from that patch and make it more readable. What we do here is move the i915_vma_move_to_active() to i915_gem_execbuffer.c and put the three stages (read, write, fenced) together so that future modifications to active handling are

[Intel-gfx] [PATCH 19/62] drm/i915: Rename drm_gem_object_unreference_unlocked in preparation for lockless free

Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 7 +++ drivers/gpu/drm/i915/i915_gem.c | 10 +- drivers/gpu/drm/i915/i915_gem_tiling.c | 2 +- drivers/gpu/drm/i915/i915_gem_userptr.c | 2 +-

[Intel-gfx] [PATCH 42/62] drm/i915: Simplify calling engine->sync_to

Since requests can no longer be generated as a side-effect of intel_ring_begin(), we know that the seqno will be unchanged during ring-emission. This predicatablity then means we do not have to check for the seqno wrapping around whilst emitting the semaphore for engine->sync_to(). Signed-off-by:

[Intel-gfx] [PATCH 01/62] drm/i915: Only start retire worker when idle

The retire worker is a low frequency task that makes sure we retire outstanding requests if userspace is being lax. We only need to start it once as it remains active until the GPU is idle, so do a cheap test before the more expensive queue_work(). A consequence of this is that we need correct

[Intel-gfx] [PATCH 02/62] drm/i915: Do not keep postponing the idle-work

Rather than persistently postponing the idle-work everytime somebody calls i915_gem_retire_requests() (potentially ensuring that we never reach the idle state), queue the work the first time we detect all requests are complete. Then if in 100ms, more requests have been queued, we will abort the

[Intel-gfx] [PATCH 14/62] drm/i915: Rename request reference/unreference to get/put

Now that we derive requests from struct fence, swap over to its nomenclature for references. It's shorter and more idiomatic across the kernel. s/i915_gem_request_reference/i915_gem_request_get/ s/i915_gem_request_unreference/i915_gem_request_put/ Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 15/62] drm/i915: Rename i915_gem_context_reference/unreference()

As these are wrappers around kref_get/kref_put() it is preferable to follow the naming convention and use the same verb get/put in our wrapper names for manipulating a reference to the context. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH 10/62] drm/i915: Allow userspace to request no-error-capture upon GPU hangs

igt likes to inject GPU hangs into its command streams. However, as we expect these hangs, we don't actually want them recorded in the dmesg output or stored in the i915_error_state (usually). To accomodate this allow userspace to set a flag on the context that any hang emanating from that context

[Intel-gfx] [PATCH 03/62] drm/i915: Remove redundant queue_delayed_work() from throttle ioctl

We know, by design, that whilst the GPU is active (and thus we are throttling) the retire_worker is queued. Therefore attempting to requeue it with queue_delayed_work() is a no-op and we can safely remove it. Signed-off-by: Chris Wilson ---

[Intel-gfx] The vma leak fix from yonder

Just to see if anyone is awake this series takes us to the VMA leak fix. Just the tip of the iceberg when it comes to VMA fixes... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [01/21] drm/i915/shrinker: Flush active on objects before counting

== Series Details == Series: series starting with [01/21] drm/i915/shrinker: Flush active on objects before counting URL : https://patchwork.freedesktop.org/series/8246/ State : failure == Summary == Applying: drm/i915/shrinker: Flush active on objects before counting Applying: drm/i915:

[Intel-gfx] [PATCH 21/21] drm/i915: Remove debug noise on detecting fault-injection of missed interrupts

Since the tests can and do explicitly check debugfs/i915_ring_missed_irqs for the handling of a "missed interrupt", adding it to the dmesg at INFO is just noise. When it happens for real, we still class it as an ERROR. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 16/21] drm/i915: Only query timestamp when measuring elapsed time

Avoid the two calls to ktime_get_raw_ns() (at best it reads the TSC) as we only need to compute the elapsed time for a timed wait. v2: Eliminate the unused local variable reducing the function size by 64 bytes (using the storage space on the callers stack rather than adding to our stack frame).

[Intel-gfx] [PATCH 15/21] drm/i915: Stop setting wraparound seqno on initialisation

We have testcases to ensure that seqno wraparound works fine, so we can forgo forcing everyone to encounter seqno wraparound during early uptime. seqno wraparound incurs a full GPU stall so not forcing it will eliminate one jitter from the early system. Using the testcases, we have very

[Intel-gfx] [PATCH 07/21] drm/i915: Spin after waking up for an interrupt

When waiting for an interrupt (waiting for the GPU to complete some work), we know we are the single waiter for the GPU. We also know when the GPU has nearly completed our request (or at least started processing it), so after being woken and we detect that the GPU is almost finished, allow the

[Intel-gfx] [PATCH 13/21] drm/i915: Check the CPU cached value of seqno after waking the waiter

If we have multiple waiters, we may find that many complete on the same wake up. If we first inspect the seqno from the CPU cache, we may reduce the number of heavyweight coherent seqno reads we require. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h |

[Intel-gfx] [PATCH 11/21] drm/i915: Refactor scratch object allocation for gen2 w/a buffer

The gen2 w/a buffer is stuffed into the same slot as the gen5+ scratch buffer. If we pass in the size we want to allocate for the scratch buffer, both callers can use the same routine. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c| 2 +-

[Intel-gfx] [PATCH 20/21] drm/i915: Simplify enabling user-interrupts with L3-remapping

Borrow the idea from intel_lrc.c to precompute the mask of interrupts we wish to always enable to avoid having lots of conditionals inside the interrupt enabling. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_ringbuffer.c | 35

[Intel-gfx] [PATCH 18/21] drm/i915: Embed signaling node into the GEM request

Under the assumption that enabling signaling will be a frequent operation, lets preallocate our attachments for signaling inside the request struct (and so benefiting from the slab cache). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 1 +

[Intel-gfx] [PATCH 14/21] drm/i915: Only apply one barrier after a breadcrumb interrupt is posted

If we flag the seqno as potentially stale upon receiving an interrupt, we can use that information to reduce the frequency that we apply the heavyweight coherent seqno read (i.e. if we wake up a chain of waiters). Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 12/21] drm/i915: Add a delay between interrupt and inspecting the final seqno (ilk)

On Ironlake, there is no command nor register to ensure that the write from a MI_STORE command is completed (and coherent on the CPU) before the command parser continues. This means that the ordering between the seqno write and the subsequent user interrupt is undefined (like gen6+). So to ensure

[Intel-gfx] [PATCH 09/21] drm/i915: Stop mapping the scratch page into CPU space

After the elimination of using the scratch page for Ironlake's breadcrumb, we no longer need to kmap the object. We therefore can move it into the high unmappable space and do not need to force the object to be coherent (i.e. snooped on !llc platforms). Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 02/21] drm/i915: Delay queuing hangcheck to wait-request

We can forgo queuing the hangcheck from the start of every request to until we wait upon a request. This reduces the overhead of every request, but may increase the latency of detecting a hang. Howeever, if nothing every waits upon a hang, did it ever hang? It also improves the robustness of the

[Intel-gfx] [PATCH 08/21] drm/i915: Use HWS for seqno tracking everywhere

By using the same address for storing the HWS on every platform, we can remove the platform specific vfuncs and reduce the get-seqno routine to a single read of a cached memory location. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 6 +--

[Intel-gfx] [PATCH 19/21] drm/i915: Move the get/put irq locking into the caller

With only a single callsite for intel_engine_cs->irq_get and ->irq_put, we can reduce the code size by moving the common preamble into the caller, and we can also eliminate the reference counting. For completeness, as we are no longer doing reference counting on irq, rename the get/put vfunctions

[Intel-gfx] [PATCH 17/21] drm/i915: Convert trace-irq to the breadcrumb waiter

If we convert the tracing over from direct use of ring->irq_get() and over to the breadcrumb infrastructure, we only have a single user of the ring->irq_get and so we will be able to simplify the driver routines (eliminating the redundant validation and irq refcounting). v2: Move to a signaling

[Intel-gfx] [PATCH 10/21] drm/i915: Allocate scratch page from stolen

With the last direct CPU access to the scratch page removed, we can now allocate it from our small amount of reserved system pages (stolen memory). Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_ringbuffer.c | 4 +++- 1 file changed, 3 insertions(+), 1

[Intel-gfx] [PATCH 05/21] drm/i915: Separate GPU hang waitqueue from advance

Currently __i915_wait_request uses a per-engine wait_queue_t for the dual purpose of waking after the GPU advances or for waking after an error. In the future, we may add even more wake sources and require greater separation, but for now we can conceptually simplify wakeups by separating the two

[Intel-gfx] [PATCH 06/21] drm/i915: Slaughter the thundering i915_wait_request herd

One particularly stressful scenario consists of many independent tasks all competing for GPU time and waiting upon the results (e.g. realtime transcoding of many, many streams). One bottleneck in particular is that each client waits on its own results, but every client is woken up after every

[Intel-gfx] [PATCH 03/21] drm/i915: Remove the dedicated hangcheck workqueue

The queue only ever contains at most one item and has no special flags. It is just a very simple wrapper around the system-wq - a complication with no benefits. v2: Use the system_long_wq as we may wish to capture the error state after detecting the hang - which may take a bit of time.

[Intel-gfx] [PATCH 01/21] drm/i915/shrinker: Flush active on objects before counting

As we inspect obj->active to decide how many objects we can shrink (we only shrink idle objects), it helps to flush the active lists first in order to have a more accurate count of available objects. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin

[Intel-gfx] Breadcrumbs, again

We have a major bottleneck in waiting with many clients that is impacting customer workloads. This is because we wake up every waiter after the GPU advance for them all to try and identify if they were the lucky one. The classic thundering herd, and the response is to only wake the next in the

[Intel-gfx] [PATCH 04/21] drm/i915: Make queueing the hangcheck work inline

Since the function is a small wrapper around schedule_delayed_work(), move it inline to remove the function call overhead for the principle caller. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.h |

Re: [Intel-gfx] [PATCH 25/25] drm/i915/kbl: Add WaClearSlmSpaceAtContextSwitch

What about skl, this also seems to need the WA until A0? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915/dsi: fix bxt split screen and color issue

== Series Details == Series: drm/i915/dsi: fix bxt split screen and color issue URL : https://patchwork.freedesktop.org/series/8232/ State : warning == Summary == Series 8232v1 drm/i915/dsi: fix bxt split screen and color issue

Re: [Intel-gfx] [PATCH 20/24] drm/i915/gen9: Add WaEnableChickenDCPR

Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 17/24] drm/i915/kbl: Add WaForGAMHang

Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dsi: fix bxt split screen and color issue

On Fri, Jun 03, 2016 at 05:57:05PM +0300, Jani Nikula wrote: > Fix the failure mode where the display appears split, or shifted about > 2/3 of the screen, and the color components are cycled. Turns out we > were missing the crucial BXT_DEFEATURE_DPI_FIFO_CTR bit in the > EOT_DISABLE register. > >

Re: [Intel-gfx] [PATCH v3 09/33] drm/i915: Move panel's pipe from backlight setup to init

On Fri, Jun 03, 2016 at 06:04:36PM +0300, Ville Syrjälä wrote: > On Fri, Jun 03, 2016 at 03:36:52PM +0100, Chris Wilson wrote: > > In the very near future, we will perform the backlight setup > > consistently during connector registration - moving the setup further > > away from the

[Intel-gfx] ✗ Ro.CI.BAT: warning for series starting with [v3,01/33] drm: Export drm_dev_init() for subclassing

== Series Details == Series: series starting with [v3,01/33] drm: Export drm_dev_init() for subclassing URL : https://patchwork.freedesktop.org/series/8231/ State : warning == Summary == Series 8231v1 Series without cover letter

Re: [Intel-gfx] [PATCH v3 05/33] drm: Pass the drm_dp_aux->hw_mutex to i2c for its locking

On Fri, Jun 03, 2016 at 03:36:48PM +0100, Chris Wilson wrote: > Rather than have both drm_dp_aux lock within its transfer, and i2c to > lock around the transfer, use the same lock by filling in the locking > callbacks that i2c wants to use. We require our own hw_mutex as we > bypass i2c_transfer

Re: [Intel-gfx] [PATCH v3 09/33] drm/i915: Move panel's pipe from backlight setup to init

On Fri, Jun 03, 2016 at 03:36:52PM +0100, Chris Wilson wrote: > In the very near future, we will perform the backlight setup > consistently during connector registration - moving the setup further > away from the intel_panel_init call and to where we no longer know the > associated pipe. To pass

[Intel-gfx] [PATCH i-g-t] lib/igt_kms: Fix passing invalid fd to openat(2).

Introduced by 0e11befe442. openat(2) uses a relative path. Fix by passing the correct fd. Signed-off-by: Marius Vlad CC: Chris Wilson --- lib/igt_kms.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lib/igt_kms.c

Re: [Intel-gfx] [PATCH v3 06/33] drm: Minimally initialise drm_dp_aux

On Fri, Jun 03, 2016 at 03:36:49PM +0100, Chris Wilson wrote: > When trying to split up the initialisation phase and the registration > phase, one immediate problem encountered is trying to use our own i2c > devices before registration with userspace (to read EDID during device > discovery).

[Intel-gfx] [PATCH] drm/i915/dsi: fix bxt split screen and color issue

Fix the failure mode where the display appears split, or shifted about 2/3 of the screen, and the color components are cycled. Turns out we were missing the crucial BXT_DEFEATURE_DPI_FIFO_CTR bit in the EOT_DISABLE register. Per bspec, with the bit set, the "mipi_dpf_vblank_start" signal is

[Intel-gfx] [PATCH v3 12/33] drm/i915: Move registration actions to connector->late_register

With the introduction of a connector->func for callback from drm_connector_register() we can move all the tasks that we want to do upon registration into that callback. Later, this will allow us to reorder the registration and defer it until after the device is setup and ready for userspace.

[Intel-gfx] BAT regression bug 95634, take 3

So, at the end of the last take, Ville pointed out that debugfs was being initialised before our data structures were intact and so this series acquired a flurry of patches to close that hole so we can rely on RPS initialisation. -Chris ___ Intel-gfx

[Intel-gfx] [PATCH v3 27/33] drm/i915: Mark all default contexts as uninitialised after context loss

When the GPU is reset or state lost through suspend, every default legacy context needs to reload their state - both the golden render state and the L3 mapping. Only context images explicitly saved to memory (i.e. all execlists and non-default legacy contexts) will retain their state across the

[Intel-gfx] [PATCH v3 17/33] drm/i915: Register debugfs interface last

Currently debugfs files are created before the driver is even loads. This gives the opportunity for userspace to open that interface and poke around before the backing data structures are initialised - with the possibility of oopsing or worse. Move the creation of the debugfs files to our

[Intel-gfx] [PATCH v3 24/33] drm/i915: Skip idling an idle engine

During suspend (or module unload), if we have never accessed the engine (i.e. userspace never submitted a batch to it), the engine is idle. Then we attempt to idle the engine by forcing it to the default context, which actually means we submit a render batch to setup the golden context state and

[Intel-gfx] [PATCH v3 20/33] drm/i915: Start exploiting drm_device subclassing

Baby step, update to_i915() conversion from drm_device to drm_i915_private: textdata bss dec hex filename 1108812 23207 416 1132435 114793 i915.ko (before) 1104999 23207 416 1128622 1138ae i915.ko (after) Signed-off-by: Chris Wilson Cc:

[Intel-gfx] [PATCH v3 14/33] drm/i915: Move backlight setup to connector registration

Centralise backlight setup in the connector registration callback. Signed-off-by: Chris Wilson Cc: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/intel_crt.c | 1 + drivers/gpu/drm/i915/intel_display.c

[Intel-gfx] [PATCH v3 18/33] drm/i915: Demidlayer driver loading

Take control over allocating, loading and registering the driver from the DRM midlayer by performing it manually from i915_pci_probe. This allows us to carefully control the order of when we setup the hardware vs when it becomes visible to third parties (including userspace). The current ordering

[Intel-gfx] [PATCH v3 28/33] drm/i915: No need to wait for idle on L3 remap

As the L3 remapping is applied before the next execution, there is no need to wait until all previous uses are idle, the application will not occur any sooner. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Reviewed-by: Mika

[Intel-gfx] [PATCH v3 30/33] drm/i915: Only switch to default context when evicting from GGTT

The contexts only pin space within the global GTT. Therefore forcing the switch to the perma-pinned kernel context only has an effect when trying to evict from and find room within the global GTT. We can then restrict the switch to only when operating on the default context. This is mostly a no-op

[Intel-gfx] [PATCH v3 16/33] drm/i915: Move connector registration to driver registration

Defer connector registration from during construction to the driver registration phase. This is important for ordering the action correctly, e.g. not using debugfs before it is ready. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_dma.c | 2 ++

[Intel-gfx] [PATCH v3 33/33] drm/i915: Defer enabling rc6 til after we submit the first batch/context

Some hardware requires a valid render context before it can initiate rc6 power gating of the GPU; the default state of the GPU is not sufficient and may lead to undefined behaviour. The first execution of any batch will load the "golden render state", at which point it is safe to enable rc6. As we

[Intel-gfx] [PATCH v3 25/33] drm/i915: Move legacy kernel context pinning to intel_ringbuffer.c

This is so that we have symmetry with intel_lrc.c and avoid a source of if (i915.enable_execlists) layering violation within i915_gem_context.c - that is we move the specific handling of the dev_priv->kernel_context for legacy submission into the legacy submission code. This depends upon the

[Intel-gfx] [PATCH v3 22/33] drm/i915: Split out the PCI driver interface to i915_pci.c

To reclaim a bit of space from i915_drv.c, we can move the routines that just hook us into the PCI device tree into i915_pci.c Signed-off-by: Chris Wilson Cc: Daniel Vetter Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [PATCH v3 32/33] drm/i915: Remove superfluous powersave work flushing

Instead of flushing the outstanding enabling, remember the requested frequency to apply when the powersave work runs. Signed-off-by: Chris Wilson Cc: Ville Syrjälä --- drivers/gpu/drm/i915/i915_debugfs.c | 30 ++

[Intel-gfx] [PATCH v3 31/33] drm/i915: Preserve current RPS frequency

Select idle frequency during initialisation, then reset the last known frequency when re-enabling. This allows us to preserve the user selected frequency across resets. Signed-off-by: Chris Wilson Cc: ville Syrjälä ---

[Intel-gfx] [PATCH v3 05/33] drm: Pass the drm_dp_aux->hw_mutex to i2c for its locking

Rather than have both drm_dp_aux lock within its transfer, and i2c to lock around the transfer, use the same lock by filling in the locking callbacks that i2c wants to use. We require our own hw_mutex as we bypass i2c_transfer for drm_dp_dpcd_access(). Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v3 26/33] drm/i915: Treat kernel context as initialised

The kernel context exists simply as a placeholder and should never be executed with a render context. It does not need the golden render state, as that will always be applied to a user context. By skipping the initialisation we can avoid issues in attempting to program the golden render context

[Intel-gfx] [PATCH v3 23/33] drm/i915: Move module init/exit to i915_pci.c

The module init/exit routines are a wrapper around the PCI device init/exit, so move them across. Note that in order to avoid exporting the driver struct, instead of manipulating driver.features inside i915_init we instead opt to simply exit if i915.modeset is disabled. Signed-off-by: Chris

[Intel-gfx] [PATCH v3 01/33] drm: Export drm_dev_init() for subclassing

In order to allow drivers to pack their privates and drm_device into one struct (e.g. for subclassing), export the initialisation routines for struct drm_device. v2: Missed return ret. That error path had only one job to do! v3: Cross-referencing drm_dev_init/drm_dev_alloc in kerneldoc, fix

[Intel-gfx] [PATCH v3 29/33] drm/i915: Split idling from forcing context switch

We only need to force a switch to the kernel context placeholder during eviction. All other uses of i915_gpu_idle() just want to wait until existing work on the GPU is idle. Rename i915_gpu_idle() to i915_gem_wait_for_idle() to avoid any implications about "parking" the context first. v2: Tweak

[Intel-gfx] [PATCH v3 07/33] drm/i915: Perform async fbdev initialisation much later

Setting up fbdev requires everything ready and registered (in particular the connectors). In the next patch, we defer registration of the KMS objects and unless we defer setting off fbdev, it may run before they are registered and oops. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH v3 13/33] drm/i915/dp: Free the drm_dp_aux along with the encoder

The drm_dp_ax object is stored on the encoder, and freeing it from the connector causes a use-after-free error since the encoder is destroy first: [ 112.356952] == [ 112.357065] BUG: KASAN: use-after-free in

[Intel-gfx] [PATCH v3 10/33] drm/i915: Move intel_connector->unregister to connector->early_unregister

We now have a connector->func that serves the same purpose as our own intel_connector->unregister vfunc allowing us to unwrap ourselves and use drm_connector_register() (and friends) as the central function. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH v3 19/33] drm/i915: Demidlayer driver unloading

To complete the transition to manual control of load/unload, we need to take over unloading from i915_pci_remove(). This allows us to correctly order our unregister vs shutdown phases, which currently are inverted due to the midlayer. However, the unload sequence is still invalid as we shutdown

[Intel-gfx] [PATCH v3 15/33] drm/i915: Move backlight registration to connector registration

Currently the backlight is being registered in the load phase (before the display and its objects are registered). Move the backlight registration into the analogous phase by performing it from the connector registration, just after its creation. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v3 11/33] drm/i915: Move backlight unregistration to connector unregistration

Currently the backlight is being unregistered in the unload phase (after the display and its objects are unregistered). Move the backlight unregistration into the analogous phase by performing it from the connector unregistration, just prior to its deletion. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH v3 06/33] drm: Minimally initialise drm_dp_aux

When trying to split up the initialisation phase and the registration phase, one immediate problem encountered is trying to use our own i2c devices before registration with userspace (to read EDID during device discovery). drm_dp_aux in particular only offers an interface for setting up the device

[Intel-gfx] [PATCH v3 09/33] drm/i915: Move panel's pipe from backlight setup to init

In the very near future, we will perform the backlight setup consistently during connector registration - moving the setup further away from the intel_panel_init call and to where we no longer know the associated pipe. To pass that information along we need to store it during init. Signed-off-by:

[Intel-gfx] [PATCH v3 03/33] drm: Make drm_connector_register() safe against multiple calls

Protect against drivers that may try to register the connector more than once, or who try to unregister it multiple times. Signed-off-by: Chris Wilson Cc: Dave Airlie Cc: dri-de...@lists.freedesktop.org Reviewed-by: Daniel Vetter

[Intel-gfx] [PATCH v3 04/33] drm: Automatically unregister the connector during cleanup

As we now can call drm_connector_unregister() multiple times, provide a failsafe unregister for a connector when cleaning it up. v2: Add a WARN to catch any connectors that are still visible to userspace when we come to destoy them. Signed-off-by: Chris Wilson Cc: Dave

[Intel-gfx] [PATCH v3 02/33] drm: Add a callback from connector registering

If a driver wants to more precisely control its initialisation and in particular, defer registering its interfaces with userspace until after everything is setup, it also needs to defer registering the connectors. As some devices need more work during registration, add a callback so that drivers

[Intel-gfx] [PATCH v3 08/33] drm/i915: Make panel/backlight safe to setup/cleanup multiple times

Allow everyone to call intel_panel_setup_backlight() (i.e. only take effect if we have previously been initialised for use as a panel) and, for paranoia, allow intel_panel_cleanup_backlight() to be called multiple times. Signed-off-by: Chris Wilson Cc: Jani Nikula

Re: [Intel-gfx] [PATCH 12/24] drm/i915/kbl: Add WaDisableGamClockGating

Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: Fix a buch of kerneldoc warnings (rev2)

== Series Details == Series: drm/i915: Fix a buch of kerneldoc warnings (rev2) URL : https://patchwork.freedesktop.org/series/8169/ State : warning == Summary == Series 8169v2 drm/i915: Fix a buch of kerneldoc warnings http://patchwork.freedesktop.org/api/1.0/series/8169/revisions/2/mbox

Re: [Intel-gfx] [PATCH v2] drm/i915: Fix a buch of kerneldoc warnings

On Fri, Jun 03, 2016 at 02:02:17PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Just a bunch of stale kerneldocs generating warnings when > building the docs. Mostly function parameters so not very > useful but still. > > v2: Tidy. > > Signed-off-by: Tvrtko

Re: [Intel-gfx] [PATCH] drm/i915: Fix a buch of kerneldoc warnings

On 02/06/16 21:21, Daniel Vetter wrote: On Thu, Jun 02, 2016 at 04:19:48PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Just a bunch of stale kerneldocs generating warnings when building the docs. Mostly function parameters so not very useful but still.

[Intel-gfx] [PATCH v2] drm/i915: Fix a buch of kerneldoc warnings

From: Tvrtko Ursulin Just a bunch of stale kerneldocs generating warnings when building the docs. Mostly function parameters so not very useful but still. v2: Tidy. Signed-off-by: Tvrtko Ursulin Cc: Daniel Vetter

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: Check VBT for port presence in addition to the strap on VLV/CHV

On Fri, Jun 03, 2016 at 03:28:52PM +0300, Ville Syrjälä wrote: > On Fri, Jun 03, 2016 at 10:06:54AM -, Patchwork wrote: > > == Series Details == > > > > Series: drm/i915: Check VBT for port presence in addition to the strap on > > VLV/CHV > > URL :

Re: [Intel-gfx] FW: Wrt golden MMIO/CFG snaphot in GVT-g

> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Friday, May 27, 2016 7:32 PM > > On pe, 2016-05-27 at 10:05 +, Wang, Zhi A wrote: > > For me I think maybe i915 could save the snapshot for GVT, then GVT-g > > patch the snapshot itself, then there won’t be leaking

Re: [Intel-gfx] [PATCH] drm/i915: only disable memory self-refresh on GMCH

On Thu, May 19, 2016 at 03:50:36PM +0300, David Weinehall wrote: > The atomic version of intel_pre_plane_update did not check > for HAS_GMCH_DISPLAY before calling intel_set_memory_cxsr(). > While this doesn't cause any issues on its own (it will > return without doing anything if the hardware

Re: [Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: Check VBT for port presence in addition to the strap on VLV/CHV

On Fri, Jun 03, 2016 at 10:06:54AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Check VBT for port presence in addition to the strap on > VLV/CHV > URL : https://patchwork.freedesktop.org/series/8211/ > State : warning > > == Summary == > > Series 8211v1 drm/i915:

Re: [Intel-gfx] Wrt golden MMIO/CFG snaphot in GVT-g

> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Friday, May 27, 2016 7:39 PM > > On pe, 2016-05-27 at 10:09 +, Tian, Kevin wrote: > > Curious why leaking BIOS configuration to VM is a security problem… > > Can someone elaborate this view? > > > > Hi, > > It is a

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/gen9: Add WaVFEStateAfterPipeControlwithMediaStateClear

== Series Details == Series: drm/i915/gen9: Add WaVFEStateAfterPipeControlwithMediaStateClear URL : https://patchwork.freedesktop.org/series/8218/ State : failure == Summary == scripts/Makefile.clean:86: recipe for target 'drivers/staging/lustre/lnet/lnet' failed make[4]: ***

[Intel-gfx] ✗ Ro.CI.BAT: failure for Revert "sna: Refresh last detection timestamp on hotplug notifies"

== Series Details == Series: Revert "sna: Refresh last detection timestamp on hotplug notifies" URL : https://patchwork.freedesktop.org/series/7369/ State : failure == Summary == Applying: Revert "sna: Refresh last detection timestamp on hotplug notifies" fatal: sha1 information is lacking or

[Intel-gfx] ✗ Ro.CI.BAT: failure for Framework to collect command stream gpu metrics using i915 perf (rev2)

== Series Details == Series: Framework to collect command stream gpu metrics using i915 perf (rev2) URL : https://patchwork.freedesktop.org/series/6154/ State : failure == Summary == Applying: drm/i915: Add ctx getparam ioctl parameter to retrieve ctx unique id Applying: drm/i915: Expose OA

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/gen9: Add WaVFEStateAfterPipeControlwithMediaStateClear

== Series Details == Series: drm/i915/gen9: Add WaVFEStateAfterPipeControlwithMediaStateClear URL : https://patchwork.freedesktop.org/series/8218/ State : failure == Summary == Series 8218v1 drm/i915/gen9: Add WaVFEStateAfterPipeControlwithMediaStateClear

[Intel-gfx] [PATCH] drm/i915/gen9: Add WaVFEStateAfterPipeControlwithMediaStateClear

Kernel only need to add a register to HW whitelist, required for a preemption related issue. Reference: HSD#2131039 Signed-off-by: Arun Siluvery --- drivers/gpu/drm/i915/i915_reg.h | 1 + drivers/gpu/drm/i915/intel_ringbuffer.c | 5 + 2 files changed,

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/3] igt/gem_stolen: Verify contents of stolen-backed objects across hibernation

== Series Details == Series: series starting with [1/3] igt/gem_stolen: Verify contents of stolen-backed objects across hibernation URL : https://patchwork.freedesktop.org/series/8210/ State : failure == Summary == Applying: igt/gem_stolen: Verify contents of stolen-backed objects across

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/3] igt/gem_stolen: Verify contents of stolen-backed objects across hibernation

== Series Details == Series: series starting with [1/3] igt/gem_stolen: Verify contents of stolen-backed objects across hibernation URL : https://patchwork.freedesktop.org/series/8210/ State : failure == Summary == Applying: igt/gem_stolen: Verify contents of stolen-backed objects across

Re: [Intel-gfx] [PATCH v6 8/9] drm/i915: Support LRC context single submission

> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com] > Sent: Friday, June 03, 2016 5:47 PM > > On to, 2016-06-02 at 12:36 -0400, Zhi Wang wrote: > > This patch introduces the support of LRC context signle submission. > > "single" > > > As GVT context may come from different guests,

[Intel-gfx] ✗ Ro.CI.BAT: warning for BXT Pooled EU kernel support and WA patches (rev3)

== Series Details == Series: BXT Pooled EU kernel support and WA patches (rev3) URL : https://patchwork.freedesktop.org/series/8200/ State : warning == Summary == Series 8200v3 BXT Pooled EU kernel support and WA patches http://patchwork.freedesktop.org/api/1.0/series/8200/revisions/3/mbox

Re: [Intel-gfx] [PATCH 3/3] igt/gem_stolen: Check for available stolen memory size

On 03/06/16 09:51, ankitprasad.r.sha...@intel.com wrote: From: Ankitprasad Sharma Check for available stolen memory size before attempting to run the stolen memory tests. This way we make sure that we do not create objects from stolen memory without knowing the

Re: [Intel-gfx] [PATCH 2/3] igt/gem_stolen: Fix for no_mmap subtest

On 03/06/16 09:51, ankitprasad.r.sha...@intel.com wrote: From: Ankitprasad Sharma no_mmap subtest is expected to fail, but calling gem_mmap__cpu will assert the returned value itself, which makes test fail. Replacing gem_mmap__cpu by __gem_mmap__cpu and

<    1   2   3   >