Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Simplify _STATE_ debug macros
On pe, 2015-12-18 at 16:18 +, Dave Gordon wrote:
> On 18/12/15 12:27, Joonas Lahtinen wrote:
> > Take advantage of WARN return value to simplify the flow.
> >
> > Cc: Rob Clark
> > Reviewed-by: Chris Wilson
> > Reported-by: Chris Wilson
> > Signed-off-by: Joonas Lahtinen
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 15 +--
> > 1 file changed, 5 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 1d28d90..5a5a3e0 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -87,23 +87,18 @@
> >*/
> > #define I915_STATE_WARN(condition, format...) ({
> > \
> > int __ret_warn_on = !!(condition);
> > \
> > - if (unlikely(__ret_warn_on)) {
> > \
> > - if (i915.verbose_state_checks)
> > \
> > - WARN(1, format);
> > \
> > - else
> > \
> > + if (unlikely(__ret_warn_on))
> > \
> > + if (!WARN(i915.verbose_state_checks, format))
> > \
> > DRM_ERROR(format);
> > \
> > - }
> > \
> > unlikely(__ret_warn_on);
> > \
> > })
> >
> > #define I915_STATE_WARN_ON(condition) ({
> > \
> > int __ret_warn_on = !!(condition);
> > \
> > - if (unlikely(__ret_warn_on)) {
> > \
> > - if (i915.verbose_state_checks)
> > \
> > - WARN(1, "WARN_ON(" #condition ")\n");
> > \
> > - else
> > \
> > + if (unlikely(__ret_warn_on))
> > \
> > + if (!WARN(i915.verbose_state_checks,
> > \
> > + "WARN_ON(" #condition ")\n"))
> > \
> > DRM_ERROR("WARN_ON(" #condition ")\n");
> > \
>
> These last two lines still have the text of the condition as part of
> a
> format string :(
>
> For compile-testing, you might want to change:
>
>static void lpt_bend_clkout_dp(struct drm_i915_private *dev_priv
>...
> if (WARN_ON(steps % 5 != 0))
>return;
>
> to use I915_STATE_WARN_ON() instead of WARN_ON, then you should get a
> compile-time warning if the '%' ends up in the format string.
>
This is just a patch to convert the old macros to different order
before changing them. The way of constructing the strings is intact.
Regards, Joonas
> .Dave.
>
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [alsa-devel] [PATCH V4 2/2] drm/i915: start adding dp mst audio
Sorry, I missed the emails.
On 12/11/2015 09:58 PM, Takashi Iwai wrote:
On Fri, 11 Dec 2015 11:43:51 +0100,
Takashi Iwai wrote:
On Fri, 11 Dec 2015 07:07:53 +0100,
Libin Yang wrote:
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 9aa83e7..5ad2e66 100644
--- a/drivers/gpu/drm/i915/intel_audio.c
+++ b/drivers/gpu/drm/i915/intel_audio.c
@@ -262,7 +262,8 @@ static void hsw_audio_codec_disable(struct intel_encoder
*encoder)
tmp |= AUD_CONFIG_N_PROG_ENABLE;
tmp &= ~AUD_CONFIG_UPPER_N_MASK;
tmp &= ~AUD_CONFIG_LOWER_N_MASK;
- if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT))
+ if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT) ||
+ intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DP_MST))
tmp |= AUD_CONFIG_N_VALUE_INDEX;
The same check is missing in hsw_audio_codec_enable()?
I915_WRITE(HSW_AUD_CFG(pipe), tmp);
@@ -474,7 +475,8 @@ static void ilk_audio_codec_enable(struct drm_connector
*connector,
tmp &= ~AUD_CONFIG_N_VALUE_INDEX;
tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
tmp &= ~AUD_CONFIG_PIXEL_CLOCK_HDMI_MASK;
- if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT))
+ if (intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DISPLAYPORT) ||
+ intel_pipe_has_type(intel_crtc, INTEL_OUTPUT_DP_MST))
tmp |= AUD_CONFIG_N_VALUE_INDEX;
... and missing for ilk_audio_codec_disable()?
Based on the discussion, I think you and Jani are right. It should be
in hsw_audio_codec_enable() and not in ild_audio_codec_disable().
else
tmp |= audio_config_hdmi_pixel_clock(adjusted_mode);
@@ -512,7 +514,8 @@ void intel_audio_codec_enable(struct intel_encoder
*intel_encoder)
/* ELD Conn_Type */
connector->eld[5] &= ~(3 << 2);
- if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT))
+ if (intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT) ||
+ intel_pipe_has_type(crtc, INTEL_OUTPUT_DP_MST))
IMO, it's better to have a macro to cover this two-line check instead
of open-coding at each place. We'll have 5 places in the end.
OK, I will use a macro.
Also, this patch still has an issue about the encoder type, namely, it
passes intel_encoder from MST, where you can't apply
enc_to_dig_port(). We need another help to get the digital port
depending on the encoder type, e.g.
static struct intel_digital_port *
intel_encoder_to_dig_port(struct intel_encoder *intel_encoder)
{
struct drm_encoder *encoder = &intel_encoder->base;
if (intel_encoder->type == INTEL_OUTPUT_DP_MST)
return enc_to_mst(encoder)->primary;
return enc_to_dig_port(encoder);
}
Yes, I will fix it in the new version patch.
Best Regards,
Libin
Takashi
___
Alsa-devel mailing list
alsa-de...@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/fb-helper: Use proper plane mask for fb cleanup
On Fri, Dec 18, 2015 at 05:27:01PM -0800, Matt Roper wrote: > pan_display_atomic() calls drm_atomic_clean_old_fb() to sanitize the > legacy FB fields (plane->fb and plane->old_fb). However it was building > the plane mask to pass to this function incorrectly (the bitwise OR was > using plane indices rather than plane masks). The end result was that > sometimes the legacy pointers would become out of sync with the atomic > pointers. If another operation tried to re-set the same FB onto the > plane, we might end up with the pointers back in sync, but improper > reference counts, which would eventually lead to system crashes when we > accessed a pointer to a prematurely-destroyed FB. > > The cause here was a very subtle bug introduced in commit: > > commit 07d3bad6c1210bd21e85d084807ef4ee4ac43a78 > Author: Maarten Lankhorst > Date: Wed Nov 11 11:29:11 2015 +0100 > > drm/core: Fix old_fb handling in pan_display_atomic. > > I found the crashes were most easily reproduced (on i915 at least) by > starting X and then VT switching to a VT that wasn't running a console > instance...the sequence of vt/fbcon entries that happen in that case > trigger a reference count mismatch and crash the system. > > Cc: Maarten Lankhorst > Cc: Daniel Vetter > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93313 > Signed-off-by: Matt Roper Applied to drm-misc, thanks. -Daniel > --- > drivers/gpu/drm/drm_fb_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c > index 69cbab5..1e103c4 100644 > --- a/drivers/gpu/drm/drm_fb_helper.c > +++ b/drivers/gpu/drm/drm_fb_helper.c > @@ -1251,7 +1251,7 @@ retry: > goto fail; > > plane = mode_set->crtc->primary; > - plane_mask |= drm_plane_index(plane); > + plane_mask |= (1 << drm_plane_index(plane)); > plane->old_fb = plane->fb; > } > > -- > 2.1.4 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [GIT PULL] Add get_eld audio component for i915/HD-audio
On Thu, 10 Dec 2015 14:16:03 +0100, Takashi Iwai wrote: > > Hi Daniel, > > please pull the get_eld op addition from: > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > tags/drm-i915-get-eld > > The topmost commit is 0bdf5a05647a66dcc6394986e061daeac9b1cf96 > > > > Add get_eld audio component for i915/HD-audio > > Here are the patchset to add get_eld op to audio component for > communicating more directly between i915 and HD-audio. > > Currently, the HDMI/DP audio status and ELD are notified and obtained > via the hardware-level communication over HD-audio unsolicited event > and verbs although the graphics driver holds the exactly same > information. As we already have a notification via audio component, > this is another step forward; namely, the audio driver may fetch > directly the audio status and ELD via the new component op. > > The commits are based on Dave's latest drm-next branch. Daniel, would you pull this one, or should we postpone it for 4.6? The changes aren't too intrusive, so I prefer having it for 4.5, so that we can continue developing the MST audio stuff based on this. thanks, Takashi > > > > Takashi Iwai (2): > drm/i915: Add get_eld audio component > drm/i915: Add reverse mapping between port and intel_encoder > > --- > drivers/gpu/drm/i915/i915_drv.h| 2 + > drivers/gpu/drm/i915/intel_audio.c | 79 > ++ > drivers/gpu/drm/i915/intel_ddi.c | 1 + > drivers/gpu/drm/i915/intel_dp.c| 1 + > drivers/gpu/drm/i915/intel_drv.h | 2 + > drivers/gpu/drm/i915/intel_hdmi.c | 2 + > include/drm/i915_component.h | 14 +++ > 7 files changed, 77 insertions(+), 24 deletions(-) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [GIT PULL] Add get_eld audio component for i915/HD-audio
On Mon, Dec 21, 2015 at 10:25:14AM +0100, Takashi Iwai wrote: > On Thu, 10 Dec 2015 14:16:03 +0100, > Takashi Iwai wrote: > > > > Hi Daniel, > > > > please pull the get_eld op addition from: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > > tags/drm-i915-get-eld > > > > The topmost commit is 0bdf5a05647a66dcc6394986e061daeac9b1cf96 > > > > > > > > Add get_eld audio component for i915/HD-audio > > > > Here are the patchset to add get_eld op to audio component for > > communicating more directly between i915 and HD-audio. > > > > Currently, the HDMI/DP audio status and ELD are notified and obtained > > via the hardware-level communication over HD-audio unsolicited event > > and verbs although the graphics driver holds the exactly same > > information. As we already have a notification via audio component, > > this is another step forward; namely, the audio driver may fetch > > directly the audio status and ELD via the new component op. > > > > The commits are based on Dave's latest drm-next branch. > > Daniel, would you pull this one, or should we postpone it for 4.6? > The changes aren't too intrusive, so I prefer having it for 4.5, so > that we can continue developing the MST audio stuff based on this. Sorry, simply for got send out the confirmation mail. I pulled this a few days ago already and will send the final drm-intel pull for 4.5 with it to Dave soonish. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/13] staging/android/sync: Move sync framework out of staging
On Thu, Dec 17, 2015 at 09:35:03AM -0800, Jesse Barnes wrote: > On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote: > > From: John Harrison > > > > The sync framework is now used by the i915 driver. Therefore it can be > > moved out of staging and into the regular tree. Also, the public > > interfaces can actually be made public and exported. > > > > v3: New patch for series. > > > > Signed-off-by: John Harrison > > Signed-off-by: Geoff Miller > > --- > > drivers/android/Kconfig| 28 ++ > > drivers/android/Makefile | 2 + > > drivers/android/sw_sync.c | 260 > > drivers/android/sw_sync.h | 59 +++ > > drivers/android/sync.c | 734 > > + > > drivers/android/sync.h | 366 > > drivers/android/sync_debug.c | 256 > > drivers/android/trace/sync.h | 82 > > drivers/staging/android/Kconfig| 28 -- > > drivers/staging/android/Makefile | 2 - > > drivers/staging/android/sw_sync.c | 260 > > drivers/staging/android/sw_sync.h | 59 --- > > drivers/staging/android/sync.c | 734 > > - > > drivers/staging/android/sync.h | 366 > > drivers/staging/android/sync_debug.c | 256 > > drivers/staging/android/trace/sync.h | 82 > > drivers/staging/android/uapi/sw_sync.h | 32 -- > > drivers/staging/android/uapi/sync.h| 97 - > > include/uapi/Kbuild| 1 + > > include/uapi/sync/Kbuild | 3 + > > include/uapi/sync/sw_sync.h| 32 ++ > > include/uapi/sync/sync.h | 97 + > > 22 files changed, 1920 insertions(+), 1916 deletions(-) > > create mode 100644 drivers/android/sw_sync.c > > create mode 100644 drivers/android/sw_sync.h > > create mode 100644 drivers/android/sync.c > > create mode 100644 drivers/android/sync.h > > create mode 100644 drivers/android/sync_debug.c > > create mode 100644 drivers/android/trace/sync.h > > delete mode 100644 drivers/staging/android/sw_sync.c > > delete mode 100644 drivers/staging/android/sw_sync.h > > delete mode 100644 drivers/staging/android/sync.c > > delete mode 100644 drivers/staging/android/sync.h > > delete mode 100644 drivers/staging/android/sync_debug.c > > delete mode 100644 drivers/staging/android/trace/sync.h > > delete mode 100644 drivers/staging/android/uapi/sw_sync.h > > delete mode 100644 drivers/staging/android/uapi/sync.h > > create mode 100644 include/uapi/sync/Kbuild > > create mode 100644 include/uapi/sync/sw_sync.h > > create mode 100644 include/uapi/sync/sync.h > > > > diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig > > index bdfc6c6..9edcd8f 100644 > > --- a/drivers/android/Kconfig > > +++ b/drivers/android/Kconfig > > @@ -32,6 +32,34 @@ config ANDROID_BINDER_IPC_32BIT > > > > Note that enabling this will break newer Android user-space. > > > > +config SYNC > > + bool "Synchronization framework" > > + default n > > + select ANON_INODES > > + select DMA_SHARED_BUFFER > > + ---help--- > > + This option enables the framework for synchronization between multiple > > + drivers. Sync implementations can take advantage of hardware > > + synchronization built into devices like GPUs. > > + > > +config SW_SYNC > > + bool "Software synchronization objects" > > + default n > > + depends on SYNC > > + ---help--- > > + A sync object driver that uses a 32bit counter to coordinate > > + synchronization. Useful when there is no hardware primitive backing > > + the synchronization. > > + > > +config SW_SYNC_USER > > + bool "Userspace API for SW_SYNC" > > + default n > > + depends on SW_SYNC > > + ---help--- > > + Provides a user space API to the sw sync object. > > + *WARNING* improper use of this can result in deadlocking kernel > > + drivers from userspace. > > + > > endif # if ANDROID > > IIRC we wanted to drop the user ABI altogether? I think we can de-stage > this even before we push the new ABI on the i915 side to expose the sync > points (since we'll need an open source userspace for that), and any > changes/cleanups can happen outside of staging. Just a head-up: Gustavo Padovan from Collabora is working to de-stage all the syncpt stuff. Greg KH merged the TODO update for that work for 4.5, which covers consensus (including ack from Google's Greg Hackmann on the plan). Given that I think it'd be best to freeload on that effort. But that means we need to push all the android/syncpt stuff down in the series. I hope that works, and there's no functional depencies in the fence conversion/scheduler core? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@li
Re: [Intel-gfx] [PATCH 07/13] drm/i915: Add per context timelines to fence object
On Thu, Dec 17, 2015 at 09:49:27AM -0800, Jesse Barnes wrote: > Yeah we definitely want this, but it'll have to be reconciled with the > different request->fence patches. I'm not sure if it would be easier to move > to per-context seqnos first or go this route and deal with the mismatch > between global and per-ctx. This patch doesn't do independent per-context seqno, so the point is moot. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Move Braswell stop_machine GGTT insertion workaround
On Wed, Dec 16, 2015 at 10:02:29PM +0200, Ville Syrjälä wrote:
> On Wed, Nov 18, 2015 at 03:19:39PM +, Chris Wilson wrote:
> > There was a silent conflict between
> >
> > commit 0a878716265e9af9f697264dc2e858fcc060d833
> > Author: Daniel Vetter
> > Date: Thu Oct 15 14:23:01 2015 +0200
> >
> > drm/i915: restore ggtt double-bind avoidance
> >
> > and
> >
> > commit 5bab6f60cb4d1417ad7c599166bcfec87529c1a2
> > Author: Chris Wilson
> > Date: Fri Oct 23 18:43:32 2015 +0100
> >
> > drm/i915: Serialise updates to GGTT with access through GGTT on Braswell
> >
> > thankfully caught by the extra WARN safegaurd in 0a878716. Since we now
> > override the GGTT insert_pages callback when installing the aliasing
> > ppgtt, we assert that the callback is the original ggtt routine.
> > However, on Braswell we now use a different insertion routine to
> > serialise access through the GGTT with updating the PTE and hence the
> > conflict. To avoid the conflict, move the custom insertion routine for
> > Braswell down a level.
> >
> > Reported-by: Ville Syrjälä > Signed-off-by: Chris Wilson
> > Cc: Ville Syrjälä > Cc: Daniel Vetter
> > Cc: Michel Thierry
> > Cc: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/i915_gem_gtt.c | 50
> > +
> > 1 file changed, 28 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > index 4d357e18e5d1..8cd271fa2396 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> > @@ -2386,6 +2386,32 @@ static void gen8_ggtt_insert_entries(struct
> > i915_address_space *vm,
> > POSTING_READ(GFX_FLSH_CNTL_GEN6);
> > }
> >
> > +struct insert_entries {
> > + struct i915_address_space *vm;
> > + struct sg_table *st;
> > + uint64_t start;
> > + enum i915_cache_level level;
> > + u32 flags;
> > +};
> > +
> > +static int gen8_ggtt_insert_entries__cb(void *_arg)
> > +{
> > + struct insert_entries *arg = _arg;
> > + gen8_ggtt_insert_entries(arg->vm, arg->st,
> > +arg->start, arg->level, arg->flags);
> > + return 0;
> > +}
> > +
> > +static void gen8_ggtt_insert_entries__BKL(struct i915_address_space *vm,
> > + struct sg_table *st,
> > + uint64_t start,
> > + enum i915_cache_level level,
> > + u32 flags)
> > +{
> > + struct insert_entries arg = { vm, st, start, level, flags };
>
> Could use named initializers to avoid potential accidents with the
> weaker typed members. But the struct definition is close by so not a
> huge risk.
>
> Reviewed-by: Ville Syrjälä
> Tested-by: Ville Syrjälä
Queued for -next (including cc: fixes), thanks for the patch.
-Daniel
>
> > + stop_machine(gen8_ggtt_insert_entries__cb, &arg, NULL);
> > +}
> > +
> > /*
> > * Binds an object into the global gtt with the specified cache level. The
> > object
> > * will be accessible to the GPU via commands whose operands reference
> > offsets
> > @@ -2534,26 +2560,6 @@ static int ggtt_bind_vma(struct i915_vma *vma,
> > return 0;
> > }
> >
> > -struct ggtt_bind_vma__cb {
> > - struct i915_vma *vma;
> > - enum i915_cache_level cache_level;
> > - u32 flags;
> > -};
> > -
> > -static int ggtt_bind_vma__cb(void *_arg)
> > -{
> > - struct ggtt_bind_vma__cb *arg = _arg;
> > - return ggtt_bind_vma(arg->vma, arg->cache_level, arg->flags);
> > -}
> > -
> > -static int ggtt_bind_vma__BKL(struct i915_vma *vma,
> > - enum i915_cache_level cache_level,
> > - u32 flags)
> > -{
> > - struct ggtt_bind_vma__cb arg = { vma, cache_level, flags };
> > - return stop_machine(ggtt_bind_vma__cb, &arg, NULL);
> > -}
> > -
> > static int aliasing_gtt_bind_vma(struct i915_vma *vma,
> > enum i915_cache_level cache_level,
> > u32 flags)
> > @@ -3021,8 +3027,8 @@ static int gen8_gmch_probe(struct drm_device *dev,
> > dev_priv->gtt.base.bind_vma = ggtt_bind_vma;
> > dev_priv->gtt.base.unbind_vma = ggtt_unbind_vma;
> >
> > - if (IS_CHERRYVIEW(dev))
> > - dev_priv->gtt.base.bind_vma = ggtt_bind_vma__BKL;
> > + if (IS_CHERRYVIEW(dev_priv))
> > + dev_priv->gtt.base.insert_entries =
> > gen8_ggtt_insert_entries__BKL;
> >
> > return ret;
> > }
> > --
> > 2.6.2
>
> --
> Ville Syrjälä
> Intel OTC
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [GIT PULL] Add get_eld audio component for i915/HD-audio
On Mon, 21 Dec 2015 10:59:41 +0100, Daniel Vetter wrote: > > On Mon, Dec 21, 2015 at 10:25:14AM +0100, Takashi Iwai wrote: > > On Thu, 10 Dec 2015 14:16:03 +0100, > > Takashi Iwai wrote: > > > > > > Hi Daniel, > > > > > > please pull the get_eld op addition from: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > > > tags/drm-i915-get-eld > > > > > > The topmost commit is 0bdf5a05647a66dcc6394986e061daeac9b1cf96 > > > > > > > > > > > > Add get_eld audio component for i915/HD-audio > > > > > > Here are the patchset to add get_eld op to audio component for > > > communicating more directly between i915 and HD-audio. > > > > > > Currently, the HDMI/DP audio status and ELD are notified and obtained > > > via the hardware-level communication over HD-audio unsolicited event > > > and verbs although the graphics driver holds the exactly same > > > information. As we already have a notification via audio component, > > > this is another step forward; namely, the audio driver may fetch > > > directly the audio status and ELD via the new component op. > > > > > > The commits are based on Dave's latest drm-next branch. > > > > Daniel, would you pull this one, or should we postpone it for 4.6? > > The changes aren't too intrusive, so I prefer having it for 4.5, so > > that we can continue developing the MST audio stuff based on this. > > Sorry, simply for got send out the confirmation mail. I pulled this a few > days ago already and will send the final drm-intel pull for 4.5 with it to > Dave soonish. Great, that's a good news. Then I'll merge the branch and the commits on its top to sound git tree, too. Thanks! Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Correct max delay for HDMI hotplug live status checking
On Tue, Dec 15, 2015 at 12:40:30PM +0800, Gary Wang wrote:
> The total delay of HDMI hotplug detecting with 30ms have already
> been split into a resolution of 3 retries of 10ms each, for the worst
> cases. But it still suffered from only waiting 10ms at most in
> intel_hdmi_detect(). This patch corrects it by reading hotplug status
> with 4 times at most for 30ms delay.
>
> v2:
> - straight up to loop execution for more clear in code readability
> - mdelay will replace with msleep by Daniel's new patch
>
> drm/i915: mdelay(10) considered harmful
>
> - suggest to re-evaluate try times for being compatible to old HDMI monitor
>
> Reviewed-by: Cooper Chiou
> Tested-by: Gary Wang
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Gavin Hindman
> Cc: Sonika Jindal
> Cc: Shashank Sharma
> Signed-off-by: Gary Wang
Queued for -next (including cc: fixes), thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
> mode change 100644 => 100755 drivers/gpu/drm/i915/intel_hdmi.c
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> old mode 100644
> new mode 100755
> index 6825543..912d6c3
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1387,17 +1387,18 @@ intel_hdmi_detect(struct drm_connector *connector,
> bool force)
> struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> bool live_status = false;
> - unsigned int retry = 3;
> + unsigned int try;
>
> DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name);
>
> intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
>
> - while (!live_status && --retry) {
> + for (try = 0; !live_status && try < 4; try++) {
> + if (try)
> + mdelay(10);
> live_status = intel_digital_port_connected(dev_priv,
> hdmi_to_dig_port(intel_hdmi));
> - mdelay(10);
> }
>
> if (!live_status)
> --
> 1.9.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ warning: Fi.CI.BAT
== Summary == Built on 7cdc548e77f503593b83a1c5d58f4dcc862c17e2 drm-intel-nightly: 2015y-12m-18d-19h-26m-21s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i5k-2) pass -> DMESG-WARN (skl-i7k-2) Test kms_flip: Subgroup basic-flip-vs-dpms: pass -> DMESG-WARN (ilk-hp8440p) Subgroup basic-flip-vs-modeset: dmesg-warn -> PASS (skl-i5k-2) dmesg-warn -> PASS (hsw-brixbox) dmesg-warn -> PASS (byt-nuc) Subgroup basic-flip-vs-wf_vblank: dmesg-warn -> PASS (skl-i5k-2) dmesg-warn -> PASS (bdw-ultra) dmesg-warn -> PASS (skl-i7k-2) dmesg-warn -> PASS (ivb-t430s) dmesg-warn -> PASS (snb-x220t) dmesg-warn -> PASS (snb-dellxps) dmesg-warn -> PASS (hsw-brixbox) dmesg-warn -> PASS (bdw-nuci7) Subgroup basic-plain-flip: dmesg-warn -> PASS (ivb-t430s) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-a: dmesg-warn -> PASS (snb-x220t) Subgroup read-crc-pipe-a-frame-sequence: dmesg-warn -> PASS (byt-nuc) Subgroup read-crc-pipe-c: dmesg-warn -> PASS (skl-i7k-2) Test kms_setmode: Subgroup basic-clone-single-crtc: dmesg-warn -> PASS (snb-dellxps) Test pm_rpm: Subgroup basic-pci-d3-state: dmesg-warn -> PASS (bdw-ultra) bdw-nuci7total:135 pass:125 dwarn:1 dfail:0 fail:0 skip:9 bdw-ultratotal:132 pass:125 dwarn:1 dfail:0 fail:0 skip:6 byt-nuc total:135 pass:120 dwarn:2 dfail:0 fail:0 skip:13 hsw-brixbox total:135 pass:127 dwarn:1 dfail:0 fail:0 skip:7 hsw-gt2 total:135 pass:130 dwarn:1 dfail:0 fail:0 skip:4 ilk-hp8440p total:135 pass:99 dwarn:1 dfail:0 fail:0 skip:35 ivb-t430stotal:135 pass:128 dwarn:1 dfail:0 fail:0 skip:6 skl-i5k-2total:135 pass:122 dwarn:5 dfail:0 fail:0 skip:8 skl-i7k-2total:135 pass:122 dwarn:5 dfail:0 fail:0 skip:8 snb-dellxps total:135 pass:122 dwarn:1 dfail:0 fail:0 skip:12 snb-x220ttotal:135 pass:122 dwarn:1 dfail:0 fail:1 skip:11 Results at /archive/results/CI_IGT_test/Patchwork_730/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Correct max delay for HDMI hotplug live status checking
On Mon, Dec 21, 2015 at 11:29:16AM +0100, Daniel Vetter wrote: > On Tue, Dec 15, 2015 at 12:40:30PM +0800, Gary Wang wrote: > > The total delay of HDMI hotplug detecting with 30ms have already > > been split into a resolution of 3 retries of 10ms each, for the worst > > cases. But it still suffered from only waiting 10ms at most in > > intel_hdmi_detect(). This patch corrects it by reading hotplug status > > with 4 times at most for 30ms delay. > > > > v2: > > - straight up to loop execution for more clear in code readability > > - mdelay will replace with msleep by Daniel's new patch > > > > drm/i915: mdelay(10) considered harmful > > > > - suggest to re-evaluate try times for being compatible to old HDMI monitor > > > > Reviewed-by: Cooper Chiou > > Tested-by: Gary Wang > > Cc: Jani Nikula > > Cc: Daniel Vetter > > Cc: Gavin Hindman > > Cc: Sonika Jindal > > Cc: Shashank Sharma > > Signed-off-by: Gary Wang > > Queued for -next (including cc: fixes), thanks for the patch. Using mdelay() or fixed to use msleep()? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t 6/6] tests/kms_chv_cursor_fail: Add a test to exercise CHV pipe C cursor fail
On 18 December 2015 at 17:25, wrote:
> From: Ville Syrjälä
>
> The test tries to anger CHV pipe C cursor by walking the edges of the
> screen while moving the cursor across the screen edge.
>
> The actual hw issue only occurs on pipe C, and only on the left screen
> edge. The testcase can walk all the edges though, and on all pipes, just
> so I could make sure the failure doesn't occur there.
>
> Signed-off-by: Ville Syrjälä
> ---
> tests/Makefile.sources | 1 +
> tests/kms_chv_cursor_fail.c | 425
>
> 2 files changed, 426 insertions(+)
> create mode 100644 tests/kms_chv_cursor_fail.c
>
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index d5940388c483..104ed2be83ed 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -68,6 +68,7 @@ TESTS_progs_M = \
> gem_write_read_ring_switch \
> kms_addfb_basic \
> kms_atomic \
> + kms_chv_cursor_fail \
> kms_cursor_crc \
> kms_draw_crc \
> kms_fbc_crc \
> diff --git a/tests/kms_chv_cursor_fail.c b/tests/kms_chv_cursor_fail.c
> new file mode 100644
> index ..2ccdd4106597
> --- /dev/null
> +++ b/tests/kms_chv_cursor_fail.c
> @@ -0,0 +1,425 @@
> +/*
> + * Copyright © 2015 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> DEALINGS
> + * IN THE SOFTWARE.
> + *
> + */
> +
> +#include "igt.h"
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +IGT_TEST_DESCRIPTION("Exercise CHV pipe C cursor fail");
> +
> +#ifndef DRM_CAP_CURSOR_WIDTH
> +#define DRM_CAP_CURSOR_WIDTH 0x8
> +#endif
> +#ifndef DRM_CAP_CURSOR_HEIGHT
> +#define DRM_CAP_CURSOR_HEIGHT 0x9
> +#endif
> +
> +typedef struct {
> + int drm_fd;
> + igt_display_t display;
> + struct igt_fb primary_fb;
> + struct igt_fb fb;
> + igt_output_t *output;
> + enum pipe pipe;
> + igt_crc_t ref_crc;
> + int curw, curh; /* cursor size */
> + igt_pipe_crc_t *pipe_crc;
> + uint32_t devid;
> + bool colored, jump, disable;
> + int jump_x, jump_y;
> +} data_t;
> +
> +enum {
> + EDGE_LEFT = 0x1,
> + EDGE_RIGHT = 0x2,
> + EDGE_TOP = 0x4,
> + EDGE_BOTTOM = 0x8,
> +};
> +
> +static void cursor_disable(data_t *data)
> +{
> + igt_output_t *output = data->output;
> + igt_plane_t *cursor;
> +
> + cursor = igt_output_get_plane(output, IGT_PLANE_CURSOR);
> + igt_plane_set_fb(cursor, NULL);
> +}
> +
> +static void create_cursor_fb(data_t *data, int cur_w, int cur_h)
> +{
> + cairo_t *cr;
> + uint32_t fb_id;
> +
> + fb_id = igt_create_fb(data->drm_fd, cur_w, cur_h,
> + DRM_FORMAT_ARGB,
> + LOCAL_DRM_FORMAT_MOD_NONE,
> + &data->fb);
> + igt_assert(fb_id);
> +
> + cr = igt_get_cairo_ctx(data->drm_fd, &data->fb);
> + if (data->colored)
> + igt_paint_color_alpha(cr, 0, 0, data->fb.width,
> data->fb.height,
> + 1.0, 0.0, 0.0, 1.0);
> + else
> + igt_paint_color_alpha(cr, 0, 0, data->fb.width,
> data->fb.height,
> + 0.0, 0.0, 0.0, 0.0);
> + igt_assert(cairo_status(cr) == 0);
> + cairo_destroy(cr);
> +}
> +
> +static void cursor_move(data_t *data, int x, int y, int i)
> +{
> + int crtc_id = data->output->config.crtc->crtc_id;
> +
> + igt_debug("[%d] x=%d, y=%d\n", i, x, y);
> +
> + /*
> +* The "fixed" kernel will refuse the ioctl when pipe C cursor
> +* would straddle the left screen edge (which is when the hw
> +* fails). So let's accept a failure from the ioctl in that case.
> +*/
> + igt_assert(drmModeMoveCursor(data->drm_fd, crtc_id, x, y) == 0 ||
> + (IS_CHERR
Re: [Intel-gfx] [PATCH i-g-t 2/6] lib: Extract ssme common fb create+fill methods into helpers
On 18 December 2015 at 17:25, wrote:
> From: Ville Syrjälä
>
> Several tests do one or more of the followin:
> * igt_create_fb() + igt_paint_test_pattern()
> * igt_create_color_fb() + igt_paint_test_pattern()
> * igt_create_fb() + igt_paint_image()
>
> Extract them into new helpes: igt_create_pattern_fb(),
> igt_create_color_pattern_fb(), igt_create_image_fb().
Couple of typos above: "ssme", "followin", "helpes"
>
> Signed-off-by: Ville Syrjälä
> ---
> lib/igt_fb.c | 124
> ++
> lib/igt_fb.h | 11
> tests/kms_atomic.c| 30 ---
> tests/kms_flip_tiling.c | 25 +++---
> tests/kms_panel_fitting.c | 42
> tests/kms_plane_scaling.c | 60 ++
> tests/kms_pwrite_crc.c| 9 +---
> tests/kms_setmode.c | 11 ++--
> tests/pm_lpsp.c | 11 +---
> tests/pm_rpm.c| 10 ++--
> tests/testdisplay.c | 8 ++-
> 11 files changed, 188 insertions(+), 153 deletions(-)
>
> diff --git a/lib/igt_fb.c b/lib/igt_fb.c
> index 3ea9915c42c4..b3c7840a22ae 100644
> --- a/lib/igt_fb.c
> +++ b/lib/igt_fb.c
> @@ -537,6 +537,130 @@ unsigned int igt_create_color_fb(int fd, int width, int
> height,
> return fb_id;
> }
>
> +/**
> + * igt_create_pattern_fb:
> + * @fd: open i915 drm file descriptor
> + * @width: width of the framebuffer in pixel
> + * @height: height of the framebuffer in pixel
> + * @format: drm fourcc pixel format code
> + * @tiling: tiling layout of the framebuffer
> + * @fb: pointer to an #igt_fb structure
> + *
> + * This function allocates a gem buffer object suitable to back a framebuffer
> + * with the requested properties and then wraps it up in a drm framebuffer
> + * object. All metadata is stored in @fb.
> + *
> + * Compared to igt_create_fb() this function also fills the entire
> framebuffer
> + * with the test pattern.
> + *
> + * Returns:
> + * The kms id of the created framebuffer on success or a negative error code
> on
> + * failure.
> + */
> +unsigned int igt_create_pattern_fb(int fd, int width, int height,
> + uint32_t format, uint64_t tiling,
> + struct igt_fb *fb /* out */)
> +{
> + unsigned int fb_id;
> + cairo_t *cr;
> +
> + fb_id = igt_create_fb(fd, width, height, format, tiling, fb);
> + igt_assert(fb_id);
> +
> + cr = igt_get_cairo_ctx(fd, fb);
> + igt_paint_test_pattern(cr, width, height);
> + igt_assert(cairo_status(cr) == 0);
> + cairo_destroy(cr);
> +
> + return fb_id;
> +}
> +
> +/**
> + * igt_create_pattern_fb:
This should be igt_create_color_pattern_fb.
> + * @fd: open i915 drm file descriptor
> + * @width: width of the framebuffer in pixel
> + * @height: height of the framebuffer in pixel
> + * @format: drm fourcc pixel format code
> + * @tiling: tiling layout of the framebuffer
> + * @r: red value to use as fill color
> + * @g: gree value to use as fill color
Typo of "green" here.
> + * @b: blue value to use as fill color
> + * @fb: pointer to an #igt_fb structure
> + *
> + * This function allocates a gem buffer object suitable to back a framebuffer
> + * with the requested properties and then wraps it up in a drm framebuffer
> + * object. All metadata is stored in @fb.
> + *
> + * Compared to igt_create_fb() this function also fills the entire
> framebuffer
> + * with the test pattern.
> + *
> + * Returns:
> + * The kms id of the created framebuffer on success or a negative error code
> on
> + * failure.
> + */
> +unsigned int igt_create_color_pattern_fb(int fd, int width, int height,
> +uint32_t format, uint64_t tiling,
> +double r, double g, double b,
> +struct igt_fb *fb /* out */)
> +{
> + unsigned int fb_id;
> + cairo_t *cr;
> +
> + fb_id = igt_create_fb(fd, width, height, format, tiling, fb);
> + igt_assert(fb_id);
> +
> + cr = igt_get_cairo_ctx(fd, fb);
> + igt_paint_color(cr, 0, 0, width, height, r, g, b);
> + igt_paint_test_pattern(cr, width, height);
> + igt_assert(cairo_status(cr) == 0);
> + cairo_destroy(cr);
> +
> + return fb_id;
> +}
> +
> +/**
> + * igt_create_image_fb:
> + * @drm_fd: open i915 drm file descriptor
> + * @width: width of the framebuffer in pixel or 0
> + * @height: height of the framebuffer in pixel or 0
> + * @format: drm fourcc pixel format code
> + * @tiling: tiling layout of the framebuffer
> + * @filename: filename of the png image to draw
@fb missing here.
> + *
> + * Create a framebuffer with the specified image. If @width is zero the
> + * image width will be used. If @height is zero the image height will be
> used.
> + *
> + * Returns:
> + * The kms id of the created framebuffer on success or a negative error code
> on
> + * failure.
> + */
> +unsigned
Re: [Intel-gfx] [PATCH 1/4] drm/i915: teardown default context in reverse, update comments
On Wed, Dec 16, 2015 at 06:36:48PM +, Dave Gordon wrote:
> We set up engines in forwards order, so some things (notably the
> default context) are "owned" by engine 0 (the render engine, aka "RCS").
> For symmetry and to make sure such shared objects don't disappear too
> early, we should generally run teardown loops in the reverse order,
> so that engine 0 is processed last.
>
> This patch changes i915_gem_context_fini() to do that, and clarifies the
> comments in i915_gem_context_{init,fini}() about the refcounting of the
> default {struct intel_)context: the refcount is just ONE, no matter how
> many rings exist or are active, and this refcount is nominally ascribed
> to the render ring (RCS), which is set up first and now torn down last.
>
> Signed-off-by: Dave Gordon
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 21 +
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 900ffd0..e143ea5 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -391,7 +391,13 @@ int i915_gem_context_init(struct drm_device *dev)
> for (i = 0; i < I915_NUM_RINGS; i++) {
> struct intel_engine_cs *ring = &dev_priv->ring[i];
>
> - /* NB: RCS will hold a ref for all rings */
> + /*
> + * Although each engine has a pointer to the global default
> + * context, they don't contribute to the refcount on the
> + * context. We consider that RCS (which is set up first and
> + * torn down last) holds this reference on behalf of all the
> + * other engines
> + */
Instead of piles of comments, can't we just reference-count this pointer
properly? Pointers to reference-counted objects which don't hold a full
reference are just fraught with peril, and doing that should imo only be
done when there's really clear performance data justifying the
atomic_inc/dec overhead. Init/teardown code isn't such a place.
This misdesign goes back to the original execlist merge, which expanded
the default context from RCS to all engines.
Or do I miss something and we can't do this?
Thanks, Daniel
> ring->default_context = ctx;
> }
>
> @@ -431,14 +437,21 @@ void i915_gem_context_fini(struct drm_device *dev)
> i915_gem_object_ggtt_unpin(dctx->legacy_hw_ctx.rcs_state);
> }
>
> - for (i = 0; i < I915_NUM_RINGS; i++) {
> + for (i = I915_NUM_RINGS; --i >= 0;) {
> struct intel_engine_cs *ring = &dev_priv->ring[i];
>
> - if (ring->last_context)
> + if (ring->last_context) {
> i915_gem_context_unreference(ring->last_context);
> + ring->last_context = NULL;
> + }
>
> + /*
> + * These default_context pointers don't contribute to the
> + * refcount on the context. We consider that RCS holds its
> + * reference on behalf of all the other engines, so there's
> + * just a single unreference() call below.
> + */
> ring->default_context = NULL;
> - ring->last_context = NULL;
> }
>
> i915_gem_context_unreference(dctx);
> --
> 1.9.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: teardown default context in reverse, update comments
On Mon, Dec 21, 2015 at 11:48:35AM +0100, Daniel Vetter wrote:
> On Wed, Dec 16, 2015 at 06:36:48PM +, Dave Gordon wrote:
> > We set up engines in forwards order, so some things (notably the
> > default context) are "owned" by engine 0 (the render engine, aka "RCS").
> > For symmetry and to make sure such shared objects don't disappear too
> > early, we should generally run teardown loops in the reverse order,
> > so that engine 0 is processed last.
> >
> > This patch changes i915_gem_context_fini() to do that, and clarifies the
> > comments in i915_gem_context_{init,fini}() about the refcounting of the
> > default {struct intel_)context: the refcount is just ONE, no matter how
> > many rings exist or are active, and this refcount is nominally ascribed
> > to the render ring (RCS), which is set up first and now torn down last.
> >
> > Signed-off-by: Dave Gordon
> > ---
> > drivers/gpu/drm/i915/i915_gem_context.c | 21 +
> > 1 file changed, 17 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index 900ffd0..e143ea5 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -391,7 +391,13 @@ int i915_gem_context_init(struct drm_device *dev)
> > for (i = 0; i < I915_NUM_RINGS; i++) {
> > struct intel_engine_cs *ring = &dev_priv->ring[i];
> >
> > - /* NB: RCS will hold a ref for all rings */
> > + /*
> > +* Although each engine has a pointer to the global default
> > +* context, they don't contribute to the refcount on the
> > +* context. We consider that RCS (which is set up first and
> > +* torn down last) holds this reference on behalf of all the
> > +* other engines
> > +*/
>
> Instead of piles of comments, can't we just reference-count this pointer
> properly? Pointers to reference-counted objects which don't hold a full
> reference are just fraught with peril, and doing that should imo only be
> done when there's really clear performance data justifying the
> atomic_inc/dec overhead. Init/teardown code isn't such a place.
>
> This misdesign goes back to the original execlist merge, which expanded
> the default context from RCS to all engines.
>
> Or do I miss something and we can't do this?
We can. It's actually even easier to just do dev_priv->kernel_context.
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v16] drm/i915: Slaughter the thundering i915_wait_request herd
One particularly stressful scenario consists of many independent tasks all competing for GPU time and waiting upon the results (e.g. realtime transcoding of many, many streams). One bottleneck in particular is that each client waits on its own results, but every client is woken up after every batchbuffer - hence the thunder of hooves as then every client must do its heavyweight dance to read a coherent seqno to see if it is the lucky one. Ideally, we only want one client to wake up after the interrupt and check its request for completion. Since the requests must retire in order, we can select the first client on the oldest request to be woken. Once that client has completed his wait, we can then wake up the next client and so on. However, all clients then incur latency as every process in the chain may be delayed for scheduling - this may also then cause some priority inversion. To reduce the latency, when a client is added or removed from the list, we scan the tree for completed seqno and wake up all the completed waiters in parallel. Using igt/benchmarks/gem_latency, we can demonstrate this effect. The benchmark measures the number of GPU cycles between completion of a batch and the client waking up from a call to wait-ioctl. With many concurrent waiters, with each on a different request, we observe that the wakeup latency before the patch scales nearly linearly with the number of waiters (before external factors kick in making the scaling much worse). After applying the patch, we can see that only the single waiter for the request is being woken up, providing a constant wakeup latency for every operation. However, the situation is not quite as rosy for many waiters on the same request, though to the best of my knowledge this is much less likely in practice. Here, we can observe that the concurrent waiters incur extra latency from being woken up by the solitary bottom-half, rather than directly by the interrupt. This appears to be scheduler induced (having discounted adverse effects from having a rbtree walk/erase in the wakeup path), each additional wake_up_process() costs aproximately 1us on big core. Another effect of performing the secondary wakeups from the first bottom-half is the incurred delay this imposes on high priority threads - rather than immediately returning to userspace and leaving the interrupt handler to wake the others. To offset the delay incurred with additional waiters on a request, we could use a hybrid scheme that did a quick read in the interrupt handler and dequeued all the completed waiters (incurring the overhead in the interrupt handler, not the best plan either as we then incur GPU submission latency) but we would still have to wake up the bottom-half everytime to do the heavyweight slow read. Or we could only kick the waiters on the seqno with the same priority as the current task (i.e. in the realtime waiter scenario, only it is woken up immediately by the interrupt and simply queues the next waiter before returning to userspace, minimising its delay at the expense of the chain, and also reducing contention on its scheduler runqueue). This is effective at avoid long pauses in the interrupt handler and at avoiding the extra latency in realtime/high-priority waiters. v2: Convert from a kworker per engine into a dedicated kthread for the bottom-half. v3: Rename request members and tweak comments. v4: Use a per-engine spinlock in the breadcrumbs bottom-half. v5: Fix race in locklessly checking waiter status and kicking the task on adding a new waiter. v6: Fix deciding when to force the timer to hide missing interrupts. v7: Move the bottom-half from the kthread to the first client process. v8: Reword a few comments v9: Break the busy loop when the interrupt is unmasked or has fired. v10: Comments, unnecessary churn, better debugging from Tvrtko v11: Wake all completed waiters on removing the current bottom-half to reduce the latency of waking up a herd of clients all waiting on the same request. v12: Rearrange missed-interrupt fault injection so that it works with igt/drv_missed_irq_hang v13: Rename intel_breadcrumb and friends to intel_wait in preparation for signal handling. v14: RCU commentary, assert_spin_locked v15: Hide BUG_ON behind the compiler; report on gem_latency findings. v16: Sort seqno-groups by priority so that first-waiter has the highest task priority (and so avoid priority inversion). Testcase: igt/gem_concurrent_blit Testcase: igt/benchmarks/gem_latency Signed-off-by: Chris Wilson Cc: "Rogozhkin, Dmitry V" Cc: "Gong, Zhipeng" Cc: Tvrtko Ursulin Cc: Dave Gordon --- drivers/gpu/drm/i915/Makefile| 1 + drivers/gpu/drm/i915/i915_debugfs.c | 19 +- drivers/gpu/drm/i915/i915_drv.h | 32 ++- drivers/gpu/drm/i915/i915_gem.c | 141 + drivers/gpu/drm/i915/i915_gpu_error.c| 2 +- drivers/gpu/drm/i915/i915_irq.c | 20 +- drivers/gpu/drm/i915/intel_breadcrumbs.c | 336 +
Re: [Intel-gfx] [PATCH 1/4] drm/i915: teardown default context in reverse, update comments
On 21/12/15 11:01, Chris Wilson wrote:
On Mon, Dec 21, 2015 at 11:48:35AM +0100, Daniel Vetter wrote:
On Wed, Dec 16, 2015 at 06:36:48PM +, Dave Gordon wrote:
We set up engines in forwards order, so some things (notably the
default context) are "owned" by engine 0 (the render engine, aka "RCS").
For symmetry and to make sure such shared objects don't disappear too
early, we should generally run teardown loops in the reverse order,
so that engine 0 is processed last.
This patch changes i915_gem_context_fini() to do that, and clarifies the
comments in i915_gem_context_{init,fini}() about the refcounting of the
default {struct intel_)context: the refcount is just ONE, no matter how
many rings exist or are active, and this refcount is nominally ascribed
to the render ring (RCS), which is set up first and now torn down last.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem_context.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 900ffd0..e143ea5 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -391,7 +391,13 @@ int i915_gem_context_init(struct drm_device *dev)
for (i = 0; i < I915_NUM_RINGS; i++) {
struct intel_engine_cs *ring = &dev_priv->ring[i];
- /* NB: RCS will hold a ref for all rings */
+ /*
+* Although each engine has a pointer to the global default
+* context, they don't contribute to the refcount on the
+* context. We consider that RCS (which is set up first and
+* torn down last) holds this reference on behalf of all the
+* other engines
+*/
Instead of piles of comments, can't we just reference-count this pointer
properly? Pointers to reference-counted objects which don't hold a full
reference are just fraught with peril, and doing that should imo only be
done when there's really clear performance data justifying the
atomic_inc/dec overhead. Init/teardown code isn't such a place.
This misdesign goes back to the original execlist merge, which expanded
the default context from RCS to all engines.
Or do I miss something and we can't do this?
We can. It's actually even easier to just do dev_priv->kernel_context.
-Chris
I'm sure it can be done, but Nick & I tried changing this section so
that each engine held a reference, and it broke something else (because
the last unreference then occured at a different point), hence my
comment about the "the delicate and fragile load/unload dance".
This is why we're trying to tidy up and clarify, bit by bit, without
breaking too many of the existing assumptions at once.
But ... I like Chris' idea of moving the pointer to the default context
from the engine structure to dev_priv; that will simplify several of the
complicated ...->engine[RCS].default_context constructs, and mean that
we're change the pointers to match the lifecycle rather than vice versa.
I'll try that ...
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/2] drm/i915: Disable fast link training if DP config changes
Disable DP link training optimization if DP link configuration
changes. If one of the DP link parameters i.e. link rate or
lane count changes the link training does no longer apply the
previously computed drive current and pre-emphasis level.
Instead, the link training is started with zero values.
v5: Commit message update. Split the original patch in two.
This part considers only changes on link configuration.
Removed unnecessary debug messages. (Ville)
v4: Parameter and debug message naming improvements.
Fix for link parameter check (Ville)
v3: Remove cached old link parameters. Instead, disable
fast link training feature when link parameters are
set (Ville)
v2: Readout DPCD register to check if no aux handshaking is
required in link training (Ander)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 5 +
drivers/gpu/drm/i915/intel_dp_link_training.c | 3 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 796e3d3..6b36d82 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1676,6 +1676,11 @@ found:
void intel_dp_set_link_params(struct intel_dp *intel_dp,
const struct intel_crtc_state *pipe_config)
{
+ if (intel_dp->link_rate != pipe_config->port_clock ||
+ intel_dp->lane_count != pipe_config->lane_count) {
+ intel_dp->train_set_valid = false;
+ }
+
intel_dp->link_rate = pipe_config->port_clock;
intel_dp->lane_count = pipe_config->lane_count;
}
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 793..59d59be 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -85,6 +85,9 @@ static bool
intel_dp_reset_link_train(struct intel_dp *intel_dp,
uint8_t dp_train_pat)
{
+ DRM_DEBUG_KMS("link training optimization: %s\n",
+ intel_dp->train_set_valid ? "true" : "false");
+
if (!intel_dp->train_set_valid)
memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
intel_dp_set_signal_levels(intel_dp);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 0/2] drm/i915: Disable link training optimization if DP config has changed
These two patches are fixes for DP link trainging failures and flickering issues reported by Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393 Mika Kahola (2): drm/i915: Disable fast link training if DP config changes drm/i915: Check DP no aux transaction bit on link training drivers/gpu/drm/i915/intel_dp.c | 7 ++- drivers/gpu/drm/i915/intel_dp_link_training.c | 22 ++ drivers/gpu/drm/i915/intel_drv.h | 1 + 3 files changed, 29 insertions(+), 1 deletion(-) -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/2] drm/i915: Check DP no aux transaction bit on link training
Check if no AUX transactions are required on DP link training.
If this bit is set, we can reuse the known good drive current
and pre-emphasis level from the last "full" link training.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393
Signed-off-by: Mika Kahola
---
drivers/gpu/drm/i915/intel_dp.c | 2 +-
drivers/gpu/drm/i915/intel_dp_link_training.c | 19 +++
drivers/gpu/drm/i915/intel_drv.h | 1 +
3 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 6b36d82..3137187 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3852,7 +3852,7 @@ intel_dp_link_down(struct intel_dp *intel_dp)
intel_dp->DP = DP;
}
-static bool
+bool
intel_dp_get_dpcd(struct intel_dp *intel_dp)
{
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index 59d59be..5fb3f97 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -85,6 +85,25 @@ static bool
intel_dp_reset_link_train(struct intel_dp *intel_dp,
uint8_t dp_train_pat)
{
+ bool has_dpcd;
+ bool no_aux_handshake = false;
+
+ has_dpcd = intel_dp_get_dpcd(intel_dp);
+
+ /*
+* Source device can try to use drive current and pre-emphasis
+* parameters computed by the last "full" link training if the
+* DP_NO_AUX_HANDSHAKE_LINK_TRAINING bit is set to 1.
+*/
+ if (has_dpcd) {
+ if (intel_dp->dpcd[DP_DPCD_REV] >= 0x11) {
+ no_aux_handshake = (intel_dp->dpcd[DP_MAX_DOWNSPREAD] &
+ DP_NO_AUX_HANDSHAKE_LINK_TRAINING);
+ }
+ }
+
+ intel_dp->train_set_valid &= no_aux_handshake;
+
DRM_DEBUG_KMS("link training optimization: %s\n",
intel_dp->train_set_valid ? "true" : "false");
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d523ebb..c36a70c 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1239,6 +1239,7 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc);
bool intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config);
bool intel_dp_is_edp(struct drm_device *dev, enum port port);
+bool intel_dp_get_dpcd(struct intel_dp *intel_dp);
enum irqreturn intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port,
bool long_hpd);
void intel_edp_backlight_on(struct intel_dp *intel_dp);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Handle PipeC fused off on HSW
On some HSW boards all pipeC tests fail with various dmesg errors.
This seems to be caused by Pipe C beeing disabled in FUSE_STRAP and
thus reading back the PIPECONF register is always zero.
Fixed by adjusting pipe_count to 2 and thus the pipeC igt tests will
be skipped.
Signed-off-by: Gabriel Feceoru
---
drivers/gpu/drm/i915/i915_dma.c | 3 +++
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 988a380..130a496 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -813,6 +813,9 @@ static void intel_device_info_runtime_init(struct
drm_device *dev)
!(sfuse_strap & SFUSE_STRAP_FUSE_LOCK))) {
DRM_INFO("Display fused off, disabling\n");
info->num_pipes = 0;
+ } else if (I915_READ(FUSE_STRAP) & HSW_PIPE_C_DISABLE) {
+ DRM_INFO("PipeC fused off\n");
+ info->num_pipes = 2;
}
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 007ae83..0432a5f 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5940,6 +5940,7 @@ enum skl_disp_power_wells {
#define ILK_INTERNAL_GRAPHICS_DISABLE (1 << 31)
#define ILK_INTERNAL_DISPLAY_DISABLE (1 << 30)
#define ILK_DISPLAY_DEBUG_DISABLE (1 << 29)
+#define HSW_PIPE_C_DISABLE(1 << 28)
#define ILK_HDCP_DISABLE (1 << 25)
#define ILK_eDP_A_DISABLE (1 << 24)
#define HSW_CDCLK_LIMIT (1 << 24)
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Correct max delay for HDMI hotplug live status checking
On Mon, Dec 21, 2015 at 10:37:25AM +, Chris Wilson wrote: > On Mon, Dec 21, 2015 at 11:29:16AM +0100, Daniel Vetter wrote: > > On Tue, Dec 15, 2015 at 12:40:30PM +0800, Gary Wang wrote: > > > The total delay of HDMI hotplug detecting with 30ms have already > > > been split into a resolution of 3 retries of 10ms each, for the worst > > > cases. But it still suffered from only waiting 10ms at most in > > > intel_hdmi_detect(). This patch corrects it by reading hotplug status > > > with 4 times at most for 30ms delay. > > > > > > v2: > > > - straight up to loop execution for more clear in code readability > > > - mdelay will replace with msleep by Daniel's new patch > > > > > > drm/i915: mdelay(10) considered harmful > > > > > > - suggest to re-evaluate try times for being compatible to old HDMI > > > monitor > > > > > > Reviewed-by: Cooper Chiou > > > Tested-by: Gary Wang > > > Cc: Jani Nikula > > > Cc: Daniel Vetter > > > Cc: Gavin Hindman > > > Cc: Sonika Jindal > > > Cc: Shashank Sharma > > > Signed-off-by: Gary Wang > > > > Queued for -next (including cc: fixes), thanks for the patch. > > Using mdelay() or fixed to use msleep()? msleep patch was merged already, I just had to resolve the conflict. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Simplify _STATE_ debug macros
On 21/12/15 08:11, Joonas Lahtinen wrote:
On pe, 2015-12-18 at 16:18 +, Dave Gordon wrote:
On 18/12/15 12:27, Joonas Lahtinen wrote:
Take advantage of WARN return value to simplify the flow.
Cc: Rob Clark
Reviewed-by: Chris Wilson
Reported-by: Chris Wilson
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 15 +--
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 1d28d90..5a5a3e0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -87,23 +87,18 @@
*/
#define I915_STATE_WARN(condition, format...) ({
\
int __ret_warn_on = !!(condition);
\
- if (unlikely(__ret_warn_on)) {
\
- if (i915.verbose_state_checks)
\
- WARN(1, format);
\
- else
\
+ if (unlikely(__ret_warn_on))
\
+ if (!WARN(i915.verbose_state_checks, format))
\
DRM_ERROR(format);
\
- }
\
unlikely(__ret_warn_on);
\
})
#define I915_STATE_WARN_ON(condition) ({
\
int __ret_warn_on = !!(condition);
\
- if (unlikely(__ret_warn_on)) {
\
- if (i915.verbose_state_checks)
\
- WARN(1, "WARN_ON(" #condition ")\n");
\
- else
\
+ if (unlikely(__ret_warn_on))
\
+ if (!WARN(i915.verbose_state_checks,
\
+ "WARN_ON(" #condition ")\n"))
\
DRM_ERROR("WARN_ON(" #condition ")\n");
\
These last two lines still have the text of the condition as part of
a
format string :(
For compile-testing, you might want to change:
static void lpt_bend_clkout_dp(struct drm_i915_private *dev_priv
...
if (WARN_ON(steps % 5 != 0))
return;
to use I915_STATE_WARN_ON() instead of WARN_ON, then you should get a
compile-time warning if the '%' ends up in the format string.
This is just a patch to convert the old macros to different order
before changing them. The way of constructing the strings is intact.
Regards, Joonas
Yes, I agree, you didn't break them -- they were already wrong!
.Dave.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/10] drm/i915: Use drm_vblank_count() on gen2 for crc frame count
On Wed, Dec 16, 2015 at 07:22:25PM +0200, Ville Syrjälä wrote: > On Wed, Dec 16, 2015 at 04:28:36PM +0100, Daniel Vetter wrote: > > On Wed, Dec 16, 2015 at 02:51:20PM +0200, Ville Syrjälä wrote: > > > On Wed, Dec 16, 2015 at 11:30:19AM +0100, Daniel Vetter wrote: > > > > On Mon, Dec 14, 2015 at 06:23:44PM +0200, ville.syrj...@linux.intel.com > > > > wrote: > > > > > From: Ville Syrjälä > > > > > > > > > > Gen2 doesn't have a hardware frame counter, so let's use the sw > > > > > counter value instead. > > > > > > > > > > Testcase: igt/kms_pipe_crc_basic/read-crc-pipe-?-frame-sequence > > > > > Signed-off-by: Ville Syrjälä > > > > > > > > I think the better test is skip the testcase if all frame numbers are 0. > > > > Not sure it's worth it to hack this up. > > > > > > What's the problem with it? A few extra lines of code? > > > > Well the idea of sampling the hw irq counter is that we'd notice when we > > start missing something. Sampling the baked vblank counter isn't really > > useful in that regard I think. > > I think only if we'd also miss the vblank interrupt somehow. > > > > > Otoh we could just sample the official vblank counter, and then a test > > could schedule a flip for a given frame and check that the crc changes at > > the right frame (using continuous sampling). That would indeed be useful. > > That's a decent point. Maybe we would want to expose both counters > actually and nag if they don't match? That sort of thing could be useful > just to validate the vblank code too, but we don't have any interface > to expose the hw counter alongside the sw counter for that purpose. Hm yeah that makes sense. Makes the backward compat dance in igt a bit more annoying though. But should be doable by first trying to parse the new layout and then falling back to the old one if it fails. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v1] drm/i915/guc: Fix a potential issue during driver unload
On Fri, Dec 18, 2015 at 12:38:59PM -0800, yu@intel.com wrote: > From: Alex Dai > > The device struct_mutex needs to be held before releasing any GEM > objects allocated by GuC. > > WARNING: CPU: 0 PID: 1575 at include/drm/drm_gem.h:217 > gem_release_guc_obj+0x5f/0x70 [i915]() > Call Trace: > [] dump_stack+0x44/0x60 > [] warn_slowpath_common+0x82/0xc0 > [] warn_slowpath_null+0x1a/0x20 > [] gem_release_guc_obj+0x5f/0x70 [i915] > [] i915_guc_submission_fini+0x1a/0x70 [i915] > [] intel_guc_ucode_fini+0x29/0xa0 [i915] > [] i915_driver_unload+0x14d/0x290 [i915] > [] drm_dev_unregister+0x29/0xb0 [drm] > [] drm_put_dev+0x23/0x60 [drm] > [] i915_pci_remove+0x15/0x20 [i915] > [] pci_device_remove+0x39/0xc0 > [] __device_release_driver+0xa1/0x150 > [] driver_detach+0xb5/0xc0 > [] bus_remove_driver+0x55/0xd0 > [] driver_unregister+0x2c/0x50 > [] pci_unregister_driver+0x29/0x90 > [] drm_pci_exit+0x94/0xb0 [drm] > [] i915_exit+0x20/0xf5c [i915] > [] SyS_delete_module+0x1b5/0x210 > [] entry_SYSCALL_64_fastpath+0x16/0x75 > ---[ end trace f711c4eb63588bb7 ]--- > > v1: Add backtrace log. > When resending a patch, please add everyone who commented on the previous patch to the Cc: list here. Thanks, Daniel > Signed-off-by: Alex Dai > > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c > b/drivers/gpu/drm/i915/intel_guc_loader.c > index 625272f4..4748651 100644 > --- a/drivers/gpu/drm/i915/intel_guc_loader.c > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c > @@ -631,10 +631,10 @@ void intel_guc_ucode_fini(struct drm_device *dev) > struct drm_i915_private *dev_priv = dev->dev_private; > struct intel_guc_fw *guc_fw = &dev_priv->guc.guc_fw; > > + mutex_lock(&dev->struct_mutex); > direct_interrupts_to_host(dev_priv); > i915_guc_submission_fini(dev); > > - mutex_lock(&dev->struct_mutex); > if (guc_fw->guc_fw_obj) > drm_gem_object_unreference(&guc_fw->guc_fw_obj->base); > guc_fw->guc_fw_obj = NULL; > -- > 2.5.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [v2] drm/i915: Limit VF cache invalidate workaround usage to gen9
On Fri, Dec 18, 2015 at 12:34:16PM +0200, Imre Deak wrote: > On pe, 2015-12-18 at 11:59 +0200, Jani Nikula wrote: > > On Thu, 17 Dec 2015, Imre Deak wrote: > > > On Thu, 2015-12-17 at 09:49 -0800, Ben Widawsky wrote: > > > > +> if (IS_GEN9(ring->dev)) > > > > > > Nitpick: INTEL_INFO()->gen == 9 is the preferred way. > > > > Oh? Since when and says who? > > Haven't found it after some digging, but I do remember someone having > this comment earlier. > > My opinion is that we should only use one form, and since INTEL_INFO()- > gen can be used in a more generic manner I would prefer that. Currently > we have it both ways in the code. We use IS_GENx for individual gen checks and INTEL_INFO()->gen when checking for ranges. At least that's the usage I inferred ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] [v2] drm/i915: Limit VF cache invalidate workaround usage to gen9
On Thu, Dec 17, 2015 at 10:49:24PM +0200, Imre Deak wrote: > On Thu, 2015-12-17 at 09:49 -0800, Ben Widawsky wrote: > > It is unclear if this is even required on BXT. > > I'm not sure either, I only added it on the premise that it was marked > as SKL+ originally in BSpec. The revision log entry in BSpec has this > much to say: > """ > The workaround that requires an empty PIPE_CONTROL before a > PIPE_CONTROL with a VF Cache Invalidation Enable is only for SKL and > not SKL+. The bug was fixed in CNL with the following HSD:... > """ > Which doesn't make this clear either imo. > > > v2: Make sure to set the default value to false. Uncertain how my compiler > > doesn't complain with v1. > > > > Cc: Imre Deak > > Signed-off-by: Ben Widawsky > > --- > > drivers/gpu/drm/i915/intel_lrc.c | 16 > > 1 file changed, 8 insertions(+), 8 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_lrc.c > > b/drivers/gpu/drm/i915/intel_lrc.c > > index 519cea32..af1e001 100644 > > --- a/drivers/gpu/drm/i915/intel_lrc.c > > +++ b/drivers/gpu/drm/i915/intel_lrc.c > > @@ -1695,7 +1695,7 @@ static int gen8_emit_flush_render(struct > > drm_i915_gem_request *request, > > struct intel_ringbuffer *ringbuf = request->ringbuf; > > struct intel_engine_cs *ring = ringbuf->ring; > > u32 scratch_addr = ring->scratch.gtt_offset + 2 * CACHELINE_BYTES; > > - bool vf_flush_wa; > > + bool vf_flush_wa = false; > > u32 flags = 0; > > int ret; > > > > @@ -1716,14 +1716,14 @@ static int gen8_emit_flush_render(struct > > drm_i915_gem_request *request, > > flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE; > > flags |= PIPE_CONTROL_QW_WRITE; > > flags |= PIPE_CONTROL_GLOBAL_GTT_IVB; > > - } > > > > - /* > > - * On GEN9+ Before VF_CACHE_INVALIDATE we need to emit a NULL pipe > > - * control. > > - */ > > - vf_flush_wa = INTEL_INFO(ring->dev)->gen >= 9 && > > - flags & PIPE_CONTROL_VF_CACHE_INVALIDATE; > > + /* > > + * On GEN9: before VF_CACHE_INVALIDATE we need to emit a NULL > > + * pipe control. > > + */ > > +> if (IS_GEN9(ring->dev)) > > Nitpick: INTEL_INFO()->gen == 9 is the preferred way. Either way: > Reviewed-by: Imre Deak Queued for -next, thanks for the patch. -Daniel > > > + vf_flush_wa = true; > > + } > > > > ret = intel_logical_ring_begin(request, vf_flush_wa ? 12 : 6); > > if (ret) > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/skl: Increase ddb blocks to support large cursor sizes
On Fri, Dec 18, 2015 at 07:24:19AM -0800, Matt Roper wrote:
> On Fri, Dec 18, 2015 at 07:14:17AM -0800, Matt Roper wrote:
> > On Fri, Dec 18, 2015 at 05:10:12PM +0200, Ville Syrjälä wrote:
> > > On Fri, Dec 18, 2015 at 06:58:58AM -0800, Matt Roper wrote:
> > > > On Fri, Dec 18, 2015 at 12:35:47PM +0200, Ville Syrjälä wrote:
> > > > > On Wed, Dec 16, 2015 at 07:06:20PM -0800, Radhakrishna Sripada wrote:
> > > > > > Original value of 32 blocks is not sufficient when using cursor
> > > > > > size of
> > > > > > 256x256 causing FIFO underruns when the reworked wm
> > > > > > caluclations in
> > > > > >
> > > > > > commit 024c9045221fe45482863c47c4b4c47d37f97cbf
> > > > > > Author: Matt Roper
> > > > > > Date: Thu Sep 24 15:53:11 2015 -0700
> > > > > >
> > > > > > drm/i915/skl: Eliminate usage of pipe_wm_parameters from
> > > > > > SKL-style WM (v4)
> > > > >
> > > > > Well that commit is obviously incorrect. It's now using the pipe src
> > > > > width as the plane width for all planes.
> > > > >
> > > >
> > > > Yeah, we already noted that bug in another email thread, but decided
> > > > that it was unrelated to the problems Radhakrishna is facing.
> > > > Radhakrishna is only using a cursor (which doesn't use that buggy
> > > > function)
> > >
> > > Pop quiz: what does it use then?
> >
> > All non-cursor planes (i.e., primary+sprite). Cursors use a fixed DDB
> > allocation (currently 32 blocks as suggested by bspec, but
> > Radhakrishna's testing has found this to be too small, so his patch here
> > is bumping that number up.
> >
>
> To elaborate on this some more, we have some suspicions about why the
> bspec-suggested 32 blocks might not be enough. There's some new
> workaround information in the bspec about sometimes needing to disable
> the system agent (SAGV) on non-BXT gen9, depending on the configuration
> and that's not something that's been implemented in our driver code yet.
> There's also another new workaround that checks raw system memory
> bandwidth and adjusts watermark programming that hasn't been implemented
> yet either. It could be that one of those two missing workarounds is
> the true culprit, but Radhakrishna's patch here looks like a reasonable
> short-term workaround; my main worry is that if he needs to bump the
> hardcoded 32 up to to 52 for the single pipe case, he might also need to
> bump the hardcoded 8 up as well for the multi-pipe case; I don't think
> anyone has tested that yet (and this seems to be a SKL-specific problem,
> so I can't reproduce it on my BXT).
This needs at least a very big comment that we're just hacking around with
duct-tape. Also allocating DDB shouldn't matter for correctness, as long
as we compute the WM values correctly. I wonder how this fixes anything
really (except making it a bit harder to hit perhaps due to the enlarged
buffering it affords for the cursor).
Imo better to just implement the other workarounds first, then see what's
left.
-Daniel
>
>
> Matt
>
> > Primary and sprite planes are supposed to divide up the remaining blocks
> > proportional to their size, but the bug here causes them to all be
> > considered full-screen size. If you're not actually using sprites and
> > not windowing your primary plane, then the bug has no effect (which is
> > probably why we didn't already catch and fix it). If you do use a
> > sprite plane or window your primary plane, your proportions are probably
> > wrong and you get non-optimal settings, although even then you usually
> > won't have actual problems.
> >
> >
> > Matt
> >
> >
> > >
> > > > and a full-screen primary plane, so the numbers don't actually
> > > > change (for his use case).
> > > >
> > > > Of course that bug is still worth fixing too; I was planning on writing
> > > > up a patch for it later today.
> > > >
> > > >
> > > > Matt
> > > >
> > > >
> > > > > >
> > > > > > are used. Increasing the number of blocks to 52 to make cursor
> > > > > > plane tolerate
> > > > > > SAGV block time for the maximum possible cursor size.
> > > > > >
> > > > > > Signed-off-by: Radhakrishna Sripada
> > > > > > Signed-off-by: Kalyan Kondapally
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/intel_pm.c | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > index d385d99..137fb68 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_pm.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > > > > > @@ -2802,7 +2802,7 @@ skl_ddb_get_pipe_allocation_limits(struct
> > > > > > drm_device *dev,
> > > > > > static unsigned int skl_cursor_allocation(const struct
> > > > > > intel_wm_config *config)
> > > > > > {
> > > > > > if (config->num_pipes_active == 1)
> > > > > > - return 32;
> > > > > > + return 52;
> > > > > >
> > > > > > return 8;
> > > > > > }
> > > > > > --
> > > > > > 1.9.1
> > > > > >
> > > >
[Intel-gfx] ✗ warning: Fi.CI.BAT
== Summary == Built on c7ae36da9cc3dd7480cec86a8b19fc76d075927d drm-intel-nightly: 2015y-12m-21d-10h-37m-34s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-modeset: dmesg-warn -> PASS (bsw-nuc-2) pass -> DMESG-WARN (hsw-gt2) dmesg-warn -> PASS (bdw-nuci7) pass -> DMESG-WARN (skl-i7k-2) pass -> DMESG-WARN (byt-nuc) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-a: pass -> DMESG-WARN (snb-x220t) Subgroup read-crc-pipe-b-frame-sequence: dmesg-warn -> PASS (byt-nuc) Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (snb-x220t) bdw-nuci7total:132 pass:122 dwarn:1 dfail:0 fail:0 skip:9 bdw-ultratotal:132 pass:124 dwarn:2 dfail:0 fail:0 skip:6 bsw-nuc-2total:135 pass:114 dwarn:1 dfail:0 fail:0 skip:20 byt-nuc total:135 pass:120 dwarn:2 dfail:0 fail:0 skip:13 hsw-brixbox total:135 pass:126 dwarn:2 dfail:0 fail:0 skip:7 hsw-gt2 total:135 pass:129 dwarn:2 dfail:0 fail:0 skip:4 ilk-hp8440p total:135 pass:100 dwarn:0 dfail:0 fail:0 skip:35 ivb-t430stotal:135 pass:127 dwarn:2 dfail:0 fail:0 skip:6 skl-i5k-2total:135 pass:121 dwarn:6 dfail:0 fail:0 skip:8 skl-i7k-2total:135 pass:121 dwarn:6 dfail:0 fail:0 skip:8 snb-dellxps total:135 pass:121 dwarn:2 dfail:0 fail:0 skip:12 snb-x220ttotal:135 pass:121 dwarn:2 dfail:0 fail:1 skip:11 Results at /archive/results/CI_IGT_test/Patchwork_774/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ warning: Fi.CI.BAT
== Summary == Built on c7ae36da9cc3dd7480cec86a8b19fc76d075927d drm-intel-nightly: 2015y-12m-21d-10h-37m-34s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-modeset: dmesg-warn -> PASS (bsw-nuc-2) pass -> DMESG-WARN (hsw-gt2) dmesg-warn -> PASS (bdw-nuci7) pass -> DMESG-WARN (skl-i7k-2) pass -> DMESG-WARN (byt-nuc) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-a: pass -> DMESG-WARN (snb-x220t) Subgroup read-crc-pipe-b-frame-sequence: dmesg-warn -> PASS (byt-nuc) Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (snb-x220t) bdw-nuci7total:132 pass:122 dwarn:1 dfail:0 fail:0 skip:9 bdw-ultratotal:132 pass:124 dwarn:2 dfail:0 fail:0 skip:6 bsw-nuc-2total:135 pass:114 dwarn:1 dfail:0 fail:0 skip:20 byt-nuc total:135 pass:120 dwarn:2 dfail:0 fail:0 skip:13 hsw-brixbox total:135 pass:126 dwarn:2 dfail:0 fail:0 skip:7 hsw-gt2 total:135 pass:129 dwarn:2 dfail:0 fail:0 skip:4 ilk-hp8440p total:135 pass:100 dwarn:0 dfail:0 fail:0 skip:35 ivb-t430stotal:135 pass:127 dwarn:2 dfail:0 fail:0 skip:6 skl-i5k-2total:135 pass:121 dwarn:6 dfail:0 fail:0 skip:8 skl-i7k-2total:135 pass:121 dwarn:6 dfail:0 fail:0 skip:8 snb-dellxps total:135 pass:121 dwarn:2 dfail:0 fail:0 skip:12 snb-x220ttotal:135 pass:121 dwarn:2 dfail:0 fail:1 skip:11 Results at /archive/results/CI_IGT_test/Patchwork_774/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ warning: Fi.CI.BAT
== Summary == Built on c7ae36da9cc3dd7480cec86a8b19fc76d075927d drm-intel-nightly: 2015y-12m-21d-10h-37m-34s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-modeset: dmesg-warn -> PASS (bsw-nuc-2) pass -> DMESG-WARN (hsw-gt2) dmesg-warn -> PASS (bdw-nuci7) pass -> DMESG-WARN (skl-i7k-2) pass -> DMESG-WARN (byt-nuc) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-a: pass -> DMESG-WARN (snb-x220t) Subgroup read-crc-pipe-b-frame-sequence: dmesg-warn -> PASS (byt-nuc) Subgroup suspend-read-crc-pipe-b: dmesg-warn -> PASS (snb-x220t) bdw-nuci7total:132 pass:122 dwarn:1 dfail:0 fail:0 skip:9 bdw-ultratotal:132 pass:124 dwarn:2 dfail:0 fail:0 skip:6 bsw-nuc-2total:135 pass:114 dwarn:1 dfail:0 fail:0 skip:20 byt-nuc total:135 pass:120 dwarn:2 dfail:0 fail:0 skip:13 hsw-brixbox total:135 pass:126 dwarn:2 dfail:0 fail:0 skip:7 hsw-gt2 total:135 pass:129 dwarn:2 dfail:0 fail:0 skip:4 ilk-hp8440p total:135 pass:100 dwarn:0 dfail:0 fail:0 skip:35 ivb-t430stotal:135 pass:127 dwarn:2 dfail:0 fail:0 skip:6 skl-i5k-2total:135 pass:121 dwarn:6 dfail:0 fail:0 skip:8 skl-i7k-2total:135 pass:121 dwarn:6 dfail:0 fail:0 skip:8 snb-dellxps total:135 pass:121 dwarn:2 dfail:0 fail:0 skip:12 snb-x220ttotal:135 pass:121 dwarn:2 dfail:0 fail:1 skip:11 Results at /archive/results/CI_IGT_test/Patchwork_774/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Hide one invalid cancellation bug in i915_switch_context()
On Thu, Dec 17, 2015 at 06:18:05PM +, Chris Wilson wrote:
> As we add the VMA to the request early, it may be cancelled during
> execbuf reservation. This will leave the context object pointing to a
> dangling request; i915_wait_request() simply skips the wait and so we
> may unbind the object whilst it is still active.
>
> We can partially prevent such atrocity by doing the RCS context
> initialisation earlier. This ensures that one callsite from blowing up
> (and for igt this is a frequent culprit due to how the stressful batches
> are submitted).
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 29 +
> 1 file changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 900ffd044db8..657686e6492f 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -657,7 +657,6 @@ static int do_switch(struct drm_i915_gem_request *req)
> struct drm_i915_private *dev_priv = ring->dev->dev_private;
> struct intel_context *from = ring->last_context;
> u32 hw_flags = 0;
> - bool uninitialized = false;
> int ret, i;
>
> if (from != NULL && ring == &dev_priv->ring[RCS]) {
> @@ -764,6 +763,15 @@ static int do_switch(struct drm_i915_gem_request *req)
> to->remap_slice &= ~(1< }
>
> + if (!to->legacy_hw_ctx.initialized) {
> + if (ring->init_context) {
> + ret = ring->init_context(req);
> + if (ret)
> + goto unpin_out;
> + }
> + to->legacy_hw_ctx.initialized = true;
> + }
> +
> /* The backing object for the context is done after switching to the
>* *next* context. Therefore we cannot retire the previous context until
>* the next context has already started running. In fact, the below code
> @@ -772,6 +780,14 @@ static int do_switch(struct drm_i915_gem_request *req)
>*/
> if (from != NULL) {
> from->legacy_hw_ctx.rcs_state->base.read_domains =
> I915_GEM_DOMAIN_INSTRUCTION;
> + /* XXX Note very well this is dangerous!
> + * We are pinning this object using this request as our
> + * active reference. However, this request may yet be cancelled
> + * during the execbuf dispatch, leaving us waiting on a
> + * dangling request. Waiting upon this dangling request is
> + * ignored, which means that we may unbind the context whilst
> + * the GPU is still writing to the backing storage.
> + */
>
> i915_vma_move_to_active(i915_gem_obj_to_ggtt(from->legacy_hw_ctx.rcs_state),
> req);
Hm, since this is just a partial fix, what about instead marking any
request that has been put to use already in move_to_active. And then when
we try to cancel it from execbuf notice that and not cancel it? Fixes both
bugs and makes the entire thing a bit more robust since it allows us to
throw stuff at a request without ordering constraints.
-Daniel
> /* As long as MI_SET_CONTEXT is serializing, ie. it flushes the
>* whole damn pipeline, we don't need to explicitly mark the
> @@ -787,21 +803,10 @@ static int do_switch(struct drm_i915_gem_request *req)
> i915_gem_context_unreference(from);
> }
>
> - uninitialized = !to->legacy_hw_ctx.initialized;
> - to->legacy_hw_ctx.initialized = true;
> -
> done:
> i915_gem_context_reference(to);
> ring->last_context = to;
>
> - if (uninitialized) {
> - if (ring->init_context) {
> - ret = ring->init_context(req);
> - if (ret)
> - DRM_ERROR("ring init context: %d\n", ret);
> - }
> - }
> -
> return 0;
>
> unpin_out:
> --
> 2.6.4
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] drm: Create Color Management DRM properties
On Fri, Dec 18, 2015 at 04:53:28PM +, Daniel Stone wrote:
> [Paging danvet to the bottom paragraphs re client-cap ...]
>
> Hi Lionel,
> I've still got quite a few concerns about the implementation as it
> stands. Some are minor quibbles (e.g. can't unset blob IDs), some are
> larger design issues, some are rehashed comments from previous series,
> and some are new now I've looked at it afresh.
>
> On 17 December 2015 at 18:57, Lionel Landwerlin
> wrote:
> > DRM color manager supports these color properties:
> > 1. "ctm": Color transformation matrix property, where a
> >color transformation matrix of 9 correction values gets
> >applied as correction.
> > 2. "palette_before_ctm": for corrections which get applied
> >beore color transformation matrix correction.
> > 3. "palette_after_ctm": for corrections which get applied
> >after color transformation matrix correction.
>
> These all appear to be pretty common, at least for the platforms I've
> checked. So, sounds good. You might want to document that before and
> after palettes are often referred to as degamma and gamma,
> respectively, though.
>
> > /**
> > + * drm_atomic_crtc_set_blob - find and set a blob
> > + * @state_blob: reference pointer to the color blob in the crtc_state
> > + * @blob_id: blob_id coming from set_property() call
> > + *
> > + * Set a color correction blob (originating from a set blob property) on
> > the
> > + * desired CRTC state. This function will take reference of the blob
> > property
> > + * in the CRTC state, finds the blob based on blob_id (which comes from
> > + * set_property call) and set the blob at the proper place.
> > + *
> > + * RETURNS:
> > + * Zero on success, error code on failure.
> > + */
> > +static int drm_atomic_crtc_set_blob(struct drm_device *dev,
> > + struct drm_property_blob **state_blob, uint32_t blob_id)
> > +{
> > + struct drm_property_blob *blob;
> > +
> > + blob = drm_property_lookup_blob(dev, blob_id);
> > + if (!blob) {
> > + DRM_DEBUG_KMS("Invalid Blob ID\n");
> > + return -EINVAL;
> > + }
>
> This needs to handle blob_id == 0, to unset it. Initialising 'blob' to
> NULL and wrapping the lookup_blob check in if (blob_id != 0) should do
> it. While you're at it, a more helpful error message (e.g. actually
> listing the blob ID) might be in order. And IGT.
>
> Making crtc_state->MODE_ID use this helper, and kms_atomic not
> breaking, would be a fairly good indication that you've got it right.
> ;)
>
> > @@ -305,11 +305,15 @@ struct drm_plane_helper_funcs;
> > * @mode_changed: crtc_state->mode or crtc_state->enable has been changed
> > * @active_changed: crtc_state->active has been toggled.
> > * @connectors_changed: connectors to this crtc have been updated
> > + * @color_correction_changed: color correction blob in this crtc got
> > updated
> > * @plane_mask: bitmask of (1 << drm_plane_index(plane)) of attached planes
> > * @last_vblank_count: for helpers and drivers to capture the vblank of the
> > * update to ensure framebuffer cleanup isn't done too early
> > * @adjusted_mode: for use by helpers and drivers to compute adjusted mode
> > timings
> > * @mode: current mode timings
> > + * @palette_before_ctm_blob: blob for color corrections to be applied
> > after CTM
> > + * @palette_after_ctm_blob: blob for color corrections to be applied
> > before CTM
> > + * @ctm_blob: blob for CTM color correction
>
> For instance, documenting (de)gamma terminology here might be nice.
>
> > @@ -2019,6 +2029,11 @@ struct drm_mode_config_funcs {
> > * @property_blob_list: list of all the blob property objects
> > * @blob_lock: mutex for blob property allocation and management
> > * @*_property: core property tracking
> > + * @cm_palette_before_ctm_property: color corrections before CTM block
> > + * @cm_palette_after_ctm_property: color corrections after CTM block
> > + * @cm_ctm_property: color transformation matrix correction
> > + * @cm_coeff_before_ctm_property: query no of correction coeffi before CTM
> > + * @cm_coeff_after_ctm_property: query no of correction coeffi after CTM
>
> 'coeffi'? These also aren't sufficient either (see my descent into
> madness in the BDW patch), I don't think.
Yeah there's a question about how to best document new atomic extensions.
Traditionally we haven't documented the properties themselves (hence the
*_property), and I think that makes sense since it's a very large pile.
Two options left:
- Extensively document all the properties for a new feature in the drm
core function to attach the props to a plane/crtc.
- Document them in the drm_*_state structures. There we can even use the
new per-member kerneldoc layout to go into great details.
Probably best to do both and link between the two places.
>
> > +struct drm_r32g32b32 {
> > + /*
> > +* Data is in U8.24 fixed point format.
> > +* All platforms support values within [0,
Re: [Intel-gfx] [PATCH 1/6] drm: Create Color Management DRM properties
On Thu, Dec 17, 2015 at 06:57:53PM +, Lionel Landwerlin wrote:
> From: Shashank Sharma
>
> Color Management is an extension to DRM framework to allow hardware color
> correction and enhancement capabilities.
>
> DRM color manager supports these color properties:
> 1. "ctm": Color transformation matrix property, where a
>color transformation matrix of 9 correction values gets
>applied as correction.
> 2. "palette_before_ctm": for corrections which get applied
>beore color transformation matrix correction.
> 3. "palette_after_ctm": for corrections which get applied
>after color transformation matrix correction.
>
> These color correction capabilities may differ per platform, supporting
> various different no. of correction coefficients. So DRM color manager
> support few properties using which a user space can query the platform's
> capability, and prepare color correction accordingly.
> These query properties are:
> 1. cm_coeff_after_ctm_property
> 2. cm_coeff_before_ctm_property
> (CTM is fix to 9 coefficients across industry)
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> ---
> drivers/gpu/drm/drm_atomic.c| 67
> +++--
> drivers/gpu/drm/drm_atomic_helper.c | 9 +
> drivers/gpu/drm/drm_crtc.c | 32 ++
> include/drm/drm_crtc.h | 24 +
> include/uapi/drm/drm.h | 30 +
> 5 files changed, 160 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 6a21e5c..ebdb98d 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -388,6 +388,38 @@ int drm_atomic_set_mode_prop_for_crtc(struct
> drm_crtc_state *state,
> EXPORT_SYMBOL(drm_atomic_set_mode_prop_for_crtc);
>
> /**
> + * drm_atomic_crtc_set_blob - find and set a blob
> + * @state_blob: reference pointer to the color blob in the crtc_state
> + * @blob_id: blob_id coming from set_property() call
> + *
> + * Set a color correction blob (originating from a set blob property) on the
> + * desired CRTC state. This function will take reference of the blob property
> + * in the CRTC state, finds the blob based on blob_id (which comes from
> + * set_property call) and set the blob at the proper place.
> + *
> + * RETURNS:
> + * Zero on success, error code on failure.
> + */
> +static int drm_atomic_crtc_set_blob(struct drm_device *dev,
> + struct drm_property_blob **state_blob, uint32_t blob_id)
I think we need to at least split this into a ctm and gamma table variant
to be able to have a size check for the passed-in blob:
- ctm must exactly match the size we expect
- gamma table must be an integer multiple of the drm_r32g32b32 struct.
Also we should probably have a little helper to compute the size of the
gamma lut in entries (just the size/sizeof(drm_r32g32b32) division
really).
The other bits that's missing here is a drm core function to attach these
properties to planes/crtc. We don't want every driver to roll their own
implementation, since it'll lead to fun divergence between different
implementations. Also, that main function could be used to place the ABI
rules someplace nice (like how generic userspace is supposed to interact
with color manager props).
-Daniel
> +{
> + struct drm_property_blob *blob;
> +
> + blob = drm_property_lookup_blob(dev, blob_id);
> + if (!blob) {
> + DRM_DEBUG_KMS("Invalid Blob ID\n");
> + return -EINVAL;
> + }
> +
> + if (*state_blob)
> + drm_property_unreference_blob(*state_blob);
> +
> + /* Attach the blob to be committed in state */
> + *state_blob = blob;
> + return 0;
> +}
> +
> +/**
> * drm_atomic_crtc_set_property - set property on CRTC
> * @crtc: the drm CRTC to set a property on
> * @state: the state object to update with the new property value
> @@ -419,8 +451,31 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> ret = drm_atomic_set_mode_prop_for_crtc(state, mode);
> drm_property_unreference_blob(mode);
> return ret;
> - }
> - else if (crtc->funcs->atomic_set_property)
> + } else if (property == config->cm_palette_after_ctm_property) {
> + ret = drm_atomic_crtc_set_blob(dev,
> + &state->palette_after_ctm_blob, val);
> + if (ret)
> + DRM_DEBUG_KMS("Failed to load blob
> palette_after_ctm\n");
> + else
> + state->color_correction_changed = true;
> + return ret;
> + } else if (property == config->cm_palette_before_ctm_property) {
> + ret = drm_atomic_crtc_set_blob(dev,
> + &state->palette_before_ctm_blob, val);
> + if (ret)
> + DRM_DEBUG_KMS("Failed to load blob
> palette_before_ctm\n");
> + else
> +
Re: [Intel-gfx] [PATCH 4/6] drm/i915/chv: Implement color management
On Thu, Dec 17, 2015 at 06:57:56PM +, Lionel Landwerlin wrote:
> From: Shashank Sharma
>
> Implement degamma, csc and gamma steps on CHV.
>
> Signed-off-by: Shashank Sharma
> Signed-off-by: Kausal Malladi
> ---
> drivers/gpu/drm/i915/Makefile | 3 +-
> drivers/gpu/drm/i915/i915_drv.c| 5 +-
> drivers/gpu/drm/i915/i915_drv.h| 2 +
> drivers/gpu/drm/i915/i915_reg.h| 26 +++
> drivers/gpu/drm/i915/intel_color_manager.c | 353
> +
> drivers/gpu/drm/i915/intel_color_manager.h | 91
> drivers/gpu/drm/i915/intel_display.c | 2 +
> drivers/gpu/drm/i915/intel_drv.h | 4 +
> 8 files changed, 484 insertions(+), 2 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/intel_color_manager.c
> create mode 100644 drivers/gpu/drm/i915/intel_color_manager.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 0851de07..c66d56a 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -64,7 +64,8 @@ i915-y += intel_audio.o \
> intel_overlay.o \
> intel_psr.o \
> intel_sideband.o \
> - intel_sprite.o
> + intel_sprite.o \
> + intel_color_manager.o
> i915-$(CONFIG_ACPI) += intel_acpi.o intel_opregion.o
> i915-$(CONFIG_DRM_FBDEV_EMULATION) += intel_fbdev.o
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 3ac616d..4396300 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -34,6 +34,7 @@
> #include "i915_drv.h"
> #include "i915_trace.h"
> #include "intel_drv.h"
> +#include "intel_color_manager.h"
>
> #include
> #include
> @@ -311,7 +312,9 @@ static const struct intel_device_info
> intel_cherryview_info = {
> .gen = 8, .num_pipes = 3,
> .need_gfx_hws = 1, .has_hotplug = 1,
> .ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
> - .is_cherryview = 1,
> + .is_valleyview = 1,
> + .num_samples_after_ctm = CHV_10BIT_GAMMA_MAX_VALS,
> + .num_samples_before_ctm = CHV_DEGAMMA_MAX_VALS,
> .display_mmio_offset = VLV_DISPLAY_BASE,
> GEN_CHV_PIPEOFFSETS,
> CURSOR_OFFSETS,
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 1d28d90..4eb0fab 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -793,6 +793,8 @@ struct intel_device_info {
> u8 num_sprites[I915_MAX_PIPES];
> u8 gen;
> u8 ring_mask; /* Rings supported by the HW */
> + u16 num_samples_after_ctm;
> + u16 num_samples_before_ctm;
> DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG, SEP_SEMICOLON);
> /* Register offsets for the various display pipes and transcoders */
> int pipe_offsets[I915_MAX_TRANSCODERS];
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 007ae83..36bb320 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -8154,4 +8154,30 @@ enum skl_disp_power_wells {
> #define GEN9_VEBOX_MOCS(i) _MMIO(0xcb00 + (i) * 4) /* Video MOCS registers
> */
> #define GEN9_BLT_MOCS(i) _MMIO(0xcc00 + (i) * 4) /* Blitter MOCS
> registers */
>
> +/* Color Management */
> +#define PIPEA_CGM_CONTROL(VLV_DISPLAY_BASE + 0x67A00)
> +#define PIPEB_CGM_CONTROL(VLV_DISPLAY_BASE + 0x69A00)
> +#define PIPEC_CGM_CONTROL(VLV_DISPLAY_BASE + 0x6BA00)
> +#define PIPEA_CGM_GAMMA (VLV_DISPLAY_BASE + 0x67000)
> +#define PIPEB_CGM_GAMMA (VLV_DISPLAY_BASE + 0x69000)
> +#define PIPEC_CGM_GAMMA (VLV_DISPLAY_BASE + 0x6B000)
> +#define _PIPE_CGM_CONTROL(pipe) \
> + (_PIPE3(pipe, PIPEA_CGM_CONTROL, PIPEB_CGM_CONTROL, PIPEC_CGM_CONTROL))
> +#define _PIPE_GAMMA_BASE(pipe) \
> + (_PIPE3(pipe, PIPEA_CGM_GAMMA, PIPEB_CGM_GAMMA, PIPEC_CGM_GAMMA))
> +
> +#define PIPEA_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x66000)
> +#define PIPEB_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x68000)
> +#define PIPEC_CGM_DEGAMMA (VLV_DISPLAY_BASE + 0x6A000)
> +#define _PIPE_DEGAMMA_BASE(pipe) \
> + (_PIPE3(pipe, PIPEA_CGM_DEGAMMA, PIPEB_CGM_DEGAMMA, PIPEC_CGM_DEGAMMA))
> +
> +#define PIPEA_CGM_CSC(VLV_DISPLAY_BASE +
> 0x67900)
> +#define PIPEB_CGM_CSC(VLV_DISPLAY_BASE +
> 0x69900)
> +#define PIPEC_CGM_CSC(VLV_DISPLAY_BASE +
> 0x6B900)
> +#define _PIPE_CSC_BASE(pipe) \
> + (_PIPE3(pipe, PIPEA_CGM_CSC, PIPEB_CGM_CSC, PIPEC_CGM_CSC))
> +
> +
> +
> #endif /* _I915_REG_H_ */
> diff --git a/drivers/gpu/drm/i915/intel_color_manager.c
> b/drivers/gpu/drm/i915/intel_color_manager.c
> new file mode 100644
> index 000..02eee98
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/intel_color_
Re: [Intel-gfx] [PATCH] drm/i915: Hide one invalid cancellation bug in i915_switch_context()
On Mon, Dec 21, 2015 at 01:28:17PM +0100, Daniel Vetter wrote:
> On Thu, Dec 17, 2015 at 06:18:05PM +, Chris Wilson wrote:
> > As we add the VMA to the request early, it may be cancelled during
> > execbuf reservation. This will leave the context object pointing to a
> > dangling request; i915_wait_request() simply skips the wait and so we
> > may unbind the object whilst it is still active.
> >
> > We can partially prevent such atrocity by doing the RCS context
> > initialisation earlier. This ensures that one callsite from blowing up
> > (and for igt this is a frequent culprit due to how the stressful batches
> > are submitted).
> >
> > Signed-off-by: Chris Wilson
> > Cc: Daniel Vetter
> > Cc: sta...@vger.kernel.org
> > ---
> > drivers/gpu/drm/i915/i915_gem_context.c | 29 +
> > 1 file changed, 17 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> > b/drivers/gpu/drm/i915/i915_gem_context.c
> > index 900ffd044db8..657686e6492f 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_context.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> > @@ -657,7 +657,6 @@ static int do_switch(struct drm_i915_gem_request *req)
> > struct drm_i915_private *dev_priv = ring->dev->dev_private;
> > struct intel_context *from = ring->last_context;
> > u32 hw_flags = 0;
> > - bool uninitialized = false;
> > int ret, i;
> >
> > if (from != NULL && ring == &dev_priv->ring[RCS]) {
> > @@ -764,6 +763,15 @@ static int do_switch(struct drm_i915_gem_request *req)
> > to->remap_slice &= ~(1< > }
> >
> > + if (!to->legacy_hw_ctx.initialized) {
> > + if (ring->init_context) {
> > + ret = ring->init_context(req);
> > + if (ret)
> > + goto unpin_out;
> > + }
> > + to->legacy_hw_ctx.initialized = true;
> > + }
> > +
> > /* The backing object for the context is done after switching to the
> > * *next* context. Therefore we cannot retire the previous context until
> > * the next context has already started running. In fact, the below code
> > @@ -772,6 +780,14 @@ static int do_switch(struct drm_i915_gem_request *req)
> > */
> > if (from != NULL) {
> > from->legacy_hw_ctx.rcs_state->base.read_domains =
> > I915_GEM_DOMAIN_INSTRUCTION;
> > + /* XXX Note very well this is dangerous!
> > +* We are pinning this object using this request as our
> > +* active reference. However, this request may yet be cancelled
> > +* during the execbuf dispatch, leaving us waiting on a
> > +* dangling request. Waiting upon this dangling request is
> > +* ignored, which means that we may unbind the context whilst
> > +* the GPU is still writing to the backing storage.
> > +*/
> >
> > i915_vma_move_to_active(i915_gem_obj_to_ggtt(from->legacy_hw_ctx.rcs_state),
> > req);
>
> Hm, since this is just a partial fix, what about instead marking any
> request that has been put to use already in move_to_active. And then when
> we try to cancel it from execbuf notice that and not cancel it? Fixes both
> bugs and makes the entire thing a bit more robust since it allows us to
> throw stuff at a request without ordering constraints.
Hmm, it leaks a bit furter than execbuffer. For example, we need to
submit the request to maintain our state tracking correctly for the
semaphores and whatnot for incomplete CS flips.
From inspection, we need:
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 730a6d2f5163..c33dd6f59064 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2708,12 +2708,9 @@ int i915_gpu_idle(struct drm_device *dev)
return PTR_ERR(req);
ret = i915_switch_context(req);
- if (ret) {
- i915_gem_request_cancel(req);
- return ret;
- }
-
i915_add_request_no_flush(req);
+ if (ret)
+ return ret;
}
ret = intel_engine_idle(ring);
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index be2302f8a0cf..2496dc0948e1 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1306,7 +1306,6 @@ execbuf_submit(struct i915_execbuffer_params *params,
trace_i915_gem_ring_dispatch(params->request, params->dispatch_flags);
i915_gem_execbuffer_move_to_active(vmas, params->request);
- i915_gem_execbuffer_retire_commands(params);
return 0;
}
@@ -1603,8 +1602,10 @@ i915_gem_do_execbuffer(struct drm_device *dev, void
*data,
}
ret = i915_gem_r
[Intel-gfx] [PATCH 03/15] drm/i915/bios: split the MIPI DSI VBT block parsing to two
There's two blocks to parse, have one function per block. The existing
one cuts neatly into two.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 27 +++
1 file changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index d487f602a10e..91540ab15e0b 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -765,16 +765,12 @@ static u8 *goto_next_sequence(u8 *data, int *size)
}
static void
-parse_mipi(struct drm_i915_private *dev_priv, const struct bdb_header *bdb)
+parse_mipi_config(struct drm_i915_private *dev_priv,
+ const struct bdb_header *bdb)
{
const struct bdb_mipi_config *start;
- const struct bdb_mipi_sequence *sequence;
const struct mipi_config *config;
const struct mipi_pps_data *pps;
- u8 *data;
- const u8 *seq_data;
- int i, panel_id, seq_size;
- u16 block_size;
/* parse MIPI blocks only if LFP type is MIPI */
if (!dev_priv->vbt.has_mipi)
@@ -820,8 +816,22 @@ parse_mipi(struct drm_i915_private *dev_priv, const struct
bdb_header *bdb)
/* We have mandatory mipi config blocks. Initialize as generic panel */
dev_priv->vbt.dsi.panel_id = MIPI_DSI_GENERIC_PANEL_ID;
+}
+
+static void
+parse_mipi_sequence(struct drm_i915_private *dev_priv,
+ const struct bdb_header *bdb)
+{
+ const struct bdb_mipi_sequence *sequence;
+ const u8 *seq_data;
+ u8 *data;
+ u16 block_size;
+ int i, panel_id, seq_size;
+
+ /* Only our generic panel driver uses the sequence block. */
+ if (dev_priv->vbt.dsi.panel_id != MIPI_DSI_GENERIC_PANEL_ID)
+ return;
- /* Check if we have sequence block as well */
sequence = find_section(bdb, BDB_MIPI_SEQUENCE);
if (!sequence) {
DRM_DEBUG_KMS("No MIPI Sequence found, parsing complete\n");
@@ -1359,7 +1369,8 @@ intel_bios_init(struct drm_i915_private *dev_priv)
parse_driver_features(dev_priv, bdb);
parse_edp(dev_priv, bdb);
parse_psr(dev_priv, bdb);
- parse_mipi(dev_priv, bdb);
+ parse_mipi_config(dev_priv, bdb);
+ parse_mipi_sequence(dev_priv, bdb);
parse_ddi_ports(dev_priv, bdb);
if (bios)
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/15] drm/i915/dsi: skip unknown elements for sequence block v3+
The sequence block has sizes of elements after the operation byte since
sequence block v3. Use it to skip elements we don't support yet.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 43 +-
1 file changed, 24 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index eabfd9eb9cc0..1f9c80d21904 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -335,31 +335,36 @@ static void generic_exec_sequence(struct intel_dsi
*intel_dsi, const u8 *data)
if (dev_priv->vbt.dsi.seq_version >= 3)
data += 4;
- /* parse each byte till we reach end of sequence byte - 0x00 */
while (1) {
u8 operation_byte = *data++;
- if (operation_byte >= ARRAY_SIZE(exec_elem) ||
- !exec_elem[operation_byte]) {
+ u8 operation_size = 0;
+
+ if (operation_byte == MIPI_SEQ_ELEM_END)
+ break;
+
+ if (operation_byte < ARRAY_SIZE(exec_elem) &&
+ exec_elem[operation_byte])
+ mipi_elem_exec = exec_elem[operation_byte];
+ else
+ mipi_elem_exec = NULL;
+
+ /* Size of Operation. */
+ if (dev_priv->vbt.dsi.seq_version >= 3)
+ operation_size = *data++;
+
+ if (mipi_elem_exec) {
+ data = mipi_elem_exec(intel_dsi, data);
+ } else if (operation_size) {
+ /* We have size, skip. */
+ DRM_DEBUG_KMS("Unsupported MIPI operation byte %u\n",
+ operation_byte);
+ data += operation_size;
+ } else {
+ /* No size, can't skip without parsing. */
DRM_ERROR("Unsupported MIPI operation byte %u\n",
operation_byte);
return;
}
- mipi_elem_exec = exec_elem[operation_byte];
-
- /* Skip Size of Operation. */
- if (dev_priv->vbt.dsi.seq_version >= 3)
- data++;
-
- /* execute the element specific rotines */
- data = mipi_elem_exec(intel_dsi, data);
-
- /*
-* After processing the element, data should point to
-* next element or end of sequence
-* check if have we reached end of sequence
-*/
- if (*data == 0x00)
- break;
}
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/15] drm/i915/dsi: be defensive about out of bounds sequence id
Untie the VBT based generic panel driver from the VBT parsing, so that
the two don't have to be updated in lockstep.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index a5e99ac305da..45512e0df57a 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -246,14 +246,21 @@ static const fn_mipi_elem_exec exec_elem[] = {
*/
static const char * const seq_name[] = {
- "UNDEFINED",
- "MIPI_SEQ_ASSERT_RESET",
- "MIPI_SEQ_INIT_OTP",
- "MIPI_SEQ_DISPLAY_ON",
- "MIPI_SEQ_DISPLAY_OFF",
- "MIPI_SEQ_DEASSERT_RESET"
+ [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
+ [MIPI_SEQ_INIT_OTP] = "MIPI_SEQ_INIT_OTP",
+ [MIPI_SEQ_DISPLAY_ON] = "MIPI_SEQ_DISPLAY_ON",
+ [MIPI_SEQ_DISPLAY_OFF] = "MIPI_SEQ_DISPLAY_OFF",
+ [MIPI_SEQ_DEASSERT_RESET] = "MIPI_SEQ_DEASSERT_RESET",
};
+static const char *sequence_name(enum mipi_seq seq_id)
+{
+ if (seq_id < ARRAY_SIZE(seq_name) && seq_name[seq_id])
+ return seq_name[seq_id];
+ else
+ return "(unknown)";
+}
+
static void generic_exec_sequence(struct intel_dsi *intel_dsi, const u8 *data)
{
fn_mipi_elem_exec mipi_elem_exec;
@@ -262,7 +269,8 @@ static void generic_exec_sequence(struct intel_dsi
*intel_dsi, const u8 *data)
if (!data)
return;
- DRM_DEBUG_DRIVER("Starting MIPI sequence - %s\n", seq_name[*data]);
+ DRM_DEBUG_DRIVER("Starting MIPI sequence %u - %s\n",
+*data, sequence_name(*data));
/* go to the first element of the sequence */
data++;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/15] drm/i915/bios: mipi sequence block v3, etc.
Hi all, this is follow-up to my earlier opregion/vbt series [1]. This covers patches 1 and 7 of Deepak's series [2], but does quite a bunch of rework to make everything as neat as it can be given the spec. There's also some generic VBT documentation. Unfortunately I haven't been able to test this on a machine that actually has MIPI sequence block v3. However most of the series does not touch that yet. BR, Jani. [1] http://mid.gmane.org/cover.1450089383.git.jani.nik...@intel.com [2] http://mid.gmane.org/1448923632-16760-1-git-send-email-m.dee...@intel.com Jani Nikula (14): drm/i915/bios: add proper documentation for the Video BIOS Table (VBT) drm/i915/bios: fix header define name for intel_bios.h drm/i915/bios: split the MIPI DSI VBT block parsing to two drm/i915/bios: have get_blocksize() support MIPI sequence block v3+ drm/i915/bios: abstract finding the panel sequence block drm/i915/bios: rewrite sequence block parsing drm/i915/dsi: be defensive about out of bounds sequence id drm/i915/dsi: be defensive about out of bounds operation byte drm/i915/bios: interpret the i2c element drm/i915/bios: add sequences for MIPI sequence block v2 drm/i915/bios: add defines for v3 sequence block drm/i915/bios: add support for MIPI sequence block v3 drm/i915/dsi: skip unknown elements for sequence block v3+ drm/i915/dsi: reduce tedious repetition vkorjani (1): drm/i915: Adding the parsing logic for the i2c element Documentation/DocBook/gpu.tmpl | 6 + drivers/gpu/drm/i915/i915_drv.h| 2 +- drivers/gpu/drm/i915/intel_bios.c | 376 + drivers/gpu/drm/i915/intel_bios.h | 60 +++-- drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 198 +-- 5 files changed, 397 insertions(+), 245 deletions(-) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/15] drm/i915/bios: interpret the i2c element
Add parsing of the i2c element, defined in MIPI sequence block v2. Drop
the status operation byte while at it, that does not exist.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 5 +
drivers/gpu/drm/i915/intel_bios.h | 2 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index d6eaf32f33e5..45a7a2bc96c6 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -812,6 +812,11 @@ static int goto_next_sequence(const u8 *data, int index,
int total)
case MIPI_SEQ_ELEM_GPIO:
len = 2;
break;
+ case MIPI_SEQ_ELEM_I2C:
+ if (index + 7 > total)
+ return 0;
+ len = *(data + index + 6) + 7;
+ break;
default:
DRM_ERROR("Unknown operation byte\n");
return 0;
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 4e87df16e7b3..411b33794536 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -968,7 +968,7 @@ enum mipi_seq_element {
MIPI_SEQ_ELEM_SEND_PKT,
MIPI_SEQ_ELEM_DELAY,
MIPI_SEQ_ELEM_GPIO,
- MIPI_SEQ_ELEM_STATUS,
+ MIPI_SEQ_ELEM_I2C, /* sequence block v2+ */
MIPI_SEQ_ELEM_MAX
};
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/15] drm/i915/bios: add sequences for MIPI sequence block v2
Properly parse the new sequences added in MIPI sequence block v2.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 411b33794536..6146f1b0cf48 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -960,6 +960,9 @@ enum mipi_seq {
MIPI_SEQ_DISPLAY_ON,
MIPI_SEQ_DISPLAY_OFF,
MIPI_SEQ_DEASSERT_RESET,
+ MIPI_SEQ_BACKLIGHT_ON, /* sequence block v2+ */
+ MIPI_SEQ_BACKLIGHT_OFF, /* sequence block v2+ */
+ MIPI_SEQ_TEAR_ON, /* sequence block v2+ */
MIPI_SEQ_MAX
};
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/15] drm/i915/bios: add proper documentation for the Video BIOS Table (VBT)
Add an overview and documentation for the VBT/BDB header structures.
Signed-off-by: Jani Nikula
---
Documentation/DocBook/gpu.tmpl| 6 ++
drivers/gpu/drm/i915/intel_bios.c | 24 +++-
drivers/gpu/drm/i915/intel_bios.h | 38 --
3 files changed, 57 insertions(+), 11 deletions(-)
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 6c6e81a9eaf4..f96a5d467f84 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -3507,6 +3507,12 @@ int num_ioctls;
!Pdrivers/gpu/drm/i915/intel_csr.c csr support for dmc
!Idrivers/gpu/drm/i915/intel_csr.c
+
+ Video BIOS Table (VBT)
+!Pdrivers/gpu/drm/i915/intel_bios.c Video BIOS Table (VBT)
+!Idrivers/gpu/drm/i915/intel_bios.c
+!Idrivers/gpu/drm/i915/intel_bios.h
+
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index eba3e0f87181..d487f602a10e 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -31,6 +31,28 @@
#include "i915_drv.h"
#include "intel_bios.h"
+/**
+ * DOC: Video BIOS Table (VBT)
+ *
+ * The Video BIOS Table, or VBT, provides platform and board specific
+ * configuration information to the driver that is not discoverable or
available
+ * through other means. The configuration is mostly related to display
+ * hardware. The VBT is available via the ACPI OpRegion or, on older systems,
in
+ * the PCI ROM.
+ *
+ * The VBT consists of a VBT Header (defined as &struct vbt_header), BDB Header
+ * (&struct bdb_header), and a number of BIOS Data Blocks (BDB) that contain
the
+ * actual configuration information. The VBT Header, and thus the VBT, begins
+ * with "$VBT" signature. The VBT Header contains the offset of the BDB
+ * Header. The data blocks are concatenated after the BDB Header. The data
+ * blocks have a 1-byte Block ID, 2-byte Block Size, and Block Size bytes of
+ * data. (Block 53, the MIPI Sequence Block is an exception.)
+ *
+ * The driver parses the VBT during load. The relevant information is stored in
+ * driver private data for ease of use, and the actual VBT is not read after
+ * that.
+ */
+
#defineSLAVE_ADDR1 0x70
#defineSLAVE_ADDR2 0x72
@@ -1285,7 +1307,7 @@ static const struct vbt_header *find_vbt(void __iomem
*bios, size_t size)
/**
* intel_bios_init - find VBT and initialize settings from the BIOS
- * @dev: DRM device
+ * @dev_priv: i915 device instance
*
* Loads the Video BIOS and checks that the VBT exists. Sets scratch registers
* to appropriate values.
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 54eac1003a1e..2dc46a98c332 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -28,22 +28,40 @@
#ifndef _I830_BIOS_H_
#define _I830_BIOS_H_
+/**
+ * struct vbt_header - VBT Header structure
+ * @signature: VBT signature, always starts with "$VBT"
+ * @version: Version of this structure
+ * @header_size: Size of this structure
+ * @vbt_size: Size of VBT (VBT Header, BDB Header and data blocks)
+ * @vbt_checksum: Checksum
+ * @reserved0: Reserved
+ * @bdb_offset:Offset of &struct bdb_header from beginning of
VBT
+ * @aim_offset:Offsets of add-in data blocks from beginning of
VBT
+ */
struct vbt_header {
- u8 signature[20]; /**< Always starts with 'VBT$' */
- u16 version;/**< decimal */
- u16 header_size;/**< in bytes */
- u16 vbt_size; /**< in bytes */
+ u8 signature[20];
+ u16 version;
+ u16 header_size;
+ u16 vbt_size;
u8 vbt_checksum;
u8 reserved0;
- u32 bdb_offset; /**< from beginning of VBT */
- u32 aim_offset[4]; /**< from beginning of VBT */
+ u32 bdb_offset;
+ u32 aim_offset[4];
} __packed;
+/**
+ * struct bdb_header - BDB Header structure
+ * @signature: BDB signature "BIOS_DATA_BLOCK"
+ * @version: Version of the data block definitions
+ * @header_size: Size of this structure
+ * @bdb_size: Size of BDB (BDB Header and data blocks)
+ */
struct bdb_header {
- u8 signature[16]; /**< Always 'BIOS_DATA_BLOCK' */
- u16 version;/**< decimal */
- u16 header_size;/**< in bytes */
- u16 bdb_size; /**< in bytes */
+ u8 signature[16];
+ u16 version;
+ u16 header_size;
+ u16 bdb_size;
} __packed;
/* strictly speaking, this is a "skip" block, but it has interesting info */
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/15] drm/i915/bios: rewrite sequence block parsing
Make everything a bit more readable and clear.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_bios.c | 158 +-
drivers/gpu/drm/i915/intel_bios.h | 4 +-
3 files changed, 57 insertions(+), 107 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9b82c4532893..07c4fc539680 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1487,7 +1487,7 @@ struct intel_vbt_data {
u8 seq_version;
u32 size;
u8 *data;
- u8 *sequence[MIPI_SEQ_MAX];
+ const u8 *sequence[MIPI_SEQ_MAX];
} dsi;
int crt_ddc_pin;
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 9511a5341562..d6eaf32f33e5 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -697,73 +697,6 @@ parse_psr(struct drm_i915_private *dev_priv, const struct
bdb_header *bdb)
dev_priv->vbt.psr.tp2_tp3_wakeup_time = psr_table->tp2_tp3_wakeup_time;
}
-static u8 *goto_next_sequence(u8 *data, u16 *size)
-{
- u16 len;
- int tmp = *size;
-
- if (--tmp < 0)
- return NULL;
-
- /* goto first element */
- data++;
- while (1) {
- switch (*data) {
- case MIPI_SEQ_ELEM_SEND_PKT:
- /*
-* skip by this element payload size
-* skip elem id, command flag and data type
-*/
- tmp -= 5;
- if (tmp < 0)
- return NULL;
-
- data += 3;
- len = *((u16 *)data);
-
- tmp -= len;
- if (tmp < 0)
- return NULL;
-
- /* skip by len */
- data = data + 2 + len;
- break;
- case MIPI_SEQ_ELEM_DELAY:
- /* skip by elem id, and delay is 4 bytes */
- tmp -= 5;
- if (tmp < 0)
- return NULL;
-
- data += 5;
- break;
- case MIPI_SEQ_ELEM_GPIO:
- tmp -= 3;
- if (tmp < 0)
- return NULL;
-
- data += 3;
- break;
- default:
- DRM_ERROR("Unknown element\n");
- return NULL;
- }
-
- /* end of sequence ? */
- if (*data == 0)
- break;
- }
-
- /* goto next sequence or end of block byte */
- if (--tmp < 0)
- return NULL;
-
- data++;
-
- /* update amount of data left for the sequence block to be parsed */
- *size = tmp;
- return data;
-}
-
static void
parse_mipi_config(struct drm_i915_private *dev_priv,
const struct bdb_header *bdb)
@@ -855,6 +788,39 @@ find_panel_sequence_block(const struct bdb_mipi_sequence
*sequence,
return NULL;
}
+static int goto_next_sequence(const u8 *data, int index, int total)
+{
+ u16 len;
+
+ /* Skip Sequence Byte. */
+ for (index = index + 1; index < total; index += len) {
+ u8 operation_byte = *(data + index);
+ index++;
+
+ switch (operation_byte) {
+ case MIPI_SEQ_ELEM_END:
+ return index;
+ case MIPI_SEQ_ELEM_SEND_PKT:
+ if (index + 4 > total)
+ return 0;
+
+ len = *((const u16 *)(data + index + 2)) + 4;
+ break;
+ case MIPI_SEQ_ELEM_DELAY:
+ len = 4;
+ break;
+ case MIPI_SEQ_ELEM_GPIO:
+ len = 2;
+ break;
+ default:
+ DRM_ERROR("Unknown operation byte\n");
+ return 0;
+ }
+ }
+
+ return 0;
+}
+
static void
parse_mipi_sequence(struct drm_i915_private *dev_priv,
const struct bdb_header *bdb)
@@ -863,7 +829,7 @@ parse_mipi_sequence(struct drm_i915_private *dev_priv,
const u8 *seq_data;
u16 seq_size;
u8 *data;
- u16 block_size;
+ int index = 0;
/* Only our generic panel driver uses the sequence block. */
if (dev_priv->vbt.dsi.panel_id != MIPI_DSI_GENERIC_PANEL_ID)
@@ -883,59 +849,43 @@ parse_mipi_sequence(struct drm_i915_private *dev_priv,
DRM_DEBUG_DRIVER("Found MIPI sequence block\n");
- block_size = get_blocksize(sequence);
-
- /*
-* pars
[Intel-gfx] [PATCH 05/15] drm/i915/bios: abstract finding the panel sequence block
Make the whole thing easier to read.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 76 +--
1 file changed, 42 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 7393596df37d..9511a5341562 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -697,7 +697,7 @@ parse_psr(struct drm_i915_private *dev_priv, const struct
bdb_header *bdb)
dev_priv->vbt.psr.tp2_tp3_wakeup_time = psr_table->tp2_tp3_wakeup_time;
}
-static u8 *goto_next_sequence(u8 *data, int *size)
+static u8 *goto_next_sequence(u8 *data, u16 *size)
{
u16 len;
int tmp = *size;
@@ -818,15 +818,52 @@ parse_mipi_config(struct drm_i915_private *dev_priv,
dev_priv->vbt.dsi.panel_id = MIPI_DSI_GENERIC_PANEL_ID;
}
+/* Find the sequence block and size for the given panel. */
+static const u8 *
+find_panel_sequence_block(const struct bdb_mipi_sequence *sequence,
+ u16 panel_id, u16 *seq_size)
+{
+ u32 total = get_blocksize(sequence);
+ const u8 *data = &sequence->data[0];
+ u8 current_id;
+ u16 current_size;
+ int index = 0;
+ int i;
+
+ for (i = 0; i < MAX_MIPI_CONFIGURATIONS && index + 3 < total; i++) {
+ current_id = *(data + index);
+ index++;
+
+ current_size = *((const u16 *)(data + index));
+ index += 2;
+
+ if (index + current_size > total) {
+ DRM_ERROR("Invalid sequence block\n");
+ return NULL;
+ }
+
+ if (current_id == panel_id) {
+ *seq_size = current_size;
+ return data + index;
+ }
+
+ index += current_size;
+ }
+
+ DRM_ERROR("Sequence block detected but no valid configuration\n");
+
+ return NULL;
+}
+
static void
parse_mipi_sequence(struct drm_i915_private *dev_priv,
const struct bdb_header *bdb)
{
const struct bdb_mipi_sequence *sequence;
const u8 *seq_data;
+ u16 seq_size;
u8 *data;
u16 block_size;
- int i, panel_id, seq_size;
/* Only our generic panel driver uses the sequence block. */
if (dev_priv->vbt.dsi.panel_id != MIPI_DSI_GENERIC_PANEL_ID)
@@ -853,40 +890,11 @@ parse_mipi_sequence(struct drm_i915_private *dev_priv,
*/
dev_priv->vbt.dsi.seq_version = sequence->version;
- seq_data = &sequence->data[0];
-
- /*
-* sequence block is variable length and hence we need to parse and
-* get the sequence data for specific panel id
-*/
- for (i = 0; i < MAX_MIPI_CONFIGURATIONS; i++) {
- panel_id = *seq_data;
- seq_size = *((u16 *) (seq_data + 1));
- if (panel_id == panel_type)
- break;
-
- /* skip the sequence including seq header of 3 bytes */
- seq_data = seq_data + 3 + seq_size;
- if ((seq_data - &sequence->data[0]) > block_size) {
- DRM_ERROR("Sequence start is beyond sequence block
size, corrupted sequence block\n");
- return;
- }
- }
-
- if (i == MAX_MIPI_CONFIGURATIONS) {
- DRM_ERROR("Sequence block detected but no valid
configuration\n");
+ seq_data = find_panel_sequence_block(sequence, panel_type, &seq_size);
+ if (!seq_data)
return;
- }
-
- /* check if found sequence is completely within the sequence block
-* just being paranoid */
- if (seq_size > block_size) {
- DRM_ERROR("Corrupted sequence/size, bailing out\n");
- return;
- }
- /* skip the panel id(1 byte) and seq size(2 bytes) */
- dev_priv->vbt.dsi.data = kmemdup(seq_data + 3, seq_size, GFP_KERNEL);
+ dev_priv->vbt.dsi.data = kmemdup(seq_data, seq_size, GFP_KERNEL);
if (!dev_priv->vbt.dsi.data)
return;
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/15] drm/i915/bios: have get_blocksize() support MIPI sequence block v3+
Have get_blocksize() support the special case of MIPI sequence block v3+
which has a separate field for size. Provide and use abstractions for
getting the blocksize given a pointer to the block "envelope",
i.e. pointer to the block id, and given a pointer to the block payload
data.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 91540ab15e0b..7393596df37d 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -58,6 +58,22 @@
static int panel_type;
+/* Get BDB block size given a pointer to Block ID. */
+static u32 _get_blocksize(const u8 *block_base)
+{
+ /* The MIPI Sequence Block v3+ has a separate size field. */
+ if (*block_base == BDB_MIPI_SEQUENCE && *(block_base + 3) >= 3)
+ return *((const u32 *)(block_base + 4));
+ else
+ return *((const u16 *)(block_base + 1));
+}
+
+/* Get BDB block size give a pointer to data after Block ID and Block Size. */
+static u32 get_blocksize(const void *block_data)
+{
+ return _get_blocksize(block_data - 3);
+}
+
static const void *
find_section(const void *_bdb, int section_id)
{
@@ -74,14 +90,8 @@ find_section(const void *_bdb, int section_id)
/* walk the sections looking for section_id */
while (index + 3 < total) {
current_id = *(base + index);
- index++;
-
- current_size = *((const u16 *)(base + index));
- index += 2;
-
- /* The MIPI Sequence Block v3+ has a separate size field. */
- if (current_id == BDB_MIPI_SEQUENCE && *(base + index) >= 3)
- current_size = *((const u32 *)(base + index + 1));
+ current_size = _get_blocksize(base + index);
+ index += 3;
if (index + current_size > total)
return NULL;
@@ -95,16 +105,6 @@ find_section(const void *_bdb, int section_id)
return NULL;
}
-static u16
-get_blocksize(const void *p)
-{
- u16 *block_ptr, block_size;
-
- block_ptr = (u16 *)((char *)p - 2);
- block_size = *block_ptr;
- return block_size;
-}
-
static void
fill_detail_timing_data(struct drm_display_mode *panel_fixed_mode,
const struct lvds_dvo_timing *dvo_timing)
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/15] drm/i915/bios: add support for MIPI sequence block v3
The changes since the sequence block v2 are:
* The whole MIPI bios data block has a separate 32-bit size field since
v3, stored after the version. This facilitates big sequences.
* The size of the panel specific sequence blocks has grown to 32
bits. This facilitates big sequences.
* The elements within sequences now have an 8-bit size field following
the operation byte. This facilitates skipping unknown new operation
bytes, i.e. forward compatibility.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.c | 84 ++
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 9
2 files changed, 84 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.c
b/drivers/gpu/drm/i915/intel_bios.c
index 45a7a2bc96c6..f3c93bb0e3a7 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -754,21 +754,30 @@ parse_mipi_config(struct drm_i915_private *dev_priv,
/* Find the sequence block and size for the given panel. */
static const u8 *
find_panel_sequence_block(const struct bdb_mipi_sequence *sequence,
- u16 panel_id, u16 *seq_size)
+ u16 panel_id, u32 *seq_size)
{
u32 total = get_blocksize(sequence);
const u8 *data = &sequence->data[0];
u8 current_id;
- u16 current_size;
+ u32 current_size;
int index = 0;
int i;
+ /* skip new block size */
+ if (sequence->version >= 3)
+ data += 4;
+
for (i = 0; i < MAX_MIPI_CONFIGURATIONS && index + 3 < total; i++) {
current_id = *(data + index);
index++;
- current_size = *((const u16 *)(data + index));
- index += 2;
+ if (sequence->version >= 3) {
+ current_size = *((const u32 *)(data + index));
+ index += 4;
+ } else {
+ current_size = *((const u16 *)(data + index));
+ index += 2;
+ }
if (index + current_size > total) {
DRM_ERROR("Invalid sequence block\n");
@@ -826,13 +835,66 @@ static int goto_next_sequence(const u8 *data, int index,
int total)
return 0;
}
+static int goto_next_sequence_v3(const u8 *data, int index, int total)
+{
+ int seq_end;
+ u16 len;
+
+ /*
+* Could skip sequence based on Size of Sequence alone, but also do some
+* checking on the structure.
+*/
+ seq_end = index + *((const u32 *)(data + 1));
+ if (seq_end > total) {
+ DRM_ERROR("Invalid sequence size\n");
+ return 0;
+ }
+
+ /* Skip Sequence Byte and Size of Sequence. */
+ for (index = index + 5; index < total; index += len) {
+ u8 operation_byte = *(data + index);
+ index++;
+
+ if (operation_byte == MIPI_SEQ_ELEM_END) {
+ if (index != seq_end) {
+ DRM_ERROR("Invalid element structure\n");
+ return 0;
+ }
+ return index;
+ }
+
+ len = *(data + index);
+ index++;
+
+ /*
+* FIXME: Would be nice to check elements like for v1/v2 in
+* goto_next_sequence() above.
+*/
+ switch (operation_byte) {
+ case MIPI_SEQ_ELEM_SEND_PKT:
+ case MIPI_SEQ_ELEM_DELAY:
+ case MIPI_SEQ_ELEM_GPIO:
+ case MIPI_SEQ_ELEM_I2C:
+ case MIPI_SEQ_ELEM_SPI:
+ case MIPI_SEQ_ELEM_PMIC:
+ break;
+ default:
+ DRM_DEBUG_KMS("Unknown operation byte %u\n",
+ operation_byte);
+ break;
+ }
+ }
+
+ return 0;
+}
+
static void
parse_mipi_sequence(struct drm_i915_private *dev_priv,
const struct bdb_header *bdb)
{
const struct bdb_mipi_sequence *sequence;
const u8 *seq_data;
- u16 seq_size;
+ u32 seq_size;
u8 *data;
int index = 0;
@@ -847,12 +909,13 @@ parse_mipi_sequence(struct drm_i915_private *dev_priv,
}
/* Fail gracefully for forward incompatible sequence block. */
- if (sequence->version >= 3) {
- DRM_ERROR("Unable to parse MIPI Sequence Block v3+\n");
+ if (sequence->version >= 4) {
+ DRM_ERROR("Unable to parse MIPI Sequence Block v%u\n",
+ sequence->version);
return;
}
- DRM_DEBUG_DRIVER("Found MIPI sequence block\n");
+ DRM_DEBUG_DRIVER("Found MIPI sequence block v%u\n", sequence->version);
seq_data = find_panel_sequence_block(sequence, panel_type, &seq_size);
[Intel-gfx] [PATCH 08/15] drm/i915/dsi: be defensive about out of bounds operation byte
Untie the VBT based generic panel driver from the VBT parsing, so that
the two don't have to be updated in lockstep.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 45512e0df57a..ba5355506590 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -232,11 +232,9 @@ static const u8 *mipi_exec_gpio(struct intel_dsi
*intel_dsi, const u8 *data)
typedef const u8 * (*fn_mipi_elem_exec)(struct intel_dsi *intel_dsi,
const u8 *data);
static const fn_mipi_elem_exec exec_elem[] = {
- NULL, /* reserved */
- mipi_exec_send_packet,
- mipi_exec_delay,
- mipi_exec_gpio,
- NULL, /* status read; later */
+ [MIPI_SEQ_ELEM_SEND_PKT] = mipi_exec_send_packet,
+ [MIPI_SEQ_ELEM_DELAY] = mipi_exec_delay,
+ [MIPI_SEQ_ELEM_GPIO] = mipi_exec_gpio,
};
/*
@@ -264,7 +262,6 @@ static const char *sequence_name(enum mipi_seq seq_id)
static void generic_exec_sequence(struct intel_dsi *intel_dsi, const u8 *data)
{
fn_mipi_elem_exec mipi_elem_exec;
- int index;
if (!data)
return;
@@ -277,15 +274,14 @@ static void generic_exec_sequence(struct intel_dsi
*intel_dsi, const u8 *data)
/* parse each byte till we reach end of sequence byte - 0x00 */
while (1) {
- index = *data;
- mipi_elem_exec = exec_elem[index];
- if (!mipi_elem_exec) {
- DRM_ERROR("Unsupported MIPI element, skipping sequence
execution\n");
+ u8 operation_byte = *data++;
+ if (operation_byte >= ARRAY_SIZE(exec_elem) ||
+ !exec_elem[operation_byte]) {
+ DRM_ERROR("Unsupported MIPI operation byte %u\n",
+ operation_byte);
return;
}
-
- /* goto element payload */
- data++;
+ mipi_elem_exec = exec_elem[operation_byte];
/* execute the element specific rotines */
data = mipi_elem_exec(intel_dsi, data);
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/15] drm/i915/bios: fix header define name for intel_bios.h
Just for OCD.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 2dc46a98c332..21c162e01189 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -25,8 +25,8 @@
*
*/
-#ifndef _I830_BIOS_H_
-#define _I830_BIOS_H_
+#ifndef _INTEL_BIOS_H_
+#define _INTEL_BIOS_H_
/**
* struct vbt_header - VBT Header structure
@@ -983,4 +983,4 @@ enum mipi_gpio_pin_index {
MIPI_GPIO_MAX
};
-#endif /* _I830_BIOS_H_ */
+#endif /* _INTEL_BIOS_H_ */
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/15] drm/i915/bios: add defines for v3 sequence block
New sequences, new operations within sequences.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_bios.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_bios.h
b/drivers/gpu/drm/i915/intel_bios.h
index 6146f1b0cf48..350d4e0f75a4 100644
--- a/drivers/gpu/drm/i915/intel_bios.h
+++ b/drivers/gpu/drm/i915/intel_bios.h
@@ -963,6 +963,9 @@ enum mipi_seq {
MIPI_SEQ_BACKLIGHT_ON, /* sequence block v2+ */
MIPI_SEQ_BACKLIGHT_OFF, /* sequence block v2+ */
MIPI_SEQ_TEAR_ON, /* sequence block v2+ */
+ MIPI_SEQ_TEAR_OFF, /* sequence block v3+ */
+ MIPI_SEQ_POWER_ON, /* sequence block v3+ */
+ MIPI_SEQ_POWER_OFF, /* sequence block v3+ */
MIPI_SEQ_MAX
};
@@ -972,6 +975,8 @@ enum mipi_seq_element {
MIPI_SEQ_ELEM_DELAY,
MIPI_SEQ_ELEM_GPIO,
MIPI_SEQ_ELEM_I2C, /* sequence block v2+ */
+ MIPI_SEQ_ELEM_SPI, /* sequence block v3+ */
+ MIPI_SEQ_ELEM_PMIC, /* sequence block v3+ */
MIPI_SEQ_ELEM_MAX
};
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/15] drm/i915/dsi: reduce tedious repetition
Make it a bit tidier.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 62 +++---
1 file changed, 22 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 1f9c80d21904..f0116a6c14cd 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -317,18 +317,30 @@ static const char *sequence_name(enum mipi_seq seq_id)
return "(unknown)";
}
-static void generic_exec_sequence(struct intel_dsi *intel_dsi, const u8 *data)
+static void generic_exec_sequence(struct drm_panel *panel, enum mipi_seq
seq_id)
{
+ struct vbt_panel *vbt_panel = to_vbt_panel(panel);
+ struct intel_dsi *intel_dsi = vbt_panel->intel_dsi;
struct drm_i915_private *dev_priv = to_i915(intel_dsi->base.base.dev);
+ const u8 *data;
fn_mipi_elem_exec mipi_elem_exec;
- if (!data)
+ if (WARN_ON(seq_id >= ARRAY_SIZE(dev_priv->vbt.dsi.sequence)))
return;
- DRM_DEBUG_DRIVER("Starting MIPI sequence %u - %s\n",
-*data, sequence_name(*data));
+ data = dev_priv->vbt.dsi.sequence[seq_id];
+ if (!data) {
+ DRM_DEBUG_KMS("MIPI sequence %d - %s not available\n",
+ seq_id, sequence_name(seq_id));
+ return;
+ }
- /* go to the first element of the sequence */
+ WARN_ON(*data != seq_id);
+
+ DRM_DEBUG_KMS("Starting MIPI sequence %d - %s\n",
+ seq_id, sequence_name(seq_id));
+
+ /* Skip Sequence Byte. */
data++;
/* Skip Size of Sequence. */
@@ -370,59 +382,29 @@ static void generic_exec_sequence(struct intel_dsi
*intel_dsi, const u8 *data)
static int vbt_panel_prepare(struct drm_panel *panel)
{
- struct vbt_panel *vbt_panel = to_vbt_panel(panel);
- struct intel_dsi *intel_dsi = vbt_panel->intel_dsi;
- struct drm_device *dev = intel_dsi->base.base.dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- const u8 *sequence;
-
- sequence = dev_priv->vbt.dsi.sequence[MIPI_SEQ_ASSERT_RESET];
- generic_exec_sequence(intel_dsi, sequence);
-
- sequence = dev_priv->vbt.dsi.sequence[MIPI_SEQ_INIT_OTP];
- generic_exec_sequence(intel_dsi, sequence);
+ generic_exec_sequence(panel, MIPI_SEQ_ASSERT_RESET);
+ generic_exec_sequence(panel, MIPI_SEQ_INIT_OTP);
return 0;
}
static int vbt_panel_unprepare(struct drm_panel *panel)
{
- struct vbt_panel *vbt_panel = to_vbt_panel(panel);
- struct intel_dsi *intel_dsi = vbt_panel->intel_dsi;
- struct drm_device *dev = intel_dsi->base.base.dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- const u8 *sequence;
-
- sequence = dev_priv->vbt.dsi.sequence[MIPI_SEQ_DEASSERT_RESET];
- generic_exec_sequence(intel_dsi, sequence);
+ generic_exec_sequence(panel, MIPI_SEQ_DEASSERT_RESET);
return 0;
}
static int vbt_panel_enable(struct drm_panel *panel)
{
- struct vbt_panel *vbt_panel = to_vbt_panel(panel);
- struct intel_dsi *intel_dsi = vbt_panel->intel_dsi;
- struct drm_device *dev = intel_dsi->base.base.dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- const u8 *sequence;
-
- sequence = dev_priv->vbt.dsi.sequence[MIPI_SEQ_DISPLAY_ON];
- generic_exec_sequence(intel_dsi, sequence);
+ generic_exec_sequence(panel, MIPI_SEQ_DISPLAY_ON);
return 0;
}
static int vbt_panel_disable(struct drm_panel *panel)
{
- struct vbt_panel *vbt_panel = to_vbt_panel(panel);
- struct intel_dsi *intel_dsi = vbt_panel->intel_dsi;
- struct drm_device *dev = intel_dsi->base.base.dev;
- struct drm_i915_private *dev_priv = dev->dev_private;
- const u8 *sequence;
-
- sequence = dev_priv->vbt.dsi.sequence[MIPI_SEQ_DISPLAY_OFF];
- generic_exec_sequence(intel_dsi, sequence);
+ generic_exec_sequence(panel, MIPI_SEQ_DISPLAY_OFF);
return 0;
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/15] drm/i915: Adding the parsing logic for the i2c element
From: vkorjani
New sequence element for i2c is been added in the
mipi sequence block of the VBT. This patch parses
and executes the i2c sequence.
v2: Add i2c_put_adapter call(Jani), rebase
v3: corrected the retry loop(Jani), rebase
v4 by Jani:
- don't put the adapter if get fails
- print an error message if all retries exhausted
- use a for loop
- fix warnings for unused variables
Cc: Jani Nikula
Signed-off-by: vkorjani
Signed-off-by: Deepak M
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 58 ++
1 file changed, 58 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index ba5355506590..8fcfb0f63dc1 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include "i915_drv.h"
@@ -104,6 +105,62 @@ static struct gpio_table gtable[] = {
{ GPIO_NC_11_PCONF0, GPIO_NC_11_PAD, 0}
};
+static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data)
+{
+ struct i2c_adapter *adapter;
+ int ret, i;
+ u8 reg_offset, payload_size;
+ struct i2c_msg msg;
+ u8 *transmit_buffer;
+ u8 flag, bus_number;
+ u16 slave_add;
+
+ flag = *data++;
+ data++; /* index, unused */
+ bus_number = *data++;
+ slave_add = *(u16 *)(data);
+ data += 2;
+ reg_offset = *data++;
+ payload_size = *data++;
+
+ adapter = i2c_get_adapter(bus_number);
+ if (!adapter) {
+ DRM_ERROR("i2c_get_adapter(%u)\n", bus_number);
+ goto out;
+ }
+
+ transmit_buffer = kmalloc(1 + payload_size, GFP_TEMPORARY);
+ if (!transmit_buffer)
+ goto out_put;
+
+ transmit_buffer[0] = reg_offset;
+ memcpy(&transmit_buffer[1], data, payload_size);
+
+ msg.addr = slave_add;
+ msg.flags = 0;
+ msg.len = payload_size + 1;
+ msg.buf = &transmit_buffer[0];
+
+ for (i = 0; i < 6; i++) {
+ ret = i2c_transfer(adapter, &msg, 1);
+ if (ret == 1) {
+ goto out_free;
+ } else if (ret == -EAGAIN) {
+ usleep_range(1000, 2500);
+ } else {
+ break;
+ }
+ }
+
+ DRM_ERROR("i2c transfer failed: %d\n", ret);
+out_free:
+ kfree(transmit_buffer);
+out_put:
+ i2c_put_adapter(adapter);
+out:
+ return data + payload_size;
+}
+
static inline enum port intel_dsi_seq_port_to_port(u8 port)
{
return port ? PORT_C : PORT_A;
@@ -235,6 +292,7 @@ static const fn_mipi_elem_exec exec_elem[] = {
[MIPI_SEQ_ELEM_SEND_PKT] = mipi_exec_send_packet,
[MIPI_SEQ_ELEM_DELAY] = mipi_exec_delay,
[MIPI_SEQ_ELEM_GPIO] = mipi_exec_gpio,
+ [MIPI_SEQ_ELEM_I2C] = mipi_exec_i2c,
};
/*
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ warning: Fi.CI.BAT
== Summary == Built on ac2305b6c91b9a84cc12566016ece257c3ebcba3 drm-intel-nightly: 2015y-12m-17d-16h-19m-23s UTC integration manifest Test kms_flip: Subgroup basic-flip-vs-modeset: dmesg-warn -> PASS (bsw-nuc-2) pass -> DMESG-WARN (hsw-brixbox) Subgroup basic-flip-vs-wf_vblank: pass -> DMESG-WARN (bsw-nuc-2) dmesg-fail -> DMESG-WARN (skl-i7k-2) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-a-frame-sequence: dmesg-warn -> PASS (byt-nuc) Subgroup read-crc-pipe-b: dmesg-warn -> PASS (snb-dellxps) Subgroup read-crc-pipe-c-frame-sequence: dmesg-warn -> PASS (bsw-nuc-2) Test kms_setmode: Subgroup basic-clone-single-crtc: pass -> DMESG-WARN (snb-dellxps) bsw-nuc-2total:135 pass:114 dwarn:1 dfail:0 fail:0 skip:20 byt-nuc total:135 pass:120 dwarn:2 dfail:0 fail:0 skip:13 hsw-brixbox total:135 pass:126 dwarn:2 dfail:0 fail:0 skip:7 hsw-gt2 total:135 pass:130 dwarn:1 dfail:0 fail:0 skip:4 ilk-hp8440p total:135 pass:100 dwarn:0 dfail:0 fail:2 skip:33 ivb-t430stotal:135 pass:128 dwarn:1 dfail:1 fail:1 skip:4 skl-i5k-2total:135 pass:122 dwarn:5 dfail:0 fail:0 skip:8 skl-i7k-2total:135 pass:122 dwarn:5 dfail:0 fail:0 skip:8 snb-dellxps total:135 pass:121 dwarn:2 dfail:0 fail:0 skip:12 snb-x220ttotal:135 pass:121 dwarn:2 dfail:0 fail:1 skip:11 Results at /archive/results/CI_IGT_test/Patchwork_707/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ warning: Fi.CI.BAT
== Summary == Built on e858593f63757a993fa56f282cb1493c57810a20 drm-intel-nightly: 2015y-12m-21d-12h-06m-20s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (skl-i5k-2) pass -> DMESG-WARN (skl-i7k-2) Test kms_flip: Subgroup basic-flip-vs-modeset: dmesg-warn -> PASS (skl-i5k-2) pass -> DMESG-WARN (hsw-brixbox) Subgroup basic-flip-vs-wf_vblank: dmesg-warn -> PASS (snb-x220t) dmesg-warn -> PASS (byt-nuc) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> DMESG-WARN (snb-x220t) Subgroup read-crc-pipe-b: pass -> DMESG-WARN (skl-i5k-2) dmesg-warn -> PASS (snb-dellxps) Subgroup read-crc-pipe-b-frame-sequence: dmesg-warn -> PASS (hsw-xps12) pass -> DMESG-WARN (bdw-ultra) Test pm_rpm: Subgroup basic-rte: dmesg-warn -> PASS (bdw-ultra) bdw-nuci7total:132 pass:122 dwarn:1 dfail:0 fail:0 skip:9 bdw-ultratotal:132 pass:124 dwarn:2 dfail:0 fail:0 skip:6 bsw-nuc-2total:135 pass:113 dwarn:2 dfail:0 fail:0 skip:20 byt-nuc total:135 pass:121 dwarn:1 dfail:0 fail:0 skip:13 hsw-brixbox total:135 pass:126 dwarn:2 dfail:0 fail:0 skip:7 hsw-gt2 total:135 pass:130 dwarn:1 dfail:0 fail:0 skip:4 hsw-xps12total:132 pass:126 dwarn:2 dfail:0 fail:0 skip:4 ilk-hp8440p total:135 pass:99 dwarn:1 dfail:0 fail:0 skip:35 ivb-t430stotal:135 pass:127 dwarn:2 dfail:0 fail:0 skip:6 skl-i5k-2total:135 pass:122 dwarn:5 dfail:0 fail:0 skip:8 skl-i7k-2total:135 pass:122 dwarn:5 dfail:0 fail:0 skip:8 snb-dellxps total:135 pass:122 dwarn:1 dfail:0 fail:0 skip:12 snb-x220ttotal:135 pass:122 dwarn:1 dfail:0 fail:1 skip:11 Results at /archive/results/CI_IGT_test/Patchwork_775/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ warning: Fi.CI.BAT
== Summary == Built on e858593f63757a993fa56f282cb1493c57810a20 drm-intel-nightly: 2015y-12m-21d-12h-06m-20s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (skl-i5k-2) pass -> DMESG-WARN (skl-i7k-2) Test kms_flip: Subgroup basic-flip-vs-modeset: dmesg-warn -> PASS (skl-i5k-2) pass -> DMESG-WARN (hsw-brixbox) Subgroup basic-flip-vs-wf_vblank: dmesg-warn -> PASS (snb-x220t) dmesg-warn -> PASS (byt-nuc) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: pass -> DMESG-WARN (snb-x220t) Subgroup read-crc-pipe-b: pass -> DMESG-WARN (skl-i5k-2) dmesg-warn -> PASS (snb-dellxps) Subgroup read-crc-pipe-b-frame-sequence: dmesg-warn -> PASS (hsw-xps12) pass -> DMESG-WARN (bdw-ultra) Test pm_rpm: Subgroup basic-rte: dmesg-warn -> PASS (bdw-ultra) bdw-nuci7total:132 pass:122 dwarn:1 dfail:0 fail:0 skip:9 bdw-ultratotal:132 pass:124 dwarn:2 dfail:0 fail:0 skip:6 bsw-nuc-2total:135 pass:113 dwarn:2 dfail:0 fail:0 skip:20 byt-nuc total:135 pass:121 dwarn:1 dfail:0 fail:0 skip:13 hsw-brixbox total:135 pass:126 dwarn:2 dfail:0 fail:0 skip:7 hsw-gt2 total:135 pass:130 dwarn:1 dfail:0 fail:0 skip:4 hsw-xps12total:132 pass:126 dwarn:2 dfail:0 fail:0 skip:4 ilk-hp8440p total:135 pass:99 dwarn:1 dfail:0 fail:0 skip:35 ivb-t430stotal:135 pass:127 dwarn:2 dfail:0 fail:0 skip:6 skl-i5k-2total:135 pass:122 dwarn:5 dfail:0 fail:0 skip:8 skl-i7k-2total:135 pass:122 dwarn:5 dfail:0 fail:0 skip:8 snb-dellxps total:135 pass:122 dwarn:1 dfail:0 fail:0 skip:12 snb-x220ttotal:135 pass:122 dwarn:1 dfail:0 fail:1 skip:11 Results at /archive/results/CI_IGT_test/Patchwork_775/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/12] drm/i915: Keep track of the cdclk as if all crtc's were active.
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> On skylake when calculating plane visibility with the crtc in
> dpms off mode the real cdclk may be different from what it would be
> if the crtc was active. This may result in a WARN_ON(cdclk < crtc_clock)
> from skl_max_scale. The fix is to keep a atomic_cdclk that would be true
> if all crtc's were active.
>
> This is required to get the same calculations done correctly regardless
> of dpms mode.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_display.c | 55
>
> drivers/gpu/drm/i915/intel_drv.h | 6
> 3 files changed, 44 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 3caecf896f17..f3ad72abeea7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1776,7 +1776,7 @@ struct drm_i915_private {
>
> unsigned int fsb_freq, mem_freq, is_ddr3;
> unsigned int skl_boot_cdclk;
> - unsigned int cdclk_freq, max_cdclk_freq;
> + unsigned int cdclk_freq, max_cdclk_freq, atomic_cdclk_freq;
> unsigned int max_dotclk_freq;
> unsigned int hpll_freq;
> unsigned int czclk_freq;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 7f69f98d8b23..b2bf92a3b701 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5312,6 +5312,7 @@ static void modeset_put_power_domains(struct
> drm_i915_private *dev_priv,
>
> static void modeset_update_crtc_power_domains(struct drm_atomic_state *state)
> {
> + struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> struct drm_device *dev = state->dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> unsigned long put_domains[I915_MAX_PIPES] = {};
> @@ -5325,13 +5326,9 @@ static void modeset_update_crtc_power_domains(struct
> drm_atomic_state *state)
> modeset_get_crtc_power_domains(crtc);
> }
>
> - if (dev_priv->display.modeset_commit_cdclk) {
> - unsigned int cdclk = to_intel_atomic_state(state)->cdclk;
> -
> - if (cdclk != dev_priv->cdclk_freq &&
> - !WARN_ON(!state->allow_modeset))
> - dev_priv->display.modeset_commit_cdclk(state);
> - }
> + if (dev_priv->display.modeset_commit_cdclk &&
> + intel_state->dev_cdclk != dev_priv->cdclk_freq)
> + dev_priv->display.modeset_commit_cdclk(state);
>
> for (i = 0; i < I915_MAX_PIPES; i++)
> if (put_domains[i])
> @@ -6039,13 +6036,18 @@ static int valleyview_modeset_calc_cdclk(struct
> drm_atomic_state *state)
> struct drm_device *dev = state->dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> int max_pixclk = intel_mode_max_pixclk(dev, state);
> + struct intel_atomic_state *intel_state =
> + to_intel_atomic_state(state);
>
> if (max_pixclk < 0)
> return max_pixclk;
>
> - to_intel_atomic_state(state)->cdclk =
> + intel_state->cdclk = intel_state->dev_cdclk =
> valleyview_calc_cdclk(dev_priv, max_pixclk);
>
> + if (!intel_state->active_crtcs)
> + intel_state->dev_cdclk = valleyview_calc_cdclk(dev_priv, 0);
> +
> return 0;
> }
>
> @@ -6054,13 +6056,18 @@ static int broxton_modeset_calc_cdclk(struct
> drm_atomic_state *state)
> struct drm_device *dev = state->dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> int max_pixclk = intel_mode_max_pixclk(dev, state);
> + struct intel_atomic_state *intel_state =
> + to_intel_atomic_state(state);
>
> if (max_pixclk < 0)
> return max_pixclk;
>
> - to_intel_atomic_state(state)->cdclk =
> + intel_state->cdclk = intel_state->dev_cdclk =
> broxton_calc_cdclk(dev_priv, max_pixclk);
>
> + if (!intel_state->active_crtcs)
> + intel_state->dev_cdclk = broxton_calc_cdclk(dev_priv, 0);
> +
> return 0;
> }
>
> @@ -6103,8 +6110,10 @@ static void vlv_program_pfi_credits(struct
> drm_i915_private *dev_priv)
> static void valleyview_modeset_commit_cdclk(struct drm_atomic_state
> *old_state)
> {
> struct drm_device *dev = old_state->dev;
> - unsigned int req_cdclk = to_intel_atomic_state(old_state)->cdclk;
> struct drm_i915_private *dev_priv = dev->dev_private;
> + struct intel_atomic_state *old_intel_state =
> + to_intel_atomic_state(old_state);
> + unsigned req_cdclk = old_intel_state->dev_cdclk;
>
> /*
>* FIXME: We can end up here with all power domains off, yet
> @@ -9574,7 +9583,9 @@ void hsw_disable_pc8(struct drm_i915_private *dev_priv)
> static void broxton_modeset_commit_cdclk
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Compile time concatenate WARN_ON macro strings
On Fri, Dec 18, 2015 at 02:11:24PM +0200, Joonas Lahtinen wrote:
> On pe, 2015-12-18 at 12:03 +, Dave Gordon wrote:
> > On 18/12/15 10:39, Joonas Lahtinen wrote:
> > > Using __stringify(x) instead of #x adds support for macros as
> > > a parameter and reduces runtime overhead.
> > >
> > > Slightly increases the .text size but should not matter.
> > >
> > > v2:
> > > - Define I915_STATE_WARN_ON though I915_STATE_WARN
> > >(Bikeshed inspiration by Chris)
> > >
> > > Cc: Rob Clark
> > > Cc: Chris Wilson
> > > Acked-by: Daniel Vetter
> > > Signed-off-by: Joonas Lahtinen
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 14 --
> > > 1 file changed, 4 insertions(+), 10 deletions(-)
> > >
> > >
>
>
>
> > >
> > > \
> > > -})
> > > +#define I915_STATE_WARN_ON(x)
> > > \
> > > + I915_STATE_WARN((x), "WARN_ON(" __stringify(x) ")")
> > >
> > > static inline const char *yesno(bool v)
> > > {
> >
> > NAK.
> >
> > This will give compile-time warnings for lines such as:
> >
> > WARN_ON(x%16 != 0);
> >
> > because the stringified text of the expression (which in this case
> > contains a "%" character) would appear as part of the format string,
> > rather than inside an argument. See:
> >
> > 4eee492 drm/i915: fix driver's versions of WARN_ON & WARN_ON_ONCE
> >
>
> Great catch, I'll change it to have preceding "%s". Did not get any
> compile-time warning though, this would be something caught by a
> (rather advanced?) static analysis.
New gcc seems to complain about this. At least since a few weeks I've seen
a few patches for kernel-wide changes to address this float about.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/12] drm/i915: Calculate visibility in check_plane correctly regardless of dpms.
Ander had a comment s/During//
Other than this is
On Thu, 2015-11-19 at 16:07 +0100, Maarten Lankhorst wrote:
> When the crtc is configured but not active we currently clip to (0,0)x(0,0).
> This results in differences in calculations depending on dpms setting.
> When the crtc is enabled but not active run check_plane as if it were on,
> but afterwards set plane_state->visible = false for the checks.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/intel_atomic_plane.c | 4 ++--
> drivers/gpu/drm/i915/intel_display.c | 9 +++--
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index a5a336863109..e0b851a0004a 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -152,9 +152,9 @@ static int intel_plane_atomic_check(struct drm_plane
> *plane,
> intel_state->clip.x1 = 0;
> intel_state->clip.y1 = 0;
> intel_state->clip.x2 =
> - crtc_state->base.active ? crtc_state->pipe_src_w : 0;
> + crtc_state->base.enable ? crtc_state->pipe_src_w : 0;
> intel_state->clip.y2 =
> - crtc_state->base.active ? crtc_state->pipe_src_h : 0;
> + crtc_state->base.enable ? crtc_state->pipe_src_h : 0;
>
> if (state->fb && intel_rotation_90_or_270(state->rotation)) {
> if (!(state->fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index b2bf92a3b701..9db322182b15 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11738,8 +11738,13 @@ int intel_plane_atomic_calc_changes(struct
> drm_crtc_state *crtc_state,
> if (!was_crtc_enabled && WARN_ON(was_visible))
> was_visible = false;
>
> - if (!is_crtc_enabled && WARN_ON(visible))
> - visible = false;
> + /*
> + * During visibility is calculated as if the crtc was on,
> + * but after scaler setup everything depends on it being off
> + * when the crtc isn't active.
> + */
> + if (!is_crtc_enabled)
> + to_intel_plane_state(plane_state)->visible = visible = false;
>
> if (!was_visible && !visible)
> return 0;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ warning: Fi.CI.BAT
== Summary == Built on e858593f63757a993fa56f282cb1493c57810a20 drm-intel-nightly: 2015y-12m-21d-12h-06m-20s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (skl-i5k-2) pass -> DMESG-WARN (skl-i7k-2) Test kms_flip: Subgroup basic-flip-vs-dpms: dmesg-warn -> PASS (ilk-hp8440p) Subgroup basic-flip-vs-modeset: dmesg-warn -> PASS (skl-i5k-2) dmesg-warn -> PASS (bsw-nuc-2) pass -> DMESG-WARN (hsw-xps12) pass -> DMESG-WARN (hsw-gt2) pass -> DMESG-WARN (byt-nuc) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-a: pass -> DMESG-WARN (snb-x220t) Subgroup read-crc-pipe-b: dmesg-warn -> PASS (snb-dellxps) Subgroup read-crc-pipe-b-frame-sequence: dmesg-warn -> PASS (hsw-xps12) Test kms_setmode: Subgroup basic-clone-single-crtc: pass -> DMESG-WARN (snb-dellxps) Test pm_rpm: Subgroup basic-pci-d3-state: pass -> DMESG-WARN (bdw-ultra) Subgroup basic-rte: dmesg-warn -> PASS (bdw-ultra) bdw-nuci7total:132 pass:122 dwarn:1 dfail:0 fail:0 skip:9 bdw-ultratotal:132 pass:124 dwarn:2 dfail:0 fail:0 skip:6 bsw-nuc-2total:135 pass:114 dwarn:1 dfail:0 fail:0 skip:20 byt-nuc total:135 pass:119 dwarn:3 dfail:0 fail:0 skip:13 hsw-brixbox total:135 pass:127 dwarn:1 dfail:0 fail:0 skip:7 hsw-gt2 total:135 pass:129 dwarn:2 dfail:0 fail:0 skip:4 hsw-xps12total:132 pass:125 dwarn:3 dfail:0 fail:0 skip:4 ilk-hp8440p total:135 pass:100 dwarn:0 dfail:0 fail:0 skip:35 ivb-t430stotal:135 pass:127 dwarn:2 dfail:0 fail:0 skip:6 skl-i5k-2total:135 pass:123 dwarn:4 dfail:0 fail:0 skip:8 skl-i7k-2total:135 pass:122 dwarn:5 dfail:0 fail:0 skip:8 snb-dellxps total:135 pass:121 dwarn:2 dfail:0 fail:0 skip:12 snb-x220ttotal:135 pass:121 dwarn:2 dfail:0 fail:1 skip:11 Results at /archive/results/CI_IGT_test/Patchwork_776/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Reorder i915_params struct.
On Fri, Dec 18, 2015 at 01:08:16PM +0200, Joonas Lahtinen wrote:
> Move all the bool variables to the end as per the comment.
>
> Reviewed-by: Chris Wilson
> Signed-off-by: Joonas Lahtinen
Merged the first 2 patches from this series, thanks.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_params.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_params.h
> b/drivers/gpu/drm/i915/i915_params.h
> index 353951c..5299290 100644
> --- a/drivers/gpu/drm/i915/i915_params.h
> +++ b/drivers/gpu/drm/i915/i915_params.h
> @@ -45,6 +45,10 @@ struct i915_params {
> int enable_ips;
> int invert_brightness;
> int enable_cmd_parser;
> + int guc_log_level;
> + int use_mmio_flip;
> + int mmio_debug;
> + int edp_vswing;
> /* leave bools at the end to not create holes */
> bool enable_hangcheck;
> bool fastboot;
> @@ -54,12 +58,8 @@ struct i915_params {
> bool disable_display;
> bool disable_vtd_wa;
> bool enable_guc_submission;
> - int guc_log_level;
> - int use_mmio_flip;
> - int mmio_debug;
> bool verbose_state_checks;
> bool nuclear_pageflip;
> - int edp_vswing;
> };
>
> extern struct i915_params i915 __read_mostly;
> --
> 2.4.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Simplify _STATE_ debug macros
On Mon, Dec 21, 2015 at 11:53:52AM +, Dave Gordon wrote:
> On 21/12/15 08:11, Joonas Lahtinen wrote:
> >On pe, 2015-12-18 at 16:18 +, Dave Gordon wrote:
> >>On 18/12/15 12:27, Joonas Lahtinen wrote:
> >>>Take advantage of WARN return value to simplify the flow.
> >>>
> >>>Cc: Rob Clark
> >>>Reviewed-by: Chris Wilson
> >>>Reported-by: Chris Wilson
> >>>Signed-off-by: Joonas Lahtinen
> >>>---
> >>> drivers/gpu/drm/i915/i915_drv.h | 15 +--
> >>> 1 file changed, 5 insertions(+), 10 deletions(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/i915_drv.h
> >>>b/drivers/gpu/drm/i915/i915_drv.h
> >>>index 1d28d90..5a5a3e0 100644
> >>>--- a/drivers/gpu/drm/i915/i915_drv.h
> >>>+++ b/drivers/gpu/drm/i915/i915_drv.h
> >>>@@ -87,23 +87,18 @@
> >>>*/
> >>> #define I915_STATE_WARN(condition, format...) ({
> >>>\
> >>> int __ret_warn_on = !!(condition);
> >>> \
> >>>- if (unlikely(__ret_warn_on)) {
> >>> \
> >>>- if (i915.verbose_state_checks)
> >>> \
> >>>- WARN(1, format);
> >>>\
> >>>- else
> >>> \
> >>>+ if (unlikely(__ret_warn_on))
> >>> \
> >>>+ if (!WARN(i915.verbose_state_checks, format))
> >>> \
> >>> DRM_ERROR(format);
> >>> \
> >>>- }
> >>>\
> >>> unlikely(__ret_warn_on);
> >>>\
> >>> })
> >>>
> >>> #define I915_STATE_WARN_ON(condition) ({
> >>>\
> >>> int __ret_warn_on = !!(condition);
> >>> \
> >>>- if (unlikely(__ret_warn_on)) {
> >>> \
> >>>- if (i915.verbose_state_checks)
> >>> \
> >>>- WARN(1, "WARN_ON(" #condition ")\n");
> >>> \
> >>>- else
> >>> \
> >>>+ if (unlikely(__ret_warn_on))
> >>> \
> >>>+ if (!WARN(i915.verbose_state_checks,
> >>> \
> >>>+"WARN_ON(" #condition ")\n"))
> >>> \
> >>> DRM_ERROR("WARN_ON(" #condition ")\n");
> >>> \
> >>
> >>These last two lines still have the text of the condition as part of
> >>a
> >>format string :(
> >>
> >>For compile-testing, you might want to change:
> >>
> >>static void lpt_bend_clkout_dp(struct drm_i915_private *dev_priv
> >>...
> >> if (WARN_ON(steps % 5 != 0))
> >>return;
> >>
> >>to use I915_STATE_WARN_ON() instead of WARN_ON, then you should get a
> >>compile-time warning if the '%' ends up in the format string.
> >>
> >
> >This is just a patch to convert the old macros to different order
> >before changing them. The way of constructing the strings is intact.
> >
> >Regards, Joonas
>
> Yes, I agree, you didn't break them -- they were already wrong!
Yeah I think it makes sense to fix that. I'll wait for v4.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ failure: Fi.CI.BAT
On Fri, Dec 18, 2015 at 03:01:16PM -, Patchwork wrote: > == Summary == > > HEAD is now at da33ddb drm-intel-nightly: 2015y-12m-18d-13h-53m-06s UTC > integration manifest > Applying: drm/i915: Extend LRC pinning to cover GPU context writeback > Repository lacks necessary blobs to fall back on 3-way merge. > Cannot fall back to three-way merge. > Patch failed at 0001 drm/i915: Extend LRC pinning to cover GPU context > writeback Dependent patches should be submitted as an entire series. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Workaround CHV pipe C cursor fail
On Fri, Dec 18, 2015 at 07:24:39PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Turns out CHV pipe C was glued on somewhat poorly, and there's something
> wrong with the cursor. If the cursor straddles the left screen edge,
> and is then moved away from the edge or disabled, the pipe will often
> underrun. If enough underruns are triggered quickly enough the pipe
> will fall over and die (it just scans out a solid color and reports
> a constant underrun). We need to turn the disp2d power well off and
> on again to recover the pipe.
>
> None of that is very nice for the user, so let's just refuse to place
> the cursor in the compromised position. The ddx appears to fall back
> to swcursor when the ioctl returns an error, so theoretically there's
> no loss of functionality for the user (discounting swcursor bugs).
> I suppose most cursors images actually have the hotspot not exactly
> at 0,0 so under typical conditions the fallback will in fact kick in
> as soon as the cursor touches the left edge of the screen.
>
> Any atomic compositor should anyway be prepared to fall back to
> GPU composition when things don't work out, so there should be no
> problem with those.
>
> Other things that I tried to solve this include flipping all
> display related clock gating knobs I could find, increasing the
> minimum gtt alignment all the way up to 512k. I also tried to see
> if there are more specific screen coordinates that hit the bug, but
> the findings were somewhat inconclusive. Sometimes the failures
> happen almost across the whole left edge, sometimes more at the very
> top and around the bottom half. I wasn't able to find any real pattern
> to these variations, so it seems our only choice is to just refuse
> to straddle the left screen edge at all.
>
> Cc: sta...@vger.kernel.org
> Cc: Jason Plum
> Testcase: igt/kms_chv_cursor_fail
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92826
> Signed-off-by: Ville Syrjälä
Well can't really review with Bspec and I don't expect we can get
confirmation from hw engineers. But does what it says in the commit
message.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index abd2d2944022..8acc66b95139 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14059,6 +14059,7 @@ intel_check_cursor_plane(struct drm_plane *plane,
> struct drm_crtc *crtc = crtc_state->base.crtc;
> struct drm_framebuffer *fb = state->base.fb;
> struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> + enum pipe pipe = to_intel_plane(plane)->pipe;
> unsigned stride;
> int ret;
>
> @@ -14092,6 +14093,22 @@ intel_check_cursor_plane(struct drm_plane *plane,
> return -EINVAL;
> }
>
> + /*
> + * There's something wrong with the cursor on CHV pipe C.
> + * If it straddles the left edge of the screen then
> + * moving it away from the edge or disabling it often
> + * results in a pipe underrun, and often that can lead to
> + * dead pipe (constant underrun reported, and it scans
> + * out just a solid color). To recover from that, the
> + * display power well must be turned off and on again.
> + * Refuse the put the cursor into that compromised position.
> + */
> + if (IS_CHERRYVIEW(plane->dev) && pipe == PIPE_C &&
> + state->visible && state->base.crtc_x < 0) {
> + DRM_DEBUG_KMS("CHV cursor C not allowed to straddle the left
> screen edge\n");
> + return -EINVAL;
> + }
> +
> return 0;
> }
>
> --
> 2.4.10
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Workaround CHV pipe C cursor fail
On Mon, Dec 21, 2015 at 02:49:18PM +0100, Daniel Vetter wrote:
> On Fri, Dec 18, 2015 at 07:24:39PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Turns out CHV pipe C was glued on somewhat poorly, and there's something
> > wrong with the cursor. If the cursor straddles the left screen edge,
> > and is then moved away from the edge or disabled, the pipe will often
> > underrun. If enough underruns are triggered quickly enough the pipe
> > will fall over and die (it just scans out a solid color and reports
> > a constant underrun). We need to turn the disp2d power well off and
> > on again to recover the pipe.
> >
> > None of that is very nice for the user, so let's just refuse to place
> > the cursor in the compromised position. The ddx appears to fall back
> > to swcursor when the ioctl returns an error, so theoretically there's
> > no loss of functionality for the user (discounting swcursor bugs).
> > I suppose most cursors images actually have the hotspot not exactly
> > at 0,0 so under typical conditions the fallback will in fact kick in
> > as soon as the cursor touches the left edge of the screen.
> >
> > Any atomic compositor should anyway be prepared to fall back to
> > GPU composition when things don't work out, so there should be no
> > problem with those.
> >
> > Other things that I tried to solve this include flipping all
> > display related clock gating knobs I could find, increasing the
> > minimum gtt alignment all the way up to 512k. I also tried to see
> > if there are more specific screen coordinates that hit the bug, but
> > the findings were somewhat inconclusive. Sometimes the failures
> > happen almost across the whole left edge, sometimes more at the very
> > top and around the bottom half. I wasn't able to find any real pattern
> > to these variations, so it seems our only choice is to just refuse
> > to straddle the left screen edge at all.
> >
> > Cc: sta...@vger.kernel.org
> > Cc: Jason Plum
> > Testcase: igt/kms_chv_cursor_fail
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92826
> > Signed-off-by: Ville Syrjälä
>
> Well can't really review with Bspec and I don't expect we can get
> confirmation from hw engineers. But does what it says in the commit
> message.
>
> Reviewed-by: Daniel Vetter
And applied to dinq since that's our new flow even for fixes.
-Daniel
>
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 17 +
> > 1 file changed, 17 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index abd2d2944022..8acc66b95139 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -14059,6 +14059,7 @@ intel_check_cursor_plane(struct drm_plane *plane,
> > struct drm_crtc *crtc = crtc_state->base.crtc;
> > struct drm_framebuffer *fb = state->base.fb;
> > struct drm_i915_gem_object *obj = intel_fb_obj(fb);
> > + enum pipe pipe = to_intel_plane(plane)->pipe;
> > unsigned stride;
> > int ret;
> >
> > @@ -14092,6 +14093,22 @@ intel_check_cursor_plane(struct drm_plane *plane,
> > return -EINVAL;
> > }
> >
> > + /*
> > +* There's something wrong with the cursor on CHV pipe C.
> > +* If it straddles the left edge of the screen then
> > +* moving it away from the edge or disabling it often
> > +* results in a pipe underrun, and often that can lead to
> > +* dead pipe (constant underrun reported, and it scans
> > +* out just a solid color). To recover from that, the
> > +* display power well must be turned off and on again.
> > +* Refuse the put the cursor into that compromised position.
> > +*/
> > + if (IS_CHERRYVIEW(plane->dev) && pipe == PIPE_C &&
> > + state->visible && state->base.crtc_x < 0) {
> > + DRM_DEBUG_KMS("CHV cursor C not allowed to straddle the left
> > screen edge\n");
> > + return -EINVAL;
> > + }
> > +
> > return 0;
> > }
> >
> > --
> > 2.4.10
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/13] staging/android/sync: Move sync framework out of staging
On 21/12/2015 10:03, Daniel Vetter wrote: On Thu, Dec 17, 2015 at 09:35:03AM -0800, Jesse Barnes wrote: On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote: From: John Harrison The sync framework is now used by the i915 driver. Therefore it can be moved out of staging and into the regular tree. Also, the public interfaces can actually be made public and exported. v3: New patch for series. Signed-off-by: John Harrison Signed-off-by: Geoff Miller --- drivers/android/Kconfig| 28 ++ drivers/android/Makefile | 2 + drivers/android/sw_sync.c | 260 drivers/android/sw_sync.h | 59 +++ drivers/android/sync.c | 734 + drivers/android/sync.h | 366 drivers/android/sync_debug.c | 256 drivers/android/trace/sync.h | 82 drivers/staging/android/Kconfig| 28 -- drivers/staging/android/Makefile | 2 - drivers/staging/android/sw_sync.c | 260 drivers/staging/android/sw_sync.h | 59 --- drivers/staging/android/sync.c | 734 - drivers/staging/android/sync.h | 366 drivers/staging/android/sync_debug.c | 256 drivers/staging/android/trace/sync.h | 82 drivers/staging/android/uapi/sw_sync.h | 32 -- drivers/staging/android/uapi/sync.h| 97 - include/uapi/Kbuild| 1 + include/uapi/sync/Kbuild | 3 + include/uapi/sync/sw_sync.h| 32 ++ include/uapi/sync/sync.h | 97 + 22 files changed, 1920 insertions(+), 1916 deletions(-) create mode 100644 drivers/android/sw_sync.c create mode 100644 drivers/android/sw_sync.h create mode 100644 drivers/android/sync.c create mode 100644 drivers/android/sync.h create mode 100644 drivers/android/sync_debug.c create mode 100644 drivers/android/trace/sync.h delete mode 100644 drivers/staging/android/sw_sync.c delete mode 100644 drivers/staging/android/sw_sync.h delete mode 100644 drivers/staging/android/sync.c delete mode 100644 drivers/staging/android/sync.h delete mode 100644 drivers/staging/android/sync_debug.c delete mode 100644 drivers/staging/android/trace/sync.h delete mode 100644 drivers/staging/android/uapi/sw_sync.h delete mode 100644 drivers/staging/android/uapi/sync.h create mode 100644 include/uapi/sync/Kbuild create mode 100644 include/uapi/sync/sw_sync.h create mode 100644 include/uapi/sync/sync.h diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig index bdfc6c6..9edcd8f 100644 --- a/drivers/android/Kconfig +++ b/drivers/android/Kconfig @@ -32,6 +32,34 @@ config ANDROID_BINDER_IPC_32BIT Note that enabling this will break newer Android user-space. +config SYNC + bool "Synchronization framework" + default n + select ANON_INODES + select DMA_SHARED_BUFFER + ---help--- + This option enables the framework for synchronization between multiple + drivers. Sync implementations can take advantage of hardware + synchronization built into devices like GPUs. + +config SW_SYNC + bool "Software synchronization objects" + default n + depends on SYNC + ---help--- + A sync object driver that uses a 32bit counter to coordinate + synchronization. Useful when there is no hardware primitive backing + the synchronization. + +config SW_SYNC_USER + bool "Userspace API for SW_SYNC" + default n + depends on SW_SYNC + ---help--- + Provides a user space API to the sw sync object. + *WARNING* improper use of this can result in deadlocking kernel + drivers from userspace. + endif # if ANDROID IIRC we wanted to drop the user ABI altogether? I think we can de-stage this even before we push the new ABI on the i915 side to expose the sync points (since we'll need an open source userspace for that), and any changes/cleanups can happen outside of staging. Just a head-up: Gustavo Padovan from Collabora is working to de-stage all the syncpt stuff. Greg KH merged the TODO update for that work for 4.5, which covers consensus (including ack from Google's Greg Hackmann on the plan). Given that I think it'd be best to freeload on that effort. But that means we need to push all the android/syncpt stuff down in the series. I hope that works, and there's no functional depencies in the fence conversion/scheduler core? Thanks, Daniel Do you have any idea on the timescale for their destaging? Is it definitely, definitely happening or still just a 'some point in the future it would be nice to...'? The Android driver certainly needs it and I believe Jesse's bufferless work will require it too. So sooner is greatly preferable to later. As long as the reset of the fence conversion sti
[Intel-gfx] [i-g-t PATCH 1/5] intel_opregion_decode: add new ASLE fields
Signed-off-by: Jani Nikula
---
tools/intel_opregion_decode.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/intel_opregion_decode.c b/tools/intel_opregion_decode.c
index b19566108ed7..c65828ae2900 100644
--- a/tools/intel_opregion_decode.c
+++ b/tools/intel_opregion_decode.c
@@ -122,7 +122,9 @@ struct opregion_asle {
uint8_t fdss[8];
uint32_t fdsp;
uint32_t stat;
- uint8_t rsvd[86];
+ uint64_t rvda; /* Physical address of raw vbt data */
+ uint32_t rvds; /* Size of raw vbt data */
+ uint8_t rsvd[58];
} __attribute__((packed));
/* OpRegion mailbox #4: VBT */
@@ -308,6 +310,8 @@ static void decode_asle(const void *buffer)
printf("\tfdsp:\t0x%08x\n", asle->fdsp);
printf("\tstat:\t0x%08x\n", asle->stat);
+ printf("\trvda:\t0x%016lx\n", asle->rvda);
+ printf("\trvds:\t0x%08x\n", asle->rvds);
printf("\n");
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH 5/5] intel_bios_reader: add dumping of i2c element in mipi sequence
Due to the clever way the whole sequence block is specified without
forward compatibility, it's not possible to dump most blocks without
this.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 7c3e1bcaa387..b31f648f0607 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -894,12 +894,35 @@ static const uint8_t *mipi_dump_gpio(const uint8_t *data)
return data;
}
+static const uint8_t *mipi_dump_i2c(const uint8_t *data)
+{
+ uint8_t flags, index, bus, offset, len, i;
+ uint16_t address;
+
+ flags = *data++;
+ index = *data++;
+ bus = *data++;
+ address = *((uint16_t *) data);
+ data += 2;
+ offset = *data++;
+ len = *data++;
+
+ printf("\t\tSend I2C: Flags %02x, Index %02x, Bus %02x, Address %04x,
Offset %02x, Length %u, Data",
+ flags, index, bus, address, offset, len);
+ for (i = 0; i < len; i++)
+ printf(" %02x", *data++);
+ printf("\n");
+
+ return data;
+}
+
typedef const uint8_t * (*fn_mipi_elem_dump)(const uint8_t *data);
static const fn_mipi_elem_dump dump_elem[] = {
[MIPI_SEQ_ELEM_SEND_PKT] = mipi_dump_send_packet,
[MIPI_SEQ_ELEM_DELAY] = mipi_dump_delay,
[MIPI_SEQ_ELEM_GPIO] = mipi_dump_gpio,
+ [MIPI_SEQ_ELEM_I2C] = mipi_dump_i2c,
};
static const char * const seq_name[] = {
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH 2/5] intel_bios_reader: check mipi sequence block version
Bail out on v3+, we don't support that just yet.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index e308eaa081d6..09ca50d44a77 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -1036,6 +1036,11 @@ static void dump_mipi_sequence(const struct bdb_block
*block)
return;
}
+ printf("\tSequence block version v%u\n", sequence->version);
+
+ if (sequence->version >= 3)
+ return;
+
block_size = get_blocksize(sequence);
/*
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [i-g-t PATCH 3/5] intel_bios_reader: rewrite the mipi sequence block dumping
Simplify things a lot, make it correct, don't pass random pointers to
free() on errors, etc.
Signed-off-by: Jani Nikula
---
tools/intel_bios.h| 19 ++--
tools/intel_bios_reader.c | 224 +-
2 files changed, 78 insertions(+), 165 deletions(-)
diff --git a/tools/intel_bios.h b/tools/intel_bios.h
index 6135a2b47055..b7ebd48ef7e7 100644
--- a/tools/intel_bios.h
+++ b/tools/intel_bios.h
@@ -763,22 +763,31 @@ struct bdb_mipi_sequence {
uint8_t data[0];
} __attribute__ ((packed));
-/* MIPI Sequnece Block definitions */
-enum MIPI_SEQ {
- MIPI_SEQ_UNDEFINED = 0,
+/* MIPI Sequence Block definitions */
+enum mipi_seq {
+ MIPI_SEQ_END = 0,
MIPI_SEQ_ASSERT_RESET,
MIPI_SEQ_INIT_OTP,
MIPI_SEQ_DISPLAY_ON,
MIPI_SEQ_DISPLAY_OFF,
MIPI_SEQ_DEASSERT_RESET,
+ MIPI_SEQ_BACKLIGHT_ON, /* sequence block v2+ */
+ MIPI_SEQ_BACKLIGHT_OFF, /* sequence block v2+ */
+ MIPI_SEQ_TEAR_ON, /* sequence block v2+ */
+ MIPI_SEQ_TEAR_OFF, /* sequence block v3+ */
+ MIPI_SEQ_POWER_ON, /* sequence block v3+ */
+ MIPI_SEQ_POWER_OFF, /* sequence block v3+ */
MIPI_SEQ_MAX
};
-enum MIPI_SEQ_ELEMENT {
- MIPI_SEQ_ELEM_UNDEFINED = 0,
+enum mipi_seq_element {
+ MIPI_SEQ_ELEM_END = 0,
MIPI_SEQ_ELEM_SEND_PKT,
MIPI_SEQ_ELEM_DELAY,
MIPI_SEQ_ELEM_GPIO,
+ MIPI_SEQ_ELEM_I2C, /* sequence block v2+ */
+ MIPI_SEQ_ELEM_SPI, /* sequence block v3+ */
+ MIPI_SEQ_ELEM_PMIC, /* sequence block v3+ */
MIPI_SEQ_ELEM_MAX
};
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 09ca50d44a77..1b1cb6bc8ebf 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -71,15 +71,6 @@ struct bdb_block {
void *data;
};
-static const char * const seq_name[] = {
- "UNDEFINED",
- "MIPI_SEQ_ASSERT_RESET",
- "MIPI_SEQ_INIT_OTP",
- "MIPI_SEQ_DISPLAY_ON",
- "MIPI_SEQ_DISPLAY_OFF",
- "MIPI_SEQ_DEASSERT_RESET",
-};
-
struct bdb_header *bdb;
struct bdb_lvds_lfp_data_ptrs *lvds_lfp_data_ptrs;
static int tv_present;
@@ -858,7 +849,7 @@ static void dump_mipi_config(const struct bdb_block *block)
printf("\t\tPanel power cycle delay: %d\n",
pps->panel_power_cycle_delay);
}
-static uint8_t *mipi_dump_send_packet(uint8_t *data)
+static const uint8_t *mipi_dump_send_packet(const uint8_t *data)
{
uint8_t type, byte, count;
uint16_t len;
@@ -878,14 +869,14 @@ static uint8_t *mipi_dump_send_packet(uint8_t *data)
return data;
}
-static uint8_t *mipi_dump_delay(uint8_t *data)
+static const uint8_t *mipi_dump_delay(const uint8_t *data)
{
printf("\t\t Delay : 0x%x 0x%x 0x%x 0x%x\n", data[0], data[1], data[2],
data[3]);
data += 4;
return data;
}
-static uint8_t *mipi_dump_gpio(uint8_t *data)
+static const uint8_t *mipi_dump_gpio(const uint8_t *data)
{
uint8_t gpio, action;
@@ -898,119 +889,66 @@ static uint8_t *mipi_dump_gpio(uint8_t *data)
return data;
}
-typedef uint8_t * (*fn_mipi_elem_dump)(uint8_t *data);
+typedef const uint8_t * (*fn_mipi_elem_dump)(const uint8_t *data);
static const fn_mipi_elem_dump dump_elem[] = {
- NULL, /* reserved */
- mipi_dump_send_packet,
- mipi_dump_delay,
- mipi_dump_gpio,
- NULL, /* status read; later */
+ [MIPI_SEQ_ELEM_SEND_PKT] = mipi_dump_send_packet,
+ [MIPI_SEQ_ELEM_DELAY] = mipi_dump_delay,
+ [MIPI_SEQ_ELEM_GPIO] = mipi_dump_gpio,
};
-static void dump_sequence(uint8_t *sequence)
-{
- uint8_t *data = sequence;
- fn_mipi_elem_dump mipi_elem_dump;
- int index_no;
-
- if (!sequence)
- return;
-
- printf("\tSequence Name: %s\n", seq_name[*data]);
-
- /* go to the first element of the sequence */
- data++;
-
- /* parse each byte till we reach end of sequence byte - 0x00 */
- while (1) {
- index_no = *data;
- mipi_elem_dump = dump_elem[index_no];
- if (!mipi_elem_dump) {
- printf("Error: Unsupported MIPI element, skipping
sequence execution\n");
- return;
- }
- /* goto element payload */
- data++;
-
- /* execute the element specifc rotines */
- data = mipi_elem_dump(data);
-
- /*
-* After processing the element, data should point to
-* next element or end of sequence
-* check if have we reached end of sequence
-*/
+static const char * const seq_name[] = {
+ [MIPI_SEQ_ASSERT_RESET] = "MIPI_SEQ_ASSERT_RESET",
+ [MIPI_SEQ_INIT_OTP] = "MIPI_SEQ_INIT_OTP",
+ [MIPI_SEQ_DISPLAY_ON] = "MIPI_SEQ_DISPLAY_ON",
+
[Intel-gfx] [i-g-t PATCH 4/5] intel_bios_reader: improve element dumpers
Try to print something useful and helpful for the user.
Signed-off-by: Jani Nikula
---
tools/intel_bios_reader.c | 43 ---
1 file changed, 24 insertions(+), 19 deletions(-)
diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c
index 1b1cb6bc8ebf..7c3e1bcaa387 100644
--- a/tools/intel_bios_reader.c
+++ b/tools/intel_bios_reader.c
@@ -851,41 +851,46 @@ static void dump_mipi_config(const struct bdb_block
*block)
static const uint8_t *mipi_dump_send_packet(const uint8_t *data)
{
- uint8_t type, byte, count;
- uint16_t len;
+ uint8_t flags, type;
+ uint16_t len, i;
- byte = *data++;
- /* get packet type and increment the pointer */
+ flags = *data++;
type = *data++;
-
len = *((uint16_t *) data);
data += 2;
- printf("\t\t SEND COMMAND: ");
- printf("0x%x 0x%x 0x%x", byte, type, len);
- for (count = 0; count < len; count++)
- printf(" 0x%x",*(data+count));
+
+ printf("\t\tSend DCS: Port %s, VC %d, %s, Type %02x, Length %u, Data",
+ (flags >> 3) & 1 ? "C" : "A",
+ (flags >> 1) & 3,
+ flags & 1 ? "HS" : "LP",
+ type,
+ len);
+ for (i = 0; i < len; i++)
+ printf(" %02x", *data++);
printf("\n");
- data += len;
+
return data;
}
static const uint8_t *mipi_dump_delay(const uint8_t *data)
{
- printf("\t\t Delay : 0x%x 0x%x 0x%x 0x%x\n", data[0], data[1], data[2],
data[3]);
- data += 4;
- return data;
+ printf("\t\tDelay: %u us\n", *((const uint32_t *)data));
+
+ return data + 4;
}
static const uint8_t *mipi_dump_gpio(const uint8_t *data)
{
- uint8_t gpio, action;
+ uint8_t index, flags;
+
+ index = *data++;
+ flags = *data++;
- printf("\t\t GPIO value:");
- gpio = *data++;
+ printf("\t\tGPIO index %u, source %d, set %d\n",
+ index,
+ (flags >> 1) & 3,
+ flags & 1);
- /* pull up/down */
- action = *data++;
- printf(" 0x%x 0x%x\n", gpio, action);
return data;
}
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/skl: Use proper plane dimensions for DDB and WM calculations
In commit
commit 024c9045221fe45482863c47c4b4c47d37f97cbf
Author: Matt Roper
Date: Thu Sep 24 15:53:11 2015 -0700
drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style
WM (v4)
I fumbled while converting the dimensions stored in the plane_parameters
structure to the values stored in plane state and accidentally replaced
the plane dimensions with the pipe dimensions in both the DDB allocation
function and the WM calculation function. On the DDB side this is
harmless since we effectively treat all of our non-cursor planes as
full-screen which may not be optimal, but generally won't cause any
problems either (and in 99% of the cases where there's no sprite plane
usage or primary plane windowing, there's no effect at all). On the WM
calculation side there's more potential for this fumble to cause actual
problems since cursors also get miscalculated.
Cc: Ville Syrjälä
Cc: "Kondapally, Kalyan"
Cc: Radhakrishna Sripada
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 8d0d6f5..f4d4cc7 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2845,25 +2845,22 @@ skl_plane_relative_data_rate(const struct
intel_crtc_state *cstate,
const struct drm_plane_state *pstate,
int y)
{
- struct intel_crtc *intel_crtc = to_intel_crtc(cstate->base.crtc);
+ struct intel_plane_state *intel_pstate = to_intel_plane_state(pstate);
struct drm_framebuffer *fb = pstate->fb;
+ unsigned w = drm_rect_width(&intel_pstate->dst);
+ unsigned h = drm_rect_height(&intel_pstate->dst);
/* for planar format */
if (fb->pixel_format == DRM_FORMAT_NV12) {
if (y) /* y-plane data rate */
- return intel_crtc->config->pipe_src_w *
- intel_crtc->config->pipe_src_h *
- drm_format_plane_cpp(fb->pixel_format, 0);
+ return w * h * drm_format_plane_cpp(fb->pixel_format,
0);
else/* uv-plane data rate */
- return (intel_crtc->config->pipe_src_w/2) *
- (intel_crtc->config->pipe_src_h/2) *
+ return (w/2) * (h/2) *
drm_format_plane_cpp(fb->pixel_format, 1);
}
/* for packed formats */
- return intel_crtc->config->pipe_src_w *
- intel_crtc->config->pipe_src_h *
- drm_format_plane_cpp(fb->pixel_format, 0);
+ return w * h * drm_format_plane_cpp(fb->pixel_format, 0);
}
/*
@@ -2960,6 +2957,8 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
* FIXME: we may not allocate every single block here.
*/
total_data_rate = skl_get_total_relative_data_rate(cstate);
+ if (!total_data_rate)
+ return;
start = alloc->start;
for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
@@ -3093,12 +3092,15 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
{
struct drm_plane *plane = &intel_plane->base;
struct drm_framebuffer *fb = plane->state->fb;
+ struct intel_plane_state *intel_pstate =
+ to_intel_plane_state(plane->state);
uint32_t latency = dev_priv->wm.skl_latency[level];
uint32_t method1, method2;
uint32_t plane_bytes_per_line, plane_blocks_per_line;
uint32_t res_blocks, res_lines;
uint32_t selected_result;
uint8_t bytes_per_pixel;
+ unsigned w = drm_rect_width(&intel_pstate->dst);
if (latency == 0 || !cstate->base.active || !fb)
return false;
@@ -3109,12 +3111,12 @@ static bool skl_compute_plane_wm(const struct
drm_i915_private *dev_priv,
latency);
method2 = skl_wm_method2(skl_pipe_pixel_rate(cstate),
cstate->base.adjusted_mode.crtc_htotal,
-cstate->pipe_src_w,
+w,
bytes_per_pixel,
fb->modifier[0],
latency);
- plane_bytes_per_line = cstate->pipe_src_w * bytes_per_pixel;
+ plane_bytes_per_line = w * bytes_per_pixel;
plane_blocks_per_line = DIV_ROUND_UP(plane_bytes_per_line, 512);
if (fb->modifier[0] == I915_FORMAT_MOD_Y_TILED ||
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/skl: Increase ddb blocks to support large cursor sizes
On Mon, Dec 21, 2015 at 11:15:04AM +0530, Kumar, Shobhit wrote:
> On 12/19/2015 08:14 AM, Matt Roper wrote:
> >On Fri, Dec 18, 2015 at 03:58:52PM -0800, Radhakrishna Sripada wrote:
> >>Original value of 32 blocks is not sufficient when using cursor size of
> >>256x256 causing FIFO underruns when the reworked wm
> >>caluclations in
> >>
> >>commit 024c9045221fe45482863c47c4b4c47d37f97cbf
> >>Author: Matt Roper
> >>Date: Thu Sep 24 15:53:11 2015 -0700
> >>
> >> drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM
> >> (v4)
> >>
> >>are used. Increasing the number of blocks to 52 to make cursor plane
> >>tolerate
> >>SAGV block time for the maximum possible cursor size.
> >>
> >>v2: Included Matt's suggestion, bumping up the no of blocks in multi-pipe
> >>case
> >>to 16.
> >>
> >>Signed-off-by: Radhakrishna Sripada
> >>Signed-off-by: Kalyan Kondapally
> >
> >Can you try my patch "drm/i915/skl: Use proper plane dimensions for DDB
> >and WM calculations" first and see if it solves your problems? It's
>
> Where can I find this patch ? Couldn't find in drm-intel branches or
> the mailing list.
Yeah, looks like I mistyped the mailing list address for git-send-email;
just resent with the proper address...you can find it here:
http://patchwork.freedesktop.org/patch/68786/
Matt
>
> Regards
> Shobhit
>
> >possible that your problems were caused by my fumble that I'm fixing
> >with that patch; if that patch fixes the problem, then we may not need
> >to alter the cursor's fixed allocation after all.
> >
> >Of course as we noted, there are a handful of new workarounds in the
> >bspec (SAGV disabling, system memory bandwidth checking, etc.) that we
> >still don't have in our driver yet, so if any of those are the true root
> >cause, then your patch here is probably a reasonable short-term fix
> >until we can take action on the new workarounds. In that case, you can
> >consider this patch
> >
> >Acknowledged-by: Matt Roper
> >
> >Unfortunately I only have a BXT which doesn't exhibit the problems
> >you're seeing, so I can't actually test this out myself.
> >
> >
> >Matt
> >
> >>---
> >> drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> >> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>
> >>diff --git a/drivers/gpu/drm/i915/intel_pm.c
> >>b/drivers/gpu/drm/i915/intel_pm.c
> >>index d385d99..c5ba4e5 100644
> >>--- a/drivers/gpu/drm/i915/intel_pm.c
> >>+++ b/drivers/gpu/drm/i915/intel_pm.c
> >>@@ -2802,9 +2802,9 @@ skl_ddb_get_pipe_allocation_limits(struct drm_device
> >>*dev,
> >> static unsigned int skl_cursor_allocation(const struct intel_wm_config
> >> *config)
> >> {
> >>if (config->num_pipes_active == 1)
> >>- return 32;
> >>+ return 52;
> >>
> >>- return 8;
> >>+ return 16;
> >> }
> >>
> >> static void skl_ddb_entry_init_from_hw(struct skl_ddb_entry *entry, u32
> >> reg)
> >>--
> >>1.9.1
> >>
> >
--
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC v2] drm/i915/bdw+: Do not emit user interrupts when not needed
From: Tvrtko Ursulin
Currently a single request submission in execlist mode results
in two emitted interrupts. First the user interrupt arrives and
is then followed by the context complete interrupt. (This time
delay is caused by the time taken by the GPU to write out the
context and update the CSB.)
This also means every individual batch submission, and also the
end of the coalesced request submission, will result in two
interrupts instead of potentially one.
If we make sure that the last or solitary request does not emit
the MI_USER_INTERRUPT, but instead rely on context complete to
wake up the waiters, we can reduce the CPU time spent in
interrupt handlers.
In some interrupt heavy benchmarks this can be even 50% fewer
interrupts and 1-2% reduced CPU usage (it halved the time spent
in interrupt handlers on an i7 BDW). But on the other hand this
also has the theoretical potential of increasing the wake-up
latency (see earlier reference for the delay between emitting
the user interrupt and context complete).
v2: Clear MI_USER_INTERRUPT instructions when applicable
rather than emitting them for potentially more robustness
and not breaking GuC submission.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
---
I failed to find a benchmark, or a test, which would reliably
show a win (or lose) with this patch.
Therefore I do not think it is worth the complexity and am
filing it for reference only.
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/i915_irq.c | 24
drivers/gpu/drm/i915/intel_lrc.c | 37 +
3 files changed, 50 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9b82c4532893..94d1084a090b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2825,6 +2825,7 @@ ibx_disable_display_interrupt(struct drm_i915_private
*dev_priv, uint32_t bits)
ibx_display_interrupt_update(dev_priv, bits, 0);
}
+void intel_notify_ring(struct intel_engine_cs *ring);
/* i915_gem.c */
int i915_gem_create_ioctl(struct drm_device *dev, void *data,
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 3f8c753997ba..a2087bad0d64 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -994,7 +994,7 @@ static void ironlake_rps_change_irq_handler(struct
drm_device *dev)
return;
}
-static void notify_ring(struct intel_engine_cs *ring)
+void intel_notify_ring(struct intel_engine_cs *ring)
{
if (!intel_ring_initialized(ring))
return;
@@ -1291,9 +1291,9 @@ static void ilk_gt_irq_handler(struct drm_device *dev,
{
if (gt_iir &
(GT_RENDER_USER_INTERRUPT | GT_RENDER_PIPECTL_NOTIFY_INTERRUPT))
- notify_ring(&dev_priv->ring[RCS]);
+ intel_notify_ring(&dev_priv->ring[RCS]);
if (gt_iir & ILK_BSD_USER_INTERRUPT)
- notify_ring(&dev_priv->ring[VCS]);
+ intel_notify_ring(&dev_priv->ring[VCS]);
}
static void snb_gt_irq_handler(struct drm_device *dev,
@@ -1303,11 +1303,11 @@ static void snb_gt_irq_handler(struct drm_device *dev,
if (gt_iir &
(GT_RENDER_USER_INTERRUPT | GT_RENDER_PIPECTL_NOTIFY_INTERRUPT))
- notify_ring(&dev_priv->ring[RCS]);
+ intel_notify_ring(&dev_priv->ring[RCS]);
if (gt_iir & GT_BSD_USER_INTERRUPT)
- notify_ring(&dev_priv->ring[VCS]);
+ intel_notify_ring(&dev_priv->ring[VCS]);
if (gt_iir & GT_BLT_USER_INTERRUPT)
- notify_ring(&dev_priv->ring[BCS]);
+ intel_notify_ring(&dev_priv->ring[BCS]);
if (gt_iir & (GT_BLT_CS_ERROR_INTERRUPT |
GT_BSD_CS_ERROR_INTERRUPT |
@@ -1322,7 +1322,7 @@ static __always_inline void
gen8_cs_irq_handler(struct intel_engine_cs *ring, u32 iir, int test_shift)
{
if (iir & (GT_RENDER_USER_INTERRUPT << test_shift))
- notify_ring(ring);
+ intel_notify_ring(ring);
if (iir & (GT_CONTEXT_SWITCH_INTERRUPT << test_shift))
intel_lrc_irq_handler(ring);
}
@@ -1629,7 +1629,7 @@ static void gen6_rps_irq_handler(struct drm_i915_private
*dev_priv, u32 pm_iir)
if (HAS_VEBOX(dev_priv->dev)) {
if (pm_iir & PM_VEBOX_USER_INTERRUPT)
- notify_ring(&dev_priv->ring[VECS]);
+ intel_notify_ring(&dev_priv->ring[VECS]);
if (pm_iir & PM_VEBOX_CS_ERROR_INTERRUPT)
DRM_DEBUG("Command parser error, pm_iir 0x%08x\n",
pm_iir);
@@ -3961,7 +3961,7 @@ static irqreturn_t i8xx_irq_handler(int irq, void *arg)
new_iir = I915_READ16(IIR); /* Flush posted writes */
if (iir & I915_USER_INTERRUPT)
- notify_ring(&dev_priv->ring[RCS]);
+ intel_notify_ring(&dev_priv->
Re: [Intel-gfx] [PATCH 03/13] staging/android/sync: Move sync framework out of staging
On Mon, Dec 21, 2015 at 02:20:59PM +, John Harrison wrote: > On 21/12/2015 10:03, Daniel Vetter wrote: > >On Thu, Dec 17, 2015 at 09:35:03AM -0800, Jesse Barnes wrote: > >>On 12/11/2015 05:11 AM, john.c.harri...@intel.com wrote: > >>>From: John Harrison > >>> > >>>The sync framework is now used by the i915 driver. Therefore it can be > >>>moved out of staging and into the regular tree. Also, the public > >>>interfaces can actually be made public and exported. > >>> > >>>v3: New patch for series. > >>> > >>>Signed-off-by: John Harrison > >>>Signed-off-by: Geoff Miller > >>>--- > >>> drivers/android/Kconfig| 28 ++ > >>> drivers/android/Makefile | 2 + > >>> drivers/android/sw_sync.c | 260 > >>> drivers/android/sw_sync.h | 59 +++ > >>> drivers/android/sync.c | 734 > >>> + > >>> drivers/android/sync.h | 366 > >>> drivers/android/sync_debug.c | 256 > >>> drivers/android/trace/sync.h | 82 > >>> drivers/staging/android/Kconfig| 28 -- > >>> drivers/staging/android/Makefile | 2 - > >>> drivers/staging/android/sw_sync.c | 260 > >>> drivers/staging/android/sw_sync.h | 59 --- > >>> drivers/staging/android/sync.c | 734 > >>> - > >>> drivers/staging/android/sync.h | 366 > >>> drivers/staging/android/sync_debug.c | 256 > >>> drivers/staging/android/trace/sync.h | 82 > >>> drivers/staging/android/uapi/sw_sync.h | 32 -- > >>> drivers/staging/android/uapi/sync.h| 97 - > >>> include/uapi/Kbuild| 1 + > >>> include/uapi/sync/Kbuild | 3 + > >>> include/uapi/sync/sw_sync.h| 32 ++ > >>> include/uapi/sync/sync.h | 97 + > >>> 22 files changed, 1920 insertions(+), 1916 deletions(-) > >>> create mode 100644 drivers/android/sw_sync.c > >>> create mode 100644 drivers/android/sw_sync.h > >>> create mode 100644 drivers/android/sync.c > >>> create mode 100644 drivers/android/sync.h > >>> create mode 100644 drivers/android/sync_debug.c > >>> create mode 100644 drivers/android/trace/sync.h > >>> delete mode 100644 drivers/staging/android/sw_sync.c > >>> delete mode 100644 drivers/staging/android/sw_sync.h > >>> delete mode 100644 drivers/staging/android/sync.c > >>> delete mode 100644 drivers/staging/android/sync.h > >>> delete mode 100644 drivers/staging/android/sync_debug.c > >>> delete mode 100644 drivers/staging/android/trace/sync.h > >>> delete mode 100644 drivers/staging/android/uapi/sw_sync.h > >>> delete mode 100644 drivers/staging/android/uapi/sync.h > >>> create mode 100644 include/uapi/sync/Kbuild > >>> create mode 100644 include/uapi/sync/sw_sync.h > >>> create mode 100644 include/uapi/sync/sync.h > >>> > >>>diff --git a/drivers/android/Kconfig b/drivers/android/Kconfig > >>>index bdfc6c6..9edcd8f 100644 > >>>--- a/drivers/android/Kconfig > >>>+++ b/drivers/android/Kconfig > >>>@@ -32,6 +32,34 @@ config ANDROID_BINDER_IPC_32BIT > >>> Note that enabling this will break newer Android user-space. > >>>+config SYNC > >>>+ bool "Synchronization framework" > >>>+ default n > >>>+ select ANON_INODES > >>>+ select DMA_SHARED_BUFFER > >>>+ ---help--- > >>>+This option enables the framework for synchronization between multiple > >>>+drivers. Sync implementations can take advantage of hardware > >>>+synchronization built into devices like GPUs. > >>>+ > >>>+config SW_SYNC > >>>+ bool "Software synchronization objects" > >>>+ default n > >>>+ depends on SYNC > >>>+ ---help--- > >>>+A sync object driver that uses a 32bit counter to coordinate > >>>+synchronization. Useful when there is no hardware primitive backing > >>>+the synchronization. > >>>+ > >>>+config SW_SYNC_USER > >>>+ bool "Userspace API for SW_SYNC" > >>>+ default n > >>>+ depends on SW_SYNC > >>>+ ---help--- > >>>+Provides a user space API to the sw sync object. > >>>+*WARNING* improper use of this can result in deadlocking kernel > >>>+drivers from userspace. > >>>+ > >>> endif # if ANDROID > >>IIRC we wanted to drop the user ABI altogether? I think we can de-stage > >>this even before we push the new ABI on the i915 side to expose the sync > >>points (since we'll need an open source userspace for that), and any > >>changes/cleanups can happen outside of staging. > >Just a head-up: Gustavo Padovan from Collabora is working to de-stage all > >the syncpt stuff. Greg KH merged the TODO update for that work for 4.5, > >which covers consensus (including ack from Google's Greg Hackmann on the > >plan). Given that I think it'd be best to freeload on that effort. But > >that means we need to push all the android/syncpt stuff down in the > >series. I hope that works, and there's no funct
Re: [Intel-gfx] [PATCH i-g-t 4/6] lib: Add igt_pipe_crc_new_nonblock()
On Fri, Dec 18, 2015 at 07:25:48PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add support for reading the CRC in non-blocking mode. Useful for tests
> that want to start the CRC capture, then do a bunch of operations, then
> collect however many CRCs that got generated. The current
> igt_pipe_crc_new() + igt_pipe_crc_get_crcs() method would block until
> it gets the requested number of CRCs, whreas in non-blocking mode we
> can just read as many as got generated thus far.
>
> Signed-off-by: Ville Syrjälä
> ---
> lib/igt_debugfs.c | 136
> +++---
> lib/igt_debugfs.h | 4 +-
> 2 files changed, 91 insertions(+), 49 deletions(-)
>
> diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
> index a3d015267e15..1d625ad4ba50 100644
> --- a/lib/igt_debugfs.c
> +++ b/lib/igt_debugfs.c
> @@ -298,6 +298,7 @@ struct _igt_pipe_crc {
> int crc_fd;
> int line_len;
> int buffer_len;
> + int flags;
>
> enum pipe pipe;
> enum intel_pipe_crc_source source;
> @@ -389,19 +390,8 @@ void igt_require_pipe_crc(void)
> fclose(ctl);
> }
>
> -/**
> - * igt_pipe_crc_new:
> - * @pipe: display pipe to use as source
> - * @source: CRC tap point to use as source
> - *
> - * This sets up a new pipe CRC capture object for the given @pipe and
> @source.
> - *
> - * Returns: A pipe CRC object if the given @pipe and @source. The library
> - * assumes that the source is always available since recent kernels support
> at
> - * least INTEL_PIPE_CRC_SOURCE_AUTO everywhere.
> - */
> -igt_pipe_crc_t *
> -igt_pipe_crc_new(enum pipe pipe, enum intel_pipe_crc_source source)
> +static igt_pipe_crc_t *
> +pipe_crc_new(enum pipe pipe, enum intel_pipe_crc_source source, int flags)
> {
> igt_pipe_crc_t *pipe_crc;
> char buf[128];
> @@ -414,18 +404,55 @@ igt_pipe_crc_new(enum pipe pipe, enum
> intel_pipe_crc_source source)
> igt_assert(pipe_crc->ctl_fd != -1);
>
> sprintf(buf, "i915_pipe_%s_crc", kmstest_pipe_name(pipe));
> - pipe_crc->crc_fd = igt_debugfs_open(buf, O_RDONLY);
> + pipe_crc->crc_fd = igt_debugfs_open(buf, flags);
> igt_assert(pipe_crc->crc_fd != -1);
>
> pipe_crc->line_len = PIPE_CRC_LINE_LEN;
> pipe_crc->buffer_len = PIPE_CRC_BUFFER_LEN;
> pipe_crc->pipe = pipe;
> pipe_crc->source = source;
> + pipe_crc->flags = flags;
>
> return pipe_crc;
> }
>
> /**
> + * igt_pipe_crc_new:
> + * @pipe: display pipe to use as source
> + * @source: CRC tap point to use as source
> + *
> + * This sets up a new pipe CRC capture object for the given @pipe and @source
> + * in blocking mode.
> + *
> + * Returns: A pipe CRC object if the given @pipe and @source. The library
> + * assumes that the source is always available since recent kernels support
> at
> + * least INTEL_PIPE_CRC_SOURCE_AUTO everywhere.
> + */
> +igt_pipe_crc_t *
> +igt_pipe_crc_new(enum pipe pipe, enum intel_pipe_crc_source source)
> +{
> + return pipe_crc_new(pipe, source, O_RDONLY);
> +}
> +
> +/**
> + * igt_pipe_crc_new_nonblock:
> + * @pipe: display pipe to use as source
> + * @source: CRC tap point to use as source
> + *
> + * This sets up a new pipe CRC capture object for the given @pipe and @source
> + * in nonblocking mode.
> + *
> + * Returns: A pipe CRC object if the given @pipe and @source. The library
> + * assumes that the source is always available since recent kernels support
> at
> + * least INTEL_PIPE_CRC_SOURCE_AUTO everywhere.
> + */
> +igt_pipe_crc_t *
> +igt_pipe_crc_new_nonblock(enum pipe pipe, enum intel_pipe_crc_source source)
> +{
> + return pipe_crc_new(pipe, source, O_RDONLY | O_NONBLOCK);
> +}
> +
> +/**
> * igt_pipe_crc_free:
> * @pipe_crc: pipe CRC object
> *
> @@ -441,6 +468,39 @@ void igt_pipe_crc_free(igt_pipe_crc_t *pipe_crc)
> free(pipe_crc);
> }
>
> +static bool pipe_crc_init_from_string(igt_crc_t *crc, const char *line)
> +{
> + int n;
> +
> + crc->n_words = 5;
> + n = sscanf(line, "%8u %8x %8x %8x %8x %8x", &crc->frame, &crc->crc[0],
> +&crc->crc[1], &crc->crc[2], &crc->crc[3], &crc->crc[4]);
> + return n == 6;
> +}
> +
> +static int read_one_crc(igt_pipe_crc_t *pipe_crc, igt_crc_t *out)
> +{
> + ssize_t bytes_read;
> + char buf[pipe_crc->buffer_len];
> +
> + igt_set_timeout(5, "CRC reading");
> + bytes_read = read(pipe_crc->crc_fd, &buf, pipe_crc->line_len);
> + igt_reset_timeout();
> +
> + if (bytes_read < 0 && errno == EAGAIN) {
> + igt_assert(pipe_crc->flags & O_NONBLOCK);
> + bytes_read = 0;
> + } else {
> + igt_assert_eq(bytes_read, pipe_crc->line_len);
> + }
> + buf[bytes_read] = '\0';
> +
> + if (bytes_read && !pipe_crc_init_from_string(out, buf))
> + return -EINVAL;
> +
> + return bytes_read;
> +}
> +
> /**
> * igt_pipe_crc_start:
> * @pipe_crc: pipe CRC object
> @@ -449,7 +509,7 @@ void i
Re: [Intel-gfx] [PATCH i-g-t 3/6] lib: Use igt_assert_eq() to check for crc component count
On Fri, Dec 18, 2015 at 07:25:47PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> It's nice to see just how many components the crc claims to have
> when the count don't match what we expect.
>
> Signed-off-by: Ville Syrjälä
Assuming that you're on vacation already merged patches 1&3.
Thanks, Daniel
> ---
> lib/igt_debugfs.c | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
> index 4322e8eebb3c..a3d015267e15 100644
> --- a/lib/igt_debugfs.c
> +++ b/lib/igt_debugfs.c
> @@ -280,11 +280,10 @@ char *igt_crc_to_string(igt_crc_t *crc)
> {
> char buf[128];
>
> - if (crc->n_words == 5)
> - sprintf(buf, "%08x %08x %08x %08x %08x", crc->crc[0],
> - crc->crc[1], crc->crc[2], crc->crc[3], crc->crc[4]);
> - else
> - igt_assert(0);
> + igt_assert_eq(crc->n_words, 5);
> +
> + sprintf(buf, "%08x %08x %08x %08x %08x", crc->crc[0],
> + crc->crc[1], crc->crc[2], crc->crc[3], crc->crc[4]);
>
> return strdup(buf);
> }
> --
> 2.4.10
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: edp resume/On time optimization.
On Mon, Dec 21, 2015 at 05:33:41AM +, Kumar, Abhay wrote:
> Changed the implementation using boottime and removed jiffies. Please review
> and let us know if this is close.
Comments like these should be part of the patch submission itself,
including a note about which reviewer made the suggestion and adding
everyone who commented to the cc list. So something like this at the
bottom:
v2:
- Change (Ville).
- Use boootime instead of jiffies (Ville).
Cc: Ville (full mail address here).
Singed-off-by: ...
Without either the in-patch changelog or the cc it's much harder for
reviewers to follow along, especially when they're commenting on 10+ patch
series at the same time.
Please resubmit with that added.
Thanks, Daniel
>
> -Original Message-
> From: Kumar, Abhay
> Sent: Friday, December 18, 2015 11:55 AM
> To: Intel-gfx@lists.freedesktop.org
> Cc: Kumar, Abhay
> Subject: [PATCH] drm/i915: edp resume/On time optimization.
>
> From: Abhay Kumar
>
> Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12) if
> this time is already spent in suspend/poweron time.
>
> Change-Id: Ied0f10f82776af8e6e8ff561bb4e5c0ce1dad4b3
> Signed-off-by: Abhay Kumar
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 3 +++ drivers/gpu/drm/i915/intel_dp.c
> | 22 ++ drivers/gpu/drm/i915/intel_drv.h | 2 +-
> 3 files changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index cbabcb4..fe99d72 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2347,6 +2347,9 @@ static void intel_ddi_post_disable(struct intel_encoder
> *intel_encoder)
> intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> intel_edp_panel_vdd_on(intel_dp);
> intel_edp_panel_off(intel_dp);
> +
> + /* storing panel power off time */
> + intel_dp->panel_power_off_time =
> ktime_get_with_offset(TK_OFFS_BOOT);
> }
>
> if (IS_SKYLAKE(dev))
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c index acda70e..845944d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -38,7 +38,6 @@
> #include "intel_drv.h"
> #include
> #include "i915_drv.h"
> -
> #define DP_LINK_CHECK_TIMEOUT(10 * 1000)
>
> /* Compliance test status bits */
> @@ -1654,13 +1653,22 @@ static void wait_panel_off(struct intel_dp *intel_dp)
>
> static void wait_panel_power_cycle(struct intel_dp *intel_dp) {
> + ktime_t panel_power_on_time;
> + u32 panel_power_off_duration;
> +
> DRM_DEBUG_KMS("Wait for panel power cycle\n");
>
> - /* When we disable the VDD override bit last we have to do the manual
> - * wait. */
> - wait_remaining_ms_from_jiffies(intel_dp->last_power_cycle,
> -intel_dp->panel_power_cycle_delay);
> +/* take the diffrence of currrent time and panel power off time
> + and then make panel wait for t11_t12 if needed */
> + panel_power_on_time = ktime_get_with_offset(TK_OFFS_BOOT);
> + panel_power_off_duration = (panel_power_on_time.tv64 -
> intel_dp->panel_power_off_time.tv64);
> + panel_power_off_duration = panel_power_off_duration / 100;
>
> + /* When we disable the VDD override bit last we have to do the manual
> + * wait */
> + if (panel_power_off_duration < intel_dp->panel_power_cycle_delay)
> + wait_remaining_ms_from_jiffies(jiffies,
> +(intel_dp->panel_power_cycle_delay -
> +panel_power_off_duration));
> wait_panel_status(intel_dp, IDLE_CYCLE_MASK, IDLE_CYCLE_VALUE); }
>
> @@ -1811,7 +1819,7 @@ static void edp_panel_vdd_off_sync(struct intel_dp
> *intel_dp)
> I915_READ(pp_stat_reg), I915_READ(pp_ctrl_reg));
>
> if ((pp & POWER_TARGET_ON) == 0)
> - intel_dp->last_power_cycle = jiffies;
> + intel_dp->panel_power_off_time =
> ktime_get_with_offset(TK_OFFS_BOOT);
>
> power_domain = intel_display_port_power_domain(intel_encoder);
> intel_display_power_put(dev_priv, power_domain); @@ -1960,7 +1968,6 @@
> static void edp_panel_off(struct intel_dp *intel_dp)
> I915_WRITE(pp_ctrl_reg, pp);
> POSTING_READ(pp_ctrl_reg);
>
> - intel_dp->last_power_cycle = jiffies;
> wait_panel_off(intel_dp);
>
> /* We got a reference when we enabled the VDD. */ @@ -5196,7 +5203,6 @@
> intel_dp_add_properties(struct intel_dp *intel_dp, struct drm_connector
> *connect
>
> static void intel_dp_init_panel_power_timestamps(struct intel_dp *intel_dp)
> {
> - intel_dp->last_power_cycle = jiffies;
> intel_dp->last_power_on = jiffies;
> intel_dp->last_backlight_off = jiffies; } diff --git
> a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index d44f2f5..ef82e8f 100644
> --- a
Re: [Intel-gfx] [PATCH] drm/i915: Acquire RPM wakeref for KMS atomic commit
On Sat, Dec 19, 2015 at 09:58:43AM +, Chris Wilson wrote:
> Once all the preparations are complete, we are ready to write the
> modesetting to the hardware. During this phase, we will be making lots
> of HW register access, so take a top level wakeref to prevent an
> unwarranted rpm suspend cycle mid-commit. Lower level functions should
> be waking the individual power wells as required.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93439
> Signed-off-by: Chris Wilson
> Cc: Imre Deak
The original idea here was that doing this will paper over bugs in our rpm
refcounting. There's also the problem that for modeset stuff we have all
the power wells still to take care of.
For the referenced bug we should add a power domain check in the get hw
state function instead, which is what we've been doing with all the other
similar hw state readout functions too.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index abd2d2944022..60451c3932db 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13470,6 +13470,13 @@ static int intel_atomic_commit(struct drm_device
> *dev,
> drm_atomic_helper_swap_state(dev, state);
> dev_priv->wm.config = to_intel_atomic_state(state)->wm_config;
>
> + /* Take a rpm wakeref for the duration of the commit. Lower level
> + * functions should be acquiring the power wells for their own use,
> + * we take this toplevel reference to prevent rpm suspend cycles
> + * mid-commit.
> + */
> + intel_runtime_pm_get(dev_priv);
> +
> for_each_crtc_in_state(state, crtc, crtc_state, i) {
> struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>
> @@ -13558,6 +13565,8 @@ static int intel_atomic_commit(struct drm_device *dev,
> if (any_ms)
> intel_modeset_check_state(dev, state);
>
> + intel_runtime_pm_put(dev_priv);
> +
> drm_atomic_state_free(state);
>
> return 0;
> --
> 2.6.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove obsolete code from intelfb_alloc()
On Sat, Dec 19, 2015 at 03:02:49PM +, Chris Wilson wrote:
> On Sat, Dec 19, 2015 at 03:40:39PM +0100, Lukas Wunner wrote:
> > Clean up after 0c82312f3f15 ("drm/i915: Pin the ifbdev for the
> > info->system_base GGTT mmapping"):
> >
> > At each of the remaining "goto out" in intelfb_alloc(), fb can only be
> > either an ERR_PTR or NULL, so the call to drm_framebuffer_unreference()
> > is now obsolete.
> >
> > Cc: Daniel Vetter
> > Cc: Chris Wilson
> > Signed-off-by: Lukas Wunner
> Reviewed-by: Chris Wilson
Queued for -next, thanks for the patch.
-Daniel
> -Chris
>
> --
> Chris Wilson, Intel Open Source Technology Centre
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/i915: tidy up initialisation failure paths (GEM & LRC)
1. add call to i915_gem_context_fini() to deallocate the default
context(s) if the call to init_rings() fails, so that we don't
leak the context in that situation.
2. remove useless code in intel_logical_ring_cleanup(), presumably
copypasted from legacy ringbuffer version at creation.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_gem.c | 5 -
drivers/gpu/drm/i915/intel_lrc.c | 10 ++
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 01b1eea..20777e4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4964,8 +4964,11 @@ int i915_gem_init(struct drm_device *dev)
goto out_unlock;
ret = dev_priv->gt.init_rings(dev);
- if (ret)
+ if (ret) {
+ i915_gem_context_fini(dev);
+ /* XXX: anything else to be undone here? */
goto out_unlock;
+ }
ret = i915_gem_init_hw(dev);
if (ret == -EIO) {
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 743ac81..b731e16 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1884,17 +1884,11 @@ static int gen8_init_rcs_context(struct
drm_i915_gem_request *req)
*/
void intel_logical_ring_cleanup(struct intel_engine_cs *ring)
{
- struct drm_i915_private *dev_priv;
-
if (!intel_ring_initialized(ring))
return;
- dev_priv = ring->dev->dev_private;
-
- if (ring->buffer) {
- intel_logical_ring_stop(ring);
- WARN_ON((I915_READ_MODE(ring) & MODE_IDLE) == 0);
- }
+ /* should not be set in LRC mode */
+ WARN_ON(ring->buffer);
if (ring->cleanup)
ring->cleanup(ring);
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/6] drm/i915: mark the global default (intel_)context as such
Some of the LRC-specific context-destruction code has to special-case
the global default context, bacause the HWSP is part of that context. At
present it deduces it indirectly by checking for the backpointer from
the engine to the context, but that's an unsafe assumption if the setup
and teardown code is reorganised. (It could also test ctx->file_priv ==
NULL, but again that's a detail that might be subject to change).
So here we explicitly flag the default context at the point of creation,
and then reorganise the code in intel_lr_context_free() not to rely on
the ring->default_pointer (still) being set up; to iterate over engines
in reverse, as this is teardown code; and to reduce the nesting
level so it's easier to read.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem_context.c | 12 +++-
drivers/gpu/drm/i915/intel_lrc.c| 25 -
3 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9b82c45..666d07c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -854,6 +854,7 @@ struct i915_ctx_hang_stats {
* @ref: reference count.
* @user_handle: userspace tracking identity for this context.
* @remap_slice: l3 row remapping information.
+ * @is_default: true iff this is the global default context
* @flags: context specific flags:
* CONTEXT_NO_ZEROMAP: do not allow mapping things to page 0.
* @file_priv: filp associated with this context (NULL for global default
@@ -872,6 +873,7 @@ struct intel_context {
struct kref ref;
int user_handle;
uint8_t remap_slice;
+ uint8_t is_global_default;
struct drm_i915_private *i915;
int flags;
struct drm_i915_file_private *file_priv;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 900ffd0..5d3e287 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -241,8 +241,10 @@ __create_hw_context(struct drm_device *dev,
DEFAULT_CONTEXT_HANDLE, 0, GFP_KERNEL);
if (ret < 0)
goto err_out;
- } else
+ } else {
+ ctx->is_global_default = true;
ret = DEFAULT_CONTEXT_HANDLE;
+ }
ctx->file_priv = file_priv;
ctx->user_handle = ret;
@@ -269,7 +271,6 @@ static struct intel_context *
i915_gem_create_context(struct drm_device *dev,
struct drm_i915_file_private *file_priv)
{
- const bool is_global_default_ctx = file_priv == NULL;
struct intel_context *ctx;
int ret = 0;
@@ -279,8 +280,9 @@ i915_gem_create_context(struct drm_device *dev,
if (IS_ERR(ctx))
return ctx;
- if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state) {
- /* We may need to do things with the shrinker which
+ if (ctx->is_global_default && ctx->legacy_hw_ctx.rcs_state) {
+ /*
+* We may need to do things with the shrinker which
* require us to immediately switch back to the default
* context. This can cause a problem as pinning the
* default context also requires GTT space which may not
@@ -313,7 +315,7 @@ i915_gem_create_context(struct drm_device *dev,
return ctx;
err_unpin:
- if (is_global_default_ctx && ctx->legacy_hw_ctx.rcs_state)
+ if (ctx->is_global_default && ctx->legacy_hw_ctx.rcs_state)
i915_gem_object_ggtt_unpin(ctx->legacy_hw_ctx.rcs_state);
err_destroy:
idr_remove(&file_priv->context_idr, ctx->user_handle);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 3aa6147..23f90b2 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -2367,22 +2367,21 @@ void intel_lr_context_free(struct intel_context *ctx)
{
int i;
- for (i = 0; i < I915_NUM_RINGS; i++) {
+ for (i = I915_NUM_RINGS; --i >= 0; ) {
+ struct intel_ringbuffer *ringbuf = ctx->engine[i].ringbuf;
struct drm_i915_gem_object *ctx_obj = ctx->engine[i].state;
- if (ctx_obj) {
- struct intel_ringbuffer *ringbuf =
- ctx->engine[i].ringbuf;
- struct intel_engine_cs *ring = ringbuf->ring;
+ if (!ctx_obj)
+ continue;
- if (ctx == ring->default_context) {
- intel_unpin_ringbuffer_obj(ringbuf);
- i915_gem_object_ggtt_unpin(ctx_obj);
- }
- WARN_ON(ctx->engine[ring->id].pin_count);
- intel_ringbuffer_free(ringbuf);
-
[Intel-gfx] [PATCH 4/6] drm/i915: abolish separate per-engine default_context pointers
All the engines share the same default (intel_)context, so we can just
keep a single reference to it in the dev_priv structure rather than in
each of the engine[] elements. This make refcounting more sensible too,
as we now have a refcount of one for the one pointer, rather than a
refcount of one but multiple pointers.
From an idea by Chris Wilson.
Signed-off-by: Dave Gordon
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 2 ++
drivers/gpu/drm/i915/i915_gem.c| 5 +++--
drivers/gpu/drm/i915/i915_gem_context.c| 22 --
drivers/gpu/drm/i915/i915_gpu_error.c | 2 +-
drivers/gpu/drm/i915/i915_guc_submission.c | 6 +++---
drivers/gpu/drm/i915/intel_lrc.c | 5 +++--
drivers/gpu/drm/i915/intel_ringbuffer.h| 1 -
8 files changed, 21 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 13261fc..722f302 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1943,7 +1943,7 @@ static int i915_context_status(struct seq_file *m, void
*unused)
seq_puts(m, "HW context ");
describe_ctx(m, ctx);
for_each_ring(ring, dev_priv, i) {
- if (ring->default_context == ctx)
+ if (dev_priv->kernel_context == ctx)
seq_printf(m, "(default context %s) ",
ring->name);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4955db9..3c371ce 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1947,6 +1947,8 @@ struct drm_i915_private {
void (*stop_ring)(struct intel_engine_cs *ring);
} gt;
+ struct intel_context *kernel_context;
+
bool edp_low_vswing;
/* perform PHY state sanity checks? */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9f9c0c0..01b1eea 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2759,10 +2759,11 @@ err:
struct drm_i915_gem_request *
i915_gem_request_alloc_anon(struct intel_engine_cs *ring)
{
+ struct drm_i915_private *dev_priv = to_i915(ring->dev);
struct drm_i915_gem_request *req;
int err;
- err = i915_gem_request_alloc(ring, ring->default_context, &req);
+ err = i915_gem_request_alloc(ring, dev_priv->kernel_context, &req);
return err ? ERR_PTR(err) : req;
}
@@ -4849,7 +4850,7 @@ i915_gem_init_hw(struct drm_device *dev)
*/
init_unused_rings(dev);
- BUG_ON(!dev_priv->ring[RCS].default_context);
+ BUG_ON(!dev_priv->kernel_context);
ret = i915_ppgtt_init_hw(dev);
if (ret) {
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 5d3e287..b655a50 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -356,11 +356,10 @@ int i915_gem_context_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_context *ctx;
- int i;
/* Init should only be called once per module load. Eventually the
* restriction on the context_disabled check can be loosened. */
- if (WARN_ON(dev_priv->ring[RCS].default_context))
+ if (WARN_ON(dev_priv->kernel_context))
return 0;
if (intel_vgpu_active(dev) && HAS_LOGICAL_RING_CONTEXTS(dev)) {
@@ -390,12 +389,7 @@ int i915_gem_context_init(struct drm_device *dev)
return PTR_ERR(ctx);
}
- for (i = 0; i < I915_NUM_RINGS; i++) {
- struct intel_engine_cs *ring = &dev_priv->ring[i];
-
- /* NB: RCS will hold a ref for all rings */
- ring->default_context = ctx;
- }
+ dev_priv->kernel_context = ctx;
DRM_DEBUG_DRIVER("%s context support initialized\n",
i915.enable_execlists ? "LR" :
@@ -406,7 +400,7 @@ int i915_gem_context_init(struct drm_device *dev)
void i915_gem_context_fini(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev->dev_private;
- struct intel_context *dctx = dev_priv->ring[RCS].default_context;
+ struct intel_context *dctx = dev_priv->kernel_context;
int i;
if (dctx->legacy_hw_ctx.rcs_state) {
@@ -433,17 +427,17 @@ void i915_gem_context_fini(struct drm_device *dev)
i915_gem_object_ggtt_unpin(dctx->legacy_hw_ctx.rcs_state);
}
- for (i = 0; i < I915_NUM_RINGS; i++) {
+ for (i = I915_NUM_RINGS; --i >= 0;) {
struct intel_engine_cs *ring = &dev_priv->ring[i];
- if (ring->last_context)
+ if (ring->last_context) {
[Intel-gfx] [PATCH 2/6] drm/i915: simplify testing for the global default context
There are quite a number of places where the driver tests whether a
given context is or is not the global default context, usually by
checking whether an engine's default_pointer points to the context. Now
that we have a 'is_global_default' flag in the context itself, these can
be rewritten to use it. This makes the logic more obvious, and usually
saves at least one memory reference.
Signed-off-by: Dave Gordon
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_debugfs.c | 8 +++-
drivers/gpu/drm/i915/i915_gem.c | 8 ++--
drivers/gpu/drm/i915/intel_lrc.c| 26 --
3 files changed, 17 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0fc38bb..13261fc 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2037,13 +2037,11 @@ static int i915_dump_lrc(struct seq_file *m, void
*unused)
if (ret)
return ret;
- list_for_each_entry(ctx, &dev_priv->context_list, link) {
- for_each_ring(ring, dev_priv, i) {
- if (ring->default_context != ctx)
+ list_for_each_entry(ctx, &dev_priv->context_list, link)
+ if (!ctx->is_global_default)
+ for_each_ring(ring, dev_priv, i)
i915_dump_lrc_obj(m, ring,
ctx->engine[i].state);
- }
- }
mutex_unlock(&dev->struct_mutex);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6c60e04..be1f984 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2677,10 +2677,8 @@ void i915_gem_request_free(struct kref *req_ref)
i915_gem_request_remove_from_client(req);
if (ctx) {
- if (i915.enable_execlists) {
- if (ctx != req->ring->default_context)
- intel_lr_context_unpin(req);
- }
+ if (i915.enable_execlists && !ctx->is_global_default)
+ intel_lr_context_unpin(req);
i915_gem_context_unreference(ctx);
}
@@ -4869,8 +4867,6 @@ i915_gem_init_hw(struct drm_device *dev)
for_each_ring(ring, dev_priv, i) {
struct drm_i915_gem_request *req;
- WARN_ON(!ring->default_context);
-
ret = i915_gem_request_alloc(ring, ring->default_context, &req);
if (ret) {
i915_gem_cleanup_ringbuffer(dev);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 23f90b2..c44bd86 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -571,7 +571,7 @@ static int execlists_context_queue(struct
drm_i915_gem_request *request)
struct drm_i915_gem_request *cursor;
int num_elements = 0;
- if (request->ctx != ring->default_context)
+ if (!request->ctx->is_global_default)
intel_lr_context_pin(request);
i915_gem_request_reference(request);
@@ -660,17 +660,14 @@ static int execlists_move_to_gpu(struct
drm_i915_gem_request *req,
int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request
*request)
{
- int ret;
+ int ret = 0;
request->ringbuf = request->ctx->engine[request->ring->id].ringbuf;
- if (request->ctx != request->ring->default_context) {
+ if (!request->ctx->is_global_default)
ret = intel_lr_context_pin(request);
- if (ret)
- return ret;
- }
- return 0;
+ return ret;
}
static int logical_ring_wait_for_space(struct drm_i915_gem_request *req,
@@ -967,7 +964,7 @@ void intel_execlists_retire_requests(struct intel_engine_cs
*ring)
struct drm_i915_gem_object *ctx_obj =
ctx->engine[ring->id].state;
- if (ctx_obj && (ctx != ring->default_context))
+ if (ctx_obj && !ctx->is_global_default)
intel_lr_context_unpin(req);
list_del(&req->execlist_link);
i915_gem_request_unreference(req);
@@ -1916,6 +1913,8 @@ void intel_logical_ring_cleanup(struct intel_engine_cs
*ring)
static int logical_ring_init(struct drm_device *dev, struct intel_engine_cs
*ring)
{
+ struct intel_context *dctx = ring->default_context;
+ int ring_id = ring->id;
int ret;
/* Intentionally left blank. */
@@ -1936,15 +1935,14 @@ static int logical_ring_init(struct drm_device *dev,
struct intel_engine_cs *rin
if (ret)
goto error;
- ret = intel_lr_context_deferred_alloc(ring->default_context, ring);
+ ret = intel_lr_context_deferred_alloc(dctx, ring);
if (ret)
goto error;
/* As this is the default cont
[Intel-gfx] improve handling of the driver's internal default context
A collection of patches to simplify the creation, use, and destruction of the driver's global default context. The first two simplify the many places where the code treats the global default context differently from any other context: [1/6] drm/i915: mark the global default (intel_)context as such [2/6] drm/i915: simplify testing for the global default context Then we hide the use of the global-default-context from callers who don't need to know how non-batch-related requests are implemented internally: [3/6] drm/i915: simplify allocation of driver-internal requests And get rid of the multiple references to the default context, one from each engine (but all pointing to the same structure). This allows the refcount and the number of references to match! [4/6] drm/i915: abolish separate per-engine default_context Finally, fix some incorrect failure paths and tidy up the corresponding teardown code: [5/6] drm/i915: tidy up initialisation failure paths (legacy) [6/6] drm/i915: tidy up initialisation failure paths (GEM & These should make subsequent reorganisation of other startup/teardown code easier and safer. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm/i915: tidy up initialisation failure paths (legacy)
1. Fix intel_cleanup_ring_buffer() to handle the error cleanup
case where the ringbuffer has been allocated but map-and-pin
failed. Unpin it iff it's previously been mapped-and-pinned.
2. Fix the error path in intel_init_ring_buffer(), which already
called intel_destroy_ringbuffer_obj(), but failed to free the
actual ringbuffer structure. Calling intel_ringbuffer_free()
instead does both in one go.
3. With the above change, intel_destroy_ringbuffer_obj() is only
called in one place (intel_ringbuffer_free()), so flatten it
into that function.
4. move low-level register accesses from intel_cleanup_ring_buffer()
(which calls intel_stop_ring_buffer(ring) which calls stop_ring())
down into stop_ring() itself), which is already doing low-level
register accesses. Then, intel_cleanup_ring_buffer() no longer
needs 'dev_priv'.
Signed-off-by: Dave Gordon
---
drivers/gpu/drm/i915/intel_ringbuffer.c | 47 +++--
1 file changed, 22 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index 339701d..cafbcd5 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -549,6 +549,8 @@ static bool stop_ring(struct intel_engine_cs *ring)
I915_WRITE_MODE(ring, _MASKED_BIT_DISABLE(STOP_RING));
}
+ WARN_ON(!IS_GEN2(ring->dev) && (I915_READ_MODE(ring) & MODE_IDLE) == 0);
+
return (I915_READ_HEAD(ring) & HEAD_ADDR) == 0;
}
@@ -2057,12 +2059,6 @@ int intel_pin_and_map_ringbuffer_obj(struct drm_device
*dev,
return 0;
}
-static void intel_destroy_ringbuffer_obj(struct intel_ringbuffer *ringbuf)
-{
- drm_gem_object_unreference(&ringbuf->obj->base);
- ringbuf->obj = NULL;
-}
-
static int intel_alloc_ringbuffer_obj(struct drm_device *dev,
struct intel_ringbuffer *ringbuf)
{
@@ -2125,11 +2121,14 @@ intel_engine_create_ringbuffer(struct intel_engine_cs
*engine, int size)
}
void
-intel_ringbuffer_free(struct intel_ringbuffer *ring)
+intel_ringbuffer_free(struct intel_ringbuffer *ringbuf)
{
- intel_destroy_ringbuffer_obj(ring);
- list_del(&ring->link);
- kfree(ring);
+ if (ringbuf->obj) {
+ drm_gem_object_unreference(&ringbuf->obj->base);
+ ringbuf->obj = NULL;
+ }
+ list_del(&ringbuf->link);
+ kfree(ringbuf);
}
static int intel_init_ring_buffer(struct drm_device *dev,
@@ -2157,6 +2156,13 @@ static int intel_init_ring_buffer(struct drm_device *dev,
}
ring->buffer = ringbuf;
+ ret = intel_pin_and_map_ringbuffer_obj(dev, ringbuf);
+ if (ret) {
+ DRM_ERROR("Failed to pin and map ringbuffer %s: %d\n",
+ ring->name, ret);
+ goto error;
+ }
+
if (I915_NEED_GFX_HWS(dev)) {
ret = init_status_page(ring);
if (ret)
@@ -2168,14 +2174,6 @@ static int intel_init_ring_buffer(struct drm_device *dev,
goto error;
}
- ret = intel_pin_and_map_ringbuffer_obj(dev, ringbuf);
- if (ret) {
- DRM_ERROR("Failed to pin and map ringbuffer %s: %d\n",
- ring->name, ret);
- intel_destroy_ringbuffer_obj(ringbuf);
- goto error;
- }
-
ret = i915_cmd_parser_init_ring(ring);
if (ret)
goto error;
@@ -2189,19 +2187,18 @@ error:
void intel_cleanup_ring_buffer(struct intel_engine_cs *ring)
{
- struct drm_i915_private *dev_priv;
+ struct intel_ringbuffer *ringbuf;
if (!intel_ring_initialized(ring))
return;
- dev_priv = to_i915(ring->dev);
-
- if (ring->buffer) {
+ ringbuf = ring->buffer;
+ if (ringbuf) {
intel_stop_ring_buffer(ring);
- WARN_ON(!IS_GEN2(ring->dev) && (I915_READ_MODE(ring) &
MODE_IDLE) == 0);
- intel_unpin_ringbuffer_obj(ring->buffer);
- intel_ringbuffer_free(ring->buffer);
+ if (ringbuf->virtual_start)
+ intel_unpin_ringbuffer_obj(ringbuf);
+ intel_ringbuffer_free(ringbuf);
ring->buffer = NULL;
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/6] drm/i915: simplify allocation of driver-internal requests
There are a number of places where the driver needs a request, but isn't
working on behalf of any specific user or in a specific context. For
such requests, we associate them with the default context for the engine
that the request will be submitted to.
This patch provides a shorthand for doing such request allocations and
changes all such calls to use the new function.
Signed-off-by: Dave Gordon
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_gem.c | 36
drivers/gpu/drm/i915/intel_display.c | 6 --
drivers/gpu/drm/i915/intel_overlay.c | 24
4 files changed, 46 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 666d07c..4955db9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2270,6 +2270,8 @@ struct drm_i915_gem_request {
int i915_gem_request_alloc(struct intel_engine_cs *ring,
struct intel_context *ctx,
struct drm_i915_gem_request **req_out);
+struct drm_i915_gem_request * __must_check
+ i915_gem_request_alloc_anon(struct intel_engine_cs *ring);
void i915_gem_request_cancel(struct drm_i915_gem_request *req);
void i915_gem_request_free(struct kref *req_ref);
int i915_gem_request_add_to_client(struct drm_i915_gem_request *req,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index be1f984..9f9c0c0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2751,6 +2751,21 @@ err:
return ret;
}
+/*
+ * Allocate a request associated with the default context for the given
+ * ring. This can be used where the driver needs a request for internal
+ * purposes not directly related to a user batch submission.
+ */
+struct drm_i915_gem_request *
+i915_gem_request_alloc_anon(struct intel_engine_cs *ring)
+{
+ struct drm_i915_gem_request *req;
+ int err;
+
+ err = i915_gem_request_alloc(ring, ring->default_context, &req);
+ return err ? ERR_PTR(err) : req;
+}
+
void i915_gem_request_cancel(struct drm_i915_gem_request *req)
{
intel_ring_reserved_space_cancel(req->ringbuf);
@@ -3168,9 +3183,13 @@ __i915_gem_object_sync(struct drm_i915_gem_object *obj,
return 0;
if (*to_req == NULL) {
- ret = i915_gem_request_alloc(to, to->default_context,
to_req);
- if (ret)
- return ret;
+ struct drm_i915_gem_request *req;
+
+ req = i915_gem_request_alloc_anon(to);
+ if (IS_ERR(req))
+ return PTR_ERR(req);
+
+ *to_req = req;
}
trace_i915_gem_ring_sync_to(*to_req, from, from_req);
@@ -3370,9 +3389,9 @@ int i915_gpu_idle(struct drm_device *dev)
if (!i915.enable_execlists) {
struct drm_i915_gem_request *req;
- ret = i915_gem_request_alloc(ring,
ring->default_context, &req);
- if (ret)
- return ret;
+ req = i915_gem_request_alloc_anon(ring);
+ if (IS_ERR(req))
+ return PTR_ERR(req);
ret = i915_switch_context(req);
if (ret) {
@@ -4867,8 +4886,9 @@ i915_gem_init_hw(struct drm_device *dev)
for_each_ring(ring, dev_priv, i) {
struct drm_i915_gem_request *req;
- ret = i915_gem_request_alloc(ring, ring->default_context, &req);
- if (ret) {
+ req = i915_gem_request_alloc_anon(ring);
+ if (IS_ERR(req)) {
+ ret = PTR_ERR(req);
i915_gem_cleanup_ringbuffer(dev);
goto out;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index abd2d29..5716f4a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11662,9 +11662,11 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
obj->last_write_req);
} else {
if (!request) {
- ret = i915_gem_request_alloc(ring,
ring->default_context, &request);
- if (ret)
+ request = i915_gem_request_alloc_anon(ring);
+ if (IS_ERR(request)) {
+ ret = PTR_ERR(request);
goto cleanup_unpin;
+ }
}
ret = dev_priv->display.queue_flip(dev, crtc, fb, obj, request,
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i9
Re: [Intel-gfx] [PATCH i-g-t 1/3] lib/igt_kms migrate existing documentation to header file.
On Mon, Dec 21, 2015 at 01:07:23PM +0200, Marius Vlad wrote:
> Signed-off-by: Marius Vlad
Hm, why that? Given that this is against the usual style in igt this needs
some justification, not an empty commit message.
Thanks, Daniel
> ---
> lib/igt_kms.c | 321 +-
> lib/igt_kms.h | 486
> +-
> 2 files changed, 418 insertions(+), 389 deletions(-)
>
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 5d5a95c..3dc559d 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -88,23 +88,7 @@ static void update_edid_csum(unsigned char *edid)
> #define EDID_NAME base_edid
> #include "igt_edid_template.h"
>
> -/**
> - * igt_kms_get_base_edid:
> - *
> - * Get the base edid block, which includes the following modes:
> - *
> - * - 1920x1080 60Hz
> - * - 1280x720 60Hz
> - * - 1024x768 60Hz
> - * - 800x600 60Hz
> - * - 640x480 60Hz
> - *
> - * This can be extended with further features using functions such as
> - * #kmstest_edid_add_3d.
> - *
> - * Returns: a basic edid block
> - */
> -const unsigned char* igt_kms_get_base_edid(void)
> +const unsigned char *igt_kms_get_base_edid(void)
> {
> update_edid_csum(base_edid);
>
> @@ -128,59 +112,13 @@ const unsigned char* igt_kms_get_base_edid(void)
> #define EDID_NAME alt_edid
> #include "igt_edid_template.h"
>
> -/**
> - * igt_kms_get_alt_edid:
> - *
> - * Get an alternate edid block, which includes the following modes:
> - *
> - * - 1400x1050 60Hz
> - * - 1920x1080 60Hz
> - * - 1280x720 60Hz
> - * - 1024x768 60Hz
> - * - 800x600 60Hz
> - * - 640x480 60Hz
> - *
> - * This can be extended with further features using functions such as
> - * #kmstest_edid_add_3d.
> - *
> - * Returns: an alternate edid block
> - */
> -const unsigned char* igt_kms_get_alt_edid(void)
> +const unsigned char *igt_kms_get_alt_edid(void)
> {
> update_edid_csum(alt_edid);
>
> return alt_edid;
> }
>
> -/**
> - * SECTION:igt_kms
> - * @short_description: Kernel modesetting support library
> - * @title: KMS
> - * @include: igt.h
> - *
> - * This library provides support to enumerate and set modeset configurations.
> - *
> - * There are two parts in this library: First the low level helper function
> - * which directly build on top of raw ioctls or the interfaces provided by
> - * libdrm. Those functions all have a kmstest_ prefix.
> - *
> - * The second part is a high-level library to manage modeset configurations
> - * which abstracts away some of the low-level details like the difference
> - * between legacy and universal plane support for setting cursors or in the
> - * future the difference between legacy and atomic commit. These high-level
> - * functions have all igt_ prefixes. This part is still very much work in
> - * progress and so also lacks a bit documentation for the individual
> functions.
> - *
> - * Note that this library's header pulls in the [i-g-t
> framebuffer](intel-gpu-tools-i-g-t-framebuffer.html)
> - * library as a dependency.
> - */
> -
> -/**
> - * kmstest_pipe_name:
> - * @pipe: display pipe
> - *
> - * Returns: String represnting @pipe, e.g. "A".
> - */
> const char *kmstest_pipe_name(enum pipe pipe)
> {
> const char *str[] = { "A", "B", "C" };
> @@ -191,12 +129,6 @@ const char *kmstest_pipe_name(enum pipe pipe)
> return str[pipe];
> }
>
> -/**
> - * kmstest_plane_name:
> - * @plane: display plane
> - *
> - * Returns: String represnting @pipe, e.g. "plane1".
> - */
> const char *kmstest_plane_name(enum igt_plane plane)
> {
> static const char *names[] = {
> @@ -235,12 +167,6 @@ static const char *mode_stereo_name(const
> drmModeModeInfo *mode)
> }
> }
>
> -/**
> - * kmstest_dump_mode:
> - * @mode: libdrm mode structure
> - *
> - * Prints @mode to stdout in a huma-readable form.
> - */
> void kmstest_dump_mode(drmModeModeInfo *mode)
> {
> const char *stereo = mode_stereo_name(mode);
> @@ -256,14 +182,6 @@ void kmstest_dump_mode(drmModeModeInfo *mode)
>stereo ? stereo : "", stereo ? ")" : "");
> }
>
> -/**
> - * kmstest_get_pipe_from_crtc_id:
> - * @fd: DRM fd
> - * @crtc_id: DRM CRTC id
> - *
> - * Returns: The pipe number for the given DRM CRTC @crtc_id. This maps
> directly
> - * to an enum pipe value used in other helper functions.
> - */
> int kmstest_get_pipe_from_crtc_id(int fd, int crtc_id)
> {
> struct drm_i915_get_pipe_from_crtc_id pfci;
> @@ -317,11 +235,6 @@ err:
>
> static unsigned long orig_vt_mode = -1UL;
>
> -/**
> - * kmstest_restore_vt_mode:
> - *
> - * Restore the VT mode in use before #kmstest_set_vt_graphics_mode was
> called.
> - */
> void kmstest_restore_vt_mode(void)
> {
> long ret;
> @@ -335,16 +248,6 @@ void kmstest_restore_vt_mode(void)
> }
> }
>
> -/**
> - * kmstest_set_vt_graphics_mode:
> - *
> - * Sets the controlling VT (if available) into graphics/raw mode and installs
> - * an igt exit handler to set the VT back t
Re: [Intel-gfx] [PATCH] drm/i915: Acquire RPM wakeref for KMS atomic commit
On Mon, Dec 21, 2015 at 05:02:08PM +0100, Daniel Vetter wrote: > On Sat, Dec 19, 2015 at 09:58:43AM +, Chris Wilson wrote: > > Once all the preparations are complete, we are ready to write the > > modesetting to the hardware. During this phase, we will be making lots > > of HW register access, so take a top level wakeref to prevent an > > unwarranted rpm suspend cycle mid-commit. Lower level functions should > > be waking the individual power wells as required. > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93439 > > Signed-off-by: Chris Wilson > > Cc: Imre Deak > > The original idea here was that doing this will paper over bugs in our rpm > refcounting. There's also the problem that for modeset stuff we have all > the power wells still to take care of. > > For the referenced bug we should add a power domain check in the get hw > state function instead, which is what we've been doing with all the other > similar hw state readout functions too. Agreed that there is another bug, but in the long term, we do want a "prolonged" wakeref here. In the next evolution of the wakeref assertions, we should be able to differentiate between the two (i.e. when we have fine grained wakerefs around the hw access, we need to assert we hold one of that type in the mmio accessor, rather than the prolonged version). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Acquire RPM wakeref for KMS atomic commit
On Mon, Dec 21, 2015 at 04:14:53PM +, Chris Wilson wrote: > On Mon, Dec 21, 2015 at 05:02:08PM +0100, Daniel Vetter wrote: > > On Sat, Dec 19, 2015 at 09:58:43AM +, Chris Wilson wrote: > > > Once all the preparations are complete, we are ready to write the > > > modesetting to the hardware. During this phase, we will be making lots > > > of HW register access, so take a top level wakeref to prevent an > > > unwarranted rpm suspend cycle mid-commit. Lower level functions should > > > be waking the individual power wells as required. > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93439 > > > Signed-off-by: Chris Wilson > > > Cc: Imre Deak > > > > The original idea here was that doing this will paper over bugs in our rpm > > refcounting. There's also the problem that for modeset stuff we have all > > the power wells still to take care of. > > > > For the referenced bug we should add a power domain check in the get hw > > state function instead, which is what we've been doing with all the other > > similar hw state readout functions too. > > Agreed that there is another bug, but in the long term, we do want a > "prolonged" wakeref here. In the next evolution of the wakeref assertions, > we should be able to differentiate between the two (i.e. when we have > fine grained wakerefs around the hw access, we need to assert we hold one > of that type in the mmio accessor, rather than the prolonged version). Why? If we enforce that I fear we lose implicit coverage. Currently if you touch any piece of modeset hw and don't have the corresponding long-time rpm/power well ref there's a good chance something will spot this. If we have a short-term rpm reference for everything we won't noticed these problems around the long-term rpm references any more. Imo the only thing short-term references are useful for is lockdep annotations to detect deadlocks, since lockdep requires that we drop a lock in the same process again. Long-term ones would simply do a might_lock in the get function to annotate the deadlock with rpm resume functions. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Acquire RPM wakeref for KMS atomic commit
On Mon, Dec 21, 2015 at 05:28:16PM +0100, Daniel Vetter wrote: > On Mon, Dec 21, 2015 at 04:14:53PM +, Chris Wilson wrote: > > On Mon, Dec 21, 2015 at 05:02:08PM +0100, Daniel Vetter wrote: > > > On Sat, Dec 19, 2015 at 09:58:43AM +, Chris Wilson wrote: > > > > Once all the preparations are complete, we are ready to write the > > > > modesetting to the hardware. During this phase, we will be making lots > > > > of HW register access, so take a top level wakeref to prevent an > > > > unwarranted rpm suspend cycle mid-commit. Lower level functions should > > > > be waking the individual power wells as required. > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93439 > > > > Signed-off-by: Chris Wilson > > > > Cc: Imre Deak > > > > > > The original idea here was that doing this will paper over bugs in our rpm > > > refcounting. There's also the problem that for modeset stuff we have all > > > the power wells still to take care of. > > > > > > For the referenced bug we should add a power domain check in the get hw > > > state function instead, which is what we've been doing with all the other > > > similar hw state readout functions too. > > > > Agreed that there is another bug, but in the long term, we do want a > > "prolonged" wakeref here. In the next evolution of the wakeref assertions, > > we should be able to differentiate between the two (i.e. when we have > > fine grained wakerefs around the hw access, we need to assert we hold one > > of that type in the mmio accessor, rather than the prolonged version). > > Why? If we enforce that I fear we lose implicit coverage. Currently if you > touch any piece of modeset hw and don't have the corresponding long-time > rpm/power well ref there's a good chance something will spot this. If we > have a short-term rpm reference for everything we won't noticed these > problems around the long-term rpm references any more. The theory being that when we get autosuspend on the order of say a hundred microseconds, we start to run into the real possibility of an rpm cycle mid update. > Imo the only thing short-term references are useful for is lockdep > annotations to detect deadlocks, since lockdep requires that we drop a > lock in the same process again. Long-term ones would simply do a > might_lock in the get function to annotate the deadlock with rpm resume > functions. I'm thinking of a world where suspend-resume time are on the order of microseconds and the rpm suspend interval not much greater. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: edp resume/On time optimization.
Thanks Daniel. Will push today with proper comment.
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, December 21, 2015 7:58 AM
To: Kumar, Abhay
Cc: Intel-gfx@lists.freedesktop.org; Syrjala, Ville; Paulo Zanoni
Subject: Re: [Intel-gfx] [PATCH] drm/i915: edp resume/On time optimization.
On Mon, Dec 21, 2015 at 05:33:41AM +, Kumar, Abhay wrote:
> Changed the implementation using boottime and removed jiffies. Please review
> and let us know if this is close.
Comments like these should be part of the patch submission itself, including a
note about which reviewer made the suggestion and adding everyone who commented
to the cc list. So something like this at the
bottom:
v2:
- Change (Ville).
- Use boootime instead of jiffies (Ville).
Cc: Ville (full mail address here).
Singed-off-by: ...
Without either the in-patch changelog or the cc it's much harder for reviewers
to follow along, especially when they're commenting on 10+ patch series at the
same time.
Please resubmit with that added.
Thanks, Daniel
>
> -Original Message-
> From: Kumar, Abhay
> Sent: Friday, December 18, 2015 11:55 AM
> To: Intel-gfx@lists.freedesktop.org
> Cc: Kumar, Abhay
> Subject: [PATCH] drm/i915: edp resume/On time optimization.
>
> From: Abhay Kumar
>
> Make resume/on codepath not to wait for panel_power_cycle_delay(t11_t12) if
> this time is already spent in suspend/poweron time.
>
> Change-Id: Ied0f10f82776af8e6e8ff561bb4e5c0ce1dad4b3
> Signed-off-by: Abhay Kumar
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 3 +++
> drivers/gpu/drm/i915/intel_dp.c | 22 ++
> drivers/gpu/drm/i915/intel_drv.h | 2 +-
> 3 files changed, 18 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index cbabcb4..fe99d72 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2347,6 +2347,9 @@ static void intel_ddi_post_disable(struct intel_encoder
> *intel_encoder)
> intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_OFF);
> intel_edp_panel_vdd_on(intel_dp);
> intel_edp_panel_off(intel_dp);
> +
> + /* storing panel power off time */
> + intel_dp->panel_power_off_time =
> +ktime_get_with_offset(TK_OFFS_BOOT);
> }
>
> if (IS_SKYLAKE(dev))
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c index acda70e..845944d 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -38,7 +38,6 @@
> #include "intel_drv.h"
> #include
> #include "i915_drv.h"
> -
> #define DP_LINK_CHECK_TIMEOUT(10 * 1000)
>
> /* Compliance test status bits */
> @@ -1654,13 +1653,22 @@ static void wait_panel_off(struct intel_dp
> *intel_dp)
>
> static void wait_panel_power_cycle(struct intel_dp *intel_dp) {
> + ktime_t panel_power_on_time;
> + u32 panel_power_off_duration;
> +
> DRM_DEBUG_KMS("Wait for panel power cycle\n");
>
> - /* When we disable the VDD override bit last we have to do the manual
> - * wait. */
> - wait_remaining_ms_from_jiffies(intel_dp->last_power_cycle,
> -intel_dp->panel_power_cycle_delay);
> +/* take the diffrence of currrent time and panel power off time
> + and then make panel wait for t11_t12 if needed */
> + panel_power_on_time = ktime_get_with_offset(TK_OFFS_BOOT);
> + panel_power_off_duration = (panel_power_on_time.tv64 -
> intel_dp->panel_power_off_time.tv64);
> + panel_power_off_duration = panel_power_off_duration / 100;
>
> + /* When we disable the VDD override bit last we have to do the manual
> + * wait */
> + if (panel_power_off_duration < intel_dp->panel_power_cycle_delay)
> + wait_remaining_ms_from_jiffies(jiffies,
> +(intel_dp->panel_power_cycle_delay -
> +panel_power_off_duration));
> wait_panel_status(intel_dp, IDLE_CYCLE_MASK, IDLE_CYCLE_VALUE); }
>
> @@ -1811,7 +1819,7 @@ static void edp_panel_vdd_off_sync(struct intel_dp
> *intel_dp)
> I915_READ(pp_stat_reg), I915_READ(pp_ctrl_reg));
>
> if ((pp & POWER_TARGET_ON) == 0)
> - intel_dp->last_power_cycle = jiffies;
> + intel_dp->panel_power_off_time =
> +ktime_get_with_offset(TK_OFFS_BOOT);
>
> power_domain = intel_display_port_power_domain(intel_encoder);
> intel_display_power_put(dev_priv, power_domain); @@ -1960,7 +1968,6 @@
> static void edp_panel_off(struct intel_dp *intel_dp)
> I915_WRITE(pp_ctrl_reg, pp);
> POSTING_READ(pp_ctrl_reg);
>
> - intel_dp->last_power_cycle = jiffies;
> wait_panel_off(intel_dp);
>
> /* We got a reference when we enabled the VDD. */ @@ -5196,7 +5203,6
> @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
> drm_c
[Intel-gfx] ✗ warning: Fi.CI.BAT
== Summary == Built on 78deeec98b10627fe2050ce8ebfa2ea2d5b9e6c7 drm-intel-nightly: 2015y-12m-21d-16h-03m-57s UTC integration manifest Test gem_mmap_gtt: Subgroup basic-small-bo: dmesg-warn -> PASS (bdw-nuci7) Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (skl-i7k-2) Test kms_flip: Subgroup basic-flip-vs-modeset: pass -> DMESG-WARN (skl-i5k-2) pass -> DMESG-WARN (hsw-xps12) dmesg-warn -> PASS (hsw-brixbox) skip -> PASS (bdw-nuci7) pass -> DMESG-WARN (ilk-hp8440p) Subgroup basic-plain-flip: skip -> PASS (bdw-nuci7) pass -> DMESG-WARN (byt-nuc) Test kms_pipe_crc_basic: Subgroup read-crc-pipe-a: pass -> DMESG-WARN (snb-x220t) skip -> PASS (bdw-nuci7) dmesg-warn -> PASS (byt-nuc) Subgroup read-crc-pipe-a-frame-sequence: skip -> PASS (bdw-nuci7) pass -> DMESG-WARN (byt-nuc) Subgroup read-crc-pipe-b: dmesg-warn -> PASS (skl-i5k-2) dmesg-warn -> PASS (hsw-xps12) pass -> DMESG-WARN (snb-dellxps) skip -> PASS (bdw-nuci7) Subgroup read-crc-pipe-b-frame-sequence: pass -> DMESG-WARN (bdw-ultra) skip -> PASS (bdw-nuci7) pass -> DMESG-WARN (byt-nuc) Subgroup read-crc-pipe-c: skip -> PASS (bdw-nuci7) Test kms_setmode: Subgroup basic-clone-single-crtc: dmesg-warn -> PASS (snb-dellxps) Test pm_rpm: Subgroup basic-pci-d3-state: skip -> PASS (bdw-nuci7) Subgroup basic-rte: skip -> PASS (bdw-nuci7) dmesg-warn -> PASS (bdw-ultra) bdw-nuci7total:132 pass:122 dwarn:1 dfail:0 fail:0 skip:9 bdw-ultratotal:132 pass:124 dwarn:2 dfail:0 fail:0 skip:6 byt-nuc total:135 pass:117 dwarn:5 dfail:0 fail:0 skip:13 hsw-brixbox total:135 pass:127 dwarn:1 dfail:0 fail:0 skip:7 hsw-gt2 total:135 pass:130 dwarn:1 dfail:0 fail:0 skip:4 hsw-xps12total:132 pass:125 dwarn:3 dfail:0 fail:0 skip:4 ilk-hp8440p total:135 pass:99 dwarn:1 dfail:0 fail:0 skip:35 ivb-t430stotal:135 pass:127 dwarn:2 dfail:0 fail:0 skip:6 skl-i5k-2total:135 pass:122 dwarn:5 dfail:0 fail:0 skip:8 skl-i7k-2total:135 pass:123 dwarn:4 dfail:0 fail:0 skip:8 snb-dellxps total:135 pass:121 dwarn:2 dfail:0 fail:0 skip:12 snb-x220ttotal:135 pass:121 dwarn:2 dfail:0 fail:1 skip:11 Results at /archive/results/CI_IGT_test/Patchwork_781/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ failure: Fi.CI.BAT
== Summary == HEAD is now at 78deeec drm-intel-nightly: 2015y-12m-21d-16h-03m-57s UTC integration manifest Applying: drm/i915/bdw+: Do not emit user interrupts when not needed Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.h M drivers/gpu/drm/i915/intel_lrc.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_lrc.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_lrc.c Auto-merging drivers/gpu/drm/i915/i915_drv.h Patch failed at 0001 drm/i915/bdw+: Do not emit user interrupts when not needed ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Acquire RPM wakeref for KMS atomic commit
On Mon, Dec 21, 2015 at 04:37:41PM +, Chris Wilson wrote: > On Mon, Dec 21, 2015 at 05:28:16PM +0100, Daniel Vetter wrote: > > On Mon, Dec 21, 2015 at 04:14:53PM +, Chris Wilson wrote: > > > On Mon, Dec 21, 2015 at 05:02:08PM +0100, Daniel Vetter wrote: > > > > On Sat, Dec 19, 2015 at 09:58:43AM +, Chris Wilson wrote: > > > > > Once all the preparations are complete, we are ready to write the > > > > > modesetting to the hardware. During this phase, we will be making lots > > > > > of HW register access, so take a top level wakeref to prevent an > > > > > unwarranted rpm suspend cycle mid-commit. Lower level functions should > > > > > be waking the individual power wells as required. > > > > > > > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93439 > > > > > Signed-off-by: Chris Wilson > > > > > Cc: Imre Deak > > > > > > > > The original idea here was that doing this will paper over bugs in our > > > > rpm > > > > refcounting. There's also the problem that for modeset stuff we have all > > > > the power wells still to take care of. > > > > > > > > For the referenced bug we should add a power domain check in the get hw > > > > state function instead, which is what we've been doing with all the > > > > other > > > > similar hw state readout functions too. > > > > > > Agreed that there is another bug, but in the long term, we do want a > > > "prolonged" wakeref here. In the next evolution of the wakeref assertions, > > > we should be able to differentiate between the two (i.e. when we have > > > fine grained wakerefs around the hw access, we need to assert we hold one > > > of that type in the mmio accessor, rather than the prolonged version). > > > > Why? If we enforce that I fear we lose implicit coverage. Currently if you > > touch any piece of modeset hw and don't have the corresponding long-time > > rpm/power well ref there's a good chance something will spot this. If we > > have a short-term rpm reference for everything we won't noticed these > > problems around the long-term rpm references any more. > > The theory being that when we get autosuspend on the order of say a > hundred microseconds, we start to run into the real possibility of an > rpm cycle mid update. > > > Imo the only thing short-term references are useful for is lockdep > > annotations to detect deadlocks, since lockdep requires that we drop a > > lock in the same process again. Long-term ones would simply do a > > might_lock in the get function to annotate the deadlock with rpm resume > > functions. > > I'm thinking of a world where suspend-resume time are on the order of > microseconds and the rpm suspend interval not much greater. That's why we need a bit of hystersis to avoid that. Statistics rule of thumb is to only suspend once you've spent about as much time idle as it would take you to suspend/resume. And since we do a few global updates we actually acquire new power wells before old ones, so as long as you don't do 2 ioctls to change configurations it's impossible to accidentally suspend in between. The rest is just appropriately tuning defaults (and still setting it to 0 in igt for maximum nastiness). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm, i915: Fix pointer size cast
From: Borislav Petkov
gcc complains on 32-bit like this:
drivers/gpu/drm/i915/intel_display.c: In function ‘intel_plane_obj_offset’:
drivers/gpu/drm/i915/intel_display.c:2954:11: warning: cast to pointer from \
integer of different size [-Wint-to-pointer-cast]
offset = (unsigned char *)vma->node.start;
^
because vma->node.start is u64 but a pointer on 32-bit is 4 bytes.
Do the calculations with an unsigned long directly and save us the
casts.
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: David Airlie
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Borislav Petkov
---
drivers/gpu/drm/i915/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 62211abe4922..640cb7c9b7f3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2941,7 +2941,7 @@ unsigned long intel_plane_obj_offset(struct intel_plane
*intel_plane,
{
const struct i915_ggtt_view *view = &i915_ggtt_view_normal;
struct i915_vma *vma;
- unsigned char *offset;
+ unsigned long offset;
if (intel_rotation_90_or_270(intel_plane->base.state->rotation))
view = &i915_ggtt_view_rotated;
@@ -2951,14 +2951,14 @@ unsigned long intel_plane_obj_offset(struct intel_plane
*intel_plane,
view->type))
return -1;
- offset = (unsigned char *)vma->node.start;
+ offset = vma->node.start;
if (plane == 1) {
offset += vma->ggtt_view.rotation_info.uv_start_page *
PAGE_SIZE;
}
- return (unsigned long)offset;
+ return offset;
}
static void skl_detach_scaler(struct intel_crtc *intel_crtc, int id)
--
2.3.5
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm, i915: Fix pointer size cast
On Mon, Dec 21, 2015 at 07:53:59PM +0100, Borislav Petkov wrote:
> From: Borislav Petkov
>
> gcc complains on 32-bit like this:
>
> drivers/gpu/drm/i915/intel_display.c: In function ‘intel_plane_obj_offset’:
> drivers/gpu/drm/i915/intel_display.c:2954:11: warning: cast to pointer from
> \
> integer of different size [-Wint-to-pointer-cast]
> offset = (unsigned char *)vma->node.start;
> ^
>
> because vma->node.start is u64 but a pointer on 32-bit is 4 bytes.
>
> Do the calculations with an unsigned long directly and save us the
> casts.
>
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: David Airlie
> Cc: intel-gfx@lists.freedesktop.org
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Signed-off-by: Borislav Petkov
This has been fixed already in
commit 44eb0cb9620c6a53ec8e7073262e2af8079b727f
Author: Mika Kuoppala
Date: Fri Oct 30 13:26:15 2015 +0200
drm/i915: Avoid pointer arithmetic in calculating plane surface offset
Cheers,
Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 62211abe4922..640cb7c9b7f3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2941,7 +2941,7 @@ unsigned long intel_plane_obj_offset(struct intel_plane
> *intel_plane,
> {
> const struct i915_ggtt_view *view = &i915_ggtt_view_normal;
> struct i915_vma *vma;
> - unsigned char *offset;
> + unsigned long offset;
>
> if (intel_rotation_90_or_270(intel_plane->base.state->rotation))
> view = &i915_ggtt_view_rotated;
> @@ -2951,14 +2951,14 @@ unsigned long intel_plane_obj_offset(struct
> intel_plane *intel_plane,
> view->type))
> return -1;
>
> - offset = (unsigned char *)vma->node.start;
> + offset = vma->node.start;
>
> if (plane == 1) {
> offset += vma->ggtt_view.rotation_info.uv_start_page *
> PAGE_SIZE;
> }
>
> - return (unsigned long)offset;
> + return offset;
> }
>
> static void skl_detach_scaler(struct intel_crtc *intel_crtc, int id)
> --
> 2.3.5
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Drop ilk_wm_max_level()
Storing the max_level in dev_priv as VLV/CHV already do is a bit simpler
than calling this standalone function, especially since some of the
callsites need to special-case the call to check whether they're running
on VLV/CHV.
This function was further confusing since it wasn't actually specific to
ILK-style platforms as its name implied (it was also used on Skylake and
would even be called on pre-ILK platforms via debugfs). Aside from this
function, our watermark programming across various platform-types
doesn't really have any overlap.
Note that we do change debugfs behavior slightly with this patch;
i915_*_wm_latency files will all now appear empty on pre-ILK platforms
rather than showing two watermark levels of 0.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_debugfs.c | 18 ++-
drivers/gpu/drm/i915/intel_pm.c | 44 +
2 files changed, 22 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0fc38bb..ae36656 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4445,14 +4445,7 @@ static void wm_latency_show(struct seq_file *m, const
uint16_t wm[8])
{
struct drm_device *dev = m->private;
int level;
- int num_levels;
-
- if (IS_CHERRYVIEW(dev))
- num_levels = 3;
- else if (IS_VALLEYVIEW(dev))
- num_levels = 1;
- else
- num_levels = ilk_wm_max_level(dev) + 1;
+ int num_levels = to_i915(dev)->wm.max_level + 1;
drm_modeset_lock_all(dev);
@@ -4560,18 +4553,11 @@ static ssize_t wm_latency_write(struct file *file,
const char __user *ubuf,
struct seq_file *m = file->private_data;
struct drm_device *dev = m->private;
uint16_t new[8] = { 0 };
- int num_levels;
+ int num_levels = to_i915(dev)->wm.max_level + 1;
int level;
int ret;
char tmp[32];
- if (IS_CHERRYVIEW(dev))
- num_levels = 3;
- else if (IS_VALLEYVIEW(dev))
- num_levels = 1;
- else
- num_levels = ilk_wm_max_level(dev) + 1;
-
if (len >= sizeof(tmp))
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index b076580..71d814c 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2027,7 +2027,7 @@ static void intel_read_wm_latency(struct drm_device *dev,
uint16_t wm[8])
if (IS_GEN9(dev)) {
uint32_t val;
int ret, i;
- int level, max_level = ilk_wm_max_level(dev);
+ int level, max_level = dev_priv->wm.max_level;
/* read the first set of memory latencies[0:3] */
val = 0; /* data0 to be programmed to 0 for first set */
@@ -2142,24 +2142,11 @@ static void intel_fixup_cur_wm_latency(struct
drm_device *dev, uint16_t wm[5])
wm[3] *= 2;
}
-int ilk_wm_max_level(const struct drm_device *dev)
-{
- /* how many WM levels are we expecting */
- if (INTEL_INFO(dev)->gen >= 9)
- return 7;
- else if (IS_HASWELL(dev) || IS_BROADWELL(dev))
- return 4;
- else if (INTEL_INFO(dev)->gen >= 6)
- return 3;
- else
- return 2;
-}
-
static void intel_print_wm_latency(struct drm_device *dev,
const char *name,
const uint16_t wm[8])
{
- int level, max_level = ilk_wm_max_level(dev);
+ int level, max_level = to_i915(dev)->wm.max_level;
for (level = 0; level <= max_level; level++) {
unsigned int latency = wm[level];
@@ -2188,7 +2175,7 @@ static void intel_print_wm_latency(struct drm_device *dev,
static bool ilk_increase_wm_latency(struct drm_i915_private *dev_priv,
uint16_t wm[5], uint16_t min)
{
- int level, max_level = ilk_wm_max_level(dev_priv->dev);
+ int level, max_level = dev_priv->wm.max_level;
if (wm[0] >= min)
return false;
@@ -2242,6 +2229,13 @@ static void ilk_setup_wm_latency(struct drm_device *dev)
if (IS_GEN6(dev))
snb_wm_latency_quirk(dev);
+
+ if (IS_HASWELL(dev) || IS_BROADWELL(dev))
+ dev_priv->wm.max_level = 4;
+ else if (INTEL_INFO(dev)->gen >= 6)
+ dev_priv->wm.max_level = 3;
+ else
+ dev_priv->wm.max_level = 2;
}
static void skl_setup_wm_latency(struct drm_device *dev)
@@ -2250,6 +2244,8 @@ static void skl_setup_wm_latency(struct drm_device *dev)
intel_read_wm_latency(dev, dev_priv->wm.skl_latency);
intel_print_wm_latency(dev, "Gen9 Plane", dev_priv->wm.skl_latency);
+
+ dev_priv->wm.max_level = 7;
}
/* Compute new watermarks for the pipe */
@@ -2265,7 +2261,7 @@ static in
[Intel-gfx] Wayland / EGL support
Hi all. Every couple of months, I try out the latest Enlightenment ( from git ), using Wayland and EGL. Using Intel graphics ( I've tried quite a few, including the latest i5 and i7 integrated chips ), there are some serious issues that look driver-related. I can now actually *start* a Wayland / EGL session, which is progress at least. However there are constant graphical glitches, full-screen flashing, particularly when I move the mouse, and lockups, kernel oopses, etc, etc. If I switch to Enlightenment's software renderer, things work remarkably well. Is anyone testing Wayland support yet? Is it supported? Is there anything special I should be doing ( environment variables )? Any minimum kernel / mesa version ( I'm bleeding-edge Gentoo anyway - 4.3 kernel, mesa-11.0.7, wayland-1.9 ). Thanks :) Dan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in:
drivers/gpu/drm/i915/intel_pm.c
between commit:
344df9809f45 ("drm/i915/skl: Disable coarse power gating up until F0")
from Linus' tree and commit:
06e668ac91c9 ("drm/i915: Apply broader WaRsDisableCoarsePowerGating for guc
also")
from the drm-intel tree.
I fixed it up (I just used the latter version) and can carry the fix as
necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
