Re: [Intel-gfx] [PATCH 01/12] drm/i915: add helper to get a display power ref if it was already enabled
On pe, 2016-02-12 at 18:55 +0200, Imre Deak wrote:
> We have many places in the code where we check if a given display power
> domain is enabled and if so access registers backed by this power
> domain. We assumed that some modeset lock will prevent the power
> reference from vanishing in the middle of the HW access, but this
> assumption doesn't always hold. In such cases we get either the wakeref
> not held, or an unclaimed register access error message. To fix this in
> a future-proof way that's independent of other locks wrap any such
> access with a get_ref_if_enabled()/put_ref() pair.
>
> Kudos to Ville and Joonas for the ideas of this new interface.
>
A couple variables could be initialized at declaration, other than
that;
Reviewed-by: Joonas Lahtinen
> CC: Mika Kuoppala
> CC: Chris Wilson
> CC: Joonas Lahtinen
> CC: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_drv.h| 3 +
> drivers/gpu/drm/i915/intel_runtime_pm.c | 111
> ++--
> 2 files changed, 96 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 878172a..9380ffe 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1436,6 +1436,8 @@ bool __intel_display_power_is_enabled(struct
> drm_i915_private *dev_priv,
> enum intel_display_power_domain domain);
> void intel_display_power_get(struct drm_i915_private *dev_priv,
> enum intel_display_power_domain domain);
> +bool intel_display_power_get_if_enabled(struct drm_i915_private *dev_priv,
> + enum intel_display_power_domain domain);
> void intel_display_power_put(struct drm_i915_private *dev_priv,
> enum intel_display_power_domain domain);
>
> @@ -1522,6 +1524,7 @@ enable_rpm_wakeref_asserts(struct drm_i915_private
> *dev_priv)
> enable_rpm_wakeref_asserts(dev_priv)
>
> void intel_runtime_pm_get(struct drm_i915_private *dev_priv);
> +bool intel_runtime_pm_get_if_in_use(struct drm_i915_private *dev_priv);
> void intel_runtime_pm_get_noresume(struct drm_i915_private *dev_priv);
> void intel_runtime_pm_put(struct drm_i915_private *dev_priv);
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index bbca527..a81f965 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -1435,39 +1435,90 @@ static void chv_pipe_power_well_disable(struct
> drm_i915_private *dev_priv,
> chv_set_pipe_power_well(dev_priv, power_well, false);
> }
>
> -/**
> - * intel_display_power_get - grab a power domain reference
> - * @dev_priv: i915 device instance
> - * @domain: power domain to reference
> - *
> - * This function grabs a power domain reference for @domain and ensures that
> the
> - * power domain and all its parents are powered up. Therefore users should
> only
> - * grab a reference to the innermost power domain they need.
> - *
> - * Any power domain reference obtained by this function must have a symmetric
> - * call to intel_display_power_put() to release the reference again.
> - */
> -void intel_display_power_get(struct drm_i915_private *dev_priv,
> - enum intel_display_power_domain domain)
> +static void
> +__intel_display_power_get_domain(struct drm_i915_private *dev_priv,
> + enum intel_display_power_domain domain)
> {
> struct i915_power_domains *power_domains;
> struct i915_power_well *power_well;
> int i;
>
> - intel_runtime_pm_get(dev_priv);
> -
> power_domains = &dev_priv->power_domains;
>
You could squash this to the declaration line.
> - mutex_lock(&power_domains->lock);
> -
> for_each_power_well(i, power_well, BIT(domain), power_domains) {
> if (!power_well->count++)
> intel_power_well_enable(dev_priv, power_well);
> }
>
> power_domains->domain_use_count[domain]++;
> +}
> +
> +/**
> + * intel_display_power_get - grab a power domain reference
> + * @dev_priv: i915 device instance
> + * @domain: power domain to reference
> + *
> + * This function grabs a power domain reference for @domain and ensures that
> the
> + * power domain and all its parents are powered up. Therefore users should
> only
> + * grab a reference to the innermost power domain they need.
> + *
> + * Any power domain reference obtained by this function must have a symmetric
> + * call to intel_display_power_put() to release the reference again.
> + */
> +void intel_display_power_get(struct drm_i915_private *dev_priv,
> + enum intel_display_power_domain domain)
> +{
> + struct i915_power_domains *power_domains;
> +
> + intel_runtime_pm_get(dev_priv);
> +
> + power_domains = &dev_priv->power_domains;
Sa
Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4
13.02.2016 01:23, Ville Syrjälä wrote: - Do you have another monitor to try? - Do you have another cable to try? More on this. Computer DVI —— old DVI-HDMI cable —— old monitor HDMI == not working Computer DVI —— another DVI-HDMI cable —— old monitor HDMI == not working Computer DVI —— DVI-DVI cable —— another monitor DVI == works So Shouldn't really matter. HDMI and DVI are identical at this level. Not quite, as far as I can see. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] Fwd: Discuss GVT context hacks in i915
+ mailing-list
Original Message
Subject: Discuss GVT context hacks in i915
Date: Mon, 15 Feb 2016 17:11:12 +0800
From: Zhi Wang
To: Joonas Lahtinen , Chris Wilson
, Daniel Vetter ,
Zhiyuan Lv , "Tian, Kevin"
Hi Guys:
Previously we have sent our GVT-g device model RFC code, and thanks
for the advices and comments! As you see GVT-g needs a special kind of
LRC context as shadow context so it could be able to use i915 GEM
submission subsystem, which requires some changes in i915.
Probably we can discuss them one by one and settle them down before the
next version of RFC code. :)
Difference between a i915 LRC context and a GVT LRC context
--
* The engine context initialization of a GVT LRC context can be
bypassed, as GVT-g will initialize it by guest LRC context.
http://www.spinics.net/lists/intel-gfx/msg86546.html
* The addressing mode bit in the context descriptor should be able to
configured at runtime, as some guest is still using 32bit PPGTT address
space.
http://www.spinics.net/lists/intel-gfx/msg86544.html
* As the GVT LRC context will go with the shadow PPGTT page table
populated by GVT-g, a GVT LRC context doesn't need a i915 PPGTT
instance, also its PDP root pointer doesn't need to be populated by i915.
http://www.spinics.net/lists/intel-gfx/msg86545.html
* The ring buffer size of a GVT LRC context ring buffer object should be
configurable or hard-coded to the max size, as some guest (e.g. windows)
has a large ring buffer and could submit a lot of commands at one time.
Hacking i915
---
The above changes needs to hack i915, in the RFC code, you can see a lot
of codes like below:
if (!gvt_context) {
/* do something i915 needed */
} else {
/* do something GVT-g needed */
}
This kinds of code piece is GVT-g specific, another approach should be
refining some i915 APIs or say something generic, like:
if (context->need_i915_ppgtt) {
/* allocating i915 ppgtt instance */
}
if (context->ppgtt) {
/* update PDP root pointers in LRC context. */
}
if (context->need_initialization) {
/* emit commands to initialize the engine context of LRC context */
}
I'm wondering which kinds do you prefer? Or maybe you can give me some
advices? :)
Thanks,
Zhi.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/prime_mmap: Encapsulate check_for_dma_buf_mmap() in igt_fixture.
Hi,
I'm positive it does. Are you sure you've re-compiled? (check or
distcheck targets do not re-compile the tests).
On Fri, Feb 12, 2016 at 03:38:27PM -0200, Tiago Vignatti wrote:
> I'm not sure this actually fix the root problem. With or without your patch
> applied, I'm seeing the following in lib/tests/test-suite.log:
>
> ../../tests/prime_mmap:
> Checking invalid option handling...
> Checking valid option handling...
> Checking subtest enumeration...
> (prime_mmap:24023) ioctl-wrappers-CRITICAL: Test assertion failure function
> gem_create, file ../../lib/ioctl_wrappers.c:501:
> (prime_mmap:24023) ioctl-wrappers-CRITICAL: Failed assertion: drmIoctl((fd),
> 2U|1U) << (((0+8)+8)+14)) | ((('d')) << (0+8)) | (((0x40 + 0x1b)) << 0)
> | sizeof(struct drm_i915_gem_create << ((0+8)+8, (&create)) == 0
> (prime_mmap:24023) ioctl-wrappers-CRITICAL: Last errno: 25, Inappropriate
> ioctl for device
> (prime_mmap:24023) ioctl-wrappers-CRITICAL: error: -1 != 0
> Test prime_mmap failed.
> DEBUG
> (prime_mmap:24023) ioctl-wrappers-CRITICAL: Test assertion failure function
> gem_create, file ../../lib/ioctl_wrappers.c:501:
> (prime_mmap:24023) ioctl-wrappers-CRITICAL: Failed assertion: drmIoctl((fd),
> 2U|1U) << (((0+8)+8)+14)) | ((('d')) << (0+8)) | (((0x40 + 0x1b)) << 0)
> | sizeof(struct drm_i915_gem_create << ((0+8)+8, (&create)) == 0
> (prime_mmap:24023) ioctl-wrappers-CRITICAL: Last errno: 25, Inappropriate
> ioctl for device
> (prime_mmap:24023) ioctl-wrappers-CRITICAL: error: -1 != 0
> END
> prime_mmap: ../../lib/igt_core.c:1014: igt_fail: Assertion
> `!test_with_subtests || in_fixture' failed.
> Received signal SIGABRT.
> Aborted (core dumped)
>
> Tiago
>
> On 02/12/2016 11:32 AM, Marius Vlad wrote:
> >This unbreaks distcheck target that in turn runs each test with
> >--list-subtests.
> >
> >Signed-off-by: Marius Vlad
> >---
> > tests/prime_mmap.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> >diff --git a/tests/prime_mmap.c b/tests/prime_mmap.c
> >index 29a0cfd..1ea61c2 100644
> >--- a/tests/prime_mmap.c
> >+++ b/tests/prime_mmap.c
> >@@ -504,10 +504,10 @@ igt_main
> >
> > igt_fixture {
> > fd = drm_open_driver(DRIVER_INTEL);
> >+igt_skip_on((check_for_dma_buf_mmap() != 0));
> > errno = 0;
> > }
> >
> >-igt_skip_on((check_for_dma_buf_mmap() != 0));
> >
> > for (i = 0; i < ARRAY_SIZE(tests); i++) {
> > igt_subtest(tests[i].name)
> >
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
signature.asc
Description: Digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Fix some invalid requests cancellations
On Thu, Feb 11, 2016 at 01:01:34PM +, Tvrtko Ursulin wrote:
> On 29/01/16 16:49, Chris Wilson wrote:
> >As we add the VMA to the request early, it may be cancelled during
> >execbuf reservation. This will leave the context object pointing to a
>
> I don't get it, request is created after the reservation.
That's the problem - we add vma for a given request (well ring/seqno pair)
before that request exists.
-Daniel
>
> >dangling request; i915_wait_request() simply skips the wait and so we
> >may unbind the object whilst it is still active.
> >
> >However, if at any point we make a change to the hardware (and equally
> >importantly our bookkeeping in the driver), we cannot cancel the request
> >as what has already been written must be submitted. Submitting a partial
> >request is far easier than trying to unwind the incomplete change.
> >
> >Unfortunately this patch undoes the excess breadcrumb usage that olr
> >prevented, e.g. if we interrupt batchbuffer submission then we submit
> >the requests along with the memory writes and interrupt (even though we
> >do no real work). Disassociating requests from breadcrumbs (and
> >semaphores) is a topic for a past/future series, but now much more
> >important.
> >
> >v2: Rebase
> >
> >Note that igt/gem_concurrent_blit tiggers both misrendering and a GPF
> >that is fixed by this patch.
> >
> >Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93907
> >Testcase: igt/gem_concurrent_blit
> >Signed-off-by: Chris Wilson
> >Cc: Daniel Vetter
> >Cc: sta...@vger.kernel.org
> >---
> > drivers/gpu/drm/i915/i915_drv.h| 1 -
> > drivers/gpu/drm/i915/i915_gem.c| 7 ++-
> > drivers/gpu/drm/i915/i915_gem_context.c| 21 +
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 16 +---
> > drivers/gpu/drm/i915/intel_display.c | 2 +-
> > drivers/gpu/drm/i915/intel_lrc.c | 1 -
> > 6 files changed, 17 insertions(+), 31 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >b/drivers/gpu/drm/i915/i915_drv.h
> >index a2d2f08b7515..f828a7ffed37 100644
> >--- a/drivers/gpu/drm/i915/i915_drv.h
> >+++ b/drivers/gpu/drm/i915/i915_drv.h
> >@@ -2823,7 +2823,6 @@ int i915_gem_sw_finish_ioctl(struct drm_device *dev,
> >void *data,
> > struct drm_file *file_priv);
> > void i915_gem_execbuffer_move_to_active(struct list_head *vmas,
> > struct drm_i915_gem_request *req);
> >-void i915_gem_execbuffer_retire_commands(struct i915_execbuffer_params
> >*params);
> > int i915_gem_ringbuffer_submission(struct i915_execbuffer_params *params,
> >struct drm_i915_gem_execbuffer2 *args,
> >struct list_head *vmas);
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c
> >b/drivers/gpu/drm/i915/i915_gem.c
> >index e9b19bca1383..f764f33580fc 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -3407,12 +3407,9 @@ int i915_gpu_idle(struct drm_device *dev)
> > return PTR_ERR(req);
> >
> > ret = i915_switch_context(req);
> >-if (ret) {
> >-i915_gem_request_cancel(req);
> >-return ret;
> >-}
> >-
> > i915_add_request_no_flush(req);
> >+if (ret)
> >+return ret;
> > }
> >
> > ret = intel_ring_idle(ring);
> >diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> >b/drivers/gpu/drm/i915/i915_gem_context.c
> >index 83a097c94911..5da7adc3f7b2 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_context.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_context.c
> >@@ -652,7 +652,6 @@ static int do_switch(struct drm_i915_gem_request *req)
> > struct drm_i915_private *dev_priv = ring->dev->dev_private;
> > struct intel_context *from = ring->last_context;
> > u32 hw_flags = 0;
> >-bool uninitialized = false;
> > int ret, i;
> >
> > if (from != NULL && ring == &dev_priv->ring[RCS]) {
> >@@ -759,6 +758,15 @@ static int do_switch(struct drm_i915_gem_request *req)
> > to->remap_slice &= ~(1< > }
> >
> >+if (!to->legacy_hw_ctx.initialized) {
> >+if (ring->init_context) {
> >+ret = ring->init_context(req);
> >+if (ret)
> >+goto unpin_out;
> >+}
> >+to->legacy_hw_ctx.initialized = true;
> >+}
> >+
> > /* The backing object for the context is done after switching to the
> > * *next* context. Therefore we cannot retire the previous context until
> > * the next context has already started running. In fact, the below code
> >@@ -782,21 +790,10 @@ static int do_switch(struct drm_i915_gem_request *req)
> > i915_gem_context_unreference(from);
> > }
> >
> >-uninitial
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Don't ERROR for an expected intel_rcs_ctx_init() interruption
On Thu, Feb 11, 2016 at 12:12:26PM +, Tvrtko Ursulin wrote:
>
> On 29/01/16 16:49, Chris Wilson wrote:
> >intel_rcs_ctx_init() can be interrupted by a signal (if it has to wait
> >upon a full ring to advance). Don't emit an error for this.
> >
> >Testcase: igt/gem_concurrent_blit
> >Signed-off-by: Chris Wilson
> >---
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> >b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >index 6f5b511bdb5d..b813bbc8e41c 100644
> >--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> >+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> >@@ -746,9 +746,9 @@ static int intel_rcs_ctx_init(struct
> >drm_i915_gem_request *req)
> >
> > ret = i915_gem_render_state_init(req);
> > if (ret)
> >-DRM_ERROR("init render state: %d\n", ret);
> >+return ret;
> >
> >-return ret;
> >+return 0;
> > }
> >
> > static int wa_add(struct drm_i915_private *dev_priv,
> >
>
> Or just "return i915_gem_render_state_init(req);", but that is way below the
> threshold.
>
> Reviewed-by: Tvrtko Ursulin
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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] kernel crash in snd_hda_intel
On Fri, 12 Feb 2016 17:47:21 +0100, Gabriel Feceoru wrote: > > !!! This caused a regression in the i-g-t drv_module_reload_basic test. > > > Reproducible easily on HSW (i5-4460) with: > #rmmod snd_hda_intel I couldn't reproduce this on my HSW machine. Does it happen always without without the monitor plugged? thanks, Takashi > The bisect shows this as the offending commit: > > > commit 25e4abb33df3aafa7d1efba8f82f9178268efab1 > Author: Libin Yang > Date: Tue Jan 12 11:13:27 2016 +0800 > > ALSA: hda - hdmi jack created based on pcm > > Jack is created based on pcm. > > Apply the acomp jack rule to dyn_pcm_assign. > For dyn_pcm_assign: > Driver does not use hda_jack. It operates snd_jack directly. > snd_jack pointer will be stored in spec->pcm.jack instead of > the current spec->acomp_jack. When pcm is assigned to pin, > jack will be assigned to pin automatically. > For !dyn_pcm_assign: > Driver continues using hda_jack for less impact on the old cases. > Pcm is statically assigned to pin. So is jack. spec->pcm.jack > saves the snd_jack pointer created in hda_jack. > > Signed-off-by: Libin Yang > Signed-off-by: Takashi Iwai > > > > > [ 79.020523] BUG: unable to handle kernel paging request at > 00015d80 > [ 79.021314] IP: [] queued_spin_lock_slowpath+0xeb/0x180 > [ 79.022125] PGD 0 > [ 79.022881] Oops: 0002 [#1] SMP > [ 79.023644] Modules linked in: snd_hda_codec_hdmi > snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel(-) > snd_hda_codec x86_pkg_temp_thermal snd_hwdep snd_hda_core i915 > i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt ehci_pci > fb_sys_fops r8169 ehci_hcd mii drm xhci_pci xhci_hcd video > [ 79.026790] CPU: 0 PID: 1294 Comm: rmmod Tainted: G U > 4.5.0-rc1+ #73 > [ 79.028322] Hardware name: Dell Inc. Inspiron 3847/088DT1 , > BIOS A06 01/15/2015 > [ 79.029854] task: 8800dac9 ti: 88021270 task.ti: > 88021270 > [ 79.031384] RIP: 0010:[] [] > queued_spin_lock_slowpath+0xeb/0x180 > [ 79.032924] RSP: 0018:8802127039b0 EFLAGS: 00010002 > [ 79.033698] RAX: 350c RBX: 8800d434ef90 RCX: > 88021fa15d80 > [ 79.035224] RDX: 00015d80 RSI: d434ef88 RDI: > 8800d434ef90 > [ 79.036751] RBP: 8802127039b0 R08: 0004 R09: > > [ 79.038277] R10: 8800daef8998 R11: 0004 R12: > 0282 > [ 79.039802] R13: R14: 0006 R15: > 8800d434ef90 > [ 79.041331] FS: 7f75be1ad700() GS:88021fa0() > knlGS: > [ 79.042863] CS: 0010 DS: ES: CR0: 80050033 > [ 79.043638] CR2: 00015d80 CR3: 0002101b1000 CR4: > 001406f0 > [ 79.045166] Stack: > [ 79.045926] 8802127039d0 81748e59 8800d434ed80 > 0005 > [ 79.047462] 880212703a10 81597e73 817472d2 > 0003 > [ 79.048995] 8800d434ecc0 0001 > 8800daef8800 > [ 79.050528] Call Trace: > [ 79.051293] [] _raw_spin_lock_irqsave+0x39/0x50 > [ 79.052071] [] input_event+0x43/0x80 > [ 79.052844] [] ? mutex_lock+0x12/0x30 > [ 79.053619] [] snd_jack_report+0xee/0x110 > [ 79.054396] [] hdmi_present_sense+0x13a/0x390 > [snd_hda_codec_hdmi] > [ 79.055921] [] ? regmap_unlock_mutex+0xe/0x10 > [ 79.056699] [] generic_hdmi_resume+0x4d/0x60 > [snd_hda_codec_hdmi] > [ 79.058235] [] ? snd_hda_add_imux_item+0x120/0x120 > [snd_hda_codec] > [ 79.059771] [] hda_call_codec_resume+0xce/0x120 > [snd_hda_codec] > [ 79.061303] [] ? snd_hda_add_imux_item+0x120/0x120 > [snd_hda_codec] > [ 79.062835] [] hda_codec_runtime_resume+0x35/0x50 > [snd_hda_codec] > [ 79.064368] [] __rpm_callback+0x28/0x70 > [ 79.065143] [] ? snd_hda_add_imux_item+0x120/0x120 > [snd_hda_codec] > [ 79.066676] [] rpm_callback+0x24/0x80 > [ 79.067449] [] ? snd_hda_add_imux_item+0x120/0x120 > [snd_hda_codec] > [ 79.068983] [] rpm_resume+0x426/0x620 > [ 79.069758] [] __pm_runtime_resume+0x4e/0x70 > [ 79.070536] [] __device_release_driver+0x43/0x160 > [ 79.071314] [] device_release_driver+0x23/0x30 > [ 79.072085] [] bus_remove_device+0x101/0x170 > [ 79.072862] [] device_del+0x139/0x270 > [ 79.073638] [] ? widget_tree_free.isra.1+0x8b/0xa0 > [snd_hda_core] > [ 79.075170] [] > snd_hdac_device_unregister+0x21/0x30 [snd_hda_core] > [ 79.076703] [] snd_hda_codec_dev_free+0x1d/0x40 > [snd_hda_codec] > [ 79.078235] [] __snd_device_free+0x4c/0x80 > [ 79.079010] [] snd_device_free_all+0x30/0x60 > [ 79.079787] [] release_card_device+0x34/0x90 > [ 79.080563] [] device_release+0x32/0x90 > [ 79.081338] [] kobject_release+0x7a/0x190 > [ 79.082113] [] kobject_put+0x27/0x50 > [ 79.082886] [] put_device+0x17/0x20 > [ 79.083659] [] snd_card_free+0
[Intel-gfx] [PATCH] Revert "drm/i915: fix context/engine cleanup order"
This reverts commit 1b39a917a9e00378c02c50ad86632ed3d872bfad.
Chris retracted his reviewed-by (which I failed to notice) and somehow
it blows up (I did it again!) as reported by Mika with the below
backtrace on module reload:
[ 58.170374] IP: []
intel_logical_ring_cleanup+0x83/0x100 [i915]
...
[ 58.170469] Call Trace:
[ 58.170479] [] i915_gem_cleanup_engines+0x34/0x60
[i915]
[ 58.170493] [] i915_driver_unload+0x140/0x220
[i915]
[ 58.170497] [] drm_dev_unregister+0x24/0xa0
[ 58.170501] [] drm_put_dev+0x1e/0x60
[ 58.170506] [] i915_pci_remove+0x10/0x20 [i915]
[ 58.170510] [] pci_device_remove+0x34/0xb0
[ 58.170514] [] __device_release_driver+0x95/0x140
[ 58.170518] [] driver_detach+0xbc/0xc0
[ 58.170521] [] bus_remove_driver+0x53/0xd0
[ 58.170525] [] driver_unregister+0x27/0x50
[ 58.170528] [] pci_unregister_driver+0x25/0x70
[ 58.170531] [] drm_pci_exit+0x74/0x90
[ 58.170543] [] i915_exit+0x20/0x1aa [i915]
[ 58.170548] [] SyS_delete_module+0x18f/0x1f0
Cc: Mika Kuoppala
Cc: Chris Wilson
Cc: Dave Gordon
Cc: Nick Hoath
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_dma.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 23 +++
3 files changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 2df2fac04708..1c6d227aae7c 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -444,8 +444,8 @@ static int i915_load_modeset_init(struct drm_device *dev)
cleanup_gem:
mutex_lock(&dev->struct_mutex);
+ i915_gem_cleanup_ringbuffer(dev);
i915_gem_context_fini(dev);
- i915_gem_cleanup_engines(dev);
mutex_unlock(&dev->struct_mutex);
cleanup_irq:
intel_guc_ucode_fini(dev);
@@ -1256,8 +1256,8 @@ int i915_driver_unload(struct drm_device *dev)
intel_guc_ucode_fini(dev);
mutex_lock(&dev->struct_mutex);
+ i915_gem_cleanup_ringbuffer(dev);
i915_gem_context_fini(dev);
- i915_gem_cleanup_engines(dev);
mutex_unlock(&dev->struct_mutex);
intel_fbc_cleanup_cfb(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 64cfd446453c..20d9dbd9f9cf 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3058,7 +3058,7 @@ int i915_gem_init_rings(struct drm_device *dev);
int __must_check i915_gem_init_hw(struct drm_device *dev);
int i915_gem_l3_remap(struct drm_i915_gem_request *req, int slice);
void i915_gem_init_swizzling(struct drm_device *dev);
-void i915_gem_cleanup_engines(struct drm_device *dev);
+void i915_gem_cleanup_ringbuffer(struct drm_device *dev);
int __must_check i915_gpu_idle(struct drm_device *dev);
int __must_check i915_gem_suspend(struct drm_device *dev);
void __i915_add_request(struct drm_i915_gem_request *req,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index de57e7f0be0f..e9b19bca1383 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4913,7 +4913,7 @@ i915_gem_init_hw(struct drm_device *dev)
req = i915_gem_request_alloc(ring, NULL);
if (IS_ERR(req)) {
ret = PTR_ERR(req);
- i915_gem_cleanup_engines(dev);
+ i915_gem_cleanup_ringbuffer(dev);
goto out;
}
@@ -4926,7 +4926,7 @@ i915_gem_init_hw(struct drm_device *dev)
if (ret && ret != -EIO) {
DRM_ERROR("PPGTT enable ring #%d failed %d\n", i, ret);
i915_gem_request_cancel(req);
- i915_gem_cleanup_engines(dev);
+ i915_gem_cleanup_ringbuffer(dev);
goto out;
}
@@ -4934,7 +4934,7 @@ i915_gem_init_hw(struct drm_device *dev)
if (ret && ret != -EIO) {
DRM_ERROR("Context enable ring #%d failed %d\n", i,
ret);
i915_gem_request_cancel(req);
- i915_gem_cleanup_engines(dev);
+ i915_gem_cleanup_ringbuffer(dev);
goto out;
}
@@ -5009,7 +5009,7 @@ out_unlock:
}
void
-i915_gem_cleanup_engines(struct drm_device *dev)
+i915_gem_cleanup_ringbuffer(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_engine_cs *ring;
@@ -5018,14 +5018,13 @@ i915_gem_cleanup_engines(struct drm_device *dev)
for_each_ring(ring, dev_priv, i)
dev_priv->gt.cleanup_ring(ring);
- if (i915.enable_execlists) {
- /*
-* Neither the BIOS, ourselves or any other kernel
-* expects the system to be in execlists mode on startup,
-* so we need to reset the GPU back to legacy mode.
[Intel-gfx] [PATCH] drm/i915/bxt: Additional MIPI clock divider form B0 stepping onwards
The MIPI clock calculations for the addtional clock
are revised from B0 stepping onwards, the bit definitions
have changed compared to old stepping.
v2: Fixing compilation warning.
v3: Retained the old Macros (Jani)
Signed-off-by: Deepak M
---
drivers/gpu/drm/i915/i915_reg.h | 96 +++-
drivers/gpu/drm/i915/intel_dsi_pll.c | 56 ++---
2 files changed, 89 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 144586e..4e61b06 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7663,58 +7663,62 @@ enum skl_disp_power_wells {
#define BXT_MIPI_DIV_SHIFT(port) \
_MIPI_PORT(port, BXT_MIPI1_DIV_SHIFT, \
BXT_MIPI2_DIV_SHIFT)
-/* Var clock divider to generate TX source. Result must be < 39.5 M */
-#define BXT_MIPI1_ESCLK_VAR_DIV_MASK (0x3F << 26)
-#define BXT_MIPI2_ESCLK_VAR_DIV_MASK (0x3F << 10)
-#define BXT_MIPI_ESCLK_VAR_DIV_MASK(port) \
- _MIPI_PORT(port, BXT_MIPI1_ESCLK_VAR_DIV_MASK, \
- BXT_MIPI2_ESCLK_VAR_DIV_MASK)
-
-#define BXT_MIPI_ESCLK_VAR_DIV(port, val) \
- (val << BXT_MIPI_DIV_SHIFT(port))
+
/* TX control divider to select actual TX clock output from (8x/var) */
-#define BXT_MIPI1_TX_ESCLK_SHIFT 21
-#define BXT_MIPI2_TX_ESCLK_SHIFT 5
+#define BXT_MIPI1_TX_ESCLK_SHIFT 26
+#define BXT_MIPI2_TX_ESCLK_SHIFT 10
#define BXT_MIPI_TX_ESCLK_SHIFT(port) \
_MIPI_PORT(port, BXT_MIPI1_TX_ESCLK_SHIFT, \
BXT_MIPI2_TX_ESCLK_SHIFT)
-#define BXT_MIPI1_TX_ESCLK_FIXDIV_MASK(3 << 21)
-#define BXT_MIPI2_TX_ESCLK_FIXDIV_MASK(3 << 5)
+#define BXT_MIPI1_TX_ESCLK_FIXDIV_MASK(0x3F << 26)
+#define BXT_MIPI2_TX_ESCLK_FIXDIV_MASK(0x3F << 10)
#define BXT_MIPI_TX_ESCLK_FIXDIV_MASK(port) \
_MIPI_PORT(port, BXT_MIPI1_TX_ESCLK_FIXDIV_MASK, \
- BXT_MIPI2_TX_ESCLK_FIXDIV_MASK)
-#define BXT_MIPI_TX_ESCLK_8XDIV_BY2(port) \
- (0x0 << BXT_MIPI_TX_ESCLK_SHIFT(port))
-#define BXT_MIPI_TX_ESCLK_8XDIV_BY4(port) \
- (0x1 << BXT_MIPI_TX_ESCLK_SHIFT(port))
-#define BXT_MIPI_TX_ESCLK_8XDIV_BY8(port) \
- (0x2 << BXT_MIPI_TX_ESCLK_SHIFT(port))
-/* RX control divider to select actual RX clock output from 8x*/
-#define BXT_MIPI1_RX_ESCLK_SHIFT 19
-#define BXT_MIPI2_RX_ESCLK_SHIFT 3
-#define BXT_MIPI_RX_ESCLK_SHIFT(port) \
- _MIPI_PORT(port, BXT_MIPI1_RX_ESCLK_SHIFT, \
- BXT_MIPI2_RX_ESCLK_SHIFT)
-#define BXT_MIPI1_RX_ESCLK_FIXDIV_MASK(3 << 19)
-#define BXT_MIPI2_RX_ESCLK_FIXDIV_MASK(3 << 3)
-#define BXT_MIPI_RX_ESCLK_FIXDIV_MASK(port) \
- (3 << BXT_MIPI_RX_ESCLK_SHIFT(port))
-#define BXT_MIPI_RX_ESCLK_8X_BY2(port)\
- (1 << BXT_MIPI_RX_ESCLK_SHIFT(port))
-#define BXT_MIPI_RX_ESCLK_8X_BY3(port)\
- (2 << BXT_MIPI_RX_ESCLK_SHIFT(port))
-#define BXT_MIPI_RX_ESCLK_8X_BY4(port)\
- (3 << BXT_MIPI_RX_ESCLK_SHIFT(port))
-/* BXT-A WA: Always prog DPHY dividers to 00 */
-#define BXT_MIPI1_DPHY_DIV_SHIFT 16
-#define BXT_MIPI2_DPHY_DIV_SHIFT 0
-#define BXT_MIPI_DPHY_DIV_SHIFT(port) \
- _MIPI_PORT(port, BXT_MIPI1_DPHY_DIV_SHIFT, \
- BXT_MIPI2_DPHY_DIV_SHIFT)
-#define BXT_MIPI_1_DPHY_DIVIDER_MASK (3 << 16)
-#define BXT_MIPI_2_DPHY_DIVIDER_MASK (3 << 0)
-#define BXT_MIPI_DPHY_DIVIDER_MASK(port) \
- (3 << BXT_MIPI_DPHY_DIV_SHIFT(port))
+ BXT_MIPI2_TX_ESCLK_FIXDIV_MASK)
+#define BXT_MIPI_TX_ESCLK_DIVIDER(port, val) \
+ ((val & 0x3F) << BXT_MIPI_TX_ESCLK_SHIFT(port))
+/* RX upper control divider to select actual RX clock output from 8x*/
+#define BXT_MIPI1_RX_ESCLK_UPPER_SHIFT21
+#define BXT_MIPI2_RX_ESCLK_UPPER_SHIFT5
+#define BXT_MIPI_RX_ESCLK_UPPER_SHIFT(port) \
+ _MIPI_PORT(port, BXT_MIPI1_RX_ESCLK_UPPER_SHIFT, \
+ BXT_MIPI2_RX_ESCLK_UPPER_SHIFT)
+#define BXT_MIPI1_RX_ESCLK_UPPER_FIXDIV_MASK (3 << 21)
+#define BXT_MIPI2_RX_ESCLK_UPPER_FIXDIV_MASK (3 << 5)
+#define BXT_MIPI_RX_ESCLK_UPPER_FIXDIV_MASK(port) \
+ _MIPI_PORT(port, BXT_MIPI1_RX_ESCLK_UPPER_FIXDIV_MASK,\
+ BXT_MIPI2_RX_ESCLK_UPPER_FIXDIV_MASK)
+#define
Re: [Intel-gfx] [PATCH v4 2/6] drm/i915: tidy up initialisation failure paths (GEM & LRC)
On 11/02/16 08:47, Daniel Vetter wrote:
On Mon, Feb 01, 2016 at 09:45:25AM +, Dave Gordon wrote:
On 30/01/16 11:28, Chris Wilson wrote:
On Sat, Jan 30, 2016 at 10:56:27AM +, Chris Wilson wrote:
On Fri, Jan 29, 2016 at 07:19:27PM +, Dave Gordon wrote:
1. add call to i915_gem_context_fini() to deallocate the default
context(s) if the call to init_rings() fails, so that we don't
leak the context in that situation.
2. remove useless code in intel_logical_ring_cleanup(), presumably
copypasted from legacy ringbuffer version at creation.
If your commit message has a list of independent changes ...
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem.c | 5 -
drivers/gpu/drm/i915/intel_lrc.c | 10 ++
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index a928823..5a4d468 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4986,8 +4986,11 @@ int i915_gem_init(struct drm_device *dev)
goto out_unlock;
ret = dev_priv->gt.init_rings(dev);
- if (ret)
+ if (ret) {
+ i915_gem_context_fini(dev);
+ /* XXX: anything else to be undone here? */
Yes. Make this a separate patch and begin the onion unwind.
Hmm. Actually, we have to make sure that we can still modeset if this
function fails - that is anything but utter catastrophe should just
result in loss of functionality (no stolen, no GEM execution etc) but we
can still drive the displays so the user can see how bad the damage is.
-Chris
Yes, Mika said that's why (he thought) there wasn't a complete reversal of
everything the driver has done up to this point.
The addition of the context_fini() seems reasonable, that's going to make it
leak a bit less, while still leaving basic framebuffer working.
Could be a separate patch if you like, but hardly seems worth splitting from
the other chunk, which after all only replaces unreachable code with a
WARNing.
... it should be split. As a rule of thumb at least. I don't really care
all that much here though, so jut for the future.
-Daniel
That was already done in the updated (v5) patchset posted 2016-02-05.
This (v4) sequence is therefore already obsolete.
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: fix context/engine cleanup order
On 11/02/16 15:02, Mika Kuoppala wrote:
Chris Wilson writes:
On Sat, Jan 30, 2016 at 11:17:07AM +, Chris Wilson wrote:
On Fri, Jan 29, 2016 at 07:19:31PM +, Dave Gordon wrote:
From: Nick Hoath
Swap the order of context & engine cleanup, so that contexts are cleaned
up first, and *then* engines. This is a more sensible order anyway, but
in particular has become necessary since the 'intel_ring_initialized()
must be simple and inline' patch, which now uses ring->dev as an
'initialised' flag, so it can now be NULL after engine teardown. This in
turn can cause a problem in the context code, which (used to) check the
ring->dev->struct_mutex -- causing a fault if ring->dev was NULL.
Also rename the cleanup function to reflect what it actually does
(cleanup engines, not a ringbuffer), and fix an annoying whitespace
issue.
v2: Also make the fix in i915_load_modeset_init, not just in
i915_driver_unload (Chris Wilson)
v3: Had extra stuff in it.
v4: Reverted extra stuff (so we're back to v2).
Rebased and updated commentary above (Dave Gordon).
Signed-off-by: Nick Hoath
Signed-off-by: David Gordon
Reviewed-by: Chris Wilson
Have to drop that, with the recent context changes.
You have to move the gpu-reset now for execlists.
Basically pull it out into:
static void i915_unload_gem(struct drm_device *dev)
{
/*
* Neither the BIOS, ourselves or any other kernel
* expects the system to be in execlists mode on startup,
* so we need to reset the GPU back to legacy mode. And the only
* known way to disable logical contexts is through a GPU reset.
*
* So in order to leave the system in a known default configration,
* always reset the GPU upon unload. This also cleans up the GEM
* state tracking, flushing off the requests and leaving the system
* idle.
*
* Note that is of the upmost importance that the GPU is idle and
* all stray writes are flushed *before* we dismantle the backing
* storage for the pinned objects.
*/
i915_reset(dev);
mutex_lock(&dev->struct_mutex);
i915_gem_context_fini(dev);
i915_gem_cleanup_ringbuffer(dev);
mutex_unlock(&dev->struct_mutex);
}
and then kill the intel_gpu_reset along both the cleanup pathsh
It appears this patch was applied without dropping my r-b for the issue
I pointed out above.
Now causes a splat in intel_logical_ring_cleanup when unloading module.
Best to revert and rework on top of Dave's cleanup set?
-Mika
This whole patchset was already superseded by a newer version before
Daniel merged it. The newer version doesn't have Chris's R-B on this
(context/engine) patch, only on two others that are still as they were
when he reviewed them.
Please go and look instead at [v5, 11 patches] posted 2016-02-05.
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] device: prevent a NULL pointer dereference in __intel_peek_fd
On 12/02/16 16:31, Martin Peres wrote: This is not a big issue to return -1 since the only codepath that uses it is for display purposes. Caught by Klockwork. Signed-off-by: Martin Peres --- src/intel_device.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/intel_device.c b/src/intel_device.c index 54c1443..35e652a 100644 --- a/src/intel_device.c +++ b/src/intel_device.c @@ -650,7 +650,10 @@ int __intel_peek_fd(ScrnInfoPtr scrn) dev = intel_device(scrn); assert(dev && dev->fd != -1); Doesn't Klocwork recognise the assert() above? I thought that would tell it that dev can't be NULL. .Dave. - return dev->fd; + if (!dev) + return -1; + else + return dev->fd; } int intel_has_render_node(struct intel_device *dev) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] kernel/cpu: Distinctive name for cpu_hotplug.dep_map
Hi,
According to scripts/get_maintainer.pl Ingo or Peter would be more
appropriate to merge.
Added them as To:
On ke, 2016-02-03 at 22:42 +0530, Gautham R Shenoy wrote:
> Hello Joonas,
>
> On Wed, Feb 03, 2016 at 04:24:28PM +0200, Joonas Lahtinen wrote:
> > Use distinctive name for cpu_hotplug.dep_map to avoid the actual
> > cpu_hotplug.lock appearing as cpu_hotplug.lock#2 in lockdep splats.
> >
> > Cc: Gautham R. Shenoy
> > Cc: Rafael J. Wysocki
> > Cc: Intel graphics driver community testing & development > x...@lists.freedesktop.org>
> > Signed-off-by: Joonas Lahtinen
> > ---
> > kernel/cpu.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/cpu.c b/kernel/cpu.c
> > index 5b9d396..6a13f24 100644
> > --- a/kernel/cpu.c
> > +++ b/kernel/cpu.c
> > @@ -78,7 +78,7 @@ static struct {
> > .wq = __WAIT_QUEUE_HEAD_INITIALIZER(cpu_hotplug.wq),
> > .lock = __MUTEX_INITIALIZER(cpu_hotplug.lock),
> > #ifdef CONFIG_DEBUG_LOCK_ALLOC
> > - .dep_map = {.name = "cpu_hotplug.lock" },
> > + .dep_map = STATIC_LOCKDEP_MAP_INIT("cpu_hotplug.dep_map",
> > &cpu_hotplug.dep_map),
>
> Looks good to me!
> Acked-by: Gautham R. Shenoy
>
Thanks!
Regards, Joonas
> --
> Thanks and Regards
> gautham.
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Use atomic helpers for suspend.
Op 09-02-16 om 15:58 schreef Ville Syrjälä:
> On Tue, Feb 09, 2016 at 03:05:51PM +0100, Maarten Lankhorst wrote:
>> Op 09-02-16 om 14:37 schreef Ville Syrjälä:
>>> On Tue, Feb 09, 2016 at 01:52:22PM +0100, Maarten Lankhorst wrote:
Instead of duplicating the functionality now that we no longer need
to preserve dpll state we can move to using the upstream suspend helper.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 3 +
drivers/gpu/drm/i915/i915_drv.c | 8 ---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 117
---
4 files changed, 42 insertions(+), 87 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 2b430b05f35d..a2d3b094f27c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2102,6 +2102,9 @@ int drm_atomic_helper_resume(struct drm_device *dev,
err = drm_atomic_commit(state);
drm_modeset_unlock_all(dev);
+ if (err)
+ drm_atomic_state_free(state);
+
return err;
}
EXPORT_SYMBOL(drm_atomic_helper_resume);
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index 11d8414edbbe..fc9b552bfcd1 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -600,13 +600,7 @@ static int i915_drm_suspend(struct drm_device *dev)
intel_suspend_gt_powersave(dev);
- /*
- * Disable CRTCs directly since we want to preserve sw state
- * for _thaw. Also, power gate the CRTC power wells.
- */
- drm_modeset_lock_all(dev);
intel_display_suspend(dev);
- drm_modeset_unlock_all(dev);
intel_dp_mst_suspend(dev);
@@ -761,9 +755,7 @@ static int i915_drm_resume(struct drm_device *dev)
dev_priv->display.hpd_irq_setup(dev);
spin_unlock_irq(&dev_priv->irq_lock);
- drm_modeset_lock_all(dev);
intel_display_resume(dev);
- drm_modeset_unlock_all(dev);
intel_dp_mst_resume(dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 8216665405eb..ef289514b97e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1848,6 +1848,7 @@ struct drm_i915_private {
enum modeset_restore modeset_restore;
struct mutex modeset_restore_lock;
+ struct drm_atomic_state *modeset_restore_state;
struct list_head vm_list; /* Global list of all address spaces */
struct i915_gtt gtt; /* VM representing the global address space */
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index e496c130364d..4c91fd1c5222 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6393,58 +6393,19 @@ static void intel_crtc_disable_noatomic(struct
drm_crtc *crtc)
*/
int intel_display_suspend(struct drm_device *dev)
{
- struct drm_mode_config *config = &dev->mode_config;
- struct drm_modeset_acquire_ctx *ctx = config->acquire_ctx;
- struct drm_atomic_state *state;
- struct drm_crtc *crtc;
- unsigned crtc_mask = 0;
- int ret = 0;
-
- if (WARN_ON(!ctx))
- return 0;
-
- lockdep_assert_held(&ctx->ww_ctx);
- state = drm_atomic_state_alloc(dev);
- if (WARN_ON(!state))
- return -ENOMEM;
-
- state->acquire_ctx = ctx;
- state->allow_modeset = true;
-
- for_each_crtc(dev, crtc) {
- struct drm_crtc_state *crtc_state =
- drm_atomic_get_crtc_state(state, crtc);
-
- ret = PTR_ERR_OR_ZERO(crtc_state);
- if (ret)
- goto free;
-
- if (!crtc_state->active)
- continue;
-
- crtc_state->active = false;
- crtc_mask |= 1 << drm_crtc_index(crtc);
- }
-
- if (crtc_mask) {
- ret = drm_atomic_commit(state);
-
- if (!ret) {
- for_each_crtc(dev, crtc)
- if (crtc_mask & (1 << drm_crtc_index(crtc)))
- crtc->state->active = true;
-
- return ret;
- }
- }
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ int ret;
-free:
- if (ret)
+ dev_priv->modeset_restore_state = drm_atomic_helper_suspend(dev);
+ ret = PTR_ERR_OR_ZERO(dev_priv->modeset_restore_state);
+ if (ret) {
DRM_ERROR("Suspending crtc's
[Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting
Instead of implementing a custom locked reference counting, use lockref.
Current implementation leads to a deadlock splat on Intel SKL platforms
when lockdep debugging is enabled.
This is due to few of CPUfreq drivers (including Intel P-state) having this;
policy->rwsem is locked during driver initialization and the functions called
during init that actually apply CPU limits use get_online_cpus (because they
have other calling paths too), which will briefly lock cpu_hotplug.lock to
increase cpu_hotplug.refcount.
On later calling path, when doing a suspend, when cpu_hotplug_begin() is called
in disable_nonboot_cpus(), callbacks to CPUfreq functions get called after,
which will lock policy->rwsem and cpu_hotplug.lock is already held by
cpu_hotplug_begin() and we do have a potential deadlock scenario reported by
our CI system (though it is a very unlikely one). See the Bugzilla link for more
details.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93294
Cc: Linux kernel development
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: David Hildenbrand
Cc: Paul E. McKenney
Cc: Gautham R. Shenoy
Cc: Chris Wilson
Signed-off-by: Joonas Lahtinen
---
kernel/cpu.c | 87 +---
1 file changed, 54 insertions(+), 33 deletions(-)
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 5b9d396..8acec83 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -62,13 +63,10 @@ static struct {
struct task_struct *active_writer;
/* wait queue to wake up the active_writer */
wait_queue_head_t wq;
- /* verifies that no writer will get active while readers are active */
- struct mutex lock;
- /*
-* Also blocks the new readers during
-* an ongoing cpu hotplug operation.
-*/
- atomic_t refcount;
+ /* wait queue to wake up readers */
+ wait_queue_head_t reader_wq;
+ /* track online CPU users */
+ struct lockref lockref;
#ifdef CONFIG_DEBUG_LOCK_ALLOC
struct lockdep_map dep_map;
@@ -76,7 +74,7 @@ static struct {
} cpu_hotplug = {
.active_writer = NULL,
.wq = __WAIT_QUEUE_HEAD_INITIALIZER(cpu_hotplug.wq),
- .lock = __MUTEX_INITIALIZER(cpu_hotplug.lock),
+ .reader_wq = __WAIT_QUEUE_HEAD_INITIALIZER(cpu_hotplug.reader_wq),
#ifdef CONFIG_DEBUG_LOCK_ALLOC
.dep_map = {.name = "cpu_hotplug.lock" },
#endif
@@ -92,52 +90,64 @@ static struct {
void get_online_cpus(void)
{
- might_sleep();
+ DEFINE_WAIT(wait);
+
if (cpu_hotplug.active_writer == current)
return;
+
cpuhp_lock_acquire_read();
- mutex_lock(&cpu_hotplug.lock);
- atomic_inc(&cpu_hotplug.refcount);
- mutex_unlock(&cpu_hotplug.lock);
+
+ /* First to get might have to wait over a hotplug operation. */
+ while (!lockref_get_or_lock(&cpu_hotplug.lockref)) {
+ if (cpu_hotplug.lockref.count == 0) {
+ cpu_hotplug.lockref.count++;
+ spin_unlock(&cpu_hotplug.lockref.lock);
+ break;
+ }
+ spin_unlock(&cpu_hotplug.lockref.lock);
+
+ prepare_to_wait(&cpu_hotplug.reader_wq, &wait,
TASK_UNINTERRUPTIBLE);
+ schedule();
+ finish_wait(&cpu_hotplug.reader_wq, &wait);
+ }
}
EXPORT_SYMBOL_GPL(get_online_cpus);
void put_online_cpus(void)
{
- int refcount;
-
if (cpu_hotplug.active_writer == current)
return;
- refcount = atomic_dec_return(&cpu_hotplug.refcount);
- if (WARN_ON(refcount < 0)) /* try to fix things up */
- atomic_inc(&cpu_hotplug.refcount);
+ /* Last to release might have to wake queued hotplug operation. */
+ if (!lockref_put_or_lock(&cpu_hotplug.lockref)) {
+ WARN_ON(cpu_hotplug.lockref.count <= 0);
+ cpu_hotplug.lockref.count = 0;
+ spin_unlock(&cpu_hotplug.lockref.lock);
- if (refcount <= 0 && waitqueue_active(&cpu_hotplug.wq))
- wake_up(&cpu_hotplug.wq);
+ if (waitqueue_active(&cpu_hotplug.wq))
+ wake_up(&cpu_hotplug.wq);
+ }
cpuhp_lock_release();
-
}
EXPORT_SYMBOL_GPL(put_online_cpus);
/*
* This ensures that the hotplug operation can begin only when the
- * refcount goes to zero.
+ * cpu_hotplug.lockref goes to zero.
*
* Note that during a cpu-hotplug operation, the new readers, if any,
- * will be blocked by the cpu_hotplug.lock
+ * will be blocked by the cpu_hotplug.lockref being dead.
*
* Since cpu_hotplug_begin() is always called after invoking
* cpu_maps_update_begin(), we can be sure that only one writer is active.
*
* Note that theoretically, there is a possibility of a livelock:
- * - Refcount goes to zero, last reader wakes up the sleeping
+ * - Lockref goes t
Re: [Intel-gfx] [PATCH i-g-t v5] lib/igt_kms: Add COMIT_ATOMIC to igt_display_commit2()
Op 12-02-16 om 11:34 schreef Pratik Vishwakarma:
> From: Mayuresh Gharpure
>
> Co-Author : Marius Vlad
> Co-Author : Pratik Vishwakarma
>
> So far we have had only two commit styles, COMMIT_LEGACY
> and COMMIT_UNIVERSAL. This patch adds another commit style
> COMMIT_ATOMIC which makes use of drmModeAtomicCommit()
>
> v2: (Marius)
> i)Set CRTC_ID to zero while disabling plane
> ii)Modified the log message in igt_atomic_prepare_plane_commit
> https://patchwork.freedesktop.org/patch/71945/
>
> v3: (Marius)Set FB_ID to zero while disabling plane
> https://patchwork.freedesktop.org/patch/72179/
>
> v4: (Maarten) Corrected the typo in commit message
> https://patchwork.freedesktop.org/patch/72598/
>
> v5: Added check for DRM_CLIENT_CAP_ATOMIC in igt_display_init
> (Marius)
> i)Removed unused props from igt_display_init
> ii)Removed unused ret. Changed function to void
> iii)Declare the variable before checking if we have
> DRM_CLIENT_CAP_ATOMIC.
>
> Signed-off-by: Mayuresh Gharpure
> Signed-off-by: Pratik Vishwakarma
> ---
> lib/igt_kms.c | 317
> +-
> lib/igt_kms.h | 71 -
> 2 files changed, 386 insertions(+), 2 deletions(-)
>
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 90c8da7..8e201e8 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -145,6 +145,120 @@ const unsigned char* igt_kms_get_base_edid(void)
> *
> * Returns: an alternate edid block
> */
> +static const char *igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
> + "SRC_X",
> + "SRC_Y",
> + "SRC_W",
> + "SRC_H",
> + "CRTC_X",
> + "CRTC_Y",
> + "CRTC_W",
> + "CRTC_H",
> + "FB_ID",
> + "CRTC_ID",
> + "type",
> + "rotation"
> +};
> +
> +static const char *igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
> + "background_color"
> +};
> +
> +static const char *igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
> + "scaling mode",
> + "DPMS"
> +};
> +
> +/*
> + * Retrieve all the properies specified in props_name and store them into
> + * plane->atomic_props_plane.
> + */
> +static void
> +igt_atomic_fill_plane_props(igt_display_t *display, igt_plane_t *plane,
> + int num_props, const char **prop_names)
> +{
> + drmModeObjectPropertiesPtr props;
> + int i, j, fd;
> +
> + fd = display->drm_fd;
> +
> + props = drmModeObjectGetProperties(fd, plane->drm_plane->plane_id,
> DRM_MODE_OBJECT_PLANE);
> + igt_assert(props);
> +
> + for (i = 0; i < props->count_props; i++) {
> + drmModePropertyPtr prop =
> + drmModeGetProperty(fd, props->props[i]);
> +
> + for (j = 0; j < num_props; j++) {
> + if (strcmp(prop->name, prop_names[j]) != 0)
> + continue;
> +
> + plane->atomic_props_plane[j] = props->props[i];
> + break;
> + }
> +
> + drmModeFreeProperty(prop);
> + }
> +
> + drmModeFreeObjectProperties(props);
> +}
> +
> +/*
> + * Retrieve all the properies specified in props_name and store them into
> + * config->atomic_props_crtc and config->atomic_props_connector.
> + */
> +static void
> +igt_atomic_fill_props(igt_display_t *display, igt_output_t *output,
> + int num_crtc_props, const char **crtc_prop_names,
> + int num_connector_props, const char **conn_prop_names)
> +{
> + drmModeObjectPropertiesPtr props;
> + int i, j, fd;
> +
> + fd = display->drm_fd;
> +
> + props = drmModeObjectGetProperties(fd, output->config.crtc->crtc_id,
> DRM_MODE_OBJECT_CRTC);
> + igt_assert(props);
> +
> + for (i = 0; i < props->count_props; i++) {
> + drmModePropertyPtr prop =
> + drmModeGetProperty(fd, props->props[i]);
> +
> + for (j = 0; j < num_crtc_props; j++) {
> + if (strcmp(prop->name, crtc_prop_names[j]) != 0)
> + continue;
> +
> + output->config.atomic_props_crtc[j] = props->props[i];
> + break;
> + }
> +
> + drmModeFreeProperty(prop);
> + }
> +
> + drmModeFreeObjectProperties(props);
> + props = NULL;
> + props = drmModeObjectGetProperties(fd,
> output->config.connector->connector_id, DRM_MODE_OBJECT_CONNECTOR);
> + igt_assert(props);
> +
> + for (i = 0; i < props->count_props; i++) {
> + drmModePropertyPtr prop =
> + drmModeGetProperty(fd, props->props[i]);
> +
> + for (j = 0; j < num_connector_props; j++) {
> + if (strcmp(prop->name, conn_prop_names[j]) != 0)
> + continue;
> +
> + output->config.atomic_props_connector[j] =
> props->props[i];
> + break;
> + }
> +
> + drmModeFr
Re: [Intel-gfx] kernel crash in snd_hda_intel
On 15.02.2016 12:23, Takashi Iwai wrote: On Fri, 12 Feb 2016 17:47:21 +0100, Gabriel Feceoru wrote: !!! This caused a regression in the i-g-t drv_module_reload_basic test. Reproducible easily on HSW (i5-4460) with: #rmmod snd_hda_intel I couldn't reproduce this on my HSW machine. Does it happen always without without the monitor plugged? Reproducible with or without the monitor plugged in, just tested. Play a bit with rmmod/modprobe on snd_ha_intel and you'll get it. It's not always first time, but easy to catch. Gabriel. thanks, Takashi The bisect shows this as the offending commit: commit 25e4abb33df3aafa7d1efba8f82f9178268efab1 Author: Libin Yang Date: Tue Jan 12 11:13:27 2016 +0800 ALSA: hda - hdmi jack created based on pcm Jack is created based on pcm. Apply the acomp jack rule to dyn_pcm_assign. For dyn_pcm_assign: Driver does not use hda_jack. It operates snd_jack directly. snd_jack pointer will be stored in spec->pcm.jack instead of the current spec->acomp_jack. When pcm is assigned to pin, jack will be assigned to pin automatically. For !dyn_pcm_assign: Driver continues using hda_jack for less impact on the old cases. Pcm is statically assigned to pin. So is jack. spec->pcm.jack saves the snd_jack pointer created in hda_jack. Signed-off-by: Libin Yang Signed-off-by: Takashi Iwai [ 79.020523] BUG: unable to handle kernel paging request at 00015d80 [ 79.021314] IP: [] queued_spin_lock_slowpath+0xeb/0x180 [ 79.022125] PGD 0 [ 79.022881] Oops: 0002 [#1] SMP [ 79.023644] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel(-) snd_hda_codec x86_pkg_temp_thermal snd_hwdep snd_hda_core i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt ehci_pci fb_sys_fops r8169 ehci_hcd mii drm xhci_pci xhci_hcd video [ 79.026790] CPU: 0 PID: 1294 Comm: rmmod Tainted: G U 4.5.0-rc1+ #73 [ 79.028322] Hardware name: Dell Inc. Inspiron 3847/088DT1 , BIOS A06 01/15/2015 [ 79.029854] task: 8800dac9 ti: 88021270 task.ti: 88021270 [ 79.031384] RIP: 0010:[] [] queued_spin_lock_slowpath+0xeb/0x180 [ 79.032924] RSP: 0018:8802127039b0 EFLAGS: 00010002 [ 79.033698] RAX: 350c RBX: 8800d434ef90 RCX: 88021fa15d80 [ 79.035224] RDX: 00015d80 RSI: d434ef88 RDI: 8800d434ef90 [ 79.036751] RBP: 8802127039b0 R08: 0004 R09: [ 79.038277] R10: 8800daef8998 R11: 0004 R12: 0282 [ 79.039802] R13: R14: 0006 R15: 8800d434ef90 [ 79.041331] FS: 7f75be1ad700() GS:88021fa0() knlGS: [ 79.042863] CS: 0010 DS: ES: CR0: 80050033 [ 79.043638] CR2: 00015d80 CR3: 0002101b1000 CR4: 001406f0 [ 79.045166] Stack: [ 79.045926] 8802127039d0 81748e59 8800d434ed80 0005 [ 79.047462] 880212703a10 81597e73 817472d2 0003 [ 79.048995] 8800d434ecc0 0001 8800daef8800 [ 79.050528] Call Trace: [ 79.051293] [] _raw_spin_lock_irqsave+0x39/0x50 [ 79.052071] [] input_event+0x43/0x80 [ 79.052844] [] ? mutex_lock+0x12/0x30 [ 79.053619] [] snd_jack_report+0xee/0x110 [ 79.054396] [] hdmi_present_sense+0x13a/0x390 [snd_hda_codec_hdmi] [ 79.055921] [] ? regmap_unlock_mutex+0xe/0x10 [ 79.056699] [] generic_hdmi_resume+0x4d/0x60 [snd_hda_codec_hdmi] [ 79.058235] [] ? snd_hda_add_imux_item+0x120/0x120 [snd_hda_codec] [ 79.059771] [] hda_call_codec_resume+0xce/0x120 [snd_hda_codec] [ 79.061303] [] ? snd_hda_add_imux_item+0x120/0x120 [snd_hda_codec] [ 79.062835] [] hda_codec_runtime_resume+0x35/0x50 [snd_hda_codec] [ 79.064368] [] __rpm_callback+0x28/0x70 [ 79.065143] [] ? snd_hda_add_imux_item+0x120/0x120 [snd_hda_codec] [ 79.066676] [] rpm_callback+0x24/0x80 [ 79.067449] [] ? snd_hda_add_imux_item+0x120/0x120 [snd_hda_codec] [ 79.068983] [] rpm_resume+0x426/0x620 [ 79.069758] [] __pm_runtime_resume+0x4e/0x70 [ 79.070536] [] __device_release_driver+0x43/0x160 [ 79.071314] [] device_release_driver+0x23/0x30 [ 79.072085] [] bus_remove_device+0x101/0x170 [ 79.072862] [] device_del+0x139/0x270 [ 79.073638] [] ? widget_tree_free.isra.1+0x8b/0xa0 [snd_hda_core] [ 79.075170] [] snd_hdac_device_unregister+0x21/0x30 [snd_hda_core] [ 79.076703] [] snd_hda_codec_dev_free+0x1d/0x40 [snd_hda_codec] [ 79.078235] [] __snd_device_free+0x4c/0x80 [ 79.079010] [] snd_device_free_all+0x30/0x60 [ 79.079787] [] release_card_device+0x34/0x90 [ 79.080563] [] device_release+0x32/0x90 [ 79.081338] [] kobject_release+0x7a/0x190 [ 79.082113] [] kobject_put+0x27/0x50 [ 79.082886] [] put_device+0x17/0x20 [ 79.083659] [] snd_card_free+0x58/0x70 [
Re: [Intel-gfx] kernel crash in snd_hda_intel
On Mon, 15 Feb 2016 13:57:00 +0100, Gabriel Feceoru wrote: > > > > On 15.02.2016 12:23, Takashi Iwai wrote: > > On Fri, 12 Feb 2016 17:47:21 +0100, > > Gabriel Feceoru wrote: > >> > >> !!! This caused a regression in the i-g-t drv_module_reload_basic test. > >> > >> > >> Reproducible easily on HSW (i5-4460) with: > >> #rmmod snd_hda_intel > > > > I couldn't reproduce this on my HSW machine. Does it happen always > > without without the monitor plugged? > > Reproducible with or without the monitor plugged in, just tested. > Play a bit with rmmod/modprobe on snd_ha_intel and you'll get it. It's > not always first time, but easy to catch. Hmm, it still doesn't happen here... Does the bug disappear when you revert the commit? Takashi > Gabriel. > > > > > > > thanks, > > > > Takashi > > > >> The bisect shows this as the offending commit: > >> > >> > >> commit 25e4abb33df3aafa7d1efba8f82f9178268efab1 > >> Author: Libin Yang > >> Date: Tue Jan 12 11:13:27 2016 +0800 > >> > >> ALSA: hda - hdmi jack created based on pcm > >> > >> Jack is created based on pcm. > >> > >> Apply the acomp jack rule to dyn_pcm_assign. > >> For dyn_pcm_assign: > >>Driver does not use hda_jack. It operates snd_jack directly. > >>snd_jack pointer will be stored in spec->pcm.jack instead of > >>the current spec->acomp_jack. When pcm is assigned to pin, > >>jack will be assigned to pin automatically. > >> For !dyn_pcm_assign: > >>Driver continues using hda_jack for less impact on the old cases. > >>Pcm is statically assigned to pin. So is jack. spec->pcm.jack > >>saves the snd_jack pointer created in hda_jack. > >> > >> Signed-off-by: Libin Yang > >> Signed-off-by: Takashi Iwai > >> > >> > >> > >> > >> [ 79.020523] BUG: unable to handle kernel paging request at > >> 00015d80 > >> [ 79.021314] IP: [] > >> queued_spin_lock_slowpath+0xeb/0x180 > >> [ 79.022125] PGD 0 > >> [ 79.022881] Oops: 0002 [#1] SMP > >> [ 79.023644] Modules linked in: snd_hda_codec_hdmi > >> snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel(-) > >> snd_hda_codec x86_pkg_temp_thermal snd_hwdep snd_hda_core i915 > >> i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt ehci_pci > >> fb_sys_fops r8169 ehci_hcd mii drm xhci_pci xhci_hcd video > >> [ 79.026790] CPU: 0 PID: 1294 Comm: rmmod Tainted: G U > >> 4.5.0-rc1+ #73 > >> [ 79.028322] Hardware name: Dell Inc. Inspiron 3847/088DT1 , > >> BIOS A06 01/15/2015 > >> [ 79.029854] task: 8800dac9 ti: 88021270 task.ti: > >> 88021270 > >> [ 79.031384] RIP: 0010:[] [] > >> queued_spin_lock_slowpath+0xeb/0x180 > >> [ 79.032924] RSP: 0018:8802127039b0 EFLAGS: 00010002 > >> [ 79.033698] RAX: 350c RBX: 8800d434ef90 RCX: > >> 88021fa15d80 > >> [ 79.035224] RDX: 00015d80 RSI: d434ef88 RDI: > >> 8800d434ef90 > >> [ 79.036751] RBP: 8802127039b0 R08: 0004 R09: > >> > >> [ 79.038277] R10: 8800daef8998 R11: 0004 R12: > >> 0282 > >> [ 79.039802] R13: R14: 0006 R15: > >> 8800d434ef90 > >> [ 79.041331] FS: 7f75be1ad700() GS:88021fa0() > >> knlGS: > >> [ 79.042863] CS: 0010 DS: ES: CR0: 80050033 > >> [ 79.043638] CR2: 00015d80 CR3: 0002101b1000 CR4: > >> 001406f0 > >> [ 79.045166] Stack: > >> [ 79.045926] 8802127039d0 81748e59 8800d434ed80 > >> 0005 > >> [ 79.047462] 880212703a10 81597e73 817472d2 > >> 0003 > >> [ 79.048995] 8800d434ecc0 0001 > >> 8800daef8800 > >> [ 79.050528] Call Trace: > >> [ 79.051293] [] _raw_spin_lock_irqsave+0x39/0x50 > >> [ 79.052071] [] input_event+0x43/0x80 > >> [ 79.052844] [] ? mutex_lock+0x12/0x30 > >> [ 79.053619] [] snd_jack_report+0xee/0x110 > >> [ 79.054396] [] hdmi_present_sense+0x13a/0x390 > >> [snd_hda_codec_hdmi] > >> [ 79.055921] [] ? regmap_unlock_mutex+0xe/0x10 > >> [ 79.056699] [] generic_hdmi_resume+0x4d/0x60 > >> [snd_hda_codec_hdmi] > >> [ 79.058235] [] ? snd_hda_add_imux_item+0x120/0x120 > >> [snd_hda_codec] > >> [ 79.059771] [] hda_call_codec_resume+0xce/0x120 > >> [snd_hda_codec] > >> [ 79.061303] [] ? snd_hda_add_imux_item+0x120/0x120 > >> [snd_hda_codec] > >> [ 79.062835] [] hda_codec_runtime_resume+0x35/0x50 > >> [snd_hda_codec] > >> [ 79.064368] [] __rpm_callback+0x28/0x70 > >> [ 79.065143] [] ? snd_hda_add_imux_item+0x120/0x120 > >> [snd_hda_codec] > >> [ 79.066676] [] rpm_callback+0x24/0x80 > >> [ 79.067449] [] ? snd_hda_add_imux_item+0x120/0x120 > >> [snd_hda_codec] > >> [ 79.068983] [] rpm_resume+0x426/0x620 > >> [ 79.069758] [] __pm_runtime_resume+0x4e/0x70 > >> [ 79.070536] [] __device_release_driver+0x43/0x16
Re: [Intel-gfx] kernel crash in snd_hda_intel
On 15.02.2016 14:57, Takashi Iwai wrote: On Mon, 15 Feb 2016 13:57:00 +0100, Gabriel Feceoru wrote: On 15.02.2016 12:23, Takashi Iwai wrote: On Fri, 12 Feb 2016 17:47:21 +0100, Gabriel Feceoru wrote: !!! This caused a regression in the i-g-t drv_module_reload_basic test. Reproducible easily on HSW (i5-4460) with: #rmmod snd_hda_intel I couldn't reproduce this on my HSW machine. Does it happen always without without the monitor plugged? Reproducible with or without the monitor plugged in, just tested. Play a bit with rmmod/modprobe on snd_ha_intel and you'll get it. It's not always first time, but easy to catch. Hmm, it still doesn't happen here... Does the bug disappear when you revert the commit? The commit couldn't be reverted as is, there were dependencies to other commits. But reverting the entire sound merge fixed the problem. That was just to save our CI. Takashi Gabriel. thanks, Takashi The bisect shows this as the offending commit: commit 25e4abb33df3aafa7d1efba8f82f9178268efab1 Author: Libin Yang Date: Tue Jan 12 11:13:27 2016 +0800 ALSA: hda - hdmi jack created based on pcm Jack is created based on pcm. Apply the acomp jack rule to dyn_pcm_assign. For dyn_pcm_assign: Driver does not use hda_jack. It operates snd_jack directly. snd_jack pointer will be stored in spec->pcm.jack instead of the current spec->acomp_jack. When pcm is assigned to pin, jack will be assigned to pin automatically. For !dyn_pcm_assign: Driver continues using hda_jack for less impact on the old cases. Pcm is statically assigned to pin. So is jack. spec->pcm.jack saves the snd_jack pointer created in hda_jack. Signed-off-by: Libin Yang Signed-off-by: Takashi Iwai [ 79.020523] BUG: unable to handle kernel paging request at 00015d80 [ 79.021314] IP: [] queued_spin_lock_slowpath+0xeb/0x180 [ 79.022125] PGD 0 [ 79.022881] Oops: 0002 [#1] SMP [ 79.023644] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel(-) snd_hda_codec x86_pkg_temp_thermal snd_hwdep snd_hda_core i915 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt ehci_pci fb_sys_fops r8169 ehci_hcd mii drm xhci_pci xhci_hcd video [ 79.026790] CPU: 0 PID: 1294 Comm: rmmod Tainted: G U 4.5.0-rc1+ #73 [ 79.028322] Hardware name: Dell Inc. Inspiron 3847/088DT1 , BIOS A06 01/15/2015 [ 79.029854] task: 8800dac9 ti: 88021270 task.ti: 88021270 [ 79.031384] RIP: 0010:[] [] queued_spin_lock_slowpath+0xeb/0x180 [ 79.032924] RSP: 0018:8802127039b0 EFLAGS: 00010002 [ 79.033698] RAX: 350c RBX: 8800d434ef90 RCX: 88021fa15d80 [ 79.035224] RDX: 00015d80 RSI: d434ef88 RDI: 8800d434ef90 [ 79.036751] RBP: 8802127039b0 R08: 0004 R09: [ 79.038277] R10: 8800daef8998 R11: 0004 R12: 0282 [ 79.039802] R13: R14: 0006 R15: 8800d434ef90 [ 79.041331] FS: 7f75be1ad700() GS:88021fa0() knlGS: [ 79.042863] CS: 0010 DS: ES: CR0: 80050033 [ 79.043638] CR2: 00015d80 CR3: 0002101b1000 CR4: 001406f0 [ 79.045166] Stack: [ 79.045926] 8802127039d0 81748e59 8800d434ed80 0005 [ 79.047462] 880212703a10 81597e73 817472d2 0003 [ 79.048995] 8800d434ecc0 0001 8800daef8800 [ 79.050528] Call Trace: [ 79.051293] [] _raw_spin_lock_irqsave+0x39/0x50 [ 79.052071] [] input_event+0x43/0x80 [ 79.052844] [] ? mutex_lock+0x12/0x30 [ 79.053619] [] snd_jack_report+0xee/0x110 [ 79.054396] [] hdmi_present_sense+0x13a/0x390 [snd_hda_codec_hdmi] [ 79.055921] [] ? regmap_unlock_mutex+0xe/0x10 [ 79.056699] [] generic_hdmi_resume+0x4d/0x60 [snd_hda_codec_hdmi] [ 79.058235] [] ? snd_hda_add_imux_item+0x120/0x120 [snd_hda_codec] [ 79.059771] [] hda_call_codec_resume+0xce/0x120 [snd_hda_codec] [ 79.061303] [] ? snd_hda_add_imux_item+0x120/0x120 [snd_hda_codec] [ 79.062835] [] hda_codec_runtime_resume+0x35/0x50 [snd_hda_codec] [ 79.064368] [] __rpm_callback+0x28/0x70 [ 79.065143] [] ? snd_hda_add_imux_item+0x120/0x120 [snd_hda_codec] [ 79.066676] [] rpm_callback+0x24/0x80 [ 79.067449] [] ? snd_hda_add_imux_item+0x120/0x120 [snd_hda_codec] [ 79.068983] [] rpm_resume+0x426/0x620 [ 79.069758] [] __pm_runtime_resume+0x4e/0x70 [ 79.070536] [] __device_release_driver+0x43/0x160 [ 79.071314] [] device_release_driver+0x23/0x30 [ 79.072085] [] bus_remove_device+0x101/0x170 [ 79.072862] [] device_del+0x139/0x270 [ 79.073638] [] ? widget_tree_free.isra.1+0x8b/0xa0 [snd_hda_core] [ 79.075170] [] snd_hdac_device_unregister+0x21/0x30 [snd_hda_core] [ 79.076703] [] snd_hda_codec_dev
Re: [Intel-gfx] [PATCH V5] drm/i915/skl: SKL CDCLK change on modeset tracking VCO
On Fri, Feb 12, 2016 at 06:06:10PM -0800, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Set cdclk based on the max required pixel clock based on VCO
> selected. Track boot vco instead of boot cdclk.
>
> The vco is now tracked at the atomic level and all CRTCs updated if
> the required vco is changed. Not tested with eDP v1.4 panels that
> require 8640 vco due to availability.
>
> V1: initial version
> V2: add vco tracking in intel_dp_compute_config(), rename
> skl_boot_cdclk.
> V3: rebase, V2 feedback not possible as encoders are not aware of
> atomic.
> V4: track target vco is atomic state. modeset all CRTCs if vco changes
> V5: rename atomic variable, cleaner if/else logic, use existing vco if
> encoder does not return a new vco value. check_patch.pl cleanup
>
> Signed-off-by: Clint Taylor
> Cc: Ville =?iso-8859-1?Q?Syrj=E4l=E4?=
> ---
> drivers/gpu/drm/i915/i915_drv.h |2 +-
> drivers/gpu/drm/i915/intel_ddi.c |2 +-
> drivers/gpu/drm/i915/intel_display.c | 114
> +-
> drivers/gpu/drm/i915/intel_dp.c |6 +-
> drivers/gpu/drm/i915/intel_drv.h |4 ++
> 5 files changed, 111 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 8216665..f65dd1a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1822,7 +1822,7 @@ struct drm_i915_private {
> int num_fence_regs; /* 8 on pre-965, 16 otherwise */
>
> unsigned int fsb_freq, mem_freq, is_ddr3;
> - unsigned int skl_boot_cdclk;
> + unsigned int skl_vco_freq;
> unsigned int cdclk_freq, max_cdclk_freq, atomic_cdclk_freq;
> unsigned int max_dotclk_freq;
> unsigned int hpll_freq;
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 6d5b09f..285adab 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2958,7 +2958,7 @@ void intel_ddi_pll_init(struct drm_device *dev)
> int cdclk_freq;
>
> cdclk_freq = dev_priv->display.get_display_clock_speed(dev);
> - dev_priv->skl_boot_cdclk = cdclk_freq;
> + dev_priv->skl_vco_freq = skl_cdclk_get_vco(cdclk_freq);
> if (skl_sanitize_cdclk(dev_priv))
> DRM_DEBUG_KMS("Sanitized cdclk programmed by pre-os\n");
> if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE))
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 9e2273b..c283abd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5663,7 +5663,7 @@ static unsigned int skl_cdclk_decimal(unsigned int freq)
> return (freq - 1000) / 500;
> }
>
> -static unsigned int skl_cdclk_get_vco(unsigned int freq)
> +unsigned int skl_cdclk_get_vco(unsigned int freq)
> {
> unsigned int i;
>
> @@ -5821,17 +5821,21 @@ void skl_uninit_cdclk(struct drm_i915_private
> *dev_priv)
>
> void skl_init_cdclk(struct drm_i915_private *dev_priv)
> {
> - unsigned int required_vco;
> + unsigned int cdclk;
>
> /* DPLL0 not enabled (happens on early BIOS versions) */
> if (!(I915_READ(LCPLL1_CTL) & LCPLL_PLL_ENABLE)) {
> /* enable DPLL0 */
> - required_vco = skl_cdclk_get_vco(dev_priv->skl_boot_cdclk);
> - skl_dpll0_enable(dev_priv, required_vco);
> + if (dev_priv->skl_vco_freq != 8640)
> + dev_priv->skl_vco_freq = 8100;
> + skl_dpll0_enable(dev_priv, dev_priv->skl_vco_freq);
> + cdclk = ((dev_priv->skl_vco_freq == 8100) ? 337500 : 308570);
> + } else {
> + cdclk = dev_priv->cdclk_freq;
> }
>
> - /* set CDCLK to the frequency the BIOS chose */
> - skl_set_cdclk(dev_priv, dev_priv->skl_boot_cdclk);
> + /* set CDCLK to the lowest frequency, Modeset follows */
> + skl_set_cdclk(dev_priv, cdclk);
>
> /* enable DBUF power */
> I915_WRITE(DBUF_CTL, I915_READ(DBUF_CTL) | DBUF_POWER_REQUEST);
> @@ -5847,7 +5851,7 @@ int skl_sanitize_cdclk(struct drm_i915_private
> *dev_priv)
> {
> uint32_t lcpll1 = I915_READ(LCPLL1_CTL);
> uint32_t cdctl = I915_READ(CDCLK_CTL);
> - int freq = dev_priv->skl_boot_cdclk;
> + int freq = dev_priv->cdclk_freq;
>
> /*
>* check if the pre-os intialized the display
> @@ -5871,11 +5875,7 @@ int skl_sanitize_cdclk(struct drm_i915_private
> *dev_priv)
> /* All well; nothing to sanitize */
> return false;
> sanitize:
> - /*
> - * As of now initialize with max cdclk till
> - * we get dynamic cdclk support
> - * */
> - dev_priv->skl_boot_cdclk = dev_priv->max_cdclk_freq;
> +
> skl_init_cdclk(dev_priv);
>
> /* we did have to sanitize */
> @@ -9845,6 +9845,70 @@ static void broadwell_modeset_commit_cdclk
[Intel-gfx] [PATCH] drm/atomic: Allow for holes in connector state.
Because we record connector_mask using 1 << drm_connector_index now
the connector_mask should stay the same even when other connectors
are removed. This was not the case with MST, in that case when removing
a connector all other connectors may change their index.
This is fixed by waiting until the first get_connector_state to allocate
connector_state, and force reallocation when state is too small.
As a side effect connector arrays no longer have to be preallocated,
and can be allocated on first use which means a less allocations in
the page flip only path.
Fixes: 14de6c44d149 ("drm/atomic: Remove drm_atomic_connectors_for_crtc.")
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic.c| 45 +
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
drivers/gpu/drm/drm_crtc.c | 45 +
include/drm/drm_crtc.h | 8 ++-
4 files changed, 45 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 8fb469c4e4b8..5d4774450540 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -65,8 +65,6 @@ drm_atomic_state_init(struct drm_device *dev, struct
drm_atomic_state *state)
*/
state->allow_modeset = true;
- state->num_connector = ACCESS_ONCE(dev->mode_config.num_connector);
-
state->crtcs = kcalloc(dev->mode_config.num_crtc,
sizeof(*state->crtcs), GFP_KERNEL);
if (!state->crtcs)
@@ -83,16 +81,6 @@ drm_atomic_state_init(struct drm_device *dev, struct
drm_atomic_state *state)
sizeof(*state->plane_states), GFP_KERNEL);
if (!state->plane_states)
goto fail;
- state->connectors = kcalloc(state->num_connector,
- sizeof(*state->connectors),
- GFP_KERNEL);
- if (!state->connectors)
- goto fail;
- state->connector_states = kcalloc(state->num_connector,
- sizeof(*state->connector_states),
- GFP_KERNEL);
- if (!state->connector_states)
- goto fail;
state->dev = dev;
@@ -823,19 +811,28 @@ drm_atomic_get_connector_state(struct drm_atomic_state
*state,
index = drm_connector_index(connector);
- /*
-* Construction of atomic state updates can race with a connector
-* hot-add which might overflow. In this case flip the table and just
-* restart the entire ioctl - no one is fast enough to livelock a cpu
-* with physical hotplug events anyway.
-*
-* Note that we only grab the indexes once we have the right lock to
-* prevent hotplug/unplugging of connectors. So removal is no problem,
-* at most the array is a bit too large.
-*/
if (index >= state->num_connector) {
- DRM_DEBUG_ATOMIC("Hot-added connector would overflow state
array, restarting\n");
- return ERR_PTR(-EAGAIN);
+ struct drm_connector **c;
+ struct drm_connector_state **cs;
+
+ u32 alloc = max(index + 1, config->num_connector);
+
+ c = krealloc(state->connectors, alloc *
sizeof(*state->connectors), GFP_KERNEL);
+ if (!c)
+ return ERR_PTR(-ENOMEM);
+
+ state->connectors = c;
+ memset(&state->connectors[state->num_connector], 0,
+ sizeof(*state->connectors) * (alloc -
state->num_connector));
+
+ cs = krealloc(state->connector_states, alloc *
sizeof(*state->connector_states), GFP_KERNEL);
+ if (!cs)
+ return ERR_PTR(-ENOMEM);
+
+ state->connector_states = cs;
+ memset(&state->connector_states[state->num_connector], 0,
+ sizeof(*state->connector_states) * (alloc -
state->num_connector));
+ state->num_connector = alloc;
}
if (state->connector_states[index])
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 2b430b05f35d..4da4f2a49078 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1535,7 +1535,7 @@ void drm_atomic_helper_swap_state(struct drm_device *dev,
{
int i;
- for (i = 0; i < dev->mode_config.num_connector; i++) {
+ for (i = 0; i < state->num_connector; i++) {
struct drm_connector *connector = state->connectors[i];
if (!connector)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 65258acddb90..ea00aea88de7 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -918,12 +918,18 @@ int drm_connector_init(struct drm_device *dev,
connector->base.properties = &con
Re: [Intel-gfx] [PATCH 02/12] drm/i915: ensure the HW is powered during display pipe HW readout
Imre Deak writes:
> The assumption when adding the intel_display_power_is_enabled() checks
> was that if it returns success the power can't be turned off afterwards
> during the HW access, which is guaranteed by modeset locks. This isn't
> always true, so make sure we hold a dedicated reference for the time of
> the access.
>
> Signed-off-by: Imre Deak
Was concerned on domain mask overflows but there was already
BUILD_BUG_ON for it.
Revieved-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_display.c | 67
> ++--
> 1 file changed, 48 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 836bbdc..6abfc54 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -8181,18 +8181,22 @@ static bool i9xx_get_pipe_config(struct intel_crtc
> *crtc,
> {
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> + enum intel_display_power_domain power_domain;
> uint32_t tmp;
> + bool ret;
>
> - if (!intel_display_power_is_enabled(dev_priv,
> - POWER_DOMAIN_PIPE(crtc->pipe)))
> + power_domain = POWER_DOMAIN_PIPE(crtc->pipe);
> + if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
> return false;
>
> pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe;
> pipe_config->shared_dpll = DPLL_ID_PRIVATE;
>
> + ret = false;
> +
> tmp = I915_READ(PIPECONF(crtc->pipe));
> if (!(tmp & PIPECONF_ENABLE))
> - return false;
> + goto out;
>
> if (IS_G4X(dev) || IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
> switch (tmp & PIPECONF_BPC_MASK) {
> @@ -8272,7 +8276,12 @@ static bool i9xx_get_pipe_config(struct intel_crtc
> *crtc,
> pipe_config->base.adjusted_mode.crtc_clock =
> pipe_config->port_clock / pipe_config->pixel_multiplier;
>
> - return true;
> + ret = true;
> +
> +out:
> + intel_display_power_put(dev_priv, power_domain);
> +
> + return ret;
> }
>
> static void ironlake_init_pch_refclk(struct drm_device *dev)
> @@ -9376,18 +9385,21 @@ static bool ironlake_get_pipe_config(struct
> intel_crtc *crtc,
> {
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> + enum intel_display_power_domain power_domain;
> uint32_t tmp;
> + bool ret;
>
> - if (!intel_display_power_is_enabled(dev_priv,
> - POWER_DOMAIN_PIPE(crtc->pipe)))
> + power_domain = POWER_DOMAIN_PIPE(crtc->pipe);
> + if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
> return false;
>
> pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe;
> pipe_config->shared_dpll = DPLL_ID_PRIVATE;
>
> + ret = false;
> tmp = I915_READ(PIPECONF(crtc->pipe));
> if (!(tmp & PIPECONF_ENABLE))
> - return false;
> + goto out;
>
> switch (tmp & PIPECONF_BPC_MASK) {
> case PIPECONF_6BPC:
> @@ -9450,7 +9462,12 @@ static bool ironlake_get_pipe_config(struct intel_crtc
> *crtc,
>
> ironlake_get_pfit_config(crtc, pipe_config);
>
> - return true;
> + ret = true;
> +
> +out:
> + intel_display_power_put(dev_priv, power_domain);
> +
> + return ret;
> }
>
> static void assert_can_disable_lcpll(struct drm_i915_private *dev_priv)
> @@ -9982,12 +,17 @@ static bool haswell_get_pipe_config(struct intel_crtc
> *crtc,
> {
> struct drm_device *dev = crtc->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> - enum intel_display_power_domain pfit_domain;
> + enum intel_display_power_domain power_domain;
> + unsigned long power_domain_mask;
> uint32_t tmp;
> + bool ret;
>
> - if (!intel_display_power_is_enabled(dev_priv,
> - POWER_DOMAIN_PIPE(crtc->pipe)))
> + power_domain = POWER_DOMAIN_PIPE(crtc->pipe);
> + if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
> return false;
> + power_domain_mask = BIT(power_domain);
> +
> + ret = false;
>
> pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe;
> pipe_config->shared_dpll = DPLL_ID_PRIVATE;
> @@ -10014,13 +10036,14 @@ static bool haswell_get_pipe_config(struct
> intel_crtc *crtc,
> pipe_config->cpu_transcoder = TRANSCODER_EDP;
> }
>
> - if (!intel_display_power_is_enabled(dev_priv,
> - POWER_DOMAIN_TRANSCODER(pipe_config->cpu_transcoder)))
> - return false;
> + power_domain = POWER_DOMAIN_TRANSCODER(pipe_config->cpu_transcoder);
> + if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
> + goto out;
> + power_d
Re: [Intel-gfx] [PATCHv2 4/4] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT
On Mon, Feb 15, 2016 at 06:55:07AM +, R, Durgadoss wrote: > Hi Ville, > > >-Original Message- > >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > >Sent: Friday, February 12, 2016 10:43 PM > >To: R, Durgadoss > >Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander > > > >Subject: Re: [Intel-gfx] [PATCHv2 4/4] drm/i915/dp: Enable Upfront link > >training for typeC DP support on > >BXT > > > >On Mon, Feb 01, 2016 at 07:27:53PM +0530, Durgadoss R wrote: > >> To support USB type C alternate DP mode, the display driver needs to > >> know the number of lanes required by the DP panel as well as number > >> of lanes that can be supported by the type-C cable. Sometimes, the > >> type-C cable may limit the bandwidth even if Panel can support > >> more lanes. To address these scenarios, the display driver will > >> start link training with max lanes, and if that fails, the driver > >> falls back to x2 lanes; and repeats this procedure for all > >> bandwidth/lane configurations. > >> > >> * Since link training is done before modeset only the port > >> (and not pipe/planes) and its associated PLLs are enabled. > >> * On DP hotplug: Directly start link training on the crtc > >> associated with the DP encoder. > >> * On Connected boot scenarios: When booted with an LFP and a DP, > >> typically, BIOS brings up DP. In these cases, we disable the > >> crtc, do upfront link training and then re-enable it back. > >> * All local changes made for upfront link training are reset > >> to their previous values once it is done; so that the > >> subsequent modeset is not aware of these changes. > > > >Glancing over this stuff, it doesn't look all that good on the locking > >front. Mainly there doesn't seem to locking. > > > >In general I'm not really convinced upfront link training is a very good > >idea if it needs a pipe. What happens if we fail to find a free pipe? > > > >I'd be much happier about this if we could make do without a pipe at > > We actually don't enable/disable the pipe. We need the crtc structures > because values like port clock/link bw/dpll hw state are stored in > crtc->config structures. This is why we had to touch crtc related > data structures. > > Ander has pulled the dpll_hw_states out of crtc structures and made them > independent. With this, things should improve.. I need to try this > implementation to see if we can/can't completely get away > with modifying crtc structures. One option might involve adding a fake crtc if we can't easily detangle it from the code. But obviously if we can remove the crtc dependency things ought to be much cleaner. I already had the thought that we might want to add fake crtcs for dealing with the MST main link, and just use atomic to modeset both the main link with its fake crtc and real encoder alongside any streams with their real crtcs and fake encoders. > > >least on some modern platforms and actually limit the feature to > >those platforms. PLLs are another concern, but I think modern platforms > >often have some kind of way to always get the standard DP frequencies > >from eg. the LCPLL. > > > >If we do go with the "hope you find a free pipe" approach, then it > >really needs to do that atomic locking stuff right. Otherwise I'd expect > > Yes, we missed it. Ander pointed out the place where we need this > locking. So, we will re-work this. One concern is how whether it might block other threads from eg. page flipping. I suppose if we have independent crtcs it should be fine since page flip won't require the connetion_mutex. > > Thanks, > Durga > > >fireworks when someone plugs in a display while there's modeset > >happening. > > > >-- > >Ville Syrjälä > >Intel OTC -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Kill off intel_crtc->atomic! (rev8)
== Summary == Series 77v8 Kill off intel_crtc->atomic! http://patchwork.freedesktop.org/api/1.0/series/77/revisions/8/mbox/ Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (skl-i5k-2) pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE Subgroup basic-flip-vs-wf_vblank: pass -> DMESG-WARN (skl-i5k-2) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> FAIL (hsw-brixbox) fail -> PASS (bdw-nuci7) Subgroup basic-rte: dmesg-warn -> PASS (bsw-nuc-2) pass -> FAIL (bdw-ultra) bdw-nuci7total:162 pass:152 dwarn:0 dfail:0 fail:0 skip:10 bdw-ultratotal:165 pass:151 dwarn:0 dfail:0 fail:1 skip:13 bsw-nuc-2total:165 pass:136 dwarn:0 dfail:0 fail:0 skip:29 byt-nuc total:165 pass:141 dwarn:0 dfail:0 fail:0 skip:24 hsw-brixbox total:165 pass:150 dwarn:0 dfail:0 fail:1 skip:14 hsw-gt2 total:165 pass:154 dwarn:0 dfail:0 fail:1 skip:10 ilk-hp8440p total:165 pass:115 dwarn:1 dfail:0 fail:1 skip:48 ivb-t430stotal:165 pass:150 dwarn:0 dfail:0 fail:1 skip:14 skl-i5k-2total:165 pass:147 dwarn:3 dfail:0 fail:0 skip:15 snb-dellxps total:165 pass:142 dwarn:0 dfail:0 fail:1 skip:22 snb-x220ttotal:165 pass:142 dwarn:0 dfail:0 fail:2 skip:21 Results at /archive/results/CI_IGT_test/Patchwork_1389/ f2110d8eac120416f8f5669f2aa561d9ab330a77 drm-intel-nightly: 2016y-02m-15d-09h-53m-04s UTC integration manifest 6c3070b739e39258955200bc894f404624443512 drm/i915: Remove vblank wait from hsw_enable_ips. a2efbd40f02b67ccfad95fe1aaa15ee16d064587 drm/i915: Do not compute watermarks on a noop. d4bd3c52cb02bc40d649a9f6a894ea9cea39cd5f drm/i915: Nuke fbc members from intel_crtc->atomic, v2. e18153d768dc4e148e64593a6426c7c17f189299 drm/i915: Remove some post-commit members from intel_crtc->atomic, v2. bbea33f7e7ddb289c194963cf8ebd2e6ff2dc800 drm/i915: Remove update_sprite_watermarks. e593cced664d88417e24324260b9458904268c3d drm/i915: Kill off intel_crtc->atomic.wait_vblank, v4. 3b74695aaa8dd202baec985c3338b36083648c17 drm/i915: Unify power domain handling. a1af80d9af7f7bbd18b60c0e633436ff2bc53c92 drm/i915: Pass crtc state to modeset_get_crtc_power_domains. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] device: prevent a NULL pointer dereference in __intel_peek_fd
On 15/02/16 14:24, Dave Gordon wrote: On 12/02/16 16:31, Martin Peres wrote: This is not a big issue to return -1 since the only codepath that uses it is for display purposes. Caught by Klockwork. Signed-off-by: Martin Peres --- src/intel_device.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/intel_device.c b/src/intel_device.c index 54c1443..35e652a 100644 --- a/src/intel_device.c +++ b/src/intel_device.c @@ -650,7 +650,10 @@ int __intel_peek_fd(ScrnInfoPtr scrn) dev = intel_device(scrn); assert(dev && dev->fd != -1); Doesn't Klocwork recognise the assert() above? I thought that would tell it that dev can't be NULL. It does not, I had to close many false positives related to this... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] kernel crash in snd_hda_intel
On Mon, 15 Feb 2016 14:20:46 +0100, Gabriel Feceoru wrote: > > > > On 15.02.2016 14:57, Takashi Iwai wrote: > > On Mon, 15 Feb 2016 13:57:00 +0100, > > Gabriel Feceoru wrote: > >> > >> > >> > >> On 15.02.2016 12:23, Takashi Iwai wrote: > >>> On Fri, 12 Feb 2016 17:47:21 +0100, > >>> Gabriel Feceoru wrote: > > !!! This caused a regression in the i-g-t drv_module_reload_basic test. > > > Reproducible easily on HSW (i5-4460) with: > #rmmod snd_hda_intel > >>> > >>> I couldn't reproduce this on my HSW machine. Does it happen always > >>> without without the monitor plugged? > >> > >> Reproducible with or without the monitor plugged in, just tested. > >> Play a bit with rmmod/modprobe on snd_ha_intel and you'll get it. It's > >> not always first time, but easy to catch. > > > > Hmm, it still doesn't happen here... > > Does the bug disappear when you revert the commit? > > The commit couldn't be reverted as is, there were dependencies to other > commits. Huh? On sound for-next branch, it can be reverted cleanly. Could you check whether the issue happens sound git tree for-next branch, too? If yes, revert the commit there and retry. Takashi > But reverting the entire sound merge fixed the problem. That was just to > save our CI. > > > > > > > Takashi > > > > > >> Gabriel. > >> > >>> > >>> > >>> thanks, > >>> > >>> Takashi > >>> > The bisect shows this as the offending commit: > > > commit 25e4abb33df3aafa7d1efba8f82f9178268efab1 > Author: Libin Yang > Date: Tue Jan 12 11:13:27 2016 +0800 > > ALSA: hda - hdmi jack created based on pcm > > Jack is created based on pcm. > > Apply the acomp jack rule to dyn_pcm_assign. > For dyn_pcm_assign: > Driver does not use hda_jack. It operates snd_jack directly. > snd_jack pointer will be stored in spec->pcm.jack instead of > the current spec->acomp_jack. When pcm is assigned to pin, > jack will be assigned to pin automatically. > For !dyn_pcm_assign: > Driver continues using hda_jack for less impact on the old cases. > Pcm is statically assigned to pin. So is jack. spec->pcm.jack > saves the snd_jack pointer created in hda_jack. > > Signed-off-by: Libin Yang > Signed-off-by: Takashi Iwai > > > > > [ 79.020523] BUG: unable to handle kernel paging request at > 00015d80 > [ 79.021314] IP: [] > queued_spin_lock_slowpath+0xeb/0x180 > [ 79.022125] PGD 0 > [ 79.022881] Oops: 0002 [#1] SMP > [ 79.023644] Modules linked in: snd_hda_codec_hdmi > snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel(-) > snd_hda_codec x86_pkg_temp_thermal snd_hwdep snd_hda_core i915 > i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt ehci_pci > fb_sys_fops r8169 ehci_hcd mii drm xhci_pci xhci_hcd video > [ 79.026790] CPU: 0 PID: 1294 Comm: rmmod Tainted: G U > 4.5.0-rc1+ #73 > [ 79.028322] Hardware name: Dell Inc. Inspiron 3847/088DT1 , > BIOS A06 01/15/2015 > [ 79.029854] task: 8800dac9 ti: 88021270 task.ti: > 88021270 > [ 79.031384] RIP: 0010:[] [] > queued_spin_lock_slowpath+0xeb/0x180 > [ 79.032924] RSP: 0018:8802127039b0 EFLAGS: 00010002 > [ 79.033698] RAX: 350c RBX: 8800d434ef90 RCX: > 88021fa15d80 > [ 79.035224] RDX: 00015d80 RSI: d434ef88 RDI: > 8800d434ef90 > [ 79.036751] RBP: 8802127039b0 R08: 0004 R09: > > [ 79.038277] R10: 8800daef8998 R11: 0004 R12: > 0282 > [ 79.039802] R13: R14: 0006 R15: > 8800d434ef90 > [ 79.041331] FS: 7f75be1ad700() GS:88021fa0() > knlGS: > [ 79.042863] CS: 0010 DS: ES: CR0: 80050033 > [ 79.043638] CR2: 00015d80 CR3: 0002101b1000 CR4: > 001406f0 > [ 79.045166] Stack: > [ 79.045926] 8802127039d0 81748e59 8800d434ed80 > 0005 > [ 79.047462] 880212703a10 81597e73 817472d2 > 0003 > [ 79.048995] 8800d434ecc0 0001 > 8800daef8800 > [ 79.050528] Call Trace: > [ 79.051293] [] _raw_spin_lock_irqsave+0x39/0x50 > [ 79.052071] [] input_event+0x43/0x80 > [ 79.052844] [] ? mutex_lock+0x12/0x30 > [ 79.053619] [] snd_jack_report+0xee/0x110 > [ 79.054396] [] hdmi_present_sense+0x13a/0x390 > [snd_hda_codec_hdmi] > [ 79.055921] [] ? regmap_unlock_mutex+0xe/0x10 > [ 79.056699] [] generic_hdmi_resume+0x4d/0x60 >
Re: [Intel-gfx] [PATCH v4 6/6] drm/i915: fix context/engine cleanup order
On 11/02/16 13:36, Chris Wilson wrote: On Sat, Jan 30, 2016 at 11:17:07AM +, Chris Wilson wrote: On Fri, Jan 29, 2016 at 07:19:31PM +, Dave Gordon wrote: From: Nick Hoath Swap the order of context & engine cleanup, so that contexts are cleaned up first, and *then* engines. This is a more sensible order anyway, but in particular has become necessary since the 'intel_ring_initialized() must be simple and inline' patch, which now uses ring->dev as an 'initialised' flag, so it can now be NULL after engine teardown. This in turn can cause a problem in the context code, which (used to) check the ring->dev->struct_mutex -- causing a fault if ring->dev was NULL. [snip] It appears this patch was applied without dropping my r-b for the issue I pointed out above. -Chris Not only that, but it was plucked from the end of the set of 6 patches without the earlier ones in the sequence, despite the cover letter [0/6] saying this: Patches reordered again; the bug fixes are now in patches 3 and 5. The former could stand alone; the latter depends on patch 4 and is a prerequisite for Nick's patch [6/6] to function. So there's no chance that this one alone could be expected to work :( .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] device: prevent a NULL pointer dereference in __intel_peek_fd
On Mon, Feb 15, 2016 at 12:24:04PM +, Dave Gordon wrote: > On 12/02/16 16:31, Martin Peres wrote: > >This is not a big issue to return -1 since the only codepath that uses > >it is for display purposes. > > > >Caught by Klockwork. > > > >Signed-off-by: Martin Peres > >--- > > src/intel_device.c | 5 - > > 1 file changed, 4 insertions(+), 1 deletion(-) > > > >diff --git a/src/intel_device.c b/src/intel_device.c > >index 54c1443..35e652a 100644 > >--- a/src/intel_device.c > >+++ b/src/intel_device.c > >@@ -650,7 +650,10 @@ int __intel_peek_fd(ScrnInfoPtr scrn) > > dev = intel_device(scrn); > > assert(dev && dev->fd != -1); > > Doesn't Klocwork recognise the assert() above? > I thought that would tell it that dev can't be NULL. My guess is that klockwork recognises that assert() can be a no-op if NDEBUG is defined and in such case won't generate code. In such a case neither of those two checks are performed. Kind regards, David ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] device: prevent a NULL pointer dereference in __intel_peek_fd
On 15/02/16 13:40, Martin Peres wrote: On 15/02/16 14:24, Dave Gordon wrote: On 12/02/16 16:31, Martin Peres wrote: This is not a big issue to return -1 since the only codepath that uses it is for display purposes. Caught by Klockwork. Signed-off-by: Martin Peres --- src/intel_device.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/intel_device.c b/src/intel_device.c index 54c1443..35e652a 100644 --- a/src/intel_device.c +++ b/src/intel_device.c @@ -650,7 +650,10 @@ int __intel_peek_fd(ScrnInfoPtr scrn) dev = intel_device(scrn); assert(dev && dev->fd != -1); Doesn't Klocwork recognise the assert() above? I thought that would tell it that dev can't be NULL. It does not, I had to close many false positives related to this... Hmmm .. elsewhere (e.g. [4/7]) you have /added/ an assert, which I thought must be so that Klocwork stops complaining that something might be NULL ... maybe it can't handle the composite assertion? Does it silence the complaint if you change: assert(dev && dev->fd != -1); into: assert(dev); assert(dev->fd != -1); ? .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Capture more useful details in error state (rev2)
== Summary == Series 2906v2 Capture more useful details in error state http://patchwork.freedesktop.org/api/1.0/series/2906/revisions/2/mbox/ Test gem_sync: Subgroup basic-bsd: pass -> DMESG-FAIL (hsw-brixbox) Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (skl-i5k-2) Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (skl-i5k-2) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (bsw-nuc-2) fail -> PASS (bdw-nuci7) pass -> DMESG-WARN (byt-nuc) Subgroup basic-rte: dmesg-warn -> PASS (bsw-nuc-2) bdw-nuci7total:162 pass:152 dwarn:0 dfail:0 fail:0 skip:10 bdw-ultratotal:165 pass:152 dwarn:0 dfail:0 fail:0 skip:13 bsw-nuc-2total:165 pass:134 dwarn:2 dfail:0 fail:0 skip:29 byt-nuc total:165 pass:140 dwarn:1 dfail:0 fail:0 skip:24 hsw-brixbox total:165 pass:150 dwarn:0 dfail:1 fail:0 skip:14 hsw-gt2 total:165 pass:154 dwarn:0 dfail:0 fail:1 skip:10 ilk-hp8440p total:165 pass:115 dwarn:1 dfail:0 fail:1 skip:48 ivb-t430stotal:165 pass:150 dwarn:0 dfail:0 fail:1 skip:14 skl-i5k-2total:165 pass:149 dwarn:1 dfail:0 fail:0 skip:15 snb-dellxps total:165 pass:142 dwarn:0 dfail:0 fail:1 skip:22 Results at /archive/results/CI_IGT_test/Patchwork_1390/ f2110d8eac120416f8f5669f2aa561d9ab330a77 drm-intel-nightly: 2016y-02m-15d-09h-53m-04s UTC integration manifest 10ba39cb2b21edfb52e3a6a908765027ae335515 drm/i915/error: Capture WA ctx batch in error state f81f205a6e31efb4cb8b23884959e0387358 drm/i915/error: add GuC state error capture & decode 8c03e0b8a6665e0300574a83ade7a010cb1d2a17 drm/i915/guc: Improve action error reporting 83b9556d95e0ad3a00be792e1301e8b9279051dd drm/i915/error: enhanced error capture of requests 5bea04449494651ed718a6b6c46dbe7d5bd7514b drm/i915/error: capture errored context based on request context-id 9a7ae94eca4f9bb8ed9398efb771cf763999dfdf drm/i915/error: improve CSB reporting 103fb92fc496252de85d0687399bfc62c6989aa0 drm/i915/error: report ctx id & desc for each request in the queue ba175d618bbd5266ff567b9c2cebcf60dd794195 drm/i915/error: capture ringbuffer pointed to by START 1a021f92fd3065dd2e8dffa52e6d2951d542b414 drm/i915/error: capture execlist state on error ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/12] drm/i915/ibx: ensure the HW is powered during PLL HW readout
Imre Deak writes:
> The assumption when adding the intel_display_power_is_enabled() checks
> was that if it returns success the power can't be turned off afterwards
> during the HW access, which is guaranteed by modeset locks. This isn't
> always true, so make sure we hold a dedicated reference for the time of
> the access.
>
> Signed-off-by: Imre Deak
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/intel_display.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 6abfc54..fe249ff 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13699,7 +13699,7 @@ static bool ibx_pch_dpll_get_hw_state(struct
> drm_i915_private *dev_priv,
> {
> uint32_t val;
>
> - if (!intel_display_power_is_enabled(dev_priv, POWER_DOMAIN_PLLS))
> + if (!intel_display_power_get_if_enabled(dev_priv, POWER_DOMAIN_PLLS))
> return false;
>
> val = I915_READ(PCH_DPLL(pll->id));
> @@ -13707,6 +13707,8 @@ static bool ibx_pch_dpll_get_hw_state(struct
> drm_i915_private *dev_priv,
> hw_state->fp0 = I915_READ(PCH_FP0(pll->id));
> hw_state->fp1 = I915_READ(PCH_FP1(pll->id));
>
> + intel_display_power_put(dev_priv, POWER_DOMAIN_PLLS);
> +
> return val & DPLL_VCO_ENABLE;
> }
>
> --
> 2.5.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Fix hpd live status bits for g4x
== Summary == Series 3243v1 drm/i915: Fix hpd live status bits for g4x http://patchwork.freedesktop.org/api/1.0/series/3243/revisions/1/mbox/ Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) UNSTABLE Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (skl-i5k-2) Subgroup suspend-read-crc-pipe-c: pass -> DMESG-WARN (skl-i5k-2) dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (bsw-nuc-2) fail -> PASS (bdw-nuci7) pass -> DMESG-WARN (byt-nuc) Subgroup basic-rte: dmesg-warn -> PASS (bsw-nuc-2) bdw-nuci7total:162 pass:152 dwarn:0 dfail:0 fail:0 skip:10 bdw-ultratotal:165 pass:152 dwarn:0 dfail:0 fail:0 skip:13 bsw-nuc-2total:165 pass:135 dwarn:1 dfail:0 fail:0 skip:29 byt-nuc total:165 pass:140 dwarn:1 dfail:0 fail:0 skip:24 hsw-brixbox total:165 pass:151 dwarn:0 dfail:0 fail:0 skip:14 hsw-gt2 total:165 pass:154 dwarn:0 dfail:0 fail:1 skip:10 ilk-hp8440p total:165 pass:115 dwarn:1 dfail:0 fail:1 skip:48 ivb-t430stotal:165 pass:150 dwarn:0 dfail:0 fail:1 skip:14 skl-i5k-2total:165 pass:149 dwarn:1 dfail:0 fail:0 skip:15 snb-dellxps total:165 pass:142 dwarn:0 dfail:0 fail:1 skip:22 snb-x220ttotal:165 pass:142 dwarn:0 dfail:0 fail:2 skip:21 Results at /archive/results/CI_IGT_test/Patchwork_1391/ f2110d8eac120416f8f5669f2aa561d9ab330a77 drm-intel-nightly: 2016y-02m-15d-09h-53m-04s UTC integration manifest 618b5aeb2c5b496b1ed112b47529cc8ddad2f862 drm/i915: Fix hpd live status bits for g4x ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] device: prevent a NULL pointer dereference in __intel_peek_fd
On 15/02/16 13:43, David Weinehall wrote:
On Mon, Feb 15, 2016 at 12:24:04PM +, Dave Gordon wrote:
On 12/02/16 16:31, Martin Peres wrote:
This is not a big issue to return -1 since the only codepath that uses
it is for display purposes.
Caught by Klockwork.
Signed-off-by: Martin Peres
---
src/intel_device.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/src/intel_device.c b/src/intel_device.c
index 54c1443..35e652a 100644
--- a/src/intel_device.c
+++ b/src/intel_device.c
@@ -650,7 +650,10 @@ int __intel_peek_fd(ScrnInfoPtr scrn)
dev = intel_device(scrn);
assert(dev && dev->fd != -1);
Doesn't Klocwork recognise the assert() above?
I thought that would tell it that dev can't be NULL.
My guess is that klockwork recognises that assert() can be a no-op
if NDEBUG is defined and in such case won't generate code.
In such a case neither of those two checks are performed.
Kind regards, David
Klocwork is a static analysis tool, it doesn't generate code at all.
It's supposed to recognise assert() and similar macros as constraints on
what values particular expressions may have; in particular, it knows
that if a code path ends with a call to abort(), that path *should*
never be taken and it will assume (for static analysis purposes) that it
*will* not be taken. Thus any combination of values that leads to an
abort() is considered "impossible" and need not be further checked. Then
assert() is typically defined as:
#define assert(x) do { if(!(x)) abort(); } while (0)
and then
int foo(char *s)
{
assert(s);
return *s;
}
should not cause Klocwork to complain, whereas without the assert() it
should say that 's' might be NULL when dereferenced. If it's getting
false positives it may be that Klocwork hasn't been told the proper
(conditional) definition for assert()?
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting
On Mon, Feb 15, 2016 at 02:36:43PM +0200, Joonas Lahtinen wrote: > Instead of implementing a custom locked reference counting, use lockref. > > Current implementation leads to a deadlock splat on Intel SKL platforms > when lockdep debugging is enabled. > > This is due to few of CPUfreq drivers (including Intel P-state) having this; > policy->rwsem is locked during driver initialization and the functions called > during init that actually apply CPU limits use get_online_cpus (because they > have other calling paths too), which will briefly lock cpu_hotplug.lock to > increase cpu_hotplug.refcount. > > On later calling path, when doing a suspend, when cpu_hotplug_begin() is > called > in disable_nonboot_cpus(), callbacks to CPUfreq functions get called after, > which will lock policy->rwsem and cpu_hotplug.lock is already held by > cpu_hotplug_begin() and we do have a potential deadlock scenario reported by > our CI system (though it is a very unlikely one). See the Bugzilla link for > more > details. I've been meaning to change the thing into a percpu-rwsem, I just haven't had time to look into the lockdep splat that generated. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 01/12] drm/i915: add helper to get a display power ref if it was already enabled
We have many places in the code where we check if a given display power
domain is enabled and if so access registers backed by this power
domain. We assumed that some modeset lock will prevent the power
reference from vanishing in the middle of the HW access, but this
assumption doesn't always hold. In such cases we get either the wakeref
not held, or an unclaimed register access error message. To fix this in
a future-proof way that's independent of other locks wrap any such
access with a get_ref_if_enabled()/put_ref() pair.
Kudos to Ville and Joonas for the ideas of this new interface.
v2:
- init the power_domains ptr when declaring it everywhere (Joonas)
CC: Mika Kuoppala
CC: Chris Wilson
CC: Joonas Lahtinen
CC: Ville Syrjälä
Signed-off-by: Imre Deak
Reviewed-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/intel_drv.h| 3 +
drivers/gpu/drm/i915/intel_runtime_pm.c | 111 ++--
2 files changed, 93 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 3cae376..f95f8b2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1436,6 +1436,8 @@ bool __intel_display_power_is_enabled(struct
drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
void intel_display_power_get(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
+bool intel_display_power_get_if_enabled(struct drm_i915_private *dev_priv,
+ enum intel_display_power_domain domain);
void intel_display_power_put(struct drm_i915_private *dev_priv,
enum intel_display_power_domain domain);
@@ -1522,6 +1524,7 @@ enable_rpm_wakeref_asserts(struct drm_i915_private
*dev_priv)
enable_rpm_wakeref_asserts(dev_priv)
void intel_runtime_pm_get(struct drm_i915_private *dev_priv);
+bool intel_runtime_pm_get_if_in_use(struct drm_i915_private *dev_priv);
void intel_runtime_pm_get_noresume(struct drm_i915_private *dev_priv);
void intel_runtime_pm_put(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index bbca527..0e476f7 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -1435,39 +1435,84 @@ static void chv_pipe_power_well_disable(struct
drm_i915_private *dev_priv,
chv_set_pipe_power_well(dev_priv, power_well, false);
}
-/**
- * intel_display_power_get - grab a power domain reference
- * @dev_priv: i915 device instance
- * @domain: power domain to reference
- *
- * This function grabs a power domain reference for @domain and ensures that
the
- * power domain and all its parents are powered up. Therefore users should only
- * grab a reference to the innermost power domain they need.
- *
- * Any power domain reference obtained by this function must have a symmetric
- * call to intel_display_power_put() to release the reference again.
- */
-void intel_display_power_get(struct drm_i915_private *dev_priv,
-enum intel_display_power_domain domain)
+static void
+__intel_display_power_get_domain(struct drm_i915_private *dev_priv,
+enum intel_display_power_domain domain)
{
- struct i915_power_domains *power_domains;
+ struct i915_power_domains *power_domains = &dev_priv->power_domains;
struct i915_power_well *power_well;
int i;
- intel_runtime_pm_get(dev_priv);
-
- power_domains = &dev_priv->power_domains;
-
- mutex_lock(&power_domains->lock);
-
for_each_power_well(i, power_well, BIT(domain), power_domains) {
if (!power_well->count++)
intel_power_well_enable(dev_priv, power_well);
}
power_domains->domain_use_count[domain]++;
+}
+
+/**
+ * intel_display_power_get - grab a power domain reference
+ * @dev_priv: i915 device instance
+ * @domain: power domain to reference
+ *
+ * This function grabs a power domain reference for @domain and ensures that
the
+ * power domain and all its parents are powered up. Therefore users should only
+ * grab a reference to the innermost power domain they need.
+ *
+ * Any power domain reference obtained by this function must have a symmetric
+ * call to intel_display_power_put() to release the reference again.
+ */
+void intel_display_power_get(struct drm_i915_private *dev_priv,
+enum intel_display_power_domain domain)
+{
+ struct i915_power_domains *power_domains = &dev_priv->power_domains;
+
+ intel_runtime_pm_get(dev_priv);
+
+ mutex_lock(&power_domains->lock);
+
+ __intel_display_power_get_domain(dev_priv, domain);
+
+ mutex_unlock(&power_domains->lock);
+}
+
+/**
+ * intel_display_power_get_if_enabled - grab a reference for an enabled
display p
[Intel-gfx] ✗ Fi.CI.BAT: failure for CRTC background color support for i915
== Summary == Series 3265v1 CRTC background color support for i915 http://patchwork.freedesktop.org/api/1.0/series/3265/revisions/1/mbox/ Test gem_sync: Subgroup basic-default: pass -> DMESG-FAIL (hsw-brixbox) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) pass -> INCOMPLETE (hsw-gt2) Test pm_rpm: Subgroup basic-pci-d3-state: fail -> PASS (bdw-nuci7) Subgroup basic-rte: dmesg-warn -> PASS (bsw-nuc-2) pass -> DMESG-WARN (byt-nuc) UNSTABLE bdw-nuci7total:162 pass:152 dwarn:0 dfail:0 fail:0 skip:10 bdw-ultratotal:165 pass:152 dwarn:0 dfail:0 fail:0 skip:13 bsw-nuc-2total:165 pass:136 dwarn:0 dfail:0 fail:0 skip:29 byt-nuc total:165 pass:140 dwarn:1 dfail:0 fail:0 skip:24 hsw-brixbox total:165 pass:150 dwarn:0 dfail:1 fail:0 skip:14 hsw-gt2 total:86 pass:80 dwarn:0 dfail:0 fail:1 skip:4 ilk-hp8440p total:165 pass:116 dwarn:0 dfail:0 fail:1 skip:48 ivb-t430stotal:165 pass:150 dwarn:0 dfail:0 fail:1 skip:14 snb-dellxps total:165 pass:142 dwarn:0 dfail:0 fail:1 skip:22 snb-x220ttotal:165 pass:142 dwarn:0 dfail:0 fail:2 skip:21 Results at /archive/results/CI_IGT_test/Patchwork_1392/ f2110d8eac120416f8f5669f2aa561d9ab330a77 drm-intel-nightly: 2016y-02m-15d-09h-53m-04s UTC integration manifest 02ba7fa3e68b07163a900e9fd2609874a6ac425b drm/i915/gen9: Add support for pipe background color (v2) 1db340510effedb03d3174211f288ba0f77a78c5 drm: Add infrastructure for CRTC background color property (v2) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: Allow for holes in connector state.
Hi Maarten, [auto build test WARNING on drm/drm-next] [also build test WARNING on v4.5-rc4 next-20160215] [if your patch is applied to the wrong git tree, please drop us a note to help improving the system] url: https://github.com/0day-ci/linux/commits/Maarten-Lankhorst/drm-atomic-Allow-for-holes-in-connector-state/20160215-212056 base: git://people.freedesktop.org/~airlied/linux.git drm-next reproduce: make htmldocs All warnings (new ones prefixed by >>): drivers/gpu/drm/i915/i915_irq.c:2659: warning: No description found for parameter 'wedged' drivers/gpu/drm/i915/i915_irq.c:2659: warning: No description found for parameter 'fmt' include/drm/drm_crtc.h:359: warning: No description found for parameter 'mode_blob' include/drm/drm_crtc.h:774: warning: No description found for parameter 'name' >> include/drm/drm_crtc.h:1233: warning: No description found for parameter >> 'connector_id' include/drm/drm_crtc.h:1233: warning: No description found for parameter 'tile_blob_ptr' include/drm/drm_crtc.h:1272: warning: No description found for parameter 'rotation' include/drm/drm_crtc.h:1534: warning: No description found for parameter 'name' include/drm/drm_crtc.h:1534: warning: No description found for parameter 'mutex' include/drm/drm_crtc.h:1534: warning: No description found for parameter 'helper_private' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'tile_idr' >> include/drm/drm_crtc.h:2144: warning: No description found for parameter >> 'connector_ida' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'delayed_event' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'edid_property' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'dpms_property' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'path_property' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'tile_property' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'plane_type_property' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'rotation_property' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'prop_src_x' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'prop_src_y' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'prop_src_w' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'prop_src_h' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'prop_crtc_x' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'prop_crtc_y' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'prop_crtc_w' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'prop_crtc_h' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'prop_fb_id' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'prop_crtc_id' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'prop_active' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'prop_mode_id' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'dvi_i_subconnector_property' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'dvi_i_select_subconnector_property' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'tv_subconnector_property' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'tv_select_subconnector_property' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'tv_mode_property' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'tv_left_margin_property' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'tv_right_margin_property' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'tv_top_margin_property' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'tv_bottom_margin_property' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'tv_brightness_property' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'tv_contrast_property' include/drm/drm_crtc.h:2144: warning: No description found for parameter 'tv_flicker_re
Re: [Intel-gfx] [PATCH v4 6/8] drm/i915: Nuke fbc members from intel_crtc->atomic, v2.
Op 12-02-16 om 14:56 schreef Zanoni, Paulo R:
> Em Qua, 2016-02-10 às 13:49 +0100, Maarten Lankhorst escreveu:
>> Factor out intel_fbc_supports_rotation
> ^ not anymore
>
>
>> and use it in
>> pre_plane_update as well. This leaves intel_crtc->atomic
>> empty, so remove it too.
>>
>> Changes since v1:
>> - Add a intel_fbc_supports_rotation helper.
> Changes since v2:
> - No more need for rotation special-casing.
>
> (I suppose you also have to edit the commit title to be v3)
>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/intel_display.c | 58 +-
>> --
>> drivers/gpu/drm/i915/intel_drv.h | 15 --
>> 2 files changed, 20 insertions(+), 53 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 54be8a255f1f..00cb261c6787 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -4782,11 +4782,9 @@ static void intel_post_plane_update(struct
>> intel_crtc_state *old_crtc_state)
>> {
>> struct intel_crtc *crtc = to_intel_crtc(old_crtc_state-
>>> base.crtc);
>> struct drm_atomic_state *old_state = old_crtc_state-
>>> base.state;
>> -struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
>> struct intel_crtc_state *pipe_config =
>> to_intel_crtc_state(crtc->base.state);
>> struct drm_device *dev = crtc->base.dev;
>> -struct drm_i915_private *dev_priv = dev->dev_private;
>> struct drm_plane *primary = crtc->base.primary;
>> struct drm_plane_state *old_pri_state =
>> drm_atomic_get_existing_plane_state(old_state,
>> primary);
>> @@ -4798,22 +4796,19 @@ static void intel_post_plane_update(struct
>> intel_crtc_state *old_crtc_state)
>> if (pipe_config->wm_changed && pipe_config->base.active)
>> intel_update_watermarks(&crtc->base);
>>
>> -if (atomic->update_fbc)
>> -intel_fbc_post_update(crtc);
>> -
>> if (old_pri_state) {
> For a code reader that is not very familiar with all the atomic history
> and its details, it's not trivial to conclude that "if
> (drm_atomic_get_existing_plane_state(primary))", then we're updating
> the primary plane on this atomic commit. And before this patch, it's
> much much easier to conclude that update_fbc will be true when an
> atomic update is touching the primary plane because that's explicitly
> stated by the cod.
>
> So although "let's kill this redundant struct" sounds good, it seems to
> me that code clarity is going away with this patch, so I wonder if the
> benefits of the patch outweigh the downsides. Isn't there something
> else we could do about this, such as some renaming, or adding some
> function aliases or just extra commenting?
>
>> struct intel_plane_state *primary_state =
>> to_intel_plane_state(primary->state);
>> struct intel_plane_state *old_primary_state =
>> to_intel_plane_state(old_pri_state);
>>
>> +intel_fbc_post_update(crtc);
>> +
>> if (primary_state->visible &&
>> (needs_modeset(&pipe_config->base) ||
>> !old_primary_state->visible))
>> intel_post_enable_primary(&crtc->base);
>> }
>> -
>> -memset(atomic, 0, sizeof(*atomic));
>> }
>>
>> static void intel_pre_plane_update(struct intel_crtc_state
>> *old_crtc_state)
>> @@ -4821,7 +4816,6 @@ static void intel_pre_plane_update(struct
>> intel_crtc_state *old_crtc_state)
>> struct intel_crtc *crtc = to_intel_crtc(old_crtc_state-
>>> base.crtc);
>> struct drm_device *dev = crtc->base.dev;
>> struct drm_i915_private *dev_priv = dev->dev_private;
>> -struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
>> struct intel_crtc_state *pipe_config =
>> to_intel_crtc_state(crtc->base.state);
>> struct drm_atomic_state *old_state = old_crtc_state-
>>> base.state;
>> @@ -4830,17 +4824,17 @@ static void intel_pre_plane_update(struct
>> intel_crtc_state *old_crtc_state)
>> drm_atomic_get_existing_plane_state(old_state,
>> primary);
>> bool modeset = needs_modeset(&pipe_config->base);
>>
>> -if (atomic->update_fbc)
>> -intel_fbc_pre_update(crtc);
>> -
>> if (old_pri_state) {
>> struct intel_plane_state *primary_state =
>> to_intel_plane_state(primary->state);
>> struct intel_plane_state *old_primary_state =
>> to_intel_plane_state(old_pri_state);
>> +bool turn_off = old_primary_state->visible &&
>> +(modeset || !primary_state->visible);
> Not really related to the patch, but ok to keep since it's trivial...
>
>> +
>> +intel_fbc_pre_update(crtc);
>>
>> -if (old_primary_state->visible &&
>> -(modeset || !primary_state->visible))
>> +if (turn_off)
>>
[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/gen9: Check for DC state mismatch
== Summary == Series 3276v1 drm/i915/gen9: Check for DC state mismatch http://patchwork.freedesktop.org/api/1.0/series/3276/revisions/1/mbox/ Test drv_module_reload_basic: pass -> DMESG-WARN (ilk-hp8440p) Test gem_mmap_gtt: Subgroup basic-small-copy: pass -> DMESG-WARN (ilk-hp8440p) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (skl-i5k-2) Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (skl-i5k-2) Subgroup suspend-read-crc-pipe-c: pass -> SKIP (hsw-gt2) Test pm_rpm: Subgroup basic-pci-d3-state: fail -> PASS (bdw-nuci7) bdw-nuci7total:162 pass:152 dwarn:0 dfail:0 fail:0 skip:10 bdw-ultratotal:165 pass:152 dwarn:0 dfail:0 fail:0 skip:13 bsw-nuc-2total:165 pass:134 dwarn:2 dfail:0 fail:0 skip:29 byt-nuc total:165 pass:141 dwarn:0 dfail:0 fail:0 skip:24 hsw-brixbox total:165 pass:151 dwarn:0 dfail:0 fail:0 skip:14 hsw-gt2 total:165 pass:153 dwarn:0 dfail:0 fail:1 skip:11 ilk-hp8440p total:165 pass:114 dwarn:2 dfail:0 fail:1 skip:48 ivb-t430stotal:165 pass:150 dwarn:0 dfail:0 fail:1 skip:14 skl-i5k-2total:165 pass:149 dwarn:1 dfail:0 fail:0 skip:15 snb-dellxps total:165 pass:142 dwarn:0 dfail:0 fail:1 skip:22 snb-x220ttotal:165 pass:142 dwarn:0 dfail:0 fail:2 skip:21 Results at /archive/results/CI_IGT_test/Patchwork_1393/ f2110d8eac120416f8f5669f2aa561d9ab330a77 drm-intel-nightly: 2016y-02m-15d-09h-53m-04s UTC integration manifest 6bbe421b1a4cf2afe5519bf2ad297436c04144f0 drm/i915/gen9: Check for DC state mismatch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Simplify code by keeping kmap of guc_client object
On 12/02/16 13:03, Tvrtko Ursulin wrote: On 11/02/16 23:09, yu@intel.com wrote: From: Alex Dai GuC client object is always pinned during its life cycle. We cache the kmap of its first page, which includes guc_process_desc and doorbell. By doing so, we can simplify the code where we read from this page to get where GuC is progressing on work queue; and the code where driver program doorbell to send work queue item to GuC. [snip] -/* Finally, update the cached copy of the GuC's WQ head */ -gc->wq_head = desc->head; Did you mean to remove the above? I wondered that too at first, but the answer is "yes" -- see below. +client->client_base = kmap(i915_gem_object_get_dirty_page(obj, 0)); Was this another bug, that the page/object wasn't dirtied before? It wouldn't have made any difference; the object is pinned in the GTT forever, so it can't be swapped out or reclaimed. -uint32_t wq_head; Hm ok I don't get why kmap caching means removing this as well? 'wq_head' was an optimisation so that we could check whether there was known to be space in the workqueue without kmapping and reading the process descriptor. Now that the client (which includes the process descriptor) is permanently mapped, there's no advantage to caching the head; we might just as well read the current value from 'desc->head' each time. Btw I don't see patch 2/2 ? Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4
On Mon, Feb 15, 2016 at 10:55:33AM +0200, Oleksandr Natalenko wrote:
> 13.02.2016 01:23, Ville Syrjälä wrote:
> > - Do you have another monitor to try?
> > - Do you have another cable to try?
>
> More on this.
>
> Computer DVI —— old DVI-HDMI cable —— old monitor HDMI == not working
> Computer DVI —— another DVI-HDMI cable —— old monitor HDMI == not
> working
> Computer DVI —— DVI-DVI cable —— another monitor DVI == works
>
> So
>
> > Shouldn't really matter. HDMI and DVI are identical at this level.
>
> Not quite, as far as I can see.
Well, it seems this particular monitor is just somehow funky. It's a bit
strange that the hpd interrupt still works. It would seem to indicate
that there's two separate voltage thresholds for detection, one for the
hpd generation, and another for the live status. I did see something
similar on another platforms (CHV) where it had two different hpd
detection registers, and those produced different results when the
pullup on the hpd pin was misconfigured.
Anyway, I'm out of ideas now :( Anyone else got something up their
sleeve?
I'm starting to think this is going to be our only option:
- if (intel_hdmi_set_edid(connector, live_status)) {
+ if (intel_hdmi_set_edid(connector, true)) {
It would more or less turn the live status check into a fixed
msleep(80) for the disconnect case. For the connect case it would
still break out sooner when live status works.
The downside is that if the cable is yanked slowly, we'll still succeed
in the ddc communication during unplug and thus fail to notice that the
monitor was actually disconnected. But the delay should make that less
likely.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for Assorted reviewed patches for CI run
== Summary == Series 3277v1 Assorted reviewed patches for CI run http://patchwork.freedesktop.org/api/1.0/series/3277/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (skl-i5k-2) Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (skl-i5k-2) Test pm_rpm: Subgroup basic-pci-d3-state: fail -> PASS (bdw-nuci7) Subgroup basic-rte: pass -> DMESG-WARN (byt-nuc) UNSTABLE bdw-nuci7total:162 pass:152 dwarn:0 dfail:0 fail:0 skip:10 bdw-ultratotal:165 pass:152 dwarn:0 dfail:0 fail:0 skip:13 bsw-nuc-2total:165 pass:134 dwarn:2 dfail:0 fail:0 skip:29 byt-nuc total:165 pass:140 dwarn:1 dfail:0 fail:0 skip:24 hsw-brixbox total:165 pass:151 dwarn:0 dfail:0 fail:0 skip:14 hsw-gt2 total:165 pass:154 dwarn:0 dfail:0 fail:1 skip:10 ilk-hp8440p total:165 pass:116 dwarn:0 dfail:0 fail:1 skip:48 ivb-t430stotal:165 pass:150 dwarn:0 dfail:0 fail:1 skip:14 skl-i5k-2total:165 pass:149 dwarn:1 dfail:0 fail:0 skip:15 snb-dellxps total:165 pass:142 dwarn:0 dfail:0 fail:1 skip:22 snb-x220ttotal:165 pass:142 dwarn:0 dfail:0 fail:2 skip:21 Results at /archive/results/CI_IGT_test/Patchwork_1394/ f2110d8eac120416f8f5669f2aa561d9ab330a77 drm-intel-nightly: 2016y-02m-15d-09h-53m-04s UTC integration manifest b569392e655ae61e36db9c2855e3c5444e80f681 drm/i915/ilk: Move register read under spinlock 5ebea17ad6e3ead0efef6ad4e6dcdddc16209c9d drm/i915/guc: Do not wait for firmware load atomically 8bfc1509b39863c3cbb5755d065e241d27d96c9d drm/i915: Fix struct mutex vs. RPS lock inversion 9daa18b7c90411745d5e3783a595080fed6d7ef7 drm/i915: GEM operations need to be done under the big lock 7725bdeaf3de05cb3db4cd04198aaabb594054ca drm/i915: Use appropriate spinlock flavour ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Set init value for cached work queue head
On 10/02/16 20:31, Yu Dai wrote: On 02/10/2016 09:30 AM, Tvrtko Ursulin wrote: Hi, On 10/02/16 00:05, yu@intel.com wrote: > From: Alex Dai > > The cached work queue header pointer is set to last byte of work > queue buffer. It will make sure the whole work queue buffer is > available after coming back from reset or init. [snip] > @@ -730,6 +728,8 @@ static struct i915_guc_client *guc_client_alloc(struct drm_device *dev, > client->client_obj = obj; > client->wq_offset = GUC_DB_SIZE; > client->wq_size = GUC_WQ_SIZE; > +client->wq_head = GUC_WQ_SIZE - 1; > +client->wq_tail = 0; > > client->doorbell_offset = select_doorbell_cacheline(guc); This one I can't really figure out without I suppose knowing more about the code design. How come it was OK when it was zero (apart after reset)? The value is otherwise only updated from the GuC shared page and a driver does not appear to modify it. Perhaps just a better commit message to explain things? The way this kernel CIRC_xx works is it leaves one byte free and treat head == tail case as empty. So, there won't be a problem if this head happens to be 0. If it comes with some random number between [1, sizeof(WQ item)], there will be a SW dead looping in driver. Actually, I think it works like this: if both wq_tail and wq_head (which is a CACHE of the GuC's WQ tail) are initialised to 0, the driver thinks the WQ is empty, which is correct at startup but not necessarily after a GPU reset. By initialising them as above, the driver will at first think the WQ is FULL, and will then refresh the actual value from the GuC's process descriptor. This should ensure that it doesn't assume more WQ space than the GuC thinks there is. It's very much the same sort of issue as (re)initialising the CSB pointers after a reset, because the CS h/w (or in this case the GuC firmware) has internally set them to a new value and the driver needs to get in sync. Anyway all of this is superseded by Alex's later patch that leaves the client permanently kmapped, 'cos that gets rid of wq_head entirely :) .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Keep the previous context pinned until the next one has been completed
== Summary == Series 3278v1 drm/i915/guc: Keep the previous context pinned until the next one has been completed http://patchwork.freedesktop.org/api/1.0/series/3278/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> INCOMPLETE (hsw-gt2) Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (skl-i5k-2) Subgroup suspend-read-crc-pipe-c: pass -> DMESG-WARN (skl-i5k-2) dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: fail -> PASS (bdw-nuci7) pass -> DMESG-WARN (byt-nuc) bdw-nuci7total:162 pass:152 dwarn:0 dfail:0 fail:0 skip:10 bdw-ultratotal:165 pass:152 dwarn:0 dfail:0 fail:0 skip:13 bsw-nuc-2total:165 pass:135 dwarn:1 dfail:0 fail:0 skip:29 byt-nuc total:165 pass:140 dwarn:1 dfail:0 fail:0 skip:24 hsw-brixbox total:165 pass:151 dwarn:0 dfail:0 fail:0 skip:14 hsw-gt2 total:43 pass:38 dwarn:0 dfail:0 fail:0 skip:4 ilk-hp8440p total:165 pass:116 dwarn:0 dfail:0 fail:1 skip:48 ivb-t430stotal:165 pass:150 dwarn:0 dfail:0 fail:1 skip:14 skl-i5k-2total:165 pass:149 dwarn:1 dfail:0 fail:0 skip:15 snb-dellxps total:165 pass:142 dwarn:0 dfail:0 fail:1 skip:22 snb-x220ttotal:165 pass:142 dwarn:0 dfail:0 fail:2 skip:21 Results at /archive/results/CI_IGT_test/Patchwork_1395/ f2110d8eac120416f8f5669f2aa561d9ab330a77 drm-intel-nightly: 2016y-02m-15d-09h-53m-04s UTC integration manifest 5fb1d5339f588317a492cacdd66c182aeff051b7 drm/i915/guc: Keep the previous context pinned until the next one has been completed ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add missing 'else' to intel_digital_port_connected()
== Summary == Series 3292v1 drm/i915: Add missing 'else' to intel_digital_port_connected() http://patchwork.freedesktop.org/api/1.0/series/3292/revisions/1/mbox/ Test gem_mmap_gtt: Subgroup basic-small-copy-xy: pass -> DMESG-FAIL (ilk-hp8440p) Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-c: dmesg-warn -> PASS (bsw-nuc-2) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (bsw-nuc-2) fail -> PASS (bdw-nuci7) Subgroup basic-rte: dmesg-warn -> PASS (bsw-nuc-2) pass -> FAIL (bdw-ultra) bdw-nuci7total:162 pass:152 dwarn:0 dfail:0 fail:0 skip:10 bdw-ultratotal:165 pass:151 dwarn:0 dfail:0 fail:1 skip:13 bsw-nuc-2total:165 pass:135 dwarn:1 dfail:0 fail:0 skip:29 byt-nuc total:165 pass:141 dwarn:0 dfail:0 fail:0 skip:24 hsw-brixbox total:165 pass:151 dwarn:0 dfail:0 fail:0 skip:14 hsw-gt2 total:165 pass:154 dwarn:0 dfail:0 fail:1 skip:10 ilk-hp8440p total:165 pass:115 dwarn:0 dfail:1 fail:1 skip:48 ivb-t430stotal:165 pass:150 dwarn:0 dfail:0 fail:1 skip:14 skl-i5k-2total:165 pass:149 dwarn:1 dfail:0 fail:0 skip:15 snb-dellxps total:165 pass:142 dwarn:0 dfail:0 fail:1 skip:22 snb-x220ttotal:165 pass:142 dwarn:0 dfail:0 fail:2 skip:21 Results at /archive/results/CI_IGT_test/Patchwork_1396/ f2110d8eac120416f8f5669f2aa561d9ab330a77 drm-intel-nightly: 2016y-02m-15d-09h-53m-04s UTC integration manifest bb6fd4ba57d864494466a3bd498428f71db09492 drm/i915: Add missing 'else' to intel_digital_port_connected() ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/guc: Simplify code by keeping kmap of guc_client object
On 12/02/16 13:03, Tvrtko Ursulin wrote: On 11/02/16 23:09, yu@intel.com wrote: From: Alex Dai GuC client object is always pinned during its life cycle. We cache the kmap of its first page, which includes guc_process_desc and doorbell. By doing so, we can simplify the code where we read from this page to get where GuC is progressing on work queue; and the code where driver program doorbell to send work queue item to GuC. There's still one k(un)map_atomic() pair, in guc_add_workqueue_item(). Maybe we could get rid of that one too? So instead of kmapping only the first page of the client, we could vmap() all three pages and so not need to kmap_atomic() the WQ pages on the fly. There's a handy vmap_obj() function we might use, except it's currently static ... .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION] i915: No HDMI output with 4.4
On Mon, Feb 15, 2016 at 04:42:35PM +0200, Ville Syrjälä wrote:
> On Mon, Feb 15, 2016 at 10:55:33AM +0200, Oleksandr Natalenko wrote:
> > 13.02.2016 01:23, Ville Syrjälä wrote:
> > > - Do you have another monitor to try?
> > > - Do you have another cable to try?
> >
> > More on this.
> >
> > Computer DVI —— old DVI-HDMI cable —— old monitor HDMI == not working
> > Computer DVI —— another DVI-HDMI cable —— old monitor HDMI == not
> > working
> > Computer DVI —— DVI-DVI cable —— another monitor DVI == works
> >
> > So
> >
> > > Shouldn't really matter. HDMI and DVI are identical at this level.
> >
> > Not quite, as far as I can see.
>
> Well, it seems this particular monitor is just somehow funky. It's a bit
> strange that the hpd interrupt still works. It would seem to indicate
> that there's two separate voltage thresholds for detection, one for the
> hpd generation, and another for the live status. I did see something
> similar on another platforms (CHV) where it had two different hpd
> detection registers, and those produced different results when the
> pullup on the hpd pin was misconfigured.
>
> Anyway, I'm out of ideas now :( Anyone else got something up their
> sleeve?
>
> I'm starting to think this is going to be our only option:
> - if (intel_hdmi_set_edid(connector, live_status)) {
> + if (intel_hdmi_set_edid(connector, true)) {
>
> It would more or less turn the live status check into a fixed
> msleep(80) for the disconnect case. For the connect case it would
> still break out sooner when live status works.
>
> The downside is that if the cable is yanked slowly, we'll still succeed
> in the ddc communication during unplug and thus fail to notice that the
> monitor was actually disconnected. But the delay should make that less
> likely.
The other downside is that it'll make us non-compliant, which was the
point of this entire ordeal: HDMI spec forbids us from starting any i2c
transactions when the hpd isn't signalling a present screen.
So maybe we need to buy one of these broken screens.
Oleksandr, what exact model are you using? And any chance that you could
test this on some other machine with intel gfx and latest kernel, just to
make sure this really is some issue with the sink and not with the machine
itself? And I guess you've tested with some other hdmi sink, and that
works?
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/7] device: prevent a NULL pointer dereference in __intel_peek_fd
On 15/02/16 15:47, Dave Gordon wrote: On 15/02/16 13:40, Martin Peres wrote: On 15/02/16 14:24, Dave Gordon wrote: On 12/02/16 16:31, Martin Peres wrote: This is not a big issue to return -1 since the only codepath that uses it is for display purposes. Caught by Klockwork. Signed-off-by: Martin Peres --- src/intel_device.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/intel_device.c b/src/intel_device.c index 54c1443..35e652a 100644 --- a/src/intel_device.c +++ b/src/intel_device.c @@ -650,7 +650,10 @@ int __intel_peek_fd(ScrnInfoPtr scrn) dev = intel_device(scrn); assert(dev && dev->fd != -1); Doesn't Klocwork recognise the assert() above? I thought that would tell it that dev can't be NULL. It does not, I had to close many false positives related to this... Hmmm .. elsewhere (e.g. [4/7]) you have /added/ an assert, which I thought must be so that Klocwork stops complaining that something might be NULL ... maybe it can't handle the composite assertion? Does it silence the complaint if you change: assert(dev && dev->fd != -1); into: assert(dev); assert(dev->fd != -1); ? Sure, I added an assert, but not to silence patchwork, just to make sure we have no problem. I cannot run klokwork myself and my goal was not to silence but instead to check the reported issues. David is right, I think Klokwork only cares about runtime checks and wants to make sure that we never de-reference a NULL pointer. Martin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Discuss GVT context hacks in i915
Hi Daniel:
Thanks for shedding the light! See my comments below. :)
-Original Message-
From: Vetter, Daniel
Sent: Monday, February 15, 2016 5:32 PM
To: Wang, Zhi A; Joonas Lahtinen; Chris Wilson; Lv, Zhiyuan; Tian, Kevin
Subject: Re: Discuss GVT context hacks in i915
Am 15/02/2016 um 10:11 schrieb Zhi Wang:
> Hi Guys:
>Previously we have sent our GVT-g device model RFC code, and thanks
> for the advices and comments! As you see GVT-g needs a special kind of
> LRC context as shadow context so it could be able to use i915 GEM
> submission subsystem, which requires some changes in i915.
>
> Probably we can discuss them one by one and settle them down before
> the next version of RFC code. :)
>
> Difference between a i915 LRC context and a GVT LRC context
> --
>
> * The engine context initialization of a GVT LRC context can be
> bypassed, as GVT-g will initialize it by guest LRC context.
>
> http://www.spinics.net/lists/intel-gfx/msg86546.html
>
> * The addressing mode bit in the context descriptor should be able to
> configured at runtime, as some guest is still using 32bit PPGTT
> address space.
>
> http://www.spinics.net/lists/intel-gfx/msg86544.html
>
> * As the GVT LRC context will go with the shadow PPGTT page table
> populated by GVT-g, a GVT LRC context doesn't need a i915 PPGTT
> instance, also its PDP root pointer doesn't need to be populated by i915.
>
> http://www.spinics.net/lists/intel-gfx/msg86545.html
>
> * The ring buffer size of a GVT LRC context ring buffer object should
> be configurable or hard-coded to the max size, as some guest (e.g.
> windows) has a large ring buffer and could submit a lot of commands at
> one time.
>
> Hacking i915
> ---
>
> The above changes needs to hack i915, in the RFC code, you can see a
> lot of codes like below:
>
> if (!gvt_context) {
> /* do something i915 needed */
> } else {
> /* do something GVT-g needed */
> }
>
> This kinds of code piece is GVT-g specific, another approach should be
> refining some i915 APIs or say something generic, like:
>
> if (context->need_i915_ppgtt) {
> /* allocating i915 ppgtt instance */
> }
>
> if (context->ppgtt) {
> /* update PDP root pointers in LRC context. */
> }
>
> if (context->need_initialization) {
> /* emit commands to initialize the engine context of LRC context */
> }
>
> I'm wondering which kinds do you prefer? Or maybe you can give me some
> advices? :)
Without looking at more than what's in your mail here and in the links,
this style is the midlayer mistake: We have some abstraction (lrc
context, ppgtt) and force everyone to go through the same code paths.
Which means deep down in those paths we have lots of if (special_case)
conditions, which make the code a maintainance nightmare. Yes execlist
support has already a lot of such bad examples unfortunately.
The better design idea is to reuse the data structures and helper
functions, but have new top-level entry functions for creating e.g. a
xengt lrc context. So e.g. have a lrc init function for xengt which
takes the setup stuff as parameters. Wrt ppgtt my idea was to reuse
struct i915_hw_ppgtt for managing the shadow pagetable, with xengt using
the i915_gem_gtt.c functions to write shadow pagetable entries. That way
i915 still knows the virtual->physical mapping, which aids in e.g. crash
dump recording. Of course you're not going to bind entire vma, but
instead will use the lower-level functions that just bind pages.
[Zhi] Thanks! Just want to make sure that you prefer that GVT-g specific
modifications should be put into a fork of top-level i915 APIs? For example,
we prepare a new function to create the GVT context, which is a fork of
simplified i915_gem_create_context().
For i915_hw_ppgtt and GVT-g shadow page table, we tried to think about how
to merge these two similar things into one, but have some opens:
Most of the GTT/PPGTT page table entry routines in i915_gem_gtt.c, e.g. the
abstractions/ insert_entries() are aimed to generate the page table entry, but
GVT-g shadow page implementation also need the per-platform page table
entry bit field extraction routines. For example, extract the GFN from guest
page
table, which means we have to add some new callbacks which native i915
will not use at all. Is it OK for host i915 to add such kinds of callbacks?
b. GVT-g shadow page table implementation should be the most complicated
part in GVT-g, maybe the first easy step should be putting the shadow page
table root pointer into i915_hw_ppgtt. E.g. GVT-g allocates a fake i915_hw_ppgtt
only use it to store root pointer and addressing mode bit?
For ppgtt size selection I think we should have a field for that in
i915_hw_ppgtt, that the lrc setup code reads.
For the ringbuffer size you could just create a fake ringbuffer object I
think.
[Zhi] You mean we should add another ring buffer object allocation function?
In GVT
context we reuse the i915 ring buffer submission interface lik
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for Assorted reviewed patches for CI run
On 15/02/16 14:53, Patchwork wrote: == Summary == Series 3277v1 Assorted reviewed patches for CI run http://patchwork.freedesktop.org/api/1.0/series/3277/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (skl-i5k-2) Known unrelated: https://bugs.freedesktop.org/show_bug.cgi?id=93294 Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (skl-i5k-2) Test pm_rpm: Subgroup basic-pci-d3-state: fail -> PASS (bdw-nuci7) Subgroup basic-rte: pass -> DMESG-WARN (byt-nuc) UNSTABLE Known unrelated: https://bugs.freedesktop.org/show_bug.cgi?id=93121 bdw-nuci7total:162 pass:152 dwarn:0 dfail:0 fail:0 skip:10 bdw-ultratotal:165 pass:152 dwarn:0 dfail:0 fail:0 skip:13 bsw-nuc-2total:165 pass:134 dwarn:2 dfail:0 fail:0 skip:29 byt-nuc total:165 pass:140 dwarn:1 dfail:0 fail:0 skip:24 hsw-brixbox total:165 pass:151 dwarn:0 dfail:0 fail:0 skip:14 hsw-gt2 total:165 pass:154 dwarn:0 dfail:0 fail:1 skip:10 ilk-hp8440p total:165 pass:116 dwarn:0 dfail:0 fail:1 skip:48 ivb-t430stotal:165 pass:150 dwarn:0 dfail:0 fail:1 skip:14 skl-i5k-2total:165 pass:149 dwarn:1 dfail:0 fail:0 skip:15 snb-dellxps total:165 pass:142 dwarn:0 dfail:0 fail:1 skip:22 snb-x220ttotal:165 pass:142 dwarn:0 dfail:0 fail:2 skip:21 Results at /archive/results/CI_IGT_test/Patchwork_1394/ f2110d8eac120416f8f5669f2aa561d9ab330a77 drm-intel-nightly: 2016y-02m-15d-09h-53m-04s UTC integration manifest b569392e655ae61e36db9c2855e3c5444e80f681 drm/i915/ilk: Move register read under spinlock 5ebea17ad6e3ead0efef6ad4e6dcdddc16209c9d drm/i915/guc: Do not wait for firmware load atomically 8bfc1509b39863c3cbb5755d065e241d27d96c9d drm/i915: Fix struct mutex vs. RPS lock inversion 9daa18b7c90411745d5e3783a595080fed6d7ef7 drm/i915: GEM operations need to be done under the big lock 7725bdeaf3de05cb3db4cd04198aaabb594054ca drm/i915: Use appropriate spinlock flavour So will merge this bunch. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 07/12] drm/i915: GEM operations need to be done under the big lock
On Thu, Feb 11, 2016 at 10:13:30AM +, Chris Wilson wrote: > On Tue, Feb 02, 2016 at 02:46:19PM +, Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > > > VMA creation and GEM list management need the big lock. > > > > v2: > > > > Mutex unlock ended on the wrong path somehow. (0-day, Julia Lawall) > > > > Not to mention drm_gem_object_unreference was there in existing > > code with no mutex held. > > > > v3: > > > > Some callers of i915_gem_object_create_stolen_for_preallocated > > already hold the lock so move the mutex into the other caller > > as well. > > > > v4: > > > > Changed to lockdep_assert_held. (Chris Wilson) > > > > Signed-off-by: Tvrtko Ursulin > > Cc: Chris Wilson > > Also > Reviewed-by: Chris Wilson > :) > > Daniel, what did you think of having a config option to turn > lockdep_assert_held into WARN_ON(!mutex_is_locked()) when lockdep is not > fully-enabled? I like, and kinda would even go as far as making it the default. But that might upset some performance concious folks, so Kconfig seems fine. Cany you please submit that to a wider audience? Then we'd never have to have this discussion again ;-) Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/BXT: Configure DSI after enabling DSI pll
On Wed, Feb 03, 2016 at 02:59:11PM +0200, Mika Kahola wrote:
> On Wed, 2016-02-03 at 11:28 +0200, Jani Nikula wrote:
> > On Tue, 02 Feb 2016, Ramalingam C wrote:
> > > We need to enable DSI PLL before configuring the DSI registers.
> > >
> > > Signed-off-by: Ramalingam C
> > > ---
> > > drivers/gpu/drm/i915/intel_dsi.c |2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_dsi.c
> > > b/drivers/gpu/drm/i915/intel_dsi.c
> > > index 91cef35..378f879 100644
> > > --- a/drivers/gpu/drm/i915/intel_dsi.c
> > > +++ b/drivers/gpu/drm/i915/intel_dsi.c
> > > @@ -478,8 +478,8 @@ static void intel_dsi_pre_enable(struct intel_encoder
> > > *encoder)
> > >
> > > DRM_DEBUG_KMS("\n");
> > >
> > > - intel_dsi_prepare(encoder);
> > > intel_enable_dsi_pll(encoder);
> > > + intel_dsi_prepare(encoder);
> >
> > I'd really like to have this tested on BYT/CHV DSI to ensure we're not
> > breaking anything.
> >
> > BR,
> > Jani.
> >
> We have CI results for this. Should we be worried about CPU fifo
> underrun?
>
> http://benchsrv.fi.intel.com/archive/results/CI_IGT_test/Patchwork_1344/
Known issue on ilk: https://bugs.freedesktop.org/show_bug.cgi?id=93787
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/BXT: Fixed COS blanking issue
On Tue, Feb 02, 2016 at 11:24:16PM +0530, Ramalingam C wrote:
> From: Uma Shankar
>
> During Charging OS mode, mipi display was blanking.This is
> because during driver load, though encoder, connector were
> active but crtc returned inactive. This caused sanitize
> function to disable the DSI panel. In AOS, this is fine
> since HWC will do a modeset and crtc, connector, encoder
> mapping will be restored. But in COS, no modeset is called,
> it just calls DPMS ON/OFF.
>
> This is fine on BYT/CHT since transcoder is common b/w
> all encoders. But for BXT, there is a separate mipi
> transcoder. Hence this needs special handling for BXT.
>
> Signed-off-by: Uma Shankar
> Signed-off-by: Ramalingam C
> ---
> drivers/gpu/drm/i915/intel_display.c | 107
> --
> 1 file changed, 101 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index a66220a..f8685f5 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -7814,6 +7814,69 @@ static void intel_set_pipe_timings(struct intel_crtc
> *intel_crtc)
> (intel_crtc->config->pipe_src_h - 1));
> }
>
> +static void intel_get_dsi_pipe_timings(struct intel_crtc *crtc,
> +struct intel_crtc_state *pipe_config)
> +{
> + struct drm_device *dev = crtc->base.dev;
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
> + struct intel_encoder *encoder;
> + uint32_t tmp;
> +
> + tmp = I915_READ(HTOTAL(cpu_transcoder));
> + pipe_config->base.adjusted_mode.crtc_hdisplay = (tmp & 0x) + 1;
> + pipe_config->base.adjusted_mode.crtc_htotal =
> + ((tmp >> 16) & 0x) + 1;
> + tmp = I915_READ(HBLANK(cpu_transcoder));
> + pipe_config->base.adjusted_mode.crtc_hblank_start = (tmp & 0x) + 1;
> + pipe_config->base.adjusted_mode.crtc_hblank_end =
> + ((tmp >> 16) & 0x) + 1;
> + tmp = I915_READ(HSYNC(cpu_transcoder));
> + pipe_config->base.adjusted_mode.crtc_hsync_start = (tmp & 0x) + 1;
> + pipe_config->base.adjusted_mode.crtc_hsync_end =
> + ((tmp >> 16) & 0x) + 1;
> +
> + tmp = I915_READ(VBLANK(cpu_transcoder));
> + pipe_config->base.adjusted_mode.crtc_vblank_start = (tmp & 0x) + 1;
> + pipe_config->base.adjusted_mode.crtc_vblank_end =
> + ((tmp >> 16) & 0x) + 1;
> + tmp = I915_READ(VSYNC(cpu_transcoder));
> + pipe_config->base.adjusted_mode.crtc_vsync_start = (tmp & 0x) + 1;
> + pipe_config->base.adjusted_mode.crtc_vsync_end =
> + ((tmp >> 16) & 0x) + 1;
> +
> + if (I915_READ(PIPECONF(cpu_transcoder)) & PIPECONF_INTERLACE_MASK) {
> + pipe_config->base.adjusted_mode.flags |=
> + DRM_MODE_FLAG_INTERLACE;
> + pipe_config->base.adjusted_mode.crtc_vtotal += 1;
> + pipe_config->base.adjusted_mode.crtc_vblank_end += 1;
> + }
> +
> +
> + for_each_encoder_on_crtc(dev, &crtc->base, encoder) {
> + struct intel_dsi *intel_dsi =
> + enc_to_intel_dsi(&encoder->base);
> + enum port port;
> +
> + pipe_config->pipe_bpp = intel_dsi->dsi_bpp;
> + for_each_dsi_port(port, intel_dsi->ports) {
> + pipe_config->base.adjusted_mode.crtc_hdisplay =
> + I915_READ(BXT_MIPI_TRANS_HACTIVE(port));
> + pipe_config->base.adjusted_mode.crtc_vdisplay =
> + I915_READ(BXT_MIPI_TRANS_VACTIVE(port));
> + pipe_config->base.adjusted_mode.crtc_vtotal =
> + I915_READ(BXT_MIPI_TRANS_VTOTAL(port));
> + }
> + }
If some state is encoder specific (and a for_each_encoder_on_crtc highly
suggests that), then please read out such state from the
encoder->get_config hook.
-Daniel
> +
> + tmp = I915_READ(PIPESRC(crtc->pipe));
> + pipe_config->pipe_src_h = (tmp & 0x) + 1;
> + pipe_config->pipe_src_w = ((tmp >> 16) & 0x) + 1;
> +
> + pipe_config->base.mode.vdisplay = pipe_config->pipe_src_h;
> + pipe_config->base.mode.hdisplay = pipe_config->pipe_src_w;
> +}
> +
> static void intel_get_pipe_timings(struct intel_crtc *crtc,
> struct intel_crtc_state *pipe_config)
> {
> @@ -9969,6 +10032,7 @@ static bool haswell_get_pipe_config(struct intel_crtc
> *crtc,
> struct drm_i915_private *dev_priv = dev->dev_private;
> enum intel_display_power_domain pfit_domain;
> uint32_t tmp;
> + bool is_dsi = false;
>
> if (!intel_display_power_is_enabled(
Re: [Intel-gfx] [PATCH 1/2] drm/i915/BXT: Fixed COS blanking issue
On Wed, Feb 03, 2016 at 11:44:03AM +0200, Jani Nikula wrote:
> On Tue, 02 Feb 2016, Ramalingam C wrote:
> > From: Uma Shankar
> >
> > During Charging OS mode, mipi display was blanking.This is
> > because during driver load, though encoder, connector were
> > active but crtc returned inactive. This caused sanitize
> > function to disable the DSI panel. In AOS, this is fine
> > since HWC will do a modeset and crtc, connector, encoder
> > mapping will be restored. But in COS, no modeset is called,
> > it just calls DPMS ON/OFF.
> >
> > This is fine on BYT/CHT since transcoder is common b/w
> > all encoders. But for BXT, there is a separate mipi
> > transcoder. Hence this needs special handling for BXT.
> >
> > Signed-off-by: Uma Shankar
> > Signed-off-by: Ramalingam C
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 107
> > --
> > 1 file changed, 101 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index a66220a..f8685f5 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -7814,6 +7814,69 @@ static void intel_set_pipe_timings(struct intel_crtc
> > *intel_crtc)
> >(intel_crtc->config->pipe_src_h - 1));
> > }
> >
> > +static void intel_get_dsi_pipe_timings(struct intel_crtc *crtc,
> > + struct intel_crtc_state *pipe_config)
> > +{
> > + struct drm_device *dev = crtc->base.dev;
> > + struct drm_i915_private *dev_priv = dev->dev_private;
> > + enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
> > + struct intel_encoder *encoder;
> > + uint32_t tmp;
> > +
> > + tmp = I915_READ(HTOTAL(cpu_transcoder));
> > + pipe_config->base.adjusted_mode.crtc_hdisplay = (tmp & 0x) + 1;
> > + pipe_config->base.adjusted_mode.crtc_htotal =
> > + ((tmp >> 16) & 0x) + 1;
> > + tmp = I915_READ(HBLANK(cpu_transcoder));
> > + pipe_config->base.adjusted_mode.crtc_hblank_start = (tmp & 0x) + 1;
> > + pipe_config->base.adjusted_mode.crtc_hblank_end =
> > + ((tmp >> 16) & 0x) + 1;
> > + tmp = I915_READ(HSYNC(cpu_transcoder));
> > + pipe_config->base.adjusted_mode.crtc_hsync_start = (tmp & 0x) + 1;
> > + pipe_config->base.adjusted_mode.crtc_hsync_end =
> > + ((tmp >> 16) & 0x) + 1;
> > +
> > + tmp = I915_READ(VBLANK(cpu_transcoder));
> > + pipe_config->base.adjusted_mode.crtc_vblank_start = (tmp & 0x) + 1;
> > + pipe_config->base.adjusted_mode.crtc_vblank_end =
> > + ((tmp >> 16) & 0x) + 1;
> > + tmp = I915_READ(VSYNC(cpu_transcoder));
> > + pipe_config->base.adjusted_mode.crtc_vsync_start = (tmp & 0x) + 1;
> > + pipe_config->base.adjusted_mode.crtc_vsync_end =
> > + ((tmp >> 16) & 0x) + 1;
> > +
> > + if (I915_READ(PIPECONF(cpu_transcoder)) & PIPECONF_INTERLACE_MASK) {
> > + pipe_config->base.adjusted_mode.flags |=
> > + DRM_MODE_FLAG_INTERLACE;
> > + pipe_config->base.adjusted_mode.crtc_vtotal += 1;
> > + pipe_config->base.adjusted_mode.crtc_vblank_end += 1;
> > + }
> > +
> > +
> > + for_each_encoder_on_crtc(dev, &crtc->base, encoder) {
> > + struct intel_dsi *intel_dsi =
> > + enc_to_intel_dsi(&encoder->base);
> > + enum port port;
> > +
> > + pipe_config->pipe_bpp = intel_dsi->dsi_bpp;
> > + for_each_dsi_port(port, intel_dsi->ports) {
> > + pipe_config->base.adjusted_mode.crtc_hdisplay =
> > + I915_READ(BXT_MIPI_TRANS_HACTIVE(port));
> > + pipe_config->base.adjusted_mode.crtc_vdisplay =
> > + I915_READ(BXT_MIPI_TRANS_VACTIVE(port));
> > + pipe_config->base.adjusted_mode.crtc_vtotal =
> > + I915_READ(BXT_MIPI_TRANS_VTOTAL(port));
> > + }
> > + }
> > +
> > + tmp = I915_READ(PIPESRC(crtc->pipe));
> > + pipe_config->pipe_src_h = (tmp & 0x) + 1;
> > + pipe_config->pipe_src_w = ((tmp >> 16) & 0x) + 1;
> > +
> > + pipe_config->base.mode.vdisplay = pipe_config->pipe_src_h;
> > + pipe_config->base.mode.hdisplay = pipe_config->pipe_src_w;
> > +}
> > +
> > static void intel_get_pipe_timings(struct intel_crtc *crtc,
> >struct intel_crtc_state *pipe_config)
> > {
> > @@ -9969,6 +10032,7 @@ static bool haswell_get_pipe_config(struct
> > intel_crtc *crtc,
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > enum intel_display_power_domain pfit_domain;
> > uint32_t tmp;
> > + bool is_dsi = false;
> >
> > if (!intel_display_power_is_enabled(dev_priv,
> >
Re: [Intel-gfx] [PATCH] drm/i915: Protect fbdev across slow or failed initialisation
On Fri, Feb 05, 2016 at 03:58:31PM +0100, Lukas Wunner wrote:
> Hi Chris,
>
> On Fri, Feb 05, 2016 at 11:09:27AM +, Chris Wilson wrote:
> > On Fri, Feb 05, 2016 at 01:27:10AM +0100, Lukas Wunner wrote:
> > > On Thu, Feb 04, 2016 at 09:21:17AM +, Li, Weinan Z wrote:
> > > > We still need this patch. Seems 54632abe8ca3 ("drm/i915: Fix oops
> > > > caused by fbdev initialization
> > > > failure") as well as 366e39b4d2c5 ("drm/i915: Tear down fbdev if
> > > > initialization fails") this 2 patches can???t cover this case. It???s
> > > > access ifbdev->fb before the initialization
> > > > finished, but not initialization failed. If don???t have any other
> > > > patches or code update relative, it may still have in 4.5.
> > >
> > > Okay, I see.
> > >
> > > >
> > > > add info NULL check should be better, it is also initialized in the
> > > > async queue
> > > > > info = ifbdev->helper.fbdev;
> > > > > + if (info == NULL)
> > > > > +return false;
> > > > > if (!info->screen_base)
> > >
> > > So if there's indeed a race between fbdev initialization and the call to
> > > intel_fbdev_restore_mode() (on lastclose), there's more that can go awry:
> > > - intel_fbdev_restore_mode() dereferences ifbdev->fb->obj
> > > - it calls __drm_atomic_helper_set_config() which WARNs if ifbdev->fb is
> > > NULL
> > > - it calls drm_fb_helper_set_par() which dereferences ifbdev->helper.fbdev
> > >
> > > Instead of checking all that it's probably simpler to call
> > > async_synchronize_full() at the beginning of intel_fbdev_restore_mode(),
> > > as Li Weinan suggested. I'll submit the corresponding one-liner patch
> > > tomorrow if noone else does.
> > >
> > > Chris' patch also modified intel_fbdev_set_suspend() as well as
> > > intel_fbdev_output_poll_changed(), not sure if these are racy as well.
> > > At least the stack traces posted by Li Weinan and Gustav Fägerlind
> > > only indicate that lastclose is racy.
> >
> > We called set-suspend internally, but we don't do any checks before
> > hand. I was concerned we may be able to get into a situation where
> > .fb_probe fails and leaves a dangling dev_priv->ifbdev for which we
> > would then trip over the NULL info->screen_base. So I was looking for a
> > suitable guard.
>
> Yes, looking at this with a fresh pair of eyeballs I think you were
> totally right, i915_pm_ops is declared as part of i915_pci_driver and
> it might indeed happen that i915_pm_suspend() is called before the fbdev
> is fully initialized.
>
> As for intel_fbdev_output_poll_changed(), there's even a comment in
> i915_load_modeset_init() stating that hotplug events might occur
> during fdbev initial config.
>
> Below patch adds the requisite async_synchronize_full() to the three
> functions that you also modified and updates that comment.
>
> However AFAICT a corner case remains where we're still vulnerable to races:
> async_schedule() runs synchronously "if we're out of memory or if there's
> too much work pending already" (see __async_schedule() in kernel/async.c).
> In this case no entry is added to the pending list and
> async_synchronize_full() might theoretically return before the synchronously
> executed function has finished.
>
> The existing call to async_synchronize_full() in intel_fbdev_fini()
> seems to be susceptible to the same race condition, but it's probably
> very hard to trigger it. (Unload the module before the fbdev is fully
> initialized.)
>
> To make it bullet proof we could declare a completion in intel_fbdev.c
> and wait for that instead. Opinions?
>
> Thanks,
>
> Lukas
>
> -- >8 --
>
> Subject: [PATCH] drm/i915: Fix races on fbdev
>
> The ->lastclose callback invokes intel_fbdev_restore_mode() and has
> been witnessed to run before intel_fbdev_initial_config_async()
> has finished.
>
> We might likewise receive hotplug events or be suspended before
> we've had a chance to fully set up the fbdev.
>
> Fix by waiting for the asynchronous thread to finish.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580
> Reported-by: Gustav FÀgerlind
> Reported-by: "Li, Weinan Z"
> Cc: Chris Wilson
> Cc: sta...@vger.kernel.org
> Signed-off-by: Lukas Wunner
Can you pls resubmit this patch stand-alone? Patchwork (and therefore CI)
won't pick up inlined patches like this one here unfortunately.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/i915_dma.c| 8 +++-
> drivers/gpu/drm/i915/intel_fbdev.c | 4
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index a0f5659..a76b528 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -437,11 +437,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
>* Some ports require correctly set-up hpd registers for detection to
>* work properly (leading to ghost connected connector status), e.g. VGA
>* on gm45. Hence we can on
Re: [Intel-gfx] [PATCH] drm/i915/bxt: Save/restore HOTPLUG_CTL during suspend/resume.
On Thu, Feb 04, 2016 at 10:41:33AM +0200, Jani Nikula wrote: > On Thu, 04 Feb 2016, Matt Roper wrote: > > On Thu, Feb 04, 2016 at 07:17:08AM +0530, Thulasimani, Sivakumar wrote: > >> > >> > >> On 2/4/2016 6:19 AM, Matt Roper wrote: > >> >From: Bob Paauwe > >> > > >> >Broxton has some additional bits in the HOTPLUG_CTL register that > >> >indicate whether the HPD sense lines need to be inverted or not for the > >> >current platform. The BIOS sets these bits to an appropriate value at > >> >boot time, but the value is lost across suspend/resume. We need to save > >> >and restore the register so that hotplug and display detect works on > >> >resume. > >> i have a patch that is about to be upstreamed that will read and write > >> these > >> values based on vbt. Shuhangi did the basic testing last week so will > >> ask her to send to mail list today. i would prefer that patch where > >> we know how and when to set these bits rather than just save > >> & restore. > > > > Sure, sounds good. Can your patch handle cases where there is no VBT by > > falling back to a save/restore? Quite often in the embedded world, we > > have very specialized boot firmware that doesn't resemble vbios/gop and > > doesn't have any VBT info. > > Please no blind save/restore of registers anywhere. > > We can (and in many places do) read the BIOS set values for defaults at > driver load, but preferably should also survive without. If there's > anything you really need enabled, it should be stored in the appropriate > driver data structures, and the registers should be fully initialized > when needed. > > Looks like there's still plenty of read-modify-write in > *_hpd_irq_setup(), but the right approach would be to ensure > bxt_hpd_irq_setup() does the right thing for you. Either based on sane > defaults or VBT. Fully concurred. The safe/restore stuff for byt/chv/bxt is really not a part I like, and if we already have code to set up hpd bits (hpd_setup et al), then please don't proliferate safe/restore hacks. They're way too fragile, it's pretty much impossible to get ordering right and as soon as they need to interact with other setup functions you're landing in rmw hell. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix to allow render compression on primary plane of PIPEB
On Fri, Feb 05, 2016 at 06:51:53AM +0530, Thulasimani, Sivakumar wrote:
> not sure how this can be pushed separately even if approved at present.
> why not push this as part of new patch set of the RC patches ?
Yes, please don't send around patches which need depencies. Instead squash
them into the original patch (if it's a clear fixup) or add it as another
patch in the overall series (if it's a separate logical step in enabling a
feature and more involved).
Sending patches without their requirements just confuses CI&people.
Thanks, Daniel
>
> but ignoring the dependency this is fine.
> Reviewed-by: Sivakumar Thulasimani
>
> On 2/4/2016 11:44 AM, Mayuresh Gharpure wrote:
> >Currently, a flip with render compression enabled is failing on primary
> >plane of HDMI panel which is driven by PIPEB, this issue is fixed with
> >this patch
> >
> >Change-Id: I197fe61faffad9da58733ed3f0e8cf6ef8640af7
> >Signed-off-by: Mayuresh Gharpure
> >---
> >Please note that this patch depends on following patch:
> >https://patchwork.freedesktop.org/patch/67448/
> >
> >Current patch is a bug fix on the above mentioned patch
> > drivers/gpu/drm/i915/intel_display.c | 12
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_display.c
> >b/drivers/gpu/drm/i915/intel_display.c
> >index 4b23ec2..f8485fa 100644
> >--- a/drivers/gpu/drm/i915/intel_display.c
> >+++ b/drivers/gpu/drm/i915/intel_display.c
> >@@ -12777,10 +12777,6 @@ int intel_plane_atomic_calc_changes(struct
> >drm_crtc_state *crtc_state,
> > if (fb && to_intel_plane_state(plane_state)->
> > render_comp_enable) {
> >-if (to_intel_plane(plane)->plane != PLANE_A) {
> >-DRM_DEBUG_KMS("RC supported only on planes 1 &
> >2\n");
> >-return -EINVAL;
> >-}
> > ret = skl_check_compression(dev,
> > to_intel_plane_state(plane_state),
> > intel_crtc->pipe, crtc->x, crtc->y);
> >@@ -15088,6 +15084,7 @@ static int skl_check_compression(struct drm_device
> >*dev,
> > enum pipe pipe, int x, int y)
> > {
> > struct drm_framebuffer *fb = plane_state->base.fb;
> >+struct drm_plane *plane = plane_state->base.plane;
> > int x_offset;
> > int src_w = drm_rect_width(&plane_state->src) >> 16;
> >@@ -15127,6 +15124,13 @@ static int skl_check_compression(struct drm_device
> >*dev,
> > return -EINVAL;
> > }
> >+if (!(plane->type == DRM_PLANE_TYPE_PRIMARY ||
> >+(plane->type == DRM_PLANE_TYPE_OVERLAY &&
> >+to_intel_plane(plane)->plane == PLANE_A))) {
> >+DRM_DEBUG_KMS("RC supported only on planes 1 & 2\n");
> >+return -EINVAL;
> >+}
> >+
> > if (intel_rotation_90_or_270(plane_state->base.rotation)) {
> > DRM_DEBUG_KMS("RC support only with 0/180 degree rotation\n");
> > return -EINVAL;
>
> ___
> 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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/8] drm/i915: Adding the parsing logic for the i2c element
On Thu, Feb 04, 2016 at 06:36:22PM +0200, Ville Syrjälä wrote:
> On Thu, Feb 04, 2016 at 06:21:23PM +0200, Jani Nikula wrote:
> > On Thu, 04 Feb 2016, Ville Syrjälä wrote:
> > > On Thu, Feb 04, 2016 at 12:50:51PM +0200, Jani Nikula wrote:
> > >> From: vkorjani
> > >>
> > >> New sequence element for i2c is been added in the
> > >> mipi sequence block of the VBT. This patch parses
> > >> and executes the i2c sequence.
> > >>
> > >> v2: Add i2c_put_adapter call(Jani), rebase
> > >>
> > >> v3: corrected the retry loop(Jani), rebase
> > >>
> > >> v4 by Jani:
> > >> - don't put the adapter if get fails
> > >> - print an error message if all retries exhausted
> > >> - use a for loop
> > >> - fix warnings for unused variables
> > >>
> > >> v5 by Jani:
> > >> - rebase on the skip i2c element patch
> > >>
> > >> v6: by Jani:
> > >> - ignore the gmbus i2c elements (Ville)
> > >>
> > >> Signed-off-by: vkorjani
> > >> Signed-off-by: Deepak M
> > >> Signed-off-by: Jani Nikula
> > >> ---
> > >> drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 64
> > >> --
> > >> 1 file changed, 61 insertions(+), 3 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> > >> b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> > >> index 6f013efba45b..f4d303ee538b 100644
> > >> --- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> > >> +++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
> > >> @@ -31,6 +31,7 @@
> > >> #include
> > >> #include
> > >> #include
> > >> +#include
> > >> #include
> > >> #include
> > >> #include "i915_drv.h"
> > >> @@ -235,9 +236,66 @@ out:
> > >> return data;
> > >> }
> > >>
> > >> -static const u8 *mipi_exec_i2c_skip(struct intel_dsi *intel_dsi, const
> > >> u8 *data)
> > >> +static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8
> > >> *data)
> > >> {
> > >> -return data + *(data + 6) + 7;
> > >> +struct i2c_adapter *adapter;
> > >> +int ret, i;
> > >> +u8 reg_offset, payload_size;
> > >> +struct i2c_msg msg;
> > >> +u8 *transmit_buffer;
> > >> +u8 flag, resource_id, bus_number;
> > >> +u16 slave_add;
> > >> +
> > >> +flag = *data++;
> > >> +resource_id = *data++;
> > >> +bus_number = *data++;
> > >> +slave_add = *(u16 *)(data);
> > >> +data += 2;
> > >> +reg_offset = *data++;
> > >> +payload_size = *data++;
> > >> +
> > >> +if (resource_id == 0xff || bus_number == 0xff) {
> > >> +DRM_DEBUG_KMS("ignoring gmbus (resource id %02x, bus
> > >> %02x)\n",
> > >> + resource_id, bus_number);
> > >> +goto out;
> > >> +}
> > >> +
> > >
> > > Still missing the check for __i2c_first_dynamic_bus_num which I think
> > > would at least provide some kind of half arsed protection against
> > > something not registering these magic i2c busses.
> >
> > I meant to reply to that part of the review but forgot.
> >
> > Problem is, we'd have to include drivers/i2c/i2c-core.h directly, which
> > also has this warning,
> >
> > /* These symbols are exported ONLY FOR the i2c core.
> > * No other users will be supported.
> > */
> >
> > and there are no users outside of drivers/i2c. I'm quite reluctant to
> > add that.
>
> The we need some other way to look up the adapter. Passing in
> essentially random adapter numbers could give us more or less
> any i2c bus on the system, and if we go poke there we could do
> real damage.
>
> The whole scheme is very poorly thoght out I think. There really
> should be some kind of ACPI ID or something that lets us look up
> exactly the right thing.
Agreed this is super fragile, but we should at least try to make sure we
don't end up getting some random dynamic i2c adapter. Maybe add an
i2c_get_board_adapter or similar, which does this check in the i2c core?
Definitely need to pull in the i2c maintainers here (and help them with
avoid hair-pulling exercises on their end ...).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add missing 'else' to intel_digital_port_connected()
On Mon, Feb 15, 2016 at 03:21:54PM -, Patchwork wrote: > == Summary == > > Series 3292v1 drm/i915: Add missing 'else' to intel_digital_port_connected() > http://patchwork.freedesktop.org/api/1.0/series/3292/revisions/1/mbox/ > > Test gem_mmap_gtt: > Subgroup basic-small-copy-xy: > pass -> DMESG-FAIL (ilk-hp8440p) Some kind of corrupted spinlock: [ 488.270400] BUG: unable to handle kernel paging request at eef7 [ 488.270487] IP: [] __lock_acquire+0x1ac/0x1f70 [ 488.270555] PGD 13006a067 PUD 0 [ 488.270605] Oops: [#1] PREEMPT SMP [ 488.270667] Modules linked in: snd_hda_intel i915 ax88179_178a usbnet mii snd_hda_codec_hdmi snd_hda_codec_generic intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul snd_hda_codec ghash_clmulni_intel snd_hwdep snd_hda_core snd_pcm mei_me mei lpc_ich sdhci_pci sdhci mmc_core e1000e ptp pps_core [last unloaded: i915] [ 488.271084] CPU: 0 PID: 6426 Comm: gem_mmap_gtt Tainted: G U 4.5.0-rc3-gfxbench+ #1 [ 488.271162] Hardware name: Hewlett-Packard HP EliteBook 8440p/172A, BIOS 68CCU Ver. F.24 09/13/2013 [ 488.271240] task: 8800b4afcb00 ti: 880132314000 task.ti: 880132314000 [ 488.271306] RIP: 0010:[] [] __lock_acquire+0x1ac/0x1f70 [ 488.271387] RSP: 0018:880132317c10 EFLAGS: 00010002 [ 488.271437] RAX: 0001 RBX: 8800b4afcb00 RCX: [ 488.271499] RDX: RSI: RDI: eef7 [ 488.271561] RBP: 880132317cd0 R08: 0001 R09: [ 488.271623] R10: eef7 R11: R12: [ 488.271685] R13: R14: R15: [ 488.271749] FS: 7f700065a740() GS:880137c0() knlGS: [ 488.271820] CS: 0010 DS: ES: CR0: 80050033 [ 488.271872] CR2: eef7 CR3: 000130068000 CR4: 06f0 [ 488.271934] Stack: [ 488.271958] 880131f09c38 8800b4afcb00 0005 0003 [ 488.272047] 0001 8800b4afd350 880132317d08 00b8 [ 488.272136] 880131f09bb8 8801329d1bc0 880132317d98 [ 488.272224] Call Trace: [ 488.272256] [] ? trace_hardirqs_on_thunk+0x17/0x19 [ 488.272315] [] lock_acquire+0xc3/0x1d0 [ 488.272368] [] ? drop_pagecache_sb+0x68/0xe0 [ 488.272426] [] _raw_spin_lock+0x36/0x50 [ 488.272479] [] ? drop_pagecache_sb+0x68/0xe0 [ 488.272535] [] drop_pagecache_sb+0x68/0xe0 [ 488.272589] [] ? do_coredump+0xf70/0xf70 [ 488.272645] [] iterate_supers+0xa9/0x100 [ 488.272698] [] drop_caches_sysctl_handler+0x4e/0xb0 [ 488.272761] [] proc_sys_call_handler+0xc1/0xe0 [ 488.272817] [] proc_sys_write+0xf/0x20 [ 488.272868] [] __vfs_write+0x23/0xe0 [ 488.272920] [] ? percpu_down_read+0x52/0x90 [ 488.272975] [] ? __sb_start_write+0xd4/0xf0 [ 488.273030] [] ? __sb_start_write+0xd4/0xf0 [ 488.273085] [] vfs_write+0xa4/0x190 [ 488.273136] [] ? __fget_light+0x6a/0x90 [ 488.273188] [] SyS_write+0x44/0xb0 [ 488.273237] [] entry_SYSCALL_64_fastpath+0x16/0x73 [ 488.273294] Code: b7 a7 01 85 c0 75 0a 45 3b 7e 28 0f 85 1f 0a 00 00 4d 85 f6 75 40 45 31 e4 48 8d 65 d8 44 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <49> 81 3a c0 d4 ea 81 b8 00 00 00 00 44 0f 44 c0 41 83 ff 01 0f [ 488.273912] RIP [] __lock_acquire+0x1ac/0x1f70 [ 488.273975] RSP [ 488.274009] CR2: eef7 [ 488.274044] ---[ end trace cca43566d6f09c11 ]--- Imre and I had a look and this would seem to correspond to this C code: if (!prove_locking || lock->key == &__lockdep_no_validate__) check = 0; so the passed lockdep_map was garbage for some reason. > Test kms_pipe_crc_basic: > Subgroup suspend-read-crc-pipe-c: > dmesg-warn -> PASS (bsw-nuc-2) > Test pm_rpm: > Subgroup basic-pci-d3-state: > pass -> DMESG-WARN (bsw-nuc-2) *ERROR* Unclaimed access detected prior to suspending Seems to have been there for quite a while. Filed a bug https://bugs.freedesktop.org/show_bug.cgi?id=94164 > fail -> PASS (bdw-nuci7) > Subgroup basic-rte: > dmesg-warn -> PASS (bsw-nuc-2) > pass -> FAIL (bdw-ultra) The rpm tests seem unstable. Bunch of random fails here and there. Filed https://bugs.freedesktop.org/show_bug.cgi?id=94163 > > bdw-nuci7total:162 pass:152 dwarn:0 dfail:0 fail:0 skip:10 > bdw-ultratotal:165 pass:151 dwarn:0 dfail:0 fail:1 skip:13 > bsw-nuc-2total:165 pass:135 dwarn:1 dfail:0 fail:0 skip:29 > byt-nuc total:165 pass:141 dwarn:0 dfail:0 fail:0 skip:24 > hsw-brixbox total:165 pass:151 dwarn:0 dfail:0 fail:0 skip:14 > hsw-gt2 total:165 pass:154 dwarn:0 dfail:0 fail:1 skip:10 > ilk-hp8440p total:165
Re: [Intel-gfx] [PATCH i-g-t v3] lib/igt_core.c: Expand --run-subtest functionality.
On Thu, Feb 04, 2016 at 12:06:57PM +, Derek Morton wrote:
> Added extended wildcard support when specifying --run-subtest.
>
> Wildcard format is as specified in rfc3977 and the uwildmat() implementation
> is taken from libinn.
> See https://tools.ietf.org/html/rfc3977#section-4 for a description of
> allowed wildcard expressions.
>
> v2: Use comma as list separator (Ville Syrjala)
> support both ^ and ! as not operators (Dave Gordon)
>
> v3: Updated to use uwildmat() (Dave Gordon)
>
> Signed-off-by: Derek Morton
> ---
> COPYING | 21 +++
> lib/Makefile.sources| 2 +
> lib/igt_core.c | 17 +-
> lib/uwildmat/uwildmat.c | 474
>
> lib/uwildmat/uwildmat.h | 24 +++
Not really a fan of copying other sources into ours. Don't we have
something ready-made that's generally available, or can we at least pull
it in as a build-dep?
Thanks, Daniel
> 5 files changed, 536 insertions(+), 2 deletions(-)
> create mode 100644 lib/uwildmat/uwildmat.c
> create mode 100644 lib/uwildmat/uwildmat.h
>
> diff --git a/COPYING b/COPYING
> index b8f6753..16375f2 100644
> --- a/COPYING
> +++ b/COPYING
> @@ -106,3 +106,24 @@ 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.
> +
> +Copyright (c) 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012,
> +2013, 2014 by Internet Systems Consortium, Inc. ("ISC")
> +Copyright (c) 1991, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001,
> +2002, 2003 by The Internet Software Consortium and Rich Salz
> +
> +This code is derived from software contributed to the Internet Software
> +Consortium by Rich Salz.
> +
> +Permission to use, copy, modify, and distribute this software for any
> +purpose with or without fee is hereby granted, provided that the above
> +copyright notice and this permission notice appear in all copies.
> +
> +THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES WITH
> +REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
> +MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR ANY
> +SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
> +WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
> +ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
> +OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
> +
> diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> index 4999868..e33861e 100644
> --- a/lib/Makefile.sources
> +++ b/lib/Makefile.sources
> @@ -60,6 +60,8 @@ libintel_tools_la_SOURCES = \
> igt_core.h \
> igt_draw.c \
> igt_draw.h \
> + uwildmat/uwildmat.h \
> + uwildmat/uwildmat.c \
> $(NULL)
>
> .PHONY: version.h.tmp
> diff --git a/lib/igt_core.c b/lib/igt_core.c
> index 6b69bb7..8e0bd2e 100644
> --- a/lib/igt_core.c
> +++ b/lib/igt_core.c
> @@ -56,7 +56,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
> #include "drmtest.h"
> #include "intel_chipset.h"
> @@ -209,6 +209,19 @@
> * intel gpu to be present). Then individual subtests can be run with
> * "--run-subtest". Usage help for tests with subtests can be obtained with
> the
> * "--help" command line option.
> + *
> + * A wildcard expression can be given to --run-subtest to specify a subset of
> + * subtests to run. See https://tools.ietf.org/html/rfc3977#section-4 for a
> + * description of allowed wildcard expressions.
> + * Some examples of allowed wildcard expressions are:
> + *
> + * - '*basic*' match any subtest containing basic
> + * - 'basic-???' match any subtest named basic- with 3 characters after -
> + * - 'basic-[0-9]' match any subtest named basic- with a single number after
> -
> + * - 'basic-[^0-9]' match any subtest named basic- with a single non
> numerical character after -
> + * - 'basic*,advanced*' match any subtest starting basic or advanced
> + * - '*,!basic*' match any subtest not starting basic
> + * - 'basic*,!basic-render*' match any subtest starting basic but not
> starting basic-render
> */
>
> static unsigned int exit_handler_count;
> @@ -814,7 +827,7 @@ bool __igt_run_subtest(const char *subtest_name)
> }
>
> if (run_single_subtest) {
> - if (fnmatch(run_single_subtest, subtest_name, 0) != 0)
> + if (uwildmat(subtest_name, run_single_subtest) == 0)
> return false;
> else
> run_single_subtest_found = true;
> diff --git a/lib/uwildmat/uwildmat.c b/lib/uwildmat/uwildmat.c
> new file mode 100644
> index 000..2d34742
> --- /dev/null
> +++ b/lib/uwildmat/uwildmat.c
> @@ -0,0 +1,474 @@
> +/* uwildmat.c is reused from libinn -
> https://launchpad.net/ubuntu/+source/inn
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_pipe_crc_basic: Don't suspend the machine if
On Thu, Feb 04, 2016 at 04:25:41PM +0200, Marius Vlad wrote:
> suspend-read-crc-pipe will perform a suspend and then skip the test in case
> the
> pipe is not present on the platform. Skip the test before doing the suspend.
>
>
> Signed-off-by: Marius Vlad
> ---
> tests/kms_pipe_crc_basic.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tests/kms_pipe_crc_basic.c b/tests/kms_pipe_crc_basic.c
> index 3c51ba0..dbb2919 100644
> --- a/tests/kms_pipe_crc_basic.c
> +++ b/tests/kms_pipe_crc_basic.c
> @@ -271,6 +271,7 @@ igt_main
> test_read_crc(&data, i, TEST_SEQUENCE | TEST_NONBLOCK);
>
> igt_subtest_f("suspend-read-crc-pipe-%c", 'A'+i) {
> + igt_skip_on(i >= data.display.n_pipes);
We should place this into an igt_fixture at the top of the loop. Hitting
igt_skip outside of any testcase means we'll skip all the subsequent ones
without doing any work.
Otoh this is a bit a bikeshed, so Reviewed-by: Daniel Vetter
either way.
-Daniel
> igt_system_suspend_autoresume();
>
> test_read_crc(&data, i, 0);
> --
> 2.7.0
>
> ___
> 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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Reject invalid-pad for context-destroy and -create ioctls
On Fri, Feb 05, 2016 at 04:45:59PM +, Chris Wilson wrote: > Unknown parameters, especially structure padding, are expected to invoke > rejection with -EINVAL. > > v2: similar issue exists for context-create > > Testcase: igt/gem_ctx_create/invalid-pad > Testcase: igt/gem_ctx_bad_destroy/invalid-pad > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89602 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93999 > Signed-off-by: Chris Wilson > Cc: Daniel Vetter > Reviewed-by: Daniel Vetter Queued for -next, thanks for the patch. -Daniel > --- > drivers/gpu/drm/i915/i915_gem_context.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c > b/drivers/gpu/drm/i915/i915_gem_context.c > index 54af654d04d6..c75d3468f29a 100644 > --- a/drivers/gpu/drm/i915/i915_gem_context.c > +++ b/drivers/gpu/drm/i915/i915_gem_context.c > @@ -972,6 +972,9 @@ int i915_gem_context_create_ioctl(struct drm_device *dev, > void *data, > if (!contexts_enabled(dev)) > return -ENODEV; > > + if (args->pad != 0) > + return -EINVAL; > + > ret = i915_mutex_lock_interruptible(dev); > if (ret) > return ret; > @@ -995,6 +998,9 @@ int i915_gem_context_destroy_ioctl(struct drm_device > *dev, void *data, > struct intel_context *ctx; > int ret; > > + if (args->pad != 0) > + return -EINVAL; > + > if (args->ctx_id == DEFAULT_CONTEXT_HANDLE) > return -ENOENT; > > -- > 2.7.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting
On Mon, Feb 15, 2016 at 03:17:55PM +0100, Peter Zijlstra wrote:
> On Mon, Feb 15, 2016 at 02:36:43PM +0200, Joonas Lahtinen wrote:
> > Instead of implementing a custom locked reference counting, use lockref.
> >
> > Current implementation leads to a deadlock splat on Intel SKL platforms
> > when lockdep debugging is enabled.
> >
> > This is due to few of CPUfreq drivers (including Intel P-state) having this;
> > policy->rwsem is locked during driver initialization and the functions
> > called
> > during init that actually apply CPU limits use get_online_cpus (because they
> > have other calling paths too), which will briefly lock cpu_hotplug.lock to
> > increase cpu_hotplug.refcount.
> >
> > On later calling path, when doing a suspend, when cpu_hotplug_begin() is
> > called
> > in disable_nonboot_cpus(), callbacks to CPUfreq functions get called after,
> > which will lock policy->rwsem and cpu_hotplug.lock is already held by
> > cpu_hotplug_begin() and we do have a potential deadlock scenario reported by
> > our CI system (though it is a very unlikely one). See the Bugzilla link for
> > more
> > details.
>
> I've been meaning to change the thing into a percpu-rwsem, I just
> haven't had time to look into the lockdep splat that generated.
The below has plenty lockdep issues because percpu-rwsem is
reader-writer fair (like the regular rwsem), so it does throw up a fair
number of very icky issues.
If at all possible, I'd really rather fix those and have a 'saner'
hotplug lock, rather than muddle on with open-coded horror lock we have
now.
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -225,6 +225,8 @@ extern struct bus_type cpu_subsys;
#ifdef CONFIG_HOTPLUG_CPU
/* Stop CPUs going up and down. */
+extern void cpu_hotplug_init_task(struct task_struct *p);
+
extern void cpu_hotplug_begin(void);
extern void cpu_hotplug_done(void);
extern void get_online_cpus(void);
@@ -242,6 +244,8 @@ int cpu_down(unsigned int cpu);
#else /* CONFIG_HOTPLUG_CPU */
+static inline void cpu_hotplug_init_task(struct task_struct *p) {}
+
static inline void cpu_hotplug_begin(void) {}
static inline void cpu_hotplug_done(void) {}
#define get_online_cpus() do { } while (0)
--- a/include/linux/percpu-rwsem.h
+++ b/include/linux/percpu-rwsem.h
@@ -16,6 +16,15 @@ struct percpu_rw_semaphore {
wait_queue_head_t write_waitq;
};
+#define DEFINE_STATIC_PERCPU_RWSEM(name) \
+static DEFINE_PER_CPU(unsigned int, __percpu_rwsem_frc_##name);\
+static struct percpu_rw_semaphore name = { \
+ .rss = __RCU_SYNC_INITIALIZER(name.rss, RCU_SCHED_SYNC),\
+ .fast_read_ctr = &__percpu_rwsem_frc_##name,\
+ .rw_sem = __RWSEM_INITIALIZER(name.rw_sem), \
+ .write_waitq = __WAIT_QUEUE_HEAD_INITIALIZER(name.write_waitq), \
+}
+
extern void percpu_down_read(struct percpu_rw_semaphore *);
extern int percpu_down_read_trylock(struct percpu_rw_semaphore *);
extern void percpu_up_read(struct percpu_rw_semaphore *);
@@ -33,9 +42,11 @@ extern void percpu_free_rwsem(struct per
__percpu_init_rwsem(brw, #brw, &rwsem_key); \
})
-
#define percpu_rwsem_is_held(sem) lockdep_is_held(&(sem)->rw_sem)
+#define percpu_rwsem_assert_held(sem) \
+ lockdep_assert_held(&(sem)->rw_sem)
+
static inline void percpu_rwsem_release(struct percpu_rw_semaphore *sem,
bool read, unsigned long ip)
{
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1403,6 +1403,9 @@ struct task_struct {
struct task_struct *last_wakee;
int wake_cpu;
+#ifdef CONFIG_HOTPLUG_CPU
+ int cpuhp_ref;
+#endif
#endif
int on_rq;
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -23,6 +23,7 @@
#include
#include
#include
+#include
#include "smpboot.h"
@@ -51,121 +52,52 @@ EXPORT_SYMBOL(cpu_notifier_register_done
static RAW_NOTIFIER_HEAD(cpu_chain);
-/* If set, cpu_up and cpu_down will return -EBUSY and do nothing.
+/*
+ * If set, cpu_up and cpu_down will return -EBUSY and do nothing.
* Should always be manipulated under cpu_add_remove_lock
*/
static int cpu_hotplug_disabled;
#ifdef CONFIG_HOTPLUG_CPU
-static struct {
- struct task_struct *active_writer;
- /* wait queue to wake up the active_writer */
- wait_queue_head_t wq;
- /* verifies that no writer will get active while readers are active */
- struct mutex lock;
- /*
-* Also blocks the new readers during
-* an ongoing cpu hotplug operation.
-*/
- atomic_t refcount;
-
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
- struct lockdep_map dep_map;
-#endif
-} cpu_hotplug = {
- .active_writer = NULL,
- .wq = __WAIT_QUEUE_HEAD_INITIALIZER(cpu_hotplug.wq),
- .lock = __MUTEX_INITIALIZER(cpu_hotplug.lock),
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
- .dep_map
Re: [Intel-gfx] [PATCH v8 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6
On Mon, Feb 08, 2016 at 05:08:03PM +0200, Jani Nikula wrote: > On Mon, 08 Feb 2016, Imre Deak wrote: > >> > Thanks for the patch, I pushed it to -dinq. > >> > >> The rule is, we should wait for the CI results before pushing. > > > > Yes, I forgot to wait for the result for this version of the patch, > > thanks for pointing it out. As a side-note the CI result still didn't > > show up, what to do in that case? Resend the patch after a day or so? > > Complain to Damien and/or Tomi. CI is/was down. Please don't push patches when that happens, but instead wait for things to stabilize again. Yes that slows things down, but otoh everytime CI is down we manage to sneak in an overlapping regression. And recovering from overlapping regressions makes everything even more painful than it already is. Yes, some kind of CI status dashboard is on the wishlist. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/1] drm/i915: Fix races on fbdev
The ->lastclose callback invokes intel_fbdev_restore_mode() and has
been witnessed to run before intel_fbdev_initial_config_async()
has finished.
We might likewise receive hotplug events or be suspended before
we've had a chance to fully set up the fbdev.
Fix by waiting for the asynchronous thread to finish.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93580
Reported-by: Gustav Fägerlind
Reported-by: "Li, Weinan Z"
Cc: Chris Wilson
Cc: sta...@vger.kernel.org
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i915/i915_dma.c| 8 +++-
drivers/gpu/drm/i915/intel_fbdev.c | 4
2 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a0f5659..a76b528 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -437,11 +437,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
* Some ports require correctly set-up hpd registers for detection to
* work properly (leading to ghost connected connector status), e.g. VGA
* on gm45. Hence we can only set up the initial fbdev config after hpd
-* irqs are fully enabled. Now we should scan for the initial config
-* only once hotplug handling is enabled, but due to screwed-up locking
-* around kms/fbdev init we can't protect the fdbev initial config
-* scanning against hotplug events. Hence do this first and ignore the
-* tiny window where we will loose hotplug notifactions.
+* irqs are fully enabled. We protect the fbdev initial config scanning
+* against hotplug events by waiting in intel_fbdev_output_poll_changed
+* until the asynchronous thread has finished.
*/
intel_fbdev_initial_config_async(dev);
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 09840f4..2002b13 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -749,6 +749,7 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int
state, bool synchronous
struct intel_fbdev *ifbdev = dev_priv->fbdev;
struct fb_info *info;
+ async_synchronize_full();
if (!ifbdev)
return;
@@ -795,6 +796,8 @@ void intel_fbdev_set_suspend(struct drm_device *dev, int
state, bool synchronous
void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
+
+ async_synchronize_full();
if (dev_priv->fbdev)
drm_fb_helper_hotplug_event(&dev_priv->fbdev->helper);
}
@@ -806,6 +809,7 @@ void intel_fbdev_restore_mode(struct drm_device *dev)
struct intel_fbdev *ifbdev = dev_priv->fbdev;
struct drm_fb_helper *fb_helper;
+ async_synchronize_full();
if (!ifbdev)
return;
--
1.8.5.2 (Apple Git-48)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/1] drm/i915: Fix races on fbdev [RESEND FOR CI]
Originally submitted inline with <20160205145831.ga14...@wunner.de>, hereby resubmitted standalone for CI as requested by Daniel with <20160215163251.GR11240@phenom.ffwll.local>. Above-mentioned message contained the following important note: > However AFAICT a corner case remains where we're still vulnerable to races: > async_schedule() runs synchronously "if we're out of memory or if there's > too much work pending already" (see __async_schedule() in kernel/async.c). > In this case no entry is added to the pending list and > async_synchronize_full() might theoretically return before the synchronously > executed function has finished. > > The existing call to async_synchronize_full() in intel_fbdev_fini() > seems to be susceptible to the same race condition, but it's probably > very hard to trigger it. (Unload the module before the fbdev is fully > initialized.) > > To make it bullet proof we could declare a completion in intel_fbdev.c > and wait for that instead. Opinions? Lukas Wunner (1): drm/i915: Fix races on fbdev drivers/gpu/drm/i915/i915_dma.c| 8 +++- drivers/gpu/drm/i915/intel_fbdev.c | 4 2 files changed, 7 insertions(+), 5 deletions(-) -- 1.8.5.2 (Apple Git-48) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix hpd live status bits for g4x
On Fri, Feb 12, 2016 at 08:26:27AM +0200, Jani Nikula wrote:
> On Thu, 11 Feb 2016, Daniel Vetter wrote:
> > On Wed, Feb 10, 2016 at 07:59:05PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> >> From: Ville Syrjälä
> >>
> >> Looks like g4x hpd live status bits actually agree with the spec. At
> >> least they do on the machine I have, and apparently on Nick Bowler's
> >> g4x as well.
> >>
> >> So gm45 may be the only platform where they don't agree. At least
> >> that seems to be the case based on the (somewhat incomplete)
> >> logs/dumps in [1], and Daniel has also tested this on his gm45
> >> sometime in the past.
> >>
> >> So let's change the bits to match the spec on g4x. That actually makes
> >> the g4x bits identical to vlv/chv so we can just share the code
> >> between those platforms, leaving gm45 as the special case.
> >>
> >> [1] https://bugzilla.kernel.org/show_bug.cgi?id=52361
> >>
> >> Cc: Shashank Sharma
> >> Cc: Sonika Jindal
> >> Cc: Daniel Vetter
> >> Cc: Jani Nikula
> >> Cc: Nick Bowler
> >> References:
> >> https://lists.freedesktop.org/archives/dri-devel/2016-February/100382.html
> >> Reported-by: Nick Bowler
> >> Cc: sta...@vger.kernel.org
> >> Fixes: 237ed86c693d ("drm/i915: Check live status before reading edid")
> >> Signed-off-by: Ville Syrjälä
> >
> > Yeah I'm hopeful this will work. Reviewed-by: Daniel Vetter
> >
> >
> > Since CI is down and this is super restricted impact and fixing a
> > regression I'm voting that we'll pick it up right away. Jani, are you ok
> > with that?
>
> Ack.
"Right away" was slightly dealyed by my lazyness.
Anyway, pushed this to dinq. Thanks for the review.
>
> > -Daniel
> >
> >> ---
> >> drivers/gpu/drm/i915/i915_reg.h | 15 ---
> >> drivers/gpu/drm/i915/intel_dp.c | 14 +++---
> >> 2 files changed, 15 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> b/drivers/gpu/drm/i915/i915_reg.h
> >> index 188ad5de020f..678faa957e75 100644
> >> --- a/drivers/gpu/drm/i915/i915_reg.h
> >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> @@ -3296,19 +3296,20 @@ enum skl_disp_power_wells {
> >>
> >> #define PORT_HOTPLUG_STAT _MMIO(dev_priv->info.display_mmio_offset +
> >> 0x61114)
> >> /*
> >> - * HDMI/DP bits are gen4+
> >> + * HDMI/DP bits are g4x+
> >> *
> >> * WARNING: Bspec for hpd status bits on gen4 seems to be completely
> >> confused.
> >> * Please check the detailed lore in the commit message for for
> >> experimental
> >> * evidence.
> >> */
> >> -#define PORTD_HOTPLUG_LIVE_STATUS_G4X (1 << 29)
> >> +/* Bspec says GM45 should match G4X/VLV/CHV, but reality disagrees */
> >> +#define PORTD_HOTPLUG_LIVE_STATUS_GM45 (1 << 29)
> >> +#define PORTC_HOTPLUG_LIVE_STATUS_GM45 (1 << 28)
> >> +#define PORTB_HOTPLUG_LIVE_STATUS_GM45 (1 << 27)
> >> +/* G4X/VLV/CHV DP/HDMI bits again match Bspec */
> >> +#define PORTD_HOTPLUG_LIVE_STATUS_G4X (1 << 27)
> >> #define PORTC_HOTPLUG_LIVE_STATUS_G4X (1 << 28)
> >> -#define PORTB_HOTPLUG_LIVE_STATUS_G4X (1 << 27)
> >> -/* VLV DP/HDMI bits again match Bspec */
> >> -#define PORTD_HOTPLUG_LIVE_STATUS_VLV (1 << 27)
> >> -#define PORTC_HOTPLUG_LIVE_STATUS_VLV (1 << 28)
> >> -#define PORTB_HOTPLUG_LIVE_STATUS_VLV (1 << 29)
> >> +#define PORTB_HOTPLUG_LIVE_STATUS_G4X (1 << 29)
> >> #define PORTD_HOTPLUG_INT_STATUS(3 << 21)
> >> #define PORTD_HOTPLUG_INT_LONG_PULSE(2 << 21)
> >> #define PORTD_HOTPLUG_INT_SHORT_PULSE (1 << 21)
> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> >> b/drivers/gpu/drm/i915/intel_dp.c
> >> index a073f04a5330..bbe18996efe6 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -4490,20 +4490,20 @@ static bool g4x_digital_port_connected(struct
> >> drm_i915_private *dev_priv,
> >>return I915_READ(PORT_HOTPLUG_STAT) & bit;
> >> }
> >>
> >> -static bool vlv_digital_port_connected(struct drm_i915_private *dev_priv,
> >> - struct intel_digital_port *port)
> >> +static bool gm45_digital_port_connected(struct drm_i915_private *dev_priv,
> >> + struct intel_digital_port *port)
> >> {
> >>u32 bit;
> >>
> >>switch (port->port) {
> >>case PORT_B:
> >> - bit = PORTB_HOTPLUG_LIVE_STATUS_VLV;
> >> + bit = PORTB_HOTPLUG_LIVE_STATUS_GM45;
> >>break;
> >>case PORT_C:
> >> - bit = PORTC_HOTPLUG_LIVE_STATUS_VLV;
> >> + bit = PORTC_HOTPLUG_LIVE_STATUS_GM45;
> >>break;
> >>case PORT_D:
> >> - bit = PORTD_HOTPLUG_LIVE_STATUS_VLV;
> >> + bit = PORTD_HOTPLUG_LIVE_STATUS_GM45;
> >>break;
> >>default:
> >>MISSING_CASE(port->port);
> >> @@ -4555,8 +4555,8 @@ bool intel_digital_port_connected(struct
> >> drm_i915_private *dev_priv,
> >>
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add missing 'else' to intel_digital_port_connected()
On Mon, Feb 15, 2016 at 06:52:52PM +0200, Ville Syrjälä wrote: > On Mon, Feb 15, 2016 at 03:21:54PM -, Patchwork wrote: > > == Summary == > > > > Series 3292v1 drm/i915: Add missing 'else' to intel_digital_port_connected() > > http://patchwork.freedesktop.org/api/1.0/series/3292/revisions/1/mbox/ > > > > Test gem_mmap_gtt: > > Subgroup basic-small-copy-xy: > > pass -> DMESG-FAIL (ilk-hp8440p) > > Some kind of corrupted spinlock: > > [ 488.270400] BUG: unable to handle kernel paging request at eef7 > [ 488.270487] IP: [] __lock_acquire+0x1ac/0x1f70 > [ 488.270555] PGD 13006a067 PUD 0 > [ 488.270605] Oops: [#1] PREEMPT SMP > [ 488.270667] Modules linked in: snd_hda_intel i915 ax88179_178a usbnet mii > snd_hda_codec_hdmi snd_hda_codec_generic intel_powerclamp coretemp > crct10dif_pclmul crc32_pclmul snd_hda_codec ghash_clmulni_intel snd_hwdep > snd_hda_core snd_pcm mei_me mei lpc_ich sdhci_pci sdhci mmc_core e1000e ptp > pps_core [last unloaded: i915] > [ 488.271084] CPU: 0 PID: 6426 Comm: gem_mmap_gtt Tainted: G U > 4.5.0-rc3-gfxbench+ #1 > [ 488.271162] Hardware name: Hewlett-Packard HP EliteBook 8440p/172A, BIOS > 68CCU Ver. F.24 09/13/2013 > [ 488.271240] task: 8800b4afcb00 ti: 880132314000 task.ti: > 880132314000 > [ 488.271306] RIP: 0010:[] [] > __lock_acquire+0x1ac/0x1f70 > [ 488.271387] RSP: 0018:880132317c10 EFLAGS: 00010002 > [ 488.271437] RAX: 0001 RBX: 8800b4afcb00 RCX: > > [ 488.271499] RDX: RSI: RDI: > eef7 > [ 488.271561] RBP: 880132317cd0 R08: 0001 R09: > > [ 488.271623] R10: eef7 R11: R12: > > [ 488.271685] R13: R14: R15: > > [ 488.271749] FS: 7f700065a740() GS:880137c0() > knlGS: > [ 488.271820] CS: 0010 DS: ES: CR0: 80050033 > [ 488.271872] CR2: eef7 CR3: 000130068000 CR4: > 06f0 > [ 488.271934] Stack: > [ 488.271958] 880131f09c38 8800b4afcb00 0005 > 0003 > [ 488.272047] 0001 8800b4afd350 880132317d08 > 00b8 > [ 488.272136] 880131f09bb8 8801329d1bc0 > 880132317d98 > [ 488.272224] Call Trace: > [ 488.272256] [] ? trace_hardirqs_on_thunk+0x17/0x19 > [ 488.272315] [] lock_acquire+0xc3/0x1d0 > [ 488.272368] [] ? drop_pagecache_sb+0x68/0xe0 > [ 488.272426] [] _raw_spin_lock+0x36/0x50 > [ 488.272479] [] ? drop_pagecache_sb+0x68/0xe0 > [ 488.272535] [] drop_pagecache_sb+0x68/0xe0 > [ 488.272589] [] ? do_coredump+0xf70/0xf70 > [ 488.272645] [] iterate_supers+0xa9/0x100 > [ 488.272698] [] drop_caches_sysctl_handler+0x4e/0xb0 > [ 488.272761] [] proc_sys_call_handler+0xc1/0xe0 > [ 488.272817] [] proc_sys_write+0xf/0x20 > [ 488.272868] [] __vfs_write+0x23/0xe0 > [ 488.272920] [] ? percpu_down_read+0x52/0x90 > [ 488.272975] [] ? __sb_start_write+0xd4/0xf0 > [ 488.273030] [] ? __sb_start_write+0xd4/0xf0 > [ 488.273085] [] vfs_write+0xa4/0x190 > [ 488.273136] [] ? __fget_light+0x6a/0x90 > [ 488.273188] [] SyS_write+0x44/0xb0 > [ 488.273237] [] entry_SYSCALL_64_fastpath+0x16/0x73 > [ 488.273294] Code: b7 a7 01 85 c0 75 0a 45 3b 7e 28 0f 85 1f 0a 00 00 4d 85 > f6 75 40 45 31 e4 48 8d 65 d8 44 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 <49> > 81 3a c0 d4 ea 81 b8 00 00 00 00 44 0f 44 c0 41 83 ff 01 0f > [ 488.273912] RIP [] __lock_acquire+0x1ac/0x1f70 > [ 488.273975] RSP > [ 488.274009] CR2: eef7 > [ 488.274044] ---[ end trace cca43566d6f09c11 ]--- > > Imre and I had a look and this would seem to correspond to this C code: > if (!prove_locking || lock->key == &__lockdep_no_validate__) > check = 0; > > so the passed lockdep_map was garbage for some reason. > > > Test kms_pipe_crc_basic: > > Subgroup suspend-read-crc-pipe-c: > > dmesg-warn -> PASS (bsw-nuc-2) > > Test pm_rpm: > > Subgroup basic-pci-d3-state: > > pass -> DMESG-WARN (bsw-nuc-2) > > *ERROR* Unclaimed access detected prior to suspending > > Seems to have been there for quite a while. Filed a bug > https://bugs.freedesktop.org/show_bug.cgi?id=94164 > > > fail -> PASS (bdw-nuci7) > > Subgroup basic-rte: > > dmesg-warn -> PASS (bsw-nuc-2) > > pass -> FAIL (bdw-ultra) > > The rpm tests seem unstable. Bunch of random fails here and > there. Filed https://bugs.freedesktop.org/show_bug.cgi?id=94163 None of that seems related to my little 'else' so I went and pushed the patch to dinq. Thanks for the review. > > > > > bdw-nuci7total:162 pass:152 dwarn:0 dfail:0 fail:0 skip:10 > > bdw-ultratot
Re: [Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting
On Mon, Feb 15, 2016 at 03:17:55PM +0100, Peter Zijlstra wrote: > On Mon, Feb 15, 2016 at 02:36:43PM +0200, Joonas Lahtinen wrote: > > Instead of implementing a custom locked reference counting, use lockref. > > > > Current implementation leads to a deadlock splat on Intel SKL platforms > > when lockdep debugging is enabled. > > > > This is due to few of CPUfreq drivers (including Intel P-state) having this; > > policy->rwsem is locked during driver initialization and the functions > > called > > during init that actually apply CPU limits use get_online_cpus (because they > > have other calling paths too), which will briefly lock cpu_hotplug.lock to > > increase cpu_hotplug.refcount. > > > > On later calling path, when doing a suspend, when cpu_hotplug_begin() is > > called > > in disable_nonboot_cpus(), callbacks to CPUfreq functions get called after, > > which will lock policy->rwsem and cpu_hotplug.lock is already held by > > cpu_hotplug_begin() and we do have a potential deadlock scenario reported by > > our CI system (though it is a very unlikely one). See the Bugzilla link for > > more > > details. > > I've been meaning to change the thing into a percpu-rwsem, I just > haven't had time to look into the lockdep splat that generated. I've thrown Joonas patch into a local topic branch to shut up the noise in our CI, and it seems to be effective at that (2 runs thus far). I'll drop this again once we have a proper solution (whatever it'll be) upstream. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Discuss GVT context hacks in i915
On Mon, Feb 15, 2016 at 04:03:49PM +, Wang, Zhi A wrote:
> Hi Daniel:
> Thanks for shedding the light! See my comments below. :)
>
> -Original Message-
> From: Vetter, Daniel
> Sent: Monday, February 15, 2016 5:32 PM
> To: Wang, Zhi A; Joonas Lahtinen; Chris Wilson; Lv, Zhiyuan; Tian, Kevin
> Subject: Re: Discuss GVT context hacks in i915
>
> Am 15/02/2016 um 10:11 schrieb Zhi Wang:
> > Hi Guys:
> >Previously we have sent our GVT-g device model RFC code, and thanks
> > for the advices and comments! As you see GVT-g needs a special kind of
> > LRC context as shadow context so it could be able to use i915 GEM
> > submission subsystem, which requires some changes in i915.
> >
> > Probably we can discuss them one by one and settle them down before
> > the next version of RFC code. :)
> >
> > Difference between a i915 LRC context and a GVT LRC context
> > --
> >
> > * The engine context initialization of a GVT LRC context can be
> > bypassed, as GVT-g will initialize it by guest LRC context.
> >
> > http://www.spinics.net/lists/intel-gfx/msg86546.html
> >
> > * The addressing mode bit in the context descriptor should be able to
> > configured at runtime, as some guest is still using 32bit PPGTT
> > address space.
> >
> > http://www.spinics.net/lists/intel-gfx/msg86544.html
> >
> > * As the GVT LRC context will go with the shadow PPGTT page table
> > populated by GVT-g, a GVT LRC context doesn't need a i915 PPGTT
> > instance, also its PDP root pointer doesn't need to be populated by i915.
> >
> > http://www.spinics.net/lists/intel-gfx/msg86545.html
> >
> > * The ring buffer size of a GVT LRC context ring buffer object should
> > be configurable or hard-coded to the max size, as some guest (e.g.
> > windows) has a large ring buffer and could submit a lot of commands at
> > one time.
> >
> > Hacking i915
> > ---
> >
> > The above changes needs to hack i915, in the RFC code, you can see a
> > lot of codes like below:
> >
> > if (!gvt_context) {
> > /* do something i915 needed */
> > } else {
> > /* do something GVT-g needed */
> > }
> >
> > This kinds of code piece is GVT-g specific, another approach should be
> > refining some i915 APIs or say something generic, like:
> >
> > if (context->need_i915_ppgtt) {
> > /* allocating i915 ppgtt instance */
> > }
> >
> > if (context->ppgtt) {
> > /* update PDP root pointers in LRC context. */
> > }
> >
> > if (context->need_initialization) {
> > /* emit commands to initialize the engine context of LRC context */
> > }
> >
> > I'm wondering which kinds do you prefer? Or maybe you can give me some
> > advices? :)
>
> Without looking at more than what's in your mail here and in the links,
> this style is the midlayer mistake: We have some abstraction (lrc
> context, ppgtt) and force everyone to go through the same code paths.
> Which means deep down in those paths we have lots of if (special_case)
> conditions, which make the code a maintainance nightmare. Yes execlist
> support has already a lot of such bad examples unfortunately.
>
> The better design idea is to reuse the data structures and helper
> functions, but have new top-level entry functions for creating e.g. a
> xengt lrc context. So e.g. have a lrc init function for xengt which
> takes the setup stuff as parameters. Wrt ppgtt my idea was to reuse
> struct i915_hw_ppgtt for managing the shadow pagetable, with xengt using
> the i915_gem_gtt.c functions to write shadow pagetable entries. That way
> i915 still knows the virtual->physical mapping, which aids in e.g. crash
> dump recording. Of course you're not going to bind entire vma, but
> instead will use the lower-level functions that just bind pages.
>
> [Zhi] Thanks! Just want to make sure that you prefer that GVT-g specific
> modifications should be put into a fork of top-level i915 APIs? For example,
> we prepare a new function to create the GVT context, which is a fork of
> simplified i915_gem_create_context().
>
> For i915_hw_ppgtt and GVT-g shadow page table, we tried to think about how
> to merge these two similar things into one, but have some opens:
>
> Most of the GTT/PPGTT page table entry routines in i915_gem_gtt.c, e.g. the
> abstractions/ insert_entries() are aimed to generate the page table entry, but
> GVT-g shadow page implementation also need the per-platform page table
> entry bit field extraction routines. For example, extract the GFN from guest
> page
> table, which means we have to add some new callbacks which native i915
> will not use at all. Is it OK for host i915 to add such kinds of callbacks?
>
> b. GVT-g shadow page table implementation should be the most complicated
> part in GVT-g, maybe the first easy step should be putting the shadow page
> table root pointer into i915_hw_ppgtt. E.g. GVT-g allocates a fake
> i915_hw_ppgtt
> only use it to store root pointer and addressing mode bit?
>
> For ppgtt size selection I think we should have a field
Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Check for get_pages instead of shmem (filp) (rev2)
On Wed, Feb 10, 2016 at 07:14:36AM -, Patchwork wrote: > == Summary == > > Series 3145v2 drm/i915: Check for get_pages instead of shmem (filp) > http://patchwork.freedesktop.org/api/1.0/series/3145/revisions/2/mbox/ > > Test pm_rpm: > Subgroup basic-pci-d3-state: > fail -> PASS (hsw-gt2) > pass -> DMESG-WARN (byt-nuc) Known fail: https://bugs.freedesktop.org/show_bug.cgi?id=93121 I really should simply merge the patch to shut this all up. -Daniel > Subgroup basic-rte: > dmesg-warn -> PASS (bsw-nuc-2) > dmesg-warn -> PASS (byt-nuc) UNSTABLE > > bdw-nuci7total:161 pass:152 dwarn:0 dfail:0 fail:0 skip:9 > bdw-ultratotal:164 pass:152 dwarn:0 dfail:0 fail:0 skip:12 > bsw-nuc-2total:164 pass:136 dwarn:0 dfail:0 fail:0 skip:28 > byt-nuc total:164 pass:140 dwarn:1 dfail:0 fail:0 skip:23 > hsw-brixbox total:164 pass:151 dwarn:0 dfail:0 fail:0 skip:13 > hsw-gt2 total:164 pass:154 dwarn:0 dfail:0 fail:0 skip:10 > ilk-hp8440p total:164 pass:116 dwarn:0 dfail:0 fail:0 skip:48 > ivb-t430stotal:164 pass:150 dwarn:0 dfail:0 fail:0 skip:14 > snb-dellxps total:164 pass:142 dwarn:0 dfail:0 fail:0 skip:22 > snb-x220ttotal:164 pass:142 dwarn:0 dfail:0 fail:1 skip:21 > > Results at /archive/results/CI_IGT_test/Patchwork_1385/ > > d9bd337b4b2d46f73005fcdf0e7049e7f8ed5c04 drm-intel-nightly: > 2016y-02m-09d-15h-42m-46s UTC integration manifest > cb1f5a551af8b6b2f3f75a322a70df5891eee393 drm/i915: Check for get_pages > instead of shmem (filp) > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://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 https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [v2] drm/i915: Check for get_pages instead of shmem (filp)
On Wed, Feb 10, 2016 at 09:39:33AM -0800, Ben Widawsky wrote: > On Wed, Feb 10, 2016 at 04:23:08PM +, Chris Wilson wrote: > > On Wed, Feb 10, 2016 at 07:42:23AM -0800, Ben Widawsky wrote: > > > Do you guys get the CI mails? This version has regressions. v1 did not. I > > > don't > > > know what to trust. > > > > I didn't even see v2 itself! > > > > > On Tue, Feb 09, 2016 at 11:44:12AM -0800, Ben Widawsky wrote: > > > > This behavior of checking for a shmem backed GEM object was introduced > > > > here: > > > > commit 4c914c0c7c787b8f730128a8cdcca9c50b0784ab > > > > Author: Brad Volkin > > > > Date: Tue Feb 18 10:15:45 2014 -0800 > > > > > > > > drm/i915: Refactor shmem pread setup > > > > > > > > It is possible for an object to not be a shmem backed GEM object (for > > > > example > > > > userptr objects). An example of how we hit this failure can be found > > > > through > > > > copy_batch() in the command parser because we allocate a userptr object > > > > for the > > > > batch which contains privileged instructions. Userptr calls > > > > drm_gem_private_object_init() which explicitly sets the filp to none. > > > > > > > > NOTE: I manually retyped this from a test machine. So I haven't even > > > > compiled > > > > this exact patch. > > > > > > > > v2: Use same logic as from a2a4f916c2f (Kristian, Dave Gordon) > > > > > > > > Cc: Chris Wilson > > > > Cc: Kristian Høgsberg > > > > Cc: Dave Gordon > > > > Signed-off-by: Ben Widawsky > > > > Tested-by: Jordan Justen (v1) > > > > Reviewed-by: Jordan Justen (v1) > > > > > > --- > > > > drivers/gpu/drm/i915/i915_gem.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > > > b/drivers/gpu/drm/i915/i915_gem.c > > > > index e9b19bc..7fd79b0 100644 > > > > --- a/drivers/gpu/drm/i915/i915_gem.c > > > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > > > @@ -489,7 +489,7 @@ int i915_gem_obj_prepare_shmem_read(struct > > > > drm_i915_gem_object *obj, > > > > > > > > *needs_clflush = 0; > > > > > > > > - if (!obj->base.filp) > > > > + if (WARN_ON((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) > > > > == 0)) > > > > Don't use WARN_ON, there is code (or will be) where we use > > prepare_shmem_read/write to determine if we can use the shmem paths. > > > > Also i915_gem_obj_prepare_shmem_write() requires the same treatment. > > > > My apologies I had this patch but appear to have accidentally squashed > > it whilst rebasing. Thanks! > > -Chris > > > > So... is someone going to land this fix? We need it. Queued for -next, thanks for the patch. Aside: We have about 15 committers by now, Chris being one of them. No need to hang in there waiting for lazy me to undig myself from the latest CI fire. -Daniel > > -- > Ben Widawsky, Intel Open Source Technology Center > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://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 https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [v2] drm/i915: Check for get_pages instead of shmem (filp)
On 10/02/16 17:39, Ben Widawsky wrote: On Wed, Feb 10, 2016 at 04:23:08PM +, Chris Wilson wrote: On Wed, Feb 10, 2016 at 07:42:23AM -0800, Ben Widawsky wrote: Do you guys get the CI mails? This version has regressions. v1 did not. I don't know what to trust. I didn't even see v2 itself! On Tue, Feb 09, 2016 at 11:44:12AM -0800, Ben Widawsky wrote: This behavior of checking for a shmem backed GEM object was introduced here: commit 4c914c0c7c787b8f730128a8cdcca9c50b0784ab Author: Brad Volkin Date: Tue Feb 18 10:15:45 2014 -0800 drm/i915: Refactor shmem pread setup It is possible for an object to not be a shmem backed GEM object (for example userptr objects). An example of how we hit this failure can be found through copy_batch() in the command parser because we allocate a userptr object for the batch which contains privileged instructions. Userptr calls drm_gem_private_object_init() which explicitly sets the filp to none. NOTE: I manually retyped this from a test machine. So I haven't even compiled this exact patch. v2: Use same logic as from a2a4f916c2f (Kristian, Dave Gordon) Cc: Chris Wilson Cc: Kristian Høgsberg Cc: Dave Gordon Signed-off-by: Ben Widawsky Tested-by: Jordan Justen (v1) Reviewed-by: Jordan Justen (v1) --- drivers/gpu/drm/i915/i915_gem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index e9b19bc..7fd79b0 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -489,7 +489,7 @@ int i915_gem_obj_prepare_shmem_read(struct drm_i915_gem_object *obj, *needs_clflush = 0; - if (!obj->base.filp) + if (WARN_ON((obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE) == 0)) It looks like the above code can't be reached? 'filp' is tested in i915_gem_pread_ioctl(), before i915_gem_obj_prepare_shmem_read() is called! Don't use WARN_ON, there is code (or will be) where we use prepare_shmem_read/write to determine if we can use the shmem paths. Also i915_gem_obj_prepare_shmem_write() requires the same treatment. No such function, but there's a 'filp' test in i915_gem_pwrite_ioctl(). Also, what about i915_gem_mmap_ioctl() ? Is mmap() also going to be legitimate without a file pointer? > My apologies I had this patch but appear to have accidentally squashed it whilst rebasing. Thanks! -Chris So... is someone going to land this fix? We need it. Looks like Chris wants this to read if (!(obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE)) return -EINVAL; leaving it to the caller to decide whether to log a complaint. I'm happy with that. .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3] lib/igt_core.c: Expand --run-subtest functionality.
On 15/02/16 16:55, Daniel Vetter wrote: On Thu, Feb 04, 2016 at 12:06:57PM +, Derek Morton wrote: Added extended wildcard support when specifying --run-subtest. Wildcard format is as specified in rfc3977 and the uwildmat() implementation is taken from libinn. See https://tools.ietf.org/html/rfc3977#section-4 for a description of allowed wildcard expressions. v2: Use comma as list separator (Ville Syrjala) support both ^ and ! as not operators (Dave Gordon) v3: Updated to use uwildmat() (Dave Gordon) Signed-off-by: Derek Morton --- COPYING | 21 +++ lib/Makefile.sources| 2 + lib/igt_core.c | 17 +- lib/uwildmat/uwildmat.c | 474 lib/uwildmat/uwildmat.h | 24 +++ Not really a fan of copying other sources into ours. Don't we have something ready-made that's generally available, or can we at least pull it in as a build-dep? Thanks, Daniel It's a standard, RFC3977. The source is readily available for download, for example from the INN master site https://inn.eyrie.org/trac/browser/trunk/lib/uwildmat.c It seems to be very stable (last change was 2014: "Change Russ' email address"). It *is* already available (in Ubuntu at least), but it's in a fairly obscure package that not many people will have installed. On Ubuntu, /usr/lib/news/libinn.a is part of package 'inn2-dev'; I understand that on some other distros its in a different package (e.g. 'inn-devel' on CentOS). So this is probably why Derek chose to include the source from INN rather than working out how to make it a prerequisite for building i-g-t. And it almost certainly isn't otherwise available for Android! .Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [BUG] HDMI 12bpc causing occasional flickering and blanking
Hello, Since upgrading to the Fedora 4.3 kernel package, the picture on my the BenQ M2700 HD monitor I've got connected to my HP EliteBook Folio 9470m laptop began having issues. The monitor is connected with a DP+-to-HDMI cable (HDMI in the monitor end), and the resolution I'm using is 1920x1080. The symptoms are brief flickers of which looks like a thin horizontal line (or maybe more) overlaying the picture for a very brief period. This is ofte often (but not always) followed by the entire picture going completely black (kind of like when xscreensaver blanks the screen). Usually, the picture returns after maybe a second, but sometimes it remains off for several seconds before returning. It might also be that these blankings happen without a horizontal line flicker having occurred immediately before, thought it's hard to be certain because the flickers are very brief. The laptop's internal screen is not impacted, the picture there remains stable while the external screen is flickering/blanking (including if both screens are set up in xrandr to show the same output). Most of the time the flickers and blankings happens only occasionally, and be just a minor annoyance. However, some times it gets really bad, and the screen spends a majority of the time black - making it impossible to use the system. I have not determined anything that will with 100% certainty cause the symptoms to manifest themselves, but I do have a feeling that it is more likely to happen if the picture is mostly white/bright (e.g., when displaying a web browser window or an application such as gitk), and also after having resumed from suspend. But flickering/blanking certainly does happen if the screen showing mostly black xterms and without having suspended/resumed too. I bisected the problem, which resulted in the following verdict: 7a0baa6234468aa387f9b8a1a79dc2a4b4821f67 is the first bad commit commit 7a0baa6234468aa387f9b8a1a79dc2a4b4821f67 Author: Ville Syrjälä Date: Tue Jun 30 15:33:54 2015 +0300 Revert "drm/i915: Disable 12bpc hdmi for now" HDMI 12bpc should be working fine now. Let it loose. This reverts commit 5e3daaca09f5158eff9c92290faa1d2001ecc6e4. v2: Rebased due to CHV/BXT port clock check improvemnts Signed-off-by: Ville Syrjälä Reviewed-and-tested-by: Imre Deak Signed-off-by: Daniel Vetter I also confirmed that the problem is still present in drm-intel-nightly as of today (8ed1804). I'm currently running 8ed1804 + 7a0baa6 reverted and the symptoms are gone. I've uploaded a kernel logs with drm.debug=0xe here: http://filebin.net/r3nlwu09y2 One file is from when running 8ed1804 (with some comments of when the symptoms occurred added by me), the other file is from right now (running 8ed1804 + 7a0baa6 reverted) - I've not yet experienced any issues since booting the system with this kernel. Tore ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BUG] HDMI 12bpc causing occasional flickering and blanking
On Mon, Feb 15, 2016 at 08:17:23PM +0100, Tore Anderson wrote:
> Hello,
>
> Since upgrading to the Fedora 4.3 kernel package, the picture on my the
> BenQ M2700 HD monitor I've got connected to my HP EliteBook Folio 9470m
> laptop began having issues. The monitor is connected with a DP+-to-HDMI
> cable (HDMI in the monitor end), and the resolution I'm using is
> 1920x1080.
>
> The symptoms are brief flickers of which looks like a thin horizontal
> line (or maybe more) overlaying the picture for a very brief period.
> This is ofte often (but not always) followed by the entire picture
> going completely black (kind of like when xscreensaver blanks the
> screen). Usually, the picture returns after maybe a second, but
> sometimes it remains off for several seconds before returning. It might
> also be that these blankings happen without a horizontal line flicker
> having occurred immediately before, thought it's hard to be certain
> because the flickers are very brief.
>
> The laptop's internal screen is not impacted, the picture there remains
> stable while the external screen is flickering/blanking (including if
> both screens are set up in xrandr to show the same output).
>
> Most of the time the flickers and blankings happens only occasionally,
> and be just a minor annoyance. However, some times it gets really bad,
> and the screen spends a majority of the time black - making it
> impossible to use the system. I have not determined anything that will
> with 100% certainty cause the symptoms to manifest themselves, but I do
> have a feeling that it is more likely to happen if the picture is
> mostly white/bright (e.g., when displaying a web browser window or an
> application such as gitk), and also after having resumed from suspend.
> But flickering/blanking certainly does happen if the screen showing
> mostly black xterms and without having suspended/resumed too.
>
> I bisected the problem, which resulted in the following verdict:
>
> 7a0baa6234468aa387f9b8a1a79dc2a4b4821f67 is the first bad commit
> commit 7a0baa6234468aa387f9b8a1a79dc2a4b4821f67
> Author: Ville Syrjälä
> Date: Tue Jun 30 15:33:54 2015 +0300
>
> Revert "drm/i915: Disable 12bpc hdmi for now"
>
> HDMI 12bpc should be working fine now. Let it loose.
>
> This reverts commit 5e3daaca09f5158eff9c92290faa1d2001ecc6e4.
>
> v2: Rebased due to CHV/BXT port clock check improvemnts
>
> Signed-off-by: Ville Syrjälä
> Reviewed-and-tested-by: Imre Deak
> Signed-off-by: Daniel Vetter
>
> I also confirmed that the problem is still present in drm-intel-nightly
> as of today (8ed1804). I'm currently running 8ed1804 + 7a0baa6 reverted
> and the symptoms are gone.
>
> I've uploaded a kernel logs with drm.debug=0xe here:
>
> http://filebin.net/r3nlwu09y2
>
> One file is from when running 8ed1804 (with some comments of when the symptoms
> occurred added by me), the other file is from right now (running
> 8ed1804 + 7a0baa6 reverted) - I've not yet experienced any issues since
> booting the system with this kernel.
Could you test the following hack while using a 1920x1080 mode with 148.5 MHz
dotclock, and see if there's any improvement?
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4e1321b96522..ea24de873e14 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12842,6 +12842,11 @@ intel_modeset_pipe_config(struct drm_crtc *crtc,
clear_intel_crtc_state(pipe_config);
+ if (pipe_config->base.adjusted_mode.clock == 148500) {
+ DRM_ERROR("adjusting dotclock\n");
+ pipe_config->base.adjusted_mode.clock = 148800;
+ }
+
pipe_config->cpu_transcoder =
(enum transcoder) to_intel_crtc(crtc)->pipe;
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/21] drm/i915: Account for the size of the chroma plane for the rotated gtt view
From: Ville Syrjälä
The size of the rotated ggtt mapping ought to include the size of the
chroma plane as well. Not a huge deal since we don't expose NV12 (or any
pother planar format for that matter) yet.
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Fixes: 9e759ff1f4a0 ("drm/i915: Return correct size for rotated views")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 9127f8f3561c..4ccc8ec7003c 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3636,7 +3636,7 @@ i915_ggtt_view_size(struct drm_i915_gem_object *obj,
if (view->type == I915_GGTT_VIEW_NORMAL) {
return obj->base.size;
} else if (view->type == I915_GGTT_VIEW_ROTATED) {
- return view->params.rotated.size;
+ return view->params.rotated.size + view->params.rotated.size_uv;
} else if (view->type == I915_GGTT_VIEW_PARTIAL) {
return view->params.partial.size << PAGE_SHIFT;
} else {
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 07/21] drm/i915: Reorganize intel_rotation_info
From: Ville Syrjälä
Throw out a bunch of unnecessary stuff from struct intel_rotation_info,
and pull most of the remaining stuff to live under an array of
per-color plane sub-structures.
What still remains outside the sub-structure will be reorgranized later
as well, but that requires more work elsewhere so leave it be for now.
v2: Split the vma size == luma+chroma size fix to prep patch (Daniel)
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter (v1)
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 35 +++
drivers/gpu/drm/i915/i915_gem_gtt.h | 11 ---
drivers/gpu/drm/i915/intel_display.c | 25 +++--
drivers/gpu/drm/i915/intel_drv.h | 1 +
4 files changed, 35 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 4ccc8ec7003c..27a3e17f2882 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3403,7 +3403,7 @@ static struct sg_table *
intel_rotate_fb_obj_pages(struct intel_rotation_info *rot_info,
struct drm_i915_gem_object *obj)
{
- unsigned int size_pages = rot_info->size >> PAGE_SHIFT;
+ unsigned int size_pages = rot_info->plane[0].width *
rot_info->plane[0].height;
unsigned int size_pages_uv;
struct sg_page_iter sg_iter;
unsigned long i;
@@ -3421,7 +3421,7 @@ intel_rotate_fb_obj_pages(struct intel_rotation_info
*rot_info,
/* Account for UV plane with NV12. */
if (rot_info->pixel_format == DRM_FORMAT_NV12)
- size_pages_uv = rot_info->size_uv >> PAGE_SHIFT;
+ size_pages_uv = rot_info->plane[1].width *
rot_info->plane[1].height;
else
size_pages_uv = 0;
@@ -3443,9 +3443,9 @@ intel_rotate_fb_obj_pages(struct intel_rotation_info
*rot_info,
/* Rotate the pages. */
sg = rotate_pages(page_addr_list, 0,
-rot_info->width_pages, rot_info->height_pages,
-rot_info->width_pages,
-st, NULL);
+ rot_info->plane[0].width, rot_info->plane[0].height,
+ rot_info->plane[0].width,
+ st, NULL);
/* Append the UV plane if NV12. */
if (rot_info->pixel_format == DRM_FORMAT_NV12) {
@@ -3457,18 +3457,15 @@ intel_rotate_fb_obj_pages(struct intel_rotation_info
*rot_info,
rot_info->uv_start_page = uv_start_page;
- rotate_pages(page_addr_list, uv_start_page,
-rot_info->width_pages_uv,
-rot_info->height_pages_uv,
-rot_info->width_pages_uv,
+ rotate_pages(page_addr_list, rot_info->uv_start_page,
+rot_info->plane[1].width,
rot_info->plane[1].height,
+rot_info->plane[1].width,
st, sg);
}
- DRM_DEBUG_KMS(
- "Created rotated page mapping for object size %zu
(pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u pages (%u plane
0)).\n",
- obj->base.size, rot_info->pitch, rot_info->height,
- rot_info->pixel_format, rot_info->width_pages,
- rot_info->height_pages, size_pages + size_pages_uv,
+ DRM_DEBUG_KMS("Created rotated page mapping for object size %zu (%ux%u
tiles, %u pages (%u plane 0)).\n",
+ obj->base.size, rot_info->plane[0].width,
+ rot_info->plane[0].height, size_pages + size_pages_uv,
size_pages);
drm_free_large(page_addr_list);
@@ -3480,11 +3477,9 @@ err_sg_alloc:
err_st_alloc:
drm_free_large(page_addr_list);
- DRM_DEBUG_KMS(
- "Failed to create rotated mapping for object size %zu!
(%d) (pitch=%u, height=%u, pixel_format=0x%x, %ux%u tiles, %u pages (%u plane
0))\n",
- obj->base.size, ret, rot_info->pitch, rot_info->height,
- rot_info->pixel_format, rot_info->width_pages,
- rot_info->height_pages, size_pages + size_pages_uv,
+ DRM_DEBUG_KMS("Failed to create rotated mapping for object size %zu!
(%d) (%ux%u tiles, %u pages (%u plane 0))\n",
+ obj->base.size, ret, rot_info->plane[0].width,
+ rot_info->plane[0].height, size_pages + size_pages_uv,
size_pages);
return ERR_PTR(ret);
}
@@ -3636,7 +3631,7 @@ i915_ggtt_view_size(struct drm_i915_gem_object *obj,
if (view->type == I915_GGTT_VIEW_NORMAL) {
return obj->base.size;
} else if (view->type == I915_GGTT_VIEW_ROTATED) {
- return view->params.rotated.size + view->params.rotated.size_uv;
+ return intel_rotation_info_size(&view->params.rotated) <<
PAGE_SHIFT;
} else if (view
[Intel-gfx] [PATCH v3 04/21] drm/i915: Support for extra alignment for tiled surfaces
From: Ville Syrjälä
SKL+ needs >4K alignment for tiled surfaces, so make
intel_compute_page_offset() handle it.
The way we do it is first we compute the closest tile boundary
as before, and then figure out how many tiles we need to go
to reach the desired alignment. The difference in the offset
is then added into the x/y offsets.
v2: Be less confusing wrt. units (pixels vs. bytes) (Daniel)
v3: Use u32 for offsets
Have intel_adjust_tile_offset() return the new offset (will be
useful later)
Add an offset_aligned variable (Daniel)
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 50
1 file changed, 45 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index dcf379c29523..fe8d534a3334 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2461,6 +2461,35 @@ static void intel_unpin_fb_obj(struct drm_framebuffer
*fb,
}
/*
+ * Adjust the tile offset by moving the difference into
+ * the x/y offsets.
+ *
+ * Input tile dimensions and pitch must already be
+ * rotated to match x and y, and in pixel units.
+ */
+static u32 intel_adjust_tile_offset(int *x, int *y,
+ unsigned int tile_width,
+ unsigned int tile_height,
+ unsigned int tile_size,
+ unsigned int pitch_tiles,
+ u32 old_offset,
+ u32 new_offset)
+{
+ unsigned int tiles;
+
+ WARN_ON(old_offset & (tile_size - 1));
+ WARN_ON(new_offset & (tile_size - 1));
+ WARN_ON(new_offset > old_offset);
+
+ tiles = (old_offset - new_offset) / tile_size;
+
+ *y += tiles / pitch_tiles * tile_height;
+ *x += tiles % pitch_tiles * tile_width;
+
+ return new_offset;
+}
+
+/*
* Computes the linear offset to the base tile and adjusts
* x, y. bytes per pixel is assumed to be a power-of-two.
*
@@ -2475,6 +2504,12 @@ u32 intel_compute_tile_offset(struct drm_i915_private
*dev_priv,
unsigned int pitch,
unsigned int rotation)
{
+ u32 offset, offset_aligned, alignment;
+
+ alignment = intel_surf_alignment(dev_priv, fb_modifier);
+ if (alignment)
+ alignment--;
+
if (fb_modifier != DRM_FORMAT_MOD_NONE) {
unsigned int tile_size, tile_width, tile_height;
unsigned int tile_rows, tiles, pitch_tiles;
@@ -2496,16 +2531,21 @@ u32 intel_compute_tile_offset(struct drm_i915_private
*dev_priv,
tiles = *x / tile_width;
*x %= tile_width;
- return (tile_rows * pitch_tiles + tiles) * tile_size;
- } else {
- unsigned int alignment = intel_linear_alignment(dev_priv) - 1;
- unsigned int offset;
+ offset = (tile_rows * pitch_tiles + tiles) * tile_size;
+ offset_aligned = offset & ~alignment;
+ intel_adjust_tile_offset(x, y, tile_width, tile_height,
+tile_size, pitch_tiles,
+offset, offset_aligned);
+ } else {
offset = *y * pitch + *x * cpp;
+ offset_aligned = offset & ~alignment;
+
*y = (offset & alignment) / pitch;
*x = ((offset & alignment) - *y * pitch) / cpp;
- return offset & ~alignment;
}
+
+ return offset_aligned;
}
static int i9xx_format_to_fourcc(int format)
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/21] drm/i915: s/tile_width/tile_width_bytes/
From: Ville Syrjälä
Make if clear whether we're talking tile widths in bytes or in pixels.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4d30bca0b26b..acc632c06135 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -,8 +,8 @@ static unsigned int intel_tile_size(const struct
drm_i915_private *dev_priv)
return IS_GEN2(dev_priv) ? 2048 : 4096;
}
-static unsigned int intel_tile_width(const struct drm_i915_private *dev_priv,
-uint64_t fb_modifier, unsigned int cpp)
+static unsigned int intel_tile_width_bytes(const struct drm_i915_private
*dev_priv,
+ uint64_t fb_modifier, unsigned int
cpp)
{
switch (fb_modifier) {
case DRM_FORMAT_MOD_NONE:
@@ -2266,7 +2266,7 @@ unsigned int intel_tile_height(const struct
drm_i915_private *dev_priv,
return 1;
else
return intel_tile_size(dev_priv) /
- intel_tile_width(dev_priv, fb_modifier, cpp);
+ intel_tile_width_bytes(dev_priv, fb_modifier, cpp);
}
unsigned int
@@ -2285,7 +2285,7 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view *view,
struct drm_framebuffer *fb,
{
struct drm_i915_private *dev_priv = to_i915(fb->dev);
struct intel_rotation_info *info = &view->params.rotated;
- unsigned int tile_size, tile_width, tile_height, cpp;
+ unsigned int tile_size, tile_width_bytes, tile_height, cpp;
*view = i915_ggtt_view_normal;
@@ -2306,19 +2306,19 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view *view,
struct drm_framebuffer *fb,
tile_size = intel_tile_size(dev_priv);
cpp = drm_format_plane_cpp(fb->pixel_format, 0);
- tile_width = intel_tile_width(dev_priv, fb->modifier[0], cpp);
- tile_height = tile_size / tile_width;
+ tile_width_bytes = intel_tile_width_bytes(dev_priv, fb->modifier[0],
cpp);
+ tile_height = tile_size / tile_width_bytes;
- info->width_pages = DIV_ROUND_UP(fb->pitches[0], tile_width);
+ info->width_pages = DIV_ROUND_UP(fb->pitches[0], tile_width_bytes);
info->height_pages = DIV_ROUND_UP(fb->height, tile_height);
info->size = info->width_pages * info->height_pages * tile_size;
if (info->pixel_format == DRM_FORMAT_NV12) {
cpp = drm_format_plane_cpp(fb->pixel_format, 1);
- tile_width = intel_tile_width(dev_priv, fb->modifier[1], cpp);
- tile_height = tile_size / tile_width;
+ tile_width_bytes = intel_tile_width_bytes(dev_priv,
fb->modifier[1], cpp);
+ tile_height = tile_size / tile_width_bytes;
- info->width_pages_uv = DIV_ROUND_UP(fb->pitches[1], tile_width);
+ info->width_pages_uv = DIV_ROUND_UP(fb->pitches[1],
tile_width_bytes);
info->height_pages_uv = DIV_ROUND_UP(fb->height / 2,
tile_height);
info->size_uv = info->width_pages_uv * info->height_pages_uv *
tile_size;
}
@@ -2455,18 +2455,18 @@ u32 intel_compute_tile_offset(struct drm_i915_private
*dev_priv,
unsigned int pitch)
{
if (fb_modifier != DRM_FORMAT_MOD_NONE) {
- unsigned int tile_size, tile_width, tile_height;
+ unsigned int tile_size, tile_width_bytes, tile_height;
unsigned int tile_rows, tiles;
tile_size = intel_tile_size(dev_priv);
- tile_width = intel_tile_width(dev_priv, fb_modifier, cpp);
- tile_height = tile_size / tile_width;
+ tile_width_bytes = intel_tile_width_bytes(dev_priv,
fb_modifier, cpp);
+ tile_height = tile_size / tile_width_bytes;
tile_rows = *y / tile_height;
*y %= tile_height;
- tiles = *x / (tile_width/cpp);
- *x %= tile_width/cpp;
+ tiles = *x / (tile_width_bytes/cpp);
+ *x %= tile_width_bytes/cpp;
return tile_rows * pitch * tile_height + tiles * tile_size;
} else {
@@ -2928,7 +2928,7 @@ u32 intel_fb_stride_alignment(const struct
drm_i915_private *dev_priv,
} else {
int cpp = drm_format_plane_cpp(pixel_format, 0);
- return intel_tile_width(dev_priv, fb_modifier, cpp);
+ return intel_tile_width_bytes(dev_priv, fb_modifier, cpp);
}
}
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 03/21] drm/i915: Pass 90/270 vs. 0/180 rotation info for intel_gen4_compute_page_offset()
From: Ville Syrjälä
The page aligned surface address calculation needs to know which way
things are rotated. The contract now says that the caller must pass the
rotate x/y coordinates, as well as the tile_height aligned stride in
the tile_height direction. This will make it fairly simple to deal with
90/270 degree rotation on SKL+ where we have to deal with the rotated
view into the GTT.
v2: Pass rotation instead of bool even thoughwe only care about 0/180 vs. 90/270
v3: Introduce intel_tile_dims(), and don't mix up different units so much
v4: Unconfuse bytes vs. pixels even more
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 72 +---
drivers/gpu/drm/i915/intel_drv.h | 3 +-
drivers/gpu/drm/i915/intel_sprite.c | 18 +
3 files changed, 63 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index acc632c06135..dcf379c29523 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2269,6 +2269,20 @@ unsigned int intel_tile_height(const struct
drm_i915_private *dev_priv,
intel_tile_width_bytes(dev_priv, fb_modifier, cpp);
}
+/* Return the tile dimensions in pixel units */
+static void intel_tile_dims(const struct drm_i915_private *dev_priv,
+ unsigned int *tile_width,
+ unsigned int *tile_height,
+ uint64_t fb_modifier,
+ unsigned int cpp)
+{
+ unsigned int tile_width_bytes =
+ intel_tile_width_bytes(dev_priv, fb_modifier, cpp);
+
+ *tile_width = tile_width_bytes / cpp;
+ *tile_height = intel_tile_size(dev_priv) / tile_width_bytes;
+}
+
unsigned int
intel_fb_align_height(struct drm_device *dev, unsigned int height,
uint32_t pixel_format, uint64_t fb_modifier)
@@ -2285,7 +2299,7 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view *view,
struct drm_framebuffer *fb,
{
struct drm_i915_private *dev_priv = to_i915(fb->dev);
struct intel_rotation_info *info = &view->params.rotated;
- unsigned int tile_size, tile_width_bytes, tile_height, cpp;
+ unsigned int tile_size, tile_width, tile_height, cpp;
*view = i915_ggtt_view_normal;
@@ -2306,19 +2320,19 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view *view,
struct drm_framebuffer *fb,
tile_size = intel_tile_size(dev_priv);
cpp = drm_format_plane_cpp(fb->pixel_format, 0);
- tile_width_bytes = intel_tile_width_bytes(dev_priv, fb->modifier[0],
cpp);
- tile_height = tile_size / tile_width_bytes;
+ intel_tile_dims(dev_priv, &tile_width, &tile_height,
+ fb->modifier[0], cpp);
- info->width_pages = DIV_ROUND_UP(fb->pitches[0], tile_width_bytes);
+ info->width_pages = DIV_ROUND_UP(fb->pitches[0], tile_width * cpp);
info->height_pages = DIV_ROUND_UP(fb->height, tile_height);
info->size = info->width_pages * info->height_pages * tile_size;
if (info->pixel_format == DRM_FORMAT_NV12) {
cpp = drm_format_plane_cpp(fb->pixel_format, 1);
- tile_width_bytes = intel_tile_width_bytes(dev_priv,
fb->modifier[1], cpp);
- tile_height = tile_size / tile_width_bytes;
+ intel_tile_dims(dev_priv, &tile_width, &tile_height,
+ fb->modifier[1], cpp);
- info->width_pages_uv = DIV_ROUND_UP(fb->pitches[1],
tile_width_bytes);
+ info->width_pages_uv = DIV_ROUND_UP(fb->pitches[1], tile_width
* cpp);
info->height_pages_uv = DIV_ROUND_UP(fb->height / 2,
tile_height);
info->size_uv = info->width_pages_uv * info->height_pages_uv *
tile_size;
}
@@ -2446,29 +2460,43 @@ static void intel_unpin_fb_obj(struct drm_framebuffer
*fb,
i915_gem_object_unpin_from_display_plane(obj, &view);
}
-/* Computes the linear offset to the base tile and adjusts x, y. bytes per
pixel
- * is assumed to be a power-of-two. */
+/*
+ * Computes the linear offset to the base tile and adjusts
+ * x, y. bytes per pixel is assumed to be a power-of-two.
+ *
+ * In the 90/270 rotated case, x and y are assumed
+ * to be already rotated to match the rotated GTT view, and
+ * pitch is the tile_height aligned framebuffer height.
+ */
u32 intel_compute_tile_offset(struct drm_i915_private *dev_priv,
int *x, int *y,
uint64_t fb_modifier,
unsigned int cpp,
- unsigned int pitch)
+ unsigned int pitch,
+ unsigned int rotation)
{
if (fb_modifier != DRM_FORMAT_MOD_NONE) {
- unsigned int tile_size, tile_width_bytes, tile_height;
- unsigned int tile_rows, tiles;
+
[Intel-gfx] [PATCH v3 11/21] drm/i915: Don't pass pitch to intel_compute_page_offset()
From: Ville Syrjälä
intel_compute_page_offset() can dig up the correct pitch from the fb
itself, no need for the caller to pass it in.
A bit of extra care is needed for the lower level
_intel_compute_page_offset() since that one gets called before the
rotated pitch under intel_fb is populated. Note that we don't actually
call it with anything but DRM_ROTATE_0 there so we wouldn't actually
look up the rotated pitch there, but still, leave the pitch as something
the caller has to pass to _intel_compute_page_offset() as an
indicator that something is a bit special.
This leaves 'stride_div' in the skl plane update hooks as a mostly useless
variable so just get rid of it.
v2: Add a note why stride_div got nuked
v3: Extract intel_fb_pitch() since it can be useful later
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter (v2)
---
drivers/gpu/drm/i915/intel_display.c | 34 --
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_sprite.c | 26 +++---
3 files changed, 31 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index acd92f957054..1561923906a1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2437,6 +2437,15 @@ static void intel_unpin_fb_obj(struct drm_framebuffer
*fb, unsigned int rotation
i915_gem_object_unpin_from_display_plane(obj, &view);
}
+static int intel_fb_pitch(const struct drm_framebuffer *fb, int plane,
+ unsigned int rotation)
+{
+ if (intel_rotation_90_or_270(rotation))
+ return to_intel_framebuffer(fb)->rotated[plane].pitch;
+ else
+ return fb->pitches[plane];
+}
+
/*
* Convert the x/y offsets into a linear offset.
* Only valid with 0/180 degree rotation, which is fine since linear
@@ -2570,11 +2579,11 @@ static u32 _intel_compute_tile_offset(const struct
drm_i915_private *dev_priv,
u32 intel_compute_tile_offset(int *x, int *y,
const struct drm_framebuffer *fb, int plane,
- unsigned int pitch,
unsigned int rotation)
{
const struct drm_i915_private *dev_priv = to_i915(fb->dev);
u32 alignment = intel_surf_alignment(dev_priv, fb->modifier[plane]);
+ int pitch = intel_fb_pitch(fb, plane, rotation);
return _intel_compute_tile_offset(dev_priv, x, y, fb, plane, pitch,
rotation, alignment);
@@ -3000,8 +3009,7 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
if (INTEL_INFO(dev)->gen >= 4)
intel_crtc->dspaddr_offset =
- intel_compute_tile_offset(&x, &y, fb, 0,
- fb->pitches[0], rotation);
+ intel_compute_tile_offset(&x, &y, fb, 0, rotation);
if (rotation == BIT(DRM_ROTATE_180)) {
dspcntr |= DISPPLANE_ROTATE_180;
@@ -3103,8 +3111,7 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
intel_add_fb_offsets(&x, &y, fb, 0, rotation);
intel_crtc->dspaddr_offset =
- intel_compute_tile_offset(&x, &y, fb, 0,
- fb->pitches[0], rotation);
+ intel_compute_tile_offset(&x, &y, fb, 0, rotation);
if (rotation == BIT(DRM_ROTATE_180)) {
dspcntr |= DISPPLANE_ROTATE_180;
@@ -3275,7 +3282,7 @@ static void skylake_update_primary_plane(struct drm_plane
*plane,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
int pipe = intel_crtc->pipe;
- u32 plane_ctl, stride_div, stride;
+ u32 plane_ctl, stride;
unsigned int rotation = plane_state->base.rotation;
u32 surf_addr;
int scaler_id = plane_state->scaler_id;
@@ -3315,17 +3322,16 @@ static void skylake_update_primary_plane(struct
drm_plane *plane,
src_w = drm_rect_width(&r);
src_h = drm_rect_height(&r);
- stride_div = intel_tile_height(dev_priv, fb->modifier[0], cpp);
- stride = intel_fb->rotated[0].pitch;
+ stride = intel_fb->rotated[0].pitch /
+ intel_tile_height(dev_priv, fb->modifier[0], cpp);
} else {
- stride_div = intel_fb_stride_alignment(dev_priv,
fb->modifier[0],
- fb->pixel_format);
- stride = fb->pitches[0];
+ stride = fb->pitches[0] /
+ intel_fb_stride_alignment(dev_priv, fb->modifier[0],
+ fb->pixel_format);
}
intel_add_fb_offsets(&src_x, &src_y, fb, 0, rotation);
- surf_addr = intel_compute_tile_offset(&src_x,
[Intel-gfx] [PATCH v4 10/21] drm/i915: Rewrite fb rotation GTT handling
From: Ville Syrjälä
Redo the fb rotation handling in order to:
- eliminate the NV12 special casing
- handle fb->offsets[] properly
- make the rotation handling reasier for the plane code
To achieve these goals we reduce intel_rotation_info to only contain
(for each plane) the rotated view width,height,stride in tile units,
and the page offset into the object where the plane starts. Each plane
is handled exactly the same way, no special casing for NV12 or other
formats. We then store the computed rotation_info under
intel_framebuffer so that we don't have to recompute it again.
To handle fb->offsets[] we treat them as a linear offsets and convert
them to x/y offsets from the start of the relevant GTT mapping (either
normal or rotated). We store the x/y offsets under intel_framebuffer,
and for some extra convenience we also store the rotated pitch (ie.
tile aligned plane height). So for each plane we have the normal
x/y offsets, rotated x/y offsets, and the rotated pitch. The normal
pitch is available already in fb->pitches[].
While we're gathering up all that extra information, we can also easily
compute the storage requirements for the framebuffer, so that we can
check that the object is big enough to hold it.
When it comes time to deal with the plane source coordinates, we first
rotate the clipped src coordinates to match the relevant GTT view
orientation, then add to them the fb x/y offsets. Next we compute
the aligned surface page offset, and as a result we're left with some
residual x/y offsets. Finally, if required by the hardware, we convert
the remaining x/y offsets into a linear offset.
For gen2/3 we simply skip computing the final page offset, and just
convert the src+fb x/y offsets directly into a linear offset since
that's what the hardware wants.
After this all platforms, incluing SKL+, compute these things in exactly
the same way (excluding alignemnt differences).
v2: Use BIT(DRM_ROTATE_270) instead of ROTATE_270 when rotating
plane src coordinates
Drop some spurious changes that got left behind during
development
v3: Split out more changes to prep patches (Daniel)
s/intel_fb->plane[].foo.bar/intel_fb->foo[].bar/ for brevity
Rename intel_surf_gtt_offset to intel_fb_gtt_offset
Kill the pointless 'plane' parameter from intel_fb_gtt_offset()
v4: Fix alignment vs. alignment-1 when calling
_intel_compute_tile_offset() from intel_fill_fb_info()
Pass the pitch in tiles in
stad of pixels to intel_adjust_tile_offset() from intel_fill_fb_info()
Pass the full width/height of the rotated area to
drm_rect_rotate() for clarity
Use u32 for more offsets
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 51 ++---
drivers/gpu/drm/i915/i915_gem_gtt.h | 5 +-
drivers/gpu/drm/i915/intel_display.c | 373 +++
drivers/gpu/drm/i915/intel_drv.h | 19 +-
drivers/gpu/drm/i915/intel_sprite.c | 97 -
5 files changed, 331 insertions(+), 214 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 51f2597e3c56..5b17944a512b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3395,16 +3395,14 @@ rotate_pages(const dma_addr_t *in, unsigned int offset,
}
static struct sg_table *
-intel_rotate_fb_obj_pages(struct intel_rotation_info *rot_info,
+intel_rotate_fb_obj_pages(const struct intel_rotation_info *rot_info,
struct drm_i915_gem_object *obj)
{
- unsigned int size_pages = rot_info->plane[0].width *
rot_info->plane[0].height;
- unsigned int size_pages_uv;
+ unsigned int size = intel_rotation_info_size(rot_info);
struct sg_page_iter sg_iter;
unsigned long i;
dma_addr_t *page_addr_list;
struct sg_table *st;
- unsigned int uv_start_page;
struct scatterlist *sg;
int ret = -ENOMEM;
@@ -3414,18 +3412,12 @@ intel_rotate_fb_obj_pages(struct intel_rotation_info
*rot_info,
if (!page_addr_list)
return ERR_PTR(ret);
- /* Account for UV plane with NV12. */
- if (rot_info->pixel_format == DRM_FORMAT_NV12)
- size_pages_uv = rot_info->plane[1].width *
rot_info->plane[1].height;
- else
- size_pages_uv = 0;
-
/* Allocate target SG list. */
st = kmalloc(sizeof(*st), GFP_KERNEL);
if (!st)
goto err_st_alloc;
- ret = sg_alloc_table(st, size_pages + size_pages_uv, GFP_KERNEL);
+ ret = sg_alloc_table(st, size, GFP_KERNEL);
if (ret)
goto err_sg_alloc;
@@ -3439,32 +3431,14 @@ intel_rotate_fb_obj_pages(struct intel_rotation_info
*rot_info,
st->nents = 0;
sg = st->sgl;
- /* Rotate the pages. */
- sg = rotate_pages(page_addr_list, 0,
- rot_info->plane[0].width, rot_info->plane[0].height,
- rot_info->
[Intel-gfx] [PATCH 12/21] drm/i915: Move SKL hw stride calculation into a helper
From: Ville Syrjälä
We repeat the SKL stride register value calculations a several places.
Move it into a small helper function.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 52 +---
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_sprite.c | 12 ++---
3 files changed, 29 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 1561923906a1..66794681b2ba 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3192,6 +3192,28 @@ static void skl_detach_scalers(struct intel_crtc
*intel_crtc)
}
}
+u32 skl_plane_stride(const struct drm_framebuffer *fb, int plane,
+unsigned int rotation)
+{
+ const struct drm_i915_private *dev_priv = to_i915(fb->dev);
+ u32 stride = intel_fb_pitch(fb, plane, rotation);
+
+ /*
+* The stride is either expressed as a multiple of 64 bytes chunks for
+* linear buffers or in number of tiles for tiled buffers.
+*/
+ if (intel_rotation_90_or_270(rotation)) {
+ int cpp = drm_format_plane_cpp(fb->pixel_format, plane);
+
+ stride /= intel_tile_height(dev_priv, fb->modifier[0], cpp);
+ } else {
+ stride /= intel_fb_stride_alignment(dev_priv, fb->modifier[0],
+ fb->pixel_format);
+ }
+
+ return stride;
+}
+
u32 skl_plane_ctl_format(uint32_t pixel_format)
{
switch (pixel_format) {
@@ -3282,8 +3304,9 @@ static void skylake_update_primary_plane(struct drm_plane
*plane,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
int pipe = intel_crtc->pipe;
- u32 plane_ctl, stride;
+ u32 plane_ctl;
unsigned int rotation = plane_state->base.rotation;
+ u32 stride = skl_plane_stride(fb, 0, rotation);
u32 surf_addr;
int scaler_id = plane_state->scaler_id;
int src_x = plane_state->src.x1 >> 16;
@@ -3311,8 +3334,6 @@ static void skylake_update_primary_plane(struct drm_plane
*plane,
.y1 = src_y,
.y2 = src_y + src_h,
};
- int cpp = drm_format_plane_cpp(fb->pixel_format, 0);
- struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
/* Rotate src coordinates to match rotated GTT view */
drm_rect_rotate(&r, fb->width, fb->height, BIT(DRM_ROTATE_270));
@@ -3321,13 +3342,6 @@ static void skylake_update_primary_plane(struct
drm_plane *plane,
src_y = r.y1;
src_w = drm_rect_width(&r);
src_h = drm_rect_height(&r);
-
- stride = intel_fb->rotated[0].pitch /
- intel_tile_height(dev_priv, fb->modifier[0], cpp);
- } else {
- stride = fb->pitches[0] /
- intel_fb_stride_alignment(dev_priv, fb->modifier[0],
- fb->pixel_format);
}
intel_add_fb_offsets(&src_x, &src_y, fb, 0, rotation);
@@ -11542,7 +11556,7 @@ static void skl_do_mmio_flip(struct intel_crtc
*intel_crtc,
struct drm_i915_private *dev_priv = dev->dev_private;
struct drm_framebuffer *fb = intel_crtc->base.primary->fb;
const enum pipe pipe = intel_crtc->pipe;
- u32 ctl, stride;
+ u32 ctl, stride = skl_plane_stride(fb, 0, rotation);
ctl = I915_READ(PLANE_CTL(pipe, 0));
ctl &= ~PLANE_CTL_TILED_MASK;
@@ -11563,22 +11577,6 @@ static void skl_do_mmio_flip(struct intel_crtc
*intel_crtc,
}
/*
-* The stride is either expressed as a multiple of 64 bytes chunks for
-* linear buffers or in number of tiles for tiled buffers.
-*/
- if (intel_rotation_90_or_270(rotation)) {
- int cpp = drm_format_plane_cpp(fb->pixel_format, 0);
- struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
-
- stride = intel_fb->rotated[0].pitch /
- intel_tile_height(dev_priv, fb->modifier[0], cpp);
- } else {
- stride = fb->pitches[0] /
- intel_fb_stride_alignment(dev_priv, fb->modifier[0],
- fb->pixel_format);
- }
-
- /*
* Both PLANE_CTL and PLANE_STRIDE are not updated on vblank but on
* PLANE_SURF updates, the update is then guaranteed to be atomic.
*/
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 40cbe5c6163c..a32470acf529 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1236,6 +1236,8 @@ u32 intel_fb_gtt_offset(struct drm_framebuffer *fb,
unsigned int rotation)
[Intel-gfx] [PATCH v3 00/21] drm/i915: Handle fb->offsets[] and rewrite fb rotation handling to be more generic (v3)
From: Ville Syrjälä Another iteration of the fb offset stuff. Unfortunately this seems to be one of those things that just keeps on growing when you're not looking. But I'm hoping we're starting to approach the limit. Changes from the last time [1]: * split the chrome plane vma size fix from one of the other patches * shuffling the bytes vs. pixels vs. tiles stuff around * extracted a few more pieces of common code * deal with fence vs. fb offset alignment better * deal with SKL X-tile fail * add preliminary NV12 AUX_DIST handling * possible something else I've forgotten I also have a few testcases lying around somewhere, but I'll need to clean those up somewhat before I post them. Entire lot (+ a few extras on top) available here: git://github.com/vsyrjala/linux.git fb_offsets_14 [1] https://lists.freedesktop.org/archives/intel-gfx/2016-January/085802.html Ville Syrjälä (21): drm/i915: Account for the size of the chroma plane for the rotated gtt view drm/i915: s/tile_width/tile_width_bytes/ drm/i915: Pass 90/270 vs. 0/180 rotation info for intel_gen4_compute_page_offset() drm/i915: Support for extra alignment for tiled surfaces drm/i915: Don't pass plane+plane_state to intel_pin_and_fence_fb_obj() drm/i915: Pass drm_frambuffer to intel_compute_page_offset() drm/i915: Reorganize intel_rotation_info drm/i915: Move the NULL sg handling out from rotate_pages() drm/i915: Embed rotation_info under intel_framebuffer drm/i915: Rewrite fb rotation GTT handling drm/i915: Don't pass pitch to intel_compute_page_offset() drm/i915: Move SKL hw stride calculation into a helper drm/i915: Pass around plane_state instead of fb+rotation drm/i915: Use fb modifiers for display tiling decisions drm/i915: Adjust obj tiling vs. fb modifier rules drm/i915: Limit fb x offset due to fences drm/i915: Allow calling intel_adjust_tile_offset() multiple times drm/i915: Make intel_adjust_tile_offset() work for linear buffers drm/i915: Compute display surface offset in the plane check hook for SKL+ drm/i915: Deal with NV12 CbCr plane AUX surface on SKL+ drm/i915: Make sure fb offset is (macro)pixel aligned drivers/gpu/drm/i915/i915_gem_gtt.c | 64 +-- drivers/gpu/drm/i915/i915_gem_gtt.h | 14 +- drivers/gpu/drm/i915/intel_display.c | 924 +++ drivers/gpu/drm/i915/intel_drv.h | 44 +- drivers/gpu/drm/i915/intel_fbdev.c | 2 +- drivers/gpu/drm/i915/intel_sprite.c | 126 ++--- 6 files changed, 812 insertions(+), 362 deletions(-) -- 2.4.10 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/21] drm/i915: Use fb modifiers for display tiling decisions
From: Ville Syrjälä
Soon the fence tiling mode may not always match the fb modifier
even for X tiled buffers. So let's use the fb modifier
consistently for all display tiling decisions.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 33 ++---
drivers/gpu/drm/i915/intel_sprite.c | 15 ++-
2 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 5f60fe0214e1..733bd68d2e01 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2606,6 +2606,18 @@ static void intel_fb_offset_to_xy(int *x, int *y,
*x = linear_offset % pitch / cpp;
}
+static unsigned int intel_fb_modifier_to_tiling(uint64_t fb_modifier)
+{
+ switch (fb_modifier) {
+ case I915_FORMAT_MOD_X_TILED:
+ return I915_TILING_X;
+ case I915_FORMAT_MOD_Y_TILED:
+ return I915_TILING_Y;
+ default:
+ return I915_TILING_NONE;
+ }
+}
+
static int
intel_fill_fb_info(struct drm_i915_private *dev_priv,
struct drm_framebuffer *fb)
@@ -3004,7 +3016,7 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
}
if (INTEL_INFO(dev)->gen >= 4 &&
- obj->tiling_mode != I915_TILING_NONE)
+ fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
dspcntr |= DISPPLANE_TILED;
if (IS_G4X(dev))
@@ -3069,7 +3081,6 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
- struct drm_i915_gem_object *obj = intel_fb_obj(fb);
int plane = intel_crtc->plane;
u32 linear_offset;
u32 dspcntr;
@@ -3107,7 +3118,7 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
BUG();
}
- if (obj->tiling_mode != I915_TILING_NONE)
+ if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
dspcntr |= DISPPLANE_TILED;
if (!IS_HASWELL(dev) && !IS_BROADWELL(dev))
@@ -11377,7 +11388,7 @@ static int intel_gen4_queue_flip(struct drm_device *dev,
MI_DISPLAY_FLIP_PLANE(intel_crtc->plane));
intel_ring_emit(ring, fb->pitches[0]);
intel_ring_emit(ring, intel_crtc->unpin_work->gtt_offset |
- obj->tiling_mode);
+ intel_fb_modifier_to_tiling(fb->modifier[0]));
/* XXX Enabling the panel-fitter across page-flip is so far
* untested on non-native modes, so ignore it for now.
@@ -11410,7 +11421,8 @@ static int intel_gen6_queue_flip(struct drm_device *dev,
intel_ring_emit(ring, MI_DISPLAY_FLIP |
MI_DISPLAY_FLIP_PLANE(intel_crtc->plane));
- intel_ring_emit(ring, fb->pitches[0] | obj->tiling_mode);
+ intel_ring_emit(ring, fb->pitches[0] |
+ intel_fb_modifier_to_tiling(fb->modifier[0]));
intel_ring_emit(ring, intel_crtc->unpin_work->gtt_offset);
/* Contrary to the suggestions in the documentation,
@@ -11514,7 +11526,8 @@ static int intel_gen7_queue_flip(struct drm_device *dev,
}
intel_ring_emit(ring, MI_DISPLAY_FLIP_I915 | plane_bit);
- intel_ring_emit(ring, (fb->pitches[0] | obj->tiling_mode));
+ intel_ring_emit(ring, fb->pitches[0] |
+ intel_fb_modifier_to_tiling(fb->modifier[0]));
intel_ring_emit(ring, intel_crtc->unpin_work->gtt_offset);
intel_ring_emit(ring, (MI_NOOP));
@@ -11597,15 +11610,13 @@ static void ilk_do_mmio_flip(struct intel_crtc
*intel_crtc,
{
struct drm_device *dev = intel_crtc->base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_framebuffer *intel_fb =
- to_intel_framebuffer(intel_crtc->base.primary->fb);
- struct drm_i915_gem_object *obj = intel_fb->obj;
+ struct drm_framebuffer *fb = intel_crtc->base.primary->fb;
i915_reg_t reg = DSPCNTR(intel_crtc->plane);
u32 dspcntr;
dspcntr = I915_READ(reg);
- if (obj->tiling_mode != I915_TILING_NONE)
+ if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED)
dspcntr |= DISPPLANE_TILED;
else
dspcntr &= ~DISPPLANE_TILED;
@@ -11870,7 +11881,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev)) {
ring = &dev_priv->ring[BCS];
- if (obj->tiling_mode != intel_fb_obj(work->old_fb)->tiling_mode)
+ if (fb->modifier[0] != old_fb->modifier[0])
/* vlv: DISPLAY_FLIP fails to change tiling */
ring = NULL;
} else if (IS_IVYBRIDGE(dev) || IS_HASWEL
[Intel-gfx] [PATCH v2 05/21] drm/i915: Don't pass plane+plane_state to intel_pin_and_fence_fb_obj()
From: Ville Syrjälä
intel_pin_and_fence_fb_obj() only needs the framebuffer, and the desird
rotation (to find the right GTT view for it), so no need to pass all
kinds of plane stuff.
The main motivation is to get rid of the uggy NULL plane_state handling
due to fbdev.
v2: Add a note why I really want this
Signed-off-by: Ville Syrjälä
Grumpily-Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 41 +++-
drivers/gpu/drm/i915/intel_drv.h | 5 ++---
drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
3 files changed, 20 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index fe8d534a3334..15634d9cb666 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2294,8 +2294,9 @@ intel_fb_align_height(struct drm_device *dev, unsigned
int height,
}
static void
-intel_fill_fb_ggtt_view(struct i915_ggtt_view *view, struct drm_framebuffer
*fb,
- const struct drm_plane_state *plane_state)
+intel_fill_fb_ggtt_view(struct i915_ggtt_view *view,
+ const struct drm_framebuffer *fb,
+ unsigned int rotation)
{
struct drm_i915_private *dev_priv = to_i915(fb->dev);
struct intel_rotation_info *info = &view->params.rotated;
@@ -2303,10 +2304,7 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view *view,
struct drm_framebuffer *fb,
*view = i915_ggtt_view_normal;
- if (!plane_state)
- return;
-
- if (!intel_rotation_90_or_270(plane_state->rotation))
+ if (!intel_rotation_90_or_270(rotation))
return;
*view = i915_ggtt_view_rotated;
@@ -2371,9 +2369,8 @@ static unsigned int intel_surf_alignment(const struct
drm_i915_private *dev_priv
}
int
-intel_pin_and_fence_fb_obj(struct drm_plane *plane,
- struct drm_framebuffer *fb,
- const struct drm_plane_state *plane_state)
+intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
+ unsigned int rotation)
{
struct drm_device *dev = fb->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -2386,7 +2383,7 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
alignment = intel_surf_alignment(dev_priv, fb->modifier[0]);
- intel_fill_fb_ggtt_view(&view, fb, plane_state);
+ intel_fill_fb_ggtt_view(&view, fb, rotation);
/* Note that the w/a also requires 64 PTE of padding following the
* bo. We currently fill all unused PTE with the shadow page and so
@@ -2444,15 +2441,14 @@ err_pm:
return ret;
}
-static void intel_unpin_fb_obj(struct drm_framebuffer *fb,
- const struct drm_plane_state *plane_state)
+static void intel_unpin_fb_obj(struct drm_framebuffer *fb, unsigned int
rotation)
{
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
struct i915_ggtt_view view;
WARN_ON(!mutex_is_locked(&obj->base.dev->struct_mutex));
- intel_fill_fb_ggtt_view(&view, fb, plane_state);
+ intel_fill_fb_ggtt_view(&view, fb, rotation);
if (view.type == I915_GGTT_VIEW_NORMAL)
i915_gem_object_unpin_fence(obj);
@@ -3011,7 +3007,7 @@ u32 intel_plane_obj_offset(struct intel_plane
*intel_plane,
u64 offset;
intel_fill_fb_ggtt_view(&view, intel_plane->base.state->fb,
- intel_plane->base.state);
+ intel_plane->base.state->rotation);
vma = i915_gem_obj_to_ggtt_view(obj, &view);
if (WARN(!vma, "ggtt vma for display object not found! (view=%u)\n",
@@ -10980,7 +10976,7 @@ static void intel_unpin_work_fn(struct work_struct
*__work)
struct drm_plane *primary = crtc->base.primary;
mutex_lock(&dev->struct_mutex);
- intel_unpin_fb_obj(work->old_fb, primary->state);
+ intel_unpin_fb_obj(work->old_fb, primary->state->rotation);
drm_gem_object_unreference(&work->pending_flip_obj->base);
if (work->flip_queued_req)
@@ -11746,8 +11742,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
goto cleanup_pending;
}
- ret = intel_pin_and_fence_fb_obj(crtc->primary, fb,
-crtc->primary->state);
+ ret = intel_pin_and_fence_fb_obj(fb, primary->state->rotation);
if (ret)
goto cleanup_pending;
@@ -11797,7 +11792,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
return 0;
cleanup_unpin:
- intel_unpin_fb_obj(fb, crtc->primary->state);
+ intel_unpin_fb_obj(fb, crtc->primary->state->rotation);
cleanup_pending:
if (!IS_ERR_OR_NULL(request))
i915_gem_request_cancel(request);
@@ -13909,7 +13904,7 @@ intel_prepare_plane_fb(struct drm_plane *plane,
if (ret)
[Intel-gfx] [PATCH 09/21] drm/i915: Embed rotation_info under intel_framebuffer
From: Ville Syrjälä
Instead of repopulatin the rotation_info struct for the fb every time
we try to use the fb, we can just populate it once when creating the fb,
and later we can just copy the pre-populate struct into the gtt_view.
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 27 ---
drivers/gpu/drm/i915/intel_drv.h | 1 +
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 74252433b1ec..fddfc5875752 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2309,18 +2309,20 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view *view,
const struct drm_framebuffer *fb,
unsigned int rotation)
{
- struct drm_i915_private *dev_priv = to_i915(fb->dev);
- struct intel_rotation_info *info = &view->params.rotated;
- unsigned int tile_size, tile_width, tile_height, cpp;
-
- *view = i915_ggtt_view_normal;
-
- if (!intel_rotation_90_or_270(rotation))
- return;
-
- *view = i915_ggtt_view_rotated;
+ if (intel_rotation_90_or_270(rotation)) {
+ *view = i915_ggtt_view_rotated;
+ view->params.rotated = to_intel_framebuffer(fb)->rot_info;
+ } else {
+ *view = i915_ggtt_view_normal;
+ }
+}
- info->uv_offset = fb->offsets[1];
+static void
+intel_fill_fb_info(struct drm_i915_private *dev_priv,
+ struct drm_framebuffer *fb)
+{
+ struct intel_rotation_info *info = &to_intel_framebuffer(fb)->rot_info;
+ unsigned int tile_size, tile_width, tile_height, cpp;
tile_size = intel_tile_size(dev_priv);
@@ -2336,6 +2338,7 @@ intel_fill_fb_ggtt_view(struct i915_ggtt_view *view,
intel_tile_dims(dev_priv, &tile_width, &tile_height,
fb->modifier[1], cpp);
+ info->uv_offset = fb->offsets[1];
info->plane[1].width = DIV_ROUND_UP(fb->pitches[1], tile_width
* cpp);
info->plane[1].height = DIV_ROUND_UP(fb->height / 2,
tile_height);
}
@@ -14891,6 +14894,8 @@ static int intel_framebuffer_init(struct drm_device
*dev,
drm_helper_mode_fill_fb_struct(&intel_fb->base, mode_cmd);
intel_fb->obj = obj;
+ intel_fill_fb_info(dev_priv, &intel_fb->base);
+
ret = drm_framebuffer_init(dev, &intel_fb->base, &intel_fb_funcs);
if (ret) {
DRM_ERROR("framebuffer init failed %d\n", ret);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 59bed59388ad..674afa1f9f97 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -118,6 +118,7 @@ enum intel_output_type {
struct intel_framebuffer {
struct drm_framebuffer base;
struct drm_i915_gem_object *obj;
+ struct intel_rotation_info rot_info;
};
struct intel_fbdev {
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 16/21] drm/i915: Limit fb x offset due to fences
From: Ville Syrjälä
If there's a fence on the object it will be aligned to the start
of the object, and hence CPU rendering to any fb that straddles
the fence edge will come out wrong due to lines wrapping at the
wrong place.
We have no API to manage fences on a sub-object level, so we can't
really fix this in any way. Additonally gen2/3 fences are rather
coarse grained so adjusting the offset migth not even be possible.
Avoid these problems by requiring the fb layout to agree with the
fence layout (if present).
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index de312af9b117..f805ec332393 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2643,6 +2643,22 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
intel_fb_offset_to_xy(&x, &y, fb, i);
/*
+* The fence (if used) is aligned to the start of the object
+* so having the framebuffer wrap around across the edge of the
+* fenced region doesn't really work. We have no API to
configure
+* the fence start offset within the object (nor could we
probably
+* on gen2/3). So it's just easier if we just require that the
+* fb layout agrees with the fence layout. We already check
that the
+* fb stride matches the fence stride elsewhere.
+*/
+ if (intel_fb->obj->tiling_mode != I915_TILING_NONE &&
+ (x + width) * cpp > fb->pitches[i]) {
+ DRM_DEBUG("bad fb plane %d offset: 0x%x\n",
+ i, fb->offsets[i]);
+ return -EINVAL;
+ }
+
+ /*
* First pixel of the framebuffer from
* the start of the normal gtt mapping.
*/
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/21] drm/i915: Move the NULL sg handling out from rotate_pages()
From: Ville Syrjälä
rotate_pages() checks to see if it got called with a NULL sg, and then
goes to extract it from sg->sgl. It always gets called with a NULL sg
for the first plane, so moving the initial 'sg=st->sgl' assignment out
into intel_rotate_fb_obj_pages() seems less special-casey.
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 27a3e17f2882..51f2597e3c56 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3375,11 +3375,6 @@ rotate_pages(const dma_addr_t *in, unsigned int offset,
unsigned int column, row;
unsigned int src_idx;
- if (!sg) {
- st->nents = 0;
- sg = st->sgl;
- }
-
for (column = 0; column < width; column++) {
src_idx = stride * (height - 1) + column;
for (row = 0; row < height; row++) {
@@ -3441,11 +3436,14 @@ intel_rotate_fb_obj_pages(struct intel_rotation_info
*rot_info,
i++;
}
+ st->nents = 0;
+ sg = st->sgl;
+
/* Rotate the pages. */
sg = rotate_pages(page_addr_list, 0,
rot_info->plane[0].width, rot_info->plane[0].height,
rot_info->plane[0].width,
- st, NULL);
+ st, sg);
/* Append the UV plane if NV12. */
if (rot_info->pixel_format == DRM_FORMAT_NV12) {
@@ -3457,10 +3455,10 @@ intel_rotate_fb_obj_pages(struct intel_rotation_info
*rot_info,
rot_info->uv_start_page = uv_start_page;
- rotate_pages(page_addr_list, rot_info->uv_start_page,
-rot_info->plane[1].width,
rot_info->plane[1].height,
-rot_info->plane[1].width,
-st, sg);
+ sg = rotate_pages(page_addr_list, rot_info->uv_start_page,
+ rot_info->plane[1].width,
rot_info->plane[1].height,
+ rot_info->plane[1].width,
+ st, sg);
}
DRM_DEBUG_KMS("Created rotated page mapping for object size %zu (%ux%u
tiles, %u pages (%u plane 0)).\n",
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/21] drm/i915: Pass drm_frambuffer to intel_compute_page_offset()
From: Ville Syrjälä
intel_compute_page_offsets() gets passed a bunch of the framebuffer
metadate sepearately. Just pass the framebuffer itself to make life
simpler for the caller, and make it less likely they would make a
mistake in the order of the arguments (as most as just unsigned ints and
such).
We still pass the pitch explicitly since for 90/270 degree rotation
the caller has to pass in the right thing.
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
drivers/gpu/drm/i915/intel_drv.h | 6 ++
drivers/gpu/drm/i915/intel_sprite.c | 9 +++--
3 files changed, 12 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 15634d9cb666..523e75e536dd 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2493,13 +2493,14 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
* to be already rotated to match the rotated GTT view, and
* pitch is the tile_height aligned framebuffer height.
*/
-u32 intel_compute_tile_offset(struct drm_i915_private *dev_priv,
- int *x, int *y,
- uint64_t fb_modifier,
- unsigned int cpp,
+u32 intel_compute_tile_offset(int *x, int *y,
+ const struct drm_framebuffer *fb, int plane,
unsigned int pitch,
unsigned int rotation)
{
+ const struct drm_i915_private *dev_priv = to_i915(fb->dev);
+ uint64_t fb_modifier = fb->modifier[plane];
+ unsigned int cpp = drm_format_plane_cpp(fb->pixel_format, plane);
u32 offset, offset_aligned, alignment;
alignment = intel_surf_alignment(dev_priv, fb_modifier);
@@ -2842,8 +2843,7 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
if (INTEL_INFO(dev)->gen >= 4) {
intel_crtc->dspaddr_offset =
- intel_compute_tile_offset(dev_priv, &x, &y,
- fb->modifier[0], cpp,
+ intel_compute_tile_offset(&x, &y, fb, 0,
fb->pitches[0], rotation);
linear_offset -= intel_crtc->dspaddr_offset;
} else {
@@ -2950,8 +2950,7 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
linear_offset = y * fb->pitches[0] + x * cpp;
intel_crtc->dspaddr_offset =
- intel_compute_tile_offset(dev_priv, &x, &y,
- fb->modifier[0], cpp,
+ intel_compute_tile_offset(&x, &y, fb, 0,
fb->pitches[0], rotation);
linear_offset -= intel_crtc->dspaddr_offset;
if (rotation == BIT(DRM_ROTATE_180)) {
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cb17e1f28e2c..1d3ed21addb4 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1172,10 +1172,8 @@ void assert_fdi_rx_pll(struct drm_i915_private *dev_priv,
void assert_pipe(struct drm_i915_private *dev_priv, enum pipe pipe, bool
state);
#define assert_pipe_enabled(d, p) assert_pipe(d, p, true)
#define assert_pipe_disabled(d, p) assert_pipe(d, p, false)
-u32 intel_compute_tile_offset(struct drm_i915_private *dev_priv,
- int *x, int *y,
- uint64_t fb_modifier,
- unsigned int cpp,
+u32 intel_compute_tile_offset(int *x, int *y,
+ const struct drm_framebuffer *fb, int plane,
unsigned int pitch,
unsigned int rotation);
void intel_prepare_reset(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 7dc2b8b2a4ac..8821533561b1 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -423,8 +423,7 @@ vlv_update_plane(struct drm_plane *dplane,
crtc_h--;
linear_offset = y * fb->pitches[0] + x * cpp;
- sprsurf_offset = intel_compute_tile_offset(dev_priv, &x, &y,
- fb->modifier[0], cpp,
+ sprsurf_offset = intel_compute_tile_offset(&x, &y, fb, 0,
fb->pitches[0], rotation);
linear_offset -= sprsurf_offset;
@@ -557,8 +556,7 @@ ivb_update_plane(struct drm_plane *plane,
sprscale = SPRITE_SCALE_ENABLE | (src_w << 16) | src_h;
linear_offset = y * fb->pitches[0] + x * cpp;
- sprsurf_offset = intel_compute_tile_offset(dev_priv, &x, &y,
- fb->modifier[0], cpp,
+ sprsurf_offset = intel_compute_tile_offset(&x, &y, fb, 0,
[Intel-gfx] [PATCH 19/21] drm/i915: Compute display surface offset in the plane check hook for SKL+
From: Ville Syrjälä
SKL has nasty limitations with the display surface offsets:
* source x offset + width must be less than the stride for X tiled
surfaces or the display engine falls over
* the surface offset requires lots of alignment (256K or 1M)
These facts mean that we can't just pick any suitably aligned tile
boundary as the offset and expect the resulting x offset to be useable.
The solution is to start with the closest boundary as before, but then
keep searhing backwards until we find one that works, or don't. This
means we must be prepared to fail, hence the whole surface offset
calculation needs to be moved to the .check_plane() hook from the
.update_plane() hook.
While at it we can check that the source width/height don't exceed
maximum plane size limits.
We'll store the results of the computation in the plane state to make
it easy for the .update_plane() hook to do its thing.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 164 +--
drivers/gpu/drm/i915/intel_drv.h | 5 ++
drivers/gpu/drm/i915/intel_sprite.c | 33 +++
3 files changed, 151 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 0b1f45d7612e..ad739f79e710 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3011,6 +3011,120 @@ valid_fb:
obj->frontbuffer_bits |= to_intel_plane(primary)->frontbuffer_bit;
}
+static int skl_max_plane_width(const struct drm_framebuffer *fb, int plane,
+ unsigned int rotation)
+{
+ int cpp = drm_format_plane_cpp(fb->pixel_format, plane);
+
+ switch (fb->modifier[plane]) {
+ case DRM_FORMAT_MOD_NONE:
+ case I915_FORMAT_MOD_X_TILED:
+ switch (cpp) {
+ case 8:
+ return 4096;
+ case 4:
+ case 2:
+ case 1:
+ return 8192;
+ default:
+ MISSING_CASE(cpp);
+ break;
+ }
+ break;
+ case I915_FORMAT_MOD_Y_TILED:
+ case I915_FORMAT_MOD_Yf_TILED:
+ switch (cpp) {
+ case 8:
+ return 2048;
+ case 4:
+ return 4096;
+ case 2:
+ case 1:
+ return 8192;
+ default:
+ MISSING_CASE(cpp);
+ break;
+ }
+ break;
+ default:
+ MISSING_CASE(fb->modifier[plane]);
+ }
+
+ return 2048;
+}
+
+static int skl_check_main_surface(struct intel_plane_state *plane_state)
+{
+ const struct drm_i915_private *dev_priv =
to_i915(plane_state->base.plane->dev);
+ const struct drm_framebuffer *fb = plane_state->base.fb;
+ unsigned int rotation = plane_state->base.rotation;
+ int x = plane_state->src.x1 >> 16;
+ int y = plane_state->src.y1 >> 16;
+ int w = drm_rect_width(&plane_state->src) >> 16;
+ int h = drm_rect_height(&plane_state->src) >> 16;
+ int max_width = skl_max_plane_width(fb, 0, rotation);
+ int max_height = 4096;
+ u32 alignment, offset;
+
+ if (w > max_width || h > max_height) {
+ DRM_DEBUG_KMS("requested Y/RGB source size %dx%d too big (limit
%dx%d)\n",
+ w, h, max_width, max_height);
+ return -EINVAL;
+ }
+
+ intel_add_fb_offsets(&x, &y, plane_state, 0);
+ offset = intel_compute_tile_offset(&x, &y, plane_state, 0);
+
+ alignment = intel_surf_alignment(dev_priv, fb->modifier[0]);
+
+ /*
+* When using an X-tiled surface, the plane blows up
+* if the x offset + width exceed the stride.
+*
+* TODO: linear and Y-tiled seem fine, Yf untested,
+*/
+ if (fb->modifier[0] == I915_FORMAT_MOD_X_TILED) {
+ int cpp = drm_format_plane_cpp(fb->pixel_format, 0);
+
+ for (;;) {
+ if ((x + w) * cpp <= fb->pitches[0])
+ break;
+
+ if (offset == 0) {
+ DRM_DEBUG_KMS("Unable to find suitable display
surface offset\n");
+ return -EINVAL;
+ }
+
+ offset = intel_adjust_tile_offset(&x, &y, plane_state,
0,
+ offset, offset -
alignment);
+ }
+ }
+
+ plane_state->main.offset = offset;
+ plane_state->main.x = x;
+ plane_state->main.y = y;
+
+ return 0;
+}
+
+int skl_check_plane_surface(struct intel_plane_state *plane_state)
+{
+ const struct drm_framebuffer *fb = plane_state->base.fb;
+ unsigned int rotation = plane_state->base.rotation;
+
[Intel-gfx] [PATCH 15/21] drm/i915: Adjust obj tiling vs. fb modifier rules
From: Ville Syrjälä
Currently we requite the object to be X tiled if the fb is X
tiled. The argument is supposedly FBC GTT tracking. But
actually that no longer holds water since FBC supports
Y tiling as well on SKL+.
A better rule IMO is to require that if there is a fence, the
fb modifier match the object tiling mode. But if the object is linear,
we can allow the fb modifier to be anything. The idea being that
if the user set the tiling mode on the object, presumaly the intention
is to actually use the fence for CPU access. But if the tiling mode is
not set, the user has no intention of using a fence (and can't actually
since we disalling tiling mode changes when there are framebuffers
associated with the object).
On gen2/3 we must keep to the rule that the object and fb
must be either both linear or both X tiled. No mixing allowed
since the display engine itself will use the fence if it's present.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 733bd68d2e01..de312af9b117 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14922,17 +14922,19 @@ static int intel_framebuffer_init(struct drm_device
*dev,
WARN_ON(!mutex_is_locked(&dev->struct_mutex));
if (mode_cmd->flags & DRM_MODE_FB_MODIFIERS) {
- /* Enforce that fb modifier and tiling mode match, but only for
-* X-tiled. This is needed for FBC. */
- if (!!(obj->tiling_mode == I915_TILING_X) !=
- !!(mode_cmd->modifier[0] == I915_FORMAT_MOD_X_TILED)) {
+ /*
+* If there's a fence, enforce that
+* the fb modifier and tiling mode match.
+*/
+ if (obj->tiling_mode != I915_TILING_NONE &&
+ obj->tiling_mode !=
intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
DRM_DEBUG("tiling_mode doesn't match fb modifier\n");
return -EINVAL;
}
} else {
- if (obj->tiling_mode == I915_TILING_X)
+ if (obj->tiling_mode == I915_TILING_X) {
mode_cmd->modifier[0] = I915_FORMAT_MOD_X_TILED;
- else if (obj->tiling_mode == I915_TILING_Y) {
+ } else if (obj->tiling_mode == I915_TILING_Y) {
DRM_DEBUG("No Y tiling for legacy addfb\n");
return -EINVAL;
}
@@ -14956,6 +14958,16 @@ static int intel_framebuffer_init(struct drm_device
*dev,
return -EINVAL;
}
+ /*
+* gen2/3 display engine uses the fence if present,
+* so the tiling mode must match the fb modifier exactly.
+*/
+ if (INTEL_INFO(dev_priv)->gen < 4 &&
+ obj->tiling_mode !=
intel_fb_modifier_to_tiling(mode_cmd->modifier[0])) {
+ DRM_DEBUG("tiling_mode must match fb modifier exactly on
gen2/3\n");
+ return -EINVAL;
+ }
+
stride_alignment = intel_fb_stride_alignment(dev_priv,
mode_cmd->modifier[0],
mode_cmd->pixel_format);
@@ -14975,7 +14987,7 @@ static int intel_framebuffer_init(struct drm_device
*dev,
return -EINVAL;
}
- if (mode_cmd->modifier[0] == I915_FORMAT_MOD_X_TILED &&
+ if (obj->tiling_mode != I915_TILING_NONE &&
mode_cmd->pitches[0] != obj->stride) {
DRM_DEBUG("pitch (%d) must match tiling stride (%d)\n",
mode_cmd->pitches[0], obj->stride);
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 21/21] drm/i915: Make sure fb offset is (macro)pixel aligned
From: Ville Syrjälä
We convert the fb->offsets[] into x/y offsets, so they must be
(macro)pixel aligned. Check for this, and if things look good
allow fb->offsets[] != 0 when creating fbs since we now handle
them correctly.
v2: Move to last place in the series and improve the commit message
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter (v1)
---
drivers/gpu/drm/i915/intel_display.c | 37 +---
1 file changed, 34 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index bb496c036049..db4a531e1d58 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15138,6 +15138,37 @@ u32 intel_fb_pitch_limit(struct drm_device *dev,
uint64_t fb_modifier,
}
}
+static int intel_fb_check_offsets(const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ uint32_t format = mode_cmd->pixel_format;
+ int num_planes = drm_format_num_planes(format);
+ int i;
+
+ for (i = 0; i < num_planes; i++) {
+ unsigned int cpp;
+
+ switch (format) {
+ case DRM_FORMAT_YUYV:
+ case DRM_FORMAT_UYVY:
+ case DRM_FORMAT_YVYU:
+ case DRM_FORMAT_VYUY:
+ cpp = 4;
+ break;
+ default:
+ cpp = drm_format_plane_cpp(format, i);
+ break;
+ }
+
+ if (mode_cmd->offsets[i] % cpp) {
+ DRM_DEBUG("fb plane %d offset 0x%08x not (macro)pixel
aligned\n",
+ i, mode_cmd->offsets[i]);
+ return -EINVAL;
+ }
+ }
+
+ return 0;
+}
+
static int intel_framebuffer_init(struct drm_device *dev,
struct intel_framebuffer *intel_fb,
struct drm_mode_fb_cmd2 *mode_cmd,
@@ -15276,9 +15307,9 @@ static int intel_framebuffer_init(struct drm_device
*dev,
return -EINVAL;
}
- /* FIXME need to adjust LINOFF/TILEOFF accordingly. */
- if (mode_cmd->offsets[0] != 0)
- return -EINVAL;
+ ret = intel_fb_check_offsets(mode_cmd);
+ if (ret)
+ return ret;
drm_helper_mode_fill_fb_struct(&intel_fb->base, mode_cmd);
intel_fb->obj = obj;
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 20/21] drm/i915: Deal with NV12 CbCr plane AUX surface on SKL+
From: Ville Syrjälä
With NV12 we have two color planes to deal with so we must compute the
surface and x/y offsets for the second plane as well.
What makes this a bit nasty is that the hardware expects the surface
offset to be specified as a distance from the main surface offset.
What's worse, the distance must be non-negative (no neat wraparound or
anything). So we must make sure that the main surface offset is always
less or equal to the AUX surface offset. We do that by computing the AUX
offset first and the main surface offset second. If the main surface
offset ends up being above the AUX offset, we just push it down as far
as is required while still maintaining the required alignment etc.
Fortunately the AUX offset only reuqires 4K alignment, so we don't need
to do any of the backwards searching for an acceptable offset that we
must do for the main surface. And X tiled + NV12 isn't a supported
combination anyway.
TODO: actually program the HW registers
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 62 ++--
drivers/gpu/drm/i915/intel_drv.h | 4 +++
2 files changed, 64 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index ad739f79e710..bb496c036049 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2633,8 +2633,14 @@ u32 intel_compute_tile_offset(int *x, int *y,
const struct drm_i915_private *dev_priv =
to_i915(state->base.plane->dev);
const struct drm_framebuffer *fb = state->base.fb;
unsigned int rotation = state->base.rotation;
- u32 alignment = intel_surf_alignment(dev_priv, fb->modifier[plane]);
int pitch = intel_fb_pitch(fb, plane, rotation);
+ u32 alignment;
+
+ /* AUX_DIST needs only 4K alignment */
+ if (fb->pixel_format == DRM_FORMAT_NV12 && plane == 1)
+ alignment = 4096;
+ else
+ alignment = intel_surf_alignment(dev_priv, fb->modifier[plane]);
return _intel_compute_tile_offset(dev_priv, x, y, fb, plane, pitch,
rotation, alignment);
@@ -3064,7 +3070,7 @@ static int skl_check_main_surface(struct
intel_plane_state *plane_state)
int h = drm_rect_height(&plane_state->src) >> 16;
int max_width = skl_max_plane_width(fb, 0, rotation);
int max_height = 4096;
- u32 alignment, offset;
+ u32 alignment, offset, aux_offset = plane_state->aux.offset;
if (w > max_width || h > max_height) {
DRM_DEBUG_KMS("requested Y/RGB source size %dx%d too big (limit
%dx%d)\n",
@@ -3078,6 +3084,15 @@ static int skl_check_main_surface(struct
intel_plane_state *plane_state)
alignment = intel_surf_alignment(dev_priv, fb->modifier[0]);
/*
+* AUX surface offset is specified as the distance from the
+* main surface offset, and it must be non-negative. Make
+* sure that is what we will get.
+*/
+ if (offset > aux_offset)
+ offset = intel_adjust_tile_offset(&x, &y, plane_state, 0,
+ offset, aux_offset &
~(alignment - 1));
+
+ /*
* When using an X-tiled surface, the plane blows up
* if the x offset + width exceed the stride.
*
@@ -3107,6 +3122,35 @@ static int skl_check_main_surface(struct
intel_plane_state *plane_state)
return 0;
}
+static int skl_check_nv12_aux_surface(struct intel_plane_state *plane_state)
+{
+ const struct drm_framebuffer *fb = plane_state->base.fb;
+ unsigned int rotation = plane_state->base.rotation;
+ int max_width = skl_max_plane_width(fb, 1, rotation);
+ int max_height = 4096;
+ int x = plane_state->src.x1 >> 17;
+ int y = plane_state->src.y1 >> 17;
+ int w = drm_rect_width(&plane_state->src) >> 17;
+ int h = drm_rect_height(&plane_state->src) >> 17;
+ u32 offset;
+
+ intel_add_fb_offsets(&x, &y, plane_state, 1);
+ offset = intel_compute_tile_offset(&x, &y, plane_state, 1);
+
+ /* FIXME not quite sure how/if these apply to the chroma plane */
+ if (w > max_width || h > max_height) {
+ DRM_DEBUG_KMS("CbCr source size %dx%d too big (limit %dx%d)\n",
+ w, h, max_width, max_height);
+ return -EINVAL;
+ }
+
+ plane_state->aux.offset = offset;
+ plane_state->aux.x = x;
+ plane_state->aux.y = y;
+
+ return 0;
+}
+
int skl_check_plane_surface(struct intel_plane_state *plane_state)
{
const struct drm_framebuffer *fb = plane_state->base.fb;
@@ -3118,6 +3162,20 @@ int skl_check_plane_surface(struct intel_plane_state
*plane_state)
drm_rect_rotate(&plane_state->src,
fb->width, fb->height, BIT(DRM_ROTATE_270));
+ /*
+* Handle the AUX
[Intel-gfx] [PATCH 13/21] drm/i915: Pass around plane_state instead of fb+rotation
From: Ville Syrjälä
intel_compute_tile_offset() and intel_add_fb_offsets() get passed the fb
and the rotation. As both of those come from the plane state we can just
pass that in instead.
For extra consitency pass the plane state to intel_fb_xy_to_linear() as
well even though it only really needs the fb.
Signed-off-by: Ville Syrjälä
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 35 ---
drivers/gpu/drm/i915/intel_drv.h | 9 -
drivers/gpu/drm/i915/intel_sprite.c | 22 +++---
3 files changed, 35 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 66794681b2ba..5f60fe0214e1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2453,8 +2453,10 @@ static int intel_fb_pitch(const struct drm_framebuffer
*fb, int plane,
* with gen2/3, and 90/270 degree rotations isn't supported on any of them.
*/
u32 intel_fb_xy_to_linear(int x, int y,
- const struct drm_framebuffer *fb, int plane)
+ const struct intel_plane_state *state,
+ int plane)
{
+ const struct drm_framebuffer *fb = state->base.fb;
unsigned int cpp = drm_format_plane_cpp(fb->pixel_format, plane);
unsigned int pitch = fb->pitches[plane];
@@ -2467,11 +2469,12 @@ u32 intel_fb_xy_to_linear(int x, int y,
* specify the start of scanout from the beginning of the gtt mapping.
*/
void intel_add_fb_offsets(int *x, int *y,
- const struct drm_framebuffer *fb, int plane,
- unsigned int rotation)
+ const struct intel_plane_state *state,
+ int plane)
{
- const struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ const struct intel_framebuffer *intel_fb =
to_intel_framebuffer(state->base.fb);
+ unsigned int rotation = state->base.rotation;
if (intel_rotation_90_or_270(rotation)) {
*x += intel_fb->rotated[plane].x;
@@ -2578,10 +2581,12 @@ static u32 _intel_compute_tile_offset(const struct
drm_i915_private *dev_priv,
}
u32 intel_compute_tile_offset(int *x, int *y,
- const struct drm_framebuffer *fb, int plane,
- unsigned int rotation)
+ const struct intel_plane_state *state,
+ int plane)
{
- const struct drm_i915_private *dev_priv = to_i915(fb->dev);
+ const struct drm_i915_private *dev_priv =
to_i915(state->base.plane->dev);
+ const struct drm_framebuffer *fb = state->base.fb;
+ unsigned int rotation = state->base.rotation;
u32 alignment = intel_surf_alignment(dev_priv, fb->modifier[plane]);
int pitch = intel_fb_pitch(fb, plane, rotation);
@@ -3005,11 +3010,11 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
if (IS_G4X(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
- intel_add_fb_offsets(&x, &y, fb, 0, rotation);
+ intel_add_fb_offsets(&x, &y, plane_state, 0);
if (INTEL_INFO(dev)->gen >= 4)
intel_crtc->dspaddr_offset =
- intel_compute_tile_offset(&x, &y, fb, 0, rotation);
+ intel_compute_tile_offset(&x, &y, plane_state, 0);
if (rotation == BIT(DRM_ROTATE_180)) {
dspcntr |= DISPPLANE_ROTATE_180;
@@ -3018,7 +3023,7 @@ static void i9xx_update_primary_plane(struct drm_plane
*primary,
y += (crtc_state->pipe_src_h - 1);
}
- linear_offset = intel_fb_xy_to_linear(x, y, fb, 0);
+ linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
if (INTEL_INFO(dev)->gen < 4)
intel_crtc->dspaddr_offset = linear_offset;
@@ -3108,10 +3113,10 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
if (!IS_HASWELL(dev) && !IS_BROADWELL(dev))
dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
- intel_add_fb_offsets(&x, &y, fb, 0, rotation);
+ intel_add_fb_offsets(&x, &y, plane_state, 0);
intel_crtc->dspaddr_offset =
- intel_compute_tile_offset(&x, &y, fb, 0, rotation);
+ intel_compute_tile_offset(&x, &y, plane_state, 0);
if (rotation == BIT(DRM_ROTATE_180)) {
dspcntr |= DISPPLANE_ROTATE_180;
@@ -3122,7 +3127,7 @@ static void ironlake_update_primary_plane(struct
drm_plane *primary,
}
}
- linear_offset = intel_fb_xy_to_linear(x, y, fb, 0);
+ linear_offset = intel_fb_xy_to_linear(x, y, plane_state, 0);
intel_crtc->adjusted_x = x;
intel_crtc->adjusted_y = y;
@@ -3344,8 +3349,8 @@ static void skylake_update_primary_plane(struct drm_plane
*plane,
src_h = drm_rect_height(&r);
[Intel-gfx] [PATCH 18/21] drm/i915: Make intel_adjust_tile_offset() work for linear buffers
From: Ville Syrjälä
To make life less surprising we can make intel_adjust_tile_offset()
deal with linear buffers as well. Currently it doesn't seem like there's
a real need for this since only X tiling and NV12 (which would always
be tiled currently) should need it. But I've used it for some debug
hacks already so seems like a reasonable thing to have.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 73
1 file changed, 57 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 79dcb7d26b7a..0b1f45d7612e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2486,19 +2486,16 @@ void intel_add_fb_offsets(int *x, int *y,
}
/*
- * Adjust the tile offset by moving the difference into
- * the x/y offsets.
- *
* Input tile dimensions and pitch must already be
* rotated to match x and y, and in pixel units.
*/
-static u32 intel_adjust_tile_offset(int *x, int *y,
- unsigned int tile_width,
- unsigned int tile_height,
- unsigned int tile_size,
- unsigned int pitch_tiles,
- u32 old_offset,
- u32 new_offset)
+static u32 _intel_adjust_tile_offset(int *x, int *y,
+unsigned int tile_width,
+unsigned int tile_height,
+unsigned int tile_size,
+unsigned int pitch_tiles,
+u32 old_offset,
+u32 new_offset)
{
unsigned int pitch_pixels = pitch_tiles * tile_width;
unsigned int tiles;
@@ -2520,6 +2517,50 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
}
/*
+ * Adjust the tile offset by moving the difference into
+ * the x/y offsets.
+ */
+static u32 intel_adjust_tile_offset(int *x, int *y,
+ const struct intel_plane_state *state, int
plane,
+ u32 old_offset, u32 new_offset)
+{
+ const struct drm_i915_private *dev_priv =
to_i915(state->base.plane->dev);
+ const struct drm_framebuffer *fb = state->base.fb;
+ unsigned int cpp = drm_format_plane_cpp(fb->pixel_format, plane);
+ unsigned int rotation = state->base.rotation;
+ unsigned int pitch = intel_fb_pitch(fb, plane, rotation);
+
+ WARN_ON(new_offset > old_offset);
+
+ if (fb->modifier[plane] != DRM_FORMAT_MOD_NONE) {
+ unsigned int tile_size, tile_width, tile_height;
+ unsigned int pitch_tiles;
+
+ tile_size = intel_tile_size(dev_priv);
+ intel_tile_dims(dev_priv, &tile_width, &tile_height,
+ fb->modifier[plane], cpp);
+
+ if (intel_rotation_90_or_270(rotation)) {
+ pitch_tiles = pitch / tile_height;
+ swap(tile_width, tile_height);
+ } else {
+ pitch_tiles = pitch / (tile_width * cpp);
+ }
+
+ _intel_adjust_tile_offset(x, y, tile_width, tile_height,
+ tile_size, pitch_tiles,
+ old_offset, new_offset);
+ } else {
+ old_offset += *y * pitch + *x * cpp;
+
+ *y = (old_offset - new_offset) / pitch;
+ *x = ((old_offset - new_offset) - *y * pitch) / cpp;
+ }
+
+ return new_offset;
+}
+
+/*
* Computes the linear offset to the base tile and adjusts
* x, y. bytes per pixel is assumed to be a power-of-two.
*
@@ -2571,9 +2612,9 @@ static u32 _intel_compute_tile_offset(const struct
drm_i915_private *dev_priv,
offset = (tile_rows * pitch_tiles + tiles) * tile_size;
offset_aligned = offset & ~alignment;
- intel_adjust_tile_offset(x, y, tile_width, tile_height,
-tile_size, pitch_tiles,
-offset, offset_aligned);
+ _intel_adjust_tile_offset(x, y, tile_width, tile_height,
+ tile_size, pitch_tiles,
+ offset, offset_aligned);
} else {
offset = *y * pitch + *x * cpp;
offset_aligned = offset & ~alignment;
@@ -2720,9 +2761,9 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
* We only keep the x/y offsets, so push all of the
* gtt offset into the x/y offsets.
*/
- intel_adjust_tile_offset(&x, &y, tile_size,
-tile_w
[Intel-gfx] [PATCH 17/21] drm/i915: Allow calling intel_adjust_tile_offset() multiple times
From: Ville Syrjälä
Minimize the resulting X coordinate after intel_adjust_tile_offset() is
done with it's offset adjustment. This allows calling
intel_adjust_tile_offset() multiple times in case we need to adjust
the offset several times.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index f805ec332393..79dcb7d26b7a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2500,6 +2500,7 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
u32 old_offset,
u32 new_offset)
{
+ unsigned int pitch_pixels = pitch_tiles * tile_width;
unsigned int tiles;
WARN_ON(old_offset & (tile_size - 1));
@@ -2511,6 +2512,10 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
*y += tiles / pitch_tiles * tile_height;
*x += tiles % pitch_tiles * tile_width;
+ /* minimize x in case it got needlessly big */
+ *y += *x / pitch_pixels * tile_height;
+ *x %= pitch_pixels;
+
return new_offset;
}
--
2.4.10
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] 4.3.3 / skylake / dual graphics: multiple CSR errors at boot from i915 driver
On Mon, Feb 15, 2016 at 02:11:24PM +0800, Zhi Wang wrote: > From SKL, i915 will try to load DMC firmware when system is starting up. You > can find it from 01.org. Personally, it looks without the firmware, the > system is also able to work, except a lot warnings. :) We pretty much require dmc, since supporting a non-dmc path would double the amount of testing we'd have to do. And right now we can do barely enough to keep that one configuration working. This is the same with all the various pm features that are disabled by default - if you touch any of those we taint the kernel. Thanks, Daniel > > On 02/13/16 08:42, Marc MERLIN wrote: > >I'm testing a new thinkpad skylake based P70 with dual graphics > >legolas:~# lspci | grep VGA > >00:02.0 VGA compatible controller: Intel Corporation Device 191b (rev 06) > >01:00.0 VGA compatible controller: NVIDIA Corporation GM107GLM [Quadro > >M600M] (rev a2) > > > > > >I'm getting these warnings at boot, although X11 seems to come up ok. > > > >Should I worry about them? > >WARNING: CPU: 4 PID: 101 at drivers/gpu/drm/i915/intel_csr.c:458 > >assert_csr_loaded+0x2e/0xbe() > >CSR is not loaded. > >Modules linked in: rtsx_pci_ms(+) snd_hda_intel rtsx_pci_sdmmc memstick > >iTCO_wdt iTCO_vendor_support snd_hda_codec snd_hda_core snd_hwdep > >snd_pcm_oss snd_mixer_oss intel_rapl snd_pcm iosf_mbi thinkpad_acpi > >x86_pkg_temp_thermal nvram intel_powerclamp coretemp snd_seq_midi > >snd_seq_midi_event kvm_intel snd_rawmidi kvm snd_seq crct10dif_pclmul > >crc32_pclmul snd_seq_device ttm snd_timer iwlwifi microcode input_leds snd > >nvidiafb xhci_pci psmouse pcspkr vgastate serio_raw xhci_hcd cfg80211 > >i2c_i801 rtsx_pci sg soundcore fb_ddc wmi(+) usbcore rfkill battery ac > >tpm_crb(+) usb_common tpm fjes evdev shpchp processor sata_sil24 r8169 mii > >fuse fan raid456 multipath mmc_block mmc_core dm_crypt dm_mod > >async_raid6_recov async_pq async_xor async_memcpy async_tx blowfish_x86_64 > >blowfish_common ecb xts crc32c_intel > > aesni_intel e1000e aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd > > ptp pps_core thermal > >CPU: 4 PID: 101 Comm: kworker/4:1 Not tainted > >4.3.3-amd64-i915-volpreempt-20150421 #2 > >Hardware name: LENOVO 20ERCTO1WW/20ERCTO1WW, BIOS N1DET41W (1.15 ) 12/31/2015 > >ahci :00:17.0: port does not support device sleep > >Workqueue: events azx_probe_work [snd_hda_intel] > > 88087aebbc48 8134150e 88087aebbc90 > > 88087aebbc80 8105aa29 8146f5ee 88087ad5 > > 81cd81d0 300f 88087ad45800 88087aebbce8 > >Call Trace: > > [] dump_stack+0x44/0x55 > > [] warn_slowpath_common+0x99/0xb2 > > [] ? assert_csr_loaded+0x2e/0xbe > > [] warn_slowpath_fmt+0x48/0x50 > > [] ? mutex_lock+0x12/0x2f > > [] ? mutex_unlock+0x16/0x18 > > [] assert_csr_loaded+0x2e/0xbe > > [] skl_set_power_well+0x198/0x7df > > [] skl_power_well_enable+0x13/0x15 > > [] intel_display_power_get+0x9e/0xc9 > > [] i915_audio_component_get_power+0x1e/0x20 > > [] snd_hdac_display_power+0x91/0xf1 [snd_hda_core] > > [] azx_probe_continue+0xa9/0x654 [snd_hda_intel] > > [] ? finish_task_switch+0xb0/0x13b > > [] azx_probe_work+0x15/0x17 [snd_hda_intel] > > [] process_one_work+0x15b/0x260 > > [] worker_thread+0x1f0/0x29d > > [] ? rescuer_thread+0x281/0x281 > > [] ? rescuer_thread+0x281/0x281 > > [] kthread+0xa5/0xad > > [] ? kthread_parkme+0x24/0x24 > > [] ret_from_fork+0x3f/0x70 > > [] ? kthread_parkme+0x24/0x24 > >---[ end trace 904c3d98e9b53001 ]--- > >[ cut here ] > >WARNING: CPU: 4 PID: 101 at drivers/gpu/drm/i915/intel_csr.c:461 > >assert_csr_loaded+0x8c/0xbe() > >CSR SSP Base Not fine > >Modules linked in: rtsx_pci_ms(+) snd_hda_intel rtsx_pci_sdmmc memstick > >iTCO_wdt iTCO_vendor_support snd_hda_codec snd_hda_core snd_hwdep > >snd_pcm_oss snd_mixer_oss intel_rapl snd_pcm iosf_mbi thinkpad_acpi > >x86_pkg_temp_thermal nvram intel_powerclamp coretemp snd_seq_midi > >snd_seq_midi_event kvm_intel snd_rawmidi kvm snd_seq crct10dif_pclmul > >crc32_pclmul snd_seq_device ttm snd_timer iwlwifi microcode input_leds snd > >nvidiafb xhci_pci psmouse pcspkr vgastate serio_raw xhci_hcd cfg80211 > >i2c_i801 rtsx_pci sg soundcore fb_ddc wmi(+) usbcore rfkill battery ac > >tpm_crb(+) usb_common tpm fjes evdev shpchp processor sata_sil24 r8169 mii > >fuse fan raid456 multipath mmc_block mmc_core dm_crypt dm_mod > >async_raid6_recov async_pq async_xor async_memcpy async_tx blowfish_x86_64 > >blowfish_common ecb xts crc32c_intel > > aesni_intel e1000e aes_x86_64 glue_helper lrw gf128mul ablk_helper cryptd > > ptp pps_core thermal > >CPU: 4 PID: 101 Comm: kworker/4:1 Tainted: GW > >4.3.3-amd64-i915-volpreempt-20150421 #2 > >Hardware name: LENOVO 20ERCTO1WW/20ERCTO1WW, BIOS N1DET41W (1.15 ) 12/31/2015 > >Workqueue: events azx_probe_work [snd_hda_intel] > > 88087aebbc48 8134150e 88087aebbc90 > >
Re: [Intel-gfx] [BUG] HDMI 12bpc causing occasional flickering and blanking
* Ville Syrjälä > Could you test the following hack while using a 1920x1080 mode with > 148.5 MHz dotclock, and see if there's any improvement? I think it might be an improvement, that is, the blanking/flickers seems to occur less often than it did with 8ed1804, but it is not completely fixed. I've noticed 5-6 blankings events in the last hour or so (during most of those events I wasn't even using the computer actively, it was just sitting there showing a static image of gitk). Kernel output here: http://filebin.net/r3nlwu09y2/villepatched.txt Tore ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
