Re: [Intel-gfx] [PATCH v2] drm/i915: Declare the swizzling unknown for L-shaped configurations
On Mon, Jun 29, 2015 at 02:01:19PM +0100, Chris Wilson wrote:
> The old style of memory interleaving swizzled upto the end of the
> first even bank of memory, and then used the remainder as unswizzled on
> the unpaired bank - i.e. swizzling is not constant for all memory. This
> causes problems when we try to migrate memory and so the kernel prevents
> migration at all when we detect L-shaped inconsistent swizzling.
> However, this issue also extends to userspace who try to manually detile
> into memory as the swizzling for an individual page is unknown (it
> depends on its physical address only known to the kernel), userspace
> cannot correctly swizzle objects.
>
> v2: Mark the global swizzling as unknown rather than adjust the value
> reported to userspace.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91105
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: sta...@vger.kernel.org
Applied to -fixes, thanks.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_gem_tiling.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
> b/drivers/gpu/drm/i915/i915_gem_tiling.c
> index d16585f788ea..a0d98f0abc71 100644
> --- a/drivers/gpu/drm/i915/i915_gem_tiling.c
> +++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
> @@ -183,8 +183,18 @@ i915_gem_detect_bit_6_swizzle(struct drm_device *dev)
> if (IS_GEN4(dev)) {
> uint32_t ddc2 = I915_READ(DCC2);
>
> - if (!(ddc2 & DCC2_MODIFIED_ENHANCED_DISABLE))
> + if (!(ddc2 & DCC2_MODIFIED_ENHANCED_DISABLE)) {
> + /* Since the swizzling may vary within an
> + * object, we have no idea what the swizzling
> + * is for any page in particular. Thus we
> + * cannot migrate tiled pages using the GPU,
> + * nor can we tell userspace what the exact
> + * swizzling is for any object.
> + */
> dev_priv->quirks |= QUIRK_PIN_SWIZZLED_PAGES;
> + swizzle_x = I915_BIT_6_SWIZZLE_UNKNOWN;
> + swizzle_y = I915_BIT_6_SWIZZLE_UNKNOWN;
> + }
> }
>
> if (dcc == 0x) {
> --
> 2.1.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] uxa: fix the call to PixmapSyncDirtyHelper, broken by xserver's 90db5ed
Signed-off-by: Martin Peres --- src/compat-api.h | 4 1 file changed, 4 insertions(+) diff --git a/src/compat-api.h b/src/compat-api.h index aa93bee..1ca4380 100644 --- a/src/compat-api.h +++ b/src/compat-api.h @@ -247,3 +247,7 @@ static inline void FreePixmap(PixmapPtr pixmap) #endif #endif + +#if XORG_VERSION_CURRENT >= XORG_VERSION_NUMERIC(1,17,99,0,0) +#define PixmapSyncDirtyHelper(d, dd) PixmapSyncDirtyHelper(d) +#endif -- 2.4.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] sna: allow the usage of buffer age without enable async swaps
Signed-off-by: Martin Peres
---
src/sna/sna_dri2.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/sna/sna_dri2.c b/src/sna/sna_dri2.c
index 47bc046..1f34ebe 100644
--- a/src/sna/sna_dri2.c
+++ b/src/sna/sna_dri2.c
@@ -3605,11 +3605,14 @@ bool sna_dri2_open(struct sna *sna, ScreenPtr screen)
}
#endif
+#if DRI2INFOREC_VERSION >= 10
+DBG(("%s: enabled buffer age\n", __FUNCTION__));
+info.version = 10;
+info.bufferAge = 1;
#if USE_ASYNC_SWAP
- DBG(("%s: enabled async swap and buffer age\n", __FUNCTION__));
- info.version = 10;
- info.scheduleSwap0 = 1;
- info.bufferAge = 1;
+DBG(("%s: enabled async swap\n", __FUNCTION__));
+info.scheduleSwap0 = 1;
+#endif
#endif
return DRI2ScreenInit(screen, &info);
--
2.4.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] uxa: fix the call to PixmapSyncDirtyHelper, broken by xserver's 90db5ed
On Thu, Jul 09, 2015 at 11:26:38AM +0300, Martin Peres wrote: > Signed-off-by: Martin Peres I would prefer this to be testing for the unstable release that introduces the ABI change (i.e. > rather than >=), but it fixes the build from git today and you said you would follow through later if we can be more precise. Thanks, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] NULL pointer dereference in trace_i915_context_free
Hi, I'm hitting a NULL pointer dereference when I enable the i915_context_free tracepoint (call trace attached). This is caused by the fact that the trace tries to access ctx->file_priv, which however may have already been deleted (even if the pointer is != NULL). I've used that trace extensively back when I've submitted it a few months ago without ecountering this issue, but it doesn't seem that there ever was a guarantee that the file_priv would be valid at ctx free time, so I'll put the blame on my original commit that introduced the trace: commit 198c974d7e80a5135fc4a2e69a07ba3e64122f8a Author: Daniele Ceraolo Spurio Date: Mon Nov 10 13:44:31 2014 + drm/i915: Add tracepoints to track a vm during its lifetime The trace doesn't specifically need the file_priv pointer, it just uses it to reach the drm_device pointer to get the device index. To fix the issue I've looked for another way to get the drm_device pointer from the ctx, but I couldn't find any that is valid for every GEN. Modifying the trace to add an extra parameter is out of the question for 2 reasons: - The only variable available in i915_gem_context_free is the ctx ptr - Modifying a tracepoint could break ABI Ideas, anyone? Thanks, Daniele [ 53.691790] BUG: unable to handle kernel paging request at c9000124d000 [ 53.698507] [drm:i915_gem_open] [ 53.703445] IP: [] ftrace_raw_event_i915_context+0x53/0x80 [i915] [ 53.712229] PGD 24688f067 PUD 2468a0067 PMD a9581067 PTE 0 [ 53.718547] Oops: [#1] SMP [ 53.722264] Modules linked in: binfmt_misc(E) cfg80211(E) nls_iso8859_1(E) snd_hda_codec_hdmi(E) asix(E) usbnet(E) mii(E) intel_rapl(E) snd_hda_intel(E) hid_generic(E) iosf_mbi(E) snd_hda_ codec(E) x86_pkg_temp_thermal(E) snd_hda_core(E) intel_powerclamp(E) snd_hwdep(E) coretemp(E) snd_pcm(E) kvm_intel(E) snd_seq_midi(E) kvm(E) snd_seq_midi_event(E) crct10dif_pclmul(E) snd_rawm idi(E) crc32_pclmul(E) ghash_clmulni_intel(E) snd_seq(E) aesni_intel(E) snd_seq_device(E) snd_timer(E) aes_x86_64(E) i915(E) lrw(E) gf128mul(E) glue_helper(E) ablk_helper(E) cryptd(E) drm_kms _helper(E) drm(E) serio_raw(E) i2c_algo_bit(E) snd(E) mei_me(E) mei(E) lpc_ich(E) soundcore(E) winbond_cir(E) rc_core(E) i2c_hid(E) dw_dmac(E) dw_dmac_core(E) video(E) 8250_dw(E) i2c_designwa re_platform(E) i2c_designware_core(E) spi_pxa2xx_platform(E) acpi_pad(E) mac_hid(E) usbhid(E) hid(E) parport_pc(E) ppdev(E) lp(E) parport(E) autofs4(E) sdhci_acpi(E) ahci(E) libahci(E) sdhci( E) [ 53.818335] CPU: 3 PID: 1487 Comm: compiz Tainted: G U E 4.1.0+ #3 [ 53.826477] Hardware name: Intel Corporation Broadwell Client platform/WhiteTip Mountain 1, BIOS BDW-E1R1.86C.0080.R01.1406120446 06/12/2014 [ 53.840824] task: 8800a998e440 ti: 880242214000 task.ti: 880242214000 [ 53.849337] RIP: 0010:[] [] ftrace_raw_event_i915_context+0x53/0x80 [i915] [ 53.860853] RSP: 0018:880242217b98 EFLAGS: 00010282 [ 53.866893] RAX: 88024573601c RBX: RCX: 0008 [ 53.875009] RDX: c9000124d000 RSI: RDI: 880242217b98 [ 53.883124] RBP: 880242217be8 R08: 880245736010 R09: 002c [ 53.891240] R10: 000c80477c9c R11: 0008 R12: 880243f89058 [ 53.899355] R13: 8802438bfa00 R14: 880242217c48 R15: 880243d31ef0 [ 53.907471] FS: 7f22043ea780() GS:88024f4c() knlGS: [ 53.916673] CS: 0010 DS: ES: CR0: 80050033 [ 53.924550] CR2: c9000124d000 CR3: 0002429e7000 CR4: 003407e0 [ 53.934011] DR0: DR1: DR2: [ 53.943445] DR3: DR6: fffe0ff0 DR7: 0400 [ 53.952870] Stack: [ 53.956465] 880246806100 880245736010 880243f89058 88024573601c [ 53.966240] 0296 8802 8802438bfa00 880234586e20 [ 53.976516] 8802438bfa00 880243d31ef0 880242217c08 a023ab3d [ 53.986286] Call Trace: [ 53.990392] [] i915_gem_context_free+0xbd/0x100 [i915] [ 53.999447] [] i915_gem_request_free+0xd0/0xe0 [i915] [ 54.008396] [] intel_execlists_retire_requests+0x188/0x1d0 [i915] [ 54.018537] [] i915_gem_retire_requests+0xfc/0x110 [i915] [ 54.027882] [] i915_gem_userptr_init__mmu_notifier+0xae/0x2e0 [i915] [ 54.038297] [] i915_gem_userptr_ioctl+0x252/0x320 [i915] [ 54.047512] [] ? unlock_page+0x69/0x70 [ 54.054966] [] drm_ioctl+0x349/0x670 [drm] [ 54.062799] [] ? __i915_gem_userptr_get_pages_worker+0x2e0/0x2e0 [i915] [ 54.073482] [] ? acct_account_cputime+0x1c/0x20 [ 54.081785] [] do_vfs_ioctl+0x2f8/0x510 [ 54.089280] [] ? rcu_eqs_enter+0x68/0x90 [ 54.096851] [] ? context_tracking_user_exit+0x13/0x20 [ 54.105714] [] SyS_ioctl+0x81/0xa0 [ 54.112692] [] ? context_tracking_user_enter+0x13/0x20 [ 54.121652] [] ? syscall_trace_leave+0xa5/0x120
Re: [Intel-gfx] NULL pointer dereference in trace_i915_context_free
On Thu, Jul 09, 2015 at 10:08:08AM +0100, Ceraolo Spurio, Daniele wrote: > Hi, > > I'm hitting a NULL pointer dereference when I enable the > i915_context_free tracepoint (call trace attached). This is caused > by the fact that the trace tries to access ctx->file_priv, which > however may have already been deleted (even if the pointer is != > NULL). I've used that trace extensively back when I've submitted it > a few months ago without ecountering this issue, but it doesn't seem > that there ever was a guarantee that the file_priv would be valid at > ctx free time, so I'll put the blame on my original commit that > introduced the trace: > > commit 198c974d7e80a5135fc4a2e69a07ba3e64122f8a > Author: Daniele Ceraolo Spurio > Date: Mon Nov 10 13:44:31 2014 + > > drm/i915: Add tracepoints to track a vm during its lifetime > > The trace doesn't specifically need the file_priv pointer, it just > uses it to reach the drm_device pointer to get the device index. To > fix the issue I've looked for another way to get the drm_device > pointer from the ctx, but I couldn't find any that is valid for > every GEN. Modifying the trace to add an extra parameter is out of > the question for 2 reasons: > - The only variable available in i915_gem_context_free is the ctx ptr > - Modifying a tracepoint could break ABI > > Ideas, anyone? http://patchwork.freedesktop.org/patch/48529/ -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] uxa: fix the call to PixmapSyncDirtyHelper, broken by xserver's 90db5ed
Please just use #ifdef HAS_DIRTYTRACKING_ROTATION avoids the pain of versions. Dave. On 9 July 2015 at 18:44, Chris Wilson wrote: > On Thu, Jul 09, 2015 at 11:26:38AM +0300, Martin Peres wrote: >> Signed-off-by: Martin Peres > > I would prefer this to be testing for the unstable release that > introduces the ABI change (i.e. > rather than >=), but it fixes the > build from git today and you said you would follow through later if we > can be more precise. > > Thanks, > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Store device pointer in contexts for late tracepoint usafe
On 29/06/2015 12:49, Jani Nikula wrote:
On Mon, 29 Jun 2015, Chris Wilson wrote:
On Mon, Jun 29, 2015 at 02:40:15PM +0300, Jani Nikula wrote:
On Thu, 07 May 2015, Chris Wilson wrote:
On Wed, May 06, 2015 at 01:16:30PM +0200, Daniel Vetter wrote:
On Tue, May 05, 2015 at 09:17:29AM +0100, Chris Wilson wrote:
[ 1572.417121] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 1572.421010] IP: [] ftrace_raw_event_i915_context+0x5d/0x70
[i915]
[ 1572.424970] PGD 1766a3067 PUD 1767a2067 PMD 0
[ 1572.428892] Oops: [#1] SMP
[ 1572.432787] Modules linked in: ipv6 dm_mod iTCO_wdt iTCO_vendor_support
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_controller
snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_timer snd soundcore serio_raw
pcspkr lpc_ich i2c_i801 mfd_core battery ac acpi_cpufreq i915 button video
drm_kms_helper drm
[ 1572.441720] CPU: 2 PID: 18853 Comm: kworker/u8:0 Not tainted
4.0.0_kcloud_3f0360_20150429+ #588
[ 1572.446298] Workqueue: i915 i915_gem_retire_work_handler [i915]
[ 1572.450876] task: 880002f428f0 ti: 880035724000 task.ti:
880035724000
[ 1572.47] RIP: 0010:[] []
ftrace_raw_event_i915_context+0x5d/0x70 [i915]
[ 1572.460423] RSP: 0018:880035727ce8 EFLAGS: 00010286
[ 1572.465262] RAX: 880073f1643c RBX: 880002da9058 RCX: 880073e5db40
[ 1572.470179] RDX: RSI: RDI: 880035727ce8
[ 1572.475107] RBP: 88007bb11a00 R08: R09:
[ 1572.480034] R10: 00362200 R11: 0008 R12:
[ 1572.484952] R13: 880035727d78 R14: 880002dc1c98 R15: 880002dc1dc8
[ 1572.489886] FS: () GS:88017fd0()
knlGS:
[ 1572.494883] CS: 0010 DS: ES: CR0: 8005003b
[ 1572.499859] CR2: CR3: 00017572a000 CR4: 001006e0
[ 1572.504842] Stack:
[ 1572.509834] 88017b0090c0 880073f16438 880002da9058
880073f1643c
[ 1572.514904] 0246 8801 88007bb11a00
880002ddeb10
[ 1572.519985] 8801759f79c0 a0092ff0
88007bb11a00
[ 1572.525049] Call Trace:
[ 1572.530093] [] ? i915_gem_context_free+0xa8/0xc1 [i915]
[ 1572.535227] [] ? i915_gem_request_free+0x4e/0x50 [i915]
[ 1572.540347] [] ?
intel_execlists_retire_requests+0x14c/0x159 [i915]
[ 1572.545500] [] ? i915_gem_retire_requests+0x9d/0xeb [i915]
[ 1572.550664] [] ? i915_gem_retire_work_handler+0x4c/0x61
[i915]
[ 1572.555825] [] ? process_one_work+0x1b2/0x31d
[ 1572.560951] [] ? worker_thread+0x24d/0x339
[ 1572.566033] [] ? cancel_delayed_work_sync+0xa/0xa
[ 1572.571140] [] ? kthread+0xce/0xd6
[ 1572.576191] [] ? kthread_create_on_node+0x162/0x162
[ 1572.581228] [] ? ret_from_fork+0x58/0x90
[ 1572.586259] [] ? kthread_create_on_node+0x162/0x162
[ 1572.591318] Code: de 48 89 e7 e8 09 4d 00 e1 48 85 c0 74 27 48 89 68 10 48 8b 55
38 48 89 e7 48 89 50 18 48 8b 55 10 48 8b 12 48 8b 12 48 8b 52 38 <8b> 12 89 50
08 e8 95 4d 00 e1 48 83 c4 30 5b 5d 41 5c c3 41 55
[ 1572.596981] RIP []
ftrace_raw_event_i915_context+0x5d/0x70 [i915]
[ 1572.602464] RSP
[ 1572.607911] CR2:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90112#c23
Signed-off-by: Chris Wilson
Could we do an igt for this, maybe using the sysfs trace interface?
I wonder if it is as simple as:
tracefs=/sys/kernel/tracing
function set_tracing {
for i in `find $tracefs/i915 -name enable`; do $i
echo $1 > $i
done
echo $1 > $tracefs/enable
}
set_tracing 1
./gem_ctx_basic
./gem_foo_basic
./gem_bar_basic
./gem_baz_basic
set_tracing 0
Is the patch still valid?
Yes.
I could use some review here
I had to rebase the patch to apply it, but apart from that:
Tested-by: Daniele Ceraolo Spurio
Reviewed-by: Daniele Ceraolo Spurio
Daniele
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/2] drm/i915: avoid leaking DMA mappings
We have 3 types of DMA mappings for GEM objects:
1. physically contiguous for stolen and for objects needing contiguous
memory
2. DMA-buf mappings imported via a DMA-buf attach operation
3. SG DMA mappings for shmem backed and userptr objects
For 1. and 2. the lifetime of the DMA mapping matches the lifetime of the
corresponding backing pages and so in practice we create/release the
mapping in the object's get_pages/put_pages callback.
For 3. the lifetime of the mapping matches that of any existing GPU binding
of the object, so we'll create the mapping when the object is bound to
the first vma and release the mapping when the object is unbound from its
last vma.
Since the object can be bound to multiple vmas, we can end up creating a
new DMA mapping in the 3. case even if the object already had one. This
is not allowed by the DMA API and can lead to leaked mapping data and
IOMMU memory space starvation in certain cases. For example HW IOMMU
drivers (intel_iommu) allocate a new range from their memory space
whenever a mapping is created, silently overriding a pre-existing
mapping.
Fix this by moving the creation/removal of DMA mappings to the object's
get_pages/put_pages callbacks. These callbacks already check for and do
an early return in case of any nested calls. This way objects of the 3.
case also become more like the other object types.
I noticed this issue by enabling DMA debugging, which got disabled after
a while due to its internal mapping tables getting full. It also reported
errors in connection to random other drivers that did a DMA mapping for
an address that was previously mapped by i915 but was never released.
Besides these diagnostic messages and the memory space starvation
problem for IOMMUs, I'm not aware of this causing a real issue.
The fix is based on a patch from Chris.
v2:
- move the DMA mapping create/remove calls to the get_pages/put_pages
callbacks instead of adding new callbacks for these (Chris)
v3:
- also fix the get_page cache logic on the userptr async path (Chris)
Signed-off-by: Imre Deak
Reviewed-by: Chris Wilson
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/i915_gem.c | 31 ---
drivers/gpu/drm/i915/i915_gem_userptr.c | 29 +++--
2 files changed, 43 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 425ced6..aa71067 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2146,6 +2146,8 @@ i915_gem_object_put_pages_gtt(struct drm_i915_gem_object
*obj)
obj->base.read_domains = obj->base.write_domain =
I915_GEM_DOMAIN_CPU;
}
+ i915_gem_gtt_finish_object(obj);
+
if (i915_gem_object_needs_bit17_swizzle(obj))
i915_gem_object_save_bit_17_swizzle(obj);
@@ -2206,6 +2208,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
struct sg_page_iter sg_iter;
struct page *page;
unsigned long last_pfn = 0; /* suppress gcc warning */
+ int ret;
gfp_t gfp;
/* Assert that the object is not currently in any GPU domain. As it
@@ -2253,8 +2256,10 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
*/
i915_gem_shrink_all(dev_priv);
page = shmem_read_mapping_page(mapping, i);
- if (IS_ERR(page))
+ if (IS_ERR(page)) {
+ ret = PTR_ERR(page);
goto err_pages;
+ }
}
#ifdef CONFIG_SWIOTLB
if (swiotlb_nr_tbl()) {
@@ -2283,6 +2288,10 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object
*obj)
sg_mark_end(sg);
obj->pages = st;
+ ret = i915_gem_gtt_prepare_object(obj);
+ if (ret)
+ goto err_pages;
+
if (i915_gem_object_needs_bit17_swizzle(obj))
i915_gem_object_do_bit_17_swizzle(obj);
@@ -2307,10 +2316,10 @@ err_pages:
* space and so want to translate the error from shmemfs back to our
* usual understanding of ENOMEM.
*/
- if (PTR_ERR(page) == -ENOSPC)
- return -ENOMEM;
- else
- return PTR_ERR(page);
+ if (ret == -ENOSPC)
+ ret = -ENOMEM;
+
+ return ret;
}
/* Ensure that the associated pages are gathered from the backing storage
@@ -3288,10 +3297,8 @@ int i915_vma_unbind(struct i915_vma *vma)
/* Since the unbound list is global, only move to that list if
* no more VMAs exist. */
- if (list_empty(&obj->vma_list)) {
- i915_gem_gtt_finish_object(obj);
+ if (list_empty(&obj->vma_list))
list_move_tail(&obj->global_list, &dev_priv->mm.unbound_list);
- }
/* And finally now the object is completely decoupled from this v
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: avoid leaking DMA mappings
On Thu, Jul 09, 2015 at 12:59:05PM +0300, Imre Deak wrote: > We have 3 types of DMA mappings for GEM objects: > 1. physically contiguous for stolen and for objects needing contiguous >memory > 2. DMA-buf mappings imported via a DMA-buf attach operation > 3. SG DMA mappings for shmem backed and userptr objects > > For 1. and 2. the lifetime of the DMA mapping matches the lifetime of the > corresponding backing pages and so in practice we create/release the > mapping in the object's get_pages/put_pages callback. > > For 3. the lifetime of the mapping matches that of any existing GPU binding > of the object, so we'll create the mapping when the object is bound to > the first vma and release the mapping when the object is unbound from its > last vma. > > Since the object can be bound to multiple vmas, we can end up creating a > new DMA mapping in the 3. case even if the object already had one. This > is not allowed by the DMA API and can lead to leaked mapping data and > IOMMU memory space starvation in certain cases. For example HW IOMMU > drivers (intel_iommu) allocate a new range from their memory space > whenever a mapping is created, silently overriding a pre-existing > mapping. > > Fix this by moving the creation/removal of DMA mappings to the object's > get_pages/put_pages callbacks. These callbacks already check for and do > an early return in case of any nested calls. This way objects of the 3. > case also become more like the other object types. > > I noticed this issue by enabling DMA debugging, which got disabled after > a while due to its internal mapping tables getting full. It also reported > errors in connection to random other drivers that did a DMA mapping for > an address that was previously mapped by i915 but was never released. > Besides these diagnostic messages and the memory space starvation > problem for IOMMUs, I'm not aware of this causing a real issue. > > The fix is based on a patch from Chris. > > v2: > - move the DMA mapping create/remove calls to the get_pages/put_pages > callbacks instead of adding new callbacks for these (Chris) > v3: > - also fix the get_page cache logic on the userptr async path (Chris) > > Signed-off-by: Imre Deak > Reviewed-by: Chris Wilson > Cc: sta...@vger.kernel.org Note to future self, I still like adding __i915_gem_object_init_pages() so that we can get that bit of incestrous knowledge out of userptr. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 0/5] drm/i915: Execlist cleanup
This set of patches cleans up a number of issues that were pushed out in the initial execlist submission. Nick Hoath (5): drm/i915: Clean up gen8 irq handler drm/i915: Unify execlist and legacy request life-cycles drm/i915: Simplify runtime_pm reference for execlists drm/i915: Reorder make_rpcs for later patch drm/i915: Clean up lrc context init drivers/gpu/drm/i915/i915_drv.h| 7 +- drivers/gpu/drm/i915/i915_gem.c| 94 +++ drivers/gpu/drm/i915/i915_gem_context.c| 21 --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 34 +++- drivers/gpu/drm/i915/i915_irq.c| 66 drivers/gpu/drm/i915/intel_lrc.c | 242 - drivers/gpu/drm/i915/intel_lrc.h | 8 +- drivers/gpu/drm/i915/intel_ringbuffer.c| 1 + drivers/gpu/drm/i915/intel_ringbuffer.h| 2 +- 9 files changed, 242 insertions(+), 233 deletions(-) -- 2.1.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 5/5] drm/i915: Clean up lrc context init
Clean up lrc context init by:
- Move context initialisation in to i915_gem_init_hw
- Move one off initialisation for render ring to
i915_gem_validate_context
- Move default context initialisation to logical_ring_init
Rename intel_lr_context_deferred_create to
intel_lr_context_deferred_alloc, to reflect reduced functionality.
Issue: VIZ-4798
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_drv.h| 1 -
drivers/gpu/drm/i915/i915_gem.c| 41
drivers/gpu/drm/i915/i915_gem_context.c| 21 --
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 36 +-
drivers/gpu/drm/i915/intel_lrc.c | 101 ++---
drivers/gpu/drm/i915/intel_lrc.h | 6 +-
drivers/gpu/drm/i915/intel_ringbuffer.c| 1 +
drivers/gpu/drm/i915/intel_ringbuffer.h| 1 +
8 files changed, 105 insertions(+), 103 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ef02378..3142a3a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3063,7 +3063,6 @@ int __must_check i915_gem_context_init(struct drm_device
*dev);
void i915_gem_context_fini(struct drm_device *dev);
void i915_gem_context_reset(struct drm_device *dev);
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file);
-int i915_gem_context_enable(struct drm_i915_gem_request *req);
void i915_gem_context_close(struct drm_device *dev, struct drm_file *file);
int i915_switch_context(struct drm_i915_gem_request *req);
struct intel_context *
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index d9f5e4d..914f660 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5048,6 +5048,7 @@ i915_gem_init_hw(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *ring;
int ret, i, j;
+ struct drm_i915_gem_request *req;
if (INTEL_INFO(dev)->gen < 6 && !intel_enable_gtt())
return -EIO;
@@ -5100,15 +5101,17 @@ i915_gem_init_hw(struct drm_device *dev)
}
/* Now it is safe to go back round and do everything else: */
- for_each_ring(ring, dev_priv, i) {
- struct drm_i915_gem_request *req;
+ ret = i915_gem_set_seqno(dev, ((u32)~0 - 0x1000));
+ if (ret)
+ goto out;
+
+ for_each_ring(ring, dev_priv, i) {
WARN_ON(!ring->default_context);
ret = i915_gem_request_alloc(ring, ring->default_context, &req);
if (ret) {
- i915_gem_cleanup_ringbuffer(dev);
- goto out;
+ goto clean_ringbuf_out;
}
if (ring->id == RCS) {
@@ -5119,22 +5122,34 @@ i915_gem_init_hw(struct drm_device *dev)
ret = i915_ppgtt_init_ring(req);
if (ret && ret != -EIO) {
DRM_ERROR("PPGTT enable ring #%d failed %d\n", i, ret);
- i915_gem_request_cancel(req);
- i915_gem_cleanup_ringbuffer(dev);
- goto out;
+ goto clean_req_out;
}
- ret = i915_gem_context_enable(req);
- if (ret && ret != -EIO) {
- DRM_ERROR("Context enable ring #%d failed %d\n", i,
ret);
- i915_gem_request_cancel(req);
- i915_gem_cleanup_ringbuffer(dev);
- goto out;
+ if (ring->switch_context) {
+ ret = ring->switch_context(req);
+ if (ret && ret != -EIO) {
+ DRM_ERROR("ring switch context: %d\n",
+ ret);
+ goto clean_req_out;
+ }
+ } else if (ring->init_context) {
+ ret = ring->init_context(req);
+ if (ret && ret != -EIO) {
+ DRM_ERROR("ring init context: %d\n",
+ ret);
+ goto clean_req_out;
+ }
}
i915_add_request_no_flush(req);
}
+ return ret;
+
+clean_req_out:
+ i915_gem_request_cancel(req);
+clean_ringbuf_out:
+ i915_gem_cleanup_ringbuffer(dev);
out:
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
return ret;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index a7e58a8..87a7fbc 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -409,27 +409,6 @@ void i915_gem_context_fini(struct drm_device *dev)
i915_gem_context_unreference(dctx);
}
-int i915_gem_context_enable
[Intel-gfx] [RFC 2/5] drm/i915: Unify execlist and legacy request life-cycles
There is a desire to simplify the i915 driver by reducing the number of
different code paths introduced by the LRC / execlists support. As the
execlists request is now part of the gem request it is possible and
desirable to unify the request life-cycles for execlist and legacy
requests.
Added a context complete flag to a request which gets set during the
context switch interrupt.
Added a function i915_gem_request_retireable(). A request is considered
retireable if its seqno passed (i.e. the request has completed) and either
it was never submitted to the ELSP or its context completed. This ensures
that context save is carried out before the last request for a context is
considered retireable. retire_requests_ring() now uses
i915_gem_request_retireable() rather than request_complete() when deciding
which requests to retire. Requests that were not waiting for a context
switch interrupt (either as a result of being merged into a following
request or by being a legacy request) will be considered retireable as
soon as their seqno has passed.
Removed the extra request reference held for the execlist request.
Removed intel_execlists_retire_requests() and all references to
intel_engine_cs.execlist_retired_req_list.
Moved context unpinning into retire_requests_ring() for now. Further work
is pending for the context pinning - this patch should allow us to use the
active list to track context and ring buffer objects later.
Changed gen8_cs_irq_handler() so that notify_ring() is called when
contexts complete as well as when a user interrupt occurs so that
notification happens when a request is complete and context save has
finished.
v2: Rebase over the read-read optimisation changes
Signed-off-by: Thomas Daniel
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_drv.h | 6
drivers/gpu/drm/i915/i915_gem.c | 49 +++--
drivers/gpu/drm/i915/i915_irq.c | 6 ++--
drivers/gpu/drm/i915/intel_lrc.c| 44 ++---
drivers/gpu/drm/i915/intel_lrc.h| 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
6 files changed, 53 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1dbd957..ef02378 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2213,6 +2213,12 @@ struct drm_i915_gem_request {
/** Execlists no. of times this request has been sent to the ELSP */
int elsp_submitted;
+ /**
+* Execlists: whether this requests's context has completed after
+* submission to the ELSP
+*/
+ bool ctx_complete;
+
};
int i915_gem_request_alloc(struct intel_engine_cs *ring,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 49016e0..3681a33 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2368,6 +2368,12 @@ void i915_vma_move_to_active(struct i915_vma *vma,
list_move_tail(&vma->mm_list, &vma->vm->active_list);
}
+static bool i915_gem_request_retireable(struct drm_i915_gem_request *req)
+{
+ return (i915_gem_request_completed(req, true) &&
+ (!req->elsp_submitted || req->ctx_complete));
+}
+
static void
i915_gem_object_retire__write(struct drm_i915_gem_object *obj)
{
@@ -2853,10 +2859,28 @@ i915_gem_retire_requests_ring(struct intel_engine_cs
*ring)
struct drm_i915_gem_request,
list);
- if (!i915_gem_request_completed(request, true))
+ if (!i915_gem_request_retireable(request))
break;
i915_gem_request_retire(request);
+
+ if (i915.enable_execlists) {
+ struct intel_context *ctx = request->ctx;
+ struct drm_i915_private *dev_priv =
+ ring->dev->dev_private;
+ unsigned long flags;
+ struct drm_i915_gem_object *ctx_obj =
+ ctx->engine[ring->id].state;
+
+ spin_lock_irqsave(&ring->execlist_lock, flags);
+
+ if (ctx_obj && (ctx != ring->default_context))
+ intel_lr_context_unpin(ring, ctx);
+
+ intel_runtime_pm_put(dev_priv);
+ spin_unlock_irqrestore(&ring->execlist_lock, flags);
+ }
+
}
/* Move any buffers on the active list that are no longer referenced
@@ -2872,12 +2896,14 @@ i915_gem_retire_requests_ring(struct intel_engine_cs
*ring)
if (!list_empty(&obj->last_read_req[ring->id]->list))
break;
+ if (!i915_gem_request_retireable(obj->last_read_req[ring->id]))
+ break;
i915_gem_object_retire__read(obj, ring->id);
}
[Intel-gfx] [RFC 1/5] drm/i915: Clean up gen8 irq handler
Moved common code handling command streamer interrupts into a function.
Renamed tmp variable to the more descriptive iir.
Signed-off-by: Thomas Daniel
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_irq.c | 68 +
1 file changed, 35 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a6fbe64..3ac30b8 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1156,70 +1156,72 @@ static void snb_gt_irq_handler(struct drm_device *dev,
ivybridge_parity_error_irq_handler(dev, gt_iir);
}
+static void gen8_cs_irq_handler(struct intel_engine_cs *ring, u32 iir)
+{
+ if (iir & GT_CONTEXT_SWITCH_INTERRUPT)
+ intel_lrc_irq_handler(ring);
+ if (iir & GT_RENDER_USER_INTERRUPT)
+ notify_ring(ring);
+}
+
static irqreturn_t gen8_gt_irq_handler(struct drm_i915_private *dev_priv,
u32 master_ctl)
{
irqreturn_t ret = IRQ_NONE;
if (master_ctl & (GEN8_GT_RCS_IRQ | GEN8_GT_BCS_IRQ)) {
- u32 tmp = I915_READ_FW(GEN8_GT_IIR(0));
- if (tmp) {
- I915_WRITE_FW(GEN8_GT_IIR(0), tmp);
+ u32 iir = I915_READ_FW(GEN8_GT_IIR(0));
+
+ if (iir) {
+ I915_WRITE_FW(GEN8_GT_IIR(0), iir);
ret = IRQ_HANDLED;
- if (tmp & (GT_CONTEXT_SWITCH_INTERRUPT <<
GEN8_RCS_IRQ_SHIFT))
- intel_lrc_irq_handler(&dev_priv->ring[RCS]);
- if (tmp & (GT_RENDER_USER_INTERRUPT <<
GEN8_RCS_IRQ_SHIFT))
- notify_ring(&dev_priv->ring[RCS]);
+ gen8_cs_irq_handler(&dev_priv->ring[RCS],
+ iir >> GEN8_RCS_IRQ_SHIFT);
- if (tmp & (GT_CONTEXT_SWITCH_INTERRUPT <<
GEN8_BCS_IRQ_SHIFT))
- intel_lrc_irq_handler(&dev_priv->ring[BCS]);
- if (tmp & (GT_RENDER_USER_INTERRUPT <<
GEN8_BCS_IRQ_SHIFT))
- notify_ring(&dev_priv->ring[BCS]);
+ gen8_cs_irq_handler(&dev_priv->ring[BCS],
+ iir >> GEN8_BCS_IRQ_SHIFT);
} else
DRM_ERROR("The master control interrupt lied (GT0)!\n");
}
if (master_ctl & (GEN8_GT_VCS1_IRQ | GEN8_GT_VCS2_IRQ)) {
- u32 tmp = I915_READ_FW(GEN8_GT_IIR(1));
- if (tmp) {
- I915_WRITE_FW(GEN8_GT_IIR(1), tmp);
+ u32 iir = I915_READ_FW(GEN8_GT_IIR(1));
+
+ if (iir) {
+ I915_WRITE_FW(GEN8_GT_IIR(1), iir);
ret = IRQ_HANDLED;
- if (tmp & (GT_CONTEXT_SWITCH_INTERRUPT <<
GEN8_VCS1_IRQ_SHIFT))
- intel_lrc_irq_handler(&dev_priv->ring[VCS]);
- if (tmp & (GT_RENDER_USER_INTERRUPT <<
GEN8_VCS1_IRQ_SHIFT))
- notify_ring(&dev_priv->ring[VCS]);
+ gen8_cs_irq_handler(&dev_priv->ring[VCS],
+ iir >> GEN8_VCS1_IRQ_SHIFT);
- if (tmp & (GT_CONTEXT_SWITCH_INTERRUPT <<
GEN8_VCS2_IRQ_SHIFT))
- intel_lrc_irq_handler(&dev_priv->ring[VCS2]);
- if (tmp & (GT_RENDER_USER_INTERRUPT <<
GEN8_VCS2_IRQ_SHIFT))
- notify_ring(&dev_priv->ring[VCS2]);
+ gen8_cs_irq_handler(&dev_priv->ring[VCS2],
+ iir >> GEN8_VCS2_IRQ_SHIFT);
} else
DRM_ERROR("The master control interrupt lied (GT1)!\n");
}
if (master_ctl & GEN8_GT_VECS_IRQ) {
- u32 tmp = I915_READ_FW(GEN8_GT_IIR(3));
- if (tmp) {
- I915_WRITE_FW(GEN8_GT_IIR(3), tmp);
+ u32 iir = I915_READ_FW(GEN8_GT_IIR(3));
+
+ if (iir) {
+ I915_WRITE_FW(GEN8_GT_IIR(3), iir);
ret = IRQ_HANDLED;
- if (tmp & (GT_CONTEXT_SWITCH_INTERRUPT <<
GEN8_VECS_IRQ_SHIFT))
- intel_lrc_irq_handler(&dev_priv->ring[VECS]);
- if (tmp & (GT_RENDER_USER_INTERRUPT <<
GEN8_VECS_IRQ_SHIFT))
- notify_ring(&dev_priv->ring[VECS]);
+ gen8_cs_irq_handler(&dev_priv->ring[VECS],
+ iir >> GEN8_VECS_IRQ_SHIFT);
} else
DRM_ERROR("The master control interrupt lied (GT3)!\n");
}
if (master_ctl & GEN8_GT_PM_IRQ) {
- u32 tmp = I915_READ_FW(GEN8_GT_IIR(2));
- if (tmp & dev_priv->pm_rps_events) {
+ u32
[Intel-gfx] [RFC 4/5] drm/i915: Reorder make_rpcs for later patch
Issue: VIZ-4798
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/intel_lrc.c | 86
1 file changed, 43 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index adc4942..770a6f6 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1302,6 +1302,49 @@ out:
return ret;
}
+static u32
+make_rpcs(struct drm_device *dev)
+{
+ u32 rpcs = 0;
+
+ /*
+* No explicit RPCS request is needed to ensure full
+* slice/subslice/EU enablement prior to Gen9.
+ */
+ if (INTEL_INFO(dev)->gen < 9)
+ return 0;
+
+ /*
+* Starting in Gen9, render power gating can leave
+* slice/subslice/EU in a partially enabled state. We
+* must make an explicit request through RPCS for full
+* enablement.
+ */
+ if (INTEL_INFO(dev)->has_slice_pg) {
+ rpcs |= GEN8_RPCS_S_CNT_ENABLE;
+ rpcs |= INTEL_INFO(dev)->slice_total <<
+ GEN8_RPCS_S_CNT_SHIFT;
+ rpcs |= GEN8_RPCS_ENABLE;
+ }
+
+ if (INTEL_INFO(dev)->has_subslice_pg) {
+ rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
+ rpcs |= INTEL_INFO(dev)->subslice_per_slice <<
+ GEN8_RPCS_SS_CNT_SHIFT;
+ rpcs |= GEN8_RPCS_ENABLE;
+ }
+
+ if (INTEL_INFO(dev)->has_eu_pg) {
+ rpcs |= INTEL_INFO(dev)->eu_per_subslice <<
+ GEN8_RPCS_EU_MIN_SHIFT;
+ rpcs |= INTEL_INFO(dev)->eu_per_subslice <<
+ GEN8_RPCS_EU_MAX_SHIFT;
+ rpcs |= GEN8_RPCS_ENABLE;
+ }
+
+ return rpcs;
+}
+
static int gen8_init_common_ring(struct intel_engine_cs *ring)
{
struct drm_device *dev = ring->dev;
@@ -1919,49 +1962,6 @@ cleanup_render_ring:
return ret;
}
-static u32
-make_rpcs(struct drm_device *dev)
-{
- u32 rpcs = 0;
-
- /*
-* No explicit RPCS request is needed to ensure full
-* slice/subslice/EU enablement prior to Gen9.
- */
- if (INTEL_INFO(dev)->gen < 9)
- return 0;
-
- /*
-* Starting in Gen9, render power gating can leave
-* slice/subslice/EU in a partially enabled state. We
-* must make an explicit request through RPCS for full
-* enablement.
- */
- if (INTEL_INFO(dev)->has_slice_pg) {
- rpcs |= GEN8_RPCS_S_CNT_ENABLE;
- rpcs |= INTEL_INFO(dev)->slice_total <<
- GEN8_RPCS_S_CNT_SHIFT;
- rpcs |= GEN8_RPCS_ENABLE;
- }
-
- if (INTEL_INFO(dev)->has_subslice_pg) {
- rpcs |= GEN8_RPCS_SS_CNT_ENABLE;
- rpcs |= INTEL_INFO(dev)->subslice_per_slice <<
- GEN8_RPCS_SS_CNT_SHIFT;
- rpcs |= GEN8_RPCS_ENABLE;
- }
-
- if (INTEL_INFO(dev)->has_eu_pg) {
- rpcs |= INTEL_INFO(dev)->eu_per_subslice <<
- GEN8_RPCS_EU_MIN_SHIFT;
- rpcs |= INTEL_INFO(dev)->eu_per_subslice <<
- GEN8_RPCS_EU_MAX_SHIFT;
- rpcs |= GEN8_RPCS_ENABLE;
- }
-
- return rpcs;
-}
-
static int
populate_lr_context(struct intel_context *ctx, struct drm_i915_gem_object
*ctx_obj,
struct intel_engine_cs *ring, struct intel_ringbuffer
*ringbuf)
--
2.1.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 3/5] drm/i915: Simplify runtime_pm reference for execlists
No longer take a runtime_pm reference for each execlist request. Only
take a single reference when the execlist queue becomes nonempty and
release it when it becomes empty.
Signed-off-by: Thomas Daniel
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_gem.c | 10 +++---
drivers/gpu/drm/i915/intel_lrc.c | 15 +--
2 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3681a33..d9f5e4d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2758,6 +2758,13 @@ static void i915_gem_reset_ring_cleanup(struct
drm_i915_private *dev_priv,
}
/*
+* If we come in here, and the list wasn't empty, then there was
+* a pm taken, so free it up now
+*/
+ if (!list_empty(&ring->execlist_queue))
+ intel_runtime_pm_put(dev_priv);
+
+ /*
* Clear the execlists queue up before freeing the requests, as those
* are the ones that keep the context and ringbuffer backing objects
* pinned in place.
@@ -2866,8 +2873,6 @@ i915_gem_retire_requests_ring(struct intel_engine_cs
*ring)
if (i915.enable_execlists) {
struct intel_context *ctx = request->ctx;
- struct drm_i915_private *dev_priv =
- ring->dev->dev_private;
unsigned long flags;
struct drm_i915_gem_object *ctx_obj =
ctx->engine[ring->id].state;
@@ -2877,7 +2882,6 @@ i915_gem_retire_requests_ring(struct intel_engine_cs
*ring)
if (ctx_obj && (ctx != ring->default_context))
intel_lr_context_unpin(ring, ctx);
- intel_runtime_pm_put(dev_priv);
spin_unlock_irqrestore(&ring->execlist_lock, flags);
}
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 8373900..adc4942 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -399,8 +399,16 @@ static void execlists_context_unqueue(struct
intel_engine_cs *ring)
*/
WARN_ON(!intel_irqs_enabled(ring->dev->dev_private));
- if (list_empty(&ring->execlist_queue))
+ if (list_empty(&ring->execlist_queue)) {
+ /*
+* We can only come in to this function if at some
+* point there was a request queued. So if there
+* are no longer any requests queued, it's time to
+* put the pm
+*/
+ intel_runtime_pm_put(ring->dev->dev_private);
return;
+ }
/* Try to read in pairs */
list_for_each_entry_safe(cursor, tmp, &ring->execlist_queue,
@@ -546,6 +554,7 @@ bool intel_lrc_irq_handler(struct intel_engine_cs *ring)
static int execlists_context_queue(struct drm_i915_gem_request *request)
{
struct intel_engine_cs *ring = request->ring;
+ struct drm_i915_private *dev_priv = ring->dev->dev_private;
struct drm_i915_gem_request *cursor;
int num_elements = 0;
@@ -577,8 +586,10 @@ static int execlists_context_queue(struct
drm_i915_gem_request *request)
}
list_add_tail(&request->execlist_link, &ring->execlist_queue);
- if (num_elements == 0)
+ if (num_elements == 0) {
+ intel_runtime_pm_get(dev_priv);
execlists_context_unqueue(ring);
+ }
spin_unlock_irq(&ring->execlist_lock);
--
2.1.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 1/5] drm/i915: Clean up gen8 irq handler
On Thu, Jul 09, 2015 at 11:57:40AM +0100, Nick Hoath wrote: > Moved common code handling command streamer interrupts into a function. > Renamed tmp variable to the more descriptive iir. Does the compiler eliminate those shifts you added? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/5] drm/i915: Unify execlist and legacy request life-cycles
On Thu, Jul 09, 2015 at 11:57:41AM +0100, Nick Hoath wrote: > There is a desire to simplify the i915 driver by reducing the number of > different code paths introduced by the LRC / execlists support. As the > execlists request is now part of the gem request it is possible and > desirable to unify the request life-cycles for execlist and legacy > requests. > > Added a context complete flag to a request which gets set during the > context switch interrupt. > > Added a function i915_gem_request_retireable(). A request is considered > retireable if its seqno passed (i.e. the request has completed) and either > it was never submitted to the ELSP or its context completed. This ensures > that context save is carried out before the last request for a context is > considered retireable. retire_requests_ring() now uses > i915_gem_request_retireable() rather than request_complete() when deciding > which requests to retire. Requests that were not waiting for a context > switch interrupt (either as a result of being merged into a following > request or by being a legacy request) will be considered retireable as > soon as their seqno has passed. Nak. Just keep the design as requests only retire when seqno passes. > Removed the extra request reference held for the execlist request. > > Removed intel_execlists_retire_requests() and all references to > intel_engine_cs.execlist_retired_req_list. > > Moved context unpinning into retire_requests_ring() for now. Further work > is pending for the context pinning - this patch should allow us to use the > active list to track context and ring buffer objects later. > > Changed gen8_cs_irq_handler() so that notify_ring() is called when > contexts complete as well as when a user interrupt occurs so that > notification happens when a request is complete and context save has > finished. > > v2: Rebase over the read-read optimisation changes Any reason why you didn't review my patches to do this much more neatly? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 3/5] drm/i915: Simplify runtime_pm reference for execlists
On Thu, Jul 09, 2015 at 11:57:42AM +0100, Nick Hoath wrote: > No longer take a runtime_pm reference for each execlist request. Only > take a single reference when the execlist queue becomes nonempty and > release it when it becomes empty. Nak. We already hold the runtime_pm for GPU activity. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 5/5] drm/i915: Clean up lrc context init
On Thu, Jul 09, 2015 at 11:57:44AM +0100, Nick Hoath wrote: > Clean up lrc context init by: >- Move context initialisation in to i915_gem_init_hw >- Move one off initialisation for render ring to > i915_gem_validate_context >- Move default context initialisation to logical_ring_init > > Rename intel_lr_context_deferred_create to > intel_lr_context_deferred_alloc, to reflect reduced functionality. Not far enough. You can tidy the deferred context creation to request allocation now, e.g.: http://cgit.freedesktop.org/~ickle/linux-2.6/commit/?h=nightly&id=d1a7b2bd3a65b3fb605f0702a7550e8ae281cfd8 -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/5] HDMI optimization series
This series adds some optimization related to reading of edid only when required and when live status says so. The comments in the patches explain more. First 3 patches were posted earlier(last week) too. Sending them again along with the live status patch as part of the series. Shashank Sharma (3): drm/i915: add attached connector to hdmi container drm/i915: Add HDMI probe function drm/i915: Read HDMI EDID only when required Sonika Jindal (2): drm/i915: Check live status before reading edid drm/i915: Set edid from detect only if forced drivers/gpu/drm/i915/intel_drv.h |1 + drivers/gpu/drm/i915/intel_hdmi.c | 99 + 2 files changed, 90 insertions(+), 10 deletions(-) -- 1.7.10.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915: Read HDMI EDID only when required
From: Shashank Sharma
This patch makes sure that the HDMI detect function
reads EDID only when its forced to do it. All the other
times, it uses the connector->detect_edid which was cached
during hotplug handling in the hdmi_probe() function. As the
probe function gets called before detect in the interrupt handler
and handles the EDID cacheing part, its absolutely safe to assume
that presence of EDID reflects monitor connected and viceversa.
This will save us from many race conditions between hotplug/unplug
detect call handler threads and userspace calls for the same.
The previous patch in this patch series explains this in detail.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_hdmi.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 064ddd8..1fb6919 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1362,19 +1362,33 @@ static enum drm_connector_status
intel_hdmi_detect(struct drm_connector *connector, bool force)
{
enum drm_connector_status status;
+ struct intel_connector *intel_connector =
+ to_intel_connector(connector);
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
+ /*
+* There are many userspace calls which probe EDID from
+* detect path. In case on multiple hotplug/unplug, these
+* can cause race conditions while probing EDID. Also its
+* waste of CPU cycles to read the EDID again and again
+* unless there is a real hotplug.
+* So until we are forced, check connector status
+* based on availability of cached EDID. This will avoid many of
+* these race conditions and timing problems.
+*/
+ if (force)
+ intel_hdmi_probe(intel_connector->encoder);
- intel_hdmi_unset_edid(connector);
-
- if (intel_hdmi_set_edid(connector)) {
+ if (intel_connector->detect_edid) {
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
-
- hdmi_to_dig_port(intel_hdmi)->base.type = INTEL_OUTPUT_HDMI;
status = connector_status_connected;
- } else
+ hdmi_to_dig_port(intel_hdmi)->base.type = INTEL_OUTPUT_HDMI;
+ DRM_DEBUG_DRIVER("hdmi status = connected\n");
+ } else {
status = connector_status_disconnected;
+ DRM_DEBUG_DRIVER("hdmi status = disconnected\n");
+ }
return status;
}
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: Add HDMI probe function
From: Shashank Sharma
This patch adds a separate probe function for HDMI
EDID read over DDC channel. This function has been
registered as a .hot_plug handler for HDMI encoder.
The reason behind addition of this separate function needs
brief explaination. The current implementation of hdmi_detect()
function re-sets the cached HDMI edid (in connector->detect_edid) in
every detect call.This function gets called many times, sometimes
directly from userspace probes, forcing drivers to read EDID every
detect function call.This causes several problems like:
1. Race conditions in multiple hot_plug / unplug cases, between
interrupts bottom halves and userspace detections.
2. Many Un-necessary EDID reads for single hotplug/unplug
3. HDMI complaince failures which expects only one EDID read per hotplug
This function will be serving the purpose of really reading the EDID
by really probing the DDC channel, and updating the cached EDID.
The plan is to:
1. i915 IRQ handler bottom half function already calls
intel_encoder->hotplug() function. Adding This probe function which
will read the EDID only in case of a hotplug / unplug.
2. Reuse the cached EDID in hdmi_detect() function UNLESS we are forced
to probe the EDID by the force=1 variable.The next patch in the
series does this.
3. Make sure that we are using this force variable properly.
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_hdmi.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index af4d1e6..064ddd8 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1340,6 +1340,24 @@ intel_hdmi_set_edid(struct drm_connector *connector)
return connected;
}
+void intel_hdmi_probe(struct intel_encoder *intel_encoder)
+{
+ struct intel_hdmi *intel_hdmi =
+ enc_to_intel_hdmi(&intel_encoder->base);
+ struct intel_connector *intel_connector =
+ intel_hdmi->attached_connector;
+ /*
+* We are here, means there is a hotplug or a force
+* detection. Clear the cached EDID and probe the
+* DDC bus to check the current status of HDMI.
+*/
+ intel_hdmi_unset_edid(&intel_connector->base);
+ if (intel_hdmi_set_edid(&intel_connector->base))
+ DRM_DEBUG_DRIVER("DDC probe: got EDID\n");
+ else
+ DRM_DEBUG_DRIVER("DDC probe: no EDID\n");
+}
+
static enum drm_connector_status
intel_hdmi_detect(struct drm_connector *connector, bool force)
{
@@ -1997,6 +2015,7 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
intel_connector->unregister = intel_connector_unregister;
intel_hdmi_add_properties(intel_hdmi, connector);
+ intel_encoder->hot_plug = intel_hdmi_probe;
intel_connector_attach_encoder(intel_connector, intel_encoder);
drm_connector_register(connector);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: add attached connector to hdmi container
From: Shashank Sharma
This patch adds the intel_connector initialized to intel_hdmi
display, during the init phase, just like the other encoders do.
This attachment is very useful when we need to extract the connector
pointer during the hotplug handler function
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_hdmi.c |1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index e90c743..a47fbc3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -659,6 +659,7 @@ struct intel_hdmi {
enum hdmi_force_audio force_audio;
bool rgb_quant_range_selectable;
enum hdmi_picture_aspect aspect_ratio;
+ struct intel_connector *attached_connector;
void (*write_infoframe)(struct drm_encoder *encoder,
enum hdmi_infoframe_type type,
const void *frame, ssize_t len);
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 00c4b40..af4d1e6 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2000,6 +2000,7 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
intel_connector_attach_encoder(intel_connector, intel_encoder);
drm_connector_register(connector);
+ intel_hdmi->attached_connector = intel_connector;
/* For G4X desktop chip, PEG_BAND_GAP_DATA 3:0 must first be written
* 0xd. Failure to do so will result in spurious interrupts being
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/5] drm/i915: Check live status before reading edid
Adding this for SKL onwards.
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/intel_hdmi.c | 49 ++---
1 file changed, 45 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 1fb6919..769cf4f 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1300,6 +1300,46 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
to_intel_connector(connector)->detect_edid = NULL;
}
+static bool intel_hdmi_live_status(struct intel_digital_port *intel_dig_port)
+{
+ struct drm_device *dev = intel_dig_port->base.base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ enum port port = intel_dig_port->port;
+
+ if (IS_SKYLAKE(dev)) {
+ u32 temp = I915_READ(SDEISR);
+
+ switch (port) {
+ case PORT_B:
+ return temp & SDE_PORTB_HOTPLUG_CPT;
+
+ case PORT_C:
+ return temp & SDE_PORTC_HOTPLUG_CPT;
+
+ case PORT_D:
+ return temp & SDE_PORTD_HOTPLUG_CPT;
+
+ default:
+ return false;
+ }
+ } else if (IS_BROXTON(dev)) {
+ u32 temp = I915_READ(GEN8_DE_PORT_ISR);
+
+ switch (port) {
+ case PORT_B:
+ return temp & BXT_DE_PORT_HP_DDIB;
+
+ case PORT_C:
+ return temp & BXT_DE_PORT_HP_DDIC;
+
+ default:
+ return false;
+
+ }
+ }
+ return true;
+}
+
static bool
intel_hdmi_set_edid(struct drm_connector *connector)
{
@@ -1308,15 +1348,16 @@ intel_hdmi_set_edid(struct drm_connector *connector)
struct intel_encoder *intel_encoder =
&hdmi_to_dig_port(intel_hdmi)->base;
enum intel_display_power_domain power_domain;
- struct edid *edid;
+ struct edid *edid = NULL;
bool connected = false;
power_domain = intel_display_port_power_domain(intel_encoder);
intel_display_power_get(dev_priv, power_domain);
- edid = drm_get_edid(connector,
- intel_gmbus_get_adapter(dev_priv,
- intel_hdmi->ddc_bus));
+ if (intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi)))
+ edid = drm_get_edid(connector,
+ intel_gmbus_get_adapter(dev_priv,
+ intel_hdmi->ddc_bus));
intel_display_power_put(dev_priv, power_domain);
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Set edid from detect only if forced
During init_connector set the edid, then edid will be set/unset only during
hotplug. For the sake of older platforms where HPD is not stable, let edid
read happen from detect as well only if it is forced to do so.
Signed-off-by: Sonika Jindal
---
drivers/gpu/drm/i915/intel_hdmi.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 769cf4f..0111ac0a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1405,6 +1405,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
enum drm_connector_status status;
struct intel_connector *intel_connector =
to_intel_connector(connector);
+ struct drm_device *dev = connector->dev;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
connector->base.id, connector->name);
@@ -1418,7 +1419,7 @@ intel_hdmi_detect(struct drm_connector *connector, bool
force)
* based on availability of cached EDID. This will avoid many of
* these race conditions and timing problems.
*/
- if (force)
+ if (force && INTEL_INFO(dev)->gen < 9)
intel_hdmi_probe(intel_connector->encoder);
if (intel_connector->detect_edid) {
@@ -2076,6 +2077,9 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
drm_connector_register(connector);
intel_hdmi->attached_connector = intel_connector;
+ /* Set edid during init */
+ intel_hdmi_probe(intel_encoder);
+
/* For G4X desktop chip, PEG_BAND_GAP_DATA 3:0 must first be written
* 0xd. Failure to do so will result in spurious interrupts being
* generated on the port when a cable is not attached.
--
1.7.10.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: storm detection documentation update
On 7/8/2015 8:50 PM, Daniel Vetter wrote: On Wed, Jul 08, 2015 at 06:54:06PM +0530, Sivakumar Thulasimani wrote: On 7/7/2015 5:01 PM, Daniel Vetter wrote: On Tue, Jul 07, 2015 at 04:10:49PM +0530, Sivakumar Thulasimani wrote: From: "Thulasimani,Sivakumar" Update the hotplug documentation to explain that hotplug storm is not expected for Display port panels and hence is not handled in current code. Signed-off-by: Sivakumar Thulasimani --- drivers/gpu/drm/i915/intel_hotplug.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_hotplug.c b/drivers/gpu/drm/i915/intel_hotplug.c index bac91a1..7dc5e6a 100644 --- a/drivers/gpu/drm/i915/intel_hotplug.c +++ b/drivers/gpu/drm/i915/intel_hotplug.c @@ -66,6 +66,10 @@ * while before being re-enabled. The intention is to mitigate issues raising * from broken hardware triggering massive amounts of interrupts and grinding * the system to a halt. + * + * Hotplug interrupt storm is not expected on Display port panel, hence the + * current code only handles disabling and later enabling of HPD interrupts + * for HDMI panels through the storm handling set of functions. This isn't accurate, we handle storms on everything _but_ DP (tv, vga, sdvo, ...). I'd go with * Hotplug interrupt storm is not expected on Display port panel, hence the * current code doesn't handle irq reenabling when a DP sink is connected * and the hpd is handled by the DP callbacks. But on DP+ ports * storms are still handled correctly in all other cases (e.g. due to HDMI * sinks). Could still be improved I think. -Daniel Sorry i don't get the "DP+" reference here. By DP+, do you mean dongles ? passive dongles will report them selves as HDMI to respective detect routines active dongles will be still treated as DP hence not handling HPD will apply to any display connected through active dongle as well. DP+ is DP with support for HDMI with level shifter cables (i.e. all the ports on intel chips). I just wanted to make it clear that storm handling doesn't work if we have a confirmed DP sink on the port, but will work in any other cases (nothing or HDMI sink or DVI or whatever connected). Like I said some room for improvement ;-) -Daniel how about the following ? * current implementation expects that hotplug interrupt storm will not be * seen when display port sink is connected, hence on platforms whose DP * callback is handled by i915_digport_work_func reenabling of hpd is not * performed ( it was never expected to be disabled in the first place ;) ) * this is specific to DP sinks handled by this routine and any other display * such as HDMI or DVI enabled on the same port will have proper logic since * it will use i915_hotplug_work_func where this logic is handled. please provide any corrections or new comment to be used, i'll upload a new patch with the final approved text block. -- regards, Sivakumar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: PSR: Flush means invalidate + flush
2015-07-08 20:21 GMT-03:00 Rodrigo Vivi :
> Since flush actually means invalidate + flush we need to force psr
> exit on PSR flush.
>
> On Core platforms there is no way to disable hw tracking and
> do the pure sw tracking so we simulate it by fully disable psr and
> reschedule a enable back.
> So a good idea is to minimize sequential disable/enable in cases we
> know that HW tracking like when flush has been originated by a flip.
> Also flip had just invalidated it already.
>
> It also uses origin to minimize the a bit the amount of
> disable/enabled, mainly when flip already had invalidated.
>
> With this patch in place it is possible to do a flush on dirty areas
> properly in a following patch.
>
> v2: Remove duplicated exit on HSW+Sprites as pointed out by Paulo.
Reviewed-by: Paulo Zanoni
>
> Cc: Paulo Zanoni
> Cc: Daniel Vetter
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_drv.h | 3 ++-
> drivers/gpu/drm/i915/intel_frontbuffer.c | 2 +-
> drivers/gpu/drm/i915/intel_psr.c | 40
> +---
> 3 files changed, 24 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index beeb4d3..c863511 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1329,7 +1329,8 @@ void intel_psr_disable(struct intel_dp *intel_dp);
> void intel_psr_invalidate(struct drm_device *dev,
> unsigned frontbuffer_bits);
> void intel_psr_flush(struct drm_device *dev,
> -unsigned frontbuffer_bits);
> +unsigned frontbuffer_bits,
> +enum fb_op_origin origin);
> void intel_psr_init(struct drm_device *dev);
> void intel_psr_single_frame_update(struct drm_device *dev,
>unsigned frontbuffer_bits);
> diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c
> b/drivers/gpu/drm/i915/intel_frontbuffer.c
> index cb5a6f0..e73d2ff0 100644
> --- a/drivers/gpu/drm/i915/intel_frontbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
> @@ -128,7 +128,7 @@ void intel_frontbuffer_flush(struct drm_device *dev,
> return;
>
> intel_edp_drrs_flush(dev, frontbuffer_bits);
> - intel_psr_flush(dev, frontbuffer_bits);
> + intel_psr_flush(dev, frontbuffer_bits, origin);
> intel_fbc_flush(dev_priv, frontbuffer_bits);
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index d79ba58..6db043f 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -680,6 +680,7 @@ void intel_psr_invalidate(struct drm_device *dev,
> * intel_psr_flush - Flush PSR
> * @dev: DRM device
> * @frontbuffer_bits: frontbuffer plane tracking bits
> + * @origin: which operation caused the flush
> *
> * Since the hardware frontbuffer tracking has gaps we need to integrate
> * with the software frontbuffer tracking. This function gets called every
> @@ -689,7 +690,7 @@ void intel_psr_invalidate(struct drm_device *dev,
> * Dirty frontbuffers relevant to PSR are tracked in busy_frontbuffer_bits.
> */
> void intel_psr_flush(struct drm_device *dev,
> -unsigned frontbuffer_bits)
> +unsigned frontbuffer_bits, enum fb_op_origin origin)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> struct drm_crtc *crtc;
> @@ -707,24 +708,25 @@ void intel_psr_flush(struct drm_device *dev,
> frontbuffer_bits &= INTEL_FRONTBUFFER_ALL_MASK(pipe);
> dev_priv->psr.busy_frontbuffer_bits &= ~frontbuffer_bits;
>
> - /*
> -* On Haswell sprite plane updates don't result in a psr invalidating
> -* signal in the hardware. Which means we need to manually fake this
> in
> -* software for all flushes, not just when we've seen a preceding
> -* invalidation through frontbuffer rendering.
> -*/
> - if (IS_HASWELL(dev) &&
> - (frontbuffer_bits & INTEL_FRONTBUFFER_SPRITE(pipe)))
> - intel_psr_exit(dev);
> -
> - /*
> -* On Valleyview and Cherryview we don't use hardware tracking so
> -* any plane updates or cursor moves don't result in a PSR
> -* invalidating. Which means we need to manually fake this in
> -* software for all flushes, not just when we've seen a preceding
> -* invalidation through frontbuffer rendering. */
> - if (frontbuffer_bits && !HAS_DDI(dev))
> - intel_psr_exit(dev);
> + if (HAS_DDI(dev)) {
> + /*
> +* By definition every flush should mean invalidate + flush,
> +* however on core platforms let's minimize the
> +* disable/re-enable so we can avoid the invalidate when flip
> +* originated the flush.
> +*/
> + if (frontbuffer_bits && origin != O
Re: [Intel-gfx] [PATCH] drm/i915: dirty fb operation flushsing frontbuffer
2015-07-08 20:22 GMT-03:00 Rodrigo Vivi :
> Let's do a frontbuffer flush on dirty fb.
> To be used for DIRTYFB drm ioctl.
>
> This patch solves the biggest PSR known issue, that is
> missed screen updates during boot, mainly when there is a splash
> screen involved like Plymouth.
>
> Previously PSR was being invalidated by fbdev and Plymounth
> was taking control with PSR yet invalidated and could get screen
> updates normally. However with some atomic modeset changes
> Pymouth modeset over ioctl was now causing frontbuffer flushes
> making PSR gets back to work while it cannot track the
> screen updates and exit properly.
>
> By adding this flush on dirtyfb we properly track frontbuffer
> writes and properly exit PSR.
>
> Actually all mmap_wc users should call this dirty callback
> in order to have a proper frontbuffer tracking.
>
> In the future it can be extended to return 0 if the whole
> screen has being flushed or the number of rects flushed
> as Chris suggested.
>
> v2: Remove ORIGIN_FB_DIRTY and use ORIGIN_GTT instead since dirty
> callback is just called after few screen updates and not on
> everyone as pointed by Daniel.
>
> v3: Use flush instead of invalidate since flush means
> invalidate + flush and dirty means drawn had finished and
> it can be flushed.
>
> v4: Remove PSR from subject since it is purely frontbuffer tracking
> change and that can be useful for FBC as well.
>
> Cc: Chris Wilson
> Cc: Paulo Zanoni
> Cc: Daniel Vetter
> Signed-off-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_display.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 0efa455..1d67958 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14388,9 +14388,27 @@ static int
> intel_user_framebuffer_create_handle(struct drm_framebuffer *fb,
> return drm_gem_handle_create(file, &obj->base, handle);
> }
>
> +static int intel_user_framebuffer_dirty(struct drm_framebuffer *fb,
> + struct drm_file *file,
> + unsigned flags, unsigned color,
> + struct drm_clip_rect *clips,
> + unsigned num_clips)
We still have all those useless white spaces above. Only the tabs are
needed. I guess Daniel can remove these when applying the patch, so:
Reviewed-by: Paulo Zanoni
> +{
> + struct drm_device *dev = fb->dev;
> + struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
> + struct drm_i915_gem_object *obj = intel_fb->obj;
> +
> + mutex_lock(&dev->struct_mutex);
> + intel_fb_obj_flush(obj, false, ORIGIN_GTT);
> + mutex_unlock(&dev->struct_mutex);
> +
> + return 0;
> +}
> +
> static const struct drm_framebuffer_funcs intel_fb_funcs = {
> .destroy = intel_user_framebuffer_destroy,
> .create_handle = intel_user_framebuffer_create_handle,
> + .dirty = intel_user_framebuffer_dirty,
> };
>
> static
> --
> 2.1.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Snapshot seqno of most recently submitted request.
The hang checker needs to inspect whether or not the ring request list is empty
as well as if the given engine has reached or passed the most recently
submitted request. The problem with this is that the hang checker cannot grab
the struct_mutex, which is required in order to safely inspect requests since
requests might be deallocated during inspection. In the past we've had kernel
panics due to this very unsynchronized access in the hang checker.
One solution to this problem is to not inspect the requests directly since
we're only interested in the seqno of the most recently submitted request - not
the request itself. Instead the seqno of the most recently submitted request is
stored separately, which the hang checker then inspects, circumventing the
issue of synchronization from the hang checker entirely.
Issue: VIZ-5998
Signed-off-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/i915_irq.c | 14 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 7 +++
3 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a0bff41..971b439 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2549,6 +2549,7 @@ void __i915_add_request(struct drm_i915_gem_request
*request,
request->batch_obj = obj;
request->emitted_jiffies = jiffies;
+ ring->last_submitted_seqno = request->seqno;
list_add_tail(&request->list, &ring->request_list);
trace_i915_gem_request_add(request);
@@ -2784,6 +2785,7 @@ static void i915_gem_reset_ring_cleanup(struct
drm_i915_private *dev_priv,
i915_gem_request_retire(request);
}
+
}
void i915_gem_restore_fences(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a6fbe64..f291bb9 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2484,18 +2484,16 @@ static void gen8_disable_vblank(struct drm_device *dev,
int pipe)
spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
}
-static struct drm_i915_gem_request *
-ring_last_request(struct intel_engine_cs *ring)
-{
- return list_entry(ring->request_list.prev,
- struct drm_i915_gem_request, list);
-}
-
static bool
ring_idle(struct intel_engine_cs *ring)
{
+ u32 current_seqno;
+
+ current_seqno = ring->get_seqno(ring, false);
+
return (list_empty(&ring->request_list) ||
- i915_gem_request_completed(ring_last_request(ring), false));
+ i915_seqno_passed(current_seqno,
+ ring->last_submitted_seqno));
}
static bool
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 0ea89ea..2e85fda 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -292,6 +292,13 @@ struct intel_engine_cs {
*/
struct list_head request_list;
+ /**
+* Seqno of request most recently submitted to request_list.
+* Used exclusively by hang checker to avoid grabbing lock while
+* inspecting request list.
+*/
+ u32 last_submitted_seqno;
+
bool gpu_caches_dirty;
wait_queue_head_t irq_queue;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fbdev_set_par reliably invalidating frontbuffer
2015-07-08 20:24 GMT-03:00 Rodrigo Vivi : > fbdev_set_par is called when fbcon is taking over control. > In the past frontbuffer was being invalidated on > set_to_gtt_domain, but it moved to set_domain fixing that case, > but left this behind. > > Commit that changed this fixing set_domain case was: > > commit 031b698a77a70a6c394568034437b5486a44e868 > Author: Daniel Vetter > Date: Fri Jun 26 19:35:16 2015 +0200 > > drm/i915: Unconditionally do fb tracking invalidate in set_domain > > Since we are also invalidating in other fbdev cases this one > was masked here. At least until now that I found this corner > case: On boot with plymouth doing a splash screen > when returning to the console frontbuffer wans't being invalidated > causing missed screen updates with PSR enabled. > > So this patch fixes this issue. > > v2: Make invalidate directly and unconditionally and > fix commit message indicating the set_domain fix > as pointed out by Daniel. > > Cc: Daniel Vetter > Signed-off-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_fbdev.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c > b/drivers/gpu/drm/i915/intel_fbdev.c > index 2a1724e..44c9ccc 100644 > --- a/drivers/gpu/drm/i915/intel_fbdev.c > +++ b/drivers/gpu/drm/i915/intel_fbdev.c > @@ -63,8 +63,8 @@ static int intel_fbdev_set_par(struct fb_info *info) > * now until we solve this for real. > */ > mutex_lock(&fb_helper->dev->struct_mutex); > - ret = i915_gem_object_set_to_gtt_domain(ifbdev->fb->obj, > - true); > + if (ifbdev->fb->obj) I'm confused. Why are we doing this check now? If this is actually needed, then the current set_to_gtt_domain() call will blow up too. So this would be 2 different patches: one preventing the explosion, the other doing obj_invalidate. Unless we don't need the obj check. > + intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); > mutex_unlock(&fb_helper->dev->struct_mutex); > } > > -- > 2.1.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fbdev restore mode needs to invalidate frontbuffer
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6761 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 302/302 302/302 SNB 312/316 312/316 IVB 343/343 343/343 BYT -3 287/287 284/287 HSW 380/380 380/380 -Detailed- Platform Testdrm-intel-nightly Series Applied *BYT igt@gem_partial_pwrite_pread@reads PASS(1) FAIL(1) *BYT igt@gem_persistent_relocs@normal PASS(1) FAIL(1) *BYT igt@gem_tiled_partial_pwrite_pread@reads PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/15] drm/i915: CHV DPIO power gating, take two
On Thursday 09 July 2015 02:15 AM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä Here's the new version of the CHV DPIO powergating feature. In short, it allows us to power off unused lanes in the display PHY. So should save some power when stuff is either disabled, or when running DP links with less than four lanes. My previous attempt [1] failed to actually enable the dynamic powerdown bits in the PHY, which meant it basically did nothing. Actually setting those bits has a pretty big effect on the hardware as CMN/TX/PCS registers stop working in powered down lanes. So dealing with that fact, and several nasty corner cases makes things a bit tricky in places. The series depends on my earlier DP pipe config cleanup [2] since we now depend on knowing which lanes are actually powered on when enabling/disabling DP ports. The entire thing is availabe from my github repo [3] where it's sitting on a few other patches, including my earlier DPLL cleanup series [4]. However there should be no real dependency on this other stuff apart from the already mentioned DP pipe config patches (which are also included in the branch). Deepak, perchance you would be willing to review this since you already reviwed my first attempt (and shot it full of holes)? Sure. I will review the patches :) Oh, and the first two patches aren't really about DPIO powergating. But I wanted to get them out and one of them does touch the same code so I figured I'd sneak them in. [1] http://lists.freedesktop.org/archives/intel-gfx/2015-April/064403.html [2] http://lists.freedesktop.org/archives/intel-gfx/2015-July/070780.html [3] git://github.com/vsyrjala/linux.git chv_dpio_powergating_4 [4] http://lists.freedesktop.org/archives/intel-gfx/2015-June/070036.html Ville Syrjälä (15): drm/i915: Always program m2 fractional value on CHV drm/i915: Always program unique transition scale for CHV drm/i915: Add encoder->post_pll_disable() hooks and move CHV clock buffer disables there drm/i915: Move DPIO port init earlier drm/i915: Add locking around chv_phy_control_init() drm/i915: Move VLV/CHV prepare_pll later drm/i915: Add vlv_dport_to_phy() drm/i915: Implement PHY lane power gating for CHV drm/i915: Trick CL2 into life on CHV when using pipe B with port B drm/i915: Force common lane on for the PPS kick on CHV drm/i915: Enable DPIO SUS clock gating on CHV drm/i915: Force CL2 off in CHV x1 PHY drm/i915: Clean up CHV lane soft reset programming drm/i915: Add some CHV DPIO lane power state asserts drm/i915: Add CHV PHY LDO power sanity checks drivers/gpu/drm/i915/i915_dma.c | 20 ++ drivers/gpu/drm/i915/i915_reg.h | 23 +++ drivers/gpu/drm/i915/intel_display.c| 54 + drivers/gpu/drm/i915/intel_dp.c | 315 +++-- drivers/gpu/drm/i915/intel_drv.h| 26 ++- drivers/gpu/drm/i915/intel_hdmi.c | 171 +++- drivers/gpu/drm/i915/intel_runtime_pm.c | 344 +--- 7 files changed, 721 insertions(+), 232 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave, Pile of fixes for either 4.2 issues or cc: stable. This should fix the 2nd kind of WARNING Linus's been seeing, please ask him to scream if that's not the case. Cheers, Daniel The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754: Linux 4.2-rc1 (2015-07-05 11:01:52 -0700) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/drm-intel-fixes-2015-07-09 for you to fetch changes up to 52613921b31d8573a212a4b0854b390a18d9849c: Revert "drm/i915: Allocate context objects from stolen" (2015-07-09 09:40:16 +0200) Chris Wilson (1): drm/i915: Declare the swizzling unknown for L-shaped configurations Daniel Vetter (2): drm/i915: Check crtc->active in intel_crtc_disable_planes drm/i915: Use crtc_state->active in primary check_plane func Imre Deak (1): drm/i915/chv: fix HW readout of the port PLL fractional divider Tvrtko Ursulin (1): drm/i915: Restore all GGTT VMAs on resume Ville Syrjälä (1): Revert "drm/i915: Allocate context objects from stolen" drivers/gpu/drm/i915/i915_gem_context.c | 4 +--- drivers/gpu/drm/i915/i915_gem_gtt.c | 23 --- drivers/gpu/drm/i915/i915_gem_tiling.c | 12 +++- drivers/gpu/drm/i915/intel_display.c| 12 +--- 4 files changed, 37 insertions(+), 14 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] topic/drm-fixes for 4.2
Hi Dave, Non-i915 fixes I picked up in your absence: kerneldoc + 2x cc: stable. The rockchip fix is just in here to make sure it won't get lost, I kept it since I didn't yet see a rockchip fixes pull nor confirmation from Mark that he pulled it into his tree. Cheers, Daniel The following changes since commit e24ff467e12e1560de753313976c46e84fa6306a: drm/crtc: Fix edid length computation (2015-07-04 00:52:34 +0200) are available in the git repository at: git://anongit.freedesktop.org/drm-intel tags/topic/drm-fixes-2015-07-09 for you to fetch changes up to d4acc1651588835b802a2049f4f3a2adcc1af750: Documentation: drm: Fix tablulation in KMS properties table (2015-07-07 22:42:58 +0200) Daniel Kurtz (1): drm/rockchip: use drm_gem_mmap helpers Graham Whaley (1): Documentation: drm: Fix tablulation in KMS properties table Zhao Junwang (1): drm: add a check for x/y in drm_mode_setcrtc Documentation/DocBook/drm.tmpl | 2 +- drivers/gpu/drm/drm_crtc.c | 7 ++- drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 67 +++-- 3 files changed, 40 insertions(+), 36 deletions(-) -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Snapshot seqno of most recently submitted request.
The hang checker needs to inspect whether or not the ring request list is empty
as well as if the given engine has reached or passed the most recently
submitted request. The problem with this is that the hang checker cannot grab
the struct_mutex, which is required in order to safely inspect requests since
requests might be deallocated during inspection. In the past we've had kernel
panics due to this very unsynchronized access in the hang checker.
One solution to this problem is to not inspect the requests directly since
we're only interested in the seqno of the most recently submitted request - not
the request itself. Instead the seqno of the most recently submitted request is
stored separately, which the hang checker then inspects, circumventing the
issue of synchronization from the hang checker entirely.
v2 (Chris Wilson):
- Pass current engine seqno to ring_idle() from i915_hangcheck_elapsed() rather
than compute it over again.
- Remove extra whitespace.
Issue: VIZ-5998
Signed-off-by: Tomas Elf
---
drivers/gpu/drm/i915/i915_gem.c | 1 +
drivers/gpu/drm/i915/i915_irq.c | 13 +++--
drivers/gpu/drm/i915/intel_ringbuffer.h | 7 +++
3 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a0bff41..a871be4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2549,6 +2549,7 @@ void __i915_add_request(struct drm_i915_gem_request
*request,
request->batch_obj = obj;
request->emitted_jiffies = jiffies;
+ ring->last_submitted_seqno = request->seqno;
list_add_tail(&request->list, &ring->request_list);
trace_i915_gem_request_add(request);
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index a6fbe64..0d0741f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2484,18 +2484,11 @@ static void gen8_disable_vblank(struct drm_device *dev,
int pipe)
spin_unlock_irqrestore(&dev_priv->irq_lock, irqflags);
}
-static struct drm_i915_gem_request *
-ring_last_request(struct intel_engine_cs *ring)
-{
- return list_entry(ring->request_list.prev,
- struct drm_i915_gem_request, list);
-}
-
static bool
-ring_idle(struct intel_engine_cs *ring)
+ring_idle(struct intel_engine_cs *ring, u32 seqno)
{
return (list_empty(&ring->request_list) ||
- i915_gem_request_completed(ring_last_request(ring), false));
+ i915_seqno_passed(seqno, ring->last_submitted_seqno));
}
static bool
@@ -2717,7 +2710,7 @@ static void i915_hangcheck_elapsed(struct work_struct
*work)
acthd = intel_ring_get_active_head(ring);
if (ring->hangcheck.seqno == seqno) {
- if (ring_idle(ring)) {
+ if (ring_idle(ring, seqno)) {
ring->hangcheck.action = HANGCHECK_IDLE;
if (waitqueue_active(&ring->irq_queue)) {
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 0ea89ea..2e85fda 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -292,6 +292,13 @@ struct intel_engine_cs {
*/
struct list_head request_list;
+ /**
+* Seqno of request most recently submitted to request_list.
+* Used exclusively by hang checker to avoid grabbing lock while
+* inspecting request list.
+*/
+ u32 last_submitted_seqno;
+
bool gpu_caches_dirty;
wait_queue_head_t irq_queue;
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Snapshot seqno of most recently submitted request.
On Thu, Jul 09, 2015 at 03:30:57PM +0100, Tomas Elf wrote: > The hang checker needs to inspect whether or not the ring request list is > empty > as well as if the given engine has reached or passed the most recently > submitted request. The problem with this is that the hang checker cannot grab > the struct_mutex, which is required in order to safely inspect requests since > requests might be deallocated during inspection. In the past we've had kernel > panics due to this very unsynchronized access in the hang checker. > > One solution to this problem is to not inspect the requests directly since > we're only interested in the seqno of the most recently submitted request - > not > the request itself. Instead the seqno of the most recently submitted request > is > stored separately, which the hang checker then inspects, circumventing the > issue of synchronization from the hang checker entirely. > > v2 (Chris Wilson): > - Pass current engine seqno to ring_idle() from i915_hangcheck_elapsed() > rather > than compute it over again. > - Remove extra whitespace. > > Issue: VIZ-5998 > Signed-off-by: Tomas Elf Yup, that is a nice simple fix by partially reverting the s/seqno/requests/ change (and improving upon it in the process). We should mention Fixes commit 44cdd6d219bc64f6810b8ed0023a4d4db9e0fe68 Author: John Harrison Date: Mon Nov 24 18:49:40 2014 + drm/i915: Convert 'ring_idle()' to use requests not seqnos and Cc: sta...@vger.kernel.org Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Store device pointer in contexts for late tracepoint usafe
On Thu, Jul 09, 2015 at 10:41:36AM +0100, Ceraolo Spurio, Daniele wrote:
> On 29/06/2015 12:49, Jani Nikula wrote:
> >On Mon, 29 Jun 2015, Chris Wilson wrote:
> >>On Mon, Jun 29, 2015 at 02:40:15PM +0300, Jani Nikula wrote:
> >>>On Thu, 07 May 2015, Chris Wilson wrote:
> On Wed, May 06, 2015 at 01:16:30PM +0200, Daniel Vetter wrote:
> >On Tue, May 05, 2015 at 09:17:29AM +0100, Chris Wilson wrote:
> >>[ 1572.417121] BUG: unable to handle kernel NULL pointer dereference at
> >> (null)
> >>[ 1572.421010] IP: []
> >>ftrace_raw_event_i915_context+0x5d/0x70 [i915]
> >>[ 1572.424970] PGD 1766a3067 PUD 1767a2067 PMD 0
> >>[ 1572.428892] Oops: [#1] SMP
> >>[ 1572.432787] Modules linked in: ipv6 dm_mod iTCO_wdt
> >>iTCO_vendor_support snd_hda_codec_realtek snd_hda_codec_generic
> >>snd_hda_intel snd_hda_controller snd_hda_codec snd_hda_core snd_hwdep
> >>snd_pcm snd_timer snd soundcore serio_raw pcspkr lpc_ich i2c_i801
> >>mfd_core battery ac acpi_cpufreq i915 button video drm_kms_helper drm
> >>[ 1572.441720] CPU: 2 PID: 18853 Comm: kworker/u8:0 Not tainted
> >>4.0.0_kcloud_3f0360_20150429+ #588
> >>[ 1572.446298] Workqueue: i915 i915_gem_retire_work_handler [i915]
> >>[ 1572.450876] task: 880002f428f0 ti: 880035724000 task.ti:
> >>880035724000
> >>[ 1572.47] RIP: 0010:[] []
> >>ftrace_raw_event_i915_context+0x5d/0x70 [i915]
> >>[ 1572.460423] RSP: 0018:880035727ce8 EFLAGS: 00010286
> >>[ 1572.465262] RAX: 880073f1643c RBX: 880002da9058 RCX:
> >>880073e5db40
> >>[ 1572.470179] RDX: RSI: RDI:
> >>880035727ce8
> >>[ 1572.475107] RBP: 88007bb11a00 R08: R09:
> >>
> >>[ 1572.480034] R10: 00362200 R11: 0008 R12:
> >>
> >>[ 1572.484952] R13: 880035727d78 R14: 880002dc1c98 R15:
> >>880002dc1dc8
> >>[ 1572.489886] FS: () GS:88017fd0()
> >>knlGS:
> >>[ 1572.494883] CS: 0010 DS: ES: CR0: 8005003b
> >>[ 1572.499859] CR2: CR3: 00017572a000 CR4:
> >>001006e0
> >>[ 1572.504842] Stack:
> >>[ 1572.509834] 88017b0090c0 880073f16438 880002da9058
> >>880073f1643c
> >>[ 1572.514904] 0246 8801 88007bb11a00
> >>880002ddeb10
> >>[ 1572.519985] 8801759f79c0 a0092ff0
> >>88007bb11a00
> >>[ 1572.525049] Call Trace:
> >>[ 1572.530093] [] ? i915_gem_context_free+0xa8/0xc1
> >>[i915]
> >>[ 1572.535227] [] ? i915_gem_request_free+0x4e/0x50
> >>[i915]
> >>[ 1572.540347] [] ?
> >>intel_execlists_retire_requests+0x14c/0x159 [i915]
> >>[ 1572.545500] [] ?
> >>i915_gem_retire_requests+0x9d/0xeb [i915]
> >>[ 1572.550664] [] ?
> >>i915_gem_retire_work_handler+0x4c/0x61 [i915]
> >>[ 1572.555825] [] ? process_one_work+0x1b2/0x31d
> >>[ 1572.560951] [] ? worker_thread+0x24d/0x339
> >>[ 1572.566033] [] ? cancel_delayed_work_sync+0xa/0xa
> >>[ 1572.571140] [] ? kthread+0xce/0xd6
> >>[ 1572.576191] [] ?
> >>kthread_create_on_node+0x162/0x162
> >>[ 1572.581228] [] ? ret_from_fork+0x58/0x90
> >>[ 1572.586259] [] ?
> >>kthread_create_on_node+0x162/0x162
> >>[ 1572.591318] Code: de 48 89 e7 e8 09 4d 00 e1 48 85 c0 74 27 48 89 68
> >>10 48 8b 55 38 48 89 e7 48 89 50 18 48 8b 55 10 48 8b 12 48 8b 12 48 8b
> >>52 38 <8b> 12 89 50 08 e8 95 4d 00 e1 48 83 c4 30 5b 5d 41 5c c3 41 55
> >>[ 1572.596981] RIP []
> >>ftrace_raw_event_i915_context+0x5d/0x70 [i915]
> >>[ 1572.602464] RSP
> >>[ 1572.607911] CR2:
> >>
> >>Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90112#c23
> >>Signed-off-by: Chris Wilson
> >
> >Could we do an igt for this, maybe using the sysfs trace interface?
>
> I wonder if it is as simple as:
>
> tracefs=/sys/kernel/tracing
>
> function set_tracing {
> for i in `find $tracefs/i915 -name enable`; do $i
> echo $1 > $i
> done
> echo $1 > $tracefs/enable
> }
>
> set_tracing 1
>
> ./gem_ctx_basic
> ./gem_foo_basic
> ./gem_bar_basic
> ./gem_baz_basic
>
> set_tracing 0
> >>>
> >>>Is the patch still valid?
> >>
> >>Yes.
> >
> >I could use some review here
>
> I had to rebase the patch to apply it, but apart from that:
> Tested-by: Daniele Ceraolo Spurio
> Reviewed-by: Daniele Ceraolo Spurio
Merged to -fixes, thanks.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listi
Re: [Intel-gfx] [PATCH] drm/i915: dirty fb operation flushsing frontbuffer
On Thu, Jul 09, 2015 at 10:04:20AM -0300, Paulo Zanoni wrote:
> 2015-07-08 20:22 GMT-03:00 Rodrigo Vivi :
> > Let's do a frontbuffer flush on dirty fb.
> > To be used for DIRTYFB drm ioctl.
> >
> > This patch solves the biggest PSR known issue, that is
> > missed screen updates during boot, mainly when there is a splash
> > screen involved like Plymouth.
> >
> > Previously PSR was being invalidated by fbdev and Plymounth
> > was taking control with PSR yet invalidated and could get screen
> > updates normally. However with some atomic modeset changes
> > Pymouth modeset over ioctl was now causing frontbuffer flushes
> > making PSR gets back to work while it cannot track the
> > screen updates and exit properly.
> >
> > By adding this flush on dirtyfb we properly track frontbuffer
> > writes and properly exit PSR.
> >
> > Actually all mmap_wc users should call this dirty callback
> > in order to have a proper frontbuffer tracking.
> >
> > In the future it can be extended to return 0 if the whole
> > screen has being flushed or the number of rects flushed
> > as Chris suggested.
> >
> > v2: Remove ORIGIN_FB_DIRTY and use ORIGIN_GTT instead since dirty
> > callback is just called after few screen updates and not on
> > everyone as pointed by Daniel.
> >
> > v3: Use flush instead of invalidate since flush means
> > invalidate + flush and dirty means drawn had finished and
> > it can be flushed.
> >
> > v4: Remove PSR from subject since it is purely frontbuffer tracking
> > change and that can be useful for FBC as well.
> >
> > Cc: Chris Wilson
> > Cc: Paulo Zanoni
> > Cc: Daniel Vetter
> > Signed-off-by: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 18 ++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 0efa455..1d67958 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14388,9 +14388,27 @@ static int
> > intel_user_framebuffer_create_handle(struct drm_framebuffer *fb,
> > return drm_gem_handle_create(file, &obj->base, handle);
> > }
> >
> > +static int intel_user_framebuffer_dirty(struct drm_framebuffer *fb,
> > + struct drm_file *file,
> > + unsigned flags, unsigned
> > color,
> > + struct drm_clip_rect *clips,
> > + unsigned num_clips)
>
> We still have all those useless white spaces above. Only the tabs are
> needed. I guess Daniel can remove these when applying the patch, so:
> Reviewed-by: Paulo Zanoni
Merged patches 2&3 from this series, thanks.
-Daniel
>
> > +{
> > + struct drm_device *dev = fb->dev;
> > + struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
> > + struct drm_i915_gem_object *obj = intel_fb->obj;
> > +
> > + mutex_lock(&dev->struct_mutex);
> > + intel_fb_obj_flush(obj, false, ORIGIN_GTT);
> > + mutex_unlock(&dev->struct_mutex);
> > +
> > + return 0;
> > +}
> > +
> > static const struct drm_framebuffer_funcs intel_fb_funcs = {
> > .destroy = intel_user_framebuffer_destroy,
> > .create_handle = intel_user_framebuffer_create_handle,
> > + .dirty = intel_user_framebuffer_dirty,
> > };
> >
> > static
> > --
> > 2.1.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Paulo Zanoni
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915: fbdev restore mode needs to invalidate frontbuffer
On Wed, Jul 08, 2015 at 03:05:49PM -0300, Paulo Zanoni wrote: > 2015-07-07 20:28 GMT-03:00 Rodrigo Vivi : > > This fbdev restore mode was another corner case that was now > > calling frontbuffer flip and flush and making we miss > > screen updates with PSR enabled. > > > > So let's also add the invalidate hack here while we don't have > > a reliable dirty fbdev op. > > So when I saw patches 6 and 7 I decided to investigate how fbcon > interacts with frontbuffer tracking. One thing that I notice is that, > without this patch, if I kill the display manager, I'll have a bunch > of flushes without an invalidate when returning to fbcon. And I > suppose we don't want PSR/FBC enabled on fbcon, so this patch seems to > fix a bug. > > By the way, I think we can try to simulate this "kill display manager" > bug on IGT. We could try to close the DRM device and then check if > FBC/PSR stopped. I guess it's probably easier to create a new IGT test > for that. Hm yeah that would be a nice testcase indeed. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Set edid from detect only if forced
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 6762 -Summary- Platform Delta drm-intel-nightly Series Applied ILK 302/302 302/302 SNB 312/316 312/316 IVB 343/343 343/343 BYT -1 287/287 286/287 HSW 380/380 380/380 -Detailed- Platform Testdrm-intel-nightly Series Applied *BYT igt@gem_partial_pwrite_pread@reads-display PASS(1) FAIL(1) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCHv7] drm/i915: Added Programming of the MOCS
"Siluvery, Arun" writes:
> On 07/07/2015 20:13, Francisco Jerez wrote:
>> From: Peter Antoine
>>
>> This change adds the programming of the MOCS registers to the gen 9+
>> platforms. This change set programs the MOCS register values to a set
>> of values that are defined to be optimal.
>>
>> It creates a fixed register set that is programmed across the different
>> engines so that all engines have the same table. This is done as the
>> main RCS context only holds the registers for itself and the shared
>> L3 values. By trying to keep the registers consistent across the
>> different engines it should make the programming for the registers
>> consistent.
>>
>> v2:
>> -'static const' for private data structures and style changes.(Matt Turner)
>> v3:
>> - Make the tables "slightly" more readable. (Damien Lespiau)
>> - Updated tables fix performance regression.
>> v4:
>> - Code formatting. (Chris Wilson)
>> - re-privatised mocs code. (Daniel Vetter)
>> v5:
>> - Changed the name of a function. (Chris Wilson)
>> v6:
>> - re-based
>> - Added Mesa table entry (skylake & broxton) (Francisco Jerez)
>> - Tidied up the readability defines (Francisco Jerez)
>> - NUMBER of entries defines wrong. (Jim Bish)
>> - Added comments to clear up the meaning of the tables (Jim Bish)
>>
>> Signed-off-by: Peter Antoine
>>
>> v7 (Francisco Jerez):
>> - Don't write L3-specific MOCS_ESC/SCC values into the e/LLC control
>>tables. Prefix L3-specific defines consistently with L3_ and
>>e/LLC-specific defines with LE_ to avoid this kind of confusion in
>>the future.
>> - Change L3CC WT define back to RESERVED (matches my hardware
>>documentation and the original patch, probably a misunderstanding
>>of my own previous comment).
>> - Drop Android tables, define new minimal tables more suitable for the
>>open source stack.
>> - Add comment that the MOCS tables are part of the kernel ABI.
>> - Move intel_logical_ring_begin() and _advance() calls one level down
>>(Chris Wilson).
>> - Minor formatting and style fixes.
>>
>> Signed-off-by: Francisco Jerez
>> ---
>> drivers/gpu/drm/i915/Makefile | 1 +
>> drivers/gpu/drm/i915/i915_reg.h | 9 ++
>> drivers/gpu/drm/i915/intel_lrc.c | 11 +-
>> drivers/gpu/drm/i915/intel_lrc.h | 1 +
>> drivers/gpu/drm/i915/intel_mocs.c | 324
>> ++
>> drivers/gpu/drm/i915/intel_mocs.h | 57 +++
>> 6 files changed, 401 insertions(+), 2 deletions(-)
>> create mode 100644 drivers/gpu/drm/i915/intel_mocs.c
>> create mode 100644 drivers/gpu/drm/i915/intel_mocs.h
>>
>> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
>> index de21965..e52e012 100644
>> --- a/drivers/gpu/drm/i915/Makefile
>> +++ b/drivers/gpu/drm/i915/Makefile
>> @@ -36,6 +36,7 @@ i915-y += i915_cmd_parser.o \
>>i915_trace_points.o \
>>intel_hotplug.o \
>>intel_lrc.o \
>> + intel_mocs.o \
>>intel_ringbuffer.o \
>>intel_uncore.o
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index 2a29bcc..9b17260 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -7906,4 +7906,13 @@ enum skl_disp_power_wells {
>> #define _PALETTE_A (dev_priv->info.display_mmio_offset + 0xa000)
>> #define _PALETTE_B (dev_priv->info.display_mmio_offset + 0xa800)
>>
>> +/* MOCS (Memory Object Control State) registers */
>> +#define GEN9_LNCFCMOCS0 (0xB020)/* L3 Cache Control
>> base */
>> +
>> +#define GEN9_GFX_MOCS_0 (0xc800)/* Graphics MOCS base
>> register*/
>> +#define GEN9_MFX0_MOCS_0(0xc900)/* Media 0 MOCS base register*/
>> +#define GEN9_MFX1_MOCS_0(0xcA00)/* Media 1 MOCS base register*/
>> +#define GEN9_VEBOX_MOCS_0 (0xcB00)/* Video MOCS base register*/
>> +#define GEN9_BLT_MOCS_0 (0xcc00)/* Blitter MOCS base
>> register*/
>> +
>> #endif /* _I915_REG_H_ */
>> diff --git a/drivers/gpu/drm/i915/intel_lrc.c
>> b/drivers/gpu/drm/i915/intel_lrc.c
>> index d4f8b43..466d17c 100644
>> --- a/drivers/gpu/drm/i915/intel_lrc.c
>> +++ b/drivers/gpu/drm/i915/intel_lrc.c
>> @@ -135,6 +135,7 @@
>> #include
>> #include
>> #include "i915_drv.h"
>> +#include "intel_mocs.h"
>>
>> #define GEN9_LR_CONTEXT_RENDER_SIZE (22 * PAGE_SIZE)
>> #define GEN8_LR_CONTEXT_RENDER_SIZE (20 * PAGE_SIZE)
>> @@ -772,8 +773,7 @@ static int logical_ring_prepare(struct
>> drm_i915_gem_request *req, int bytes)
>>*
>>* Return: non-zero if the ringbuffer is not ready to be written to.
>>*/
>> -static int intel_logical_ring_begin(struct drm_i915_gem_request *req,
>> -int num_dwords)
>> +int intel_logical_ring_begin(struct drm_i915_gem_request *req, int
>> num_dwords)
>> {
>> struct drm_i915_private *dev_priv;
>> int ret;
>> @@ -1675,6 +1675,13 @@ static int gen8_init_rcs_context(struct
>> drm_i915_
Re: [Intel-gfx] [PATCH v2] drm/i915: Snapshot seqno of most recently submitted request.
On Thu, Jul 09, 2015 at 04:07:05PM +0100, Chris Wilson wrote: > On Thu, Jul 09, 2015 at 03:30:57PM +0100, Tomas Elf wrote: > > The hang checker needs to inspect whether or not the ring request list is > > empty > > as well as if the given engine has reached or passed the most recently > > submitted request. The problem with this is that the hang checker cannot > > grab > > the struct_mutex, which is required in order to safely inspect requests > > since > > requests might be deallocated during inspection. In the past we've had > > kernel > > panics due to this very unsynchronized access in the hang checker. > > > > One solution to this problem is to not inspect the requests directly since > > we're only interested in the seqno of the most recently submitted request - > > not > > the request itself. Instead the seqno of the most recently submitted > > request is > > stored separately, which the hang checker then inspects, circumventing the > > issue of synchronization from the hang checker entirely. > > > > v2 (Chris Wilson): > > - Pass current engine seqno to ring_idle() from i915_hangcheck_elapsed() > > rather > > than compute it over again. > > - Remove extra whitespace. > > > > Issue: VIZ-5998 > > Signed-off-by: Tomas Elf > > Yup, that is a nice simple fix by partially reverting the > s/seqno/requests/ change (and improving upon it in the process). > > We should mention > > Fixes commit 44cdd6d219bc64f6810b8ed0023a4d4db9e0fe68 > Author: John Harrison > Date: Mon Nov 24 18:49:40 2014 + > > drm/i915: Convert 'ring_idle()' to use requests not seqnos > > and > Cc: sta...@vger.kernel.org > Reviewed-by: Chris Wilson Added and applied to -fixes, thanks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: storm detection documentation update
On Thu, Jul 09, 2015 at 06:22:01PM +0530, Sivakumar Thulasimani wrote: > > > On 7/8/2015 8:50 PM, Daniel Vetter wrote: > >On Wed, Jul 08, 2015 at 06:54:06PM +0530, Sivakumar Thulasimani wrote: > >> > >>On 7/7/2015 5:01 PM, Daniel Vetter wrote: > >>>On Tue, Jul 07, 2015 at 04:10:49PM +0530, Sivakumar Thulasimani wrote: > From: "Thulasimani,Sivakumar" > > Update the hotplug documentation to explain that hotplug storm > is not expected for Display port panels and hence is not handled > in current code. > > Signed-off-by: Sivakumar Thulasimani > --- > drivers/gpu/drm/i915/intel_hotplug.c |4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c > b/drivers/gpu/drm/i915/intel_hotplug.c > index bac91a1..7dc5e6a 100644 > --- a/drivers/gpu/drm/i915/intel_hotplug.c > +++ b/drivers/gpu/drm/i915/intel_hotplug.c > @@ -66,6 +66,10 @@ > * while before being re-enabled. The intention is to mitigate issues > raising > * from broken hardware triggering massive amounts of interrupts and > grinding > * the system to a halt. > + * > + * Hotplug interrupt storm is not expected on Display port panel, hence > the > + * current code only handles disabling and later enabling of HPD > interrupts > + * for HDMI panels through the storm handling set of functions. > >>>This isn't accurate, we handle storms on everything _but_ DP (tv, vga, > >>>sdvo, ...). I'd go with > >>> > >>> * Hotplug interrupt storm is not expected on Display port panel, hence > >>> the > >>> * current code doesn't handle irq reenabling when a DP sink is connected > >>> * and the hpd is handled by the DP callbacks. But on DP+ ports > >>> * storms are still handled correctly in all other cases (e.g. due to HDMI > >>> * sinks). > >>> > >>>Could still be improved I think. > >>> > >>>-Daniel > >>> > >>Sorry i don't get the "DP+" reference here. By DP+, do you mean dongles ? > >>passive dongles will report them selves as HDMI to respective detect > >>routines > >>active dongles will be still treated as DP hence not handling HPD will apply > >>to any > >>display connected through active dongle as well. > >DP+ is DP with support for HDMI with level shifter cables (i.e. all the > >ports on intel chips). I just wanted to make it clear that storm handling > >doesn't work if we have a confirmed DP sink on the port, but will work in > >any other cases (nothing or HDMI sink or DVI or whatever connected). Like > >I said some room for improvement ;-) > >-Daniel > how about the following ? > > * current implementation expects that hotplug interrupt storm will not be s/current/Current/ > * seen when display port sink is connected, hence on platforms whose DP > * callback is handled by i915_digport_work_func reenabling of hpd is not > * performed ( it was never expected to be disabled in the first place ;) ) > * this is specific to DP sinks handled by this routine and any other display > * such as HDMI or DVI enabled on the same port will have proper logic since > * it will use i915_hotplug_work_func where this logic is handled. lgtm. -Daniel > > please provide any corrections or new comment to be used, i'll upload a new > patch with > the final approved text block. > > -- > regards, > Sivakumar > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 17/18] drm/i915: Wa32bitGeneralStateOffset & Wa32bitInstructionBaseOffset
On 7/7/2015 4:15 PM, Michel Thierry wrote:
There are some allocations that must be only referenced by 32-bit
offsets. To limit the chances of having the first 4GB already full,
objects not requiring this workaround use DRM_MM_SEARCH_BELOW/
DRM_MM_CREATE_TOP flags
In specific, any resource used with flat/heapless (0x-0xf000)
General State Heap (GSH) or Intructions State Heap (ISH) must be in a
32-bit range, because the General State Offset and Instruction State
Offset are limited to 32-bits.
Objects must have EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag to indicate if
they can be allocated above the 32-bit address range. To limit the
chances of having the first 4GB already full, objects will use
DRM_MM_SEARCH_BELOW + DRM_MM_CREATE_TOP flags when possible.
v2: Changed flag logic from neeeds_32b, to supports_48b.
v3: Moved 48-bit support flag back to exec_object. (Chris, Daniel)
v4: Split pin flags into PIN_ZONE_4G and PIN_HIGH; update PIN_OFFSET_MASK
to use last PIN_ defined instead of hard-coded value; use correct limit
check in eb_vma_misplaced. (Chris)
v5: Don't touch PIN_OFFSET_MASK and update workaround comment (Chris)
Cc: Chris Wilson
Reviewed-by: Chris Wilson (v4)
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_drv.h| 2 ++
drivers/gpu/drm/i915/i915_gem.c| 14 --
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 13 +
include/uapi/drm/i915_drm.h| 3 ++-
4 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4a30a73..fc88e58 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2772,6 +2772,8 @@ void i915_gem_vma_destroy(struct i915_vma *vma);
#define PIN_OFFSET_BIAS(1<<3)
#define PIN_USER (1<<4)
#define PIN_UPDATE (1<<5)
+#define PIN_ZONE_4G(1<<6)
+#define PIN_HIGH (1<<7)
#define PIN_OFFSET_MASK (~4095)
int __must_check
i915_gem_object_pin(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ebfb789..b13900d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3720,6 +3720,8 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
*obj,
struct drm_i915_private *dev_priv = dev->dev_private;
u32 fence_alignment, unfenced_alignment;
u64 size, fence_size;
+ u32 search_flag = DRM_MM_SEARCH_DEFAULT;
+ u32 alloc_flag = DRM_MM_CREATE_DEFAULT;
u64 start =
flags & PIN_OFFSET_BIAS ? flags & PIN_OFFSET_MASK : 0;
u64 end =
@@ -3761,6 +3763,14 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object
*obj,
obj->tiling_mode,
false);
size = flags & PIN_MAPPABLE ? fence_size : obj->base.size;
+
+ if (flags & PIN_HIGH) {
+ search_flag = DRM_MM_SEARCH_BELOW;
+ alloc_flag = DRM_MM_CREATE_TOP;
+ }
+
+ if (flags & PIN_ZONE_4G)
+ end = (1ULL << 32);
Hi Chris,
second thoughts on this... would PIN_HIGH & PIN_ZONE_4G be a problem if
someone mixes a 64-bit kernel with 32-bit userland?
Maybe it's safer to set end = (1ULL << 32) - PAGE_SIZE.
}
if (alignment == 0)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/15] drm/i915: Clean up CHV lane soft reset programming
On Wed, Jul 08, 2015 at 11:45:59PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Currently we relesar the lane soft reset before lane stagger settings
release
> have been programmed. I believe that means we don't actually do lane
> staggering. So move the soft reset deassert to happen after lane
> staggering has been programmed.
>
> The one confusing thing in this is that when we remove the power down
> override from the lanes, they power up with defaul register values,
> which do not have the soft reset overrides enabled. And according to
> some docs by default the data lane resets are tied to cmnreset. So that
> would mean that lanes would come out of reset without staggering as
> soon as the power down overrides are removed. But sine we can't access
> either the lane stagger register nor the soft reset override registers
> until the lanes are powered on, we can really do anything about it.
can't?
> So let's just set the soft reset overrides as soon as the lane is
> powered on and hope for the best.
Fun story in these patches ...
-Daniel
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_dp.c | 91
> +--
> drivers/gpu/drm/i915/intel_hdmi.c | 91
> ++-
> 2 files changed, 100 insertions(+), 82 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 817df87..297bd14 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -2389,42 +2389,62 @@ static void vlv_post_disable_dp(struct intel_encoder
> *encoder)
> intel_dp_link_down(intel_dp);
> }
>
> -static void chv_post_disable_dp(struct intel_encoder *encoder)
> +static void chv_data_lane_soft_reset(struct intel_encoder *encoder,
> + bool reset)
> {
> - struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> - struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
> - struct drm_device *dev = encoder->base.dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - struct intel_crtc *intel_crtc =
> - to_intel_crtc(encoder->base.crtc);
> - enum dpio_channel ch = vlv_dport_to_channel(dport);
> - enum pipe pipe = intel_crtc->pipe;
> - u32 val;
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + enum dpio_channel ch =
> vlv_dport_to_channel(enc_to_dig_port(&encoder->base));
> + struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
> + enum pipe pipe = crtc->pipe;
> + uint32_t val;
>
> - intel_dp_link_down(intel_dp);
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
> + if (reset)
> + val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
> + else
> + val |= DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
>
> - mutex_lock(&dev_priv->sb_lock);
> + if (crtc->config->lane_count > 2) {
> + val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
> + if (reset)
> + val &= ~(DPIO_PCS_TX_LANE2_RESET |
> DPIO_PCS_TX_LANE1_RESET);
> + else
> + val |= DPIO_PCS_TX_LANE2_RESET |
> DPIO_PCS_TX_LANE1_RESET;
> + vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
> + }
>
> - /* Propagate soft reset to data lane reset */
> val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
> val |= CHV_PCS_REQ_SOFTRESET_EN;
> + if (reset)
> + val &= ~DPIO_PCS_CLK_SOFT_RESET;
> + else
> + val |= DPIO_PCS_CLK_SOFT_RESET;
> vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW1(ch), val);
>
> - if (intel_crtc->config->lane_count > 2) {
> + if (crtc->config->lane_count > 2) {
> val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW1(ch));
> val |= CHV_PCS_REQ_SOFTRESET_EN;
> + if (reset)
> + val &= ~DPIO_PCS_CLK_SOFT_RESET;
> + else
> + val |= DPIO_PCS_CLK_SOFT_RESET;
> vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW1(ch), val);
> }
> +}
>
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
> - val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
> - vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
> +static void chv_post_disable_dp(struct intel_encoder *encoder)
> +{
> + struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
> + struct drm_device *dev = encoder->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
>
> - if (intel_crtc->config->lane_count > 2) {
> - val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
> - val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
> - vlv
Re: [Intel-gfx] [PATCH] drm/i915: fbdev_set_par reliably invalidating frontbuffer
On Thu, 2015-07-09 at 10:10 -0300, Paulo Zanoni wrote: > 2015-07-08 20:24 GMT-03:00 Rodrigo Vivi : > > fbdev_set_par is called when fbcon is taking over control. > > In the past frontbuffer was being invalidated on > > set_to_gtt_domain, but it moved to set_domain fixing that case, > > but left this behind. > > > > Commit that changed this fixing set_domain case was: > > > > commit 031b698a77a70a6c394568034437b5486a44e868 > > Author: Daniel Vetter > > Date: Fri Jun 26 19:35:16 2015 +0200 > > > > drm/i915: Unconditionally do fb tracking invalidate in set_domain > > > > Since we are also invalidating in other fbdev cases this one > > was masked here. At least until now that I found this corner > > case: On boot with plymouth doing a splash screen > > when returning to the console frontbuffer wans't being invalidated > > causing missed screen updates with PSR enabled. > > > > So this patch fixes this issue. > > > > v2: Make invalidate directly and unconditionally and > > fix commit message indicating the set_domain fix > > as pointed out by Daniel. > > > > Cc: Daniel Vetter > > Signed-off-by: Rodrigo Vivi > > --- > > drivers/gpu/drm/i915/intel_fbdev.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c > > b/drivers/gpu/drm/i915/intel_fbdev.c > > index 2a1724e..44c9ccc 100644 > > --- a/drivers/gpu/drm/i915/intel_fbdev.c > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c > > @@ -63,8 +63,8 @@ static int intel_fbdev_set_par(struct fb_info *info) > > * now until we solve this for real. > > */ > > mutex_lock(&fb_helper->dev->struct_mutex); > > - ret = i915_gem_object_set_to_gtt_domain(ifbdev->fb->obj, > > - true); > > + if (ifbdev->fb->obj) > > I'm confused. Why are we doing this check now? If this is actually > needed, then the current set_to_gtt_domain() call will blow up too. So > this would be 2 different patches: one preventing the explosion, the > other doing obj_invalidate. Unless we don't need the obj check. I'm confused as well. I could swear I was just putting back an "if" that was already here. No idea where this came from and don't see a need for it... v++ on the way... > > > + intel_fb_obj_invalidate(ifbdev->fb->obj, > > ORIGIN_GTT); > > mutex_unlock(&fb_helper->dev->struct_mutex); > > } > > > > -- > > 2.1.0 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 2/5] drm/i915: Unify execlist and legacy request life-cycles
On 07/09/2015 03:57 AM, Nick Hoath wrote:
There is a desire to simplify the i915 driver by reducing the number of
different code paths introduced by the LRC / execlists support. As the
execlists request is now part of the gem request it is possible and
desirable to unify the request life-cycles for execlist and legacy
requests.
Added a context complete flag to a request which gets set during the
context switch interrupt.
Added a function i915_gem_request_retireable(). A request is considered
retireable if its seqno passed (i.e. the request has completed) and either
it was never submitted to the ELSP or its context completed. This ensures
that context save is carried out before the last request for a context is
considered retireable. retire_requests_ring() now uses
i915_gem_request_retireable() rather than request_complete() when deciding
which requests to retire. Requests that were not waiting for a context
switch interrupt (either as a result of being merged into a following
request or by being a legacy request) will be considered retireable as
soon as their seqno has passed.
Removed the extra request reference held for the execlist request.
Removed intel_execlists_retire_requests() and all references to
intel_engine_cs.execlist_retired_req_list.
Moved context unpinning into retire_requests_ring() for now. Further work
is pending for the context pinning - this patch should allow us to use the
active list to track context and ring buffer objects later.
Just heads up on potential performance drop on certain workloads. Since
retire_reuests_ring is called before each submission, for those CPU
bound workloads, you will see context pin & unpin very often. The
ioremap_wc / iounmap for ring buffer consumes more CPU time. I found
this issue during GuC implementation because GuC does not use execlist
request queue but legacy one. On SKL, there is about 3~5% performance
drop in workloads such as SynMark2 oglbatch5/6/7.
Thanks,
Alex
Changed gen8_cs_irq_handler() so that notify_ring() is called when
contexts complete as well as when a user interrupt occurs so that
notification happens when a request is complete and context save has
finished.
v2: Rebase over the read-read optimisation changes
Signed-off-by: Thomas Daniel
Signed-off-by: Nick Hoath
---
drivers/gpu/drm/i915/i915_drv.h | 6
drivers/gpu/drm/i915/i915_gem.c | 49 +++--
drivers/gpu/drm/i915/i915_irq.c | 6 ++--
drivers/gpu/drm/i915/intel_lrc.c| 44 ++---
drivers/gpu/drm/i915/intel_lrc.h| 2 +-
drivers/gpu/drm/i915/intel_ringbuffer.h | 1 -
6 files changed, 53 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1dbd957..ef02378 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2213,6 +2213,12 @@ struct drm_i915_gem_request {
/** Execlists no. of times this request has been sent to the ELSP */
int elsp_submitted;
+ /**
+* Execlists: whether this requests's context has completed after
+* submission to the ELSP
+*/
+ bool ctx_complete;
+
};
int i915_gem_request_alloc(struct intel_engine_cs *ring,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 49016e0..3681a33 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2368,6 +2368,12 @@ void i915_vma_move_to_active(struct i915_vma *vma,
list_move_tail(&vma->mm_list, &vma->vm->active_list);
}
+static bool i915_gem_request_retireable(struct drm_i915_gem_request *req)
+{
+ return (i915_gem_request_completed(req, true) &&
+ (!req->elsp_submitted || req->ctx_complete));
+}
+
static void
i915_gem_object_retire__write(struct drm_i915_gem_object *obj)
{
@@ -2853,10 +2859,28 @@ i915_gem_retire_requests_ring(struct intel_engine_cs
*ring)
struct drm_i915_gem_request,
list);
- if (!i915_gem_request_completed(request, true))
+ if (!i915_gem_request_retireable(request))
break;
i915_gem_request_retire(request);
+
+ if (i915.enable_execlists) {
+ struct intel_context *ctx = request->ctx;
+ struct drm_i915_private *dev_priv =
+ ring->dev->dev_private;
+ unsigned long flags;
+ struct drm_i915_gem_object *ctx_obj =
+ ctx->engine[ring->id].state;
+
+ spin_lock_irqsave(&ring->execlist_lock, flags);
+
+ if (ctx_obj && (ctx != ring->default_context))
+ intel_lr_context_unpin(ring, ctx);
+
+ intel_runtime_pm_put(dev_priv);
+ spin_u
[Intel-gfx] [PATCH] drm/i915: fbdev_set_par reliably invalidating frontbuffer
fbdev_set_par is called when fbcon is taking over control. In the past frontbuffer was being invalidated on set_to_gtt_domain, but it moved to set_domain fixing that case, but left this behind. Commit that changed this fixing set_domain case was: commit 031b698a77a70a6c394568034437b5486a44e868 Author: Daniel Vetter Date: Fri Jun 26 19:35:16 2015 +0200 drm/i915: Unconditionally do fb tracking invalidate in set_domain Since we are also invalidating in other fbdev cases this one was masked here. At least until now that I found this corner case: On boot with plymouth doing a splash screen when returning to the console frontbuffer wans't being invalidated causing missed screen updates with PSR enabled. So this patch fixes this issue. v2: Make invalidate directly and unconditionally and fix commit message indicating the set_domain fix as pointed out by Daniel. v3: Remove unecessary if(obj) added by mistake Cc: Paulo Zanoni Cc: Daniel Vetter Signed-off-by: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_fbdev.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c index 2a1724e..25ce7b6 100644 --- a/drivers/gpu/drm/i915/intel_fbdev.c +++ b/drivers/gpu/drm/i915/intel_fbdev.c @@ -63,8 +63,7 @@ static int intel_fbdev_set_par(struct fb_info *info) * now until we solve this for real. */ mutex_lock(&fb_helper->dev->struct_mutex); - ret = i915_gem_object_set_to_gtt_domain(ifbdev->fb->obj, - true); + intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); mutex_unlock(&fb_helper->dev->struct_mutex); } -- 2.1.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: fix intel_fb_obj_flush documentation
ops... Sorry.. I could swear I had added this... or probably forgot to send the version that had it... Anyway: Reviewed-by: Rodrigo Vivi On Wed, Jul 8, 2015 at 2:09 PM Paulo Zanoni wrote: > From: Paulo Zanoni > > Reported by the kbuild test robot. > > Regression introduced by: > commit de152b627eb3018de91ec5c5a50b38e17d80a88b > Author: Rodrigo Vivi > Date: Tue Jul 7 16:28:51 2015 -0700 > drm/i915: Add origin to frontbuffer tracking flush > > (I reviewed this commit, so it's also my fault) > > Signed-off-by: Paulo Zanoni > --- > drivers/gpu/drm/i915/intel_frontbuffer.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c > b/drivers/gpu/drm/i915/intel_frontbuffer.c > index 122533d..dc8f14d 100644 > --- a/drivers/gpu/drm/i915/intel_frontbuffer.c > +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c > @@ -136,6 +136,7 @@ static void intel_frontbuffer_flush(struct drm_device > *dev, > * intel_fb_obj_flush - flush frontbuffer object > * @obj: GEM object to flush > * @retire: set when retiring asynchronous rendering > + * @origin: which operation caused the flush > * > * This function gets called every time rendering on the given object has > * completed and frontbuffer caching can be started again. If @retire is > true > -- > 2.1.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: set ILK_DPFC_FENCE_YOFF to 0 on SNB
On Wed, Jul 08, 2015 at 05:58:57PM -0300, Paulo Zanoni wrote: > From: Paulo Zanoni > > The doc is pretty clear that this register should be set to 0 on SNB. > We already write y_offset to DPFC_CPU_FENCE_OFFSET a few lines below. > > Signed-off-by: Paulo Zanoni Hm, do we have testcases where we have a sufficiently big y offset? We can just allocate 128 lines more and use that as the offset, that should be big enough everywhere. Actually make that 129 lines to check the tile-size rounding ;-) Ofc this means we need to have two sets of testcases for all the affected tests (i.e. everything that tries to test the gtt hw tracking). Another funny corner case (which we're getting wrong on skl even without fbc) is x offsets > 2048 pixels (since x/y offset registers don't hold bigger values and then it wraps). I.e. I'd like this patch (and the others) to be augmented with a Testcase: tag. Cheers, Daniel > --- > drivers/gpu/drm/i915/intel_fbc.c | 7 ++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c > b/drivers/gpu/drm/i915/intel_fbc.c > index 0373cbc..0a24e96 100644 > --- a/drivers/gpu/drm/i915/intel_fbc.c > +++ b/drivers/gpu/drm/i915/intel_fbc.c > @@ -216,7 +216,12 @@ static void ilk_fbc_enable(struct intel_crtc *crtc) > dpfc_ctl |= obj->fence_reg; > > y_offset = get_crtc_fence_y_offset(crtc); > - I915_WRITE(ILK_DPFC_FENCE_YOFF, y_offset); > + > + if (IS_GEN5(dev_priv)) > + I915_WRITE(ILK_DPFC_FENCE_YOFF, y_offset); > + else > + I915_WRITE(ILK_DPFC_FENCE_YOFF, 0); > + > I915_WRITE(ILK_FBC_RT_BASE, i915_gem_obj_ggtt_offset(obj) | > ILK_FBC_RT_VALID); > /* enable it... */ > I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN); > -- > 2.1.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH igt] tests: add kms_fbcon_fbt
From: Paulo Zanoni
This test should test the interactions between fbcon and the
frontbuffer tracking infrastructure.
Right now the PSR test fails, but as soon as we merge the following
kernel patches, the test wills tart passing:
- drm/i915: PSR: Flush means invalidate + flush
- drm/i915: fbdev restore mode needs to invalidate frontbuffer
- drm/i915: fbdev_set_par reliably invalidating frontbuffer
I didn't want to make this a subtest of kms_frontbuffer_tracking just
because when I wrote it, I really didn't have in mind the fact that
someone might just close the DRM fd in the middle of a subtest.
After this commit we'll have a little bit of duplicated code among
tests. I'll clean this up later.
Signed-off-by: Paulo Zanoni
---
tests/.gitignore | 1 +
tests/Makefile.sources | 1 +
tests/kms_fbcon_fbt.c | 333 +
3 files changed, 335 insertions(+)
create mode 100644 tests/kms_fbcon_fbt.c
diff --git a/tests/.gitignore b/tests/.gitignore
index c31b22a..0af0899 100644
--- a/tests/.gitignore
+++ b/tests/.gitignore
@@ -131,6 +131,7 @@ kms_addfb
kms_cursor_crc
kms_draw_crc
kms_fbc_crc
+kms_fbcon_fbt
kms_fence_pin_leak
kms_flip
kms_flip_event_leak
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index b9479cc..c94714b 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -65,6 +65,7 @@ TESTS_progs_M = \
kms_cursor_crc \
kms_draw_crc \
kms_fbc_crc \
+ kms_fbcon_fbt \
kms_flip \
kms_flip_event_leak \
kms_flip_tiling \
diff --git a/tests/kms_fbcon_fbt.c b/tests/kms_fbcon_fbt.c
new file mode 100644
index 000..e5d2d33
--- /dev/null
+++ b/tests/kms_fbcon_fbt.c
@@ -0,0 +1,333 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ * Authors:
+ *
+ */
+
+#include
+#include
+#include
+
+#include "drmtest.h"
+#include "igt_aux.h"
+#include "igt_debugfs.h"
+#include "igt_draw.h"
+#include "igt_kms.h"
+
+IGT_TEST_DESCRIPTION("Test the relationship between fbcon and the frontbuffer "
+"tracking infrastructure.");
+
+#define MAX_CONNECTORS 32
+#define DEBUGFS_MSG_SIZE 256
+
+static bool do_wait_user = false;
+
+struct drm_info {
+ int fd;
+ drmModeResPtr res;
+ drmModeConnectorPtr connectors[MAX_CONNECTORS];
+};
+
+struct fbc_info {
+ int fd;
+};
+
+struct psr_info {
+ int fd;
+};
+
+enum feature_status {
+ ENABLED,
+ DISABLED,
+};
+
+static void wait_user(const char *msg)
+{
+ if (!do_wait_user)
+ return;
+
+ igt_info("%s Press enter...\n", msg);
+ while (getchar() != '\n')
+ ;
+}
+
+static void setup_drm(struct drm_info *drm)
+{
+ int i;
+
+ drm->fd = drm_open_any_master();
+
+ drm->res = drmModeGetResources(drm->fd);
+ igt_assert(drm->res->count_connectors <= MAX_CONNECTORS);
+
+ for (i = 0; i < drm->res->count_connectors; i++)
+ drm->connectors[i] = drmModeGetConnector(drm->fd,
+ drm->res->connectors[i]);
+
+ kmstest_set_vt_graphics_mode();
+}
+
+static void teardown_drm(struct drm_info *drm)
+{
+ int i;
+
+ kmstest_restore_vt_mode();
+
+ for (i = 0; i < drm->res->count_connectors; i++)
+ drmModeFreeConnector(drm->connectors[i]);
+
+ drmModeFreeResources(drm->res);
+ igt_assert(close(drm->fd) == 0);
+}
+
+static void get_debugfs_string(int fd, char *buf)
+{
+ ssize_t n_read;
+
+ lseek(fd, 0, SEEK_SET);
+
+ n_read = read(fd, buf, DEBUGFS_MSG_SIZE -1);
+ igt_assert(n_read >= 0);
+ buf[n_read] = '\0';
+}
+
+static bool fbc_supported_on_chipset(int fd)
+{
+ char buf[DEBUGFS_MSG_SIZE];
+
+ get_debugfs_string(fd, buf);
+ return !strstr(buf, "FBC unsupported on this chipset\n");
Re: [Intel-gfx] [PATCH 5/6] drm/i915: check for the supported strides on HSW+ FBC
On Wed, Jul 08, 2015 at 05:58:58PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> I could only find the restrictions for HSW+, but I think it's safe to
> assume that the older platforms also can't support the configurations
> HSW can't support. The older platforms probably have additional
> restrictions, so we need to figure out those and implement them later.
> Let's not block HSW+ FBC based on missing information for the older
> platforms.
>
> This may fix kms_frontbuffer_tracking failures depending on your
> monitor configuration.
>
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_fbc.c | 10 ++
> 2 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 52d07fb..4a4b2a9 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -936,6 +936,7 @@ struct i915_fbc {
> FBC_CHIP_DEFAULT, /* disabled by default on this chip */
> FBC_ROTATION, /* rotation is not supported */
> FBC_IN_DBG_MASTER, /* kernel debugger is active */
> + FBC_BAD_STRIDE, /* stride is not supported */
> } no_fbc_reason;
>
> bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
> b/drivers/gpu/drm/i915/intel_fbc.c
> index 0a24e96..7b65b00 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -501,6 +501,8 @@ const char *intel_no_fbc_reason_str(enum no_fbc_reason
> reason)
> return "rotation unsupported";
> case FBC_IN_DBG_MASTER:
> return "Kernel debugger is active";
> + case FBC_BAD_STRIDE:
> + return "framebuffer stride not supported";
> default:
> MISSING_CASE(reason);
> return "unknown reason";
> @@ -804,6 +806,14 @@ static void __intel_fbc_update(struct drm_i915_private
> *dev_priv)
> goto out_disable;
> }
>
> + /* TODO: we need to figure out what are the stride restrictions for the
> + * older platforms. */
> + if (fb->pitches[0] < 512 || fb->pitches[0] > 16384 ||
< 512 is already take care of by the X-tiling restriction (requires a
multiple of 512 bytes stride). > 16kb might be the general stride limit,
we should probably reject that in intel_framebuffer_init. 64b alignment is
strange since X-tiled is stricter, and we that already in
intel_fb_stride_alignment.
So summary: Sounds like we need to add per-platform stride limit checks to
fb create code. Plus igt testcases to make sure we check for this (since
right now it seems like we don't). Additional checks here in the fbc code
don't seem required. But if you want to I guess you could convert them to
WARN_ON (without bailing out).
-Daniel
> + (fb->pitches[0] & (64 - 1)) != 0) {
> + set_no_fbc_reason(dev_priv, FBC_BAD_STRIDE);
> + goto out_disable;
> + }
> +
> /* If the kernel debugger is active, always disable compression */
> if (in_dbg_master()) {
> set_no_fbc_reason(dev_priv, FBC_IN_DBG_MASTER);
> --
> 2.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: fix intel_fb_obj_flush documentation
On Thu, Jul 09, 2015 at 05:00:57PM +, Rodrigo Vivi wrote: > ops... Sorry.. > I could swear I had added this... or probably forgot to send the version > that had it... > > Anyway: > > Reviewed-by: Rodrigo Vivi Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 13/15] drm/i915: Clean up CHV lane soft reset programming
From: Ville Syrjälä
Currently we release the lane soft reset before lane stagger settings
have been programmed. I believe that means we don't actually do lane
staggering. So move the soft reset deassert to happen after lane
staggering has been programmed.
The one confusing thing in this is that when we remove the power down
override from the lanes, they power up with defaul register values,
which do not have the soft reset overrides enabled. And according to
some docs by default the data lane resets are tied to cmnreset. So that
would mean that lanes would come out of reset without staggering as
soon as the power down overrides are removed. But since we can't access
either the lane stagger register nor the soft reset override registers
until the lanes are powered on, we can't really do anything about it.
So let's just set the soft reset overrides as soon as the lane is
powered on and hope for the best.
v2: Fix typos in commit message (Daniel)
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 91 +--
drivers/gpu/drm/i915/intel_hdmi.c | 91 ++-
2 files changed, 100 insertions(+), 82 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 817df87..297bd14 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -2389,42 +2389,62 @@ static void vlv_post_disable_dp(struct intel_encoder
*encoder)
intel_dp_link_down(intel_dp);
}
-static void chv_post_disable_dp(struct intel_encoder *encoder)
+static void chv_data_lane_soft_reset(struct intel_encoder *encoder,
+bool reset)
{
- struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
- struct intel_digital_port *dport = dp_to_dig_port(intel_dp);
- struct drm_device *dev = encoder->base.dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_crtc *intel_crtc =
- to_intel_crtc(encoder->base.crtc);
- enum dpio_channel ch = vlv_dport_to_channel(dport);
- enum pipe pipe = intel_crtc->pipe;
- u32 val;
+ struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ enum dpio_channel ch =
vlv_dport_to_channel(enc_to_dig_port(&encoder->base));
+ struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
+ enum pipe pipe = crtc->pipe;
+ uint32_t val;
- intel_dp_link_down(intel_dp);
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
+ if (reset)
+ val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
+ else
+ val |= DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
- mutex_lock(&dev_priv->sb_lock);
+ if (crtc->config->lane_count > 2) {
+ val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
+ if (reset)
+ val &= ~(DPIO_PCS_TX_LANE2_RESET |
DPIO_PCS_TX_LANE1_RESET);
+ else
+ val |= DPIO_PCS_TX_LANE2_RESET |
DPIO_PCS_TX_LANE1_RESET;
+ vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
+ }
- /* Propagate soft reset to data lane reset */
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
val |= CHV_PCS_REQ_SOFTRESET_EN;
+ if (reset)
+ val &= ~DPIO_PCS_CLK_SOFT_RESET;
+ else
+ val |= DPIO_PCS_CLK_SOFT_RESET;
vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW1(ch), val);
- if (intel_crtc->config->lane_count > 2) {
+ if (crtc->config->lane_count > 2) {
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW1(ch));
val |= CHV_PCS_REQ_SOFTRESET_EN;
+ if (reset)
+ val &= ~DPIO_PCS_CLK_SOFT_RESET;
+ else
+ val |= DPIO_PCS_CLK_SOFT_RESET;
vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW1(ch), val);
}
+}
- val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
- val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
- vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
+static void chv_post_disable_dp(struct intel_encoder *encoder)
+{
+ struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base);
+ struct drm_device *dev = encoder->base.dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
- if (intel_crtc->config->lane_count > 2) {
- val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
- val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
- vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
- }
+ intel_dp_link_down(intel_dp);
+
+ mutex_lock(&dev_priv->sb_lock);
+
+ /* Assert data lane reset */
+ chv_data_lane_soft_reset(encoder, true);
mut
Re: [Intel-gfx] [PATCH 3/3] drm/i915: fix intel_frontbuffer_flip documentation
On Wed, Jul 08, 2015 at 06:08:39PM -0300, Paulo Zanoni wrote:
> From: Paulo Zanoni
>
> Reported by the kbuild test robot.
>
> Regression introduced by:
> commit fdbff9282c0f5f61ffc87d57461b04d943250910
> Author: Daniel Vetter
> Date: Thu Jun 18 11:23:24 2015 +0200
> drm/i915: Clear fb_tracking.busy_bits also for synchronous flips
>
> (I reviewed this commit, so it's also my fault)
>
> Signed-off-by: Paulo Zanoni
Patch 1&3 also merged to dinq, thanks.
-Daniel
> ---
> Documentation/DocBook/drm.tmpl | 1 -
> drivers/gpu/drm/i915/intel_frontbuffer.c | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
> index 596b11d..30b3651 100644
> --- a/Documentation/DocBook/drm.tmpl
> +++ b/Documentation/DocBook/drm.tmpl
> @@ -4012,7 +4012,6 @@ int num_ioctls;
> Frontbuffer Tracking
> !Pdrivers/gpu/drm/i915/intel_frontbuffer.c frontbuffer tracking
> !Idrivers/gpu/drm/i915/intel_frontbuffer.c
> -!Fdrivers/gpu/drm/i915/intel_drv.h intel_frontbuffer_flip
> !Fdrivers/gpu/drm/i915/i915_gem.c i915_gem_track_fb
>
>
> diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c
> b/drivers/gpu/drm/i915/intel_frontbuffer.c
> index dc8f14d..b5b1d25 100644
> --- a/drivers/gpu/drm/i915/intel_frontbuffer.c
> +++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
> @@ -229,7 +229,6 @@ void intel_frontbuffer_flip_complete(struct drm_device
> *dev,
> *
> * Can be called without any locks held.
> */
> -
> void intel_frontbuffer_flip(struct drm_device *dev,
> unsigned frontbuffer_bits)
> {
> --
> 2.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: set ILK_DPFC_FENCE_YOFF to 0 on SNB
2015-07-09 14:10 GMT-03:00 Daniel Vetter : > On Wed, Jul 08, 2015 at 05:58:57PM -0300, Paulo Zanoni wrote: >> From: Paulo Zanoni >> >> The doc is pretty clear that this register should be set to 0 on SNB. >> We already write y_offset to DPFC_CPU_FENCE_OFFSET a few lines below. >> >> Signed-off-by: Paulo Zanoni > > Hm, do we have testcases where we have a sufficiently big y offset? We can > just allocate 128 lines more and use that as the offset, that should be > big enough everywhere. Actually make that 129 lines to check the tile-size > rounding ;-) Yes, it's 500x500. See FBS_MULTI on kms_frontbuffer_tracking. Subtests with "sfb" on their names create a Single frontbuffer for each possible primary plane (primary, secondary, offscreen), while subtests with "mfb" have Multiple pipes pointing to the same frontbuffer. See the small drawing inside kms_frontbuffer_tracking, at the top of create_big_fb(). By the way, it's on my TODO list to change that arrangement a little bit in order to avoid super-huge strides. > > Ofc this means we need to have two sets of testcases for all the affected > tests (i.e. everything that tries to test the gtt hw tracking). We do. > > Another funny corner case (which we're getting wrong on skl even without > fbc) is x offsets > 2048 pixels (since x/y offset registers don't hold > bigger values and then it wraps). Can you please clarify the sentence above? For the dual-screen subtests, if we use 2 screens of 1024 + the 500 pixel offset, we'll already be bigger than 2048 pixels. > > I.e. I'd like this patch (and the others) to be augmented with a Testcase: This one doesn't have a Testcase tag because I'm not testing SNB right now, so I can't confirm anything here. Patch 3 has the useful Testcases tags. > tag. > > Cheers, Daniel > >> --- >> drivers/gpu/drm/i915/intel_fbc.c | 7 ++- >> 1 file changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_fbc.c >> b/drivers/gpu/drm/i915/intel_fbc.c >> index 0373cbc..0a24e96 100644 >> --- a/drivers/gpu/drm/i915/intel_fbc.c >> +++ b/drivers/gpu/drm/i915/intel_fbc.c >> @@ -216,7 +216,12 @@ static void ilk_fbc_enable(struct intel_crtc *crtc) >> dpfc_ctl |= obj->fence_reg; >> >> y_offset = get_crtc_fence_y_offset(crtc); >> - I915_WRITE(ILK_DPFC_FENCE_YOFF, y_offset); >> + >> + if (IS_GEN5(dev_priv)) >> + I915_WRITE(ILK_DPFC_FENCE_YOFF, y_offset); >> + else >> + I915_WRITE(ILK_DPFC_FENCE_YOFF, 0); >> + >> I915_WRITE(ILK_FBC_RT_BASE, i915_gem_obj_ggtt_offset(obj) | >> ILK_FBC_RT_VALID); >> /* enable it... */ >> I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN); >> -- >> 2.1.4 >> >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: set ILK_DPFC_FENCE_YOFF to 0 on SNB
2015-07-09 14:15 GMT-03:00 Paulo Zanoni : > 2015-07-09 14:10 GMT-03:00 Daniel Vetter : >> On Wed, Jul 08, 2015 at 05:58:57PM -0300, Paulo Zanoni wrote: >>> From: Paulo Zanoni >>> >>> The doc is pretty clear that this register should be set to 0 on SNB. >>> We already write y_offset to DPFC_CPU_FENCE_OFFSET a few lines below. >>> >>> Signed-off-by: Paulo Zanoni >> >> Hm, do we have testcases where we have a sufficiently big y offset? We can >> just allocate 128 lines more and use that as the offset, that should be >> big enough everywhere. Actually make that 129 lines to check the tile-size >> rounding ;-) > > Yes, it's 500x500. See FBS_MULTI on kms_frontbuffer_tracking. Subtests > with "sfb" on their names create a Single frontbuffer for each > possible primary plane (primary, secondary, offscreen), while subtests > with "mfb" have Multiple pipes pointing to the same frontbuffer. See > the small drawing inside kms_frontbuffer_tracking, at the top of > create_big_fb(). By the way, it's on my TODO list to change that > arrangement a little bit in order to avoid super-huge strides. Also notice that I tested values other than 500x500 while developing patch 3. 500x500 seems like a nice value since it's not aligned with any tiles and never part of the first tile. > >> >> Ofc this means we need to have two sets of testcases for all the affected >> tests (i.e. everything that tries to test the gtt hw tracking). > > We do. > >> >> Another funny corner case (which we're getting wrong on skl even without >> fbc) is x offsets > 2048 pixels (since x/y offset registers don't hold >> bigger values and then it wraps). > > Can you please clarify the sentence above? For the dual-screen > subtests, if we use 2 screens of 1024 + the 500 pixel offset, we'll > already be bigger than 2048 pixels. > >> >> I.e. I'd like this patch (and the others) to be augmented with a Testcase: > > This one doesn't have a Testcase tag because I'm not testing SNB right > now, so I can't confirm anything here. Patch 3 has the useful > Testcases tags. > >> tag. >> >> Cheers, Daniel >> >>> --- >>> drivers/gpu/drm/i915/intel_fbc.c | 7 ++- >>> 1 file changed, 6 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/gpu/drm/i915/intel_fbc.c >>> b/drivers/gpu/drm/i915/intel_fbc.c >>> index 0373cbc..0a24e96 100644 >>> --- a/drivers/gpu/drm/i915/intel_fbc.c >>> +++ b/drivers/gpu/drm/i915/intel_fbc.c >>> @@ -216,7 +216,12 @@ static void ilk_fbc_enable(struct intel_crtc *crtc) >>> dpfc_ctl |= obj->fence_reg; >>> >>> y_offset = get_crtc_fence_y_offset(crtc); >>> - I915_WRITE(ILK_DPFC_FENCE_YOFF, y_offset); >>> + >>> + if (IS_GEN5(dev_priv)) >>> + I915_WRITE(ILK_DPFC_FENCE_YOFF, y_offset); >>> + else >>> + I915_WRITE(ILK_DPFC_FENCE_YOFF, 0); >>> + >>> I915_WRITE(ILK_FBC_RT_BASE, i915_gem_obj_ggtt_offset(obj) | >>> ILK_FBC_RT_VALID); >>> /* enable it... */ >>> I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN); >>> -- >>> 2.1.4 >>> >>> ___ >>> Intel-gfx mailing list >>> Intel-gfx@lists.freedesktop.org >>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx >> >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch > > > > -- > Paulo Zanoni -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: set ILK_DPFC_FENCE_YOFF to 0 on SNB
On Thu, Jul 09, 2015 at 07:10:04PM +0200, Daniel Vetter wrote: > On Wed, Jul 08, 2015 at 05:58:57PM -0300, Paulo Zanoni wrote: > > From: Paulo Zanoni > > > > The doc is pretty clear that this register should be set to 0 on SNB. > > We already write y_offset to DPFC_CPU_FENCE_OFFSET a few lines below. > > > > Signed-off-by: Paulo Zanoni > > Hm, do we have testcases where we have a sufficiently big y offset? We can > just allocate 128 lines more and use that as the offset, that should be > big enough everywhere. Actually make that 129 lines to check the tile-size > rounding ;-) > > Ofc this means we need to have two sets of testcases for all the affected > tests (i.e. everything that tries to test the gtt hw tracking). > > Another funny corner case (which we're getting wrong on skl even without > fbc) is x offsets > 2048 pixels (since x/y offset registers don't hold > bigger values and then it wraps). > > I.e. I'd like this patch (and the others) to be augmented with a Testcase: > tag. I think the entire Y offset thing is currently being misprogrammed. IIRC the offset is from the display base address but we program in the offset from the start of the FB. > > Cheers, Daniel > > > --- > > drivers/gpu/drm/i915/intel_fbc.c | 7 ++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_fbc.c > > b/drivers/gpu/drm/i915/intel_fbc.c > > index 0373cbc..0a24e96 100644 > > --- a/drivers/gpu/drm/i915/intel_fbc.c > > +++ b/drivers/gpu/drm/i915/intel_fbc.c > > @@ -216,7 +216,12 @@ static void ilk_fbc_enable(struct intel_crtc *crtc) > > dpfc_ctl |= obj->fence_reg; > > > > y_offset = get_crtc_fence_y_offset(crtc); > > - I915_WRITE(ILK_DPFC_FENCE_YOFF, y_offset); > > + > > + if (IS_GEN5(dev_priv)) > > + I915_WRITE(ILK_DPFC_FENCE_YOFF, y_offset); > > + else > > + I915_WRITE(ILK_DPFC_FENCE_YOFF, 0); > > + > > I915_WRITE(ILK_FBC_RT_BASE, i915_gem_obj_ggtt_offset(obj) | > > ILK_FBC_RT_VALID); > > /* enable it... */ > > I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN); > > -- > > 2.1.4 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915: Check live status before reading edid
On Thu, Jul 09, 2015 at 05:34:29PM +0530, Sonika Jindal wrote:
> Adding this for SKL onwards.
>
> Signed-off-by: Sonika Jindal
I think this is the critical piece really, and I'd like to roll it out for
all platforms. git has the code for all the old ones, so no big deal to
digg that out. Also we need your fix for the interrupt handling first ofc,
otherwise this won't work.
Then we can apply this and give it some good testing before we start
relying on it with caching hdmi probe status. I know this means that
things will be slower, but I've been burned a bit too much the last few
times we've tried this. And I really think we need the most amount of
testing we can get (hence rolling this out for all platforms). If your
hpd irq handling bugfix is indeed the bug that will be confirmed quickly,
otherwise it means back to debugging.
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 49
> ++---
> 1 file changed, 45 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 1fb6919..769cf4f 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1300,6 +1300,46 @@ intel_hdmi_unset_edid(struct drm_connector *connector)
> to_intel_connector(connector)->detect_edid = NULL;
> }
>
> +static bool intel_hdmi_live_status(struct intel_digital_port *intel_dig_port)
> +{
> + struct drm_device *dev = intel_dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + enum port port = intel_dig_port->port;
> +
> + if (IS_SKYLAKE(dev)) {
> + u32 temp = I915_READ(SDEISR);
> +
> + switch (port) {
> + case PORT_B:
> + return temp & SDE_PORTB_HOTPLUG_CPT;
> +
> + case PORT_C:
> + return temp & SDE_PORTC_HOTPLUG_CPT;
> +
> + case PORT_D:
> + return temp & SDE_PORTD_HOTPLUG_CPT;
> +
> + default:
> + return false;
> + }
The old code had per-platform helper functions for this instead of a big
if-ladder. I think that would look better.
Also when you digg out these old versions please also cite the commit sha1
of the patches where we had to last revert this (and explain why it's now
save).
-Daniel
> + } else if (IS_BROXTON(dev)) {
> + u32 temp = I915_READ(GEN8_DE_PORT_ISR);
> +
> + switch (port) {
> + case PORT_B:
> + return temp & BXT_DE_PORT_HP_DDIB;
> +
> + case PORT_C:
> + return temp & BXT_DE_PORT_HP_DDIC;
> +
> + default:
> + return false;
> +
> + }
> + }
> + return true;
> +}
> +
> static bool
> intel_hdmi_set_edid(struct drm_connector *connector)
> {
> @@ -1308,15 +1348,16 @@ intel_hdmi_set_edid(struct drm_connector *connector)
> struct intel_encoder *intel_encoder =
> &hdmi_to_dig_port(intel_hdmi)->base;
> enum intel_display_power_domain power_domain;
> - struct edid *edid;
> + struct edid *edid = NULL;
> bool connected = false;
>
> power_domain = intel_display_port_power_domain(intel_encoder);
> intel_display_power_get(dev_priv, power_domain);
>
> - edid = drm_get_edid(connector,
> - intel_gmbus_get_adapter(dev_priv,
> - intel_hdmi->ddc_bus));
> + if (intel_hdmi_live_status(hdmi_to_dig_port(intel_hdmi)))
> + edid = drm_get_edid(connector,
> + intel_gmbus_get_adapter(dev_priv,
> + intel_hdmi->ddc_bus));
>
> intel_display_power_put(dev_priv, power_domain);
>
> --
> 1.7.10.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: check for the supported strides on HSW+ FBC
2015-07-09 14:15 GMT-03:00 Daniel Vetter :
> On Wed, Jul 08, 2015 at 05:58:58PM -0300, Paulo Zanoni wrote:
>> From: Paulo Zanoni
>>
>> I could only find the restrictions for HSW+, but I think it's safe to
>> assume that the older platforms also can't support the configurations
>> HSW can't support. The older platforms probably have additional
>> restrictions, so we need to figure out those and implement them later.
>> Let's not block HSW+ FBC based on missing information for the older
>> platforms.
>>
>> This may fix kms_frontbuffer_tracking failures depending on your
>> monitor configuration.
>>
>> Signed-off-by: Paulo Zanoni
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 1 +
>> drivers/gpu/drm/i915/intel_fbc.c | 10 ++
>> 2 files changed, 11 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 52d07fb..4a4b2a9 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -936,6 +936,7 @@ struct i915_fbc {
>> FBC_CHIP_DEFAULT, /* disabled by default on this chip */
>> FBC_ROTATION, /* rotation is not supported */
>> FBC_IN_DBG_MASTER, /* kernel debugger is active */
>> + FBC_BAD_STRIDE, /* stride is not supported */
>> } no_fbc_reason;
>>
>> bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
>> diff --git a/drivers/gpu/drm/i915/intel_fbc.c
>> b/drivers/gpu/drm/i915/intel_fbc.c
>> index 0a24e96..7b65b00 100644
>> --- a/drivers/gpu/drm/i915/intel_fbc.c
>> +++ b/drivers/gpu/drm/i915/intel_fbc.c
>> @@ -501,6 +501,8 @@ const char *intel_no_fbc_reason_str(enum no_fbc_reason
>> reason)
>> return "rotation unsupported";
>> case FBC_IN_DBG_MASTER:
>> return "Kernel debugger is active";
>> + case FBC_BAD_STRIDE:
>> + return "framebuffer stride not supported";
>> default:
>> MISSING_CASE(reason);
>> return "unknown reason";
>> @@ -804,6 +806,14 @@ static void __intel_fbc_update(struct drm_i915_private
>> *dev_priv)
>> goto out_disable;
>> }
>>
>> + /* TODO: we need to figure out what are the stride restrictions for the
>> + * older platforms. */
>> + if (fb->pitches[0] < 512 || fb->pitches[0] > 16384 ||
>
> < 512 is already take care of by the X-tiling restriction (requires a
> multiple of 512 bytes stride)
. > 16kb might be the general stride limit,
> we should probably reject that in intel_framebuffer_init. 64b alignment is
> strange since X-tiled is stricter, and we that already in
> intel_fb_stride_alignment.
16384 bytes is just 4096 32bit pixels wide. If you have 2 modern
monitors configured in wide mode you already beat that (or maybe 3
not-so-fancy monitors). So if you want FBC you'll have to "xrandr
--output DP1 --above eDP1 --auto", insead of "--left-of" (also, pray
that the guys developing your desktop environment actually tested this
case). So this is certainly a check that we want in the FBC code but
not in other places. I can remove the other checks if you want.
I also did find that gen3 requires specifically 4k or 8k strides:
nothing except for that. But I'll only write this patch much later
(gen3 is not a priority for now, as you know).
>
> So summary: Sounds like we need to add per-platform stride limit checks to
> fb create code.
As mentioned above: no. FBC can be more strict.
> Plus igt testcases to make sure we check for this (since
> right now it seems like we don't).
It's on the TODO list but it's not a priority since the Kernel checks
are very straightforward. One of the problems is that different
platforms have different requirements, so I'll have to hardcode those
requirements on IGT too. And I'll have to stop using igt_create_fb for
that case since it only use powers of 2 for stride.
So yeah, one day we may have the test, but not a priority right now
since it's very easy to look at the Kernel code and make sure it's
correct.
> Additional checks here in the fbc code
> don't seem required. But if you want to I guess you could convert them to
> WARN_ON (without bailing out).
> -Daniel
>
>> + (fb->pitches[0] & (64 - 1)) != 0) {
>> + set_no_fbc_reason(dev_priv, FBC_BAD_STRIDE);
>> + goto out_disable;
>> + }
>> +
>> /* If the kernel debugger is active, always disable compression */
>> if (in_dbg_master()) {
>> set_no_fbc_reason(dev_priv, FBC_IN_DBG_MASTER);
>> --
>> 2.1.4
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915/gen9: Corrected the sanity check of mmio address range for csr.
On Wed, Jul 08, 2015 at 07:54:47PM +0530, Animesh Manna wrote:
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/intel_csr.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index d600640..f515d54 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -296,7 +296,7 @@ static void finish_csr_load(const struct firmware *fw,
> }
> csr->mmio_count = dmc_header->mmio_count;
> for (i = 0; i < dmc_header->mmio_count; i++) {
> - if (dmc_header->mmioaddr[i] < CSR_MMIO_START_RANGE &&
> + if (dmc_header->mmioaddr[i] < CSR_MMIO_START_RANGE ||
> dmc_header->mmioaddr[i] > CSR_MMIO_END_RANGE) {
Please also fix the alignement of the 2nd line, it should align with the
opening ( like this
if (aa &&
bb) {
/* more code */
}
Cheers, Daniel
> DRM_ERROR(" Firmware has wrong mmio address 0x%x\n",
> dmc_header->mmioaddr[i]);
> --
> 2.0.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: set ILK_DPFC_FENCE_YOFF to 0 on SNB
2015-07-09 14:22 GMT-03:00 Ville Syrjälä : > On Thu, Jul 09, 2015 at 07:10:04PM +0200, Daniel Vetter wrote: >> On Wed, Jul 08, 2015 at 05:58:57PM -0300, Paulo Zanoni wrote: >> > From: Paulo Zanoni >> > >> > The doc is pretty clear that this register should be set to 0 on SNB. >> > We already write y_offset to DPFC_CPU_FENCE_OFFSET a few lines below. >> > >> > Signed-off-by: Paulo Zanoni >> >> Hm, do we have testcases where we have a sufficiently big y offset? We can >> just allocate 128 lines more and use that as the offset, that should be >> big enough everywhere. Actually make that 129 lines to check the tile-size >> rounding ;-) >> >> Ofc this means we need to have two sets of testcases for all the affected >> tests (i.e. everything that tries to test the gtt hw tracking). >> >> Another funny corner case (which we're getting wrong on skl even without >> fbc) is x offsets > 2048 pixels (since x/y offset registers don't hold >> bigger values and then it wraps). >> >> I.e. I'd like this patch (and the others) to be augmented with a Testcase: >> tag. > > I think the entire Y offset thing is currently being misprogrammed. > IIRC the offset is from the display base address but we program in > the offset from the start of the FB. After patch 3, all the current tests pass on BDW. Can you suggest a different test that won't pass? > >> >> Cheers, Daniel >> >> > --- >> > drivers/gpu/drm/i915/intel_fbc.c | 7 ++- >> > 1 file changed, 6 insertions(+), 1 deletion(-) >> > >> > diff --git a/drivers/gpu/drm/i915/intel_fbc.c >> > b/drivers/gpu/drm/i915/intel_fbc.c >> > index 0373cbc..0a24e96 100644 >> > --- a/drivers/gpu/drm/i915/intel_fbc.c >> > +++ b/drivers/gpu/drm/i915/intel_fbc.c >> > @@ -216,7 +216,12 @@ static void ilk_fbc_enable(struct intel_crtc *crtc) >> > dpfc_ctl |= obj->fence_reg; >> > >> > y_offset = get_crtc_fence_y_offset(crtc); >> > - I915_WRITE(ILK_DPFC_FENCE_YOFF, y_offset); >> > + >> > + if (IS_GEN5(dev_priv)) >> > + I915_WRITE(ILK_DPFC_FENCE_YOFF, y_offset); >> > + else >> > + I915_WRITE(ILK_DPFC_FENCE_YOFF, 0); >> > + >> > I915_WRITE(ILK_FBC_RT_BASE, i915_gem_obj_ggtt_offset(obj) | >> > ILK_FBC_RT_VALID); >> > /* enable it... */ >> > I915_WRITE(ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN); >> > -- >> > 2.1.4 >> > >> > ___ >> > Intel-gfx mailing list >> > Intel-gfx@lists.freedesktop.org >> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx >> >> -- >> Daniel Vetter >> Software Engineer, Intel Corporation >> http://blog.ffwll.ch >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Ville Syrjälä > Intel OTC -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: set ILK_DPFC_FENCE_YOFF to 0 on SNB
On Thu, Jul 09, 2015 at 02:31:15PM -0300, Paulo Zanoni wrote: > 2015-07-09 14:22 GMT-03:00 Ville Syrjälä : > > On Thu, Jul 09, 2015 at 07:10:04PM +0200, Daniel Vetter wrote: > >> On Wed, Jul 08, 2015 at 05:58:57PM -0300, Paulo Zanoni wrote: > >> > From: Paulo Zanoni > >> > > >> > The doc is pretty clear that this register should be set to 0 on SNB. > >> > We already write y_offset to DPFC_CPU_FENCE_OFFSET a few lines below. > >> > > >> > Signed-off-by: Paulo Zanoni > >> > >> Hm, do we have testcases where we have a sufficiently big y offset? We can > >> just allocate 128 lines more and use that as the offset, that should be > >> big enough everywhere. Actually make that 129 lines to check the tile-size > >> rounding ;-) > >> > >> Ofc this means we need to have two sets of testcases for all the affected > >> tests (i.e. everything that tries to test the gtt hw tracking). > >> > >> Another funny corner case (which we're getting wrong on skl even without > >> fbc) is x offsets > 2048 pixels (since x/y offset registers don't hold > >> bigger values and then it wraps). > >> > >> I.e. I'd like this patch (and the others) to be augmented with a Testcase: > >> tag. > > > > I think the entire Y offset thing is currently being misprogrammed. > > IIRC the offset is from the display base address but we program in > > the offset from the start of the FB. > > After patch 3, all the current tests pass on BDW. Can you suggest a > different test that won't pass? Ah patch 3 tries to fix it. It's not entirely accurate though since it simply relies on an implementation detail of intel_gen4_compute_page_offset(). Well, assuming my recollection of the hardware details is correct. Also IIRC intel_gen4_compute_page_offset() isn't even used on SKL/BXT currently, so it should fail on those platforms. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm/i915/gen9: Removed csr-lock and csr-state
On Wed, Jul 08, 2015 at 07:54:42PM +0530, Animesh Manna wrote:
> v1: As per review comments from Daniel, removed the csr-lock
> and csr-state which was used before in dmc firmware loading.
> Planning to have a single async task which will responsible
> for firmware loading and register programming for dc5/dc6,
> so removed csr-lock and csr-state from intel_csr structure.
>
> Signed-off-by: Animesh Manna
This patch split-up breaks correctness of the code since here you remove
the existing dmc loading coordination code before the new code is in
place. This should be done the other way round when splitting patches,
i.e. first add the new code (or replace parts of the existing code as you
go), then remove the old one.
Patches for existing features should never degrade functionality.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_dma.c | 1 -
> drivers/gpu/drm/i915/i915_drv.c | 6
> drivers/gpu/drm/i915/i915_drv.h | 10 ---
> drivers/gpu/drm/i915/intel_csr.c| 52
> -
> drivers/gpu/drm/i915/intel_drv.h| 3 --
> drivers/gpu/drm/i915/intel_runtime_pm.c | 17 ++-
> 6 files changed, 3 insertions(+), 86 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index c5349fa..1ebf0e1 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -820,7 +820,6 @@ int i915_driver_load(struct drm_device *dev, unsigned
> long flags)
> spin_lock_init(&dev_priv->mmio_flip_lock);
> mutex_init(&dev_priv->sb_lock);
> mutex_init(&dev_priv->modeset_restore_lock);
> - mutex_init(&dev_priv->csr_lock);
>
> intel_pm_setup(dev);
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index e44dc0d..4d8d2d8 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1019,12 +1019,6 @@ static int skl_suspend_complete(struct
> drm_i915_private *dev_priv)
> {
> /* Enabling DC6 is not a hard requirement to enter runtime D3 */
>
> - /*
> - * This is to ensure that CSR isn't identified as loaded before
> - * CSR-loading program is called during runtime-resume.
> - */
> - intel_csr_load_status_set(dev_priv, FW_UNINITIALIZED);
> -
> skl_uninit_cdclk(dev_priv);
>
> return 0;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1dbd957..b3a0fd6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -737,12 +737,6 @@ struct intel_uncore {
> #define for_each_fw_domain(domain__, dev_priv__, i__) \
> for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__, i__)
>
> -enum csr_state {
> - FW_UNINITIALIZED = 0,
> - FW_LOADED,
> - FW_FAILED
> -};
> -
> struct intel_csr {
> const char *fw_path;
> __be32 *dmc_payload;
> @@ -750,7 +744,6 @@ struct intel_csr {
> uint32_t mmio_count;
> uint32_t mmioaddr[8];
> uint32_t mmiodata[8];
> - enum csr_state state;
> };
>
> #define DEV_INFO_FOR_EACH_FLAG(func, sep) \
> @@ -1689,9 +1682,6 @@ struct drm_i915_private {
>
> struct intel_csr csr;
>
> - /* Display CSR-related protection */
> - struct mutex csr_lock;
> -
> struct intel_gmbus gmbus[GMBUS_NUM_PINS];
>
> /** gmbus_mutex protects against concurrent usage of the single hw gmbus
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index 6d8a7bf..62fd1b0 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -32,13 +32,6 @@
> * onwards to drive newly added DMC (Display microcontroller) in display
> * engine to save and restore the state of display engine when it enter into
> * low-power state and comes back to normal.
> - *
> - * Firmware loading status will be one of the below states: FW_UNINITIALIZED,
> - * FW_LOADED, FW_FAILED.
> - *
> - * Once the firmware is written into the registers status will be moved from
> - * FW_UNINITIALIZED to FW_LOADED and for any erroneous condition status will
> - * be moved to FW_FAILED.
> */
>
> #define I915_CSR_SKL "i915/skl_dmc_ver1.bin"
> @@ -200,40 +193,6 @@ static char intel_get_substepping(struct drm_device *dev)
> }
>
> /**
> - * intel_csr_load_status_get() - to get firmware loading status.
> - * @dev_priv: i915 device.
> - *
> - * This function helps to get the firmware loading status.
> - *
> - * Return: Firmware loading status.
> - */
> -enum csr_state intel_csr_load_status_get(struct drm_i915_private *dev_priv)
> -{
> - enum csr_state state;
> -
> - mutex_lock(&dev_priv->csr_lock);
> - state = dev_priv->csr.state;
> - mutex_unlock(&dev_priv->csr_lock);
> -
> - return state;
> -}
> -
> -/**
> - * intel_csr_load_status_set() - help to set firmware loading status.
> - * @dev_priv: i915 device.
> - * @state: enumeration of firmware loading status.
Re: [Intel-gfx] [PATCH 4/6] drm/i915/gen9: Added dmc_present flag to check firmware loading status.
On Wed, Jul 08, 2015 at 07:54:45PM +0530, Animesh Manna wrote:
> Firmware loading can be optimized by setting the dmc_present flag
> for the first time and later internallly stored firmware data
> can be used.
>
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_csr.c | 24 +++-
> 2 files changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 5ae45bd..4870666 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -746,6 +746,7 @@ struct intel_csr {
> uint32_t mmio_count;
> uint32_t mmioaddr[8];
> uint32_t mmiodata[8];
> + bool dmc_present;
You can instead look at dev_priv->csr.dmc_payload, no need to add an
additional variable.
-Daniel
> };
>
> #define DEV_INFO_FOR_EACH_FLAG(func, sep) \
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index 8e9395f..d600640 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -333,6 +333,7 @@ static void finish_csr_load(const struct firmware *fw,
>
> /* load csr program during system boot, as needed for DC states */
> intel_csr_load_program(dev);
> + dev_priv->csr.dmc_present = true;
>
> DRM_DEBUG_KMS("Finished loading %s\n", dev_priv->csr.fw_path);
> }
> @@ -352,18 +353,22 @@ void intel_display_load_csr(struct drm_i915_private
> *dev_priv)
> const struct firmware *fw;
> int ret;
>
> - /* CSR supported for platform, load firmware */
> - ret = request_firmware(&fw, csr->fw_path,
> - &dev_priv->dev->pdev->dev);
> + if (dev_priv->csr.dmc_present)
> + intel_csr_load_program(dev_priv->dev);
> + else {
> + /* CSR supported for platform, load firmware */
> + ret = request_firmware(&fw, csr->fw_path,
> + &dev_priv->dev->pdev->dev);
>
> - DRM_DEBUG_KMS("Loading %s\n", csr->fw_path);
> + DRM_DEBUG_KMS("Loading %s\n", csr->fw_path);
>
> - if (ret) {
> - i915_firmware_load_error_print(csr->fw_path, ret);
> - return;
> + if (ret) {
> + i915_firmware_load_error_print(csr->fw_path, ret);
> + return;
> + }
> + finish_csr_load(fw, dev_priv);
> + release_firmware(fw);
> }
> - finish_csr_load(fw, dev_priv);
> - release_firmware(fw);
> }
>
> /**
> @@ -408,6 +413,7 @@ void intel_csr_ucode_fini(struct drm_device *dev)
> return;
>
> flush_work(&dev_priv->csr.csr_work);
> + dev_priv->csr.dmc_present = false;
>
> kfree(dev_priv->csr.dmc_payload);
> }
> --
> 2.0.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915/gen9: Replaced request_firmware_nowait() by request_firmware().
On Wed, Jul 08, 2015 at 07:54:44PM +0530, Animesh Manna wrote:
> v1: As per review comments from Daniel, replaced async firmware
> loading with request_firmware() which will load the dmc firmware and
> once firmware is loaded, dc5/dc6 register programming can be done
> in the same thread.
>
> Signed-off-by: Animesh Manna
Ok this isn't quite what I had in mind for the new firmware loader flow.
I'm working on a demonstration patch series with lots of detailed comments
in the commit message to explain my idea in detail. It won't be tested
(since I don't have a skl here) but should serve as a guideline for this
refactoring.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.c | 3 --
> drivers/gpu/drm/i915/intel_csr.c| 79
> -
> drivers/gpu/drm/i915/intel_drv.h| 2 +-
> drivers/gpu/drm/i915/intel_runtime_pm.c | 3 +-
> 4 files changed, 41 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 217efcb..18aaaf6 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1066,10 +1066,7 @@ static int bxt_resume_prepare(struct drm_i915_private
> *dev_priv)
>
> static int skl_resume_prepare(struct drm_i915_private *dev_priv)
> {
> - struct drm_device *dev = dev_priv->dev;
> -
> skl_init_cdclk(dev_priv);
> - intel_csr_load_program(dev);
>
> return 0;
> }
> diff --git a/drivers/gpu/drm/i915/intel_csr.c
> b/drivers/gpu/drm/i915/intel_csr.c
> index f3b4a17..8e9395f 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -192,14 +192,6 @@ static char intel_get_substepping(struct drm_device *dev)
> return -ENODATA;
> }
>
> -/**
> - * intel_csr_load_program() - write the firmware from memory to register.
> - * @dev: drm device.
> - *
> - * CSR firmware is read from a .bin file and kept in internal memory one
> time.
> - * Everytime display comes back from low power state this function is called
> to
> - * copy the firmware from internal memory to registers.
> - */
> void intel_csr_load_program(struct drm_device *dev)
> {
> struct drm_i915_private *dev_priv = dev->dev_private;
> @@ -222,9 +214,9 @@ void intel_csr_load_program(struct drm_device *dev)
> }
> }
>
> -static void finish_csr_load(const struct firmware *fw, void *context)
> +static void finish_csr_load(const struct firmware *fw,
> + struct drm_i915_private *dev_priv)
> {
> - struct drm_i915_private *dev_priv = context;
> struct drm_device *dev = dev_priv->dev;
> struct intel_css_header *css_header;
> struct intel_package_header *package_header;
> @@ -235,16 +227,15 @@ static void finish_csr_load(const struct firmware *fw,
> void *context)
> uint32_t dmc_offset = CSR_DEFAULT_FW_OFFSET, readcount = 0, nbytes;
> uint32_t i;
> __be32 *dmc_payload;
> - bool fw_loaded = false;
>
> if (!fw) {
> i915_firmware_load_error_print(csr->fw_path, 0);
> - goto out;
> + return;
> }
>
> if ((stepping == -ENODATA) || (substepping == -ENODATA)) {
> DRM_ERROR("Unknown stepping info, firmware loading failed\n");
> - goto out;
> + return;
> }
>
> /* Extract CSS Header information*/
> @@ -253,7 +244,7 @@ static void finish_csr_load(const struct firmware *fw,
> void *context)
> (css_header->header_len * 4)) {
> DRM_ERROR("Firmware has wrong CSS header length %u bytes\n",
> (css_header->header_len * 4));
> - goto out;
> + return;
> }
> readcount += sizeof(struct intel_css_header);
>
> @@ -264,7 +255,7 @@ static void finish_csr_load(const struct firmware *fw,
> void *context)
> (package_header->header_len * 4)) {
> DRM_ERROR("Firmware has wrong package header length %u bytes\n",
> (package_header->header_len * 4));
> - goto out;
> + return;
> }
> readcount += sizeof(struct intel_package_header);
>
> @@ -284,7 +275,7 @@ static void finish_csr_load(const struct firmware *fw,
> void *context)
> }
> if (dmc_offset == CSR_DEFAULT_FW_OFFSET) {
> DRM_ERROR("Firmware not supported for %c stepping\n", stepping);
> - goto out;
> + return;
> }
> readcount += dmc_offset;
>
> @@ -293,7 +284,7 @@ static void finish_csr_load(const struct firmware *fw,
> void *context)
> if (sizeof(struct intel_dmc_header) != (dmc_header->header_len)) {
> DRM_ERROR("Firmware has wrong dmc header length %u bytes\n",
> (dmc_header->header_len));
> - goto out;
> + return;
> }
> readcount += sizeof(struct intel_dmc_header);
>
> @@ -301,7 +292,7 @@ static void
[Intel-gfx] [PATCH 01/13 v4] drm/i915: Add i915_gem_object_create_from_data()
i915_gem_object_create_from_data() is a generic function to save data
from a plain linear buffer in a new pageable gem object that can later
be accessed by the CPU and/or GPU.
We will need this for the microcontroller firmware loading support code.
Derived from i915_gem_object_write(), originally by Alex Dai
v2:
Change of function: now allocates & fills a new object, rather than
writing to an existing object
New name courtesy of Chris Wilson
Explicit domain-setting and other improvements per review comments
by Chris Wilson & Daniel Vetter
v4:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 40
2 files changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 464b28d..3c91507 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2755,6 +2755,8 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
const struct drm_i915_gem_object_ops *ops);
struct drm_i915_gem_object *i915_gem_alloc_object(struct drm_device *dev,
size_t size);
+struct drm_i915_gem_object *i915_gem_object_create_from_data(
+ struct drm_device *dev, const void *data, size_t size);
void i915_init_vm(struct drm_i915_private *dev_priv,
struct i915_address_space *vm);
void i915_gem_free_object(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a0bff41..dbbb649 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5478,3 +5478,43 @@ bool i915_gem_obj_is_pinned(struct drm_i915_gem_object
*obj)
return false;
}
+
+/* Allocate a new GEM object and fill it with the supplied data */
+struct drm_i915_gem_object *
+i915_gem_object_create_from_data(struct drm_device *dev,
+const void *data, size_t size)
+{
+ struct drm_i915_gem_object *obj;
+ struct sg_table *sg;
+ size_t bytes;
+ int ret;
+
+ obj = i915_gem_alloc_object(dev, round_up(size, PAGE_SIZE));
+ if (IS_ERR_OR_NULL(obj))
+ return obj;
+
+ ret = i915_gem_object_set_to_cpu_domain(obj, true);
+ if (ret)
+ goto fail;
+
+ ret = i915_gem_object_get_pages(obj);
+ if (ret)
+ goto fail;
+
+ i915_gem_object_pin_pages(obj);
+ sg = obj->pages;
+ bytes = sg_copy_from_buffer(sg->sgl, sg->nents, (void *)data, size);
+ i915_gem_object_unpin_pages(obj);
+
+ if (WARN_ON(bytes != size)) {
+ DRM_ERROR("Incomplete copy, wrote %zu of %zu", bytes, size);
+ ret = -EFAULT;
+ goto fail;
+ }
+
+ return obj;
+
+fail:
+ drm_gem_object_unreference(&obj->base);
+ return ERR_PTR(ret);
+}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/13 v4] drm/i915: Debugfs interface to read GuC load status
From: Alex Dai
The new node provides access to the status of the GuC-specific loader;
also the scratch registers used for communication between the i915
driver and the GuC firmware.
v2:
Changes to output formats per Chris Wilson's suggestions
v4:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c | 39 +
1 file changed, 39 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 98fd3c9..9ff5f17 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2359,6 +2359,44 @@ static int i915_llc(struct seq_file *m, void *data)
return 0;
}
+static int i915_guc_load_status_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_i915_private *dev_priv = node->minor->dev->dev_private;
+ struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw;
+ u32 tmp, i;
+
+ if (!HAS_GUC_UCODE(dev_priv->dev))
+ return 0;
+
+ seq_printf(m, "GuC firmware status:\n");
+ seq_printf(m, "\tpath: %s\n",
+ guc_fw->guc_fw_path);
+ seq_printf(m, "\tfetch: %s\n",
+ intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status));
+ seq_printf(m, "\tload: %s\n",
+ intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
+ seq_printf(m, "\tversion wanted: %d.%d\n",
+ guc_fw->guc_fw_major_wanted, guc_fw->guc_fw_minor_wanted);
+ seq_printf(m, "\tversion found: %d.%d\n",
+ guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found);
+
+ tmp = I915_READ(GUC_STATUS);
+
+ seq_printf(m, "\nGuC status 0x%08x:\n", tmp);
+ seq_printf(m, "\tBootrom status = 0x%x\n",
+ (tmp & GS_BOOTROM_MASK) >> GS_BOOTROM_SHIFT);
+ seq_printf(m, "\tuKernel status = 0x%x\n",
+ (tmp & GS_UKERNEL_MASK) >> GS_UKERNEL_SHIFT);
+ seq_printf(m, "\tMIA Core status = 0x%x\n",
+ (tmp & GS_MIA_MASK) >> GS_MIA_SHIFT);
+ seq_puts(m, "\nScratch registers:\n");
+ for (i = 0; i < 16; i++)
+ seq_printf(m, "\t%2d: \t0x%x\n", i, I915_READ(SOFT_SCRATCH(i)));
+
+ return 0;
+}
+
static int i915_edp_psr_status(struct seq_file *m, void *data)
{
struct drm_info_node *node = m->private;
@@ -5073,6 +5111,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_gem_hws_bsd", i915_hws_info, 0, (void *)VCS},
{"i915_gem_hws_vebox", i915_hws_info, 0, (void *)VECS},
{"i915_gem_batch_pool", i915_gem_batch_pool_info, 0},
+ {"i915_guc_load_status", i915_guc_load_status_info, 0},
{"i915_frequency_info", i915_frequency_info, 0},
{"i915_hangcheck_info", i915_hangcheck_info, 0},
{"i915_drpc_info", i915_drpc_info, 0},
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/13 v4] drm/i915: Add GuC-related module parameters
From: Alex Dai
Two new module parameters: "enable_guc_submission" which will turn
on submission of batchbuffers via the GuC (when implemented), and
"guc_log_level" which controls the level of debugging logged by the
GuC and captured by the host.
Signed-off-by: Alex Dai
v4:
Mark "enable_guc_submission" unsafe [Daniel Vetter]
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h| 2 ++
drivers/gpu/drm/i915/i915_params.c | 9 +
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3c91507..4a512da 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2606,6 +2606,8 @@ struct i915_params {
bool reset;
bool disable_display;
bool disable_vtd_wa;
+ bool enable_guc_submission;
+ int guc_log_level;
int use_mmio_flip;
int mmio_debug;
bool verbose_state_checks;
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 7983fe4..2791b5a 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -53,6 +53,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
+ .enable_guc_submission = false,
+ .guc_log_level = -1,
};
module_param_named(modeset, i915.modeset, int, 0400);
@@ -186,3 +188,10 @@ MODULE_PARM_DESC(edp_vswing,
"Ignore/Override vswing pre-emph table selection from VBT "
"(0=use value from vbt [default], 1=low power swing(200mV),"
"2=default swing(400mV))");
+
+module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission,
bool, 0400);
+MODULE_PARM_DESC(enable_guc_submission, "Enable GuC submission
(default:false)");
+
+module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
+MODULE_PARM_DESC(guc_log_level,
+ "GuC firmware logging level (-1:disabled (default), 0-3:enabled)");
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/13 v4] drm/i915: Enable GuC firmware log
From: Alex Dai
Allocate a GEM object to hold GuC log data. A debugfs interface
(i915_guc_log_dump) is provided to print out the log content.
v2:
Add struct members at point of use [Chris Wilson]
v4:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_debugfs.c| 29 +++
drivers/gpu/drm/i915/i915_guc_submission.c | 46 ++
drivers/gpu/drm/i915/intel_guc.h | 1 +
3 files changed, 76 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 9ff5f17..13e37d1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2397,6 +2397,34 @@ static int i915_guc_load_status_info(struct seq_file *m,
void *data)
return 0;
}
+static int i915_guc_log_dump(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_device *dev = node->minor->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct drm_i915_gem_object *log_obj = dev_priv->guc.log_obj;
+ u32 *log;
+ int i = 0, pg;
+
+ if (!log_obj)
+ return 0;
+
+ for (pg = 0; pg < log_obj->base.size / PAGE_SIZE; pg++) {
+ log = kmap_atomic(i915_gem_object_get_page(log_obj, pg));
+
+ for (i = 0; i < PAGE_SIZE / sizeof(u32); i += 4)
+ seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
+ *(log + i), *(log + i + 1),
+ *(log + i + 2), *(log + i + 3));
+
+ kunmap_atomic(log);
+ }
+
+ seq_putc(m, '\n');
+
+ return 0;
+}
+
static int i915_edp_psr_status(struct seq_file *m, void *data)
{
struct drm_info_node *node = m->private;
@@ -5112,6 +5140,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_gem_hws_vebox", i915_hws_info, 0, (void *)VECS},
{"i915_gem_batch_pool", i915_gem_batch_pool_info, 0},
{"i915_guc_load_status", i915_guc_load_status_info, 0},
+ {"i915_guc_log_dump", i915_guc_log_dump, 0},
{"i915_frequency_info", i915_frequency_info, 0},
{"i915_hangcheck_info", i915_hangcheck_info, 0},
{"i915_drpc_info", i915_drpc_info, 0},
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 70a0405..e9d46d6 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -75,6 +75,47 @@ static void gem_release_guc_obj(struct drm_i915_gem_object
*obj)
drm_gem_object_unreference(&obj->base);
}
+static void guc_create_log(struct intel_guc *guc)
+{
+ struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ struct drm_i915_gem_object *obj;
+ unsigned long offset;
+ uint32_t size, flags;
+
+ if (i915.guc_log_level < GUC_LOG_VERBOSITY_MIN)
+ return;
+
+ if (i915.guc_log_level > GUC_LOG_VERBOSITY_MAX)
+ i915.guc_log_level = GUC_LOG_VERBOSITY_MAX;
+
+ /* The first page is to save log buffer state. Allocate one
+* extra page for others in case for overlap */
+ size = (1 + GUC_LOG_DPC_PAGES + 1 +
+ GUC_LOG_ISR_PAGES + 1 +
+ GUC_LOG_CRASH_PAGES + 1) << PAGE_SHIFT;
+
+ obj = guc->log_obj;
+ if (!obj) {
+ obj = gem_allocate_guc_obj(dev_priv->dev, size);
+ if (!obj) {
+ /* logging will be off */
+ i915.guc_log_level = -1;
+ return;
+ }
+
+ guc->log_obj = obj;
+ }
+
+ /* each allocated unit is a page */
+ flags = GUC_LOG_VALID | GUC_LOG_NOTIFY_ON_HALF_FULL |
+ (GUC_LOG_DPC_PAGES << GUC_LOG_DPC_SHIFT) |
+ (GUC_LOG_ISR_PAGES << GUC_LOG_ISR_SHIFT) |
+ (GUC_LOG_CRASH_PAGES << GUC_LOG_CRASH_SHIFT);
+
+ offset = i915_gem_obj_ggtt_offset(obj) >> PAGE_SHIFT; /* in pages */
+ guc->log_flags = (offset << GUC_LOG_BUF_ADDR_SHIFT) | flags;
+}
+
/*
* Set up the memory resources to be shared with the GuC. At this point,
* we require just one object that can be mapped through the GGTT.
@@ -99,6 +140,8 @@ int i915_guc_submission_init(struct drm_device *dev)
ida_init(&guc->ctx_ids);
+ guc_create_log(guc);
+
return 0;
}
@@ -107,6 +150,9 @@ void i915_guc_submission_fini(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_guc *guc = &dev_priv->guc;
+ gem_release_guc_obj(dev_priv->guc.log_obj);
+ guc->log_obj = NULL;
+
if (guc->ctx_pool_obj)
ida_destroy(&guc->ctx_ids);
gem_release_guc_obj(guc->ctx_pool_obj);
diff --git a/drivers/gpu/drm/i915/intel_guc.h b/drivers/gpu/drm/i915/intel_guc.h
index be3cad8..5b51b05 100644
--- a/d
[Intel-gfx] [PATCH 04/13 v4] drm/i915: GuC-specific firmware loader
From: Alex Dai
This fetches the required firmware image from the filesystem,
then loads it into the GuC's memory via a dedicated DMA engine.
This patch is derived from GuC loading work originally done by
Vinit Azad and Ben Widawsky.
v2:
Various improvements per review comments by Chris Wilson
v3:
Removed 'wait' parameter to intel_guc_ucode_load() as firmware
prefetch is no longer supported in the common firmware loader,
per Daniel Vetter's request.
Firmware checker callback fn now returns errno rather than bool.
v4:
Squash uC-independent code into GuC-specifc loader [Daniel Vetter]
Don't keep the driver working (by falling back to execlist mode)
if GuC firmware loading fails [Daniel Vetter]
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/Makefile | 3 +
drivers/gpu/drm/i915/i915_dma.c | 4 +
drivers/gpu/drm/i915/i915_drv.h | 11 +
drivers/gpu/drm/i915/i915_gem.c | 13 +
drivers/gpu/drm/i915/i915_reg.h | 4 +-
drivers/gpu/drm/i915/intel_guc.h| 67
drivers/gpu/drm/i915/intel_guc_loader.c | 536
7 files changed, 637 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/intel_guc.h
create mode 100644 drivers/gpu/drm/i915/intel_guc_loader.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index de21965..e604cfe 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -39,6 +39,9 @@ i915-y += i915_cmd_parser.o \
intel_ringbuffer.o \
intel_uncore.o
+# general-purpose microcontroller (GuC) support
+i915-y += intel_guc_loader.o
+
# autogenerated null render state
i915-y += intel_renderstate_gen6.o \
intel_renderstate_gen7.o \
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 066c34c..958ab4f 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -472,6 +472,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
cleanup_gem:
mutex_lock(&dev->struct_mutex);
+ intel_guc_ucode_fini(dev);
i915_gem_cleanup_ringbuffer(dev);
i915_gem_context_fini(dev);
mutex_unlock(&dev->struct_mutex);
@@ -869,6 +870,8 @@ int i915_driver_load(struct drm_device *dev, unsigned long
flags)
intel_uncore_init(dev);
+ intel_guc_ucode_init(dev);
+
/* Load CSR Firmware for SKL */
intel_csr_ucode_init(dev);
@@ -1120,6 +1123,7 @@ int i915_driver_unload(struct drm_device *dev)
flush_workqueue(dev_priv->wq);
mutex_lock(&dev->struct_mutex);
+ intel_guc_ucode_fini(dev);
i915_gem_cleanup_ringbuffer(dev);
i915_gem_context_fini(dev);
mutex_unlock(&dev->struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4a512da..15b9202 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -50,6 +50,7 @@
#include
#include
#include
+#include "intel_guc.h"
/* General customization:
*/
@@ -1694,6 +1695,8 @@ struct drm_i915_private {
struct i915_virtual_gpu vgpu;
+ struct intel_guc guc;
+
struct intel_csr csr;
/* Display CSR-related protection */
@@ -1938,6 +1941,11 @@ static inline struct drm_i915_private
*dev_to_i915(struct device *dev)
return to_i915(dev_get_drvdata(dev));
}
+static inline struct drm_i915_private *guc_to_i915(struct intel_guc *guc)
+{
+ return container_of(guc, struct drm_i915_private, guc);
+}
+
/* Iterate over initialised rings */
#define for_each_ring(ring__, dev_priv__, i__) \
for ((i__) = 0; (i__) < I915_NUM_RINGS; (i__)++) \
@@ -2543,6 +2551,9 @@ struct drm_i915_cmd_table {
#define HAS_CSR(dev) (IS_SKYLAKE(dev))
+#define HAS_GUC_UCODE(dev) (IS_GEN9(dev))
+#define HAS_GUC_SCHED(dev) (IS_GEN9(dev))
+
#define HAS_RESOURCE_STREAMER(dev) (IS_HASWELL(dev) || \
INTEL_INFO(dev)->gen >= 8)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index dbbb649..e020309 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5074,6 +5074,19 @@ i915_gem_init_hw(struct drm_device *dev)
goto out;
}
+ /* We can't enable contexts until all firmware is loaded */
+ ret = intel_guc_ucode_load(dev);
+
+ /*
+* If we got an error and GuC submission is enabled, map
+* the error to -EIO so the GPU will be declared wedged.
+* OTOH, if we didn't intend to use the GuC anyway, just
+* discard the error and carry on.
+*/
+ ret = ret && i915.enable_guc_submission ? -EIO : 0;
+ if (ret)
+ goto out;
+
/* Now it is safe to go back round and do everything else: */
for_each_ring(ring, dev_priv, i) {
[Intel-gfx] [PATCH 00/13 v4] Batch submission via GuC
This patch series enables command submission via the GuC. In this mode, instead of the host CPU driving the execlist port directly, it hands over work items to the GuC, using a doorbell mechanism to tell the GuC that new items have been added to its work queue. The GuC then dispatches contexts to the various GPU engines, and manages the resulting context- switch interrupts. Completion of a batch is however still signalled to the CPU; the GuC is not involved in handling user interrupts. There are two subsequences within the patch series: drm/i915: Add i915_gem_object_create_from_data() drm/i915: Add GuC-related module parameters drm/i915: Add GuC-related header files drm/i915: GuC-specific firmware loader drm/i915: Debugfs interface to read GuC load status These five patches make up the GuC loader and its prerequisites. At this point in the sequence we can load and activate the GuC firmware, but not submit any batches through it. (This is nonetheless a potentially useful state, as the GuC could do other useful work even when not handling batch submissions). drm/i915: Expose two LRC functions for GuC submission mode drm/i915: GuC submission setup, phase 1 drm/i915: Enable GuC firmware log drm/i915: Implementation of GuC client drm/i915: Interrupt routing for GuC submission drm/i915: Integrate GuC-based command submission drm/i915: Debugfs interface for GuC submission statistics drm/i915: Enable GuC submission, where supported In this second section, we implement the GuC submission mechanism, link it into the (execlist-based) submission path, and finally enable it (on supported platforms). On platforms where there is no GuC, or if GuC submission is explicitly disabled, batch submission will revert to using the execlist mechanism directly. On the other hand, if the GuC firmware cannot be found or is invalid, the GPU will be unusable. The GuC firmware itself is not included in this patchset; it is or will be available for download from https://01.org/linuxgraphics/downloads/ This driver works with and requires GuC firmware revision 3.x. It will not work with any firmware version 1.x, as the GuC protocol in those revisions was incompatible and is no longer supported. Ben Widawsky (0): Vinit Azad (0): Michael H. Nguyen (0): created the original versions on which some of these patches are based. Alex Dai (6): drm/i915: Add GuC-related module parameters drm/i915: GuC-specific firmware loader drm/i915: Debugfs interface to read GuC load status drm/i915: GuC submission setup, phase 1 drm/i915: Enable GuC firmware log drm/i915: Integrate GuC-based command submission Dave Gordon (7): drm/i915: Add i915_gem_object_create_from_data() drm/i915: Add GuC-related header files drm/i915: Expose two LRC functions for GuC submission mode drm/i915: Implementation of GuC client drm/i915: Interrupt routing for GuC submission drm/i915: Debugfs interface for GuC submission statistics drm/i915: Enable GuC submission, where supported Documentation/DocBook/drm.tmpl | 14 + drivers/gpu/drm/i915/Makefile | 4 + drivers/gpu/drm/i915/i915_debugfs.c| 110 +++- drivers/gpu/drm/i915/i915_dma.c| 4 + drivers/gpu/drm/i915/i915_drv.h| 15 + drivers/gpu/drm/i915/i915_gem.c| 53 ++ drivers/gpu/drm/i915/i915_guc_reg.h| 102 drivers/gpu/drm/i915/i915_guc_submission.c | 853 + drivers/gpu/drm/i915/i915_params.c | 9 + drivers/gpu/drm/i915/i915_reg.h| 15 +- drivers/gpu/drm/i915/intel_guc.h | 118 drivers/gpu/drm/i915/intel_guc_fwif.h | 245 + drivers/gpu/drm/i915/intel_guc_loader.c| 618 + drivers/gpu/drm/i915/intel_lrc.c | 72 ++- drivers/gpu/drm/i915/intel_lrc.h | 9 + 15 files changed, 2211 insertions(+), 30 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_guc_reg.h create mode 100644 drivers/gpu/drm/i915/i915_guc_submission.c create mode 100644 drivers/gpu/drm/i915/intel_guc.h create mode 100644 drivers/gpu/drm/i915/intel_guc_fwif.h create mode 100644 drivers/gpu/drm/i915/intel_guc_loader.c -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/13 v4] drm/i915: GuC submission setup, phase 1
From: Alex Dai
This adds the first of the data structures used to communicate with the
GuC (the pool of guc_context structures).
We create a GuC-specific wrapper round the GEM object allocator as all
GEM objects shared with the GuC must be pinned into GGTT space at an
address that is NOT in the range [0..WOPCM_SIZE), as that range of GGTT
addresses is not accessible to the GuC (from the GuC's point of view,
it's permanently reserved for other objects such as the BootROM & SRAM).
Later, we will need to allocate additional GuC-sharable objects for the
submission client(s) and the GuC's debug log.
v2:
Remove redundant initialisation [Chris Wilson]
Defer adding struct members until needed [Chris Wilson]
Local functions should pass dev_priv rather than dev [Chris Wilson]
v4:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/Makefile | 3 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 114 +
drivers/gpu/drm/i915/intel_guc.h | 7 ++
drivers/gpu/drm/i915/intel_guc_loader.c| 19 +
4 files changed, 142 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/i915_guc_submission.c
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index e604cfe..23f5612 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -40,7 +40,8 @@ i915-y += i915_cmd_parser.o \
intel_uncore.o
# general-purpose microcontroller (GuC) support
-i915-y += intel_guc_loader.o
+i915-y += intel_guc_loader.o \
+ i915_guc_submission.o
# autogenerated null render state
i915-y += intel_renderstate_gen6.o \
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
new file mode 100644
index 000..70a0405
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -0,0 +1,114 @@
+/*
+ * Copyright © 2014 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
+ * IN THE SOFTWARE.
+ *
+ */
+#include
+#include
+#include "i915_drv.h"
+#include "intel_guc.h"
+
+/**
+ * gem_allocate_guc_obj() - Allocate gem object for GuC usage
+ * @dev: drm device
+ * @size: size of object
+ *
+ * This is a wrapper to create a gem obj. In order to use it inside GuC, the
+ * object needs to be pinned lifetime. Also we must pin it to gtt space other
+ * than [0, GUC_WOPCM_SIZE] because this range is reserved inside GuC.
+ *
+ * Return: A drm_i915_gem_object if successful, otherwise NULL.
+ */
+static struct drm_i915_gem_object *gem_allocate_guc_obj(struct drm_device *dev,
+ u32 size)
+{
+ struct drm_i915_gem_object *obj;
+
+ obj = i915_gem_alloc_object(dev, size);
+ if (!obj)
+ return NULL;
+
+ if (i915_gem_object_get_pages(obj)) {
+ drm_gem_object_unreference(&obj->base);
+ return NULL;
+ }
+
+ if (i915_gem_obj_ggtt_pin(obj, PAGE_SIZE,
+ PIN_OFFSET_BIAS | GUC_WOPCM_SIZE_VALUE)) {
+ drm_gem_object_unreference(&obj->base);
+ return NULL;
+ }
+
+ return obj;
+}
+
+/**
+ * gem_release_guc_obj() - Release gem object allocated for GuC usage
+ * @obj: gem obj to be released
+ */
+static void gem_release_guc_obj(struct drm_i915_gem_object *obj)
+{
+ if (!obj)
+ return;
+
+ if (i915_gem_obj_is_pinned(obj))
+ i915_gem_object_ggtt_unpin(obj);
+
+ drm_gem_object_unreference(&obj->base);
+}
+
+/*
+ * Set up the memory resources to be shared with the GuC. At this point,
+ * we require just one object that can be mapped through the GGTT.
+ */
+int i915_guc_submission_init(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ const size_t ctxsize = sizeof(struct guc_
[Intel-gfx] [PATCH 03/13 v4] drm/i915: Add GuC-related header files
intel_guc_fwif.h contains the subset of the GuC interface that we will need for submission of commands through the GuC. These MUST be kept in sync with the definitions used by the GuC firmware, and updates to this file will (or should) be autogenerated from the source files used to build the firmware. Editing this file is therefore not recommended. i915_guc_reg.h contains definitions of GuC-related hardware: registers, bitmasks, etc. These should match the BSpec. v2: Files renamed & resliced per review comments by Chris Wilson v4: Added DON'T-EDIT-ME warning [Tom O'Rourke] Issue: VIZ-4884 Signed-off-by: Alex Dai Signed-off-by: Dave Gordon --- drivers/gpu/drm/i915/i915_guc_reg.h | 102 ++ drivers/gpu/drm/i915/intel_guc_fwif.h | 245 ++ 2 files changed, 347 insertions(+) create mode 100644 drivers/gpu/drm/i915/i915_guc_reg.h create mode 100644 drivers/gpu/drm/i915/intel_guc_fwif.h diff --git a/drivers/gpu/drm/i915/i915_guc_reg.h b/drivers/gpu/drm/i915/i915_guc_reg.h new file mode 100644 index 000..ccdc6c8 --- /dev/null +++ b/drivers/gpu/drm/i915/i915_guc_reg.h @@ -0,0 +1,102 @@ +/* + * Copyright © 2014 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + * + */ +#ifndef _I915_GUC_REG_H_ +#define _I915_GUC_REG_H_ + +/* Definitions of GuC H/W registers, bits, etc */ + +#define GUC_STATUS 0xc000 +#define GS_BOOTROM_SHIFT 1 +#define GS_BOOTROM_MASK(0x7F << GS_BOOTROM_SHIFT) +#define GS_BOOTROM_RSA_FAILED (0x50 << GS_BOOTROM_SHIFT) +#define GS_UKERNEL_SHIFT 8 +#define GS_UKERNEL_MASK(0xFF << GS_UKERNEL_SHIFT) +#define GS_UKERNEL_LAPIC_DONE (0x30 << GS_UKERNEL_SHIFT) +#define GS_UKERNEL_DPC_ERROR (0x60 << GS_UKERNEL_SHIFT) +#define GS_UKERNEL_READY (0xF0 << GS_UKERNEL_SHIFT) +#define GS_MIA_SHIFT 16 +#define GS_MIA_MASK(0x07 << GS_MIA_SHIFT) + +#define GUC_WOPCM_SIZE 0xc050 +#define GUC_WOPCM_SIZE_VALUE (0x80 << 12) /* 512KB */ +#define GUC_WOPCM_OFFSET 0x8 /* 512KB */ + +#define SOFT_SCRATCH(n)(0xc180 + ((n) * 4)) + +#define UOS_RSA_SCRATCH_0 0xc200 +#define DMA_ADDR_0_LOW 0xc300 +#define DMA_ADDR_0_HIGH0xc304 +#define DMA_ADDR_1_LOW 0xc308 +#define DMA_ADDR_1_HIGH0xc30c +#define DMA_ADDRESS_SPACE_WOPCM(7 << 16) +#define DMA_ADDRESS_SPACE_GTT (8 << 16) +#define DMA_COPY_SIZE 0xc310 +#define DMA_CTRL 0xc314 +#define UOS_MOVE (1<<4) +#define START_DMA (1<<0) +#define DMA_GUC_WOPCM_OFFSET 0xc340 + +#define GEN8_GT_PM_CONFIG 0x138140 +#define GEN9_GT_PM_CONFIG 0x13816c +#define GEN8_GT_DOORBELL_ENABLE(1<<0) + +#define GEN8_GTCR 0x4274 +#define GEN8_GTCR_INVALIDATE (1<<0) + +#define GUC_ARAT_C6DIS 0xA178 + +#define GUC_SHIM_CONTROL 0xc064 +#define GUC_DISABLE_SRAM_INIT_TO_ZEROES (1<<0) +#define GUC_ENABLE_READ_CACHE_LOGIC (1<<1) +#define GUC_ENABLE_MIA_CACHING (1<<2) +#define GUC_GEN10_MSGCH_ENABLE (1<<4) +#define GUC_ENABLE_READ_CACHE_FOR_SRAM_DATA (1<<9) +#define GUC_ENABLE_READ_CACHE_FOR_WOPCM_DATA (1<<10) +#define GUC_ENABLE_MIA_CLOCK_GATING (1<<15) +#define GUC_GEN10_SHIM_WC_ENABLE (1<<21) + +#define GUC_SHIM_CONTROL_VALUE (GUC_DISABLE_SRAM_INIT_TO_ZEROES| \ +GUC_ENABLE_READ_CACHE_LOGIC| \ +GUC_ENABLE_MIA_CACHING | \ +
[Intel-gfx] [PATCH 06/13 v4] drm/i915: Expose two LRC functions for GuC submission mode
GuC submission is basically execlist submission, but with the GuC
handling the actual writes to the ELSP and the resulting context
switch interrupts. So to prepare a context for submission via the
GuC, we need some of the same functions used in execlist mode.
This commit exposes two such functions, changing their names to
better describe what they do (they're related to logical ring
contexts rather than to execlists per se).
v2:
Replaces previous "drm/i915: Move execlists defines from .c to .h"
v3:
Incorporates a change to one of the functions exposed here that was
previously part of an internal patch, but which was omitted from
the version recently committed to drm-intel-nightly:
7a01a0a drm/i915/lrc: Update PDPx registers with lri commands
So we reinstate this change here.
v4:
Drop v3 change, update function parameters due to collision with
8ee3615 drm/i915: Convert execlists_ctx_descriptor() for requests
Issue: VIZ-4884
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/intel_lrc.c | 21 ++---
drivers/gpu/drm/i915/intel_lrc.h | 3 +++
2 files changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d4f8b43..9e121d3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -261,11 +261,11 @@ u32 intel_execlists_ctx_id(struct drm_i915_gem_object
*ctx_obj)
return lrca >> 12;
}
-static uint64_t execlists_ctx_descriptor(struct drm_i915_gem_request *rq)
+uint64_t intel_lr_context_descriptor(struct intel_context *ctx,
+struct intel_engine_cs *ring)
{
- struct intel_engine_cs *ring = rq->ring;
struct drm_device *dev = ring->dev;
- struct drm_i915_gem_object *ctx_obj = rq->ctx->engine[ring->id].state;
+ struct drm_i915_gem_object *ctx_obj = ctx->engine[ring->id].state;
uint64_t desc;
uint64_t lrca = i915_gem_obj_ggtt_offset(ctx_obj);
@@ -303,13 +303,13 @@ static void execlists_elsp_write(struct
drm_i915_gem_request *rq0,
uint64_t desc[2];
if (rq1) {
- desc[1] = execlists_ctx_descriptor(rq1);
+ desc[1] = intel_lr_context_descriptor(rq1->ctx, rq1->ring);
rq1->elsp_submitted++;
} else {
desc[1] = 0;
}
- desc[0] = execlists_ctx_descriptor(rq0);
+ desc[0] = intel_lr_context_descriptor(rq0->ctx, rq0->ring);
rq0->elsp_submitted++;
/* You must always write both descriptors in the order below. */
@@ -328,7 +328,8 @@ static void execlists_elsp_write(struct
drm_i915_gem_request *rq0,
spin_unlock(&dev_priv->uncore.lock);
}
-static int execlists_update_context(struct drm_i915_gem_request *rq)
+/* Update the ringbuffer pointer and tail offset in a saved context image */
+void intel_lr_context_update(struct drm_i915_gem_request *rq)
{
struct intel_engine_cs *ring = rq->ring;
struct i915_hw_ppgtt *ppgtt = rq->ctx->ppgtt;
@@ -358,17 +359,15 @@ static int execlists_update_context(struct
drm_i915_gem_request *rq)
}
kunmap_atomic(reg_state);
-
- return 0;
}
static void execlists_submit_requests(struct drm_i915_gem_request *rq0,
struct drm_i915_gem_request *rq1)
{
- execlists_update_context(rq0);
+ intel_lr_context_update(rq0);
if (rq1)
- execlists_update_context(rq1);
+ intel_lr_context_update(rq1);
execlists_elsp_write(rq0, rq1);
}
@@ -2051,7 +2050,7 @@ populate_lr_context(struct intel_context *ctx, struct
drm_i915_gem_object *ctx_o
reg_state[CTX_RING_TAIL+1] = 0;
reg_state[CTX_RING_BUFFER_START] = RING_START(ring->mmio_base);
/* Ring buffer start address is not known until the buffer is pinned.
-* It is written to the context image in execlists_update_context()
+* It is written to the context image in intel_lr_context_update()
*/
reg_state[CTX_RING_BUFFER_CONTROL] = RING_CTL(ring->mmio_base);
reg_state[CTX_RING_BUFFER_CONTROL+1] =
diff --git a/drivers/gpu/drm/i915/intel_lrc.h b/drivers/gpu/drm/i915/intel_lrc.h
index e0299fb..6ecc0b3 100644
--- a/drivers/gpu/drm/i915/intel_lrc.h
+++ b/drivers/gpu/drm/i915/intel_lrc.h
@@ -73,6 +73,9 @@ int intel_lr_context_deferred_create(struct intel_context
*ctx,
void intel_lr_context_unpin(struct drm_i915_gem_request *req);
void intel_lr_context_reset(struct drm_device *dev,
struct intel_context *ctx);
+void intel_lr_context_update(struct drm_i915_gem_request *rq);
+uint64_t intel_lr_context_descriptor(struct intel_context *ctx,
+struct intel_engine_cs *ring);
/* Execlists */
int intel_sanitize_enable_execlists(struct drm_device *dev, int
enable_execlists);
--
1.9.1
___
Intel-gfx mailing
[Intel-gfx] [PATCH 09/13 v4] drm/i915: Implementation of GuC client
A GuC client has its own doorbell and workqueue. It maintains the
doorbell cache line, process description object and work queue item.
A default guc_client is created for the i915 driver to use for
normal-priority in-order submission.
Note that the created client is not yet ready for use; doorbell
allocation will fail as we haven't yet linked the GuC's context
descriptor to the default contexts for each ring (see later patch).
v2:
Defer adding structure members until needed [Chris Wilson]
Rationalise type declarations [Chris Wilson]
v4:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_guc_submission.c | 649 +
drivers/gpu/drm/i915/intel_guc.h | 42 ++
drivers/gpu/drm/i915/intel_guc_loader.c| 12 +
3 files changed, 703 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index e9d46d6..25d8807 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -27,6 +27,512 @@
#include "intel_guc.h"
/**
+ * DOC: GuC Client
+ *
+ * i915_guc_client:
+ * We use the term client to avoid confusion with contexts. A i915_guc_client
is
+ * equivalent to GuC object guc_context_desc. This context descriptor is
+ * allocated from a pool of 1024 entries. Kernel driver will allocate doorbell
+ * and workqueue for it. Also the process descriptor (guc_process_desc), which
+ * is mapped to client space. So the client can write Work Item then ring the
+ * doorbell.
+ *
+ * To simplify the implementation, we allocate one gem object that contains all
+ * pages for doorbell, process descriptor and workqueue.
+ *
+ * The Scratch registers:
+ * There are 16 MMIO-based registers start from 0xC180. The kernel driver
writes
+ * a value to the action register (SOFT_SCRATCH_0) along with any data. It then
+ * triggers an interrupt on the GuC via another register write (0xC4C8).
+ * Firmware writes a success/fail code back to the action register after
+ * processes the request. The kernel driver polls waiting for this update and
+ * then proceeds.
+ * See host2guc_action()
+ *
+ * Doorbells:
+ * Doorbells are interrupts to uKernel. A doorbell is a single cache line (QW)
+ * mapped into process space.
+ *
+ * Work Items:
+ * There are several types of work items that the host may place into a
+ * workqueue, each with its own requirements and limitations. Currently only
+ * WQ_TYPE_INORDER is needed to support legacy submission via GuC, which
+ * represents in-order queue. The kernel driver packs ring tail pointer and an
+ * ELSP context descriptor dword into Work Item.
+ * See guc_add_workqueue_item()
+ *
+ */
+
+/*
+ * Read GuC command/status register (SOFT_SCRATCH_0)
+ * Return true if it contains a response rather than a command
+ */
+static inline bool host2guc_action_response(struct drm_i915_private *dev_priv,
+ u32 *status)
+{
+ u32 val = I915_READ(SOFT_SCRATCH(0));
+ *status = val;
+ return GUC2HOST_IS_RESPONSE(val);
+}
+
+static int host2guc_action(struct intel_guc *guc, u32 *data, u32 len)
+{
+ struct drm_i915_private *dev_priv = guc_to_i915(guc);
+ u32 status;
+ int i;
+ int ret;
+
+ if (WARN_ON(len < 1 || len > 15))
+ return -EINVAL;
+
+ spin_lock(&dev_priv->guc.host2guc_lock);
+
+ dev_priv->guc.action_count += 1;
+ dev_priv->guc.action_cmd = data[0];
+
+ for (i = 0; i < len; i++)
+ I915_WRITE(SOFT_SCRATCH(i), data[i]);
+
+ POSTING_READ(SOFT_SCRATCH(i - 1));
+
+ I915_WRITE(HOST2GUC_INTERRUPT, HOST2GUC_TRIGGER);
+
+ ret = wait_for_atomic(host2guc_action_response(dev_priv, &status), 10);
+ if (status != GUC2HOST_STATUS_SUCCESS) {
+ /* either GuC doesn't respond, which is a TIMEOUT,
+* or a failure code is returned. */
+ if (ret != -ETIMEDOUT)
+ ret = -EIO;
+
+ DRM_ERROR("GUC: host2guc action 0x%X failed. ret=%d "
+ "status=0x%08X response=0x%08X\n",
+ data[0], ret, status,
+ I915_READ(SOFT_SCRATCH(15)));
+
+ dev_priv->guc.action_fail += 1;
+ dev_priv->guc.action_err = ret;
+ }
+ dev_priv->guc.action_status = status;
+
+ spin_unlock(&dev_priv->guc.host2guc_lock);
+
+ return ret;
+}
+
+/*
+ * Tell the GuC to allocate or deallocate a specific doorbell
+ */
+
+static int host2guc_allocate_doorbell(struct intel_guc *guc,
+ struct i915_guc_client *client)
+{
+ u32 data[2];
+
+ data[0] = HOST2GUC_ACTION_ALLOCATE_DOORBELL;
+ data[1] = client->ctx_index;
+
+ return host2guc_action(guc, data, 2);
+}
+
+static int host2guc_release_doorbell(struct intel_guc *guc,
+
[Intel-gfx] [PATCH 10/13 v4] drm/i915: Interrupt routing for GuC submission
Turn on interrupt steering to route necessary interrupts to GuC.
v4:
Rebased
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_reg.h | 11 +--
drivers/gpu/drm/i915/intel_guc_loader.c | 51 +
2 files changed, 60 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 63728c1..1c2072b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1664,12 +1664,18 @@ enum skl_disp_power_wells {
#define GFX_MODE_GEN7 0x0229c
#define RING_MODE_GEN7(ring) ((ring)->mmio_base+0x29c)
#define GFX_RUN_LIST_ENABLE (1<<15)
+#define GFX_INTERRUPT_STEERING (1<<14)
#define GFX_TLB_INVALIDATE_EXPLICIT (1<<13)
#define GFX_SURFACE_FAULT_ENABLE (1<<12)
#define GFX_REPLAY_MODE (1<<11)
#define GFX_PSMI_GRANULARITY (1<<10)
#define GFX_PPGTT_ENABLE (1<<9)
+#define GFX_FORWARD_VBLANK_MASK (3<<5)
+#define GFX_FORWARD_VBLANK_NEVER (0<<5)
+#define GFX_FORWARD_VBLANK_ALWAYS(1<<5)
+#define GFX_FORWARD_VBLANK_COND (2<<5)
+
#define VLV_DISPLAY_BASE 0x18
#define VLV_MIPI_BASE VLV_DISPLAY_BASE
@@ -5683,11 +5689,12 @@ enum skl_disp_power_wells {
#define GEN8_GT_IIR(which) (0x44308 + (0x10 * (which)))
#define GEN8_GT_IER(which) (0x4430c + (0x10 * (which)))
-#define GEN8_BCS_IRQ_SHIFT 16
#define GEN8_RCS_IRQ_SHIFT 0
-#define GEN8_VCS2_IRQ_SHIFT 16
+#define GEN8_BCS_IRQ_SHIFT 16
#define GEN8_VCS1_IRQ_SHIFT 0
+#define GEN8_VCS2_IRQ_SHIFT 16
#define GEN8_VECS_IRQ_SHIFT 0
+#define GEN8_WD_IRQ_SHIFT 16
#define GEN8_DE_PIPE_ISR(pipe) (0x44400 + (0x10 * (pipe)))
#define GEN8_DE_PIPE_IMR(pipe) (0x44404 + (0x10 * (pipe)))
diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 25ba29f..2aa9227 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -79,6 +79,53 @@ const char *intel_guc_fw_status_repr(enum
intel_guc_fw_status status)
}
};
+static void direct_interrupts_to_host(struct drm_i915_private *dev_priv)
+{
+ struct intel_engine_cs *ring;
+ int i, irqs;
+
+ /* tell all command streamers NOT to forward interrupts and vblank to
GuC */
+ irqs = _MASKED_FIELD(GFX_FORWARD_VBLANK_MASK, GFX_FORWARD_VBLANK_NEVER);
+ irqs |= _MASKED_BIT_DISABLE(GFX_INTERRUPT_STEERING);
+ for_each_ring(ring, dev_priv, i)
+ I915_WRITE(RING_MODE_GEN7(ring), irqs);
+
+ /* tell DE to send nothing to GuC */
+ I915_WRITE(DE_GUCRMR, ~0);
+
+ /* route all GT interrupts to the host */
+ I915_WRITE(GUC_BCS_RCS_IER, 0);
+ I915_WRITE(GUC_VCS2_VCS1_IER, 0);
+ I915_WRITE(GUC_WD_VECS_IER, 0);
+}
+
+static void direct_interrupts_to_guc(struct drm_i915_private *dev_priv)
+{
+ struct intel_engine_cs *ring;
+ int i, irqs;
+
+ /* tell all command streamers to forward interrupts and vblank to GuC */
+ irqs = _MASKED_FIELD(GFX_FORWARD_VBLANK_MASK,
GFX_FORWARD_VBLANK_ALWAYS);
+ irqs |= _MASKED_BIT_ENABLE(GFX_INTERRUPT_STEERING);
+ for_each_ring(ring, dev_priv, i)
+ I915_WRITE(RING_MODE_GEN7(ring), irqs);
+
+ /* tell DE to send (all) flip_done to GuC */
+ irqs = DERRMR_PIPEA_PRI_FLIP_DONE | DERRMR_PIPEA_SPR_FLIP_DONE |
+ DERRMR_PIPEB_PRI_FLIP_DONE | DERRMR_PIPEB_SPR_FLIP_DONE |
+ DERRMR_PIPEC_PRI_FLIP_DONE | DERRMR_PIPEC_SPR_FLIP_DONE;
+ /* Unmasked bits will cause GuC response message to be sent */
+ I915_WRITE(DE_GUCRMR, ~irqs);
+
+ /* route USER_INTERRUPT to Host, all others are sent to GuC. */
+ irqs = GT_RENDER_USER_INTERRUPT << GEN8_RCS_IRQ_SHIFT |
+ GT_RENDER_USER_INTERRUPT << GEN8_BCS_IRQ_SHIFT;
+ /* These three registers have the same bit definitions */
+ I915_WRITE(GUC_BCS_RCS_IER, ~irqs);
+ I915_WRITE(GUC_VCS2_VCS1_IER, ~irqs);
+ I915_WRITE(GUC_WD_VECS_IER, ~irqs);
+}
+
static u32 get_gttype(struct drm_i915_private *dev_priv)
{
/* XXX: GT type based on PCI device ID? field seems unused by fw */
@@ -427,6 +474,7 @@ int intel_guc_ucode_load(struct drm_device *dev)
intel_guc_fw_status_repr(guc_fw->guc_fw_fetch_status),
intel_guc_fw_status_repr(guc_fw->guc_fw_load_status));
+ direct_interrupts_to_host(dev_priv);
i915_guc_submission_disable(dev);
if (guc_fw->guc_fw_fetch_status == GUC_FIRMWARE_NONE)
@@ -485,6 +533,7 @@ int intel_guc_ucode_load(struct drm_device *dev)
err = i915_guc_submission_enable(dev);
if (err)
goto fail;
+ direct_interrupts_to_guc(dev_priv);
}
return 0;
@@ -493,6 +542,7 @@ fail:
if (guc_fw->guc_fw_load_status == GUC_FIRMWARE_PENDING)
guc_fw->guc_fw_load_s
[Intel-gfx] [PATCH 11/13 v4] drm/i915: Integrate GuC-based command submission
From: Alex Dai
GuC-based submission is mostly the same as execlist mode, up to
intel_logical_ring_advance_and_submit(), where the context being
dispatched would be added to the execlist queue; at this point
we submit the context to the GuC backend instead.
There are, however, a few other changes also required, notably:
1. Contexts must be pinned at GGTT addresses accessible by the GuC
i.e. NOT in the range [0..WOPCM_SIZE), so we have to add the
PIN_OFFSET_BIAS flag to the relevant GGTT-pinning calls.
2. The GuC's TLB must be invalidated after a context is pinned at
a new GGTT address.
3. GuC firmware uses the one page before Ring Context as shared data.
Therefore, whenever driver wants to get base address of LRC, we
will offset one page for it. LRC_PPHWSP_PN is defined as the page
number of LRCA.
4. In the work queue used to pass requests to the GuC, the GuC
firmware requires the ring-tail-offset to be represented as an
11-bit value, expressed in QWords. Therefore, the ringbuffer
size must be reduced to the representable range (4 pages).
v2:
Defer adding #defines until needed [Chris Wilson]
Rationalise type declarations [Chris Wilson]
v4:
Squashed kerneldoc patch into here [Daniel Vetter]
Issue: VIZ-4884
Signed-off-by: Alex Dai
Signed-off-by: Dave Gordon
---
Documentation/DocBook/drm.tmpl | 14
drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 52 +++---
drivers/gpu/drm/i915/intel_guc.h | 1 +
drivers/gpu/drm/i915/intel_lrc.c | 51 -
drivers/gpu/drm/i915/intel_lrc.h | 6
6 files changed, 106 insertions(+), 20 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 596b11d..0ff5fd7 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -4223,6 +4223,20 @@ int num_ioctls;
+ GuC-based Command Submission
+
+GuC
+!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC-specific firmware loader
+!Idrivers/gpu/drm/i915/intel_guc_loader.c
+
+
+GuC Client
+!Pdrivers/gpu/drm/i915/intel_guc_submission.c GuC-based command submissison
+!Idrivers/gpu/drm/i915/intel_guc_submission.c
+
+
+
+
Tracing
This sections covers all things related to the tracepoints implemented in
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 13e37d1..d93732a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1982,7 +1982,7 @@ static void i915_dump_lrc_obj(struct seq_file *m,
return;
}
- page = i915_gem_object_get_page(ctx_obj, 1);
+ page = i915_gem_object_get_page(ctx_obj, LRC_STATE_PN);
if (!WARN_ON(page == NULL)) {
reg_state = kmap_atomic(page);
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c
b/drivers/gpu/drm/i915/i915_guc_submission.c
index 25d8807..c5c9fbf 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -346,18 +346,58 @@ static void guc_init_proc_desc(struct intel_guc *guc,
static void guc_init_ctx_desc(struct intel_guc *guc,
struct i915_guc_client *client)
{
+ struct intel_context *ctx = client->owner;
struct guc_context_desc desc;
struct sg_table *sg;
+ int i;
memset(&desc, 0, sizeof(desc));
desc.attribute = GUC_CTX_DESC_ATTR_ACTIVE | GUC_CTX_DESC_ATTR_KERNEL;
desc.context_id = client->ctx_index;
desc.priority = client->priority;
- desc.engines_used = (1 << RCS) | (1 << VCS) | (1 << BCS) |
- (1 << VECS) | (1 << VCS2); /* all engines */
desc.db_id = client->doorbell_id;
+ for (i = 0; i < I915_NUM_RINGS; i++) {
+ struct guc_execlist_context *lrc = &desc.lrc[i];
+ struct intel_ringbuffer *ringbuf = ctx->engine[i].ringbuf;
+ struct intel_engine_cs *ring;
+ struct drm_i915_gem_object *obj;
+ uint64_t ctx_desc;
+
+ /* TODO: We have a design issue to be solved here. Only when we
+* receive the first batch, we know which engine is used by the
+* user. But here GuC expects the lrc and ring to be pinned. It
+* is not an issue for default context, which is the only one
+* for now who owns a GuC client. But for future owner of GuC
+* client, need to make sure lrc is pinned prior to enter here.
+*/
+ obj = ctx->engine[i].state;
+ if (!obj)
+ break;
+
+ ring = ringbuf->ring;
+ ctx_desc = intel_lr_context_descriptor(ctx, ring);
+ lrc->context_desc = (u32)ct
[Intel-gfx] [PATCH 13/13 v4] drm/i915: Enable GuC submission, where supported
Signed-off-by: Dave Gordon
v4:
Rebased
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_params.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 2791b5a..8bb1719 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -53,7 +53,7 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
- .enable_guc_submission = false,
+ .enable_guc_submission = true,
.guc_log_level = -1,
};
@@ -190,7 +190,7 @@ MODULE_PARM_DESC(edp_vswing,
"2=default swing(400mV))");
module_param_named_unsafe(enable_guc_submission, i915.enable_guc_submission,
bool, 0400);
-MODULE_PARM_DESC(enable_guc_submission, "Enable GuC submission
(default:false)");
+MODULE_PARM_DESC(enable_guc_submission, "Enable GuC submission
(default:true)");
module_param_named(guc_log_level, i915.guc_log_level, int, 0400);
MODULE_PARM_DESC(guc_log_level,
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/13 v4] drm/i915: Debugfs interface for GuC submission statistics
This provides a means of reading status and counts relating
to GuC actions and submissions.
v2:
Remove surplus blank line in output [Chris Wilson]
v4:
Rebased
Signed-off-by: Dave Gordon
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/i915_debugfs.c | 40 +
1 file changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index d93732a..cebb93c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2397,6 +2397,45 @@ static int i915_guc_load_status_info(struct seq_file *m,
void *data)
return 0;
}
+static int i915_guc_info(struct seq_file *m, void *data)
+{
+ struct drm_info_node *node = m->private;
+ struct drm_device *dev = node->minor->dev;
+ struct drm_i915_private *dev_priv = dev->dev_private;
+ struct intel_guc guc;
+ struct i915_guc_client client = { .client_obj = 0 };
+
+ if (!HAS_GUC_SCHED(dev_priv->dev))
+ return 0;
+
+ /* Take a local copy of the GuC data, so we can dump it at leisure */
+ spin_lock(&dev_priv->guc.host2guc_lock);
+ guc = dev_priv->guc;
+ if (guc.execbuf_client) {
+ spin_lock(&guc.execbuf_client->wq_lock);
+ client = *guc.execbuf_client;
+ spin_unlock(&guc.execbuf_client->wq_lock);
+ }
+ spin_unlock(&dev_priv->guc.host2guc_lock);
+
+ seq_printf(m, "GuC total action count: %llu\n", guc.action_count);
+ seq_printf(m, "GuC last action command: 0x%x\n", guc.action_cmd);
+ seq_printf(m, "GuC last action status: 0x%x\n", guc.action_status);
+
+ seq_printf(m, "GuC action failure count: %u\n", guc.action_fail);
+ seq_printf(m, "GuC last action error code: %d\n", guc.action_err);
+
+ seq_printf(m, "\nGuC execbuf client @ %p:\n", guc.execbuf_client);
+ seq_printf(m, "\tTotal submissions: %llu\n", client.submissions);
+ seq_printf(m, "\tFailed to queue: %u\n", client.q_fail);
+ seq_printf(m, "\tFailed doorbell: %u\n", client.b_fail);
+ seq_printf(m, "\tLast submission result: %d\n", client.retcode);
+
+ /* Add more as required ... */
+
+ return 0;
+}
+
static int i915_guc_log_dump(struct seq_file *m, void *data)
{
struct drm_info_node *node = m->private;
@@ -5139,6 +5178,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_gem_hws_bsd", i915_hws_info, 0, (void *)VCS},
{"i915_gem_hws_vebox", i915_hws_info, 0, (void *)VECS},
{"i915_gem_batch_pool", i915_gem_batch_pool_info, 0},
+ {"i915_guc_info", i915_guc_info, 0},
{"i915_guc_load_status", i915_guc_load_status_info, 0},
{"i915_guc_log_dump", i915_guc_log_dump, 0},
{"i915_frequency_info", i915_frequency_info, 0},
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fbdev_set_par reliably invalidating frontbuffer
2015-07-09 13:56 GMT-03:00 Rodrigo Vivi : > fbdev_set_par is called when fbcon is taking over control. > In the past frontbuffer was being invalidated on > set_to_gtt_domain, but it moved to set_domain fixing that case, > but left this behind. > > Commit that changed this fixing set_domain case was: > > commit 031b698a77a70a6c394568034437b5486a44e868 > Author: Daniel Vetter > Date: Fri Jun 26 19:35:16 2015 +0200 > > drm/i915: Unconditionally do fb tracking invalidate in set_domain > > Since we are also invalidating in other fbdev cases this one > was masked here. At least until now that I found this corner > case: On boot with plymouth doing a splash screen > when returning to the console frontbuffer wans't being invalidated > causing missed screen updates with PSR enabled. > > So this patch fixes this issue. > > v2: Make invalidate directly and unconditionally and > fix commit message indicating the set_domain fix > as pointed out by Daniel. > v3: Remove unecessary if(obj) added by mistake The commit message is a little confusing. Also, I'm not 100% sure of this since I'm not the fbcon specialist, but apparently this commit is needed for the FBC test i just submitted as a reply to patch 7. So: Reviewed-by: Paulo Zanoni > > Cc: Paulo Zanoni > Cc: Daniel Vetter > Signed-off-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_fbdev.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c > b/drivers/gpu/drm/i915/intel_fbdev.c > index 2a1724e..25ce7b6 100644 > --- a/drivers/gpu/drm/i915/intel_fbdev.c > +++ b/drivers/gpu/drm/i915/intel_fbdev.c > @@ -63,8 +63,7 @@ static int intel_fbdev_set_par(struct fb_info *info) > * now until we solve this for real. > */ > mutex_lock(&fb_helper->dev->struct_mutex); > - ret = i915_gem_object_set_to_gtt_domain(ifbdev->fb->obj, > - true); > + intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); > mutex_unlock(&fb_helper->dev->struct_mutex); > } > > -- > 2.1.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 00/11] TDR/watchdog timeout support for gen8
On Mon, Jun 08, 2015 at 06:03:18PM +0100, Tomas Elf wrote: > This patch series introduces the following features: > > * Feature 1: TDR (Timeout Detection and Recovery) for gen8 execlist mode. > * Feature 2: Watchdog Timeout (a.k.a "media engine reset") for gen8. > * Feature 3. Context Submission Status Consistency checking The high level design is reasonable and conceptually extends the current system in fairly obvious ways. In terms of discussing the implementation, I think this can be phased as: 0. Move to a per-engine hangcheck 1. Add fake-interrupt recovery for CSSC I think this can be done without changing the hangcheck heuristics at all - we just need to think carefully about recovery (which is a nice precursor to per-engine reset). I may be wrong, and so would like to be told so early on! If the fake interrupt recovery is done as part of the reset handler, we should have (one) fewer concurrency issues to worry about. (In a similar vein, I think we should move the missed interupt handler for legacy out of hangcheck, partly to simplify some very confusing code and partly so that we have fewer deviations between legacy/execlists paths.) It also gets us thinking about the consistency detection and when it is viable to do a fake-interrupt and when we must do a full-reset (for example, we only want to fake-interrupt if the consistency check says the GPU is idle, and we definitely want to reset everything if the GPU is executing an alien context.) A test here would be to suspend the execlists irq and wait for the recovery. Cheekily we could punch the irq eir by root mmio and check hangcheck automagically recovers. Whilst it would be nice to add the watchdog next, since it is conceptually quite simple and basically just a new hangcheck source with fancy setup - fast hangcheck without soft reset makes for an easy DoS. 2. TDR Given that we have a consistency check and begun to extend the reset path, we can implement a soft reset that only skips the hung request. (The devil is in the details, whilst the design here looked solid, I think the LRC recovery code could be simplified - I didn't feel another requeue path was required given that we need only pretend a request completed (fixing up the context image as required) and then use the normal unqueue.) There is also quite a bit of LRC cleanup on the lists which would be useful here. Lots of tests for concurrent engine utilisation, multiple contexts, etc and ensuring that a hang in one does not affect independent work (engines, batches, contexts). 3. Watchdog A new fast hangcheck source. So concurrency, promotion (relative scoring between watchdog / hangcheck) and issue with not programming the ring correctly (beware the interrupt after performing a dispatch and programming the tail, needs either reserved space, inlining into the dispatch etc). The only thing of remark here is the uapi. It is a server feature (interactive clients are less likely to tolerate data being thrown away). Do we want an execbuf bit or context param? An execbuf bit allows switching between two watchdog timers (or on/off), but we have many more context params available than bits. Do we want to expose context params to set the fast/slow timeouts? We haven't found any GL spec that descibe controllable watchdogs, so the ultimate uapi requirements are unknown. My feeling is that we want to do the initial uapi through context params, and start with a single fast watchdog timeout value. This is sufficient for testing and probably for most use cases. This can easily be extended by adding an execbuf bit to switch between two values and a context param to set the second value. (If the second value isn't set, the execbuf bit dosn't do anything the watchdog is always programmed to the user value. If the second value is set (maybe infinite), then the execbuf bit is used to select which timeout to use for that batch.) But given that this is a server-esque feature, it is likely to be a setting the userspace driver imposes upon its clients, and there is unlikely to be the need to switch timeouts within any one client. The tests here would focus on the uapi and ensuring that if the client asks for a 60ms hang detection, then all work packets take at most 60ms to complete. Hmm, add wait_ioctl to the list of uapi that should report -EIO. > drivers/gpu/drm/i915/i915_debugfs.c | 146 +- > drivers/gpu/drm/i915/i915_drv.c | 201 > drivers/gpu/drm/i915/intel_lrc.c| 858 > ++- The balance here feels wrong ;-) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fbdev restore mode needs to invalidate frontbuffer
2015-07-08 20:25 GMT-03:00 Rodrigo Vivi :
> This fbdev restore mode was another corner case that was now
> calling frontbuffer flip and flush and making we miss
> screen updates with PSR enabled.
>
> So let's also add the invalidate hack here while we don't have
> a reliable dirty fbdev op.
>
> v2: As pointed by Paulo: removed seg fault risk, used fb_helper
> when possible and put brackets on if.
>
> Cc: Paulo Zanoni
> Signed-off-by: Rodrigo Vivi
I just realized the other places that call intel_fb_obj_invalidate()
on this file have a huge FIXME comment. With or without that:
Reviewed-by: Paulo Zanoni
You/Daniel may also want to add:
Testcase: igt/kms_fbcon_fbt/psr
> ---
> drivers/gpu/drm/i915/intel_fbdev.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 44c9ccc..fe176d8 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -825,11 +825,20 @@ void intel_fbdev_restore_mode(struct drm_device *dev)
> {
> int ret;
> struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_fbdev *ifbdev = dev_priv->fbdev;
> + struct drm_fb_helper *fb_helper;
>
> - if (!dev_priv->fbdev)
> + if (!ifbdev)
> return;
>
> - ret =
> drm_fb_helper_restore_fbdev_mode_unlocked(&dev_priv->fbdev->helper);
> - if (ret)
> + fb_helper = &ifbdev->helper;
> +
> + ret = drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
> + if (ret) {
> DRM_DEBUG("failed to restore crtc mode\n");
> + } else {
> + mutex_lock(&fb_helper->dev->struct_mutex);
> + intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
> + mutex_unlock(&fb_helper->dev->struct_mutex);
> + }
> }
> --
> 2.1.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fbdev restore mode needs to invalidate frontbuffer
Those "FIXME" are for atomic fb ops callbacks what I don't believe that applies
for this case.
-Original Message-
From: Paulo Zanoni [mailto:przan...@gmail.com]
Sent: Thursday, July 09, 2015 11:54 AM
To: Vivi, Rodrigo
Cc: Intel Graphics Development; Zanoni, Paulo R
Subject: Re: [Intel-gfx] [PATCH] drm/i915: fbdev restore mode needs to
invalidate frontbuffer
2015-07-08 20:25 GMT-03:00 Rodrigo Vivi :
> This fbdev restore mode was another corner case that was now calling
> frontbuffer flip and flush and making we miss screen updates with PSR
> enabled.
>
> So let's also add the invalidate hack here while we don't have a
> reliable dirty fbdev op.
>
> v2: As pointed by Paulo: removed seg fault risk, used fb_helper
> when possible and put brackets on if.
>
> Cc: Paulo Zanoni
> Signed-off-by: Rodrigo Vivi
I just realized the other places that call intel_fb_obj_invalidate() on this
file have a huge FIXME comment. With or without that:
Reviewed-by: Paulo Zanoni
You/Daniel may also want to add:
Testcase: igt/kms_fbcon_fbt/psr
> ---
> drivers/gpu/drm/i915/intel_fbdev.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 44c9ccc..fe176d8 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -825,11 +825,20 @@ void intel_fbdev_restore_mode(struct drm_device
> *dev) {
> int ret;
> struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_fbdev *ifbdev = dev_priv->fbdev;
> + struct drm_fb_helper *fb_helper;
>
> - if (!dev_priv->fbdev)
> + if (!ifbdev)
> return;
>
> - ret =
> drm_fb_helper_restore_fbdev_mode_unlocked(&dev_priv->fbdev->helper);
> - if (ret)
> + fb_helper = &ifbdev->helper;
> +
> + ret = drm_fb_helper_restore_fbdev_mode_unlocked(fb_helper);
> + if (ret) {
> DRM_DEBUG("failed to restore crtc mode\n");
> + } else {
> + mutex_lock(&fb_helper->dev->struct_mutex);
> + intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT);
> + mutex_unlock(&fb_helper->dev->struct_mutex);
> + }
> }
> --
> 2.1.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Paulo Zanoni
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915: fix the FBC work allocation failure path
From: Paulo Zanoni
Always update the currrent crtc, fb and vertical offset after calling
enable_fbc. We were forgetting to do so along the failure paths when
enabling fbc synchronously. Fix this with a new helper to enable_fbc()
and update the state simultaneously.
v2: Improve commit message (Chris).
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_fbc.c | 27 +--
1 file changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 1448746..64f317a 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -308,6 +308,18 @@ bool intel_fbc_enabled(struct drm_i915_private *dev_priv)
return dev_priv->fbc.enabled;
}
+static void intel_fbc_enable(struct intel_crtc *crtc,
+struct drm_framebuffer *fb)
+{
+ struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
+
+ dev_priv->fbc.enable_fbc(crtc);
+
+ dev_priv->fbc.crtc = crtc;
+ dev_priv->fbc.fb_id = fb->base.id;
+ dev_priv->fbc.y = crtc->base.y;
+}
+
static void intel_fbc_work_fn(struct work_struct *__work)
{
struct intel_fbc_work *work =
@@ -321,13 +333,8 @@ static void intel_fbc_work_fn(struct work_struct *__work)
/* Double check that we haven't switched fb without cancelling
* the prior work.
*/
- if (crtc_fb == work->fb) {
- dev_priv->fbc.enable_fbc(work->crtc);
-
- dev_priv->fbc.crtc = work->crtc;
- dev_priv->fbc.fb_id = crtc_fb->base.id;
- dev_priv->fbc.y = work->crtc->base.y;
- }
+ if (crtc_fb == work->fb)
+ intel_fbc_enable(work->crtc, work->fb);
dev_priv->fbc.fbc_work = NULL;
}
@@ -361,7 +368,7 @@ static void intel_fbc_cancel_work(struct drm_i915_private
*dev_priv)
dev_priv->fbc.fbc_work = NULL;
}
-static void intel_fbc_enable(struct intel_crtc *crtc)
+static void intel_fbc_schedule_enable(struct intel_crtc *crtc)
{
struct intel_fbc_work *work;
struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
@@ -373,7 +380,7 @@ static void intel_fbc_enable(struct intel_crtc *crtc)
work = kzalloc(sizeof(*work), GFP_KERNEL);
if (work == NULL) {
DRM_ERROR("Failed to allocate FBC work structure\n");
- dev_priv->fbc.enable_fbc(crtc);
+ intel_fbc_enable(crtc, crtc->base.primary->fb);
return;
}
@@ -826,7 +833,7 @@ static void __intel_fbc_update(struct drm_i915_private
*dev_priv)
__intel_fbc_disable(dev_priv);
}
- intel_fbc_enable(intel_crtc);
+ intel_fbc_schedule_enable(intel_crtc);
dev_priv->fbc.no_fbc_reason = FBC_OK;
return;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm/i915: check for the supported strides on HSW+ FBC
From: Paulo Zanoni
I could only find the restrictions for HSW+, but I think it's safe to
assume that the older platforms also can't support the configurations
HSW can't support. The older platforms probably have additional
restrictions, so we need to figure out those and implement them later.
Let's not block HSW+ FBC based on missing information for the older
platforms.
v2
- Just WARN_ON() the strides that should have been caught earlier
(Daniel)
- Make it a new function since I expect this to grow more.
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_fbc.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 768d1db..6cde34f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -937,6 +937,7 @@ struct i915_fbc {
FBC_CHIP_DEFAULT, /* disabled by default on this chip */
FBC_ROTATION, /* rotation is not supported */
FBC_IN_DBG_MASTER, /* kernel debugger is active */
+ FBC_BAD_STRIDE, /* stride is not supported */
} no_fbc_reason;
bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 0a24e96..f221c0e 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -501,6 +501,8 @@ const char *intel_no_fbc_reason_str(enum no_fbc_reason
reason)
return "rotation unsupported";
case FBC_IN_DBG_MASTER:
return "Kernel debugger is active";
+ case FBC_BAD_STRIDE:
+ return "framebuffer stride not supported";
default:
MISSING_CASE(reason);
return "unknown reason";
@@ -694,6 +696,22 @@ static int intel_fbc_setup_cfb(struct drm_i915_private
*dev_priv, int size,
return intel_fbc_alloc_cfb(dev_priv, size, fb_cpp);
}
+static bool stride_is_valid(unsigned int stride)
+{
+ /* TODO: we need to figure out what are the stride restrictions for the
+* older platforms. */
+
+ /* These should have been caught earlier. */
+ WARN_ON(stride < 512);
+ WARN_ON((stride & (64 - 1)) != 0);
+
+ /* These are additional FBC restrictions. */
+ if (stride > 16385)
+ return false;
+
+ return true;
+}
+
/**
* __intel_fbc_update - enable/disable FBC as needed, unlocked
* @dev_priv: i915 device instance
@@ -804,6 +822,11 @@ static void __intel_fbc_update(struct drm_i915_private
*dev_priv)
goto out_disable;
}
+ if (!stride_is_valid(fb->pitches[0])) {
+ set_no_fbc_reason(dev_priv, FBC_BAD_STRIDE);
+ goto out_disable;
+ }
+
/* If the kernel debugger is active, always disable compression */
if (in_dbg_master()) {
set_no_fbc_reason(dev_priv, FBC_IN_DBG_MASTER);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fbdev restore mode needs to invalidate frontbuffer
On Thu, Jul 09, 2015 at 07:00:34PM +, Vivi, Rodrigo wrote: > Those "FIXME" are for atomic fb ops callbacks what I don't believe that > applies for this case. Yeah intel_fbdev_restore_mode can't be called from atomic context, no need for a FIXME here. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: fbdev_set_par reliably invalidating frontbuffer
On Thu, Jul 09, 2015 at 03:46:17PM -0300, Paulo Zanoni wrote: > 2015-07-09 13:56 GMT-03:00 Rodrigo Vivi : > > fbdev_set_par is called when fbcon is taking over control. > > In the past frontbuffer was being invalidated on > > set_to_gtt_domain, but it moved to set_domain fixing that case, > > but left this behind. > > > > Commit that changed this fixing set_domain case was: > > > > commit 031b698a77a70a6c394568034437b5486a44e868 > > Author: Daniel Vetter > > Date: Fri Jun 26 19:35:16 2015 +0200 > > > > drm/i915: Unconditionally do fb tracking invalidate in set_domain > > > > Since we are also invalidating in other fbdev cases this one > > was masked here. At least until now that I found this corner > > case: On boot with plymouth doing a splash screen > > when returning to the console frontbuffer wans't being invalidated > > causing missed screen updates with PSR enabled. > > > > So this patch fixes this issue. > > > > v2: Make invalidate directly and unconditionally and > > fix commit message indicating the set_domain fix > > as pointed out by Daniel. > > v3: Remove unecessary if(obj) added by mistake > > The commit message is a little confusing. Also, I'm not 100% sure of > this since I'm not the fbcon specialist, but apparently this commit is > needed for the FBC test i just submitted as a reply to patch 7. So: I clarified the commit message a bit and pulled in all the remaining patches from this series. Thanks, Daniel > > Reviewed-by: Paulo Zanoni > > > > > Cc: Paulo Zanoni > > Cc: Daniel Vetter > > Signed-off-by: Rodrigo Vivi > > --- > > drivers/gpu/drm/i915/intel_fbdev.c | 3 +-- > > 1 file changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c > > b/drivers/gpu/drm/i915/intel_fbdev.c > > index 2a1724e..25ce7b6 100644 > > --- a/drivers/gpu/drm/i915/intel_fbdev.c > > +++ b/drivers/gpu/drm/i915/intel_fbdev.c > > @@ -63,8 +63,7 @@ static int intel_fbdev_set_par(struct fb_info *info) > > * now until we solve this for real. > > */ > > mutex_lock(&fb_helper->dev->struct_mutex); > > - ret = i915_gem_object_set_to_gtt_domain(ifbdev->fb->obj, > > - true); > > + intel_fb_obj_invalidate(ifbdev->fb->obj, ORIGIN_GTT); > > mutex_unlock(&fb_helper->dev->struct_mutex); > > } > > > > -- > > 2.1.0 > > > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > Paulo Zanoni -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/12] drm/i915: Only allow rpm on gen9+ with dmc loaded
Instead of trying to deal with this complexity we'll simply require
that the dmc firmware is available for runtime pm support. We do that
by not releasing the rpm reference we acquire when starting the
firmware loader work. Note that since we hold a rpm reference (and rpm
get/put is synchronized with its own locking already) there's no need
for any additional synchronization between the dmc loader and the rpm
entry/exit code.
Hence we can remove all dmc_load_status_get calls, they don't do
anything any more.
Cc: Animesh Manna
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_csr.c| 9 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 17 +++--
2 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 16cd9dae1c1b..03d83892cdb0 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -393,8 +393,11 @@ static void finish_csr_load(const struct firmware *fw,
void *context)
out:
if (fw_loaded)
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
- else
- intel_csr_load_status_set(dev_priv, FW_FAILED);
+
+ /*
+* We require the dmc firmware for runtime pm on gen9+ - leak the rpm
+* reference in case this failed to disable rpm on.
+*/
release_firmware(fw);
}
@@ -462,8 +465,6 @@ void intel_csr_ucode_fini(struct drm_device *dev)
void assert_csr_loaded(struct drm_i915_private *dev_priv)
{
- WARN(intel_csr_load_status_get(dev_priv) != FW_LOADED,
-"CSR is not loaded.\n");
WARN(!I915_READ(CSR_PROGRAM_BASE),
"CSR program storage start is NULL\n");
WARN(!I915_READ(CSR_SSP_BASE), "CSR SSP Base Not fine\n");
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 2628b21ff2c0..ed8c0cee738f 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -644,21 +644,10 @@ static void skl_set_power_well(struct drm_i915_private
*dev_priv,
if ((GEN9_ENABLE_DC5(dev) || SKL_ENABLE_DC6(dev)) &&
power_well->data == SKL_DISP_PW_2) {
- enum csr_state state;
- /* TODO: wait for a completion event or
-* similar here instead of busy
-* waiting using wait_for function.
-*/
- wait_for((state =
intel_csr_load_status_get(dev_priv)) !=
- FW_UNINITIALIZED, 1000);
- if (state != FW_LOADED)
- DRM_ERROR("CSR firmware not ready
(%d)\n",
- state);
+ if (SKL_ENABLE_DC6(dev))
+ skl_enable_dc6(dev_priv);
else
- if (SKL_ENABLE_DC6(dev))
- skl_enable_dc6(dev_priv);
- else
- gen9_enable_dc5(dev_priv);
+ gen9_enable_dc5(dev_priv);
}
}
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/12] drm/i915: use correct power domain for csr loading
Grabbing a runtime pm reference with intel_runtime_pm_get will only
prevent device D3. But dmc firmware is required even earlier (namely
for the skl power well 2).
Hence we need to grab a rpm reference higher up in the hierarchy. For
simplicity just grab the _INIT display power well. That's a bit too
much, but since the firmware loading task should completely fairly
quickly this won't be a real problem really.
Cc: Animesh Manna
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_csr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 6d8a7bf06dfc..16cd9dae1c1b 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -392,7 +392,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
DRM_DEBUG_KMS("Finished loading %s\n", dev_priv->csr.fw_path);
out:
if (fw_loaded)
- intel_runtime_pm_put(dev_priv);
+ intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
else
intel_csr_load_status_set(dev_priv, FW_FAILED);
@@ -429,7 +429,7 @@ void intel_csr_ucode_init(struct drm_device *dev)
* Obtain a runtime pm reference, until CSR is loaded,
* to avoid entering runtime-suspend.
*/
- intel_runtime_pm_get(dev_priv);
+ intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
/* CSR supported for platform, load firmware */
ret = request_firmware_nowait(THIS_MODULE, true, csr->fw_path,
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/12] drm/i915: Remove csr.state, csr_lock and related code
They don't serve a purpose any more after the preceding patches.
This removes two anti-patterns:
- Locking shouldn't be used to synchronize with async work (of any
form, whether callbacks, workers or other threads). This is what the
mutex_lock/unlock seems to have been for in intel_csr_load_program.
Instead ordering should be ensured with the generic
wait_for_completion()/complete(). Or more specific functions
provided by the core kernel like e.g.
flush_work()/cancel_work_sync() in the case of synchronizing with a
work item.
- Don't invent your own completion like this code did with the
(already removed) wait_for(csr_load_status_get()) pattern - it's
really hard to get these right when you want them to be _really_
correct (and be fast) in all cases. Furthermore it's easier to read
code using the well-known primitives than new ones using
non-standard names.
Cc: Animesh Manna
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 1 -
drivers/gpu/drm/i915/i915_drv.c | 6 -
drivers/gpu/drm/i915/i915_drv.h | 10 -
drivers/gpu/drm/i915/intel_csr.c | 48 +---
drivers/gpu/drm/i915/intel_drv.h | 3 ---
5 files changed, 1 insertion(+), 67 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 6d3a7466a430..1d1a3bb51bf2 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -795,7 +795,6 @@ int i915_driver_load(struct drm_device *dev, unsigned long
flags)
spin_lock_init(&dev_priv->mmio_flip_lock);
mutex_init(&dev_priv->sb_lock);
mutex_init(&dev_priv->modeset_restore_lock);
- mutex_init(&dev_priv->csr_lock);
intel_pm_setup(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b49697a9225f..bcc991f4cb3f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1019,12 +1019,6 @@ static int skl_suspend_complete(struct drm_i915_private
*dev_priv)
{
/* Enabling DC6 is not a hard requirement to enter runtime D3 */
- /*
-* This is to ensure that CSR isn't identified as loaded before
-* CSR-loading program is called during runtime-resume.
-*/
- intel_csr_load_status_set(dev_priv, FW_UNINITIALIZED);
-
skl_uninit_cdclk(dev_priv);
return 0;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 52d07fbd9cc8..9eaefd7ab82e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -734,12 +734,6 @@ struct intel_uncore {
#define for_each_fw_domain(domain__, dev_priv__, i__) \
for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__, i__)
-enum csr_state {
- FW_UNINITIALIZED = 0,
- FW_LOADED,
- FW_FAILED
-};
-
struct intel_csr {
const char *fw_path;
__be32 *dmc_payload;
@@ -747,7 +741,6 @@ struct intel_csr {
uint32_t mmio_count;
uint32_t mmioaddr[8];
uint32_t mmiodata[8];
- enum csr_state state;
};
#define DEV_INFO_FOR_EACH_FLAG(func, sep) \
@@ -1698,9 +1691,6 @@ struct drm_i915_private {
struct intel_csr csr;
- /* Display CSR-related protection */
- struct mutex csr_lock;
-
struct intel_gmbus gmbus[GMBUS_NUM_PINS];
/** gmbus_mutex protects against concurrent usage of the single hw gmbus
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 6362653d19af..a0fbce046ef0 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -184,40 +184,6 @@ static char intel_get_substepping(struct drm_device *dev)
}
/**
- * intel_csr_load_status_get() - to get firmware loading status.
- * @dev_priv: i915 device.
- *
- * This function helps to get the firmware loading status.
- *
- * Return: Firmware loading status.
- */
-enum csr_state intel_csr_load_status_get(struct drm_i915_private *dev_priv)
-{
- enum csr_state state;
-
- mutex_lock(&dev_priv->csr_lock);
- state = dev_priv->csr.state;
- mutex_unlock(&dev_priv->csr_lock);
-
- return state;
-}
-
-/**
- * intel_csr_load_status_set() - help to set firmware loading status.
- * @dev_priv: i915 device.
- * @state: enumeration of firmware loading status.
- *
- * Set the firmware loading status.
- */
-void intel_csr_load_status_set(struct drm_i915_private *dev_priv,
- enum csr_state state)
-{
- mutex_lock(&dev_priv->csr_lock);
- dev_priv->csr.state = state;
- mutex_unlock(&dev_priv->csr_lock);
-}
-
-/**
* intel_csr_load_program() - write the firmware from memory to register.
* @dev: drm device.
*
@@ -236,7 +202,6 @@ void intel_csr_load_program(struct drm_device *dev)
return;
}
- mutex_lock(&dev_priv->csr_lock);
fw_size = dev_priv->csr.dmc_fw_size;
for (i = 0; i < fw_size; i++)
I91
[Intel-gfx] [PATCH 07/12] drm/i915/csr: extract parse_csr_fw
The loader function will get a bit more complicated soon, extract the
parsing code to make the control flow clearer. While doing that just
use dev_priv->csr.dmc_payload as the indicator for whether it all
suceeded or not.
Also restrict the forced big-edian casting to just one place.
Cc: Animesh Manna
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_csr.c | 59 ++--
1 file changed, 33 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 59e2d98d7082..7ace2cc83269 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -194,7 +194,7 @@ static char intel_get_substepping(struct drm_device *dev)
void intel_csr_load_program(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- __be32 *payload = dev_priv->csr.dmc_payload;
+ uint32_t *payload = dev_priv->csr.dmc_payload;
uint32_t i, fw_size;
if (!IS_GEN9(dev)) {
@@ -204,8 +204,7 @@ void intel_csr_load_program(struct drm_device *dev)
fw_size = dev_priv->csr.dmc_fw_size;
for (i = 0; i < fw_size; i++)
- I915_WRITE(CSR_PROGRAM_BASE + i * 4,
- (u32 __force)payload[i]);
+ I915_WRITE(CSR_PROGRAM_BASE + i * 4, payload[i]);
for (i = 0; i < dev_priv->csr.mmio_count; i++) {
I915_WRITE(dev_priv->csr.mmioaddr[i],
@@ -213,9 +212,9 @@ void intel_csr_load_program(struct drm_device *dev)
}
}
-static void finish_csr_load(const struct firmware *fw, void *context)
+static uint32_t *parse_csr_fw(struct drm_i915_private *dev_priv,
+ const struct firmware *fw)
{
- struct drm_i915_private *dev_priv = context;
struct drm_device *dev = dev_priv->dev;
struct intel_css_header *css_header;
struct intel_package_header *package_header;
@@ -225,15 +224,11 @@ static void finish_csr_load(const struct firmware *fw,
void *context)
char substepping = intel_get_substepping(dev);
uint32_t dmc_offset = CSR_DEFAULT_FW_OFFSET, readcount = 0, nbytes;
uint32_t i;
- __be32 *dmc_payload;
- bool fw_loaded = false;
-
- if (!fw)
- goto out;
+ uint32_t *dmc_payload;
if ((stepping == -ENODATA) || (substepping == -ENODATA)) {
DRM_ERROR("Unknown stepping info, firmware loading failed\n");
- goto out;
+ return NULL;
}
/* Extract CSS Header information*/
@@ -242,7 +237,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
(css_header->header_len * 4)) {
DRM_ERROR("Firmware has wrong CSS header length %u bytes\n",
(css_header->header_len * 4));
- goto out;
+ return NULL;
}
readcount += sizeof(struct intel_css_header);
@@ -253,7 +248,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
(package_header->header_len * 4)) {
DRM_ERROR("Firmware has wrong package header length %u bytes\n",
(package_header->header_len * 4));
- goto out;
+ return NULL;
}
readcount += sizeof(struct intel_package_header);
@@ -273,7 +268,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
}
if (dmc_offset == CSR_DEFAULT_FW_OFFSET) {
DRM_ERROR("Firmware not supported for %c stepping\n", stepping);
- goto out;
+ return NULL;
}
readcount += dmc_offset;
@@ -282,7 +277,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
if (sizeof(struct intel_dmc_header) != (dmc_header->header_len)) {
DRM_ERROR("Firmware has wrong dmc header length %u bytes\n",
(dmc_header->header_len));
- goto out;
+ return NULL;
}
readcount += sizeof(struct intel_dmc_header);
@@ -290,7 +285,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
if (dmc_header->mmio_count > ARRAY_SIZE(csr->mmioaddr)) {
DRM_ERROR("Firmware has wrong mmio count %u\n",
dmc_header->mmio_count);
- goto out;
+ return NULL;
}
csr->mmio_count = dmc_header->mmio_count;
for (i = 0; i < dmc_header->mmio_count; i++) {
@@ -298,7 +293,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
dmc_header->mmioaddr[i] > CSR_MMIO_END_RANGE) {
DRM_ERROR(" Firmware has wrong mmio address 0x%x\n",
dmc_header->mmioaddr[i]);
- goto out;
+ return NULL;
}
csr->mmioad
[Intel-gfx] [PATCH 11/12] drm/i915: Use flush_work to synchronize with dmc loader
I have just placed them at the exact spot the old code had a
set_state. This probably needs to be moved earlier into the suspend
sequence, but I didn't audit that.
FIXME:
- Do this audit and move the flush_work to the right places.
- For consistency and since we have the work already it would be nice
to also load the dmc asynchronously on resume. We can reuse the same
loader function by simply skipping the fw loading&parsing when
dev_priv->csr.dmc_payload is set already.
Cc: Animesh Manna
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/i915/intel_csr.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7dfe9136c86f..2764f3520c2c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -997,7 +997,7 @@ static int i915_pm_resume(struct device *dev)
static int skl_suspend_complete(struct drm_i915_private *dev_priv)
{
- /* Enabling DC6 is not a hard requirement to enter runtime D3 */
+ flush_work(&dev_priv->csr.work);
skl_uninit_cdclk(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 58ff765dc9b5..350b36f1237b 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -402,5 +402,7 @@ void intel_csr_ucode_fini(struct drm_i915_private *dev_priv)
if (!HAS_CSR(dev_priv))
return;
+ flush_work(&dev_priv->csr.work);
+
kfree(dev_priv->csr.dmc_payload);
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/12] drm/i915: Don't try to load garbage dmc firmware on resume
We need to make sure we don't put garbage into the hw if dmc firmware
loading failed mid-thru.
Cc: Animesh Manna
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_csr.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 750c859a67c7..1145a354c385 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -736,7 +736,7 @@ struct intel_uncore {
struct intel_csr {
const char *fw_path;
- __be32 *dmc_payload;
+ uint32_t *dmc_payload;
uint32_t dmc_fw_size;
uint32_t mmio_count;
uint32_t mmioaddr[8];
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 7ace2cc83269..b87d5dfc04ce 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -202,6 +202,9 @@ void intel_csr_load_program(struct drm_device *dev)
return;
}
+ if (!dev_priv->csr.dmc_payload)
+ return;
+
fw_size = dev_priv->csr.dmc_fw_size;
for (i = 0; i < fw_size; i++)
I915_WRITE(CSR_PROGRAM_BASE + i * 4, payload[i]);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/12] drm/i915: Use dev_priv in csr functions
It's the new style!
Cc: Animesh Manna
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 6 +++---
drivers/gpu/drm/i915/i915_drv.c | 4 +---
drivers/gpu/drm/i915/intel_csr.c | 27 +++
drivers/gpu/drm/i915/intel_drv.h | 6 +++---
4 files changed, 18 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 1d1a3bb51bf2..3cb5afef64c3 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -841,7 +841,7 @@ int i915_driver_load(struct drm_device *dev, unsigned long
flags)
intel_uncore_init(dev);
/* Load CSR Firmware for SKL */
- intel_csr_ucode_init(dev);
+ intel_csr_ucode_init(dev_priv);
ret = i915_gem_gtt_init(dev);
if (ret)
@@ -1016,7 +1016,7 @@ out_mtrrfree:
out_gtt:
i915_global_gtt_cleanup(dev);
out_freecsr:
- intel_csr_ucode_fini(dev);
+ intel_csr_ucode_fini(dev_priv);
intel_uncore_fini(dev);
pci_iounmap(dev->pdev, dev_priv->regs);
put_bridge:
@@ -1097,7 +1097,7 @@ int i915_driver_unload(struct drm_device *dev)
intel_fbc_cleanup_cfb(dev_priv);
i915_gem_cleanup_stolen(dev);
- intel_csr_ucode_fini(dev);
+ intel_csr_ucode_fini(dev_priv);
intel_teardown_gmbus(dev);
intel_teardown_mchbar(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index adc3502068d1..7dfe9136c86f 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1045,10 +1045,8 @@ static int bxt_resume_prepare(struct drm_i915_private
*dev_priv)
static int skl_resume_prepare(struct drm_i915_private *dev_priv)
{
- struct drm_device *dev = dev_priv->dev;
-
skl_init_cdclk(dev_priv);
- intel_csr_load_program(dev);
+ intel_csr_load_program(dev_priv);
return 0;
}
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index b87d5dfc04ce..d46f8110e72a 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -185,19 +185,18 @@ static char intel_get_substepping(struct drm_device *dev)
/**
* intel_csr_load_program() - write the firmware from memory to register.
- * @dev: drm device.
+ * @dev_priv: i915 drm device.
*
* CSR firmware is read from a .bin file and kept in internal memory one time.
* Everytime display comes back from low power state this function is called to
* copy the firmware from internal memory to registers.
*/
-void intel_csr_load_program(struct drm_device *dev)
+void intel_csr_load_program(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
uint32_t *payload = dev_priv->csr.dmc_payload;
uint32_t i, fw_size;
- if (!IS_GEN9(dev)) {
+ if (!IS_GEN9(dev_priv)) {
DRM_ERROR("No CSR support available for this platform\n");
return;
}
@@ -332,7 +331,6 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
*dev_priv,
static void finish_csr_load(const struct firmware *fw, void *context)
{
struct drm_i915_private *dev_priv = context;
- struct drm_device *dev = dev_priv->dev;
if (!fw)
goto out;
@@ -341,7 +339,7 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
if (!dev_priv->csr.dmc_payload)
goto out;
- intel_csr_load_program(dev);
+ intel_csr_load_program(dev_priv);
DRM_DEBUG_KMS("Finished loading %s\n", dev_priv->csr.fw_path);
out:
@@ -360,21 +358,20 @@ out:
/**
* intel_csr_ucode_init() - initialize the firmware loading.
- * @dev: drm device.
+ * @dev_priv: i915 drm device.
*
* This function is called at the time of loading the display driver to read
* firmware from a .bin file and copied into a internal memory.
*/
-void intel_csr_ucode_init(struct drm_device *dev)
+void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_csr *csr = &dev_priv->csr;
int ret;
- if (!HAS_CSR(dev))
+ if (!HAS_CSR(dev_priv))
return;
- if (IS_SKYLAKE(dev))
+ if (IS_SKYLAKE(dev_priv))
csr->fw_path = I915_CSR_SKL;
DRM_DEBUG_KMS("Loading %s\n", csr->fw_path);
@@ -394,16 +391,14 @@ void intel_csr_ucode_init(struct drm_device *dev)
/**
* intel_csr_ucode_fini() - unload the CSR firmware.
- * @dev: drm device.
+ * @dev_priv: i915 drm device.
*
* Firmmware unloading includes freeing the internal momory and reset the
* firmware loading status.
*/
-void intel_csr_ucode_fini(struct drm_device *dev)
+void intel_csr_ucode_fini(struct drm_i915_private *dev_priv)
{
- struct drm_i915_private *dev_priv = dev->dev_private;
-
- if (!HAS_CSR(dev))
+ if (!HAS_CSR(dev_priv))
return;
kfr
[Intel-gfx] [PATCH 05/12] drm/i915: Align line continuations in intel_csr.c
Standard is to align continuations of parameter lists and if
conditions to the opening ( in i915 and drm code.
Apply this across the entire file since it was sticking out a bit too
much.
Also align register definitions while at it.
Cc: Animesh Manna
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_reg.h | 2 +-
drivers/gpu/drm/i915/intel_csr.c | 44
2 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 46af8c784d29..15b78e40d177 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7374,7 +7374,7 @@ enum skl_disp_power_wells {
/* MMIO address range for CSR program (0x8 - 0x82FFF) */
#define CSR_MAX_FW_SIZE0x2FFF
#define CSR_DEFAULT_FW_OFFSET 0x
-#define CSR_MMIO_START_RANGE 0x8
+#define CSR_MMIO_START_RANGE 0x8
#define CSR_MMIO_END_RANGE 0x8
/* Please see hsw_read_dcomp() and hsw_write_dcomp() before using this
register,
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index a0fbce046ef0..916c183f5fa4 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -160,15 +160,15 @@ struct stepping_info {
};
static const struct stepping_info skl_stepping_info[] = {
- {'A', '0'}, {'B', '0'}, {'C', '0'},
- {'D', '0'}, {'E', '0'}, {'F', '0'},
- {'G', '0'}, {'H', '0'}, {'I', '0'}
+ {'A', '0'}, {'B', '0'}, {'C', '0'},
+ {'D', '0'}, {'E', '0'}, {'F', '0'},
+ {'G', '0'}, {'H', '0'}, {'I', '0'}
};
static char intel_get_stepping(struct drm_device *dev)
{
if (IS_SKYLAKE(dev) && (dev->pdev->revision <
- ARRAY_SIZE(skl_stepping_info)))
+ ARRAY_SIZE(skl_stepping_info)))
return skl_stepping_info[dev->pdev->revision].stepping;
else
return -ENODATA;
@@ -177,7 +177,7 @@ static char intel_get_stepping(struct drm_device *dev)
static char intel_get_substepping(struct drm_device *dev)
{
if (IS_SKYLAKE(dev) && (dev->pdev->revision <
- ARRAY_SIZE(skl_stepping_info)))
+ ARRAY_SIZE(skl_stepping_info)))
return skl_stepping_info[dev->pdev->revision].substepping;
else
return -ENODATA;
@@ -205,11 +205,11 @@ void intel_csr_load_program(struct drm_device *dev)
fw_size = dev_priv->csr.dmc_fw_size;
for (i = 0; i < fw_size; i++)
I915_WRITE(CSR_PROGRAM_BASE + i * 4,
- (u32 __force)payload[i]);
+ (u32 __force)payload[i]);
for (i = 0; i < dev_priv->csr.mmio_count; i++) {
I915_WRITE(dev_priv->csr.mmioaddr[i],
- dev_priv->csr.mmiodata[i]);
+ dev_priv->csr.mmiodata[i]);
}
}
@@ -241,20 +241,20 @@ static void finish_csr_load(const struct firmware *fw,
void *context)
/* Extract CSS Header information*/
css_header = (struct intel_css_header *)fw->data;
if (sizeof(struct intel_css_header) !=
- (css_header->header_len * 4)) {
+ (css_header->header_len * 4)) {
DRM_ERROR("Firmware has wrong CSS header length %u bytes\n",
- (css_header->header_len * 4));
+ (css_header->header_len * 4));
goto out;
}
readcount += sizeof(struct intel_css_header);
/* Extract Package Header information*/
package_header = (struct intel_package_header *)
- &fw->data[readcount];
+ &fw->data[readcount];
if (sizeof(struct intel_package_header) !=
- (package_header->header_len * 4)) {
+ (package_header->header_len * 4)) {
DRM_ERROR("Firmware has wrong package header length %u bytes\n",
- (package_header->header_len * 4));
+ (package_header->header_len * 4));
goto out;
}
readcount += sizeof(struct intel_package_header);
@@ -262,15 +262,15 @@ static void finish_csr_load(const struct firmware *fw,
void *context)
/* Search for dmc_offset to find firware binary. */
for (i = 0; i < package_header->num_entries; i++) {
if (package_header->fw_info[i].substepping == '*' &&
- stepping == package_header->fw_info[i].stepping) {
+ stepping == package_header->fw_info[i].stepping) {
dmc_offset = package_header->fw_info[i].offset;
break;
} else if (stepping == package_header->fw_info[i].stepping &&
- substepping == package_header->fw_info[i].substepping) {
+
[Intel-gfx] [PATCH 03/12] drm/i915: move assert_csr_loaded into intel_rpm.c
Avoids non-static functions since all the callers are in intel_rpm.c.
Only thing we need for that is to move the register definitions into
i915_reg.h.
Cc: Animesh Manna
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_reg.h | 16
drivers/gpu/drm/i915/intel_csr.c| 24
drivers/gpu/drm/i915/intel_drv.h| 1 -
drivers/gpu/drm/i915/intel_runtime_pm.c | 8
4 files changed, 24 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2a29bccb63ef..46af8c784d29 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7361,6 +7361,22 @@ enum skl_disp_power_wells {
#define DC_STATE_DEBUG 0x45520
#define DC_STATE_DEBUG_MASK_MEMORY_UP (1<<1)
+/*
+* SKL CSR registers for DC5 and DC6
+*/
+#define CSR_PROGRAM_BASE 0x8
+#define CSR_SSP_BASE_ADDR_GEN9 0x2FC0
+#define CSR_HTP_ADDR_SKL 0x00500034
+#define CSR_SSP_BASE 0x8F074
+#define CSR_HTP_SKL0x8F004
+#define CSR_LAST_WRITE 0x8F034
+#define CSR_LAST_WRITE_VALUE 0xc003b400
+/* MMIO address range for CSR program (0x8 - 0x82FFF) */
+#define CSR_MAX_FW_SIZE0x2FFF
+#define CSR_DEFAULT_FW_OFFSET 0x
+#define CSR_MMIO_START_RANGE 0x8
+#define CSR_MMIO_END_RANGE 0x8
+
/* Please see hsw_read_dcomp() and hsw_write_dcomp() before using this
register,
* since on HSW we can't write to it using I915_WRITE. */
#define D_COMP_HSW (MCHBAR_MIRROR_BASE_SNB + 0x5F0C)
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 03d83892cdb0..6362653d19af 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -45,22 +45,6 @@
MODULE_FIRMWARE(I915_CSR_SKL);
-/*
-* SKL CSR registers for DC5 and DC6
-*/
-#define CSR_PROGRAM_BASE 0x8
-#define CSR_SSP_BASE_ADDR_GEN9 0x2FC0
-#define CSR_HTP_ADDR_SKL 0x00500034
-#define CSR_SSP_BASE 0x8F074
-#define CSR_HTP_SKL0x8F004
-#define CSR_LAST_WRITE 0x8F034
-#define CSR_LAST_WRITE_VALUE 0xc003b400
-/* MMIO address range for CSR program (0x8 - 0x82FFF) */
-#define CSR_MAX_FW_SIZE0x2FFF
-#define CSR_DEFAULT_FW_OFFSET 0x
-#define CSR_MMIO_START_RANGE 0x8
-#define CSR_MMIO_END_RANGE 0x8
-
struct intel_css_header {
/* 0x09 for DMC */
uint32_t module_type;
@@ -462,11 +446,3 @@ void intel_csr_ucode_fini(struct drm_device *dev)
intel_csr_load_status_set(dev_priv, FW_FAILED);
kfree(dev_priv->csr.dmc_payload);
}
-
-void assert_csr_loaded(struct drm_i915_private *dev_priv)
-{
- WARN(!I915_READ(CSR_PROGRAM_BASE),
- "CSR program storage start is NULL\n");
- WARN(!I915_READ(CSR_SSP_BASE), "CSR SSP Base Not fine\n");
- WARN(!I915_READ(CSR_HTP_SKL), "CSR HTP Not fine\n");
-}
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index beeb4d326cbe..ab585e734f99 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1168,7 +1168,6 @@ void intel_csr_load_status_set(struct drm_i915_private
*dev_priv,
enum csr_state state);
void intel_csr_load_program(struct drm_device *dev);
void intel_csr_ucode_fini(struct drm_device *dev);
-void assert_csr_loaded(struct drm_i915_private *dev_priv);
/* intel_dp.c */
void intel_dp_init(struct drm_device *dev, int output_reg, enum port port);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index ed8c0cee738f..33cc3375f87f 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -439,6 +439,14 @@ static void gen9_set_dc_state_debugmask_memory_up(
}
}
+static void assert_csr_loaded(struct drm_i915_private *dev_priv)
+{
+ WARN(!I915_READ(CSR_PROGRAM_BASE),
+ "CSR program storage start is NULL\n");
+ WARN(!I915_READ(CSR_SSP_BASE), "CSR SSP Base Not fine\n");
+ WARN(!I915_READ(CSR_HTP_SKL), "CSR HTP Not fine\n");
+}
+
static void assert_can_enable_dc5(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = dev_priv->dev;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/12] drm/i915: Simplify csr loading failure printing
If we really want to we can be more verbose here, but we really don't
need an entire function for this.
Cc: Animesh Manna
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.c | 20
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_csr.c | 8 +++-
3 files changed, 3 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index bcc991f4cb3f..adc3502068d1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -539,26 +539,6 @@ bool i915_semaphore_is_enabled(struct drm_device *dev)
return true;
}
-void i915_firmware_load_error_print(const char *fw_path, int err)
-{
- DRM_ERROR("failed to load firmware %s (%d)\n", fw_path, err);
-
- /*
-* If the reason is not known assume -ENOENT since that's the most
-* usual failure mode.
-*/
- if (!err)
- err = -ENOENT;
-
- if (!(IS_BUILTIN(CONFIG_DRM_I915) && err == -ENOENT))
- return;
-
- DRM_ERROR(
- "The driver is built-in, so to load the firmware you need to\n"
- "include it either in the kernel (see CONFIG_EXTRA_FIRMWARE) or\n"
- "in your initrd/initramfs image.\n");
-}
-
static void intel_suspend_encoders(struct drm_i915_private *dev_priv)
{
struct drm_device *dev = dev_priv->dev;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9eaefd7ab82e..750c859a67c7 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2628,7 +2628,6 @@ extern unsigned long i915_mch_val(struct drm_i915_private
*dev_priv);
extern unsigned long i915_gfx_val(struct drm_i915_private *dev_priv);
extern void i915_update_gfx_val(struct drm_i915_private *dev_priv);
int vlv_force_gfx_clock(struct drm_i915_private *dev_priv, bool on);
-void i915_firmware_load_error_print(const char *fw_path, int err);
/* intel_hotplug.c */
void intel_hpd_irq_handler(struct drm_device *dev, u32 pin_mask, u32
long_mask);
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 916c183f5fa4..59e2d98d7082 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -228,10 +228,8 @@ static void finish_csr_load(const struct firmware *fw,
void *context)
__be32 *dmc_payload;
bool fw_loaded = false;
- if (!fw) {
- i915_firmware_load_error_print(csr->fw_path, 0);
+ if (!fw)
goto out;
- }
if ((stepping == -ENODATA) || (substepping == -ENODATA)) {
DRM_ERROR("Unknown stepping info, firmware loading failed\n");
@@ -339,6 +337,8 @@ static void finish_csr_load(const struct firmware *fw, void
*context)
out:
if (fw_loaded)
intel_display_power_put(dev_priv, POWER_DOMAIN_INIT);
+ else
+ DRM_ERROR("Failed to load DMC firmware, disabling runtime
pm\n");
/*
* We require the dmc firmware for runtime pm on gen9+ - leak the rpm
@@ -380,8 +380,6 @@ void intel_csr_ucode_init(struct drm_device *dev)
&dev_priv->dev->pdev->dev,
GFP_KERNEL, dev_priv,
finish_csr_load);
- if (ret)
- i915_firmware_load_error_print(csr->fw_path, ret);
}
/**
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/12] drm/i915: Use request_firmware and our own async work
Two benefits:
- We can use FW_LOADER_USERSPACE_FALLBACK.
- We can use flush_work to synchronize with the oustanding worker,
which is a notch more obvious what it does than having a special
completion.
The next patch will properly synchronize against the async loader in
the resume and unload code.
Cc: Animesh Manna
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_csr.c | 21 +++--
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 1145a354c385..5160af0901ce 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -735,6 +735,7 @@ struct intel_uncore {
for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__, i__)
struct intel_csr {
+ struct work_struct work;
const char *fw_path;
uint32_t *dmc_payload;
uint32_t dmc_fw_size;
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index d46f8110e72a..58ff765dc9b5 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -328,10 +328,16 @@ static uint32_t *parse_csr_fw(struct drm_i915_private
*dev_priv,
return dmc_payload;
}
-static void finish_csr_load(const struct firmware *fw, void *context)
+static void csr_load_work_fn(struct work_struct *work)
{
- struct drm_i915_private *dev_priv = context;
+ struct drm_i915_private *dev_priv;
+ const struct firmware *fw;
+ int ret;
+
+ dev_priv = container_of(work, typeof(*dev_priv), csr.work);
+ ret = request_firmware(&fw, dev_priv->csr.fw_path,
+ &dev_priv->dev->pdev->dev);
if (!fw)
goto out;
@@ -366,7 +372,8 @@ out:
void intel_csr_ucode_init(struct drm_i915_private *dev_priv)
{
struct intel_csr *csr = &dev_priv->csr;
- int ret;
+
+ INIT_WORK(&dev_priv->csr.work, csr_load_work_fn);
if (!HAS_CSR(dev_priv))
return;
@@ -374,19 +381,13 @@ void intel_csr_ucode_init(struct drm_i915_private
*dev_priv)
if (IS_SKYLAKE(dev_priv))
csr->fw_path = I915_CSR_SKL;
- DRM_DEBUG_KMS("Loading %s\n", csr->fw_path);
-
/*
* Obtain a runtime pm reference, until CSR is loaded,
* to avoid entering runtime-suspend.
*/
intel_display_power_get(dev_priv, POWER_DOMAIN_INIT);
- /* CSR supported for platform, load firmware */
- ret = request_firmware_nowait(THIS_MODULE, true, csr->fw_path,
- &dev_priv->dev->pdev->dev,
- GFP_KERNEL, dev_priv,
- finish_csr_load);
+ schedule_work(&dev_priv->csr.work);
}
/**
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
