Re: [Intel-gfx] Kernel 3.19rc6 flooding intel_check_page_flip warnings when using compton
On Mon, 02 Feb 2015, Sakari Kapanen wrote: > Dear maintainers, > > On an Asus Zenbook UX32VD laptop with an i5-3317U CPU and Intel HD4000 > graphics, I'm experiencing the following with the latest 3.19rc6 > mainline kernel (built from the Arch Linux AUR package: > https://aur.archlinux.org/packages/linux-mainline/ ). The problem is > related to the compton compositor: https://github.com/chjj/compton Hi, a full dmesg from boot to the problem with drm.debug=14 module parameter set might be useful. Also, you may get fastest results if you do a git bisect from a good to bad kernel. BR, Jani. > > Booting to X goes very normally. Then, I start compton with the command > `compton --backend glx`. As soon as I do that, the dmesg log starts > getting filled with these warnings. This is a snippet from my journalctl > log: > > 1 Feb 02 00:06:44 stroemsoe kernel: WARNING: CPU: 0 PID: 273 at > drivers/gpu/drm/i915/intel_display.c:9705 > intel_check_page_flip+0xa2/0xf0 [i915]() > 1421 Feb 02 00:06:44 stroemsoe kernel: WARN_ON(!in_irq()) > 1 Feb 02 00:06:44 stroemsoe kernel: Modules linked in: > 2 Feb 02 00:06:44 stroemsoe kernel: joydev mousedev msr uvcvideo > rtsx_usb_sdmmc videobuf2_vmalloc rtsx_usb_ms videobuf2_memops mmc_core > memstick videobuf2_core n ls_iso8859_1 rtsx_usb v4l2_common nls_cp437 > videodev vfat fat coretemp intel_rapl media iosf_mbi > x86_pkg_temp_thermal intel_powerclamp arc4 kvm_intel kvm iwldvm > crct10dif_pclmul crc32_pclmul iTCO_wdt mac80211 iTCO_vendor_support > crc32c_intel ghash_clmulni_intel snd_hda_codec_hdmi nouveau aesni_intel > i915 aes_x86_64 snd _hda_codec_realtek glue_helper lrw gf128mul > ablk_helper snd_hda_codec_generic cryptd iwlwifi pcspkr evdev mac_hid > snd_hda_intel psmouse serio_raw snd_hda_contro ller snd_hda_codec > snd_hwdep mxm_wmi snd_pcm ttm snd_timer cfg80211 snd lpc_ich soundcore > mfd_core i2c_i801 fan int3403_thermal button i2c_algo_bit mei_me > drm_k ms_helper mei drm battery tpm_tis > 3 Feb 02 00:06:44 stroemsoe kernel: thermal tpm shpchp ac > int3402_thermal i2c_core intel_gtt int3400_thermal acpi_thermal_rel > processor sch_fq_codel overlay ext4 crc16 mbcache jbd2 sd_mod > atkbd libps2 ahci libahci libata ehci_pci xhci_pci ehci_hcd xhci_hcd > scsi_mod usbcore usb_common i8042 serio asus_nb_wmi asus_wmi hwm on > video rfkill sparse_keymap wmi led_class > 4 Feb 02 00:06:44 stroemsoe kernel: CPU: 0 PID: 273 Comm: > irq/32-i915 Tainted: GW 3.19.0-1-mainline #1 > 5 Feb 02 00:06:44 stroemsoe kernel: Hardware name: ASUSTeK COMPUTER > INC. UX32VD/UX32VD, BIOS UX32VD.213 11/16/2012 > 6 Feb 02 00:06:44 stroemsoe kernel: > b983161a 8800c88afc78 8153537c > 7 Feb 02 00:06:44 stroemsoe kernel: > 8800c88afcd0 8800c88afcb8 81075a9a > 8 Feb 02 00:06:44 stroemsoe kernel: 8800c88afcb8 > 8800c7d99000 8800c8e05000 8800c8e05000 > 9 Feb 02 00:06:44 stroemsoe kernel: Call Trace: > 10 Feb 02 00:06:44 stroemsoe kernel: [] > dump_stack+0x4c/0x6e > 11 Feb 02 00:06:44 stroemsoe kernel: [] > warn_slowpath_common+0x8a/0xc0 > 12 Feb 02 00:06:44 stroemsoe kernel: [] > warn_slowpath_fmt+0x55/0x70 > 13 Feb 02 00:06:44 stroemsoe kernel: [] > intel_check_page_flip+0xa2/0xf0 [i915] > 14 Feb 02 00:06:44 stroemsoe kernel: [] > ironlake_irq_handler+0x428/0x1000 [i915] > 15 Feb 02 00:06:44 stroemsoe kernel: [] ? > do_set_cpus_allowed+0x4a/0x60 > 16 Feb 02 00:06:44 stroemsoe kernel: [] ? > irq_thread_fn+0x50/0x50 > 17 Feb 02 00:06:44 stroemsoe kernel: [] > irq_forced_thread_fn+0x2d/0x70 > 18 Feb 02 00:06:44 stroemsoe kernel: [] > irq_thread+0x157/0x180 > 19 Feb 02 00:06:44 stroemsoe kernel: [] ? > wake_threads_waitq+0x30/0x30 > 20 Feb 02 00:06:44 stroemsoe kernel: [] ? > irq_thread_dtor+0xc0/0xc0 > 21 Feb 02 00:06:44 stroemsoe kernel: [] > kthread+0xea/0x100 > 22 Feb 02 00:06:44 stroemsoe kernel: [] ? > kthread_create_on_node+0x1c0/0x1c0 > 23 Feb 02 00:06:44 stroemsoe kernel: [] > ret_from_fork+0x7c/0xb0 > 24 Feb 02 00:06:44 stroemsoe kernel: [] ? > kthread_create_on_node+0x1c0/0x1c0 > 25 Feb 02 00:06:44 stroemsoe kernel: ---[ end trace 46f2548918f46443 > ]--- > > I get about 4-5 of them per second as long as compton is running. > Starting compton with `--backend xrender` doesn't cause any warnings. > I'm using the SNA AccelMethod (the default), but switching to UXA or > Glamor didn't seem to have any effect. I haven't set any i915 specific > kernel flags. > > I don't see this on the current stable 3.18.5 kernel. The first time I > saw this was on 3.19rc3 when I tried it due to another bug in the 3.18 > series. I haven't gone through all the 3.19 release candidates, but the > behaviour with 3.19rc6 seems identical to what I saw with 3.19rc3. > > Sakari Kapanen > -- Jani Nikula, Inte
Re: [Intel-gfx] [PATCH 2/3] drm/i915/skl: Declare that GT3 has a second VCS
On Tue, Feb 03, 2015 at 05:55:05PM -0800, Rodrigo Vivi wrote:
> On Thu, Jan 29, 2015 at 6:13 AM, Damien Lespiau
> wrote:
> > Signed-off-by: Damien Lespiau
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 19 +--
> > 1 file changed, 17 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 6484229..9fdaf64 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -356,7 +356,7 @@ static const struct intel_device_info
> > intel_cherryview_info = {
> > CURSOR_OFFSETS,
> > };
> >
> > -static const struct intel_device_info intel_skylake_info = {
> > +static const struct intel_device_info intel_skylake_gt12_info = {
>
> didn't like much gt12 because i can be confusing with 12 1, 2, 1.2 1.5...
Yeah, at first I've thought this would be for some gt2 with stuff fused
off ... Imo just leave out the 12 and call it skylake_gt_info or so.
-Daniel
>
> > .is_preliminary = 1,
> > .is_skylake = 1,
> > .gen = 9, .num_pipes = 3,
> > @@ -369,6 +369,19 @@ static const struct intel_device_info
> > intel_skylake_info = {
> > IVB_CURSOR_OFFSETS,
> > };
> >
> > +static const struct intel_device_info intel_skylake_gt3_info = {
> > + .is_preliminary = 1,
> > + .is_skylake = 1,
> > + .gen = 9, .num_pipes = 3,
> > + .need_gfx_hws = 1, .has_hotplug = 1,
> > + .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING |
> > BSD2_RING,
> > + .has_llc = 1,
> > + .has_ddi = 1,
> > + .has_fbc = 1,
> > + GEN_DEFAULT_PIPEOFFSETS,
> > + IVB_CURSOR_OFFSETS,
> > +};
> > +
> > /*
> > * Make sure any device matches here are from most specific to most
> > * general. For example, since the Quanta match is based on the subsystem
> > @@ -406,7 +419,9 @@ static const struct intel_device_info
> > intel_skylake_info = {
> > INTEL_BDW_GT3M_IDS(&intel_broadwell_gt3m_info), \
> > INTEL_BDW_GT3D_IDS(&intel_broadwell_gt3d_info), \
> > INTEL_CHV_IDS(&intel_cherryview_info), \
> > - INTEL_SKL_IDS(&intel_skylake_info)
> > + INTEL_SKL_GT1_IDS(&intel_skylake_gt12_info),\
> > + INTEL_SKL_GT2_IDS(&intel_skylake_gt12_info),\
> > + INTEL_SKL_GT3_IDS(&intel_skylake_gt3_info) \
> >
> > static const struct pci_device_id pciidlist[] = { /* aka */
> > INTEL_PCI_IDS,
> > --
> > 1.8.3.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> But anyway patch is right!
>
> Reviewed-by: Rodrigo Vivi
>
> --
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/skl: Remove the check enforcing VCS2 to be gen8 only
On Tue, Feb 03, 2015 at 05:55:46PM -0800, Rodrigo Vivi wrote:
> Good catch!
>
> Reviewed-by: Rodrigo Vivi
>
> On Thu, Jan 29, 2015 at 6:13 AM, Damien Lespiau
> wrote:
Tiny commit messages! I've added a short blurb explaining that we track
this in intel_info already.
> > Signed-off-by: Damien Lespiau
Queued for -next, thanks for the patch.
-Daniel
> > ---
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 8 +---
> > 1 file changed, 1 insertion(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > index d393026..bbe439d 100644
> > --- a/drivers/gpu/drm/i915/intel_ringbuffer.c
> > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
> > @@ -2630,19 +2630,13 @@ int intel_init_bsd_ring_buffer(struct drm_device
> > *dev)
> > }
> >
> > /**
> > - * Initialize the second BSD ring for Broadwell GT3.
> > - * It is noted that this only exists on Broadwell GT3.
> > + * Initialize the second BSD ring (eg. Broadwell GT3, Skylake GT3)
> > */
> > int intel_init_bsd2_ring_buffer(struct drm_device *dev)
> > {
> > struct drm_i915_private *dev_priv = dev->dev_private;
> > struct intel_engine_cs *ring = &dev_priv->ring[VCS2];
> >
> > - if ((INTEL_INFO(dev)->gen != 8)) {
> > - DRM_ERROR("No dual-BSD ring on non-BDW machine\n");
> > - return -EINVAL;
> > - }
> > -
> > ring->name = "bsd2 ring";
> > ring->id = VCS2;
> >
> > --
> > 1.8.3.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] tests/gem_userptr_blits: Race between close and invalidate
On Tue, Feb 03, 2015 at 08:24:12PM +, Chris Wilson wrote: > On Tue, Feb 03, 2015 at 08:13:56PM +0100, Michał Winiarski wrote: > > It was possible for invalidate range start mmu notifier callback to race > > with releasing userptr object. If the object is released prior to > > taking a spinlock in the callback, we'll encounter a null pointer > > dereference. > > > > v2: Moved expressions inside igt_assert(), added mem barrier (Chris) > > > > Cc: Chris Wilson > > Signed-off-by: Michał Winiarski > > Lgtm, > Reviewed-by: Chris Wilson Applied, thanks. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/irq: Add drm_crtc_vblank_reset
On Tue, Feb 03, 2015 at 11:30:11AM +0100, Daniel Vetter wrote:
> At driver load we need to tell the vblank code about the state of the
> pipes, so that the logic around reject vblank_get when the pipe is off
> works correctly.
>
> Thus far i915 used drm_vblank_off, but one of the side-effects of it
> is that it also saves the vblank counter. And for that it calls down
> into the ->get_vblank_counter hook. Which isn't really a good idea
> when the pipe is off for a few reasons:
> - With runtime pm the register might not respond.
> - If the pipe is off some datastructures might not be around or
> unitialized.
>
> The later is what blew up on gen3: We look at intel_crtc->config to
> compute the vblank counter, and for a disabled pipe at boot-up that's
> just not there. Thus far this was papered over by a check for
> intel_crtc->active, but I want to get rid of that (since it's fairly
> race, vblank hooks are called from all kinds of places).
>
> So prep for that by adding a _reset functions which only does what we
> really need to be done at driver load: Mark the vblank pipe as off,
> but don't do any vblank counter saving or event flushing - neither of
> that is required.
>
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_irq.c| 32
> drivers/gpu/drm/i915/intel_display.c | 4 ++--
> include/drm/drmP.h | 1 +
> 3 files changed, 35 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
> index 75647e7f012b..1e5fb1b994d7 100644
> --- a/drivers/gpu/drm/drm_irq.c
> +++ b/drivers/gpu/drm/drm_irq.c
> @@ -1226,6 +1226,38 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc)
> EXPORT_SYMBOL(drm_crtc_vblank_off);
>
> /**
> + * drm_crtc_vblank_reset - reset vblank state to off on a CRTC
> + * @crtc: CRTC in question
> + *
> + * Drivers can use this function to reset the vblank state to off at load
> time.
> + * Drivers should use this together with the drm_crtc_vblank_off() and
> + * drm_crtc_vblank_on() functions. The diffrence comparet to
> + * drm_crtc_vblank_off() is that this function doesn't save the vblank
> counter
> + * and hence doesn't need to call any driver hooks.
> + */
> +void drm_crtc_vblank_reset(struct drm_crtc *drm_crtc)
> +{
> + struct drm_device *dev = drm_crtc->dev;
> + unsigned long irqflags;
> + int crtc = drm_crtc_index(drm_crtc);
> + struct drm_vblank_crtc *vblank = &dev->vblank[crtc];
> +
> + spin_lock_irqsave(&dev->vbl_lock, irqflags);
> + /*
> + * Prevent subsequent drm_vblank_get() from enabling the vblank
> + * interrupt by bumping the refcount.
> + */
> + if (!vblank->inmodeset) {
> + atomic_inc(&vblank->refcount);
> + vblank->inmodeset = 1;
> + }
> + spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> +
> + WARN_ON(!list_empty(&dev->vblank_event_list));
> +}
> +EXPORT_SYMBOL(drm_crtc_vblank_reset);
> +
> +/**
> * drm_vblank_on - enable vblank events on a CRTC
> * @dev: DRM device
> * @crtc: CRTC in question
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 423ef959264d..f8871a184747 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13296,9 +13296,9 @@ static void intel_sanitize_crtc(struct intel_crtc
> *crtc)
> /* restore vblank interrupts to correct state */
> if (crtc->active) {
> update_scanline_offset(crtc);
> - drm_vblank_on(dev, crtc->pipe);
> + drm_crtc_vblank_on(&crtc->base);
> } else
> - drm_vblank_off(dev, crtc->pipe);
> + drm_crtc_vblank_reset(&crtc->base);
Maybe
drm_vblank_reset()
if (active)
drm_vblank_on()
?
>
> /* We need to sanitize the plane -> pipe mapping first because this will
>* disable the crtc (and hence change the state) if it is wrong. Note
> diff --git a/include/drm/drmP.h b/include/drm/drmP.h
> index e928625a9da0..54c6ea1e5866 100644
> --- a/include/drm/drmP.h
> +++ b/include/drm/drmP.h
> @@ -922,6 +922,7 @@ extern void drm_crtc_wait_one_vblank(struct drm_crtc
> *crtc);
> extern void drm_vblank_off(struct drm_device *dev, int crtc);
> extern void drm_vblank_on(struct drm_device *dev, int crtc);
> extern void drm_crtc_vblank_off(struct drm_crtc *crtc);
> +extern void drm_crtc_vblank_reset(struct drm_crtc *crtc);
> extern void drm_crtc_vblank_on(struct drm_crtc *crtc);
> extern void drm_vblank_cleanup(struct drm_device *dev);
>
> --
> 1.9.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Ensure plane->state->fb stays in sync with plane->fb
On Tue, Feb 03, 2015 at 01:10:04PM -0800, Matt Roper wrote:
> plane->state->fb and plane->fb should always reference the same FB so
> that atomic and legacy codepaths have the same view of display state.
> In commit
>
> commit db068420560511de80ac59222644f2bdf278c3d5
> Author: Matt Roper
> Date: Fri Jan 30 16:22:36 2015 -0800
>
> drm/i915: Keep plane->state updated on pageflip
>
> we already fixed one case where these two pointers could get out of
> sync. However it turns out there are a few other places (mainly dealing
> with initial FB setup at boot) that directly set plane->fb and neglect
> to update plane->state->fb. If we never do a successful update through
> the atomic pipeline, the RmFB cleanup code will look at the
> plane->state->fb pointer, which has never actually been set to a
> legitimate value, and try to clean it up, leading to BUG's.
>
> Add a quick helper function to synchronize plane->state->fb with
> plane->fb (and update reference counts accordingly) and call it
> everywhere the driver tries to manually set plane->fb outside of the
> atomic pipeline.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88909
> Signed-off-by: Matt Roper
Unrelated thing I've spotted while reviewing this: We still update
plane->fb in our plane commit hooks, but helpers should take care of that.
Do we still have these because our code still looks at plane->fb instead
of plane->state->fb or is there some deeper reason?
I think a large-scale s/plane->fb/plane->state->fb/ and then removing
those and relying upon the fixup code in the helpers/core would be good.
Unfortunately we can't cocci this since we need to keep a few ...
Anyway, patch lgtm and is merged.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 29 ++---
> 1 file changed, 22 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 213b870..e5c0579 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2410,6 +2410,20 @@ out_unref_obj:
> return false;
> }
>
> +/* Update plane->state->fb to match plane->fb after driver-internal updates
> */
> +static void
> +update_state_fb(struct drm_plane *plane)
> +{
> + if (plane->fb == plane->state->fb)
> + return;
> +
> + if (plane->state->fb)
> + drm_framebuffer_unreference(plane->state->fb);
> + plane->state->fb = plane->fb;
> + if (plane->state->fb)
> + drm_framebuffer_reference(plane->state->fb);
> +}
> +
> static void
> intel_find_plane_obj(struct intel_crtc *intel_crtc,
>struct intel_initial_plane_config *plane_config)
> @@ -2456,6 +2470,8 @@ intel_find_plane_obj(struct intel_crtc *intel_crtc,
> break;
> }
> }
> +
> + update_state_fb(intel_crtc->base.primary);
> }
>
> static void i9xx_update_primary_plane(struct drm_crtc *crtc,
> @@ -6635,6 +6651,7 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
> plane_config->size);
>
> crtc->base.primary->fb = fb;
> + update_state_fb(crtc->base.primary);
> }
>
> static void chv_crtc_clock_get(struct intel_crtc *crtc,
> @@ -7672,6 +7689,7 @@ skylake_get_initial_plane_config(struct intel_crtc
> *crtc,
> plane_config->size);
>
> crtc->base.primary->fb = fb;
> + update_state_fb(crtc->base.primary);
> return;
>
> error:
> @@ -7763,6 +7781,7 @@ ironlake_get_initial_plane_config(struct intel_crtc
> *crtc,
> plane_config->size);
>
> crtc->base.primary->fb = fb;
> + update_state_fb(crtc->base.primary);
> }
>
> static bool ironlake_get_pipe_config(struct intel_crtc *crtc,
> @@ -9800,13 +9819,7 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
> drm_gem_object_reference(&obj->base);
>
> crtc->primary->fb = fb;
> -
> - /* Keep state structure in sync */
> - if (crtc->primary->state->fb)
> - drm_framebuffer_unreference(crtc->primary->state->fb);
> - crtc->primary->state->fb = fb;
> - if (crtc->primary->state->fb)
> - drm_framebuffer_reference(crtc->primary->state->fb);
> + update_state_fb(crtc->primary);
>
> work->pending_flip_obj = obj;
>
> @@ -9875,6 +9888,7 @@ cleanup_unpin:
> cleanup_pending:
> atomic_dec(&intel_crtc->unpin_work_count);
> crtc->primary->fb = old_fb;
> + update_state_fb(crtc->primary);
> drm_framebuffer_unreference(work->old_fb);
> drm_gem_object_unreference(&obj->base);
> mutex_unlock(&dev->struct_mutex);
> @@ -13709,6 +13723,7 @@ void intel_modeset_gem_init(struct drm_device *dev)
> to_intel_crtc(c)->pipe);
> drm_framebuffer_unreference(c->primary->fb);
> c->primary->fb = NULL;
> + up
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use frame buffer modifiers for tiled display
On 02/03/2015 07:47 PM, Daniel Vetter wrote:
On Tue, Feb 03, 2015 at 05:22:31PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Start using frame buffer modifiers instead of object tiling mode
for display purposes.
To ensure compatibility with old userspace which is using set_tiling
and does not know about frame buffer modifiers, the latter are faked
internally when tile object is set for display. This way all interested
call sites can use fb modifiers exclusively.
Also ensure tiling specified via fb modifiers must match object tiling
used for fencing if both are specified.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_display.c | 95 +---
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_pm.c | 7 +--
drivers/gpu/drm/i915/intel_sprite.c | 26 +-
4 files changed, 85 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7a3ed61..6825016 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2198,6 +2198,19 @@ intel_fb_align_height(struct drm_device *dev, int
height, unsigned int tiling)
return ALIGN(height, tile_height);
}
+static unsigned int intel_fb_modifier_to_tiling(u64 mod)
+{
+ BUILD_BUG_ON((I915_FORMAT_MOD_X_TILED & 0x00ffL) !=
+I915_TILING_X);
+
+ return mod & 1;
+}
+
+unsigned int intel_fb_tiling_mode(struct drm_framebuffer *fb)
+{
+ return intel_fb_modifier_to_tiling(fb->modifier[0]);
+}
I expect that these here will create a bit of churn with the skl patches
you have based, since I really don't want a new I915_TILING_FANCY define
in the enum space used by obj->tiling mode. But makes sense for backwards
compat with older platforms and less churn in code.
I thought we talked about effectively creating a new enum space for fb
tiling? By masking out bits from the fb modifier, no? Only thing for
backward compatibility is that object X tiling and fb X tiling == 1.
With igt for the new cases in addfb and review this is imo good to get in.
I can do the IGT, but who is doing the libdrm part? :)
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm: Add support to find drm_panel by name
For scenarios where OF is not available, we can use panel identification by
name.
v2: Use const char *name instead of name[NAME_MAX] (Thierry)
CC: Thierry Reding
Signed-off-by: Shobhit Kumar
---
drivers/gpu/drm/drm_panel.c | 18 ++
include/drm/drm_panel.h | 3 +++
2 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
index 2ef988e..7b4f559 100644
--- a/drivers/gpu/drm/drm_panel.c
+++ b/drivers/gpu/drm/drm_panel.c
@@ -95,6 +95,24 @@ struct drm_panel *of_drm_find_panel(struct device_node *np)
EXPORT_SYMBOL(of_drm_find_panel);
#endif
+struct drm_panel *drm_find_panel_by_name(const char *name)
+{
+ struct drm_panel *panel;
+
+ mutex_lock(&panel_lock);
+
+ list_for_each_entry(panel, &panel_list, list) {
+ if (panel->name && strcmp(panel->name, name) == 0) {
+ mutex_unlock(&panel_lock);
+ return panel;
+ }
+ }
+
+ mutex_unlock(&panel_lock);
+ return NULL;
+}
+EXPORT_SYMBOL(drm_find_panel_by_name);
+
MODULE_AUTHOR("Thierry Reding ");
MODULE_DESCRIPTION("DRM panel infrastructure");
MODULE_LICENSE("GPL and additional rights");
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 1fbcc96..43b9004 100644
--- a/include/drm/drm_panel.h
+++ b/include/drm/drm_panel.h
@@ -74,6 +74,7 @@ struct drm_panel {
struct drm_device *drm;
struct drm_connector *connector;
struct device *dev;
+ const char *name;
const struct drm_panel_funcs *funcs;
@@ -137,4 +138,6 @@ static inline struct drm_panel *of_drm_find_panel(struct
device_node *np)
}
#endif
+struct drm_panel *drm_find_panel_by_name(const char *name);
+
#endif
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/skl: Split the SKL PCI ids by GT
On Tue, Feb 03, 2015 at 05:51:29PM -0800, Rodrigo Vivi wrote: > On Thu, Jan 29, 2015 at 6:13 AM, Damien Lespiau > wrote: > > We need to have a separate GT3 struct intel_device_info to declare they > > have a second VCS. Let's start by splitting the PCI ids per-GT. > > > > Signed-off-by: Damien Lespiau FWIW, I'd rather not mix mechanical changes with the ones actually changing something, so will do semantic changes in separate patches. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-next
Hi Dave,
As discussed on irc one more pull for a bit of atomic goodies. Otherwise
just random all over. Plus one fixup on top of the tag because we've
accidentally broken thread-safety for the hangcheck.
drm-intel-next-2015-01-30:
- chv rps improvements from Ville
- atomic state handling prep work from Ander
- execlist request tracking refactoring from Nick Hoath
- forcewake code consolidation from Chris&Mika
- fastboot plane config refactoring and skl support from Damien
- some more skl pm patches all over (Damien)
- refactor dsi code to use drm dsi helpers and drm_panel infrastructure (Jani)
- first cut at experimental atomic plane updates (Matt Roper)
- piles of smaller things all over, as usual
From now on Jani will take care of 3.20, and apparently he already has
some fun with amdkfd conflicts ...
Cheers, Daniel
The following changes since commit 1da30627fc511a57c9bd23a02c97f0576379f761:
drm: Add rotation value to plane state (2015-01-27 18:48:53 +1000)
are available in the git repository at:
git://anongit.freedesktop.org/drm-intel drm-intel-next
for you to fetch changes up to b838cbee0d6f0234406e435032b2304f3d05515d:
drm/i915: Remove bogus locking check in the hangcheck code (2015-02-03
17:13:04 +0100)
Ander Conselvan de Oliveira (9):
drm/i915: Rename struct intel_crtc_config to intel_crtc_state
drm/i915: Embedded struct drm_crtc_state in intel_crtc_state
drm/i915: Pass new_config down do crtc_compute_clock
drm/i915: Use local pipe_config varariable when available
drm/i915: Make intel_crtc->config a pointer
drm/i915: Improve how the memory for crtc state is allocated
drm/i915: Keep drm_crtc->state in sync with intel_crtc->config
drm/i915: Split shared dpll setup out of __intel_set_mode()
drm/i915: Use pipe_config's cpu_transcoder for reading encoder hw state
Chris Wilson (9):
drm/i915: Rebalance runtime pm vs forcewake
drm/i915: Assert that runtime pm is active on user fw access
drm/i915: Skip uncore lock on earlier gens
drm/i915: Reduce duplicated forcewake logic
drm/i915: Performed deferred clflush inside set-cache-level
agp/intel: Serialise after GTT updates
drm/i915: Convert hangcheck from a timer into a delayed work item
drm/i915: Display current hangcheck status in debugfs
Revert "drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES"
Damien Lespiau (12):
drm/i915/skl: Retrieve the frequency limits
drm/i915: Change plane_config to store a tiling_mode
drm/i915: Use a common function for computing the fb height alignment
drm/i915: Unclutter the get_plane() functions
drm/i915: Don't use crtc->plane in ILK+ get_config()
drm/i915: Use pipe_name() in the get_plane_config() functions
drm/i915: Make intel_format_to_fourcc() static
drm/i915/skl: intel_format_to_fourcc() doesn't work for SKL planes
drm/i915/skl: Provide a Skylake version of get_plane_config()
drm/i915: Rename plane_config to initial_plane_config
drm/i915: Fix kzalloc() smatch warnings in get_initial_plane_config()
drm/i915: Use sizeof(*fb) not sizeof(struct ...) in
get_initial_plane_config()
Daniel Vetter (4):
drm/i915: Simplify flush_cpu_write_domain
drm/i915: Use symbolic irqreturn for ->hpd_pulse
drm/i915: Update DRIVER_DATE to 20150130
drm/i915: Remove bogus locking check in the hangcheck code
Deepak S (3):
drm/i915/chv: Populate total EU count on Cherryview
drm/i915: Increase the range of sideband address.
drm/i915: New offset for reading frequencies on CHV.
Jani Nikula (12):
drm/i915/dsi: call dpi_send_cmd() for each dsi port at a higher level
drm/i915/dsi: set max return packet size for each dsi port
drm/i915/dsi: move wait_for_dsi_fifo_empty to intel_dsi.c
drm/i915/dsi: call wait_for_dsi_fifo_empty() for each dsi port
drm/i915/dsi: remove unnecessary dsi device callbacks
drm/i915/dsi: add some constness to vbt panel driver
drm/i915/dsi: switch to drm_panel interface
drm/i915/dsi: add drm mipi dsi host support
drm/i915/dsi: make the vbt panel driver use mipi_dsi_device for transfers
drm/i915/dsi: remove old read/write functions in favor of new stuff
drm/i915/dsi: move dpi_send_cmd() to intel_dsi.c and make it static
drm/i915/dsi: remove intel_dsi_cmd.c and the unused functions therein
Jesse Barnes (1):
drm/i915/skl: add turbo support
Kumar Amit Mehta (1):
drivers: gpu: drm: i915: intel_fifo_underrun.c: Fix a typo in comment
Matt Roper (10):
drm/i915: Don't cleanup plane state in intel_plane_destroy()
drm/i915: Move rotation from intel_plane to drm_plane_state
drm/i915: Consolidate plane handler vtables
drm/i915: Add .atomic_{get, set}_property() entrypoints to planes
drm/i915: Add main atomic entrypoi
Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Also detect eDRAM on SKL
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5707 -Summary- Platform Delta drm-intel-nightly Series Applied PNV +1 282/283 283/283 ILK -3 316/319 313/319 SNB 322/346 322/346 IVB -2 382/384 380/384 BYT 296/296 296/296 HSW 425/428 425/428 BDW 318/333 318/333 -Detailed- Platform Testdrm-intel-nightly Series Applied PNV igt_gen3_render_linear_blits CRASH(1, M23)PASS(1, M25) PASS(1, M25) ILK igt_drv_suspend_fence-restore-tiled2untiled DMESG_WARN(1, M37)PASS(1, M26) DMESG_WARN(1, M37) ILK igt_drv_suspend_fence-restore-untiled DMESG_WARN(1, M37)PASS(1, M26) DMESG_WARN(1, M37) *ILK igt_kms_flip_vblank-vs-hang PASS(2, M26M37) TIMEOUT(1, M37) IVB igt_gem_pwrite_pread_snooped-pwrite-blt-cpu_mmap-performance DMESG_WARN(1, M34)PASS(1, M21) DMESG_WARN(1, M34) *IVB igt_gem_storedw_batches_loop_secure-dispatch PASS(2, M21M34) DMESG_WARN(1, M34) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [BISECTED REGRESSION in 3.19-rc1] [drm/i915] WARNING: drivers/gpu/drm/drm_irq.c:1077 drm_wait_one_vblank
Andrey Skvortsov schreef op zo 01-02-2015 om 00:16 [+0300]:
> this warning exist in v3.19-rc6 and does not in v3.18. Bisection
> points to the commit 51e31d49c890552 "drm/i915: Use generic vblank wait".
> I have two machines with integrated Intel graphics and the problem
> happens only on the old one with GM965 chipset and X3100 integrated graphics.
I see this too, since v3.19-rc1, on an (outdated) ThinkPad X41.
> backtrace information:
>
> [ 31.780813] WARNING: CPU: 0 PID: 718 at drivers/gpu/drm/drm_irq.c:1077
> drm_wait_one_vblank+0x33/0x141 [drm]()
But it also prints
vblank not available on crtc 0, ret=-22
after the WARNING line, on that machine.
> [ 31.780815] Modules linked in: ecb(E) i915(E+) snd_hda_codec_generic(E)
> coretemp(E) btusb(E) kvm_intel(E) snd_hda_intel(E) snd_hda_controller(E)
> kvm(E) drm_kms_helper(E) snd_hda_code
> c(E) snd_pcsp(E) bluetooth(E) snd_hwdep(E) drm(E) lpc_ich(E) evdev(E)
> mfd_core(E) snd_pcm(E) snd_timer(E) snd(E) psmouse(E) serio_raw(E)
> i2c_algo_bit(E) i2c_i801(E) rfkill(E) soundcore(
>
>
> E) battery(E) button(E) video(E) ac(E)
> i2ccore(E) acpi_cpufreq(E) processor(E) fuse(E) parport_pc(E) ppdev(E) lp(E)
> parport(E) autofs4(E) ext4(E) crc16(E) jbd2(E) mbcache(E) sd_mod(E) a
> ta_generic(E) ahci(E) libahci(E) sdhci_pci(E) sdhci(E) firewire_ohci(E)
> b44(E) mii(E) ssb(E) ata_piix(E) firewire_core(E) crc_itu_t(E) mmc_core(E)
> libphy(E) libata(E) scsi_mod(E) xhci_h
> cd(E) ehci_pci(E) uhci_hcd(E) ehci_hcd(E) usbcore(E) usb_common(E) thermal(E)
> [ 31.780862] thermal_sys(E)
> [ 31.780866] CPU: 0 PID: 718 Comm: kworker/u4:3 Tainted: GE
> 3.17.0-rc5-150116--00578-g51e31d4 #16
> [ 31.780868] Hardware name: Dell Inc. Vostro 1500
> /0NX907, BIOS A06 04/21/2008
> [ 31.780873] Workqueue: events_unbound async_run_entry_fn
> [ 31.780875] a0544b9d 813d4e81
>
> [ 31.780879] 8103dec3 8800d84e0068 a0521c73
> 00070008
> [ 31.780882] 8800d84e 8801973e0800
> 6014
> [ 31.780886] Call Trace:
> [ 31.780890] [] ? dump_stack+0x4a/0x75
> [ 31.780894] [] ? warn_slowpath_common+0x7e/0x97
> [ 31.781050] [] ? drm_wait_one_vblank+0x33/0x141 [drm]
> [ 31.781078] [] ? drm_wait_one_vblank+0x33/0x141 [drm]
> [ 31.781122] [] ? intel_enable_tv+0x22/0x58 [i915]
> [ 31.781153] [] ? i9xx_crtc_enable+0x33b/0x397 [i915]
> [ 31.781184] [] ? __intel_set_mode+0x1160/0x1209 [i915]
> [ 31.781216] [] ? intel_set_mode+0x12/0x2c [i915]
> [ 31.781247] [] ? intel_get_load_detect_pipe+0x367/0x408
> [i915]
> [ 31.781281] [] ? intel_tv_detect+0x103/0x444 [i915]
> [ 31.781289] [] ?
> drm_helper_probe_single_connector_modes_merge_bits+0xc0/0x327 [drm_kms_helper]
> [ 31.781296] [] ?
> drm_fb_helper_probe_connector_modes+0x3d/0x51 [drm_kms_helper]
> [ 31.781303] [] ?
> drm_fb_helper_initial_config+0x3d/0x303 [drm_kms_helper]
> [ 31.781306] [] ? async_run_entry_fn+0x5a/0x110
> [ 31.781310] [] ? process_one_work+0x194/0x292
> [ 31.781313] [] ? worker_thread+0x236/0x298
> [ 31.781316] [] ? process_scheduled_works+0x2a/0x2a
> [ 31.781319] [] ? kthread+0x9e/0xa6
> [ 31.781322] [] ? kthread_freezable_should_stop+0x36/0x36
> [ 31.781326] [] ? ret_from_fork+0x7c/0xb0
> [ 31.781329] [] ? kthread_freezable_should_stop+0x36/0x36
> [ 31.782726] ---[ end trace e2b78017f1a10054 ]---
>
>
> lspci:
>
> 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile
> GM965/GL960 Integrated Graphics Controller (primary) [8086:2a02] (rev 0c)
> 00:02.1 Display controller [0380]: Intel Corporation Mobile GM965/GL960
> Integrated Graphics Controller (secondary) [8086:2a03] (rev 0c)
A naive revert, on top of v3.19-rc7, of commit 51e31d49c890552
("drm/i915: Use generic vblank wait") clashes with later changes. It
seems intel_wait_for_vblank() became an one line inline function in a
later commit.
Anyhow, is a fix for this queued somewhere?
Thanks,
Paul Bolle
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915/skl: Split the SKL PCI ids by GT
On Tue, Feb 03, 2015 at 05:51:29PM -0800, Rodrigo Vivi wrote: > On Thu, Jan 29, 2015 at 6:13 AM, Damien Lespiau > wrote: > > We need to have a separate GT3 struct intel_device_info to declare they > > have a second VCS. Let's start by splitting the PCI ids per-GT. > > > > Signed-off-by: Damien Lespiau > > --- > > include/drm/i915_pciids.h | 28 +++- > > 1 file changed, 19 insertions(+), 9 deletions(-) > > > > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h > > index 180ad0e..38a7c80 100644 > > --- a/include/drm/i915_pciids.h > > +++ b/include/drm/i915_pciids.h > > @@ -259,21 +259,31 @@ > > INTEL_VGA_DEVICE(0x22b2, info), \ > > INTEL_VGA_DEVICE(0x22b3, info) > > > > -#define INTEL_SKL_IDS(info) \ > > - INTEL_VGA_DEVICE(0x1916, info), /* ULT GT2 */ \ > > +#define INTEL_SKL_GT1_IDS(info)\ > > INTEL_VGA_DEVICE(0x1906, info), /* ULT GT1 */ \ > > - INTEL_VGA_DEVICE(0x1926, info), /* ULT GT3 */ \ > > - INTEL_VGA_DEVICE(0x1921, info), /* ULT GT2F */ \ > > INTEL_VGA_DEVICE(0x190E, info), /* ULX GT1 */ \ > > + INTEL_VGA_DEVICE(0x1902, info), /* DT GT1 */ \ > > spec shows this id as GT2 DT That is weird, for the other ids, 0 << 4 means GT1, while GT2 are 1 << 4. Those ids have gone through review once, so 0x1902 was clearly marked as GT1 then. Could be an error in BSpec. will ask. > > > + INTEL_VGA_DEVICE(0x190B, info), /* Halo GT1 */ \ > > + INTEL_VGA_DEVICE(0x190A, info) /* SRV GT1 */ > > couldn't find those 2 on spec For these and the rest of those, I'd rather keep them in tree as they may stil be pre-production/early-adopters parts. > Also I've seem some ids there that aren't here... This is a known thing and on "purpose". > I know this patch doesn't introduce the those IDs I couldn't fine > so with 0x1902 fixed on v2 or on follow-up or explained consider this one > here: > > Reviewed-by: Rodrigo Vivi Considering the above I think we should go ahead with this patch. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3 v2] drm/i915/skl: Declare that GT3 has a second VCS
v2: leave intel_skylake_info alone (Rodrigo, Daniel)
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_drv.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 8039cec..6f4f3c5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -369,6 +369,19 @@ static const struct intel_device_info intel_skylake_info =
{
IVB_CURSOR_OFFSETS,
};
+static const struct intel_device_info intel_skylake_gt3_info = {
+ .is_preliminary = 1,
+ .is_skylake = 1,
+ .gen = 9, .num_pipes = 3,
+ .need_gfx_hws = 1, .has_hotplug = 1,
+ .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING | BSD2_RING,
+ .has_llc = 1,
+ .has_ddi = 1,
+ .has_fbc = 1,
+ GEN_DEFAULT_PIPEOFFSETS,
+ IVB_CURSOR_OFFSETS,
+};
+
/*
* Make sure any device matches here are from most specific to most
* general. For example, since the Quanta match is based on the subsystem
@@ -406,7 +419,9 @@ static const struct intel_device_info intel_skylake_info = {
INTEL_BDW_GT3M_IDS(&intel_broadwell_gt3m_info), \
INTEL_BDW_GT3D_IDS(&intel_broadwell_gt3d_info), \
INTEL_CHV_IDS(&intel_cherryview_info), \
- INTEL_SKL_IDS(&intel_skylake_info)
+ INTEL_SKL_GT1_IDS(&intel_skylake_info), \
+ INTEL_SKL_GT2_IDS(&intel_skylake_info), \
+ INTEL_SKL_GT3_IDS(&intel_skylake_gt3_info) \
static const struct pci_device_id pciidlist[] = { /* aka */
INTEL_PCI_IDS,
--
1.8.3.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Multiple declarations for intel_fbc_enabled
On Mon, 02 Feb 2015, Ed Maste wrote: > A FreeBSD developer discovered that intel_fbc_enabled has a > declaration in two headers: > > sys/dev/drm2/i915/i915_drv.h:extern bool intel_fbc_enabled(struct > drm_device *dev); > sys/dev/drm2/i915/intel_drv.h:extern bool intel_fbc_enabled(struct > drm_device *dev); > > We have a slightly older version of the i915 driver on FreeBSD, but I > see that this is still the case in Linux (although the "extern" has > been removed from one of them). Commit 85208be added the one in > intel_drv.h and didn't remove the existing one. Fixed by commit 7ff0ebcc1e30e3216c8c62ee71f59ac830b10364 Author: Rodrigo Vivi Date: Mon Dec 8 14:09:10 2014 -0200 drm/i915: Move FBC stuff to intel_fbc.c which is queued for v3.20. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] DELL Latitude e5540 Intel 4400 3rd display problem
On Mon, 02 Feb 2015, Gergely Nógrádi wrote: > I can't configure the 2nd or 3rd display on my Dell Latitude e5540 > notebook and Dell NB Port Replicator. > I tried to connect DVI, DP and VGA to Port Replicator and it is > working only in mirror mode. > The only way to use 2 external display if I connect the DVI or DP to > Port Replicator and HDMI to notebook. > I send the logs and system environment. The replicator probably needs DP MST support. Please try a newer kernel, say v3.18 or v3.19-rc7, and see what happens. Attach dmesg with drm.debug=14 module parameter set, running the new kernel. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Implementation of SKL display power well support
On Tue, Feb 03, 2015 at 01:06:31AM +0200, Imre Deak wrote:
> > +static struct i915_power_well skl_power_wells[] = {
> > + {
> > + .name = "always-on",
> > + .always_on = 1,
> > + .domains = SKL_DISPLAY_ALWAYS_ON_POWER_DOMAINS,
> > + .ops = &i9xx_always_on_power_well_ops,
> > + },
> > + {
> > + .name = "power well 1",
> > + .domains = SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS,
> > + .ops = &skl_power_well_ops,
> > + .data = SKL_DISP_PW_1,
> > + },
snip
> > + {
> > + .name = "MISC IO power well",
> > + .domains = SKL_DISPLAY_MISC_IO_POWER_DOMAINS,
> > + .ops = &skl_power_well_ops,
> > + .data = SKL_DISP_PW_MISC_IO,
> > + }
>
> Again, since the recent bspec change the misc IO power well should be
> enabled before anything else, so it needs to be listed before "power
> well 1" on the list.
So this one was causing problems. When I try to enabled MISC IO before
PW1, the request times out. Enabling MISC IO just right after PW1 seems
to work fine though.
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2 v10] drm/i915/skl: Implementation of SKL display power well support
From: Satheeshakrishna M
This patch implements core logic of SKL display power well.
v2: Addressed Imre's comments
- Added respective DDIs under power well #1 and #2
- Simplified repetitive code in power well programming
v3: Implemented Imre's comments
- Further simplified power well programming
- Made sure that PW 1 is enabled prior to PW 2
v4: Fix minor conflict with the the cherryview support (Damien)
v5: Add the PLL power domain to the always on power well (Damien)
v6: Disable BIOS power well (Imre)
Use power well data for comparison (Imre)
Put the PLL power domain into PW1 as its needed for CDCLK (Satheesh,
Damien)
v7: Addressed Imre's comments
- Lowered the time out to 1ms
- Added parantheses in macro
- Moved debug message and fixed wait_for interval
v8:
- Add a WARN() when swiching on an unknown power well (Imre, done by Damien)
- Whitespace fixes (spaces instead of tabs) (Damien)
v9: (Imre, done by Damien)
- Merge the register definitions with this patch
- Merge the MISC IO power well in this patch
v10: (Imre, done by Damien)
- Define the Misc I/O power domains to be the power well 1 ones as Misc I/O
needs to be enabled with PW1
- Added Transcoder A and VGA domains to PW 2
- Remove the MISC_IO power domains as well in the the always on
domains definition
- Move Misc I/O power well at the top of the power well list so it's turned
on right after PW1.
Reviewed-by: Imre Deak
Signed-off-by: Satheeshakrishna M (v3,v6,v7)
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_reg.h | 20 +++
drivers/gpu/drm/i915/intel_runtime_pm.c | 220
2 files changed, 240 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 33b3d0a2..cd3430f9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -586,6 +586,19 @@ enum punit_power_well {
PUNIT_POWER_WELL_NUM,
};
+enum skl_disp_power_wells {
+ SKL_DISP_PW_MISC_IO,
+ SKL_DISP_PW_DDI_A_E,
+ SKL_DISP_PW_DDI_B,
+ SKL_DISP_PW_DDI_C,
+ SKL_DISP_PW_DDI_D,
+ SKL_DISP_PW_1 = 14,
+ SKL_DISP_PW_2,
+};
+
+#define SKL_POWER_WELL_STATE(pw) (1 << ((pw) * 2))
+#define SKL_POWER_WELL_REQ(pw) (1 << (((pw) * 2) + 1))
+
#define PUNIT_REG_PWRGT_CTRL 0x60
#define PUNIT_REG_PWRGT_STATUS 0x61
#define PUNIT_PWRGT_MASK(power_well) (3 << ((power_well) * 2))
@@ -6351,6 +6364,13 @@ enum punit_power_well {
#define HSW_PWR_WELL_FORCE_ON(1<<19)
#define HSW_PWR_WELL_CTL6 0x45414
+/* SKL Fuse Status */
+#define SKL_FUSE_STATUS0x42000
+#define SKL_FUSE_DOWNLOAD_STATUS (1<<31)
+#define SKL_FUSE_PG0_DIST_STATUS (1<<27)
+#define SKL_FUSE_PG1_DIST_STATUS (1<<26)
+#define SKL_FUSE_PG2_DIST_STATUS (1<<25)
+
/* Per-pipe DDI Function Control */
#define TRANS_DDI_FUNC_CTL_A 0x60400
#define TRANS_DDI_FUNC_CTL_B 0x61400
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 49695d7..6d8e29a 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -230,6 +230,136 @@ static void hsw_set_power_well(struct drm_i915_private
*dev_priv,
}
}
+#define SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS (\
+ BIT(POWER_DOMAIN_TRANSCODER_A) |\
+ BIT(POWER_DOMAIN_PIPE_B) | \
+ BIT(POWER_DOMAIN_TRANSCODER_B) |\
+ BIT(POWER_DOMAIN_PIPE_C) | \
+ BIT(POWER_DOMAIN_TRANSCODER_C) |\
+ BIT(POWER_DOMAIN_PIPE_B_PANEL_FITTER) | \
+ BIT(POWER_DOMAIN_PIPE_C_PANEL_FITTER) | \
+ BIT(POWER_DOMAIN_PORT_DDI_B_2_LANES) | \
+ BIT(POWER_DOMAIN_PORT_DDI_B_4_LANES) | \
+ BIT(POWER_DOMAIN_PORT_DDI_C_2_LANES) | \
+ BIT(POWER_DOMAIN_PORT_DDI_C_4_LANES) | \
+ BIT(POWER_DOMAIN_PORT_DDI_D_2_LANES) | \
+ BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) | \
+ BIT(POWER_DOMAIN_AUX_B) | \
+ BIT(POWER_DOMAIN_AUX_C) | \
+ BIT(POWER_DOMAIN_AUX_D) | \
+ BIT(POWER_DOMAIN_AUDIO) | \
+ BIT(POWER_DOMAIN_VGA) | \
+ BIT(POWER_DOMAIN_INIT))
+#define SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS (\
+ SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS | \
+ BIT(POWER_DOMAIN_PLLS) |\
+ BIT(POWER_DOMAIN_PIPE_A) | \
+ BIT(POWER_DOMAIN_TRANSCODER_EDP) | \
+ BIT(POWER_DOMAIN_PIPE_A_PANEL_FITTER) | \
+ BIT(POWER_DOMAIN_PORT_DDI_A_2_
Re: [Intel-gfx] [PATCH] drm: Add support to find drm_panel by name
Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang...@intel.com) Task id: 5711 -Summary- Platform Delta drm-intel-nightly Series Applied PNV +1 282/283 283/283 ILK -1 316/319 315/319 SNB 322/346 322/346 IVB -2 382/384 380/384 BYT 296/296 296/296 HSW 425/428 425/428 BDW 318/333 318/333 -Detailed- Platform Testdrm-intel-nightly Series Applied PNV igt_gen3_render_linear_blits CRASH(1, M23)PASS(2, M25M23) PASS(1, M23) *ILK igt_kms_flip_rcs-flip-vs-panning-interruptible PASS(2, M26) DMESG_WARN(1, M26) IVB igt_gem_pwrite_pread_snooped-pwrite-blt-cpu_mmap-performance DMESG_WARN(2, M34)PASS(1, M21) DMESG_WARN(1, M34) *IVB igt_gem_storedw_batches_loop_secure-dispatch PASS(3, M21M34) DMESG_WARN(1, M34) Note: You need to pay more attention to line start with '*' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2 v10] drm/i915/skl: Implementation of SKL display power well support
On Wed, Feb 04, 2015 at 01:57:44PM +, Damien Lespiau wrote:
> From: Satheeshakrishna M
>
> This patch implements core logic of SKL display power well.
>
> v2: Addressed Imre's comments
> - Added respective DDIs under power well #1 and #2
> - Simplified repetitive code in power well programming
>
> v3: Implemented Imre's comments
> - Further simplified power well programming
> - Made sure that PW 1 is enabled prior to PW 2
>
> v4: Fix minor conflict with the the cherryview support (Damien)
>
> v5: Add the PLL power domain to the always on power well (Damien)
>
> v6: Disable BIOS power well (Imre)
> Use power well data for comparison (Imre)
> Put the PLL power domain into PW1 as its needed for CDCLK (Satheesh,
> Damien)
>
> v7: Addressed Imre's comments
> - Lowered the time out to 1ms
> - Added parantheses in macro
> - Moved debug message and fixed wait_for interval
>
> v8:
> - Add a WARN() when swiching on an unknown power well (Imre, done by Damien)
> - Whitespace fixes (spaces instead of tabs) (Damien)
>
> v9: (Imre, done by Damien)
> - Merge the register definitions with this patch
> - Merge the MISC IO power well in this patch
>
> v10: (Imre, done by Damien)
>
> - Define the Misc I/O power domains to be the power well 1 ones as Misc I/O
> needs to be enabled with PW1
> - Added Transcoder A and VGA domains to PW 2
> - Remove the MISC_IO power domains as well in the the always on
> domains definition
> - Move Misc I/O power well at the top of the power well list so it's turned
> on right after PW1.
>
> Reviewed-by: Imre Deak
> Signed-off-by: Satheeshakrishna M (v3,v6,v7)
> Signed-off-by: Damien Lespiau
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_reg.h | 20 +++
> drivers/gpu/drm/i915/intel_runtime_pm.c | 220
>
> 2 files changed, 240 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 33b3d0a2..cd3430f9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -586,6 +586,19 @@ enum punit_power_well {
> PUNIT_POWER_WELL_NUM,
> };
>
> +enum skl_disp_power_wells {
> + SKL_DISP_PW_MISC_IO,
> + SKL_DISP_PW_DDI_A_E,
> + SKL_DISP_PW_DDI_B,
> + SKL_DISP_PW_DDI_C,
> + SKL_DISP_PW_DDI_D,
> + SKL_DISP_PW_1 = 14,
> + SKL_DISP_PW_2,
> +};
> +
> +#define SKL_POWER_WELL_STATE(pw) (1 << ((pw) * 2))
> +#define SKL_POWER_WELL_REQ(pw) (1 << (((pw) * 2) + 1))
> +
> #define PUNIT_REG_PWRGT_CTRL 0x60
> #define PUNIT_REG_PWRGT_STATUS 0x61
> #define PUNIT_PWRGT_MASK(power_well) (3 << ((power_well) *
> 2))
> @@ -6351,6 +6364,13 @@ enum punit_power_well {
> #define HSW_PWR_WELL_FORCE_ON (1<<19)
> #define HSW_PWR_WELL_CTL60x45414
>
> +/* SKL Fuse Status */
> +#define SKL_FUSE_STATUS 0x42000
> +#define SKL_FUSE_DOWNLOAD_STATUS (1<<31)
> +#define SKL_FUSE_PG0_DIST_STATUS (1<<27)
> +#define SKL_FUSE_PG1_DIST_STATUS (1<<26)
> +#define SKL_FUSE_PG2_DIST_STATUS (1<<25)
> +
> /* Per-pipe DDI Function Control */
> #define TRANS_DDI_FUNC_CTL_A 0x60400
> #define TRANS_DDI_FUNC_CTL_B 0x61400
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 49695d7..6d8e29a 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -230,6 +230,136 @@ static void hsw_set_power_well(struct drm_i915_private
> *dev_priv,
> }
> }
>
> +#define SKL_DISPLAY_POWERWELL_2_POWER_DOMAINS ( \
> + BIT(POWER_DOMAIN_TRANSCODER_A) |\
> + BIT(POWER_DOMAIN_PIPE_B) | \
> + BIT(POWER_DOMAIN_TRANSCODER_B) |\
> + BIT(POWER_DOMAIN_PIPE_C) | \
> + BIT(POWER_DOMAIN_TRANSCODER_C) |\
> + BIT(POWER_DOMAIN_PIPE_B_PANEL_FITTER) | \
> + BIT(POWER_DOMAIN_PIPE_C_PANEL_FITTER) | \
> + BIT(POWER_DOMAIN_PORT_DDI_B_2_LANES) | \
> + BIT(POWER_DOMAIN_PORT_DDI_B_4_LANES) | \
> + BIT(POWER_DOMAIN_PORT_DDI_C_2_LANES) | \
> + BIT(POWER_DOMAIN_PORT_DDI_C_4_LANES) | \
> + BIT(POWER_DOMAIN_PORT_DDI_D_2_LANES) | \
> + BIT(POWER_DOMAIN_PORT_DDI_D_4_LANES) | \
> + BIT(POWER_DOMAIN_AUX_B) | \
> + BIT(POWER_DOMAIN_AUX_C) | \
> + BIT(POWER_DOMAIN_AUX_D) | \
> + BIT(POWER_DOMAIN_AUDIO) | \
> + BIT(POWER_DOMAIN_VGA) | \
> + BIT(POWER_DOMAIN_INIT))
> +#define SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS ( \
> + SKL_DISPLAY_POWERWELL_2_PO
Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Implementation of SKL display power well support
On ke, 2015-02-04 at 13:53 +, Damien Lespiau wrote:
> On Tue, Feb 03, 2015 at 01:06:31AM +0200, Imre Deak wrote:
> > > +static struct i915_power_well skl_power_wells[] = {
> > > + {
> > > + .name = "always-on",
> > > + .always_on = 1,
> > > + .domains = SKL_DISPLAY_ALWAYS_ON_POWER_DOMAINS,
> > > + .ops = &i9xx_always_on_power_well_ops,
> > > + },
> > > + {
> > > + .name = "power well 1",
> > > + .domains = SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS,
> > > + .ops = &skl_power_well_ops,
> > > + .data = SKL_DISP_PW_1,
> > > + },
>
> snip
>
> > > + {
> > > + .name = "MISC IO power well",
> > > + .domains = SKL_DISPLAY_MISC_IO_POWER_DOMAINS,
> > > + .ops = &skl_power_well_ops,
> > > + .data = SKL_DISP_PW_MISC_IO,
> > > + }
> >
> > Again, since the recent bspec change the misc IO power well should be
> > enabled before anything else, so it needs to be listed before "power
> > well 1" on the list.
>
> So this one was causing problems. When I try to enabled MISC IO before
> PW1, the request times out. Enabling MISC IO just right after PW1 seems
> to work fine though.
Ok. Bspec doesn't say anything about the ordering between PW1 and MISC
IO, just that you have to enable them together and wait for PG1 fuse
afterwards. How about then moving the MISC IO power well right after PW1
in the list and wait for the PG1 fuse after enabling MISC IO?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use frame buffer modifiers for tiled display
On Wed, Feb 04, 2015 at 10:01:45AM +, Tvrtko Ursulin wrote:
>
> On 02/03/2015 07:47 PM, Daniel Vetter wrote:
> >On Tue, Feb 03, 2015 at 05:22:31PM +, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin
> >>
> >>Start using frame buffer modifiers instead of object tiling mode
> >>for display purposes.
> >>
> >>To ensure compatibility with old userspace which is using set_tiling
> >>and does not know about frame buffer modifiers, the latter are faked
> >>internally when tile object is set for display. This way all interested
> >>call sites can use fb modifiers exclusively.
> >>
> >>Also ensure tiling specified via fb modifiers must match object tiling
> >>used for fencing if both are specified.
> >>
> >>Signed-off-by: Tvrtko Ursulin
> >>---
> >> drivers/gpu/drm/i915/intel_display.c | 95
> >> +---
> >> drivers/gpu/drm/i915/intel_drv.h | 2 +
> >> drivers/gpu/drm/i915/intel_pm.c | 7 +--
> >> drivers/gpu/drm/i915/intel_sprite.c | 26 +-
> >> 4 files changed, 85 insertions(+), 45 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/intel_display.c
> >>b/drivers/gpu/drm/i915/intel_display.c
> >>index 7a3ed61..6825016 100644
> >>--- a/drivers/gpu/drm/i915/intel_display.c
> >>+++ b/drivers/gpu/drm/i915/intel_display.c
> >>@@ -2198,6 +2198,19 @@ intel_fb_align_height(struct drm_device *dev, int
> >>height, unsigned int tiling)
> >>return ALIGN(height, tile_height);
> >> }
> >>
> >>+static unsigned int intel_fb_modifier_to_tiling(u64 mod)
> >>+{
> >>+ BUILD_BUG_ON((I915_FORMAT_MOD_X_TILED & 0x00ffL) !=
> >>+I915_TILING_X);
> >>+
> >>+ return mod & 1;
> >>+}
> >>+
> >>+unsigned int intel_fb_tiling_mode(struct drm_framebuffer *fb)
> >>+{
> >>+ return intel_fb_modifier_to_tiling(fb->modifier[0]);
> >>+}
> >
> >I expect that these here will create a bit of churn with the skl patches
> >you have based, since I really don't want a new I915_TILING_FANCY define
> >in the enum space used by obj->tiling mode. But makes sense for backwards
> >compat with older platforms and less churn in code.
>
> I thought we talked about effectively creating a new enum space for fb
> tiling? By masking out bits from the fb modifier, no? Only thing for
> backward compatibility is that object X tiling and fb X tiling == 1.
intel_fb_tiling_mode maps modifier (the new enum space) to
obj->tiling_mode (the old enum space). Means a notch less churn in legacy
code (but if that's the metric I'd just have kept using obj->tiling_mode
there). But means that you get to chance skl code twice, because I very
much don't want a new I915_TILING_DEFINE but instead the skl code should
check the new modifiers directly. Otherwise we can mash up tiling modes
valid just for ggtt fencing and fb modifiers in general.
Maybe I wasn't really clear with what I've meant ...
> >With igt for the new cases in addfb and review this is imo good to get in.
>
> I can do the IGT, but who is doing the libdrm part? :)
Generally when we do igts for new interfaces we just copypaste the new
struct definitions with local_ prefixed to avoid blocking the test on a
new libdrm release. So no one needs to do a libdrm patch ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Implementation of SKL display power well support
On Wed, Feb 04, 2015 at 04:20:28PM +0200, Imre Deak wrote:
> On ke, 2015-02-04 at 13:53 +, Damien Lespiau wrote:
> > On Tue, Feb 03, 2015 at 01:06:31AM +0200, Imre Deak wrote:
> > > > +static struct i915_power_well skl_power_wells[] = {
> > > > + {
> > > > + .name = "always-on",
> > > > + .always_on = 1,
> > > > + .domains = SKL_DISPLAY_ALWAYS_ON_POWER_DOMAINS,
> > > > + .ops = &i9xx_always_on_power_well_ops,
> > > > + },
> > > > + {
> > > > + .name = "power well 1",
> > > > + .domains = SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS,
> > > > + .ops = &skl_power_well_ops,
> > > > + .data = SKL_DISP_PW_1,
> > > > + },
> >
> > snip
> >
> > > > + {
> > > > + .name = "MISC IO power well",
> > > > + .domains = SKL_DISPLAY_MISC_IO_POWER_DOMAINS,
> > > > + .ops = &skl_power_well_ops,
> > > > + .data = SKL_DISP_PW_MISC_IO,
> > > > + }
> > >
> > > Again, since the recent bspec change the misc IO power well should be
> > > enabled before anything else, so it needs to be listed before "power
> > > well 1" on the list.
> >
> > So this one was causing problems. When I try to enabled MISC IO before
> > PW1, the request times out. Enabling MISC IO just right after PW1 seems
> > to work fine though.
>
> Ok. Bspec doesn't say anything about the ordering between PW1 and MISC
> IO, just that you have to enable them together and wait for PG1 fuse
> afterwards. How about then moving the MISC IO power well right after PW1
> in the list and wait for the PG1 fuse after enabling MISC IO?
I think we can even set the 2 requests in the same write and it should
do the right thing (and so merge the two power wells). That's really a
detail though and as the current code it seems to work, I'll leave such
refinements for later/if needed.
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Implementation of SKL display power well support
On ke, 2015-02-04 at 16:20 +0200, Imre Deak wrote:
> On ke, 2015-02-04 at 13:53 +, Damien Lespiau wrote:
> > On Tue, Feb 03, 2015 at 01:06:31AM +0200, Imre Deak wrote:
> > > > +static struct i915_power_well skl_power_wells[] = {
> > > > + {
> > > > + .name = "always-on",
> > > > + .always_on = 1,
> > > > + .domains = SKL_DISPLAY_ALWAYS_ON_POWER_DOMAINS,
> > > > + .ops = &i9xx_always_on_power_well_ops,
> > > > + },
> > > > + {
> > > > + .name = "power well 1",
> > > > + .domains = SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS,
> > > > + .ops = &skl_power_well_ops,
> > > > + .data = SKL_DISP_PW_1,
> > > > + },
> >
> > snip
> >
> > > > + {
> > > > + .name = "MISC IO power well",
> > > > + .domains = SKL_DISPLAY_MISC_IO_POWER_DOMAINS,
> > > > + .ops = &skl_power_well_ops,
> > > > + .data = SKL_DISP_PW_MISC_IO,
> > > > + }
> > >
> > > Again, since the recent bspec change the misc IO power well should be
> > > enabled before anything else, so it needs to be listed before "power
> > > well 1" on the list.
> >
> > So this one was causing problems. When I try to enabled MISC IO before
> > PW1, the request times out. Enabling MISC IO just right after PW1 seems
> > to work fine though.
>
> Ok. Bspec doesn't say anything about the ordering between PW1 and MISC
> IO, just that you have to enable them together and wait for PG1 fuse
> afterwards. How about then moving the MISC IO power well right after PW1
> in the list and wait for the PG1 fuse after enabling MISC IO?
Ah, haven't noticed v10, it looks ok to me.
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/skl: Implementation of SKL display power well support
On ke, 2015-02-04 at 14:24 +, Damien Lespiau wrote:
> On Wed, Feb 04, 2015 at 04:20:28PM +0200, Imre Deak wrote:
> > On ke, 2015-02-04 at 13:53 +, Damien Lespiau wrote:
> > > On Tue, Feb 03, 2015 at 01:06:31AM +0200, Imre Deak wrote:
> > > > > +static struct i915_power_well skl_power_wells[] = {
> > > > > + {
> > > > > + .name = "always-on",
> > > > > + .always_on = 1,
> > > > > + .domains = SKL_DISPLAY_ALWAYS_ON_POWER_DOMAINS,
> > > > > + .ops = &i9xx_always_on_power_well_ops,
> > > > > + },
> > > > > + {
> > > > > + .name = "power well 1",
> > > > > + .domains = SKL_DISPLAY_POWERWELL_1_POWER_DOMAINS,
> > > > > + .ops = &skl_power_well_ops,
> > > > > + .data = SKL_DISP_PW_1,
> > > > > + },
> > >
> > > snip
> > >
> > > > > + {
> > > > > + .name = "MISC IO power well",
> > > > > + .domains = SKL_DISPLAY_MISC_IO_POWER_DOMAINS,
> > > > > + .ops = &skl_power_well_ops,
> > > > > + .data = SKL_DISP_PW_MISC_IO,
> > > > > + }
> > > >
> > > > Again, since the recent bspec change the misc IO power well should be
> > > > enabled before anything else, so it needs to be listed before "power
> > > > well 1" on the list.
> > >
> > > So this one was causing problems. When I try to enabled MISC IO before
> > > PW1, the request times out. Enabling MISC IO just right after PW1 seems
> > > to work fine though.
> >
> > Ok. Bspec doesn't say anything about the ordering between PW1 and MISC
> > IO, just that you have to enable them together and wait for PG1 fuse
> > afterwards. How about then moving the MISC IO power well right after PW1
> > in the list and wait for the PG1 fuse after enabling MISC IO?
>
> I think we can even set the 2 requests in the same write and it should
> do the right thing (and so merge the two power wells). That's really a
> detail though and as the current code it seems to work, I'll leave such
> refinements for later/if needed.
Yes, I had the same thought, agreed that it could be done as a
follow-up.
--Imre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use frame buffer modifiers for tiled display
On 02/04/2015 02:25 PM, Daniel Vetter wrote:
On Wed, Feb 04, 2015 at 10:01:45AM +, Tvrtko Ursulin wrote:
On 02/03/2015 07:47 PM, Daniel Vetter wrote:
On Tue, Feb 03, 2015 at 05:22:31PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Start using frame buffer modifiers instead of object tiling mode
for display purposes.
To ensure compatibility with old userspace which is using set_tiling
and does not know about frame buffer modifiers, the latter are faked
internally when tile object is set for display. This way all interested
call sites can use fb modifiers exclusively.
Also ensure tiling specified via fb modifiers must match object tiling
used for fencing if both are specified.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_display.c | 95 +---
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_pm.c | 7 +--
drivers/gpu/drm/i915/intel_sprite.c | 26 +-
4 files changed, 85 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7a3ed61..6825016 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2198,6 +2198,19 @@ intel_fb_align_height(struct drm_device *dev, int
height, unsigned int tiling)
return ALIGN(height, tile_height);
}
+static unsigned int intel_fb_modifier_to_tiling(u64 mod)
+{
+ BUILD_BUG_ON((I915_FORMAT_MOD_X_TILED & 0x00ffL) !=
+I915_TILING_X);
+
+ return mod & 1;
+}
+
+unsigned int intel_fb_tiling_mode(struct drm_framebuffer *fb)
+{
+ return intel_fb_modifier_to_tiling(fb->modifier[0]);
+}
I expect that these here will create a bit of churn with the skl patches
you have based, since I really don't want a new I915_TILING_FANCY define
in the enum space used by obj->tiling mode. But makes sense for backwards
compat with older platforms and less churn in code.
I thought we talked about effectively creating a new enum space for fb
tiling? By masking out bits from the fb modifier, no? Only thing for
backward compatibility is that object X tiling and fb X tiling == 1.
intel_fb_tiling_mode maps modifier (the new enum space) to
obj->tiling_mode (the old enum space). Means a notch less churn in legacy
code (but if that's the metric I'd just have kept using obj->tiling_mode
there). But means that you get to chance skl code twice, because I very
much don't want a new I915_TILING_DEFINE but instead the skl code should
check the new modifiers directly. Otherwise we can mash up tiling modes
valid just for ggtt fencing and fb modifiers in general.
Maybe I wasn't really clear with what I've meant ...
It does seem it is taking very long to get on the same page here. :/
I did not plan to add new I915_TILING_xxx. I was exploiting the fact
both map to the same value, with masking. So legacy continues to work
since this will be true forever. (ABI)
Then the plan was to add a new namespace for display tiling enums.
This was since fb modifier could contain more than tiling and this way
it is possible to mask out and case-switch just as the current code does.
There are three namespaces here:
1. I915_TILING_xxx
2. I915_FORMAT_MOD_ (fb modifiers)
3. Tiling as programmed to display hardware
And then add a fourth one:
4. I915_DISPLAY_TILING_xxx
At this step also add something like I915_FORMAT_MOD_TILING_MASK and
redefine I915_FORMAT_MOD_X_TILE to be fourcc_mod(INTEL,
I915_DISPLAY_TILING_X). (Instead of hardcoded 1)
At call sites (opencoded):
switch (fb->modifier[0] & I915_FORMAT_MOD_TILING) {
case I915_DISPLAY_TILING_X:
...
I mean we could do:
switch (fb->modifier[0]) {
case I915_FORMAT_MOD_X_TILE:
...
If fb modifiers won't have any overlap, like for example:
#define I915_FORMAT_MOD_X_TILE fourcc_mod(INTEL, 1)
#define I915_FORMAT_MOD_X_TILE_AND_UNRELATED fourcc_mod(INTEL, 1<<8 && 1)
Then the direct usage stops working..
Up to you, I have to unblock other stuff so we can't strangle this for
too long.
With igt for the new cases in addfb and review this is imo good to get in.
I can do the IGT, but who is doing the libdrm part? :)
Generally when we do igts for new interfaces we just copypaste the new
struct definitions with local_ prefixed to avoid blocking the test on a
new libdrm release. So no one needs to do a libdrm patch ;-)
Okay I can do that. Even better that's what I already did. :)
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use frame buffer modifiers for tiled display
On Wed, Feb 04, 2015 at 03:09:38PM +, Tvrtko Ursulin wrote:
> On 02/04/2015 02:25 PM, Daniel Vetter wrote:
> >On Wed, Feb 04, 2015 at 10:01:45AM +, Tvrtko Ursulin wrote:
> >>
> >>On 02/03/2015 07:47 PM, Daniel Vetter wrote:
> >>>On Tue, Feb 03, 2015 at 05:22:31PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Start using frame buffer modifiers instead of object tiling mode
> for display purposes.
>
> To ensure compatibility with old userspace which is using set_tiling
> and does not know about frame buffer modifiers, the latter are faked
> internally when tile object is set for display. This way all interested
> call sites can use fb modifiers exclusively.
>
> Also ensure tiling specified via fb modifiers must match object tiling
> used for fencing if both are specified.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/intel_display.c | 95
> +---
> drivers/gpu/drm/i915/intel_drv.h | 2 +
> drivers/gpu/drm/i915/intel_pm.c | 7 +--
> drivers/gpu/drm/i915/intel_sprite.c | 26 +-
> 4 files changed, 85 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 7a3ed61..6825016 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2198,6 +2198,19 @@ intel_fb_align_height(struct drm_device *dev, int
> height, unsigned int tiling)
> return ALIGN(height, tile_height);
> }
>
> +static unsigned int intel_fb_modifier_to_tiling(u64 mod)
> +{
> + BUILD_BUG_ON((I915_FORMAT_MOD_X_TILED & 0x00ffL) !=
> + I915_TILING_X);
> +
> + return mod & 1;
> +}
> +
> +unsigned int intel_fb_tiling_mode(struct drm_framebuffer *fb)
> +{
> + return intel_fb_modifier_to_tiling(fb->modifier[0]);
> +}
> >>>
> >>>I expect that these here will create a bit of churn with the skl patches
> >>>you have based, since I really don't want a new I915_TILING_FANCY define
> >>>in the enum space used by obj->tiling mode. But makes sense for backwards
> >>>compat with older platforms and less churn in code.
> >>
> >>I thought we talked about effectively creating a new enum space for fb
> >>tiling? By masking out bits from the fb modifier, no? Only thing for
> >>backward compatibility is that object X tiling and fb X tiling == 1.
> >
> >intel_fb_tiling_mode maps modifier (the new enum space) to
> >obj->tiling_mode (the old enum space). Means a notch less churn in legacy
> >code (but if that's the metric I'd just have kept using obj->tiling_mode
> >there). But means that you get to chance skl code twice, because I very
> >much don't want a new I915_TILING_DEFINE but instead the skl code should
> >check the new modifiers directly. Otherwise we can mash up tiling modes
> >valid just for ggtt fencing and fb modifiers in general.
> >
> >Maybe I wasn't really clear with what I've meant ...
>
> It does seem it is taking very long to get on the same page here. :/
>
> I did not plan to add new I915_TILING_xxx. I was exploiting the fact both
> map to the same value, with masking. So legacy continues to work since this
> will be true forever. (ABI)
>
> Then the plan was to add a new namespace for display tiling enums.
>
> This was since fb modifier could contain more than tiling and this way it is
> possible to mask out and case-switch just as the current code does.
>
> There are three namespaces here:
>
> 1. I915_TILING_xxx
> 2. I915_FORMAT_MOD_ (fb modifiers)
> 3. Tiling as programmed to display hardware
>
> And then add a fourth one:
>
> 4. I915_DISPLAY_TILING_xxx
>
> At this step also add something like I915_FORMAT_MOD_TILING_MASK and
> redefine I915_FORMAT_MOD_X_TILE to be fourcc_mod(INTEL,
> I915_DISPLAY_TILING_X). (Instead of hardcoded 1)
>
> At call sites (opencoded):
>
> switch (fb->modifier[0] & I915_FORMAT_MOD_TILING) {
> case I915_DISPLAY_TILING_X:
This is kinda what I'd have done, expect that you can cleverly define the
mask to include the vendor prefix, i.e.
#define I915_FORMAT_MOD_TILING_MASK ((0xff << 56) | 0xff)
and then you don't need yet another set of defines. And still have the
clear separation between I915_TILING_FOO and the new fb modifier stuff.
> ...
>
> I mean we could do:
>
> switch (fb->modifier[0]) {
> case I915_FORMAT_MOD_X_TILE:
Or this. Since we don't yet have anything else than tiling modes you'll
get away with it and can postpone the mask stuff to whomever ends up
implementing the non-tiling fb modifiers.
> ...
>
> If fb modifiers won't have any overlap, like for example:
>
> #define I915_FORMAT_MOD_X_TILE fourcc_mod(INTEL, 1)
> #define I915_FORMAT_MOD_X_TILE_AND_UNRELATED fourcc_mod(INTEL, 1<<8 && 1)
>
> Then the direct usage stops working..
>
> Up to you, I have to unblock other
Re: [Intel-gfx] [PATCH 1/3] drm/i915/skl: Split the SKL PCI ids by GT
On Wed, Feb 4, 2015 at 5:10 AM, Damien Lespiau wrote: > On Tue, Feb 03, 2015 at 05:51:29PM -0800, Rodrigo Vivi wrote: >> On Thu, Jan 29, 2015 at 6:13 AM, Damien Lespiau >> wrote: >> > We need to have a separate GT3 struct intel_device_info to declare they >> > have a second VCS. Let's start by splitting the PCI ids per-GT. >> > >> > Signed-off-by: Damien Lespiau >> > --- >> > include/drm/i915_pciids.h | 28 +++- >> > 1 file changed, 19 insertions(+), 9 deletions(-) >> > >> > diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h >> > index 180ad0e..38a7c80 100644 >> > --- a/include/drm/i915_pciids.h >> > +++ b/include/drm/i915_pciids.h >> > @@ -259,21 +259,31 @@ >> > INTEL_VGA_DEVICE(0x22b2, info), \ >> > INTEL_VGA_DEVICE(0x22b3, info) >> > >> > -#define INTEL_SKL_IDS(info) \ >> > - INTEL_VGA_DEVICE(0x1916, info), /* ULT GT2 */ \ >> > +#define INTEL_SKL_GT1_IDS(info)\ >> > INTEL_VGA_DEVICE(0x1906, info), /* ULT GT1 */ \ >> > - INTEL_VGA_DEVICE(0x1926, info), /* ULT GT3 */ \ >> > - INTEL_VGA_DEVICE(0x1921, info), /* ULT GT2F */ \ >> > INTEL_VGA_DEVICE(0x190E, info), /* ULX GT1 */ \ >> > + INTEL_VGA_DEVICE(0x1902, info), /* DT GT1 */ \ >> >> spec shows this id as GT2 DT > > That is weird, for the other ids, 0 << 4 means GT1, while GT2 are 1 << 4. > > Those ids have gone through review once, so 0x1902 was clearly marked as > GT1 then. Could be an error in BSpec. will ask. > >> >> > + INTEL_VGA_DEVICE(0x190B, info), /* Halo GT1 */ \ >> > + INTEL_VGA_DEVICE(0x190A, info) /* SRV GT1 */ >> >> couldn't find those 2 on spec > > For these and the rest of those, I'd rather keep them in tree as they > may stil be pre-production/early-adopters parts. > >> Also I've seem some ids there that aren't here... > > This is a known thing and on "purpose". > >> I know this patch doesn't introduce the those IDs I couldn't fine >> so with 0x1902 fixed on v2 or on follow-up or explained consider this one >> here: >> >> Reviewed-by: Rodrigo Vivi > > Considering the above I think we should go ahead with this patch. Agree! > > -- > Damien -- Rodrigo Vivi Blog: http://blog.vivi.eng.br ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3 v2] drm/i915/skl: Declare that GT3 has a second VCS
just reinforcing..
Reviewed-by: Rodrigo Vivi
On Wed, Feb 4, 2015 at 5:22 AM, Damien Lespiau wrote:
> v2: leave intel_skylake_info alone (Rodrigo, Daniel)
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/i915_drv.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 8039cec..6f4f3c5 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -369,6 +369,19 @@ static const struct intel_device_info intel_skylake_info
> = {
> IVB_CURSOR_OFFSETS,
> };
>
> +static const struct intel_device_info intel_skylake_gt3_info = {
> + .is_preliminary = 1,
> + .is_skylake = 1,
> + .gen = 9, .num_pipes = 3,
> + .need_gfx_hws = 1, .has_hotplug = 1,
> + .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING |
> BSD2_RING,
> + .has_llc = 1,
> + .has_ddi = 1,
> + .has_fbc = 1,
> + GEN_DEFAULT_PIPEOFFSETS,
> + IVB_CURSOR_OFFSETS,
> +};
> +
> /*
> * Make sure any device matches here are from most specific to most
> * general. For example, since the Quanta match is based on the subsystem
> @@ -406,7 +419,9 @@ static const struct intel_device_info intel_skylake_info
> = {
> INTEL_BDW_GT3M_IDS(&intel_broadwell_gt3m_info), \
> INTEL_BDW_GT3D_IDS(&intel_broadwell_gt3d_info), \
> INTEL_CHV_IDS(&intel_cherryview_info), \
> - INTEL_SKL_IDS(&intel_skylake_info)
> + INTEL_SKL_GT1_IDS(&intel_skylake_info), \
> + INTEL_SKL_GT2_IDS(&intel_skylake_info), \
> + INTEL_SKL_GT3_IDS(&intel_skylake_gt3_info) \
>
> static const struct pci_device_id pciidlist[] = { /* aka */
> INTEL_PCI_IDS,
> --
> 1.8.3.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Use frame buffer modifiers for tiled display
On 02/04/2015 03:33 PM, Daniel Vetter wrote:
On Wed, Feb 04, 2015 at 03:09:38PM +, Tvrtko Ursulin wrote:
On 02/04/2015 02:25 PM, Daniel Vetter wrote:
On Wed, Feb 04, 2015 at 10:01:45AM +, Tvrtko Ursulin wrote:
On 02/03/2015 07:47 PM, Daniel Vetter wrote:
On Tue, Feb 03, 2015 at 05:22:31PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Start using frame buffer modifiers instead of object tiling mode
for display purposes.
To ensure compatibility with old userspace which is using set_tiling
and does not know about frame buffer modifiers, the latter are faked
internally when tile object is set for display. This way all interested
call sites can use fb modifiers exclusively.
Also ensure tiling specified via fb modifiers must match object tiling
used for fencing if both are specified.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/intel_display.c | 95 +---
drivers/gpu/drm/i915/intel_drv.h | 2 +
drivers/gpu/drm/i915/intel_pm.c | 7 +--
drivers/gpu/drm/i915/intel_sprite.c | 26 +-
4 files changed, 85 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7a3ed61..6825016 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2198,6 +2198,19 @@ intel_fb_align_height(struct drm_device *dev, int
height, unsigned int tiling)
return ALIGN(height, tile_height);
}
+static unsigned int intel_fb_modifier_to_tiling(u64 mod)
+{
+ BUILD_BUG_ON((I915_FORMAT_MOD_X_TILED & 0x00ffL) !=
+I915_TILING_X);
+
+ return mod & 1;
+}
+
+unsigned int intel_fb_tiling_mode(struct drm_framebuffer *fb)
+{
+ return intel_fb_modifier_to_tiling(fb->modifier[0]);
+}
I expect that these here will create a bit of churn with the skl patches
you have based, since I really don't want a new I915_TILING_FANCY define
in the enum space used by obj->tiling mode. But makes sense for backwards
compat with older platforms and less churn in code.
I thought we talked about effectively creating a new enum space for fb
tiling? By masking out bits from the fb modifier, no? Only thing for
backward compatibility is that object X tiling and fb X tiling == 1.
intel_fb_tiling_mode maps modifier (the new enum space) to
obj->tiling_mode (the old enum space). Means a notch less churn in legacy
code (but if that's the metric I'd just have kept using obj->tiling_mode
there). But means that you get to chance skl code twice, because I very
much don't want a new I915_TILING_DEFINE but instead the skl code should
check the new modifiers directly. Otherwise we can mash up tiling modes
valid just for ggtt fencing and fb modifiers in general.
Maybe I wasn't really clear with what I've meant ...
It does seem it is taking very long to get on the same page here. :/
I did not plan to add new I915_TILING_xxx. I was exploiting the fact both
map to the same value, with masking. So legacy continues to work since this
will be true forever. (ABI)
Then the plan was to add a new namespace for display tiling enums.
This was since fb modifier could contain more than tiling and this way it is
possible to mask out and case-switch just as the current code does.
There are three namespaces here:
1. I915_TILING_xxx
2. I915_FORMAT_MOD_ (fb modifiers)
3. Tiling as programmed to display hardware
And then add a fourth one:
4. I915_DISPLAY_TILING_xxx
At this step also add something like I915_FORMAT_MOD_TILING_MASK and
redefine I915_FORMAT_MOD_X_TILE to be fourcc_mod(INTEL,
I915_DISPLAY_TILING_X). (Instead of hardcoded 1)
At call sites (opencoded):
switch (fb->modifier[0] & I915_FORMAT_MOD_TILING) {
case I915_DISPLAY_TILING_X:
This is kinda what I'd have done, expect that you can cleverly define the
mask to include the vendor prefix, i.e.
#define I915_FORMAT_MOD_TILING_MASK ((0xff << 56) | 0xff)
and then you don't need yet another set of defines. And still have the
clear separation between I915_TILING_FOO and the new fb modifier stuff.
Hm side question - maybe DRM patch could instead of allow_fb_modifiers
boolean take allow_fb_modifier = VENDORA | VENDORB, and then stem at the
source any attempts to pass unsupported ones to the driver. :)
...
I mean we could do:
switch (fb->modifier[0]) {
case I915_FORMAT_MOD_X_TILE:
Or this. Since we don't yet have anything else than tiling modes you'll
get away with it and can postpone the mask stuff to whomever ends up
implementing the non-tiling fb modifiers.
Not nice but you told me to do it. :D
...
If fb modifiers won't have any overlap, like for example:
#define I915_FORMAT_MOD_X_TILE fourcc_mod(INTEL, 1)
#define I915_FORMAT_MOD_X_TILE_AND_UNRELATED fourcc_mod(INTEL, 1<<8 && 1)
Then the direct usage stops working..
Up to you, I have to unblock other stuff so we can't strangle this for too
long.
The super-minimal approach would be to shrink this patch down to
[Intel-gfx] [PATCH] tests/kms_addfb: Add support for fb modifiers
From: Tvrtko Ursulin
Just a few basic tests to make sure fb modifiers can be used and
behave sanely when mixed with the old set_tiling API.
Signed-off-by: Tvrtko Ursulin
---
lib/ioctl_wrappers.c | 45 ++
lib/ioctl_wrappers.h | 36 ++
tests/kms_addfb.c| 62
3 files changed, 143 insertions(+)
diff --git a/lib/ioctl_wrappers.c b/lib/ioctl_wrappers.c
index 19a457a..bca6d2a 100644
--- a/lib/ioctl_wrappers.c
+++ b/lib/ioctl_wrappers.c
@@ -1091,3 +1091,48 @@ int gem_context_has_param(int fd, uint64_t param)
return gem_context_get_param(fd, &p) == 0;
}
+
+int _drmModeAddFB2(int fd, uint32_t width, uint32_t height,
+ uint32_t pixel_format, uint32_t bo_handles[4],
+ uint32_t pitches[4], uint32_t offsets[4],
+ uint64_t modifier[0], uint32_t *buf_id, uint32_t flags)
+{
+ struct local_drm_mode_fb_cmd2 f;
+ int ret;
+
+ f.width = width;
+ f.height = height;
+ f.pixel_format = pixel_format;
+ f.flags = flags;
+
+ memcpy(f.handles, bo_handles, 4 * sizeof(bo_handles[0]));
+ memcpy(f.pitches, pitches, 4 * sizeof(pitches[0]));
+ memcpy(f.offsets, offsets, 4 * sizeof(offsets[0]));
+ memcpy(f.modifier, modifier, 4 * sizeof(modifier[0]));
+
+ if ((ret = drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, &f)))
+ return ret < 0 ? -errno : ret;
+
+ *buf_id = f.fb_id;
+ return 0;
+}
+
+unsigned int has_drm_fb_modifiers(int fd)
+{
+ static unsigned int has_modifiers, cap_modifiers_tested;
+ uint64_t cap_modifiers;
+ int ret;
+
+ if (cap_modifiers_tested)
+ return has_modifiers;
+
+ ret = drmGetCap(fd, LOCAL_DRM_CAP_ADDFB2_MODIFIERS, &cap_modifiers);
+ igt_assert(ret == 0 || errno == EINVAL);
+ has_modifiers = ret == 0 && cap_modifiers == 1;
+ cap_modifiers_tested = 1;
+
+ if (has_modifiers)
+ igt_debug("DRM_CAP_ADDFB2_MODIFIERS\n");
+
+ return has_modifiers;
+}
diff --git a/lib/ioctl_wrappers.h b/lib/ioctl_wrappers.h
index 30ab836..c277012 100644
--- a/lib/ioctl_wrappers.h
+++ b/lib/ioctl_wrappers.h
@@ -117,4 +117,40 @@ int gem_context_has_param(int fd, uint64_t param);
int gem_context_get_param(int fd, struct local_i915_gem_context_param *p);
int gem_context_set_param(int fd, struct local_i915_gem_context_param *p);
+struct local_drm_mode_fb_cmd2 {
+ uint32_t fb_id;
+ uint32_t width, height;
+ uint32_t pixel_format;
+ uint32_t flags;
+ uint32_t handles[4];
+ uint32_t pitches[4];
+ uint32_t offsets[4];
+ uint64_t modifier[4];
+};
+
+#define LOCAL_DRM_MODE_FB_MODIFIERS(1<<1)
+
+#define LOCAL_DRM_FORMAT_MOD_VENDOR_INTEL 0x01
+
+#define local_fourcc_mod_code(vendor, val) \
+ uint64_t)LOCAL_DRM_FORMAT_MOD_VENDOR_## vendor) << 56) | \
+ (val & 0x00ffL))
+
+#define LOCAL_I915_FORMAT_MOD_NONE local_fourcc_mod_code(INTEL, \
+ 0x00L)
+#define LOCAL_I915_FORMAT_MOD_X_TILED local_fourcc_mod_code(INTEL, \
+ 0x01L)
+
+#define LOCAL_DRM_IOCTL_MODE_ADDFB2DRM_IOWR(0xB8, \
+struct local_drm_mode_fb_cmd2)
+
+int _drmModeAddFB2(int fd, uint32_t width, uint32_t height,
+ uint32_t pixel_format, uint32_t bo_handles[4],
+ uint32_t pitches[4], uint32_t offsets[4],
+ uint64_t modifier[0], uint32_t *buf_id, uint32_t flags);
+
+#define LOCAL_DRM_CAP_ADDFB2_MODIFIERS 0x10
+
+unsigned int has_drm_fb_modifiers(int fd);
+
#endif /* IOCTL_WRAPPERS_H */
diff --git a/tests/kms_addfb.c b/tests/kms_addfb.c
index 756589e..9b0f77c 100644
--- a/tests/kms_addfb.c
+++ b/tests/kms_addfb.c
@@ -213,6 +213,66 @@ static void size_tests(int fd)
}
}
+static void addfb25_tests(int fd)
+{
+ struct local_drm_mode_fb_cmd2 f = {};
+
+
+ igt_require(has_drm_fb_modifiers(fd));
+
+ memset(&f, 0, sizeof(f));
+
+ f.width = 1024;
+ f.height = 1024;
+ f.pixel_format = DRM_FORMAT_XRGB;
+ f.pitches[0] = 1024*4;
+ f.flags = LOCAL_DRM_MODE_FB_MODIFIERS;
+ f.modifier[0] = LOCAL_I915_FORMAT_MOD_NONE;
+
+ igt_fixture {
+ gem_bo = gem_create(fd, 1024*1024*4);
+ igt_assert(gem_bo);
+ }
+
+ f.handles[0] = gem_bo;
+
+ igt_subtest("addfb25-X-tiled") {
+ f.modifier[0] = LOCAL_I915_FORMAT_MOD_X_TILED;
+ igt_assert(drmIoctl(fd, LOCAL_DRM_IOCTL_MODE_ADDFB2, &f) == 0);
+ igt_assert(drmIoctl(fd, DRM_IOCTL_MODE_RMFB, &f.fb_id) == 0);
+ f.fb_id = 0;
+ }
+
+ igt_subtest("addfb25-framebuffer-vs-set-tiling") {
+ igt_assert(drm
Re: [Intel-gfx] [BISECTED REGRESSION in 3.19-rc1] [drm/i915] WARNING: drivers/gpu/drm/drm_irq.c:1077 drm_wait_one_vblank
On Wed, Feb 04, 2015 at 01:32:14PM +0100, Paul Bolle wrote: > Andrey Skvortsov schreef op zo 01-02-2015 om 00:16 [+0300]: > > this warning exist in v3.19-rc6 and does not in v3.18. Bisection > > points to the commit 51e31d49c890552 "drm/i915: Use generic vblank wait". > > I have two machines with integrated Intel graphics and the problem > > happens only on the old one with GM965 chipset and X3100 integrated > > graphics. > > I see this too, since v3.19-rc1, on an (outdated) ThinkPad X41. > > > backtrace information: > > > > [ 31.780813] WARNING: CPU: 0 PID: 718 at drivers/gpu/drm/drm_irq.c:1077 > > drm_wait_one_vblank+0x33/0x141 [drm]() > > But it also prints > vblank not available on crtc 0, ret=-22 > > after the WARNING line, on that machine. I have "vblank not available on crtc 1, ret=-22" there. > > [ 31.780862] thermal_sys(E) > > [ 31.780866] CPU: 0 PID: 718 Comm: kworker/u4:3 Tainted: GE > > 3.17.0-rc5-150116--00578-g51e31d4 #16 > > [ 31.780868] Hardware name: Dell Inc. Vostro 1500 > > /0NX907, BIOS A06 04/21/2008 > > [ 31.780873] Workqueue: events_unbound async_run_entry_fn > > [ 31.780875] a0544b9d 813d4e81 > > > > [ 31.780879] 8103dec3 8800d84e0068 a0521c73 > > 00070008 > > [ 31.780882] 8800d84e 8801973e0800 > > 6014 > > [ 31.780886] Call Trace: > > [ 31.780890] [] ? dump_stack+0x4a/0x75 > > [ 31.780894] [] ? warn_slowpath_common+0x7e/0x97 > > [ 31.781050] [] ? drm_wait_one_vblank+0x33/0x141 [drm] > > [ 31.781078] [] ? drm_wait_one_vblank+0x33/0x141 [drm] > > [ 31.781122] [] ? intel_enable_tv+0x22/0x58 [i915] > > [ 31.781153] [] ? i9xx_crtc_enable+0x33b/0x397 [i915] > > [ 31.781184] [] ? __intel_set_mode+0x1160/0x1209 [i915] > > [ 31.781216] [] ? intel_set_mode+0x12/0x2c [i915] > > [ 31.781247] [] ? > > intel_get_load_detect_pipe+0x367/0x408 [i915] > > [ 31.781281] [] ? intel_tv_detect+0x103/0x444 [i915] > > [ 31.781289] [] ? > > drm_helper_probe_single_connector_modes_merge_bits+0xc0/0x327 > > [drm_kms_helper] > > [ 31.781296] [] ? > > drm_fb_helper_probe_connector_modes+0x3d/0x51 [drm_kms_helper] > > [ 31.781303] [] ? > > drm_fb_helper_initial_config+0x3d/0x303 [drm_kms_helper] > > [ 31.781306] [] ? async_run_entry_fn+0x5a/0x110 > > [ 31.781310] [] ? process_one_work+0x194/0x292 > > [ 31.781313] [] ? worker_thread+0x236/0x298 > > [ 31.781316] [] ? process_scheduled_works+0x2a/0x2a > > [ 31.781319] [] ? kthread+0x9e/0xa6 > > [ 31.781322] [] ? > > kthread_freezable_should_stop+0x36/0x36 > > [ 31.781326] [] ? ret_from_fork+0x7c/0xb0 > > [ 31.781329] [] ? > > kthread_freezable_should_stop+0x36/0x36 > > [ 31.782726] ---[ end trace e2b78017f1a10054 ]--- > > -- Best regards, Andrey Skvortsov PGP Key ID: 0x57A3AEAD signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [regression in linux-next] i915: broken graphics on laptop
On Wed, Feb 04, 2015 at 09:26:27PM +0300, Andrey Skvortsov wrote: > On Tue, Feb 03, 2015 at 08:21:52PM +, Chris Wilson wrote: > > On Tue, Feb 03, 2015 at 10:15:47PM +0300, Andrey Skvortsov wrote: > > > Hi, > > > > > > tested next-20150202. System boots, but graphic output is broken (empty > > > black screen). > > > Booted five times the same kernel, always got the same result. The system > > > works with 3.19-rc7. > > > > Those two warnings are more or less symptoms of the black screen (well > > the first is just overzealous). More important would be the drm.debug=6 > > dmesg from boot along with the gdm.log (or equivalent) aned Xorg.0.log > > as my guess is that X (or the display server) is crashing. > > Requested logs with drm.debug=6 are attached. lightdm was running after > WARN_ON, but I couldn't restart it. > The command hanged. > > As I booted next-20150202 system crashed several times with a lot of drm_ > calls in the backtrace, but I couldn't catch kernel logs, > because I have not serial port on the laptop. > > If you need to get other information or to test patches, I would be glad to > help. Right, here it looks like it freezing in intel_get_load_detect_pipe() during the initial configuration probe of X. Given the other crashes, we're back to worring about memory corruption. > [ 29.292333] [drm:intel_tv_detect] [CONNECTOR:33:SVIDEO-1] force=1 > [ 29.292336] [drm:intel_get_load_detect_pipe] [CONNECTOR:33:SVIDEO-1], > [ENCODER:34:TV-34] > [ 29.292339] [drm:intel_get_load_detect_pipe] creating tmp fb for > load-detection > [ 29.292396] [drm:intel_modeset_affected_pipes] set mode pipe masks: > modeset: 1, prepare: 1, disable: 0 > [ 29.292408] [drm:connected_sink_compute_bpp] [CONNECTOR:33:SVIDEO-1] > checking for sink bpp constrains > [ 29.292413] [drm:intel_tv_compute_config] forcing bpc to 8 for TV > [ 29.292416] [drm:intel_modeset_pipe_config] plane bpp: 24, pipe bpp: 24, > dithering: 0 > [ 29.292418] [drm:intel_dump_pipe_config] [CRTC:20][modeset] config for > pipe A > [ 29.292419] [drm:intel_dump_pipe_config] cpu_transcoder: A > [ 29.292421] [drm:intel_dump_pipe_config] pipe bpp: 24, dithering: 0 > [ 29.292423] [drm:intel_dump_pipe_config] fdi/pch: 0, lanes: 0, gmch_m: 0, > gmch_n: 0, link_m: 0, link_n: 0, tu: 0 > [ 29.292425] [drm:intel_dump_pipe_config] dp: 0, gmch_m: 0, gmch_n: 0, > link_m: 0, link_n: 0, tu: 0 > [ 29.292428] [drm:intel_dump_pipe_config] dp: 0, gmch_m2: 0, gmch_n2: 0, > link_m2: 0, link_n2: 0, tu2: 0 > [ 29.292429] [drm:intel_dump_pipe_config] audio: 0, infoframes: 0 > [ 29.292431] [drm:intel_dump_pipe_config] requested mode: > [ 29.292433] [drm:drm_mode_debug_printmodeline] Modeline 0:"NTSC 480i" 0 > 107520 1280 1368 1496 1712 1024 1027 1034 1104 0x40 0x0 > [ 29.292435] [drm:intel_dump_pipe_config] adjusted mode: > [ 29.292438] [drm:drm_mode_debug_printmodeline] Modeline 0:"NTSC 480i" 0 > 107520 1280 1368 1496 1712 1024 1027 1034 1104 0x40 0x0 > [ 29.292440] [drm:intel_dump_crtc_timings] crtc timings: 108000 1280 1368 > 1496 1712 1024 1027 1034 1104, type: 0x40 flags: 0x0 > [ 29.292442] [drm:intel_dump_pipe_config] port clock: 108000 > [ 29.292444] [drm:intel_dump_pipe_config] pipe src size: 1280x1024 > [ 29.292446] [drm:intel_dump_pipe_config] gmch pfit: control: 0x, > ratios: 0x, lvds border: 0x > [ 29.292447] [drm:intel_dump_pipe_config] pch pfit: pos: 0x, size: > 0x, disabled > [ 29.292449] [drm:intel_dump_pipe_config] ips: 0 > [ 29.292451] [drm:intel_dump_pipe_config] double wide: 0 > [ 29.292565] [ cut here ] > [ 29.293785] WARNING: CPU: 0 PID: 53 at include/linux/kref.h:47 > drm_framebuffer_reference+0x5b/0x64 [drm]() > [ 29.295032] Modules linked in: bnep(E) cfg80211(E) cpufreq_stats(E) > cpufreq_powersave(E) cpufreq_userspace(E) cpufreq_conservative(E) nfsd(E) > auth_rpcgss(E) nfs_acl(E) lockd(E) grace(E) sunrpc(E) cdc_wdm(E) cdc_acm(E) > cdc_ether(E) usbnet(E) joydev(E) coretemp(E) kvm_intel(E) kvm(E) i8k(E) > btusb(E) psmouse(E) snd_pcsp(E) i915(E) evdev(E) bluetooth(E) i2c_i801(E) > snd_hda_codec_generic(E) lpc_ich(E) mfd_core(E) xhci_pci(E) xhci_hcd(E) > serio_raw(E) rfkill(E) drm_kms_helper(E) drm(E) i2c_algo_bit(E) i2c_core(E) > snd_hda_intel(E) snd_hda_controller(E) snd_hda_codec(E) button(E) > snd_hwdep(E) battery(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) video(E) > ac(E) acpi_cpufreq(E) processor(E) fuse(E) parport_pc(E) ppdev(E) lp(E) > parport(E) autofs4(E) ext4(E) crc16(E) jbd2(E) mbcache(E) sd_mod(E) > ata_generic(E) > [ 29.295080] ahci(E) libahci(E) ata_piix(E) libata(E) scsi_mod(E) b44(E) > firewire_ohci(E) sdhci_pci(E) sdhci(E) firewire_core(E) crc_itu_t(E) mii(E) > ssb(E) mmc_core(E) libphy(E) uhci_hcd(E) ehci_pci(E) ehci_hcd(E) thermal(E) > thermal_sys(E) usbcore(E) usb_common(E) > [ 29.296301] CPU: 0 PID: 53 Comm: kworker/0:3 Tainted: GW E > 3.19.0-rc6-next-2015
Re: [Intel-gfx] Multiple declarations for intel_fbc_enabled
On 4 February 2015 at 08:27, Jani Nikula wrote: > On Mon, 02 Feb 2015, Ed Maste wrote: >> A FreeBSD developer discovered that intel_fbc_enabled has a >> declaration in two headers: >> >> ... > > Fixed by > > commit 7ff0ebcc1e30e3216c8c62ee71f59ac830b10364 Thanks. Sorry for the double post - one was stuck in moderation by the mailing list software, presumably because it came from a non-subscribed address. I've added linux-next now and will check there if we find other issues in the future. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/bdw: Implement non-coherent ctx w/a
On Mon, Feb 02, 2015 at 01:21:19PM +, Damien Lespiau wrote: > On Mon, Feb 02, 2015 at 02:33:48PM +0200, Ville Syrjälä wrote: > > On Thu, Jan 08, 2015 at 07:59:10PM -0800, Ben Widawsky wrote: > > > Implements a required workaround whose implications aren't entirely clear > > > to me > > > from the description. In particular I do not know if this effects legacy > > > contexts, execlists, or both. > > > > > > I couldn't find a real workaround name, so I made up: > > > WaHdcCtxNonCoherent > > > > I don't think we want to make up w/a names. Might cause someone to > > conclude that the w/a is no longer needed if they can't find the > > name in the w/a database or bspec. So maybe just add a small quote from > > bspec, or leave it without explanation forcing people to check bspec > > if they want to find out why it's there. > > > > I suppose one option would be to add a private namespace for our made > > up w/a names. But I don't really see a point in making up w/a names > > if we don't have a some documentation telling people what those names > > actually mean. > > > > So with the made up w/a name removed: > > Reviewed-by: Ville Syrjälä > > If you want to believe my version, it's called > WaForceContextSaveRestoreNonCoherent > > http://lists.freedesktop.org/archives/intel-gfx/2015-January/059086.html > If you reorder the defines as I did, it's Reviewed-by: Ben Widawsky It really irks me that the defines are out of place. Or you can send the v2 of my patch :D ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
