Re: [Intel-gfx] [PATCH 19/26] drm/qxl: Use drm_fb_helper_fill_info

On Thu, Jan 24, 2019 at 05:58:24PM +0100, Daniel Vetter wrote: > This should not result in any changes. I'd love to merge https://patchwork.freedesktop.org/series/53951/ instead (which will -- among other things -- switch qxl over to the generic fbdev emulation and remove the code you are patching

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [01/33] drm/i915/execlists: Move RPCS setup to context pin

== Series Details == Series: series starting with [01/33] drm/i915/execlists: Move RPCS setup to context pin URL : https://patchwork.freedesktop.org/series/55708/ State : failure == Summary == CI Bug Log - changes from CI_DRM_5478 -> Patchwork_12035 ===

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [01/33] drm/i915/execlists: Move RPCS setup to context pin

== Series Details == Series: series starting with [01/33] drm/i915/execlists: Move RPCS setup to context pin URL : https://patchwork.freedesktop.org/series/55708/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/execlists: Move RPCS setup to co

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/33] drm/i915/execlists: Move RPCS setup to context pin

== Series Details == Series: series starting with [01/33] drm/i915/execlists: Move RPCS setup to context pin URL : https://patchwork.freedesktop.org/series/55708/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6abb3bdb8c37 drm/i915/execlists: Move RPCS setup to context pin 44e0

[Intel-gfx] [PATCH 15/33] drm/i915: Move vma lookup to its own lock

Remove the struct_mutex requirement for looking up the vma for an object. v2: Highlight how the race for duplicate vma creation is resolved on reacquiring the lock with a short comment. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c | 6 +

[Intel-gfx] [PATCH 20/33] drm/i915: Enlarge vma->pin_count

Previously we only accommodated having a vma pinned by a small number of users, with the maximum being pinned for use by the display engine. As such, we used a small bitfield only large enough to allow the vma to be pinned twice (for back/front buffers) in each scanout plane. Keeping the maximum pe

[Intel-gfx] [PATCH 12/33] drm/i915: Issue engine resets onto idle engines

Always perform the requested reset, even if we believe the engine is idle. Presumably there was a reason the caller wanted the reset, and in the near future we lose the easy tracking for whether the engine is idle. Signed-off-by: Chris Wilson Reviewed-by: John Harrison --- drivers/gpu/drm/i915/

[Intel-gfx] [PATCH 26/33] drm/i915: Remove the intel_engine_notify tracepoint

The global seqno is defunct and so we have no meaningful indicator of forward progress for an engine. You need to listen to the request signaling tracepoints instead. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_irq.c | 2 -- drivers/gpu/drm/i915/i915_trace.h | 25 ---

[Intel-gfx] [PATCH 13/33] drm/i915: Stop tracking MRU activity on VMA

Our goal is to remove struct_mutex and replace it with fine grained locking. One of the thorny issues is our eviction logic for reclaiming space for an execbuffer (or GTT mmaping, among a few other examples). While eviction itself is easy to move under a per-VM mutex, performing the activity tracki

[Intel-gfx] [PATCH 10/33] drm/i915: Remove GPU reset dependence on struct_mutex

Now that the submission backends are controlled via their own spinlocks, with a wave of a magic wand we can lift the struct_mutex requirement around GPU reset. That is we allow the submission frontend (userspace) to keep on submitting while we process the GPU reset as we can suspend the backend ind

[Intel-gfx] [PATCH 03/33] drm/i915: Remove manual breadcumb counting

Now that we know we measure the size of the engine->emit_breadcrumb() correctly, we can remove the previous manual counting. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c | 4 ++-- drivers/gpu/drm/i915/intel_engine_cs.c | 7 +++ drivers/gpu/drm/i915/intel_lrc.c

[Intel-gfx] [PATCH 17/33] drm/i915: Add timeline barrier support

From: Tvrtko Ursulin Timeline barrier allows serialization between different timelines. After calling i915_timeline_set_barrier with a request, all following submissions on this timeline will be set up as depending on this request, or barrier. Once the barrier has been completed it automatically

[Intel-gfx] [PATCH 05/33] drm/i915/execlists: Suppress preempting self

In order to avoid preempting ourselves, we currently refuse to schedule the tasklet if we reschedule an inflight context. However, this glosses over a few issues such as what happens after a CS completion event and we then preempt the newly executing context with itself, or if something else causes

[Intel-gfx] [PATCH 07/33] drm/i915/selftests: Apply a subtest filter

In bringup on simulated HW even rudimentary tests are slow, and so many may fail that we want to be able to filter out the noise to focus on the specific problem. Even just the tests groups provided for igt is not specific enough, and we would like to isolate one particular subtest (and probably su

[Intel-gfx] [PATCH 23/33] drm/i915: Track the context's seqno in its own timeline HWSP

Now that we have allocated ourselves a cacheline to store a breadcrumb, we can emit a write from the GPU into the timeline's HWSP of the per-context seqno as we complete each request. This drops the mirroring of the per-engine HWSP and allows each context to operate independently. We do not need to

[Intel-gfx] [PATCH 02/33] drm/i915: Measure the required reserved size for request emission

Instead of tediously and fragilely counting up the number of dwords required to emit the breadcrumb to seal a request, fake a request and measure it automatically once during engine setup. The downside is that this requires a fair amount of mocking to create a proper breadcrumb. Still, should be l

[Intel-gfx] [PATCH 22/33] drm/i915: Share per-timeline HWSP using a slab suballocator

If we restrict ourselves to only using a cacheline for each timeline's HWSP (we could go smaller, but want to avoid needless polluting cachelines on different engines between different contexts), then we can suballocate a single 4k page into 64 different timeline HWSP. By treating each fresh alloca

[Intel-gfx] [PATCH 14/33] drm/i915: Pull VM lists under the VM mutex.

A starting point to counter the pervasive struct_mutex. For the goal of avoiding (or at least blocking under them!) global locks during user request submission, a simple but important step is being able to manage each clients GTT separately. For which, we want to replace using the struct_mutex as t

[Intel-gfx] [PATCH 09/33] drm/i915/guc: Disable global reset

The guc (and huc) currently inexcruitably depend on struct_mutex for device reinitialisation from inside the reset, and indeed taking any mutex here is verboten (as we must be able to reset from underneath any of our mutexes). That makes recovering the guc unviable without, for example, reserving c

[Intel-gfx] [PATCH 25/33] drm/i915: Identify active requests

To allow requests to forgo a common execution timeline, one question we need to be able to answer is "is this request running?". To track whether a request has started on HW, we can emit a breadcrumb at the beginning of the request and check its timeline's HWSP to see if the breadcrumb has advanced

[Intel-gfx] [PATCH 01/33] drm/i915/execlists: Move RPCS setup to context pin

From: Tvrtko Ursulin Configuring RPCS in context image just before pin is sufficient and will come extra handy in one of the following patches. v2: * Split image setup a bit differently. (Chris Wilson) v3: * Update context image after reset as well - otherwise the application of pinned def

[Intel-gfx] [PATCH 16/33] drm/i915: Always allocate an object/vma for the HWSP

Currently we only allocate an object and vma if we are using a GGTT virtual HWSP, and a plain struct page for a physical HWSP. For convenience later on with global timelines, it will be useful to always have the status page being tracked by a struct i915_vma. Make it so. Signed-off-by: Chris Wilso

[Intel-gfx] [PATCH 19/33] drm/i915: Introduce concept of per-timeline (context) HWSP

Supplement the per-engine HWSP with a per-timeline HWSP. That is a per-request pointer through which we can check a local seqno, abstracting away the presumption of a global seqno. In this first step, we point each request back into the engine's HWSP so everything continues to work with the global

[Intel-gfx] [PATCH 28/33] drm/i915: Drop fake breadcrumb irq

Missed breadcrumb detection is defunct due to the tight coupling with dma_fence signaling and the myriad ways we may signal fences from everywhere but from an interrupt, i.e. we frequently signal a fence before we even see its interrupt. This means that even if we miss an interrupt for a fence, it

[Intel-gfx] [PATCH 24/33] drm/i915: Track active timelines

Now that we pin timelines around use, we have a clearly defined lifetime and convenient points at which we can track only the active timelines. This allows us to reduce the list iteration to only consider those active timelines and not all. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin

[Intel-gfx] [PATCH 04/33] drm/i915: Compute the HWS offsets explicitly

Simplify by using sizeof(u32) to convert from the index inside the HWSP to the byte offset. This has the advantage of not only being shorter (and so not upsetting checkpatch!) but that it matches use where we are writing to byte addresses using other commands than MI_STORE_DWORD_IMM. Signed-off-by

[Intel-gfx] [PATCH 29/33] drm/i915: Implement an "idle" barrier

We have a number of tasks that we like to run when idle and parking the GPU into a powersaving mode. A few of those tasks are using the global idle point as a convenient moment when all previous execution has been required (and so we know that the GPU is not still touching random user memory). Howe

[Intel-gfx] [PATCH 06/33] drm/i915/execlists: Suppress redundant preemption

On unwinding the active request we give it a small (limited to internal priority levels) boost to prevent it from being gazumped a second time. However, this means that it can be promoted to above the request that triggered the preemption request, causing a preempt-to-idle cycle for no change. We c

[Intel-gfx] [PATCH 32/33] drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+

Having introduced per-context seqno, we know have a means to identity progress across the system without feel of rollback as befell the global_seqno. That is we can program a MI_SEMAPHORE_WAIT operation in advance of submission safe in the knowledge that our target seqno and address is stable. How

[Intel-gfx] [PATCH 11/33] drm/i915/selftests: Trim struct_mutex duration for set-wedged selftest

Trim the struct_mutex hold and exclude the call to i915_gem_set_wedged() as a reminder that it must be callable without struct_mutex held. Signed-off-by: Chris Wilson Cc: Michal Wajdeczko Cc: Mika Kuoppala Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 7 +++

[Intel-gfx] [PATCH 33/33] drm/i915: Prioritise non-busywait semaphore workloads

We don't want to busywait on the GPU if we have other work to do. If we give non-busywaiting workloads higher (initial) priority than workloads that require a busywait, we will prioritise work that is ready to run immediately. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_request.c

[Intel-gfx] [PATCH 21/33] drm/i915: Allocate a status page for each timeline

Allocate a page for use as a status page by a group of timelines, as we only need a dword of storage for each (rounded up to the cacheline for safety) we can pack multiple timelines into the same page. Each timeline will then be able to track its own HW seqno. v2: Reuse the common per-engine HWSP

[Intel-gfx] [PATCH 31/33] drm/i915/execlists: Refactor out can_merge_rq()

In the next patch, we add another user that wants to check whether requests can be merge into a single HW execution, and in the future we want to add more conditions under which requests from the same context cannot be merge. In preparation, extract out can_merge_rq(). Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 08/33] drm/i915: Make all GPU resets atomic

In preparation for the next few commits, make resetting the GPU atomic. Currently, we have prepared gen6+ for atomic resetting of individual engines, but now there is a requirement to perform the whole device level reset (just the register poking) from inside an atomic context. Signed-off-by: Chri

[Intel-gfx] [PATCH 30/33] drm/i915: Keep timeline HWSP allocated until the system is idle

In preparation for enabling HW semaphores, we need to keep in flight timeline HWSP alive until the entire system is idle, as any other timeline active on the GPU may still refer back to the already retired timeline. We both have to delay recycling available cachelines and unpinning old HWSP until t

[Intel-gfx] [PATCH 18/33] drm/i915: Move list of timelines under its own lock

Currently, the list of timelines is serialised by the struct_mutex, but to alleviate difficulties with using that mutex in future, move the list management under its own dedicated mutex. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_drv.h |

[Intel-gfx] [PATCH 27/33] drm/i915: Replace global breadcrumbs with per-context interrupt tracking

A few years ago, see commit 688e6c725816 ("drm/i915: Slaughter the thundering i915_wait_request herd"), the issue of handling multiple clients waiting in parallel was brought to our attention. The requirement was that every client should be woken immediately upon its request being signaled, without

Re: [Intel-gfx] linux-next: Fixes tag needs some work in the drm-intel-fixes tree

Hi, On Fri, 25 Jan 2019 01:21:26 + "Li, Weinan Z" wrote: > > I am not sure about the problem. The commit id "0cce2823ed37" is just > for the patch of "drm/i915/gvt: Refine error handling for > prepare_execlist_workload". Is there any other problems I missed? Its just that the subject line of

Re: [Intel-gfx] linux-next: Fixes tag needs some work in the drm-intel-fixes tree

Thank Stephen. I am not sure about the problem. The commit id "0cce2823ed37" is just for the patch of "drm/i915/gvt: Refine error handling for prepare_execlist_workload". Is there any other problems I missed? Regards. -Weinan > -Original Message- > From: Jani Nikula [mailto:jani.nik...

Re: [Intel-gfx] [RFC] drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120

On Thu, Jan 24, 2019 at 12:23:45PM +0100, Maarten Lankhorst wrote: > Op 23-01-2019 om 18:31 schreef Matt Roper: > > On Tue, Jan 22, 2019 at 01:12:07PM -0800, Manasi Navare wrote: > >> On Gen 11 platform, to enable resolutions like 5K@120 where > >> the pixel clock is greater than pipe pixel rate, w

Re: [Intel-gfx] [PATCH 4/4] drm/i915/psr: Add HBR3 support

On Tue, 2019-01-22 at 14:42 -0800, Dhinakaran Pandiyan wrote: > On Wed, 2019-01-16 at 15:43 -0800, José Roberto de Souza wrote: > > If the sink and source supports HBR3, TP4 should be used as link > > training pattern. > > For PSR2 there is no register to set and enable TP4 but according > > to > >

Re: [Intel-gfx] [PATCH 5/6] drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)

Quoting Tvrtko Ursulin (2019-01-24 11:42:02) > +static int gen8_emit_rpcs_config(struct i915_request *rq, > +struct intel_context *ce, > +struct intel_sseu sseu) > +{ > + u64 offset; > + u32 *cs; > + > + cs = intel_ri

Re: [Intel-gfx] [PATCH v2 1/6] drm/i915: Add a new "remapped" gtt_view

Quoting Ville Syrjälä (2019-01-15 13:43:41) > On Mon, Jan 14, 2019 at 09:55:10AM +, Tvrtko Ursulin wrote: > > > > On 11/01/2019 19:46, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > To overcome display engine stride limits we'll want to remap the > > > pages in the GTT. To that e

Re: [Intel-gfx] [PATCH v4 2/8] drm/i915/selftests: Add mock selftest for remapped vmas

Quoting Ville Syrjala (2019-01-24 18:58:02) > From: Ville Syrjälä > > Extend the rotated vma mock selftest to cover remapped vmas as > well. > > TODO: reindent the loops I guess? Left like this for now to > ease review Probably leave it as is for the moment. Looks like we need to split the loop

Re: [Intel-gfx] [PATCH v4 3/8] drm/i915/selftests: Add live vma selftest

Quoting Ville Syrjala (2019-01-24 19:11:57) > From: Ville Syrjälä > > Add a live selftest to excercise rotated/remapped vmas. We simply > write through the rotated/remapped vma, and confirm that the data > appears in the right page when read through the normal vma. > > Not sure what the fallout

Re: [Intel-gfx] [PATCH 1/3] treewide: Lift switch variables out of switches

On Wednesday, January 23, 2019 6:04 AM, Kees Cook wrote > > Variables declared in a switch statement before any case statements > cannot be initialized, so move all instances out of the switches. > After this, future always-initialized stack variables will work > and not throw warnings like this:

Re: [Intel-gfx] [PATCH] drm/i915: Enable fastboot by default on Skylake and newer

On Thu, Jan 24, 2019 at 02:01:14PM +0100, Maarten Lankhorst wrote: > From: Hans de Goede > > We really want to have fastboot enabled by default to avoid an ugly > modeset during boot. > > Rather then enabling it everywhere, lets start with enabling it on > Skylake and newer. > > Signed-off-by: Han

[Intel-gfx] ✗ Fi.CI.BAT: failure for Per context dynamic (sub)slice power-gating (rev18)

== Series Details == Series: Per context dynamic (sub)slice power-gating (rev18) URL : https://patchwork.freedesktop.org/series/48194/ State : failure == Summary == CALLscripts/checksyscalls.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/i915_tim

[Intel-gfx] [PATCH v4] drm/i915: Add timeline barrier support

From: Tvrtko Ursulin Timeline barrier allows serialization between different timelines. After calling i915_timeline_set_barrier with a request, all following submissions on this timeline will be set up as depending on this request, or barrier. Once the barrier has been completed it automatically

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: GTT remapping for display (rev7)

== Series Details == Series: drm/i915: GTT remapping for display (rev7) URL : https://patchwork.freedesktop.org/series/55415/ State : success == Summary == CI Bug Log - changes from CI_DRM_5475_full -> Patchwork_12033_full Summary ---

Re: [Intel-gfx] [PATCH 1/5] drm/i915/icl: use tc_port in MG_PLL macros

Em qui, 2019-01-24 às 10:52 -0800, Lucas De Marchi escreveu: > On Wed, Jan 23, 2019 at 05:15:26PM -0800, Paulo Zanoni wrote: > > Em qui, 2019-01-17 às 12:21 -0800, Lucas De Marchi escreveu: > > > Fix the TODO leftover in the code by changing the argument in MG_PLL > > > macros. The MG_PLL ids used

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: GTT remapping for display (rev7)

== Series Details == Series: drm/i915: GTT remapping for display (rev7) URL : https://patchwork.freedesktop.org/series/55415/ State : success == Summary == CI Bug Log - changes from CI_DRM_5475 -> Patchwork_12033 Summary --- **SUCCES

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: GTT remapping for display (rev7)

== Series Details == Series: drm/i915: GTT remapping for display (rev7) URL : https://patchwork.freedesktop.org/series/55415/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915: Add a new "remapped" gtt_view +drivers/gpu/drm/i915/i915_gem_gtt.c:36

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: GTT remapping for display (rev7)

== Series Details == Series: drm/i915: GTT remapping for display (rev7) URL : https://patchwork.freedesktop.org/series/55415/ State : warning == Summary == $ dim checkpatch origin/drm-tip 02b1fe191700 drm/i915: Add a new "remapped" gtt_view -:96: CHECK:LINE_SPACING: Please don't use multiple b

[Intel-gfx] [PATCH v4 7/8] hack: drm/i915: Always remap gtt

From: Ville Syrjälä v2: Rebase due to can_remap() --- drivers/gpu/drm/i915/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index c6f59bfb4744..c720891b31c9 100644 --- a/drivers/gpu/drm/i915/intel_

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: GTT remapping for display (rev6)

== Series Details == Series: drm/i915: GTT remapping for display (rev6) URL : https://patchwork.freedesktop.org/series/55415/ State : failure == Summary == Applying: drm/i915: Add a new "remapped" gtt_view Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_debugfs

[Intel-gfx] [PATCH v4 3/8] drm/i915/selftests: Add live vma selftest

From: Ville Syrjälä Add a live selftest to excercise rotated/remapped vmas. We simply write through the rotated/remapped vma, and confirm that the data appears in the right page when read through the normal vma. Not sure what the fallout of making all rotated/remapped vmas mappable/fenceable wou

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: GTT remapping for display (rev5)

== Series Details == Series: drm/i915: GTT remapping for display (rev5) URL : https://patchwork.freedesktop.org/series/55415/ State : failure == Summary == Applying: drm/i915: Add a new "remapped" gtt_view Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_debugfs

[Intel-gfx] [PATCH v4 5/8] drm/i915: Bump gen4+ fb stride limit to 256KiB

From: Ville Syrjälä With gtt remapping plugged in we can simply raise the stride limit on gen4+. Let's just pick the limit to match the render engine max stride (256KiB). No remapping CCS because the virtual address of each page actually matters due to the new hash mode (WaCompressedResourceDisp

[Intel-gfx] [PATCH v4 4/8] drm/i915: Overcome display engine stride limits via GTT remapping

From: Ville Syrjälä The display engine stride limits are getting in our way. On SKL+ we are limited to 8k pixels, which is easily exceeded with three 4k displays. To overcome this limitation we can remap the pages in the GTT to provide the display engine with a view of memory with a smaller strid

[Intel-gfx] [PATCH v4 2/8] drm/i915/selftests: Add mock selftest for remapped vmas

From: Ville Syrjälä Extend the rotated vma mock selftest to cover remapped vmas as well. TODO: reindent the loops I guess? Left like this for now to ease review v2: Include the vma type in the error message (Chris) v3: Deal with trimmed sg v4: Drop leftover debugs Cc: Chris Wilson Signed-off-

Re: [Intel-gfx] [PATCH 1/5] drm/i915/icl: use tc_port in MG_PLL macros

On Wed, Jan 23, 2019 at 05:15:26PM -0800, Paulo Zanoni wrote: Em qui, 2019-01-17 às 12:21 -0800, Lucas De Marchi escreveu: Fix the TODO leftover in the code by changing the argument in MG_PLL macros. The MG_PLL ids used to access the register values can be converted from tc_port rather than port

Re: [Intel-gfx] [PATCH] dma-buf: Enhance dma-fence tracing

Chris Wilson writes: > Quoting Koenig, Christian (2019-01-22 08:49:30) >> Am 22.01.19 um 00:20 schrieb Chris Wilson: >> > Rather than every backend and GPU driver reinventing the same wheel for >> > user level debugging of HW execution, the common dma-fence framework >> > should include the traci

Re: [Intel-gfx] [PATCH 29/34] drm/i915: Drop fake breadcrumb irq

Quoting Tvrtko Ursulin (2019-01-24 17:55:20) > > On 21/01/2019 22:21, Chris Wilson wrote: > > Missed breadcrumb detection is defunct due to the tight coupling with > > How it is defunct.. oh because there is no irq_count any more... could > you describe the transition from irq_count to irq_fired

Re: [Intel-gfx] [PATCH 09/26] drm/ast: Use drm_fb_helper_fill_info

Hi Daniel. On Thu, Jan 24, 2019 at 05:58:14PM +0100, Daniel Vetter wrote: > Should not result in any changes. > > Signed-off-by: Daniel Vetter > Cc: Dave Airlie > Cc: Junwei Zhang > Cc: Alex Deucher > Cc: "Christian König" > Cc: Daniel Vetter > Cc: Sean Paul > Cc: YueHaibing > Cc: Sam Bob

Re: [Intel-gfx] [PATCH 29/34] drm/i915: Drop fake breadcrumb irq

On 21/01/2019 22:21, Chris Wilson wrote: Missed breadcrumb detection is defunct due to the tight coupling with How it is defunct.. oh because there is no irq_count any more... could you describe the transition from irq_count to irq_fired and then to nothing briefly? dma_fence signaling an

Re: [Intel-gfx] [PATCH 06/26] drm/fb_helper: set info->par in fill_info()

Hi Daniel. On Thu, Jan 24, 2019 at 05:58:11PM +0100, Daniel Vetter wrote: > The fbdev emulation helpers pretty much assume that this is set. > Let's do it for everyone. I do not know this code at all. But I failed to follow the code from the patch description. It do not give _me_ a clue why the

Re: [Intel-gfx] [PATCH 04/26] drm/fb-helper: Add fill_info() functions

Den 24.01.2019 17.58, skrev Daniel Vetter: > The fbdev split between fix and var information is kinda > pointless for drm drivers since everything is fixed: The fbdev > emulation doesn't support changing modes at all. > > Create a new simplified helper and use it in the generic fbdev > helper co

Re: [Intel-gfx] [PATCH 02/26] drm: Switch DRIVER_ flags to an enum

Hi Daniel. > + > + /** > + * @DRIVER_HAVE_DMA: > + * > + * Driver supports DMA, the userspace DMA API will be supported. Only > + * for legacy drivers. Do not use. > + */ > + DRIVER_HAVE_DMA = BIT(4), What about grouping all the "legacy, do not use

Re: [Intel-gfx] [PATCH 05/26] drm/fb-helper: set fbi->fix.id in fill_info()

On Thu, Jan 24, 2019 at 5:58 PM Daniel Vetter wrote: > > Looking at the oldest/most popular drivers ${driver}drmfb seems to be > the standard, except i915.ko went with "inteldrmfb". I guess renaming > that for consistency won't hurt, it definitely confused me when I > started with kms 10 years ago

Re: [Intel-gfx] [PATCH 31/38] drm/i915: Allow contexts to share a single timeline across all engines

On 18/01/2019 14:01, Chris Wilson wrote: Previously, our view has been always to run the engines independently within a context. (Multiple engines happened before we had contexts and timelines, so they always operated independently and that behaviour persisted into contexts.) However, at the use

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Measure the required reserved size for request emission

== Series Details == Series: series starting with [1/3] drm/i915: Measure the required reserved size for request emission URL : https://patchwork.freedesktop.org/series/55684/ State : success == Summary == CI Bug Log - changes from CI_DRM_5475_full -> Patchwork_12028_full

[Intel-gfx] [PATCH 00/26] some cleanups, mostly around fbdev emulation

Hi all, Flushing out my "I got bored over holidays" queue. A bit of docs, a bit of simplication and a bunch of fbdev helper refactor. Review and comments very much appreciated. Cheers, Daniel Daniel Vetter (26): drm/irq: Don't check for DRIVER_HAVE_IRQ in drm_irq_(un)install drm: Switch DRIV

[Intel-gfx] [PATCH 17/26] drm/nouveau: Use drm_fb_helper_fill_info

This changes the fb name from "nouveaufb" to "nouveaudrmfb". Aside: I wonder whether the in_interrupt() check is good enough for the nouveau acceleration. Cargo-cult says drm_can_sleep() is needed, which isn't actually working if you pick a .config without PREEMPT. For the generic fbdev defio supp

[Intel-gfx] [PATCH 15/26] drm/mga200g: Use drm_fb_helper_fill_info

Should not result in any changes. Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Alex Deucher Cc: "Christian König" Cc: Junwei Zhang Cc: Daniel Vetter --- drivers/gpu/drm/mgag200/mgag200_drv.h | 2 +- drivers/gpu/drm/mgag200/mgag200_fb.c | 8 +--- 2 files changed, 2 insertions(+), 8

[Intel-gfx] [PATCH 02/26] drm: Switch DRIVER_ flags to an enum

And move the documenation we alreay have into kerneldoc, plus a bit of polish while at it. FIXME: Updates for drm_driver.driver_features are missing, need to get Sam's patches landed first. Signed-off-by: Daniel Vetter --- Documentation/gpu/drm-internals.rst | 62 - include/drm/drm

[Intel-gfx] ✗ Fi.CI.BAT: failure for some cleanups, mostly around fbdev emulation

== Series Details == Series: some cleanups, mostly around fbdev emulation URL : https://patchwork.freedesktop.org/series/55690/ State : failure == Summary == Applying: drm/irq: Don't check for DRIVER_HAVE_IRQ in drm_irq_(un)install Applying: drm: Switch DRIVER_ flags to an enum Applying: drm/i

[Intel-gfx] [PATCH 07/26] drm/amdgpu: Use drm_fb_helper_fill_info

Should not cause any changes. Signed-off-by: Daniel Vetter Cc: Alex Deucher Cc: "Christian König" Cc: Samuel Li Cc: "Michel Dänzer" Cc: Huang Rui Cc: Junwei Zhang Cc: Daniel Vetter Cc: Daniel Stone Cc: Shirish S --- drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c | 24 1

[Intel-gfx] [PATCH 14/26] drm/i915: Use drm_fb_helper_fill_info

This changes the fb name from "inteldrmfb" to "i915drmfb". Signed-off-by: Daniel Vetter Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: intel-gfx@lists.freedesktop.org --- drivers/gpu/drm/i915/intel_fbdev.c | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/dri

[Intel-gfx] [PATCH 05/26] drm/fb-helper: set fbi->fix.id in fill_info()

Looking at the oldest/most popular drivers ${driver}drmfb seems to be the standard, except i915.ko went with "inteldrmfb". I guess renaming that for consistency won't hurt, it definitely confused me when I started with kms 10 years ago. I hope this never became uapi ... worst case drivers can over

[Intel-gfx] [PATCH 16/26] drm/bochs: Use drm_fb_helper_fill_info

This will change the fb name from "msm" to "msmdrmfb". Signed-off-by: Daniel Vetter Cc: Rob Clark Cc: linux-arm-...@vger.kernel.org Cc: freedr...@lists.freedesktop.org --- drivers/gpu/drm/msm/msm_fbdev.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/ms

[Intel-gfx] [PATCH 03/26] drm/irq: Ditch DRIVER_IRQ_SHARED

This is only used by drm_irq_install(), which is an optional helper. And the right choice is to set it for all pci devices, and not for everything else. Any driver with special needs should just use request_irq() directly, and there's plenty of drivers doing that already. Signed-off-by: Daniel Ve

[Intel-gfx] [PATCH 11/26] drm/exynos: Use drm_fb_helper_fill_info

This will give the exynos fbdev a name! Signed-off-by: Daniel Vetter Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Kyungmin Park Cc: Kukjin Kim Cc: Krzysztof Kozlowski Cc: linux-arm-ker...@lists.infradead.org Cc: linux-samsung-...@vger.kernel.org --- drivers/gpu/drm/exynos/exynos_d

[Intel-gfx] [PATCH 01/26] drm/irq: Don't check for DRIVER_HAVE_IRQ in drm_irq_(un)install

If a non-legacy driver calls these it's valid to assume there is interrupt support. The flag is really only needed for legacy drivers. Also remove all the flag usage from non-legacy drivers. Signed-off-by: Daniel Vetter Cc: linux-arm-ker...@lists.infradead.org Cc: intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH 21/26] drm/rockchip: Use drm_fb_helper_fill_info

This will set an fb name for the first time! Signed-off-by: Daniel Vetter Cc: Sandy Huang Cc: "Heiko Stübner" Cc: linux-arm-ker...@lists.infradead.org Cc: linux-rockc...@lists.infradead.org --- drivers/gpu/drm/rockchip/rockchip_drm_fbdev.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(

[Intel-gfx] [PATCH 25/26] drm/fb-helper: Unexport fill_{var,info}

Not used by drivers anymore. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_fb_helper.c | 38 + include/drm/drm_fb_helper.h | 4 2 files changed, 5 insertions(+), 37 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_f

[Intel-gfx] [PATCH 26/26] drm/: Don't set FBINFO_(FLAG_)DEFAULT

It's 0. Signed-off-by: Daniel Vetter Cc: Inki Dae Cc: Joonyoung Shim Cc: Seung-Woo Kim Cc: Kyungmin Park Cc: Kukjin Kim Cc: Krzysztof Kozlowski Cc: Patrik Jakobsson Cc: Ben Skeggs Cc: Sandy Huang Cc: "Heiko Stübner" Cc: Thierry Reding Cc: Jonathan Hunter Cc: Hans de Goede Cc: Greg Kr

[Intel-gfx] [PATCH 23/26] drm/udl: Use drm_fb_helper_fill_info

This should not result in any changes. Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Sean Paul Cc: Mikulas Patocka Cc: Daniel Vetter Cc: Greg Kroah-Hartman Cc: Emil Lundmark --- drivers/gpu/drm/udl/udl_fb.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drive

[Intel-gfx] [PATCH 24/26] staging/vboxvideo: Use drm_fb_helper_fill_info

This should not result in any changes. v2: Rebase over vbox changes - vbox gained it's own line to fill fix.id. Signed-off-by: Daniel Vetter Cc: Greg Kroah-Hartman Cc: Hans de Goede Cc: Daniel Vetter Cc: Alexander Kapshuk Cc: Bartlomiej Zolnierkiewicz --- drivers/staging/vboxvideo/vbox_fb.

[Intel-gfx] [PATCH 22/26] drm/qxl: Use drm_fb_helper_fill_info

Another driver that didn't set fbinfo->fix.id before. Signed-off-by: Daniel Vetter Cc: Thierry Reding Cc: Jonathan Hunter Cc: linux-te...@vger.kernel.org --- drivers/gpu/drm/tegra/fb.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/g

[Intel-gfx] [PATCH 19/26] drm/qxl: Use drm_fb_helper_fill_info

This should not result in any changes. Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Gerd Hoffmann Cc: virtualizat...@lists.linux-foundation.org Cc: spice-de...@lists.freedesktop.org --- drivers/gpu/drm/qxl/qxl_fb.c | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a

[Intel-gfx] [PATCH 12/26] drm/gma500: Use drm_fb_helper_fill_info

This will change the fb name from "psbdrmfb" to "gma500drmfb". Signed-off-by: Daniel Vetter Cc: Patrik Jakobsson --- drivers/gpu/drm/gma500/framebuffer.c | 7 +-- drivers/gpu/drm/gma500/framebuffer.h | 2 +- 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/gma5

[Intel-gfx] [PATCH 20/26] drm/radeon: Use drm_fb_helper_fill_info

This should not result in any changes. Signed-off-by: Daniel Vetter Cc: Alex Deucher Cc: "Christian König" Cc: "David (ChunMing) Zhou" Cc: amd-...@lists.freedesktop.org --- drivers/gpu/drm/radeon/radeon_fb.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git a/driver

[Intel-gfx] [PATCH 18/26] drm/omap: Use drm_fb_helper_fill_info

This changes the fb name from "omapdrm" to "omapdrmfb". Signed-off-by: Daniel Vetter Cc: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_fbdev.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c b/drivers/gpu/drm/omapdrm/omap_fbdev.c

[Intel-gfx] [PATCH 13/26] drm/hibmc: Use drm_fb_helper_fill_info

Should not result in any changes. Signed-off-by: Daniel Vetter Cc: Alex Deucher Cc: Junwei Zhang Cc: Xinliang Liu Cc: "Christian König" Cc: Ajit Negi Cc: Souptick Joarder Cc: Daniel Vetter Cc: John Garry --- drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 2 +- drivers/gpu/drm/hisili

[Intel-gfx] [PATCH 09/26] drm/ast: Use drm_fb_helper_fill_info

Should not result in any changes. Signed-off-by: Daniel Vetter Cc: Dave Airlie Cc: Junwei Zhang Cc: Alex Deucher Cc: "Christian König" Cc: Daniel Vetter Cc: Sean Paul Cc: YueHaibing Cc: Sam Bobroff --- drivers/gpu/drm/ast/ast_drv.h | 2 +- drivers/gpu/drm/ast/ast_fb.c | 7 +-- 2 fil

[Intel-gfx] [PATCH 10/26] drm/cirrus: Use drm_fb_helper_fill_info

Should not result in any changes. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/cirrus/cirrus_drv.h | 2 +- drivers/gpu/drm/cirrus/cirrus_fbdev.c | 8 +--- 2 files changed, 2 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h b/drivers/gpu/drm/cirrus/cirrus

[Intel-gfx] [PATCH 06/26] drm/fb_helper: set info->par in fill_info()

The fbdev emulation helpers pretty much assume that this is set. Let's do it for everyone. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_fb_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index

[Intel-gfx] [PATCH 08/26] drm/armada: Use drm_fb_helper_fill_info

Only changes the name of the fb from "armada-drmfb" to armadafb. Signed-off-by: Daniel Vetter Cc: Russell King --- drivers/gpu/drm/armada/armada_fbdev.c | 6 +- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/drivers/gpu/drm/armada/armada_fbdev.c b/drivers/gpu/drm/armada/armad

[Intel-gfx] [PATCH 04/26] drm/fb-helper: Add fill_info() functions

The fbdev split between fix and var information is kinda pointless for drm drivers since everything is fixed: The fbdev emulation doesn't support changing modes at all. Create a new simplified helper and use it in the generic fbdev helper code. Follow-up patches will beef it up more and roll it ou

  1   2   >