Re: [Intel-gfx] [PATCH v3 2/6] drm/i915: update cursors asynchronously through atomic
On Wed, Jun 28, 2017 at 05:54:56PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> Add support to async updates of cursors by using the new atomic
> interface for that. Basically what this commit does is do what
> intel_legacy_cursor_update() did but through atomic.
>
> v3:
> - set correct vma to new state for cleanup
> - move size checks back to drivers (Ville Syrjälä)
>
> v2:
> - move fb setting to core and use new state (Eric Anholt)
>
> Cc: Daniel Vetter
> Signed-off-by: Gustavo Padovan
> ---
> drivers/gpu/drm/i915/intel_atomic_plane.c | 73 +++
> drivers/gpu/drm/i915/intel_display.c | 149
> +-
> 2 files changed, 97 insertions(+), 125 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index a40c82c..1737b8a 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -246,11 +246,84 @@ static void intel_plane_atomic_update(struct drm_plane
> *plane,
> }
> }
>
> +static int intel_plane_atomic_async_check(struct drm_plane *plane,
> + struct drm_plane_state *state)
> +{
> + struct drm_crtc *crtc = plane->state->crtc;
> + struct drm_crtc_state *crtc_state = crtc->state;
> +
> + if (plane->type != DRM_PLANE_TYPE_CURSOR)
> + return -EINVAL;
> +
> + /*
> + * When crtc is inactive or there is a modeset pending,
> + * wait for it to complete in the slowpath
> + */
> + if (!crtc_state->active || to_intel_crtc_state(crtc_state)->update_pipe)
> + return -EINVAL;
> +
> + /*
> + * If any parameters change that may affect watermarks,
> + * take the slowpath. Only changing fb or position should be
> + * in the fastpath.
> + */
> + if (plane->state->crtc != state->crtc ||
> + plane->state->src_w != state->src_w ||
> + plane->state->src_h != state->src_h ||
> + plane->state->crtc_w != state->crtc_w ||
> + plane->state->crtc_h != state->crtc_h ||
> + !plane->state->fb != !state->fb)
> + return -EINVAL;
If we ever expose async updates as an ATOMIC_IOCTL flag then we need to
improve this check a lot, and make it more robust. Otherwise we'll get
things wrong everytime we add a new property (like rotation).
-Daniel
> +
> + return 0;
> +}
> +
> +static void intel_plane_atomic_async_update(struct drm_plane *plane,
> + struct drm_plane_state *new_state)
> +{
> + struct intel_plane *intel_plane = to_intel_plane(plane);
> + struct drm_crtc *crtc = plane->state->crtc;
> + struct drm_framebuffer *old_fb;
> + struct i915_vma *old_vma;
> +
> + old_vma = to_intel_plane_state(plane->state)->vma;
> + old_fb = plane->state->fb;
> +
> + i915_gem_track_fb(intel_fb_obj(old_fb), intel_fb_obj(new_state->fb),
> + intel_plane->frontbuffer_bit);
> +
> + plane->state->src_x = new_state->src_x;
> + plane->state->src_y = new_state->src_y;
> + plane->state->crtc_x = new_state->crtc_x;
> + plane->state->crtc_y = new_state->crtc_y;
> + plane->state->fb = new_state->fb;
> + *to_intel_plane_state(plane->state) = *to_intel_plane_state(new_state);
> +
> + to_intel_plane_state(new_state)->vma = old_vma;
> + new_state->fb = old_fb;
> +
> + if (plane->state->visible) {
> + trace_intel_update_plane(plane, to_intel_crtc(crtc));
> + intel_plane->update_plane(plane,
> + to_intel_crtc_state(crtc->state),
> + to_intel_plane_state(plane->state));
> + } else {
> + trace_intel_disable_plane(plane, to_intel_crtc(crtc));
> + intel_plane->disable_plane(plane, crtc);
> + }
> +
> + mutex_lock(&plane->dev->struct_mutex);
> + intel_cleanup_plane_fb(plane, new_state);
> + mutex_unlock(&plane->dev->struct_mutex);
> +}
> +
> const struct drm_plane_helper_funcs intel_plane_helper_funcs = {
> .prepare_fb = intel_prepare_plane_fb,
> .cleanup_fb = intel_cleanup_plane_fb,
> .atomic_check = intel_plane_atomic_check,
> .atomic_update = intel_plane_atomic_update,
> + .atomic_async_check = intel_plane_atomic_async_check,
> + .atomic_async_update = intel_plane_atomic_async_update,
> };
>
> /**
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 636c64e..736301d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -13004,6 +13004,26 @@ static int intel_atomic_commit(struct drm_device
> *dev,
> struct drm_i915_private *dev_priv = to_i915(dev);
> int ret = 0;
>
> + /*
> + * The atomic async update fast path takes care
> + * of avoiding the vblank waits for simple cursor
>
Re: [Intel-gfx] [PATCH v3 1/6] drm/atomic: initial support for asynchronous plane update
On Wed, Jun 28, 2017 at 05:54:55PM -0300, Gustavo Padovan wrote:
> From: Gustavo Padovan
>
> In some cases, like cursor updates, it is interesting to update the
> plane in an asynchronous fashion to avoid big delays. The current queued
> update could be still waiting for a fence to signal and thus block any
> subsequent update until its scan out. In cases like this if we update the
> cursor synchronously through the atomic API it will cause significant
> delays that would even be noticed by the final user.
>
> This patch creates a fast path to jump ahead the current queued state and
> do single planes updates without going through all atomic steps in
> drm_atomic_helper_commit(). We take this path for legacy cursor updates.
>
> For now only single plane updates are supported, but we plan to support
> multiple planes updates and async PageFlips through this interface as well
> in the near future.
>
> v5:
> - improve comments (Eric Anholt)
>
> v4:
> - fix state->crtc NULL check (Archit Taneja)
>
> v3:
> - fix iteration on the wrong crtc state
> - put back code to forbid updates if there is a queued update for
> the same plane (Ville Syrjälä)
> - move size checks back to drivers (Ville Syrjälä)
> - move ASYNC_UPDATE flag addition to its own patch (Ville Syrjälä)
>
> v2:
> - allow updates even if there is a queued update for the same
> plane.
> - fixes on the documentation (Emil Velikov)
> - unconditionally call ->atomic_async_update (Emil Velikov)
> - check for ->atomic_async_update earlier (Daniel Vetter)
> - make ->atomic_async_check() the last step (Daniel Vetter)
> - add ASYNC_UPDATE flag (Eric Anholt)
> - update state in core after ->atomic_async_update (Eric Anholt)
> - update docs (Eric Anholt)
>
> Cc: Daniel Vetter
> Cc: Rob Clark
> Cc: Eric Anholt
> Signed-off-by: Gustavo Padovan
> Reviewed-by: Archit Taneja
> Acked-by: Eric Anholt
Ok I wanted to merge this, but found one more nit. The new
->atomic_async_commit/check hooks are imo driver interface functions (you
call the from the core drm_atomic.c), but you put the hooks into the
helper vtables. Can you pls move them into drm_plane_funcs instead?
The only reason this worked is because I accidentally left a
drm_plane_helper.h include in drm_atomic.c which shouldn't be there ...
Otherwise looks all good, and with that fix has my
Reviewed-by: Daniel Vetter
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_atomic.c | 70
>
> drivers/gpu/drm/drm_atomic_helper.c | 35
> include/drm/drm_atomic.h | 2 +
> include/drm/drm_atomic_helper.h | 2 +
> include/drm/drm_modeset_helper_vtables.h | 50 +++
> 5 files changed, 159 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index c0f336d..e406688 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -644,6 +644,73 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
> return 0;
> }
>
> +static bool drm_atomic_async_check(struct drm_atomic_state *state)
> +{
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
> + struct drm_crtc_commit *commit;
> + struct drm_plane *__plane, *plane = NULL;
> + struct drm_plane_state *__plane_state, *plane_state = NULL;
> + const struct drm_plane_helper_funcs *funcs;
> + int i, j, n_planes = 0;
> +
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + if (drm_atomic_crtc_needs_modeset(crtc_state))
> + return false;
> + }
> +
> + for_each_new_plane_in_state(state, __plane, __plane_state, i) {
> + n_planes++;
> + plane = __plane;
> + plane_state = __plane_state;
> + }
> +
> + /* FIXME: we support only single plane updates for now */
> + if (!plane || n_planes != 1)
> + return false;
> +
> + if (!plane_state->crtc)
> + return false;
> +
> + funcs = plane->helper_private;
> + if (!funcs->atomic_async_update)
> + return false;
> +
> + if (plane_state->fence)
> + return false;
> +
> + /*
> + * Don't do an async update if there is an outstanding commit modifying
> + * the plane. This prevents our async update's changes from getting
> + * overridden by a previous synchronous update's state.
> + */
> + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> + if (plane->crtc != crtc)
> + continue;
> +
> + spin_lock(&crtc->commit_lock);
> + commit = list_first_entry_or_null(&crtc->commit_list,
> + struct drm_crtc_commit,
> + commit_entry);
> + if (!commit) {
> +
Re: [Intel-gfx] [PATCH v3 1/6] drm/atomic: initial support for asynchronous plane update
On Fri, Jun 30, 2017 at 09:30:50AM +0200, Daniel Vetter wrote:
> On Wed, Jun 28, 2017 at 05:54:55PM -0300, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > In some cases, like cursor updates, it is interesting to update the
> > plane in an asynchronous fashion to avoid big delays. The current queued
> > update could be still waiting for a fence to signal and thus block any
> > subsequent update until its scan out. In cases like this if we update the
> > cursor synchronously through the atomic API it will cause significant
> > delays that would even be noticed by the final user.
> >
> > This patch creates a fast path to jump ahead the current queued state and
> > do single planes updates without going through all atomic steps in
> > drm_atomic_helper_commit(). We take this path for legacy cursor updates.
> >
> > For now only single plane updates are supported, but we plan to support
> > multiple planes updates and async PageFlips through this interface as well
> > in the near future.
> >
> > v5:
> > - improve comments (Eric Anholt)
> >
> > v4:
> > - fix state->crtc NULL check (Archit Taneja)
> >
> > v3:
> > - fix iteration on the wrong crtc state
> > - put back code to forbid updates if there is a queued update for
> > the same plane (Ville Syrjälä)
> > - move size checks back to drivers (Ville Syrjälä)
> > - move ASYNC_UPDATE flag addition to its own patch (Ville Syrjälä)
> >
> > v2:
> > - allow updates even if there is a queued update for the same
> > plane.
> > - fixes on the documentation (Emil Velikov)
> > - unconditionally call ->atomic_async_update (Emil Velikov)
> > - check for ->atomic_async_update earlier (Daniel Vetter)
> > - make ->atomic_async_check() the last step (Daniel Vetter)
> > - add ASYNC_UPDATE flag (Eric Anholt)
> > - update state in core after ->atomic_async_update (Eric Anholt)
> > - update docs (Eric Anholt)
> >
> > Cc: Daniel Vetter
> > Cc: Rob Clark
> > Cc: Eric Anholt
> > Signed-off-by: Gustavo Padovan
> > Reviewed-by: Archit Taneja
> > Acked-by: Eric Anholt
>
> Ok I wanted to merge this, but found one more nit. The new
> ->atomic_async_commit/check hooks are imo driver interface functions (you
> call the from the core drm_atomic.c), but you put the hooks into the
> helper vtables. Can you pls move them into drm_plane_funcs instead?
>
> The only reason this worked is because I accidentally left a
> drm_plane_helper.h include in drm_atomic.c which shouldn't be there ...
Otoh this does all feel supremely like helper code, so maybe the better
option would be to move all the code you're adding here into
drm_atomic_helper.c, (with function prefixes changed). You already call
async_commit from the helper's atomic_commit, and doing the same for the
check side would make things more symmetric.
I think that way round would be even cleaner separation between core code
and helpers.
-Daniel
>
> Otherwise looks all good, and with that fix has my
>
> Reviewed-by: Daniel Vetter
>
> Thanks, Daniel
>
> > ---
> > drivers/gpu/drm/drm_atomic.c | 70
> >
> > drivers/gpu/drm/drm_atomic_helper.c | 35
> > include/drm/drm_atomic.h | 2 +
> > include/drm/drm_atomic_helper.h | 2 +
> > include/drm/drm_modeset_helper_vtables.h | 50 +++
> > 5 files changed, 159 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index c0f336d..e406688 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -644,6 +644,73 @@ static int drm_atomic_crtc_check(struct drm_crtc *crtc,
> > return 0;
> > }
> >
> > +static bool drm_atomic_async_check(struct drm_atomic_state *state)
> > +{
> > + struct drm_crtc *crtc;
> > + struct drm_crtc_state *crtc_state;
> > + struct drm_crtc_commit *commit;
> > + struct drm_plane *__plane, *plane = NULL;
> > + struct drm_plane_state *__plane_state, *plane_state = NULL;
> > + const struct drm_plane_helper_funcs *funcs;
> > + int i, j, n_planes = 0;
> > +
> > + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> > + if (drm_atomic_crtc_needs_modeset(crtc_state))
> > + return false;
> > + }
> > +
> > + for_each_new_plane_in_state(state, __plane, __plane_state, i) {
> > + n_planes++;
> > + plane = __plane;
> > + plane_state = __plane_state;
> > + }
> > +
> > + /* FIXME: we support only single plane updates for now */
> > + if (!plane || n_planes != 1)
> > + return false;
> > +
> > + if (!plane_state->crtc)
> > + return false;
> > +
> > + funcs = plane->helper_private;
> > + if (!funcs->atomic_async_update)
> > + return false;
> > +
> > + if (plane_state->fence)
> > + return false;
> > +
> > + /*
> > +* Don't do an async update if the
Re: [Intel-gfx] [PATCH v2] drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts
On Thu, Jun 29, 2017 at 01:41:16PM -0700, Manasi Navare wrote:
> Thanks for the review comments. Please find my responses below:
>
> On Thu, Jun 29, 2017 at 11:24:48PM +0300, Ville Syrjälä wrote:
> > On Wed, Jun 28, 2017 at 05:14:31PM -0700, Manasi Navare wrote:
> > > This patch fixes the DP AUX CH timeouts observed during CI IGT
> > > tests thus fixing the CI failures. This is done by adding a
> > > quirk for a particular PCI device that requires the panel power
> > > cycle delay (T12) to be 300msecs more than the minimum value
> > > specified in the eDP spec. So a quirk is implemented for that
> > > specific PCI device.
> > >
> > > v2:
> > > * Change the function and variable names to from PPS_T12_
> > > to _T12 since it is a T12 delay (Clint)
> > >
> > > Fixes: FDO #101144 #101515 #101154 #101167
> > > Cc: Ville Syrjala
> > > Cc: Cinton Taylor
> > > Signed-off-by: Manasi Navare
> > > ---
> > > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > > drivers/gpu/drm/i915/intel_display.c | 12
> > > drivers/gpu/drm/i915/intel_dp.c | 12
> > > 3 files changed, 25 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 427d10c..4327c8a 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1168,6 +1168,7 @@ enum intel_sbi_destination {
> > > #define QUIRK_INVERT_BRIGHTNESS (1<<2)
> > > #define QUIRK_BACKLIGHT_PRESENT (1<<3)
> > > #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> > > +#define QUIRK_INCREASE_T12_DELAY (1<<6)
> > >
> > > struct intel_fbdev;
> > > struct intel_fbc_work;
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 4e03ca6..37beb62 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -14765,6 +14765,15 @@ static void quirk_backlight_present(struct
> > > drm_device *dev)
> > > DRM_INFO("applying backlight present quirk\n");
> > > }
> > >
> > > +/* Some systems require 300ms extra PPS T12 delay to be added to VBT
> > > value */
> >
> > The comment disagrees with the code. Code uses 800ms explicitly instead of
> > +300 ms.
> >
>
> Agree, I will change it to 800ms in the comment.
>
>
> > > +static void quirk_increase_t12_delay(struct drm_device *dev)
> > > +{
> > > + struct drm_i915_private *dev_priv = to_i915(dev);
> > > +
> > > + dev_priv->quirks |= QUIRK_INCREASE_T12_DELAY;
> > > + DRM_INFO("Applying T12 delay quirk\n");
> > > +}
> > > +
> > > struct intel_quirk {
> > > int device;
> > > int subsystem_vendor;
> > > @@ -14848,6 +14857,9 @@ static struct intel_quirk intel_quirks[] = {
> > >
> > > /* Dell Chromebook 11 (2015 version) */
> > > { 0x0a16, 0x1028, 0x0a35, quirk_backlight_present },
> > > +
> > > + /* Toshiba Satellite P50-C-18C */
> > > + { 0x191B, 0x1179, 0xF840, quirk_increase_t12_delay },
> >
> > Hmm. Looks like the 1179:f840 combo is present on a lot of Toshiba
> > models. But we do have the device ID here too so the quirk shouldn't
> > go totally overboard.
> >
>
> Yea this quirk should then get applied only to this device.
> Do you have any other Toshiba laptop with 1179:f840 combo
> to make sure it doesnt get applied on that?
No, but google shows many.
>
>
> > > };
> > >
> > > static void intel_init_quirks(struct drm_device *dev)
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 67bc8a7a..db6953e 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -49,6 +49,9 @@
> > > #define INTEL_DP_RESOLUTION_STANDARD (2 <<
> > > INTEL_DP_RESOLUTION_SHIFT_MASK)
> > > #define INTEL_DP_RESOLUTION_FAILSAFE (3 <<
> > > INTEL_DP_RESOLUTION_SHIFT_MASK)
> > >
> > > +/* PPS T12 Delay Quirk value for eDP */
> > > +#define T11_T12_800MS8000
> >
> > The define seems pointless. Just use the raw number in the code. Also
> > writing it as 800*10 would be more consistent with the rest of the code.
> >
>
> Sounds good, will use 800*10
>
> > > +
> > > struct dp_link_dpll {
> > > int clock;
> > > struct dpll dpll;
> > > @@ -5230,6 +5233,15 @@ intel_dp_init_panel_power_sequencer(struct
> > > drm_device *dev,
> > > intel_pps_dump_state("cur", &cur);
> > >
> > > vbt = dev_priv->vbt.edp.pps;
> > > + /* Apply the QUIRK_INCREASE_T12_DELAY quirk for a specific
> > > + * type of PCI device to avoid DP AUX CH Timeouts.
> >
> > That comment doesn't seem very helpful. I would put in something like:
> >
> > "On Toshiba the VBT t12 delay of 500ms appears to be too
> > short. Occasionally the panel just fails to power back on. Increasing
> > the delay to 800ms seems sufficient to avoid the problem."
> >
>
> Ok will do
>
> Manasi
>
> > > + */
> > > + if (dev_priv->quirks & QUIRK_INCREASE_T12_DELAY) {
> > > +
> > > + vbt.t11_t12 = max_t(u16, vbt.t11_t12,
Re: [Intel-gfx] [PATCH v3] drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts
On Thu, Jun 29, 2017 at 02:10:38PM -0700, Manasi Navare wrote:
> This patch fixes the DP AUX CH timeouts observed during CI IGT
> tests thus fixing the CI failures. This is done by adding a
> quirk for a particular PCI device that requires the panel power
> cycle delay (T12) to be set to 800ms which is 300msecs more than
> the minimum value specified in the eDP spec. So a quirk is
> implemented for that specific PCI device.
>
> v3:
> * Change some comments, specify the delay as 800 * 10 (Ville)
> v2:
> * Change the function and variable names to from PPS_T12_
> to _T12 since it is a T12 delay (Clint)
>
> Fixes: FDO #101144 #101515 #101154 #101167
That's not how we do it.
Also please look into git send-email --in-reply-to option. Review is
easier if the patches aren't spread all over the mailbox.
> Cc: Ville Syrjala
> Cc: Clinton Taylor
> Signed-off-by: Manasi Navare
> Reviewed-by: Clinton Taylor
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_display.c | 14 ++
> drivers/gpu/drm/i915/intel_dp.c | 11 +++
> 3 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 427d10c..4327c8a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1168,6 +1168,7 @@ enum intel_sbi_destination {
> #define QUIRK_INVERT_BRIGHTNESS (1<<2)
> #define QUIRK_BACKLIGHT_PRESENT (1<<3)
> #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
> +#define QUIRK_INCREASE_T12_DELAY (1<<6)
>
> struct intel_fbdev;
> struct intel_fbc_work;
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 4e03ca6..87dfde9 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14765,6 +14765,17 @@ static void quirk_backlight_present(struct
> drm_device *dev)
> DRM_INFO("applying backlight present quirk\n");
> }
>
> +/* Toshiba Satellite P50-C-18C requires T12 delay to be min 800ms
> + * which is 300 ms greater than eDP spec T12 min.
> + */
> +static void quirk_increase_t12_delay(struct drm_device *dev)
> +{
> + struct drm_i915_private *dev_priv = to_i915(dev);
> +
> + dev_priv->quirks |= QUIRK_INCREASE_T12_DELAY;
> + DRM_INFO("Applying T12 delay quirk\n");
> +}
> +
> struct intel_quirk {
> int device;
> int subsystem_vendor;
> @@ -14848,6 +14859,9 @@ static struct intel_quirk intel_quirks[] = {
>
> /* Dell Chromebook 11 (2015 version) */
> { 0x0a16, 0x1028, 0x0a35, quirk_backlight_present },
> +
> + /* Toshiba Satellite P50-C-18C */
> + { 0x191B, 0x1179, 0xF840, quirk_increase_t12_delay },
> };
>
> static void intel_init_quirks(struct drm_device *dev)
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 67bc8a7a..4d7e510 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5230,6 +5230,17 @@ intel_dp_init_panel_power_sequencer(struct drm_device
> *dev,
> intel_pps_dump_state("cur", &cur);
>
> vbt = dev_priv->vbt.edp.pps;
> + /* On Toshiba Satellite P50-C-18C system the VBT T12 delay
> + * of 500ms appears to be too short. Ocassionally the panel
> + * just fails to power back on. Increasing the delay to 800ms
> + * seems sufficient to avpid this problem.a
^
typo
Otherwise looks OK to me.
> + */
> + if (dev_priv->quirks & QUIRK_INCREASE_T12_DELAY) {
> +
> + vbt.t11_t12 = max_t(u16, vbt.t11_t12, 800 * 10);
> + DRM_DEBUG_KMS("Increasing T12 panel delay as per the quirk to
> %d\n",
> + vbt.t11_t12);
> + }
> /* T11_T12 delay is special and actually in units of 100ms, but zero
>* based in the hw (so we need to add 100 ms). But the sw vbt
>* table multiplies it with 1000 to make it in units of 100usec,
> --
> 2.1.4
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i2c: i801: Allow ACPI SystemIO OpRegion to conflict harder
On Mon, Jun 26, 2017 at 04:40:08PM -0400, Lyude wrote: > There's quite a number of machines on the market, mainly Lenovo > ThinkPads, that make the horrible mistake in their firmware of reusing > the PCIBAR space reserved for the SMBus for things that are completely > unrelated to the SMBus controller, such as the OpRegion used for i915. > This is very bad and entirely evil, but with Lenovo's historically poor > track record of fixing their firmware, it is extremely unlikely this is > ever going to be properly fixed. > > So, while it would be nice if we could just cut off the SMBus controller > and call it a day this unfortunately breaks RMI4 mode completely for > most of the ThinkPads. Even though this behavior is extremely wrong, for > whatever reason sharing the PCIBAR between the OpRegion and SMBus seems > to be just fine. Regardless however, I think it's safe to assume that > when the BIOS accesses the PCIBAR space of the SMBus controller like > this that it's trying to get to something else that we mapped the SMBus > controller over. > > On my X1 Carbon, this assumption appears to be correct. I've traced down > the firmware accesses to being caused by the firmware mistakenly placing > the SWSCI mailbox for i915 on top of the SMBus host controller region. > And indeed, blacklisting i915 causes the firmware to never attempt to > touch this region. > > So, in order to try to workaround this and not break either SMBus or > i915, we temporarily unmap the PCI device for the SMBus controller, > do the thing that the firmware wanted to do, then remap the device and > report a firmware bug. Are the registers it tries to access separate from SMBus ones? We already have TCO registers placed to this device starting from Skylake so there might be something else as well. Point here is that if the access is not to the SMBus registers we can quirk it in the driver and let the access happen because it does not mess our state. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND-CI v4 13/15] drm/i915: prepare csc unit for YCBCR HDMI output
On Fri, 2017-06-30 at 11:33 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/29/2017 5:38 PM, Ander Conselvan De Oliveira wrote:
> > On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> > > To support ycbcr HDMI output, we need a pipe CSC block to
> > > do the RGB->YCBCR conversion, as the blender output is in RGB.
> > >
> > > Current Intel platforms have only one pipe CSC unit, so
> > > we can either do color correction using it, or we can perform
> > > RGB->YCBCR conversion.
> > >
> > > This function adds a csc handler, to perform RGB->YCBCR conversion
> > > as per recommended spec values.
> >
> > Please do a full reference to the "spec", including name, version and
> > relevant
> > section.
>
> Sure, will add more details.
> > > V2: Rebase
> > > V3: Rebase
> > > V4: Rebase
> > >
> > > Cc: Ville Syrjala
> > > Cc: Daniel Vetter
> > > Cc: Ander Conselvan De Oliveira
> > > Signed-off-by: Shashank Sharma
> > > ---
> > > drivers/gpu/drm/i915/intel_color.c | 47
> > > +++-
> > > drivers/gpu/drm/i915/intel_display.c | 32
> > > 2 files changed, 78 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_color.c
> > > b/drivers/gpu/drm/i915/intel_color.c
> > > index 306c6b0..12d5f21 100644
> > > --- a/drivers/gpu/drm/i915/intel_color.c
> > > +++ b/drivers/gpu/drm/i915/intel_color.c
> > > @@ -41,6 +41,19 @@
> > >
> > > #define LEGACY_LUT_LENGTH (sizeof(struct drm_color_lut) *
> > > 256)
> > >
> > > +/* Post offset values for RGB->YCBCR conversion */
> > > +#define POSTOFF_RGB_TO_YUV_HI 0x800
> > > +#define POSTOFF_RGB_TO_YUV_ME 0x100
> > > +#define POSTOFF_RGB_TO_YUV_LO 0x800
> > > +
> > > +/* Direct spec values for RGB->YUV conversion matrix */
> > > +#define CSC_RGB_TO_YUV_RU_GU 0x2ba809d8
> > > +#define CSC_RGB_TO_YUV_BU 0x37e8
> > > +#define CSC_RGB_TO_YUV_RY_GY 0x1e089cc0
> > > +#define CSC_RGB_TO_YUV_BY 0xb528
> > > +#define CSC_RGB_TO_YUV_RV_GV 0xbce89ad8
> > > +#define CSC_RGB_TO_YUV_BV 0x1e08
> > > +
> >
> > Not a big fan or hardcoding this in the register format. We already have the
> > code for converting a number to the right format for the register in
> > i915_load_csc_matrix(). I think it would make more sense to extract the code
> > that actually writes the matrix out of that function, so it would just
> > unconditionally use a matrix and coefficients passed as arguments. Then the
> > values above would be defined in the format expected for this new function.
>
> Actually I had a small discussion on this with Ville, and we think that
> the current CSC multiplication code is not correct.
> So if CTM and limited color range is applied together, we might not be
> getting the right values. So not planning to
> reuse that code. I think while sending the BT2020 patches, we will add a
> fix for that part too, but right now not working on it.
I wasn't talking about the matrix multiplication, but creating a function to
write any given matrix into the CSC. That way, the above could be hardcoded in a
more human readable format.
This issue is independent from fixing the matrix multiplication. I'm talking
specifically about the code below:
/*
* Convert fixed point S31.32 input to format supported by the
* hardware.
*/
for (i = 0; i < ARRAY_SIZE(coeffs); i++) {
uint64_t abs_coeff = ((1ULL << 63) - 1) & input[i];
/*
* Clamp input value to min/max supported by
* hardware.
*/
abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_4_0 - 1);
/* sign bit */
if (CTM_COEFF_NEGATIVE(input[i]))
coeffs[i] |= 1 << 15;
if (abs_coeff < CTM_COEFF_0_125)
coeffs[i] |= (3 << 12) |
I9XX_CSC_COEFF_FP(abs_coeff, 12);
else if (abs_coeff < CTM_COEFF_0_25)
coeffs[i] |= (2 << 12) |
I9XX_CSC_COEFF_FP(abs_coeff, 11);
else if (abs_coeff < CTM_COEFF_0_5)
coeffs[i] |= (1 << 12) |
I9XX_CSC_COEFF_FP(abs_coeff, 10);
else if (abs_coeff < CTM_COEFF_1_0)
coeffs[i] |= I9XX_CSC_COEFF_FP(abs_coeff, 9);
else if (abs_coeff < CTM_COEFF_2_0)
coeffs[i] |= (7 << 12) |
I9XX_CSC_COEFF_FP(abs_coeff, 8);
else
coeffs[i] |= (6 << 12) |
I9XX_CSC_COEFF_FP(abs_coeff, 7);
Re: [Intel-gfx] [PATCH 01/17] drm/i915: Clear pipestat consistently
On Thu, Jun 22, 2017 at 01:39:47PM +0100, Chris Wilson wrote:
> Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:39)
> > From: Ville Syrjälä
> >
> > We have a lot of different ways of clearing the PIPESTAT registers.
> > Let's unify it all into one function. There's no magic in PIPESTAT
> > that would require any of the double clearing and whatnot that
> > some of the code tries to do. All we can really do is clear the status
> > bits and disable the enable bits. There is no way to mask anything
> > so as soon as another event happens the status bit will become set
> > again, and trying to clear them twice or something can't protect
> > against that.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 67
> > ++---
> > 1 file changed, 30 insertions(+), 37 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index b1c7d1a04612..6daaf47482d4 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -1732,6 +1732,19 @@ static bool intel_pipe_handle_vblank(struct
> > drm_i915_private *dev_priv,
> > return ret;
> > }
> >
> > +static void i9xx_pipestat_irq_reset(struct drm_i915_private *dev_priv)
> > +{
> > + enum pipe pipe;
> > +
> > + for_each_pipe(dev_priv, pipe) {
> > + I915_WRITE(PIPESTAT(pipe),
> > + PIPESTAT_INT_STATUS_MASK |
> > + PIPE_FIFO_UNDERRUN_STATUS);
>
> Hmm, is this change for i915/i965 significant? Maybe explain it away in
> the changelog?
Sorry missed your question. Which change are we concerned about here
specifically?
As the commit message tried to explain, the "first disable then clear"
thing at least is pointless, and we can just do it in one step.
But maybe that wasn't the part you're thinking about?
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND-CI v4 11/15] drm/i915: prepare scaler for YCBCR420 modeset
On Fri, 2017-06-30 at 11:20 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/27/2017 5:46 PM, Ander Conselvan De Oliveira wrote:
> > On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> > > To get a YCBCR420 output from intel platforms, we need one
> > > scaler to scale down YCBCR444 samples to YCBCR420 samples.
> > >
> > > This patch:
> > > - Does scaler allocation for HDMI ycbcr420 outputs.
> > > - Programs PIPE_MISC register for ycbcr420 output.
> > > - Adds a new scaler user "HDMI output" to plug-into existing
> > >scaler framework. This output type is identified using bit
> > >30 of the scaler users bitmap.
> > >
> > > V2: rebase
> > > V3: rebase
> > > V4: rebase
> > >
> > > Cc: Ville Syrjala
> > > Cc: Ander Conselvan De Oliveira
> > > Signed-off-by: Shashank Sharma
> > > ---
> > > drivers/gpu/drm/i915/intel_atomic.c | 6 ++
> > > drivers/gpu/drm/i915/intel_display.c | 26 ++
> > > drivers/gpu/drm/i915/intel_drv.h | 10 +-
> > > drivers/gpu/drm/i915/intel_hdmi.c| 10 ++
> > > drivers/gpu/drm/i915/intel_panel.c | 3 ++-
> > > 5 files changed, 53 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> > > b/drivers/gpu/drm/i915/intel_atomic.c
> > > index 36d4e63..a8c9ac5 100644
> > > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > > @@ -264,6 +264,12 @@ int intel_atomic_setup_scalers(struct
> > > drm_i915_private *dev_priv,
> > >
> > > /* panel fitter case: assign as a crtc scaler */
> > > scaler_id = &scaler_state->scaler_id;
> > > + } else if (i == SKL_HDMI_OUTPUT_INDEX) {
> > > + name = "HDMI-OUTPUT";
> > > + idx = intel_crtc->base.base.id;
> > > +
> > > + /* hdmi output case: needs a pipe scaler */
> > > + scaler_id = &scaler_state->scaler_id;
> > > } else {
> > > name = "PLANE";
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index da29536..983f581 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -4626,6 +4626,11 @@ skl_update_scaler(struct intel_crtc_state
> > > *crtc_state, bool force_detach,
> > >*/
> > > need_scaling = src_w != dst_w || src_h != dst_h;
> > >
> > > + if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420
> > > + && scaler_user == SKL_HDMI_OUTPUT_INDEX)
> >
> > Is it really necessary to check for both? If it is, what's the point of
> > creating
> > SKL_HDMI_OUTPUT_INDEX?
>
> Yes, else this will affect scaler update for planes, as this function
> gets called to update the plane scalers too, at that time the output
> will be still valid (as its at CRTC level), but the
> scaler user would be different.
Right, so there is a need to check for scaler_user == HDMI_OUTPUT. But then
wouldn't it be a bug if hdmi_output != YCBCR420 ? Point is, if the caller asked
for a HDMI_OUTPUT scaler hopefully it knows what its doing, no need to second
guess it.
> >
> > > + /* YCBCR 444 -> 420 conversion needs a scaler */
> > > + need_scaling = true;
> > > +
> > > /*
> > >* if plane is being disabled or scaler is no more required or
> > > force detach
> > >* - free scaler binded to this plane/crtc
> > > @@ -4673,6 +4678,26 @@ skl_update_scaler(struct intel_crtc_state
> > > *crtc_state, bool force_detach,
> > > }
> > >
> > > /**
> > > + * skl_update_scaler_hdmi_output - Stages update to scaler state for
> > > HDMI.
> > > + * HDMI YCBCR 420 output needs a scaler, for downsampling.
> > > + *
> > > + * @state: crtc's scaler state
> > > + *
> > > + * Return
> > > + * 0 - scaler_usage updated successfully
> > > + *error - requested scaling cannot be supported or other error
> > > condition
> > > + */
> > > +int skl_update_scaler_crtc_hdmi_output(struct intel_crtc_state *state)
> > > +{
> > > + const struct drm_display_mode *mode = &state->base.adjusted_mode;
> > > +
> > > + return skl_update_scaler(state, !state->base.active,
> > > + SKL_HDMI_OUTPUT_INDEX, &state->scaler_state.scaler_id,
> > > + state->pipe_src_w, state->pipe_src_h,
> > > + mode->crtc_hdisplay, mode->crtc_vdisplay);
> > > +}
> > > +
> > > +/**
> > >* skl_update_scaler_crtc - Stages update to scaler state for a given
> > > crtc.
> > >*
> > >* @state: crtc's scaler state
> > > @@ -8058,6 +8083,7 @@ static void haswell_set_pipemisc(struct drm_crtc
> > > *crtc)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(crtc->dev);
> > > struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > > + enum drm_hdmi_output_type hdmi_out = intel_crtc->config->hdmi_output;
> > >
> > > i
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Make i915_gem_object_phys_attach() use obj->mm.lock more appropriately
On Thu, Jun 15, 2017 at 09:25:08AM +0100, Chris Wilson wrote:
> Actually transferring from shmemfs to the physically contiguous set of
> pages should be wholly guarded by its obj->mm.lock!
>
> v2: Remember to free the old pages.
>
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_gem.c | 44
> +++--
> 1 file changed, 29 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 31cbe78171a9..7f3be5deeb5e 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -574,7 +574,8 @@ int
> i915_gem_object_attach_phys(struct drm_i915_gem_object *obj,
> int align)
> {
> - int ret;
> + struct sg_table *pages;
> + int err;
>
> if (align > obj->base.size)
> return -EINVAL;
> @@ -582,32 +583,45 @@ i915_gem_object_attach_phys(struct drm_i915_gem_object
> *obj,
> if (obj->ops == &i915_gem_phys_ops)
> return 0;
>
> - if (obj->mm.madv != I915_MADV_WILLNEED)
> - return -EFAULT;
> -
> - if (obj->base.filp == NULL)
> + if (obj->ops != &i915_gem_object_ops)
> return -EINVAL;
>
> - ret = i915_gem_object_unbind(obj);
> - if (ret)
> - return ret;
> + err = i915_gem_object_unbind(obj);
> + if (err)
> + return err;
> +
> + mutex_lock(&obj->mm.lock);
> +
> + if (obj->mm.quirked) {
> + err = -EFAULT;
> + goto err_unlock;
> + }
>
> - __i915_gem_object_put_pages(obj, I915_MM_NORMAL);
> - if (obj->mm.pages)
> - return -EBUSY;
> + if (obj->mm.mapping) {
> + err = -EBUSY;
> + goto err_unlock;
> + }
>
> - GEM_BUG_ON(obj->ops != &i915_gem_object_ops);
> + pages = obj->mm.pages;
> obj->ops = &i915_gem_phys_ops;
>
> - ret = i915_gem_object_pin_pages(obj);
> - if (ret)
> + err = __i915_gem_object_get_pages(obj);
> + if (err)
> goto err_xfer;
>
> + /* Perma-pin (until release) the physical set of pages */
> + __i915_gem_object_pin_pages(obj);
> +
> + i915_gem_object_ops.put_pages(obj, pages);
Leak sorted, so this lgtm.
Reviewed-by: Ville Syrjälä
> + mutex_unlock(&obj->mm.lock);
> return 0;
>
> err_xfer:
> obj->ops = &i915_gem_object_ops;
> - return ret;
> + obj->mm.pages = pages;
> +err_unlock:
> + mutex_unlock(&obj->mm.lock);
> + return err;
> }
>
> static int
> --
> 2.11.0
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [GIT PULL] GVT-g fixes for drm-intel-next-fixes
On Thu, 29 Jun 2017, Zhenyu Wang wrote: > Hi, this is current gvt fixes after 4.13 stuff got pulled in > drm-intel-next. Mostly two race fixes and several virtual display > fixes on BDW. Pulled to drm-intel-next-fixes, thanks. BR, Jani. > > Thanks. > -- > The following changes since commit e274086e473c0cbea18051ae0a78a05f8d658f47: > > drm/i915/gvt: clean up unsubmited workloads before destroying kmem cache > (2017-05-24 10:33:37 +0800) > > are available in the git repository at: > > https://github.com/01org/gvt-linux.git tags/gvt-fixes-2017-06-29 > > for you to fetch changes up to 5cd82b757795228516bf60a0552d1a40fa8adeb2: > > drm/i915/gvt: Make function dpy_reg_mmio_readx safe (2017-06-29 11:15:11 > +0800) > > > gvt-fixes-2017-06-29 > > - two race fixes for VFIO locks from Chuanxiao > - virtual display fix for BDW from Xiong > > > Changbin Du (1): > drm/i915/gvt: Make function dpy_reg_mmio_readx safe > > Chuanxiao Dong (2): > drm/i915/gvt: Fix possible recursive locking issue > drm/i915/gvt: Fix inconsistent locks holding sequence > > Xiong Zhang (2): > drm/i915/gvt: Set initial PORT_CLK_SEL vreg for BDW > drm/i915/gvt: Don't read ADPA_CRT_HOTPLUG_MONITOR from host > > drivers/gpu/drm/i915/gvt/display.c | 22 > drivers/gpu/drm/i915/gvt/gvt.h | 3 ++ > drivers/gpu/drm/i915/gvt/handlers.c | 37 +++- > drivers/gpu/drm/i915/gvt/kvmgt.c| 69 > + > 4 files changed, 99 insertions(+), 32 deletions(-) -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/17] drm/i915: Clear pipestat consistently
Quoting Ville Syrjälä (2017-06-30 12:34:15)
> On Thu, Jun 22, 2017 at 01:39:47PM +0100, Chris Wilson wrote:
> > Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:39)
> > > From: Ville Syrjälä
> > >
> > > We have a lot of different ways of clearing the PIPESTAT registers.
> > > Let's unify it all into one function. There's no magic in PIPESTAT
> > > that would require any of the double clearing and whatnot that
> > > some of the code tries to do. All we can really do is clear the status
> > > bits and disable the enable bits. There is no way to mask anything
> > > so as soon as another event happens the status bit will become set
> > > again, and trying to clear them twice or something can't protect
> > > against that.
> > >
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/i915_irq.c | 67
> > > ++---
> > > 1 file changed, 30 insertions(+), 37 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > b/drivers/gpu/drm/i915/i915_irq.c
> > > index b1c7d1a04612..6daaf47482d4 100644
> > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > @@ -1732,6 +1732,19 @@ static bool intel_pipe_handle_vblank(struct
> > > drm_i915_private *dev_priv,
> > > return ret;
> > > }
> > >
> > > +static void i9xx_pipestat_irq_reset(struct drm_i915_private *dev_priv)
> > > +{
> > > + enum pipe pipe;
> > > +
> > > + for_each_pipe(dev_priv, pipe) {
> > > + I915_WRITE(PIPESTAT(pipe),
> > > + PIPESTAT_INT_STATUS_MASK |
> > > + PIPE_FIFO_UNDERRUN_STATUS);
> >
> > Hmm, is this change for i915/i965 significant? Maybe explain it away in
> > the changelog?
>
> Sorry missed your question. Which change are we concerned about here
> specifically?
We didn't set PIPESTAT_INT_STATUS_MASK | PIPE_FIFO_UNDERRUN_STATUS
previously afaics.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND-CI v4 06/15] drm/edid: parse sink information before CEA blocks
On Fri, Jun 30, 2017 at 10:52:54AM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 6/27/2017 5:25 PM, Ville Syrjälä wrote: > > On Wed, Jun 21, 2017 at 04:04:04PM +0530, Shashank Sharma wrote: > >> CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks. > >> This block contains a map of indexes of CEA modes, which can > >> support YCBCR 420 output also. To avoid multiple parsing of same > >> CEA block, let's parse the sink information and get this map, before > >> parsing CEA modes. > >> > >> This patch moves the call to drm_add_display_info function, before the > >> mode parsing block. > >> > >> Signed-off-by: Shashank Sharma > >> --- > >> drivers/gpu/drm/drm_edid.c | 9 +++-- > >> 1 file changed, 7 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > >> index b4583f6..42934b2 100644 > >> --- a/drivers/gpu/drm/drm_edid.c > >> +++ b/drivers/gpu/drm/drm_edid.c > >> @@ -4605,6 +4605,13 @@ int drm_add_edid_modes(struct drm_connector > >> *connector, struct edid *edid) > >>quirks = edid_get_quirks(edid); > >> > >>/* > >> + * CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks. > >> + * To avoid multiple parsing of same block, lets parse that map > >> + * from sink info, before parsing CEA modes. > >> + */ > >> + drm_add_display_info(connector, edid); > >> + > > This patch should come before the 4:2:0 mode parsing, no? > Dint you ask me to move it later (in the previous series comments), for > git-bisect regression type of changes ? I wanted it split out to help with bisecting. It should be early in the series because otherwise the rest makes no sense. And I suppose we should be able to push this in on its own right now. Just need a CI run for it, so maybe resesnd just this patch on its own. > > Otherwise I think this should be fine so > > Reviewed-by: Ville Syrjälä > Thanks. > > > >> + /* > >> * EDID spec says modes should be preferred in this order: > >> * - preferred detailed mode > >> * - other detailed modes from base block > >> @@ -4632,8 +4639,6 @@ int drm_add_edid_modes(struct drm_connector > >> *connector, struct edid *edid) > >>if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75)) > >>edid_fixup_preferred(connector, quirks); > >> > >> - drm_add_display_info(connector, edid); > >> - > >>if (quirks & EDID_QUIRK_FORCE_6BPC) > >>connector->display_info.bpc = 6; > >> > >> -- > >> 2.7.4 -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND-CI v4 01/15] drm: add HDMI 2.0 VIC support for AVI info-frames
On Wed, Jun 21, 2017 at 04:03:59PM +0530, Shashank Sharma wrote:
> HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
> For any other mode, the VIC filed in AVI infoframes should be 0.
> HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
> extended to (VIC 1-107).
>
> This patch adds a bool input variable, which indicates if the connected
> sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
> HDMI 2.0 VIC to a HDMI 1.4 sink.
>
> This patch touches all drm drivers, who are callers of this function
> drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
> no change in current behavior, is_hdmi2 is kept as false.
>
> In case of I915 driver, this patch:
> - checks if the connected display is HDMI 2.0.
> - HDMI infoframes carry one of this two type of information:
> - VIC for 4K modes for HDMI 1.4 sinks
> - S3D information for S3D modes
> As CEA-861-F has already defined VICs for 4K videomodes, this
> patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks,
> until the mode is 3D.
>
> Cc: Ville Syrjala
> Cc: Jose Abreu
> Cc: Andrzej Hajda
> Cc: Alex Deucher
> Cc: Daniel Vetter
>
> PS: This patch touches a few lines in few files, which were
> already above 80 char, so checkpatch gives 80 char warning again.
> - gpu/drm/omapdrm/omap_encoder.c
> - gpu/drm/i915/intel_sdvo.c
>
> V2: Rebase, Added r-b from Andrzej
> V3: Addressed review comment from Ville:
> - Do not send VICs in both AVI-IF and HDMI-IF
> send only one of it.
>
> Reviewed-by: Andrzej Hajda
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/amd/amdgpu/dce_v10_0.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v11_0.c| 2 +-
> drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +-
> drivers/gpu/drm/bridge/analogix-anx78xx.c | 3 ++-
> drivers/gpu/drm/bridge/sii902x.c | 2 +-
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 2 +-
> drivers/gpu/drm/drm_edid.c| 12 +++-
> drivers/gpu/drm/exynos/exynos_hdmi.c | 2 +-
> drivers/gpu/drm/i2c/tda998x_drv.c | 2 +-
> drivers/gpu/drm/i915/intel_hdmi.c | 17 -
> drivers/gpu/drm/i915/intel_sdvo.c | 3 ++-
> drivers/gpu/drm/mediatek/mtk_hdmi.c | 2 +-
> drivers/gpu/drm/omapdrm/omap_encoder.c| 3 ++-
> drivers/gpu/drm/radeon/radeon_audio.c | 2 +-
> drivers/gpu/drm/rockchip/inno_hdmi.c | 2 +-
> drivers/gpu/drm/sti/sti_hdmi.c| 2 +-
> drivers/gpu/drm/tegra/hdmi.c | 2 +-
> drivers/gpu/drm/tegra/sor.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hdmi.c| 2 +-
> drivers/gpu/drm/zte/zx_hdmi.c | 2 +-
> include/drm/drm_edid.h| 3 ++-
> 21 files changed, 50 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> index 3c62c45..4923ddc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
> @@ -1864,7 +1864,7 @@ static void dce_v10_0_afmt_setmode(struct drm_encoder
> *encoder,
> dce_v10_0_audio_write_sad_regs(encoder);
> dce_v10_0_audio_write_latency_fields(encoder, mode);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> index c8ed0fa..4101684 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v11_0.c
> @@ -1848,7 +1848,7 @@ static void dce_v11_0_afmt_setmode(struct drm_encoder
> *encoder,
> dce_v11_0_audio_write_sad_regs(encoder);
> dce_v11_0_audio_write_latency_fields(encoder, mode);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> index 3e90c19..a7f6b32 100644
> --- a/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/dce_v8_0.c
> @@ -1747,7 +1747,7 @@ static void dce_v8_0_afmt_setmode(struct drm_encoder
> *encoder,
> dce_v8_0_audio_write_sad_regs(encoder);
> dce_v8_0_audio_write_latency_fields(encoder, mode);
>
> - err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode);
> + err = drm_hdmi_avi_infoframe_from_display_mode(&frame, mode, false);
> if (err < 0) {
> DRM_ERROR("failed to setup AVI infoframe: %zd\n", err);
> return;
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> b/drivers/gpu/dr
Re: [Intel-gfx] [RESEND-CI v4 04/15] drm/edid: parse YCBCR 420 videomodes from EDID
On Fri, Jun 30, 2017 at 10:47:48AM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 6/27/2017 5:22 PM, Ville Syrjälä wrote: > > On Wed, Jun 21, 2017 at 04:04:02PM +0530, Shashank Sharma wrote: > >> HDMI 2.0 spec adds support for YCBCR420 sub-sampled output. > >> CEA-861-F adds two new blocks in EDID's CEA extension blocks, > >> to provide information about sink's YCBCR420 output capabilities. > >> > >> These blocks are: > >> > >> - YCBCR420vdb(YCBCR 420 video data block): > >> This block contains VICs of video modes, which can be sopported only > >> in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal > >> SVD block, valid for YCBCR420 modes only. > >> > >> - YCBCR420cmdb(YCBCR 420 capability map data block): > >> This block gives information about video modes which can support > >> YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This > >> block contains a bitmap index of normal svd videomodes, which can > >> support YCBCR420 output too. > >> So if bit 0 from first vcb byte is set, first video mode in the svd > >> list can support YCBCR420 output too. Bit 1 means second video mode > >> from svd list can support YCBCR420 output too, and so on. > >> > >> This patch adds two bitmaps in display's hdmi_info structure, one each > >> for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch > >> adds: > >> - VDB modes (YCBCR 420 only modes) in connector's mode list, also makes > >>an entry in the vdb_bitmap per vic. > >> - VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap. > >> > >> Cc: Ville Syrjala > >> Cc: Jose Abreu > >> Cc: Emil Velikov > >> > >> V2: Addressed > >> Review comments from Emil: > >> - Use 1ULL< >> - Use the suggested method for updating dbmap. > >> - Add documentation for YCBCR420_vcb_map to fix kbuild warning. > >> > >> Review comments from Ville: > >> - Do not expose the YCBCR420 flags in uabi layer, keep it internal. > >> - Save a map of YCBCR420 modes for future reference. > >> - Check db length before trying to parse extended tag. > >> - Add a warning if there are > 64 modes in capability map block. > >> - Use y420cmdb in function names and macros while dealing with vcb > >>to be aligned with spec. > >> - Move the display information parsing block ahead of mode parsing > >>blocks. > >> > >> V3: Addressed design/review comments from Ville > >> - Do not add flags in video modes, else we have to expose them to user > >> - There should not be a UABI change, and kernel should detect the > >>choice of the output based on type of mode, and the bitmaps. > >> - Use standard bitops from kernel bitmap header, instead of > >> calculating > >>bit positions manually. > >> > >> V4: Addressed review comments from Ville: > >> - s/ycbcr_420_vdb/y420vdb > >> - s/ycbcr_420_vcb/y420cmdb > >> - Be less verbose on description of do_y420vdb_modes > >> - Move newmode variable in the loop scope. > >> - Use svd_to_vic() to get a VIC, instead of 0x7f > >> - Remove bitmap description for CMDB modes & VDB modes > >> - Dont add connector->ycbcr_420_allowed check for cmdb modes > >> - Remove 'len' variable, in is_y420cmdb function, which is used > >>only once > >> - Add length check in is_y420vdb function > >> - Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap > >> - Do not add print about YCBCR 420 modes > >> - Fix indentation in few places > >> - Move ycbcr420_dc_modes in next patch, where its used > >> - Add a separate patch for movement of drm_add_display_info() > >> > >> Signed-off-by: Shashank Sharma > >> --- > >> drivers/gpu/drm/drm_edid.c | 157 > >> +++- > >> include/drm/drm_connector.h | 20 ++ > >> 2 files changed, 174 insertions(+), 3 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c > >> index e2d1b30..8c7e73b 100644 > >> --- a/drivers/gpu/drm/drm_edid.c > >> +++ b/drivers/gpu/drm/drm_edid.c > >> @@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector, > >> struct edid *edid, > >> #define VIDEO_BLOCK 0x02 > >> #define VENDOR_BLOCK0x03 > >> #define SPEAKER_BLOCK0x04 > >> -#define VIDEO_CAPABILITY_BLOCK0x07 > >> +#define VIDEO_CAPABILITY_BLOCK 0x07 > >> +#define VIDEO_DATA_BLOCK_420 0x0E > >> +#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F > >> #define EDID_BASIC_AUDIO (1 << 6) > >> #define EDID_CEA_YCRCB444(1 << 5) > >> #define EDID_CEA_YCRCB422(1 << 4) > >> @@ -3153,15 +3155,79 @@ drm_display_mode_from_vic_index(struct > >> drm_connector *connector, > >>return newmode; > >> } > >> > >> +/* > >> + * do_y420vdb_modes - Parse YCBCR 420 only modes > >> + * @connector: connector corresponding to the HDMI sink > >> + * @svds: start of the data block of CEA YCBCR 420 VDB > >> + * @len: l
Re: [Intel-gfx] [RESEND-CI v4 11/15] drm/i915: prepare scaler for YCBCR420 modeset
Regards
Shashank
On 6/30/2017 5:04 PM, Ander Conselvan De Oliveira wrote:
On Fri, 2017-06-30 at 11:20 +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/27/2017 5:46 PM, Ander Conselvan De Oliveira wrote:
On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.
This patch:
- Does scaler allocation for HDMI ycbcr420 outputs.
- Programs PIPE_MISC register for ycbcr420 output.
- Adds a new scaler user "HDMI output" to plug-into existing
scaler framework. This output type is identified using bit
30 of the scaler users bitmap.
V2: rebase
V3: rebase
V4: rebase
Cc: Ville Syrjala
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_atomic.c | 6 ++
drivers/gpu/drm/i915/intel_display.c | 26 ++
drivers/gpu/drm/i915/intel_drv.h | 10 +-
drivers/gpu/drm/i915/intel_hdmi.c| 10 ++
drivers/gpu/drm/i915/intel_panel.c | 3 ++-
5 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 36d4e63..a8c9ac5 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -264,6 +264,12 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
/* panel fitter case: assign as a crtc scaler */
scaler_id = &scaler_state->scaler_id;
+ } else if (i == SKL_HDMI_OUTPUT_INDEX) {
+ name = "HDMI-OUTPUT";
+ idx = intel_crtc->base.base.id;
+
+ /* hdmi output case: needs a pipe scaler */
+ scaler_id = &scaler_state->scaler_id;
} else {
name = "PLANE";
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index da29536..983f581 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4626,6 +4626,11 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
*/
need_scaling = src_w != dst_w || src_h != dst_h;
+ if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420
+ && scaler_user == SKL_HDMI_OUTPUT_INDEX)
Is it really necessary to check for both? If it is, what's the point of creating
SKL_HDMI_OUTPUT_INDEX?
Yes, else this will affect scaler update for planes, as this function
gets called to update the plane scalers too, at that time the output
will be still valid (as its at CRTC level), but the
scaler user would be different.
Right, so there is a need to check for scaler_user == HDMI_OUTPUT. But then
wouldn't it be a bug if hdmi_output != YCBCR420 ? Point is, if the caller asked
for a HDMI_OUTPUT scaler hopefully it knows what its doing, no need to second
guess it.
skl_update_scaler function gets called for all the users, which are:
- panel fitter
- all the planes
- newly added user hdmi_output
what about the case (assume) when we have handled hdmi_output and now we
are handling for a plane, which doesnt need scaling.
in this case, the code will look like:
if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420)
need_scaling = true /* which is wrong, as this function call is
for plane scalar, and scaler_user = scaler */
if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420 &&
scaler_user == HDMI_OUT)
need_scaling = true /* this is correct, as I want to consume scalar only
when both the conditions are true.
+ /* YCBCR 444 -> 420 conversion needs a scaler */
+ need_scaling = true;
+
/*
* if plane is being disabled or scaler is no more required or force
detach
* - free scaler binded to this plane/crtc
@@ -4673,6 +4678,26 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
}
/**
+ * skl_update_scaler_hdmi_output - Stages update to scaler state for HDMI.
+ * HDMI YCBCR 420 output needs a scaler, for downsampling.
+ *
+ * @state: crtc's scaler state
+ *
+ * Return
+ * 0 - scaler_usage updated successfully
+ *error - requested scaling cannot be supported or other error condition
+ */
+int skl_update_scaler_crtc_hdmi_output(struct intel_crtc_state *state)
+{
+ const struct drm_display_mode *mode = &state->base.adjusted_mode;
+
+ return skl_update_scaler(state, !state->base.active,
+ SKL_HDMI_OUTPUT_INDEX, &state->scaler_state.scaler_id,
+ state->pipe_src_w, state->pipe_src_h,
+ mode->crtc_hdisplay, mode->crtc_vdisplay);
+}
+
+/**
* skl_update_scaler_crtc - Stages update to scaler state for a given crtc.
*
* @state: crtc's scaler state
@@ -8058,6 +8083,7 @@ static void haswell_set_pipemisc(struct drm_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc-
Re: [Intel-gfx] [PATCH 01/17] drm/i915: Clear pipestat consistently
On Fri, Jun 30, 2017 at 12:41:53PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjälä (2017-06-30 12:34:15)
> > On Thu, Jun 22, 2017 at 01:39:47PM +0100, Chris Wilson wrote:
> > > Quoting ville.syrj...@linux.intel.com (2017-06-22 12:55:39)
> > > > From: Ville Syrjälä
> > > >
> > > > We have a lot of different ways of clearing the PIPESTAT registers.
> > > > Let's unify it all into one function. There's no magic in PIPESTAT
> > > > that would require any of the double clearing and whatnot that
> > > > some of the code tries to do. All we can really do is clear the status
> > > > bits and disable the enable bits. There is no way to mask anything
> > > > so as soon as another event happens the status bit will become set
> > > > again, and trying to clear them twice or something can't protect
> > > > against that.
> > > >
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > drivers/gpu/drm/i915/i915_irq.c | 67
> > > > ++---
> > > > 1 file changed, 30 insertions(+), 37 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > index b1c7d1a04612..6daaf47482d4 100644
> > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > @@ -1732,6 +1732,19 @@ static bool intel_pipe_handle_vblank(struct
> > > > drm_i915_private *dev_priv,
> > > > return ret;
> > > > }
> > > >
> > > > +static void i9xx_pipestat_irq_reset(struct drm_i915_private *dev_priv)
> > > > +{
> > > > + enum pipe pipe;
> > > > +
> > > > + for_each_pipe(dev_priv, pipe) {
> > > > + I915_WRITE(PIPESTAT(pipe),
> > > > + PIPESTAT_INT_STATUS_MASK |
> > > > + PIPE_FIFO_UNDERRUN_STATUS);
> > >
> > > Hmm, is this change for i915/i965 significant? Maybe explain it away in
> > > the changelog?
> >
> > Sorry missed your question. Which change are we concerned about here
> > specifically?
>
> We didn't set PIPESTAT_INT_STATUS_MASK | PIPE_FIFO_UNDERRUN_STATUS
> previously afaics.
Ah. Those are the sticky status bits, so the earlier
I915_WRITE(PIPESTAT, I915_READ(PIPESTAT)) did the same thing
effectively.
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND-CI v4 06/15] drm/edid: parse sink information before CEA blocks
Regards Shashank On 6/30/2017 5:16 PM, Ville Syrjälä wrote: On Fri, Jun 30, 2017 at 10:52:54AM +0530, Sharma, Shashank wrote: Regards Shashank On 6/27/2017 5:25 PM, Ville Syrjälä wrote: On Wed, Jun 21, 2017 at 04:04:04PM +0530, Shashank Sharma wrote: CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks. This block contains a map of indexes of CEA modes, which can support YCBCR 420 output also. To avoid multiple parsing of same CEA block, let's parse the sink information and get this map, before parsing CEA modes. This patch moves the call to drm_add_display_info function, before the mode parsing block. Signed-off-by: Shashank Sharma --- drivers/gpu/drm/drm_edid.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c index b4583f6..42934b2 100644 --- a/drivers/gpu/drm/drm_edid.c +++ b/drivers/gpu/drm/drm_edid.c @@ -4605,6 +4605,13 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) quirks = edid_get_quirks(edid); /* +* CEA-861-F adds ycbcr capability map block, for HDMI 2.0 sinks. +* To avoid multiple parsing of same block, lets parse that map +* from sink info, before parsing CEA modes. +*/ + drm_add_display_info(connector, edid); + This patch should come before the 4:2:0 mode parsing, no? Dint you ask me to move it later (in the previous series comments), for git-bisect regression type of changes ? I wanted it split out to help with bisecting. It should be early in the series because otherwise the rest makes no sense. And I suppose we should be able to push this in on its own right now. Just need a CI run for it, so maybe resesnd just this patch on its own. Ok, got it. - Shashank Otherwise I think this should be fine so Reviewed-by: Ville Syrjälä Thanks. + /* * EDID spec says modes should be preferred in this order: * - preferred detailed mode * - other detailed modes from base block @@ -4632,8 +4639,6 @@ int drm_add_edid_modes(struct drm_connector *connector, struct edid *edid) if (quirks & (EDID_QUIRK_PREFER_LARGE_60 | EDID_QUIRK_PREFER_LARGE_75)) edid_fixup_preferred(connector, quirks); - drm_add_display_info(connector, edid); - if (quirks & EDID_QUIRK_FORCE_6BPC) connector->display_info.bpc = 6; -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/2] drm/i915/skl+: Scaling not supported in IF-ID Interlace mode
GEN9+ Interlace fetch mode doesn't support pipe/plane scaling,
This patch adds check to fail the flip if pipe/plane scaling is
requested in Interlace fetch mode.
Changes since V1:
- move check to skl_update_scaler (ville)
- mode to adjusted_mode (ville)
- combine pipe/plane scaling check
Changes since V2:
- Indentation fix
- Added TODO to handle/reject NV12 with interlace mode
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4e03ca6c946f..059e74170a59 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4612,6 +4612,9 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
&crtc_state->scaler_state;
struct intel_crtc *intel_crtc =
to_intel_crtc(crtc_state->base.crtc);
+ struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
+ const struct drm_display_mode *adjusted_mode =
+ &crtc_state->base.adjusted_mode;
int need_scaling;
/*
@@ -4622,6 +4625,18 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
need_scaling = src_w != dst_w || src_h != dst_h;
/*
+* Scaling/fitting not supported in IF-ID mode in GEN9+
+* TODO: Interlace fetch mode doesn't support YUV420 planar formats.
+* Once NV12 is enabled, handle it here while allocating scaler
+* for NV12.
+*/
+ if (INTEL_GEN(dev_priv) >=9 && crtc_state->base.enable &&
+ need_scaling && adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
+ DRM_DEBUG_KMS("Pipe/Plane scaling not supported with IF-ID
mode\n");
+ return -EINVAL;
+ }
+
+ /*
* if plane is being disabled or scaler is no more required or force
detach
* - free scaler binded to this plane/crtc
* - in order to do this, update crtc->scaler_usage
--
2.13.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 0/2] Handle unsupported configuration with IF-ID
Gen9+ Interlace fetch mode doesn't support few plane configurations & pipe scaling. - Y-tile - 90/270 rotation - pipe/plane scaling - 420 planar formats Changes since V2: - Address review comments from ville Mahesh Kumar (2): drm/i915/skl+: Check for supported plane configuration in Interlace mode drm/i915/skl+: Scaling not supported in IF-ID Interlace mode drivers/gpu/drm/i915/intel_atomic_plane.c | 15 +++ drivers/gpu/drm/i915/intel_display.c | 15 +++ 2 files changed, 30 insertions(+) -- 2.13.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 1/2] drm/i915/skl+: Check for supported plane configuration in Interlace mode
In Gen9 platform Interlaced fetch mode doesn't support following plane
configuration:
- Y/Yf tiling
- 90/270 rotation
- YUV420 hybrid planar source pixel formats.
This patch adds check to fail the flip if any of the above configuration
is requested.
Changes since V1:
- handle checks in intel_plane_atomic_check_with_state (ville)
- takeout plane scaler checks combile with pipe scaler in next patch
Changes since V2:
- No need to check for NV12 as it need scaling, so it will be rejected
by scaling check (ville)
Signed-off-by: Mahesh Kumar
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 4325cb0a04f5..ee76fab7bb6f 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -114,6 +114,8 @@ int intel_plane_atomic_check_with_state(struct
intel_crtc_state *crtc_state,
struct drm_i915_private *dev_priv = to_i915(plane->dev);
struct drm_plane_state *state = &intel_state->base;
struct intel_plane *intel_plane = to_intel_plane(plane);
+ const struct drm_display_mode *adjusted_mode =
+ &crtc_state->base.adjusted_mode;
int ret;
/*
@@ -173,6 +175,19 @@ int intel_plane_atomic_check_with_state(struct
intel_crtc_state *crtc_state,
if (ret)
return ret;
+ /*
+* Y-tiling is not supported in IF-ID Interlace mode in
+* GEN9 and above.
+*/
+ if (state->fb && INTEL_GEN(dev_priv) >= 9 && crtc_state->base.enable &&
+ adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
+ if (state->fb->modifier == I915_FORMAT_MOD_Y_TILED ||
+ state->fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
+ DRM_DEBUG_KMS("Y/Yf tiling not supported in IF-ID
mode\n");
+ return -EINVAL;
+ }
+ }
+
/* FIXME pre-g4x don't work like this */
if (intel_state->base.visible)
crtc_state->active_planes |= BIT(intel_plane->id);
--
2.13.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND-CI v4 15/15] drm/i915/glk: set HDMI 2.0 identifier
On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> This patch sets the is_hdmi2_src identifier in drm connector
> for GLK platform. GLK contains a native HDMI 2.0 controller.
> This identifier will help the EDID handling functions to save
> lot of work which is specific to HDMI 2.0 sources.
>
> V3: Added this patch
> V4: Rebase
>
> Signed-off-by: Shashank Sharma
This and patches 12 and 14 look fine to me. I'm not sure about the patch split,
maybe they should be squashed together in the end? And perhaps patch 10 and 13
too if the refactor I proposed are separate prep patches. But anyway, you can
use
Reviewed-by: Ander Conselvan de Oliveira
on those if you want.
> ---
> drivers/gpu/drm/i915/intel_hdmi.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> b/drivers/gpu/drm/i915/intel_hdmi.c
> index 3bd9af3..0d9d088 100644
> --- a/drivers/gpu/drm/i915/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> @@ -1979,6 +1979,9 @@ void intel_hdmi_init_connector(struct
> intel_digital_port *intel_dig_port,
> connector->doublescan_allowed = 0;
> connector->stereo_allowed = 1;
>
> + if (IS_GEMINILAKE(dev_priv))
> + connector->ycbcr_420_allowed = true;
> +
> intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
>
> switch (port) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND-CI v4 04/15] drm/edid: parse YCBCR 420 videomodes from EDID
Regards
Shashank
On 6/30/2017 5:28 PM, Ville Syrjälä wrote:
On Fri, Jun 30, 2017 at 10:47:48AM +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/27/2017 5:22 PM, Ville Syrjälä wrote:
On Wed, Jun 21, 2017 at 04:04:02PM +0530, Shashank Sharma wrote:
HDMI 2.0 spec adds support for YCBCR420 sub-sampled output.
CEA-861-F adds two new blocks in EDID's CEA extension blocks,
to provide information about sink's YCBCR420 output capabilities.
These blocks are:
- YCBCR420vdb(YCBCR 420 video data block):
This block contains VICs of video modes, which can be sopported only
in YCBCR420 output mode (Not in RGB/YCBCR444/422. Its like a normal
SVD block, valid for YCBCR420 modes only.
- YCBCR420cmdb(YCBCR 420 capability map data block):
This block gives information about video modes which can support
YCBCR420 output mode also (along with RGB,YCBCR444/422 etc) This
block contains a bitmap index of normal svd videomodes, which can
support YCBCR420 output too.
So if bit 0 from first vcb byte is set, first video mode in the svd
list can support YCBCR420 output too. Bit 1 means second video mode
from svd list can support YCBCR420 output too, and so on.
This patch adds two bitmaps in display's hdmi_info structure, one each
for VCB and VDB modes. If the source is HDMI 2.0 capable, this patch
adds:
- VDB modes (YCBCR 420 only modes) in connector's mode list, also makes
an entry in the vdb_bitmap per vic.
- VCB modes (YCBCR 420 also modes) only entry in the vcb_bitmap.
Cc: Ville Syrjala
Cc: Jose Abreu
Cc: Emil Velikov
V2: Addressed
Review comments from Emil:
- Use 1ULL< 64 modes in capability map block.
- Use y420cmdb in function names and macros while dealing with vcb
to be aligned with spec.
- Move the display information parsing block ahead of mode parsing
blocks.
V3: Addressed design/review comments from Ville
- Do not add flags in video modes, else we have to expose them to user
- There should not be a UABI change, and kernel should detect the
choice of the output based on type of mode, and the bitmaps.
- Use standard bitops from kernel bitmap header, instead of calculating
bit positions manually.
V4: Addressed review comments from Ville:
- s/ycbcr_420_vdb/y420vdb
- s/ycbcr_420_vcb/y420cmdb
- Be less verbose on description of do_y420vdb_modes
- Move newmode variable in the loop scope.
- Use svd_to_vic() to get a VIC, instead of 0x7f
- Remove bitmap description for CMDB modes & VDB modes
- Dont add connector->ycbcr_420_allowed check for cmdb modes
- Remove 'len' variable, in is_y420cmdb function, which is used
only once
- Add length check in is_y420vdb function
- Remove unnecessary if (!db) check in function parse_y420cmdb_bitmap
- Do not add print about YCBCR 420 modes
- Fix indentation in few places
- Move ycbcr420_dc_modes in next patch, where its used
- Add a separate patch for movement of drm_add_display_info()
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_edid.c | 157
+++-
include/drm/drm_connector.h | 20 ++
2 files changed, 174 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index e2d1b30..8c7e73b 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2781,7 +2781,9 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
#define VIDEO_BLOCK 0x02
#define VENDOR_BLOCK0x03
#define SPEAKER_BLOCK0x04
-#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_CAPABILITY_BLOCK 0x07
+#define VIDEO_DATA_BLOCK_420 0x0E
+#define VIDEO_CAP_BLOCK_Y420CMDB 0x0F
#define EDID_BASIC_AUDIO (1 << 6)
#define EDID_CEA_YCRCB444(1 << 5)
#define EDID_CEA_YCRCB422(1 << 4)
@@ -3153,15 +3155,79 @@ drm_display_mode_from_vic_index(struct drm_connector
*connector,
return newmode;
}
+/*
+ * do_y420vdb_modes - Parse YCBCR 420 only modes
+ * @connector: connector corresponding to the HDMI sink
+ * @svds: start of the data block of CEA YCBCR 420 VDB
+ * @len: length of the CEA YCBCR 420 VDB
+ *
+ * Parse the CEA-861-F YCBCR 420 Video Data Block (Y420VDB)
+ * which contains modes which can be supported in YCBCR 420
+ * output format only.
+ */
+static int do_y420vdb_modes(struct drm_connector *connector,
+ const u8 *svds, u8 svds_len)
+{
+ int modes = 0, i;
+ struct drm_device *dev = connector->dev;
+ struct drm_display_info *info = &connector->display_info;
+ struct drm_hdmi_info *hdmi = &info->hdmi;
+
+ for (i = 0; i < svds_len; i++) {
+ u8 vic = svd_to_vic(svds[i]);
+ struct drm_display_mode *newmode;
+
+ newmode = drm_mode_duplicate(dev, &edid_cea_modes[vic]);
+ if (!newmode)
+ break;
+ bitmap_s
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_mocs_settings: Fix LNCFCMOCS testing and extract the subtests
On Wed, 2017-06-28 at 17:41 +0200, Michał Winiarski wrote:
> Testing LNCFCMOCS values on non-render engines is tricky. The values
> in
> those registers are lost on RC6, which means that if users of non-
> render
> engines want to see the proper values, they need to obtain a
> forcewake
> and execute something on render (relying on it to restore the values)
> before using non-render engine.
> Previous version of the test did exactly that - we were relying on
> the
> fact that we're taking forcewake (hidden by
> intel_register_access_init,
> even though the test is not doing any mmio accesses) before iterating
> through engines (and render is before other engines, so job done).
> I really hope that this is not an ABI and those registers are not
> used
> on non-render in any way. Let's limit testing LNCFCMOCS to render
> engine only.
> The other non-render issue is that when we're using I915_EXEC_BSD, we
> can't be sure which BSD ring we'll end up executing on. Let's
> explicitly select BSD1 and BSD2 in our tests.
> While we're here, let's also remove the duplicated code and add some
> structure by extracting moving more content into subtests.
> We're only doing tests that involve "dirtying" the registers for the
> render engine - since it's the only one that has those registers in
> its
> context.
>
> Cc: Arkadiusz Hiler
> Cc: Chris Wilson
> Cc: David Weinehall
> Cc: Łukasz Kałamarz
> Signed-off-by: Michał Winiarski
Reviewed-By: Lukasz Kalamarz
--
Lukasz
> ---
> tests/gem_mocs_settings.c | 353 ++
>
> 1 file changed, 108 insertions(+), 245 deletions(-)
>
> diff --git a/tests/gem_mocs_settings.c b/tests/gem_mocs_settings.c
> index a96aa66..9760c0e 100644
> --- a/tests/gem_mocs_settings.c
> +++ b/tests/gem_mocs_settings.c
> @@ -32,14 +32,28 @@
> #include "igt_sysfs.h"
>
> #define MAX_NUMBER_MOCS_REGISTERS(64)
> -
> enum {
> NONE,
> RESET,
> + RC6,
> SUSPEND,
> - HIBERNATE
> + HIBERNATE,
> + MAX_MOCS_TEST_MODES
> +};
> +
> +static const char * const test_modes[] = {
> + [NONE] = "settings",
> + [RESET] = "reset",
> + [RC6] = "rc6",
> + [SUSPEND] = "suspend",
> + [HIBERNATE] = "hibernate"
> };
>
> +#define MOCS_NON_DEFAULT_CTX (1<<0)
> +#define MOCS_DIRTY_VALUES(1<<1)
> +#define ALL_MOCS_FLAGS (MOCS_NON_DEFAULT_CTX | \
> + MOCS_DIRTY_VALUES)
> +
> #define GEN9_LNCFCMOCS0 (0xB020)/* L3 Cache
> Control base */
> #define GEN9_GFX_MOCS_0 (0xc800)/* Graphics
> MOCS base register*/
> #define GEN9_MFX0_MOCS_0 (0xc900)/* Media 0 MOCS base
> register*/
> @@ -117,19 +131,18 @@ static bool get_mocs_settings(int fd, struct
> mocs_table *table, bool dirty)
> return result;
> }
>
> +#define LOCAL_I915_EXEC_BSD1 (I915_EXEC_BSD | (1<<13))
> +#define LOCAL_I915_EXEC_BSD2 (I915_EXEC_BSD | (2<<13))
> +
> static uint32_t get_engine_base(uint32_t engine)
> {
> - /* Note we cannot test BSD1 or BSD2 due to limitations of
> current ANI */
> switch (engine) {
> - case I915_EXEC_BSD: return GEN9_MFX0_MOCS_0;
> -/*
> - case I915_EXEC_BSD1:return GEN9_MFX0_MOCS_0;
> - case I915_EXEC_BSD2:return GEN9_MFX1_MOCS_0;
> -*/
> - case I915_EXEC_RENDER: return GEN9_GFX_MOCS_0;
> - case I915_EXEC_BLT: return GEN9_BLT_MOCS_0;
> - case I915_EXEC_VEBOX: return GEN9_VEBOX_MOCS_0;
> - default:return 0;
> + case LOCAL_I915_EXEC_BSD1: return GEN9_MFX0_MOCS_0;
> + case LOCAL_I915_EXEC_BSD2: return GEN9_MFX1_MOCS_0;
> + case I915_EXEC_RENDER: return
> GEN9_GFX_MOCS_0;
> + case I915_EXEC_BLT: return GEN9_BLT_MOCS_0;
> + case I915_EXEC_VEBOX: return
> GEN9_VEBOX_MOCS_0;
> + default:return 0;
> }
> }
>
> @@ -252,7 +265,7 @@ static void check_control_registers(int fd,
> uint32_t ctx_id,
> bool dirty)
> {
> - const uint32_t reg_base = get_engine_base(engine);
> + const uint32_t reg_base = get_engine_base(engine);
> uint32_t dst_handle = gem_create(fd, 4096);
> uint32_t *read_regs;
> struct mocs_table table;
> @@ -299,6 +312,7 @@ static void check_l3cc_registers(int fd,
> read_regs = gem_mmap__cpu(fd, dst_handle, 0, 4096,
> PROT_READ);
>
> gem_set_domain(fd, dst_handle, I915_GEM_DOMAIN_CPU, 0);
> +
> for (index = 0; index < table.size / 2; index++) {
> igt_assert_eq_u32(read_regs[index] & 0x,
> table.table[index *
> 2].l3cc_value);
> @@ -314,183 +328,65 @@ static void check_l3cc_registers(int fd,
> gem_close(fd, dst_handle);
> }
>
> -static void test_context_mocs_values(int fd, unsigned engine)
> -{
> - int local_fd;
> - uint32_t ctx_id = 0;
> -
> - local_fd = fd;
> - if (l
Re: [Intel-gfx] [RESEND-CI v4 15/15] drm/i915/glk: set HDMI 2.0 identifier
Regards
Shashank
On 6/30/2017 5:37 PM, Ander Conselvan De Oliveira wrote:
On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
This patch sets the is_hdmi2_src identifier in drm connector
for GLK platform. GLK contains a native HDMI 2.0 controller.
This identifier will help the EDID handling functions to save
lot of work which is specific to HDMI 2.0 sources.
V3: Added this patch
V4: Rebase
Signed-off-by: Shashank Sharma
This and patches 12 and 14 look fine to me. I'm not sure about the patch split,
maybe they should be squashed together in the end? And perhaps patch 10 and 13
too if the refactor I proposed are separate prep patches.
In fact this is exactly how I prepared at the first place, keeping all
the crtc/pipe level changes together.
But then I thought the patch might be touching too many things, and
might be too big or complex for
review, that's why I had split into 3-4 small patches :-)
But anyway, you can
use
Reviewed-by: Ander Conselvan de Oliveira
on those if you want.
Thanks, I guess this applies for 12,14,10,13 and 15 (with a separate
patch for CSC coeff handling).
Please correct me if I misunderstood.
- Shashank
---
drivers/gpu/drm/i915/intel_hdmi.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index 3bd9af3..0d9d088 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1979,6 +1979,9 @@ void intel_hdmi_init_connector(struct intel_digital_port
*intel_dig_port,
connector->doublescan_allowed = 0;
connector->stereo_allowed = 1;
+ if (IS_GEMINILAKE(dev_priv))
+ connector->ycbcr_420_allowed = true;
+
intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
switch (port) {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/skl+: Check for supported plane configuration in Interlace mode
On Fri, Jun 30, 2017 at 05:40:59PM +0530, Mahesh Kumar wrote:
> In Gen9 platform Interlaced fetch mode doesn't support following plane
> configuration:
> - Y/Yf tiling
> - 90/270 rotation
The rotation check seems to be missing from the code?
> - YUV420 hybrid planar source pixel formats.
>
> This patch adds check to fail the flip if any of the above configuration
> is requested.
>
> Changes since V1:
> - handle checks in intel_plane_atomic_check_with_state (ville)
> - takeout plane scaler checks combile with pipe scaler in next patch
> Changes since V2:
> - No need to check for NV12 as it need scaling, so it will be rejected
>by scaling check (ville)
>
> Signed-off-by: Mahesh Kumar
> ---
> drivers/gpu/drm/i915/intel_atomic_plane.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/intel_atomic_plane.c
> index 4325cb0a04f5..ee76fab7bb6f 100644
> --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> @@ -114,6 +114,8 @@ int intel_plane_atomic_check_with_state(struct
> intel_crtc_state *crtc_state,
> struct drm_i915_private *dev_priv = to_i915(plane->dev);
> struct drm_plane_state *state = &intel_state->base;
> struct intel_plane *intel_plane = to_intel_plane(plane);
> + const struct drm_display_mode *adjusted_mode =
> + &crtc_state->base.adjusted_mode;
> int ret;
>
> /*
> @@ -173,6 +175,19 @@ int intel_plane_atomic_check_with_state(struct
> intel_crtc_state *crtc_state,
> if (ret)
> return ret;
>
> + /*
> + * Y-tiling is not supported in IF-ID Interlace mode in
> + * GEN9 and above.
> + */
> + if (state->fb && INTEL_GEN(dev_priv) >= 9 && crtc_state->base.enable &&
> + adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
> + if (state->fb->modifier == I915_FORMAT_MOD_Y_TILED ||
> + state->fb->modifier == I915_FORMAT_MOD_Yf_TILED) {
> + DRM_DEBUG_KMS("Y/Yf tiling not supported in IF-ID
> mode\n");
> + return -EINVAL;
> + }
> + }
> +
> /* FIXME pre-g4x don't work like this */
> if (intel_state->base.visible)
> crtc_state->active_planes |= BIT(intel_plane->id);
> --
> 2.13.0
--
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/5] drm/i915/gen9+: Don't remove secondary power well requests
On Thu, Jun 29, 2017 at 01:06:01PM -0700, Rodrigo Vivi wrote:
> This patch makes sense and seems the right thing to do...
>
> However removing the sanitize with I915_WRITE(*, val & ~mask);
> doesn't give me very comfortable...
>
> I've seem many power well timeouts on cnl due the lack of that sanitize...
> I will try to save some time here and do some experiments with cnl.
Thanks for the review.
You shouldn't get any timeouts due to this change. On CNL as on any other
GEN9+ platform previously you got a timeout when disabling power well 1
during the display uninit sequence, which was due to DMC's own request on
PW#1. After this change we'll detect this scenario and won't wait for
the power well to get disabled.
--Imre
>
> On Thu, Jun 29, 2017 at 8:37 AM, Imre Deak wrote:
> > So far in an attempt to make sure all power wells get disabled during
> > display uninitialization the driver removed any secondary request bits
> > (BIOS, KVMR, DEBUG) that were set for a given power well. The known
> > source for these requests was DMC's request on power well 1 and the misc
> > IO power well. Since DMC is inactive (DC states are disabled) at the
> > point we disable these power wells, there shouldn't be any reason to
> > leave them on. However there are two problems with the above
> > assumption: Bspec requires that the misc IO power well stays enabled
> > (without providing a reason) and there can be KVMR requests that we
> > can't remove anyway (the KVMR request register is R/O). Atm, a KVMR
> > request can trigger a timeout WARN when trying to disable power wells.
> >
> > To make the code aligned to Bspec and to get rid of the KVMR WARN, don't
> > try to remove the secondary requests, only detect them and stop polling
> > for the power well disabled state when any one is set.
> >
> > Also add a comment about the timeout values required by Bspec when
> > enabling power wells and the fact that waiting for them to get disabled
> > is not required by Bspec.
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98564
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 109
> > ++--
> > 1 file changed, 63 insertions(+), 46 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 1fc75e6..2fe715b 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -341,6 +341,59 @@ static void skl_power_well_pre_disable(struct
> > drm_i915_private *dev_priv,
> > 1 << PIPE_C | 1 << PIPE_B);
> > }
> >
> > +static void gen9_wait_for_power_well_enable(struct drm_i915_private
> > *dev_priv,
> > + struct i915_power_well
> > *power_well)
> > +{
> > + int id = power_well->id;
> > +
> > + /* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
> > + WARN_ON(intel_wait_for_register(dev_priv,
> > + HSW_PWR_WELL_DRIVER,
> > + SKL_POWER_WELL_STATE(id),
> > + SKL_POWER_WELL_STATE(id),
> > + 1));
> > +}
> > +
> > +static u32 gen9_power_well_requesters(struct drm_i915_private *dev_priv,
> > int id)
> > +{
> > + u32 req_mask = SKL_POWER_WELL_REQ(id);
> > + u32 ret;
> > +
> > + ret = I915_READ(HSW_PWR_WELL_BIOS) & req_mask ? 1 : 0;
> > + ret |= I915_READ(HSW_PWR_WELL_DRIVER) & req_mask ? 2 : 0;
> > + ret |= I915_READ(HSW_PWR_WELL_KVMR) & req_mask ? 4 : 0;
> > + ret |= I915_READ(HSW_PWR_WELL_DEBUG) & req_mask ? 8 : 0;
> > +
> > + return ret;
> > +}
> > +
> > +static void gen9_wait_for_power_well_disable(struct drm_i915_private
> > *dev_priv,
> > +struct i915_power_well
> > *power_well)
> > +{
> > + int id = power_well->id;
> > + bool disabled;
> > + u32 reqs;
> > +
> > + /*
> > +* Bspec doesn't require waiting for PWs to get disabled, but still
> > do
> > +* this for paranoia. The known cases where a PW will be forced on:
> > +* - a KVMR request on any power well via the KVMR request register
> > +* - a DMC request on PW1 and MISC_IO power wells via the BIOS and
> > +* DEBUG request registers
> > +* Skip the wait in case any of the request bits are set and print a
> > +* diagnostic message.
> > +*/
> > + wait_for((disabled = !(I915_READ(HSW_PWR_WELL_DRIVER) &
> > + SKL_POWER_WELL_STATE(id))) ||
> > +(reqs = gen9_power_well_requesters(dev_priv, id)), 1);
> > + if (disabled)
> > + return;
> > +
> > + DRM_DEBUG_KMS("%s forced on (bios:%d driver:%d kvmr:%d debug:%d)\n",
> > + power_well->name,
> > +
Re: [Intel-gfx] [PATCH] drm/atomic: Add missing drm_atomic_state_clear to atomic_remove_fb
On Thu, Jun 29, 2017 at 05:17:39PM +0300, Ville Syrjälä wrote:
> On Thu, Jun 29, 2017 at 04:57:25PM +0300, Ville Syrjälä wrote:
> > On Thu, Jun 29, 2017 at 01:59:54PM +0200, Maarten Lankhorst wrote:
> > > Signed-off-by: Maarten Lankhorst
> > > ---
> > > drivers/gpu/drm/drm_framebuffer.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_framebuffer.c
> > > b/drivers/gpu/drm/drm_framebuffer.c
> > > index fc8ef42203ec..b3ef4f1c2630 100644
> > > --- a/drivers/gpu/drm/drm_framebuffer.c
> > > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > > @@ -832,6 +832,7 @@ static int atomic_remove_fb(struct drm_framebuffer
> > > *fb)
> > > drm_atomic_clean_old_fb(dev, plane_mask, ret);
> > >
> > > if (ret == -EDEADLK) {
> > > + drm_atomic_state_clear(state);
> >
> > Hmm. We seem to be missing this all over. Do those other places need it
> > as well? Hard to say without a commit message explaining why we need it
> > here.
> >
> > Should we just back it into drm_modeset_backoff() if it's always needed?
>
> s/back/bake/
It's not needed everywhere, and that's because you can do the modeset_lock
dance without necessarily doing an atomic transaction (e.g. hw state
readout on boot or load detect). Or the atomic transaction is happening
somewhere else from where the ctx backoff is handled (e.g. for legacy
paths the core code handles the w/w dance since my recent rework, whereas
compat helpers handle the retry for the atomic side).
But yeah if you do an atomic commit, you must have the state_clear in the
EDEADLK path somewhere. Maybe we could do a trick with lockdep annotations
(make the state another ww mutex that nests within the modeset_lock class,
or something like that) to ensure that no one ever forgets to clear this
up? But that's a bit tricky, since on successful commit we hand the state
over to the driver and must _not_ clear it, this is only for the backoff
case (even on any other errors it's not needed, since we just kfree
everything).
-Daniel
>
> >
> > > drm_modeset_backoff(&ctx);
> > > goto retry;
> > > }
> > > --
> > > 2.11.0
> > >
> > > ___
> > > dri-devel mailing list
> > > dri-de...@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Ville Syrjälä
> > Intel OTC
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/atomic: Add missing drm_atomic_state_clear to atomic_remove_fb
On Thu, Jun 29, 2017 at 01:59:54PM +0200, Maarten Lankhorst wrote:
> Signed-off-by: Maarten Lankhorst
With a real commit message (just explain why it's needed):
Reviewed-by: Daniel Vetter
Also needs
Fixes: db8f6403e88a ("drm: Convert drm_framebuffer_remove to atomic, v4.")
Cc: sta...@vger.kernel.org # v4.12-rc1+
Please push to drm-misc-next-fixes so Sean can send a pull for it for
4.13.
Thanks, Daniel
> ---
> drivers/gpu/drm/drm_framebuffer.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/drm_framebuffer.c
> b/drivers/gpu/drm/drm_framebuffer.c
> index fc8ef42203ec..b3ef4f1c2630 100644
> --- a/drivers/gpu/drm/drm_framebuffer.c
> +++ b/drivers/gpu/drm/drm_framebuffer.c
> @@ -832,6 +832,7 @@ static int atomic_remove_fb(struct drm_framebuffer *fb)
> drm_atomic_clean_old_fb(dev, plane_mask, ret);
>
> if (ret == -EDEADLK) {
> + drm_atomic_state_clear(state);
> drm_modeset_backoff(&ctx);
> goto retry;
> }
> --
> 2.11.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Handle unsupported configuration with IF-ID (rev3)
== Series Details == Series: Handle unsupported configuration with IF-ID (rev3) URL : https://patchwork.freedesktop.org/series/26546/ State : failure == Summary == Series 26546v3 Handle unsupported configuration with IF-ID https://patchwork.freedesktop.org/api/1.0/series/26546/revisions/3/mbox/ Test core_auth: Subgroup basic-auth: pass -> INCOMPLETE (fi-skl-6700k) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: dmesg-warn -> PASS (fi-pnv-d510) fdo#101597 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fi-bdw-5557u total:279 pass:264 dwarn:0 dfail:0 fail:3 skip:11 time:434s fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 time:430s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:352s fi-bsw-n3050 total:279 pass:239 dwarn:0 dfail:0 fail:3 skip:36 time:512s fi-bxt-j4205 total:279 pass:256 dwarn:0 dfail:0 fail:3 skip:19 time:510s fi-byt-j1900 total:279 pass:250 dwarn:1 dfail:0 fail:3 skip:24 time:477s fi-byt-n2820 total:279 pass:246 dwarn:1 dfail:0 fail:3 skip:28 time:480s fi-glk-2atotal:279 pass:256 dwarn:0 dfail:0 fail:3 skip:19 time:585s fi-hsw-4770 total:279 pass:259 dwarn:0 dfail:0 fail:3 skip:16 time:431s fi-hsw-4770r total:279 pass:259 dwarn:0 dfail:0 fail:3 skip:16 time:417s fi-ilk-650 total:279 pass:225 dwarn:0 dfail:0 fail:3 skip:50 time:414s fi-ivb-3520m total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:487s fi-ivb-3770 total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:467s fi-kbl-7500u total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:462s fi-kbl-7560u total:279 pass:265 dwarn:0 dfail:0 fail:3 skip:10 time:559s fi-kbl-r total:279 pass:256 dwarn:1 dfail:0 fail:3 skip:18 time:563s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:564s fi-skl-6260u total:279 pass:265 dwarn:0 dfail:0 fail:3 skip:10 time:453s fi-skl-6700hqtotal:279 pass:219 dwarn:1 dfail:0 fail:33 skip:24 time:328s fi-skl-6700k total:42 pass:0dwarn:0 dfail:0 fail:0 skip:0 fi-skl-6770hqtotal:279 pass:264 dwarn:0 dfail:0 fail:4 skip:10 time:457s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:433s fi-snb-2520m total:279 pass:247 dwarn:0 dfail:0 fail:3 skip:28 time:532s fi-snb-2600 total:279 pass:246 dwarn:0 dfail:0 fail:3 skip:29 time:405s 052c9c3244e7417a28637f8f039db7a0244fad31 drm-tip: 2017y-06m-30d-11h-41m-52s UTC integration manifest 1b017b8 drm/i915/skl+: Scaling not supported in IF-ID Interlace mode 88397c2c drm/i915/skl+: Check for supported plane configuration in Interlace mode == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5078/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/atomic: Refactor drm_atomic_state_realloc_connectors()
On Thu, Jun 29, 2017 at 04:49:44PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Pull the code to reallocate the state->connectors[] array into a
> helper function. We'll have another use for this later.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_atomic.c | 43 +--
> include/drm/drm_atomic.h | 5 +
> 2 files changed, 34 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 095e87278a88..a9f02b214fc6 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1043,6 +1043,32 @@ drm_atomic_get_private_obj_state(struct
> drm_atomic_state *state, void *obj,
> }
> EXPORT_SYMBOL(drm_atomic_get_private_obj_state);
>
> +int drm_atomic_state_realloc_connectors(struct drm_device *dev,
> + struct drm_atomic_state *state,
> + int index)
Needs some pretty kerneldoc, best with some explanation why/when drivers
might want to use this (i.e. when they're constructing their own state for
special reasons like hw state read-out or recovery after a hw reset or
whatever). Commit message should explain that too, but better to stuff it
into the kerneldoc. With that addressed:
Reviewed-by: Daniel Vetter
> +{
> + struct drm_mode_config *config = &dev->mode_config;
> + struct __drm_connnectors_state *c;
> + int alloc = max(index + 1, config->num_connector);
> +
> + if (index < state->num_connector)
> + return 0;
> +
> + c = krealloc(state->connectors,
> + alloc * sizeof(*state->connectors), GFP_KERNEL);
> + if (!c)
> + return -ENOMEM;
> +
> + state->connectors = c;
> + memset(&state->connectors[state->num_connector], 0,
> +sizeof(*state->connectors) * (alloc - state->num_connector));
> +
> + state->num_connector = alloc;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_atomic_state_realloc_connectors);
> +
> /**
> * drm_atomic_get_connector_state - get connector state
> * @state: global atomic state object
> @@ -1074,20 +1100,9 @@ drm_atomic_get_connector_state(struct drm_atomic_state
> *state,
>
> index = drm_connector_index(connector);
>
> - if (index >= state->num_connector) {
> - struct __drm_connnectors_state *c;
> - int alloc = max(index + 1, config->num_connector);
> -
> - c = krealloc(state->connectors, alloc *
> sizeof(*state->connectors), GFP_KERNEL);
> - if (!c)
> - return ERR_PTR(-ENOMEM);
> -
> - state->connectors = c;
> - memset(&state->connectors[state->num_connector], 0,
> -sizeof(*state->connectors) * (alloc -
> state->num_connector));
> -
> - state->num_connector = alloc;
> - }
> + ret = drm_atomic_state_realloc_connectors(connector->dev, state, index);
> + if (ret)
> + return ERR_PTR(ret);
>
> if (state->connectors[index].state)
> return state->connectors[index].state;
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 0196f264a418..5596ad58bcdc 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -324,6 +324,11 @@ drm_atomic_get_private_obj_state(struct drm_atomic_state
> *state,
> void *obj,
> const struct drm_private_state_funcs *funcs);
>
> +int __must_check
> +drm_atomic_state_realloc_connectors(struct drm_device *dev,
> + struct drm_atomic_state *state,
> + int index);
> +
> /**
> * drm_atomic_get_existing_crtc_state - get crtc state, if it exists
> * @state: global atomic state object
> --
> 2.13.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts
On Fri, 30 Jun 2017, Ville Syrjälä wrote:
> On Thu, Jun 29, 2017 at 02:10:38PM -0700, Manasi Navare wrote:
>> This patch fixes the DP AUX CH timeouts observed during CI IGT
>> tests thus fixing the CI failures. This is done by adding a
>> quirk for a particular PCI device that requires the panel power
>> cycle delay (T12) to be set to 800ms which is 300msecs more than
>> the minimum value specified in the eDP spec. So a quirk is
>> implemented for that specific PCI device.
>>
>> v3:
>> * Change some comments, specify the delay as 800 * 10 (Ville)
>> v2:
>> * Change the function and variable names to from PPS_T12_
>> to _T12 since it is a T12 delay (Clint)
>>
>> Fixes: FDO #101144 #101515 #101154 #101167
>
> That's not how we do it.
Indeed.
Fixes: is used to indicate another commit that this patch fixes. See
Documentation/process/submitting-patches.rst. Does one exist here?
Bugzilla links are tagged using:
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101144
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101154
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101167
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101515
See git log for examples.
BR,
Jani.
>
> Also please look into git send-email --in-reply-to option. Review is
> easier if the patches aren't spread all over the mailbox.
>
>> Cc: Ville Syrjala
>> Cc: Clinton Taylor
>> Signed-off-by: Manasi Navare
>> Reviewed-by: Clinton Taylor
>> ---
>> drivers/gpu/drm/i915/i915_drv.h | 1 +
>> drivers/gpu/drm/i915/intel_display.c | 14 ++
>> drivers/gpu/drm/i915/intel_dp.c | 11 +++
>> 3 files changed, 26 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 427d10c..4327c8a 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -1168,6 +1168,7 @@ enum intel_sbi_destination {
>> #define QUIRK_INVERT_BRIGHTNESS (1<<2)
>> #define QUIRK_BACKLIGHT_PRESENT (1<<3)
>> #define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
>> +#define QUIRK_INCREASE_T12_DELAY (1<<6)
>>
>> struct intel_fbdev;
>> struct intel_fbc_work;
>> diff --git a/drivers/gpu/drm/i915/intel_display.c
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 4e03ca6..87dfde9 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -14765,6 +14765,17 @@ static void quirk_backlight_present(struct
>> drm_device *dev)
>> DRM_INFO("applying backlight present quirk\n");
>> }
>>
>> +/* Toshiba Satellite P50-C-18C requires T12 delay to be min 800ms
>> + * which is 300 ms greater than eDP spec T12 min.
>> + */
>> +static void quirk_increase_t12_delay(struct drm_device *dev)
>> +{
>> +struct drm_i915_private *dev_priv = to_i915(dev);
>> +
>> +dev_priv->quirks |= QUIRK_INCREASE_T12_DELAY;
>> +DRM_INFO("Applying T12 delay quirk\n");
>> +}
>> +
>> struct intel_quirk {
>> int device;
>> int subsystem_vendor;
>> @@ -14848,6 +14859,9 @@ static struct intel_quirk intel_quirks[] = {
>>
>> /* Dell Chromebook 11 (2015 version) */
>> { 0x0a16, 0x1028, 0x0a35, quirk_backlight_present },
>> +
>> +/* Toshiba Satellite P50-C-18C */
>> +{ 0x191B, 0x1179, 0xF840, quirk_increase_t12_delay },
>> };
>>
>> static void intel_init_quirks(struct drm_device *dev)
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index 67bc8a7a..4d7e510 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -5230,6 +5230,17 @@ intel_dp_init_panel_power_sequencer(struct drm_device
>> *dev,
>> intel_pps_dump_state("cur", &cur);
>>
>> vbt = dev_priv->vbt.edp.pps;
>> +/* On Toshiba Satellite P50-C-18C system the VBT T12 delay
>> + * of 500ms appears to be too short. Ocassionally the panel
>> + * just fails to power back on. Increasing the delay to 800ms
>> + * seems sufficient to avpid this problem.a
> ^
> typo
>
> Otherwise looks OK to me.
>
>> + */
>> +if (dev_priv->quirks & QUIRK_INCREASE_T12_DELAY) {
>> +
>> +vbt.t11_t12 = max_t(u16, vbt.t11_t12, 800 * 10);
>> +DRM_DEBUG_KMS("Increasing T12 panel delay as per the quirk to
>> %d\n",
>> + vbt.t11_t12);
>> +}
>> /* T11_T12 delay is special and actually in units of 100ms, but zero
>> * based in the hw (so we need to add 100 ms). But the sw vbt
>> * table multiplies it with 1000 to make it in units of 100usec,
>> --
>> 2.1.4
--
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore
On Thu, Jun 29, 2017 at 04:49:48PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Introduce an rw_semaphore to protect the display commits. All normal
> commits use down_read() and hence can proceed in parallel, but GPU reset
> will use down_write() making sure no other commits are in progress when
> we have to pull the plug on the display engine on pre-g4x platforms.
> There are no modeset/gem locks taken inside __intel_atomic_commit_tail()
> itself, and we wait for all dependencies before the down_read(), and
> thus there is no chance of deadlocks with this scheme.
How does this solve the deadlock? Afaiui the deadlock is that the gpu
reset stopped unconditionally completing all requests before it did
anything else, including anything with the hw or taking modeset locks.
This ensured that any outstanding flips (we only had pageflips, no atomic
ones back then) could complete (although maybe displaying garbage). The
only thing we had to do was grab the locks (to avoid concurrent modesets)
and then we could happily nuke the hw (since the flips where lost in the
CS anyway), and restore it afterwards.
Then the TDR rewrite came around and broke that, which now makes atomic
time out waiting for the gpu to complete (because the gpu reset waits for
the modeset to complete first). Which means if you want to fix this
without breaking TDR, then you need to cancel the pending atomic commits.
That seems somewhat what you're attempting here with trying to figure out
what the latest hw-committed step is (but that function gets it wrong),
and lots more locking and stuff on top.
Why exactly can't we just go back to the old world of force-completing
dead requests on gen4 and earlier? That would be tons simpler imo instead
of throwing a pile of hacks (which really needs a complete rewrite of the
atomic code in i915) in as a work-around. We didn't have TDR on gen4 and
earlier for years, going back to that isn't going to hurt anyone.
Making working gen4 gpu reset contigent on cancellable atomic commits and
the full commit queue is imo nuts.
-Daniel
>
> During reset we should be recommiting the state that was committed last.
> But for now we'll settle for recommiting the last state for each object.
> Hence we may commit things a bit too soon when a GPU reset occurs. The
> rw_semaphore should guarantee that whatever state we observe in
> obj->state during reset sticks around while we do the commit. The
> obj->state pointer might change for some objects if another swap_state()
> occurs while we do our thing, so there migth be some theoretical
> mismatch which I tink we could avoid by grabbing the rw_semaphore also
> around the swap_state(), but for now I didn't do that.
>
> Another source of mismatch can happen because we sometimes use the
> intel_crtc->config during the actual commit, and that only gets updated
> when we do the commuit. Hence we may get some state via ->state, some
> via the duplicated ->state, and some via ->config. We'll want to
> fix this all by tracking the commited state properly, but that will
> some bigger refactroing so for now we'll just choose to accept these
> potential mismatches.
>
> I left out the state readout from the post-reset display
> reinitialization as that still likes to clobber crtc->state etc.
> If we make it use a free standing atomic state and mke sure it doesn't
> need any locks we could reintroduce it. For now I just mark the
> post-reset display state as dirty as possible to make sure we
> reinitialize everything.
>
> One other potential issue remains in the form of display detection.
> Either we need to protect that with the same rw_semaphore as well, or
> perhaps it would be enough to force gmbus into bitbanging mode while
> the reset is happening and we don't have interrupts, and just across
> the actual hardware GPU reset we could hold the gmbus mutex.
>
> v2: Keep intel_prepare/finish_reset() outside struct_mutex (Chris)
> v3: Drop all the committed_state refactoring to make this less
> obnoxious to backport (Daniel)
>
> Cc: sta...@vger.kernel.org # for the brave
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101597
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99093
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101600
> Fixes: 4680816be336 ("drm/i915: Wait first for submission, before waiting for
> request completion")
> Fixes: 221fe7994554 ("drm/i915: Perform a direct reset of the GPU from the
> waiter")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/i915_irq.c | 44 +---
> drivers/gpu/drm/i915/intel_display.c | 199
> ---
> 3 files changed, 139 insertions(+), 106 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index effbe4f72a64..88ddd27f61b0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gp
Re: [Intel-gfx] [RESEND-CI v4 15/15] drm/i915/glk: set HDMI 2.0 identifier
On Fri, 2017-06-30 at 17:47 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/30/2017 5:37 PM, Ander Conselvan De Oliveira wrote:
> > On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> > > This patch sets the is_hdmi2_src identifier in drm connector
> > > for GLK platform. GLK contains a native HDMI 2.0 controller.
> > > This identifier will help the EDID handling functions to save
> > > lot of work which is specific to HDMI 2.0 sources.
> > >
> > > V3: Added this patch
> > > V4: Rebase
> > >
> > > Signed-off-by: Shashank Sharma
> >
> > This and patches 12 and 14 look fine to me. I'm not sure about the patch
> > split,
> > maybe they should be squashed together in the end? And perhaps patch 10 and
> > 13
> > too if the refactor I proposed are separate prep patches.
>
> In fact this is exactly how I prepared at the first place, keeping all
> the crtc/pipe level changes together.
> But then I thought the patch might be touching too many things, and
> might be too big or complex for
> review, that's why I had split into 3-4 small patches :-)
> > But anyway, you can
> > use
> >
> > Reviewed-by: Ander Conselvan de Oliveira
> >
> > on those if you want.
>
> Thanks, I guess this applies for 12,14,10,13 and 15 (with a separate
> patch for CSC coeff handling).
> Please correct me if I misunderstood.
This applies to 12, 14 and 15.
Ander
>
> - Shashank
> >
> >
> > > ---
> > > drivers/gpu/drm/i915/intel_hdmi.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
> > > b/drivers/gpu/drm/i915/intel_hdmi.c
> > > index 3bd9af3..0d9d088 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > > @@ -1979,6 +1979,9 @@ void intel_hdmi_init_connector(struct
> > > intel_digital_port *intel_dig_port,
> > > connector->doublescan_allowed = 0;
> > > connector->stereo_allowed = 1;
> > >
> > > + if (IS_GEMINILAKE(dev_priv))
> > > + connector->ycbcr_420_allowed = true;
> > > +
> > > intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
> > >
> > > switch (port) {
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore
On Fri, Jun 30, 2017 at 03:25:58PM +0200, Daniel Vetter wrote: > On Thu, Jun 29, 2017 at 04:49:48PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Introduce an rw_semaphore to protect the display commits. All normal > > commits use down_read() and hence can proceed in parallel, but GPU reset > > will use down_write() making sure no other commits are in progress when > > we have to pull the plug on the display engine on pre-g4x platforms. > > There are no modeset/gem locks taken inside __intel_atomic_commit_tail() > > itself, and we wait for all dependencies before the down_read(), and > > thus there is no chance of deadlocks with this scheme. > > How does this solve the deadlock? Afaiui the deadlock is that the gpu > reset stopped unconditionally completing all requests before it did > anything else, including anything with the hw or taking modeset locks. > > This ensured that any outstanding flips (we only had pageflips, no atomic > ones back then) could complete (although maybe displaying garbage). The > only thing we had to do was grab the locks (to avoid concurrent modesets) > and then we could happily nuke the hw (since the flips where lost in the > CS anyway), and restore it afterwards. > > Then the TDR rewrite came around and broke that, which now makes atomic > time out waiting for the gpu to complete (because the gpu reset waits for > the modeset to complete first). Which means if you want to fix this > without breaking TDR, then you need to cancel the pending atomic commits. > That seems somewhat what you're attempting here with trying to figure out > what the latest hw-committed step is (but that function gets it wrong), > and lots more locking and stuff on top. > > Why exactly can't we just go back to the old world of force-completing > dead requests on gen4 and earlier? That would be tons simpler imo instead > of throwing a pile of hacks (which really needs a complete rewrite of the > atomic code in i915) in as a work-around. We didn't have TDR on gen4 and > earlier for years, going back to that isn't going to hurt anyone. > > Making working gen4 gpu reset contigent on cancellable atomic commits and > the full commit queue is imo nuts. And if the GEM folks insist the old behavior can't be restored, then we just need a tailor-made get-out-of-jail card for gen4 gpu reset somewhere in i915_sw_fence. Force-completing all render requests atomic updates depend upon is imo the simplest solution to this, and we've had a driver that worked like that for years. And as long as TDR resubmits the batches the render-glitch will at most be temporary, but that's totally fine: We're killing the entire display block in the reset anyway, there's no way the user won't notice _that_ kind of glitch. Either way, let's please not over-engineer something for a dead-old platform when something much, much, much simpler worked for years, and should keep on working for another few years. -Daniel PS: One issue with atomic is that there's the small matter of having to wait for pending atomic commits to complete before we nuke the display, to avoid upsetting the display code. We could do that with a dummy commit, or just having a special wait_for_depencies that waits for all CRTC to complete their pending atomic updates. -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 5/5] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore
On Thu, Jun 29, 2017 at 10:26:08PM +0300, Ville Syrjälä wrote: > On Thu, Jun 29, 2017 at 06:57:30PM +0100, Chris Wilson wrote: > > Quoting ville.syrj...@linux.intel.com (2017-06-29 15:36:42) > > > From: Ville Syrjälä > > > > > > Introduce an rw_semaphore to protect the display commits. All normal > > > commits use down_read() and hence can proceed in parallel, but GPU reset > > > will use down_write() making sure no other commits are in progress when > > > we have to pull the plug on the display engine on pre-g4x platforms. > > > There are no modeset/gem locks taken inside __intel_atomic_commit_tail() > > > itself, and we wait for all dependencies before the down_read(), and > > > thus there is no chance of deadlocks with this scheme. > > > > This matches what I thought should be done (I didn't think of using > > rwsem just a mutex, nice touch). The point I got stuck on was what > > should be done after the reset? I expected another modeset to return the > > state back or otherwise the inflight would get confused? > > I guess that can happen. For instance, if we have a crtc_enable() in flight, > and then we do a reset before it gets committed we would end up doing > crtc_enable() twice in a row without a crtc_disable in between. For page > flips and such this shouldn't be a big deal in general. atomic commits are ordered. You have to wait for the previous ones to complete before you do a new one. If you don't do that, then all hell breaks loose. What you really can't do with atomic (without rewriting everything once more) is cancel a commit. Pre-atomic we could do that on gen4 since the mmio flips died with the gpu, but that's the one design change we need to cope with (plus TDR insisting it can't force-complete requests anymore). > > > During reset we should be recommiting the state that was committed last. > > > But for now we'll settle for recommiting the last state for each object. > > > > Ah, I guess that explains the above. What is the complication with > > restoring the current state as opposed to the next state? > > Well the main thing is just tracking which is the current state. That > just needs refactoring the .atomic_duplicate_state() calling convention > across the whole tree so that we can then duplicate the committed state > rather than the latest state. > > Also due to the commit_hw_done() being potentially done after the > modeset locks have been dropped, I don't think we can be certain > of it getting called in the same order as swap_state(), hence > when we track the committed state in commit_hw_done() we'll have > to have some way to figure out if our new state is in fact the > latest committed state for each object or if the calls got > reordered. We don't insert any dependencies between two commits > unless they touch the same active crtc, thus this reordering > seems very much possible. Dunno if we should add some way to add > such dependeencies whenever the same object is part of two otherwise > independent commits, or if we just want to try and work with the > reordered calls. My idea for the latter was some kind of seqno/age > counter on the object states that allows me to recongnize which > state is more recent. The object states aren't refcounted so hanging > on to the wrong pointer could cause an oops the next time we have to > perform a GPU reset. Atomic commits are strongly ordered on a given CRTC, so stuff can't be out-of-order within one. Across them the idea was to just add more CRTC states into the atomic commit to make sure stuff is ordered correctly. Laurent just pointed out that for switching planes that doesn't happen atm, but for i915 we should be safe (I guess I thought too much about i915 when typing the commit tracking code). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/atomic: Wait indefinitely and interruptibly for hw_done.
On Wed, Jun 28, 2017 at 03:28:12PM +0200, Maarten Lankhorst wrote:
> Without waiting for hw_done, previous atomic updates may dereference
> the wrong state and cause a lot of confusion. The real fix is fixing
> all obj->state to use the accessor macros, but for now wait
> indefinitely and interruptibly.
>
> Cc: Boris Brezillon
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: CK Hu
> Cc: Philipp Zabel
> Cc: Matthias Brugger
> Cc: Rob Clark
> Cc: Ben Skeggs
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Cc: Eric Anholt
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index f66b6c45cdd0..56e7729d993d 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2144,8 +2144,7 @@ EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
> int drm_atomic_helper_swap_state(struct drm_atomic_state *state,
> bool stall)
Needs improved kernel-doc:
* Returns:
*
* 0 on success. Can return -EINTR when @stall is true and the waiting for
* the previous commits has been interrupted.
With that Reviewed-by: Daniel Vetter
> {
> - int i;
> - long ret;
> + int i, ret;
> struct drm_connector *connector;
> struct drm_connector_state *old_conn_state, *new_conn_state;
> struct drm_crtc *crtc;
> @@ -2168,12 +2167,11 @@ int drm_atomic_helper_swap_state(struct
> drm_atomic_state *state,
> if (!commit)
> continue;
>
> - ret = wait_for_completion_timeout(&commit->hw_done,
> - 10*HZ);
> - if (ret == 0)
> - DRM_ERROR("[CRTC:%d:%s] hw_done timed out\n",
> - crtc->base.id, crtc->name);
> + ret =
> wait_for_completion_interruptible(&commit->hw_done);
> drm_crtc_commit_put(commit);
> +
> + if (ret)
> + return ret;
> }
> }
>
> --
> 2.11.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://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
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/1] drm/i915: Hold RPM wakelock while initializing OA buffer
Hi Daniel,
Any chance on getting this patch upstream?
Thanks a lot!
-
Lionel
On 29/06/17 10:35, Lionel Landwerlin wrote:
Cc: drm-intel-fi...@lists.freedesktop.org
Fixes: d79651522e89c ("drm/i915: Enable i915 perf stream for Haswell
OA unit")
On 27/06/17 18:39, Sagar Arun Kamble wrote:
OA buffer initialization involves access to HW registers to set
the OA base, head and tail. Ensure device is awake while setting
these. With this, all oa.ops are covered under RPM and forcewake
wakelock.
Cc: Lionel Landwerlin
Signed-off-by: Sagar Arun Kamble
---
drivers/gpu/drm/i915/i915_perf.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c
b/drivers/gpu/drm/i915/i915_perf.c
index 38c4440..9cd22f8 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2067,10 +2067,6 @@ static int i915_oa_stream_init(struct
i915_perf_stream *stream,
return ret;
}
-ret = alloc_oa_buffer(dev_priv);
-if (ret)
-goto err_oa_buf_alloc;
-
/* PRM - observability performance counters:
*
* OACONTROL, performance counter enable, note:
@@ -2086,6 +2082,10 @@ static int i915_oa_stream_init(struct
i915_perf_stream *stream,
intel_runtime_pm_get(dev_priv);
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+ret = alloc_oa_buffer(dev_priv);
+if (ret)
+goto err_oa_buf_alloc;
+
ret = dev_priv->perf.oa.ops.enable_metric_set(dev_priv);
if (ret)
goto err_enable;
@@ -2097,11 +2097,11 @@ static int i915_oa_stream_init(struct
i915_perf_stream *stream,
return 0;
err_enable:
-intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
-intel_runtime_pm_put(dev_priv);
free_oa_buffer(dev_priv);
err_oa_buf_alloc:
+intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+intel_runtime_pm_put(dev_priv);
if (stream->ctx)
oa_put_render_ctx_id(stream);
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 5/5] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore
On Fri, Jun 30, 2017 at 03:35:03PM +0200, Daniel Vetter wrote: > On Thu, Jun 29, 2017 at 10:26:08PM +0300, Ville Syrjälä wrote: > > On Thu, Jun 29, 2017 at 06:57:30PM +0100, Chris Wilson wrote: > > > Quoting ville.syrj...@linux.intel.com (2017-06-29 15:36:42) > > > > From: Ville Syrjälä > > > > > > > > Introduce an rw_semaphore to protect the display commits. All normal > > > > commits use down_read() and hence can proceed in parallel, but GPU reset > > > > will use down_write() making sure no other commits are in progress when > > > > we have to pull the plug on the display engine on pre-g4x platforms. > > > > There are no modeset/gem locks taken inside __intel_atomic_commit_tail() > > > > itself, and we wait for all dependencies before the down_read(), and > > > > thus there is no chance of deadlocks with this scheme. > > > > > > This matches what I thought should be done (I didn't think of using > > > rwsem just a mutex, nice touch). The point I got stuck on was what > > > should be done after the reset? I expected another modeset to return the > > > state back or otherwise the inflight would get confused? > > > > I guess that can happen. For instance, if we have a crtc_enable() in flight, > > and then we do a reset before it gets committed we would end up doing > > crtc_enable() twice in a row without a crtc_disable in between. For page > > flips and such this shouldn't be a big deal in general. > > atomic commits are ordered. You have to wait for the previous ones to > complete before you do a new one. If you don't do that, then all hell > breaks loose. What we're effectively doing here is inserting two new commits in the middle of the timeline, one to disable everything, and another one to re-enable everything. At the end of the the re-enable we would want the hardware state should match exactly what was there before the disable, hence any commits still in the timeline should work correctly. That is, their old_state will match the hardware state when it comes time to commit them. But we can only do that properly after we start to track the committed state. Without that tracking we can get into trouble wrt. the hardware state not matching the old state when it comes time to commit the new state. > > What you really can't do with atomic (without rewriting everything once > more) is cancel a commit. Pre-atomic we could do that on gen4 since the > mmio flips died with the gpu, but that's the one design change we need to > cope with (plus TDR insisting it can't force-complete requests anymore). > > > > > During reset we should be recommiting the state that was committed last. > > > > But for now we'll settle for recommiting the last state for each object. > > > > > > Ah, I guess that explains the above. What is the complication with > > > restoring the current state as opposed to the next state? > > > > Well the main thing is just tracking which is the current state. That > > just needs refactoring the .atomic_duplicate_state() calling convention > > across the whole tree so that we can then duplicate the committed state > > rather than the latest state. > > > > Also due to the commit_hw_done() being potentially done after the > > modeset locks have been dropped, I don't think we can be certain > > of it getting called in the same order as swap_state(), hence > > when we track the committed state in commit_hw_done() we'll have > > to have some way to figure out if our new state is in fact the > > latest committed state for each object or if the calls got > > reordered. We don't insert any dependencies between two commits > > unless they touch the same active crtc, thus this reordering > > seems very much possible. Dunno if we should add some way to add > > such dependeencies whenever the same object is part of two otherwise > > independent commits, or if we just want to try and work with the > > reordered calls. My idea for the latter was some kind of seqno/age > > counter on the object states that allows me to recongnize which > > state is more recent. The object states aren't refcounted so hanging > > on to the wrong pointer could cause an oops the next time we have to > > perform a GPU reset. > > Atomic commits are strongly ordered on a given CRTC, so stuff can't be > out-of-order within one. Across them the idea was to just add more CRTC > states into the atomic commit to make sure stuff is ordered correctly. And atomic commits not touching the same crtc will not be ordered in any way. Thus if they touch the same object (eg. disabled plane or connector) we can't currently tell if the commit_hw_done() calls happened in the same order as the swap_state() calls for that particular object. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/atomic: Change drm_atomic_helper_swap_state to return an error.
On Wed, Jun 28, 2017 at 03:28:11PM +0200, Maarten Lankhorst wrote:
> We want to change swap_state to wait indefinitely, but to do this
> swap_state should wait interruptibly. This requires propagating
> the error to each driver. All drivers have changes to deal with the
> clean up. In order to allow easy reverting, the commit that changes
> behavior is separate so someone only has to revert that for testing.
>
> Nouveau has a small bugfix, if drm_atomic_helper_wait_for_fences
> failed cleanup_planes was not called.
>
> Cc: Boris Brezillon
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Jani Nikula
> Cc: Sean Paul
> Cc: CK Hu
> Cc: Philipp Zabel
> Cc: Matthias Brugger
> Cc: Rob Clark
> Cc: Ben Skeggs
> Cc: Thierry Reding
> Cc: Jonathan Hunter
> Cc: Jyri Sarha
> Cc: Tomi Valkeinen
> Cc: Eric Anholt
> Cc: dri-de...@lists.freedesktop.org
> Cc: linux-ker...@vger.kernel.org
> Cc: intel-gfx@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> Cc: linux-arm-...@vger.kernel.org
> Cc: freedr...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Maarten Lankhorst
We kinda need to backport this to older kernels, but I don't really see
how :( Maybe we should split this up:
patch 1: Change to int return type
patches 2-(n-1): Driver conversions
patch n: __must_check addition
That would at least somewhat make this backportable ...
> ---
> drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c | 14 --
> drivers/gpu/drm/drm_atomic_helper.c | 18 --
> drivers/gpu/drm/i915/intel_display.c | 10 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 7 ++-
> drivers/gpu/drm/msm/msm_atomic.c | 14 +-
> drivers/gpu/drm/nouveau/nv50_display.c | 10 --
> drivers/gpu/drm/tegra/drm.c | 7 ++-
> drivers/gpu/drm/tilcdc/tilcdc_drv.c | 6 +-
> drivers/gpu/drm/vc4/vc4_kms.c| 21 +
> include/drm/drm_atomic_helper.h | 4 ++--
> 10 files changed, 82 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 516d9547d331..d4f787bf1d4a 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -544,9 +544,11 @@ static int atmel_hlcdc_dc_atomic_commit(struct
> drm_device *dev,
> goto error;
> }
>
> - /* Swap the state, this is the point of no return. */
> - drm_atomic_helper_swap_state(state, true);
Push the swap_state up over the commit setup (but after the allocation)
and there's no more a problem with unrolling.
> + ret = drm_atomic_helper_swap_state(state, true);
> + if (ret)
> + goto err_pending;
>
> + /* Swap state succeeded, this is the point of no return. */
> drm_atomic_state_get(state);
> if (async)
> queue_work(dc->wq, &commit->work);
> @@ -555,6 +557,14 @@ static int atmel_hlcdc_dc_atomic_commit(struct
> drm_device *dev,
>
> return 0;
>
> +err_pending:
> + /* Fail the commit, wake up any waiter. */
> + spin_lock(&dc->commit.wait.lock);
> + dc->commit.pending = false;
> + wake_up_all_locked(&dc->commit.wait);
> + spin_unlock(&dc->commit.wait.lock);
> +err_free:
> + kfree(commit);
> error:
> drm_atomic_helper_cleanup_planes(dev, state);
> return ret;
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index f1847d29ba3e..f66b6c45cdd0 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1387,10 +1387,8 @@ int drm_atomic_helper_commit(struct drm_device *dev,
>
> if (!nonblock) {
> ret = drm_atomic_helper_wait_for_fences(dev, state, true);
> - if (ret) {
> - drm_atomic_helper_cleanup_planes(dev, state);
> - return ret;
> - }
> + if (ret)
> + goto err;
> }
>
> /*
> @@ -1399,7 +1397,9 @@ int drm_atomic_helper_commit(struct drm_device *dev,
>* the software side now.
>*/
>
> - drm_atomic_helper_swap_state(state, true);
> + ret = drm_atomic_helper_swap_state(state, true);
> + if (ret)
> + goto err;
>
> /*
>* Everything below can be run asynchronously without the need to grab
> @@ -1428,6 +1428,10 @@ int drm_atomic_helper_commit(struct drm_device *dev,
> commit_tail(state);
>
> return 0;
> +
> +err:
> + drm_atomic_helper_cleanup_planes(dev, state);
> + return ret;
> }
> EXPORT_SYMBOL(drm_atomic_helper_commit);
>
> @@ -2137,7 +2141,7 @@ EXPORT_SYMBOL(drm_atomic_helper_cleanup_planes);
> * the current atomic helpers this is almost always the case, since the
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Fix the CURSOR_COEFF_MASK used in DDI Vswing Programming
Oh! nevermind, please fully ignore my last email!
Fixes: 04416108ccea ("drm/i915/cnl: Add registers related to voltage
swing sequences.")
Reviewed-by: Rodrigo Vivi
On Thu, Jun 29, 2017 at 9:13 PM, Rodrigo Vivi wrote:
> the patch that introduces this error didn't land yet
>
> so, could we squash to the original patch whenever that is reworked to
> be resent?
>
>
> On Thu, Jun 29, 2017 at 6:14 PM, Manasi Navare
> wrote:
>> The Cursor Coeff is lower 6 bits in the PORT_TX_DW4 register
>> and hence the CURSOR_COEFF_MASK should be (0x3F << 0)
>>
>> Signed-off-by: Manasi Navare
>> Cc: Rodrigo Vivi
>> ---
>> drivers/gpu/drm/i915/i915_reg.h | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_reg.h
>> b/drivers/gpu/drm/i915/i915_reg.h
>> index c8647cf..64cc674 100644
>> --- a/drivers/gpu/drm/i915/i915_reg.h
>> +++ b/drivers/gpu/drm/i915/i915_reg.h
>> @@ -1802,7 +1802,7 @@ enum skl_disp_power_wells {
>> #define POST_CURSOR_2(x) ((x) << 6)
>> #define POST_CURSOR_2_MASK (0x3F << 6)
>> #define CURSOR_COEFF(x) ((x) << 0)
>> -#define CURSOR_COEFF_MASK(0x3F << 6)
>> +#define CURSOR_COEFF_MASK(0x3F << 0)
>>
>> #define _CNL_PORT_TX_DW5_GRP_AE0x162354
>> #define _CNL_PORT_TX_DW5_GRP_B 0x1623D4
>> --
>> 2.1.4
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
>
> --
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND-CI v4 11/15] drm/i915: prepare scaler for YCBCR420 modeset
On Fri, 2017-06-30 at 17:29 +0530, Sharma, Shashank wrote:
> Regards
>
> Shashank
>
>
> On 6/30/2017 5:04 PM, Ander Conselvan De Oliveira wrote:
> > On Fri, 2017-06-30 at 11:20 +0530, Sharma, Shashank wrote:
> > > Regards
> > >
> > > Shashank
> > >
> > >
> > > On 6/27/2017 5:46 PM, Ander Conselvan De Oliveira wrote:
> > > > On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
> > > > > To get a YCBCR420 output from intel platforms, we need one
> > > > > scaler to scale down YCBCR444 samples to YCBCR420 samples.
> > > > >
> > > > > This patch:
> > > > > - Does scaler allocation for HDMI ycbcr420 outputs.
> > > > > - Programs PIPE_MISC register for ycbcr420 output.
> > > > > - Adds a new scaler user "HDMI output" to plug-into existing
> > > > > scaler framework. This output type is identified using bit
> > > > > 30 of the scaler users bitmap.
> > > > >
> > > > > V2: rebase
> > > > > V3: rebase
> > > > > V4: rebase
> > > > >
> > > > > Cc: Ville Syrjala
> > > > > Cc: Ander Conselvan De Oliveira
> > > > >
> > > > > Signed-off-by: Shashank Sharma
> > > > > ---
> > > > >drivers/gpu/drm/i915/intel_atomic.c | 6 ++
> > > > >drivers/gpu/drm/i915/intel_display.c | 26
> > > > > ++
> > > > >drivers/gpu/drm/i915/intel_drv.h | 10 +-
> > > > >drivers/gpu/drm/i915/intel_hdmi.c| 10 ++
> > > > >drivers/gpu/drm/i915/intel_panel.c | 3 ++-
> > > > >5 files changed, 53 insertions(+), 2 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_atomic.c
> > > > > b/drivers/gpu/drm/i915/intel_atomic.c
> > > > > index 36d4e63..a8c9ac5 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_atomic.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_atomic.c
> > > > > @@ -264,6 +264,12 @@ int intel_atomic_setup_scalers(struct
> > > > > drm_i915_private *dev_priv,
> > > > >
> > > > > /* panel fitter case: assign as a crtc scaler */
> > > > > scaler_id = &scaler_state->scaler_id;
> > > > > + } else if (i == SKL_HDMI_OUTPUT_INDEX) {
> > > > > + name = "HDMI-OUTPUT";
> > > > > + idx = intel_crtc->base.base.id;
> > > > > +
> > > > > + /* hdmi output case: needs a pipe scaler */
> > > > > + scaler_id = &scaler_state->scaler_id;
> > > > > } else {
> > > > > name = "PLANE";
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > > index da29536..983f581 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > > @@ -4626,6 +4626,11 @@ skl_update_scaler(struct intel_crtc_state
> > > > > *crtc_state, bool force_detach,
> > > > >*/
> > > > > need_scaling = src_w != dst_w || src_h != dst_h;
> > > > >
> > > > > + if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420
> > > > > + && scaler_user == SKL_HDMI_OUTPUT_INDEX)
> > > >
> > > > Is it really necessary to check for both? If it is, what's the point of
> > > > creating
> > > > SKL_HDMI_OUTPUT_INDEX?
> > >
> > > Yes, else this will affect scaler update for planes, as this function
> > > gets called to update the plane scalers too, at that time the output
> > > will be still valid (as its at CRTC level), but the
> > > scaler user would be different.
> >
> > Right, so there is a need to check for scaler_user == HDMI_OUTPUT. But then
> > wouldn't it be a bug if hdmi_output != YCBCR420 ? Point is, if the caller
> > asked
> > for a HDMI_OUTPUT scaler hopefully it knows what its doing, no need to
> > second
> > guess it.
>
> skl_update_scaler function gets called for all the users, which are:
> - panel fitter
> - all the planes
> - newly added user hdmi_output
> what about the case (assume) when we have handled hdmi_output and now we
> are handling for a plane, which doesnt need scaling.
>
> in this case, the code will look like:
> if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420)
>need_scaling = true /* which is wrong, as this function call is
> for plane scalar, and scaler_user = scaler */
>
> if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420 &&
> scaler_user == HDMI_OUT)
> need_scaling = true /* this is correct, as I want to consume scalar only
> when both the conditions are true.
I meant to do just
if (scaler_user == SKL_HDMI_OUTPUT_INDEX)
...;
I failed to notice the ambiguity in abbreviating to just HDMI_OUTPUT. But the
caller shouldn't request it if it doesn't need it, right?
>
> > > > > + /* YCBCR 444 -> 420 conversion needs a scaler */
> > > > > + need_scaling = true;
> > > > > +
> > > > > /*
> > > > >* if plane is being disabled or scaler is no more required or
> > > > > force detach
> > > > >* - free scaler binded to
[Intel-gfx] [PATCH 3/3] drm/i915: Use drm_crtc_vblank_get_accurate() in intel_atomic_wait_for_vblanks()
From: Ville Syrjälä
To make sure intel_atomic_wait_for_vblanks() really waits for at least
one vblank let's switch to using drm_crtc_vblank_get_accurate().
Also toss in a FIXME that we should really be sampling the vblank
counter when we did the plane/wm update instead of resampling it
potentially much later when we call intel_atomic_wait_for_vblanks().
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4e03ca6c946f..12fc4fcf78c5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12826,12 +12826,16 @@ static void intel_atomic_wait_for_vblanks(struct
drm_device *dev,
if (!((1 << pipe) & crtc_mask))
continue;
- ret = drm_crtc_vblank_get(&crtc->base);
+ ret = drm_crtc_vblank_get_accurate(&crtc->base);
if (WARN_ON(ret != 0)) {
crtc_mask &= ~(1 << pipe);
continue;
}
+ /*
+* FIXME we should have sampled this
+* when we did the actual update.
+*/
last_vblank_count[pipe] = drm_crtc_vblank_count(&crtc->base);
}
--
2.13.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/vblank: Introduce drm_crtc_vblank_get_accurate()
From: Ville Syrjälä
Add drm_crtc_vblank_get_accurate() which is the same as
drm_crtc_vblank_get() except that it will forcefully update the
the current vblank counter/timestamp value even if the interrupt
is already enabled.
And we'll switch drm_wait_one_vblank() over to using it to make sure it
will really wait at least one vblank even if it races with the irq
handler.
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_vblank.c | 37 -
include/drm/drm_vblank.h | 1 +
2 files changed, 33 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 823c853de052..c57383b8753b 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -955,7 +955,8 @@ static int drm_vblank_enable(struct drm_device *dev,
unsigned int pipe)
return ret;
}
-static int drm_vblank_get(struct drm_device *dev, unsigned int pipe)
+static int drm_vblank_get(struct drm_device *dev, unsigned int pipe,
+ bool force_update)
{
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
unsigned long irqflags;
@@ -975,6 +976,10 @@ static int drm_vblank_get(struct drm_device *dev, unsigned
int pipe)
if (!vblank->enabled) {
atomic_dec(&vblank->refcount);
ret = -EINVAL;
+ } else if (force_update) {
+ spin_lock(&dev->vblank_time_lock);
+ drm_update_vblank_count(dev, pipe, false);
+ spin_unlock(&dev->vblank_time_lock);
}
}
spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
@@ -994,10 +999,32 @@ static int drm_vblank_get(struct drm_device *dev,
unsigned int pipe)
*/
int drm_crtc_vblank_get(struct drm_crtc *crtc)
{
- return drm_vblank_get(crtc->dev, drm_crtc_index(crtc));
+ return drm_vblank_get(crtc->dev, drm_crtc_index(crtc), false);
}
EXPORT_SYMBOL(drm_crtc_vblank_get);
+/**
+ * drm_crtc_vblank_get_accurate - get a reference count on vblank events and
+ *make sure the counter is uptodate
+ * @crtc: which CRTC to own
+ *
+ * Acquire a reference count on vblank events to avoid having them disabled
+ * while in use.
+ *
+ * Also make sure the current vblank counter is value is fully up to date
+ * even if we're already past the start of vblank but the irq hasn't fired
+ * yet, which may be the case with some hardware that raises the interrupt
+ * only some time after the start of vblank.
+ *
+ * Returns:
+ * Zero on success or a negative error code on failure.
+ */
+int drm_crtc_vblank_get_accurate(struct drm_crtc *crtc)
+{
+ return drm_vblank_get(crtc->dev, drm_crtc_index(crtc), true);
+}
+EXPORT_SYMBOL(drm_crtc_vblank_get_accurate);
+
static void drm_vblank_put(struct drm_device *dev, unsigned int pipe)
{
struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
@@ -1053,7 +1080,7 @@ void drm_wait_one_vblank(struct drm_device *dev, unsigned
int pipe)
if (WARN_ON(pipe >= dev->num_crtcs))
return;
- ret = drm_vblank_get(dev, pipe);
+ ret = drm_vblank_get(dev, pipe, true);
if (WARN(ret, "vblank not available on crtc %i, ret=%i\n", pipe, ret))
return;
@@ -1248,7 +1275,7 @@ static void drm_legacy_vblank_pre_modeset(struct
drm_device *dev,
*/
if (!vblank->inmodeset) {
vblank->inmodeset = 0x1;
- if (drm_vblank_get(dev, pipe) == 0)
+ if (drm_vblank_get(dev, pipe, false) == 0)
vblank->inmodeset |= 0x2;
}
}
@@ -1448,7 +1475,7 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void
*data,
return 0;
}
- ret = drm_vblank_get(dev, pipe);
+ ret = drm_vblank_get(dev, pipe, false);
if (ret) {
DRM_DEBUG("crtc %d failed to acquire vblank counter, %d\n",
pipe, ret);
return ret;
diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
index 7fba9efe4951..5629e7841318 100644
--- a/include/drm/drm_vblank.h
+++ b/include/drm/drm_vblank.h
@@ -162,6 +162,7 @@ void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
bool drm_handle_vblank(struct drm_device *dev, unsigned int pipe);
bool drm_crtc_handle_vblank(struct drm_crtc *crtc);
int drm_crtc_vblank_get(struct drm_crtc *crtc);
+int drm_crtc_vblank_get_accurate(struct drm_crtc *crtc);
void drm_crtc_vblank_put(struct drm_crtc *crtc);
void drm_wait_one_vblank(struct drm_device *dev, unsigned int pipe);
void drm_crtc_wait_one_vblank(struct drm_crtc *crtc);
--
2.13.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Fix race between pipe update and vblank irq
From: Ville Syrjälä
Make sure that we have an up to date vblank counter value for sending
out the completion event. On gen2/3 the vblank irq fires at frame start
rather than at start of vblank, so if we perform an update between
vblank start and frame start we would potentially sample a stale vblank
counter value, and thus send out the event one frame too soon.
Cc: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 0c650c2cbca8..61681a11086a 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -197,7 +197,7 @@ void intel_pipe_update_end(struct intel_crtc *crtc, struct
intel_flip_work *work
* event outside of the critical section - the spinlock might spin for a
* while ... */
if (crtc->base.state->event) {
- WARN_ON(drm_crtc_vblank_get(&crtc->base) != 0);
+ WARN_ON(drm_crtc_vblank_get_accurate(&crtc->base) != 0);
spin_lock(&crtc->base.dev->event_lock);
drm_crtc_arm_vblank_event(&crtc->base, crtc->base.state->event);
--
2.13.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RESEND-CI v4 11/15] drm/i915: prepare scaler for YCBCR420 modeset
Regards
Shashank
On 6/30/2017 7:45 PM, Ander Conselvan De Oliveira wrote:
On Fri, 2017-06-30 at 17:29 +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/30/2017 5:04 PM, Ander Conselvan De Oliveira wrote:
On Fri, 2017-06-30 at 11:20 +0530, Sharma, Shashank wrote:
Regards
Shashank
On 6/27/2017 5:46 PM, Ander Conselvan De Oliveira wrote:
On Wed, 2017-06-21 at 16:04 +0530, Shashank Sharma wrote:
To get a YCBCR420 output from intel platforms, we need one
scaler to scale down YCBCR444 samples to YCBCR420 samples.
This patch:
- Does scaler allocation for HDMI ycbcr420 outputs.
- Programs PIPE_MISC register for ycbcr420 output.
- Adds a new scaler user "HDMI output" to plug-into existing
scaler framework. This output type is identified using bit
30 of the scaler users bitmap.
V2: rebase
V3: rebase
V4: rebase
Cc: Ville Syrjala
Cc: Ander Conselvan De Oliveira
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_atomic.c | 6 ++
drivers/gpu/drm/i915/intel_display.c | 26 ++
drivers/gpu/drm/i915/intel_drv.h | 10 +-
drivers/gpu/drm/i915/intel_hdmi.c| 10 ++
drivers/gpu/drm/i915/intel_panel.c | 3 ++-
5 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 36d4e63..a8c9ac5 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -264,6 +264,12 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
/* panel fitter case: assign as a crtc scaler */
scaler_id = &scaler_state->scaler_id;
+ } else if (i == SKL_HDMI_OUTPUT_INDEX) {
+ name = "HDMI-OUTPUT";
+ idx = intel_crtc->base.base.id;
+
+ /* hdmi output case: needs a pipe scaler */
+ scaler_id = &scaler_state->scaler_id;
} else {
name = "PLANE";
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
index da29536..983f581 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4626,6 +4626,11 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
*/
need_scaling = src_w != dst_w || src_h != dst_h;
+ if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420
+ && scaler_user == SKL_HDMI_OUTPUT_INDEX)
Is it really necessary to check for both? If it is, what's the point of creating
SKL_HDMI_OUTPUT_INDEX?
Yes, else this will affect scaler update for planes, as this function
gets called to update the plane scalers too, at that time the output
will be still valid (as its at CRTC level), but the
scaler user would be different.
Right, so there is a need to check for scaler_user == HDMI_OUTPUT. But then
wouldn't it be a bug if hdmi_output != YCBCR420 ? Point is, if the caller asked
for a HDMI_OUTPUT scaler hopefully it knows what its doing, no need to second
guess it.
skl_update_scaler function gets called for all the users, which are:
- panel fitter
- all the planes
- newly added user hdmi_output
what about the case (assume) when we have handled hdmi_output and now we
are handling for a plane, which doesnt need scaling.
in this case, the code will look like:
if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420)
need_scaling = true /* which is wrong, as this function call is
for plane scalar, and scaler_user = scaler */
if (crtc_state->hdmi_output == DRM_HDMI_OUTPUT_YCBCR420 &&
scaler_user == HDMI_OUT)
need_scaling = true /* this is correct, as I want to consume scalar only
when both the conditions are true.
I meant to do just
if (scaler_user == SKL_HDMI_OUTPUT_INDEX)
...;
I failed to notice the ambiguity in abbreviating to just HDMI_OUTPUT. But the
caller shouldn't request it if it doesn't need it, right?
I agree, I dont see a reason why not !
Will do the needful.
Regards
Shashank
+ /* YCBCR 444 -> 420 conversion needs a scaler */
+ need_scaling = true;
+
/*
* if plane is being disabled or scaler is no more required or force
detach
* - free scaler binded to this plane/crtc
@@ -4673,6 +4678,26 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
}
/**
+ * skl_update_scaler_hdmi_output - Stages update to scaler state for HDMI.
+ * HDMI YCBCR 420 output needs a scaler, for downsampling.
+ *
+ * @state: crtc's scaler state
+ *
+ * Return
+ * 0 - scaler_usage updated successfully
+ *error - requested scaling cannot be supported or other error condition
+ */
+int skl_update_scaler_crtc_hdmi_output(struct intel_crtc_state *state)
+{
+ const struct drm_display_mode *mode = &state->base.adjusted_mode;
+
+ return skl_update_scaler(state, !state->bas
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/vblank: Introduce drm_crtc_vblank_get_accurate()
== Series Details == Series: series starting with [1/3] drm/vblank: Introduce drm_crtc_vblank_get_accurate() URL : https://patchwork.freedesktop.org/series/26633/ State : success == Summary == Series 26633v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/26633/revisions/1/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-r) fdo#100125 Test kms_busy: Subgroup basic-flip-default-b: dmesg-warn -> FAIL (fi-skl-6700hq) fdo#101144 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: dmesg-warn -> PASS (fi-pnv-d510) fdo#101597 +1 Subgroup suspend-read-crc-pipe-a: fail -> PASS (fi-skl-6700k) Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101516 +1 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fdo#101516 https://bugs.freedesktop.org/show_bug.cgi?id=101516 fi-bdw-5557u total:279 pass:264 dwarn:0 dfail:0 fail:3 skip:11 time:440s fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 time:434s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:352s fi-bsw-n3050 total:279 pass:239 dwarn:0 dfail:0 fail:3 skip:36 time:515s fi-bxt-j4205 total:279 pass:256 dwarn:0 dfail:0 fail:3 skip:19 time:509s fi-byt-j1900 total:279 pass:250 dwarn:1 dfail:0 fail:3 skip:24 time:477s fi-byt-n2820 total:279 pass:247 dwarn:0 dfail:0 fail:3 skip:28 time:474s fi-glk-2atotal:279 pass:256 dwarn:0 dfail:0 fail:3 skip:19 time:584s fi-hsw-4770 total:279 pass:259 dwarn:0 dfail:0 fail:3 skip:16 time:429s fi-hsw-4770r total:279 pass:259 dwarn:0 dfail:0 fail:3 skip:16 time:414s fi-ilk-650 total:279 pass:225 dwarn:0 dfail:0 fail:3 skip:50 time:414s fi-ivb-3520m total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:495s fi-ivb-3770 total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:463s fi-kbl-7500u total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:457s fi-kbl-7560u total:279 pass:265 dwarn:0 dfail:0 fail:3 skip:10 time:561s fi-kbl-r total:279 pass:256 dwarn:1 dfail:0 fail:3 skip:18 time:571s fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:555s fi-skl-6260u total:279 pass:265 dwarn:0 dfail:0 fail:3 skip:10 time:452s fi-skl-6700hqtotal:279 pass:219 dwarn:1 dfail:0 fail:33 skip:24 time:333s fi-skl-6700k total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:460s fi-skl-6770hqtotal:279 pass:265 dwarn:0 dfail:0 fail:3 skip:10 time:477s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:435s fi-snb-2520m total:279 pass:247 dwarn:0 dfail:0 fail:3 skip:28 time:539s fi-snb-2600 total:279 pass:246 dwarn:0 dfail:0 fail:3 skip:29 time:405s bcea90f867d52f57e0919ae8eaad5fba3c53735e drm-tip: 2017y-06m-30d-13h-38m-04s UTC integration manifest 58679573 drm/i915: Use drm_crtc_vblank_get_accurate() in intel_atomic_wait_for_vblanks() 47a42e9 drm/i915: Fix race between pipe update and vblank irq 139e473 drm/vblank: Introduce drm_crtc_vblank_get_accurate() == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5079/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/kms_flip: Make panning tests actually pan all the time
From: Ville Syrjälä
Currently the panning tests actually stop panning when they hit the
right edge fo the framebuffer. Let's make them ping-pong across the
fb to make it clear that they are indeed trying to pan around all the
time.
Signed-off-by: Ville Syrjälä
---
tests/kms_flip.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
index 14396d860c5e..ede5fd2ba9c5 100644
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -834,7 +834,10 @@ static unsigned int run_test_step(struct test_output *o)
if (o->flags & TEST_PAN) {
int count = do_flip ?
o->flip_state.count : o->vblank_state.count;
- int x_ofs = min(count * 10, o->fb_width - o->kmode[0].hdisplay);
+ int width = o->fb_width - o->kmode[0].hdisplay;
+ int x_ofs = count * 10 % (2 * width);
+ if (x_ofs >= width)
+ x_ofs = 2 * width - x_ofs;
/* Make sure DSPSURF changes value */
if (o->flags & TEST_HANG)
--
2.13.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/cnl: Fix the CURSOR_COEFF_MASK used in DDI Vswing Programming
Patch merged to dinq.
With the proper "Fixes:".
Thanks,
Rodrigo.
On Fri, 2017-06-30 at 07:15 -0700, Rodrigo Vivi wrote:
> Oh! nevermind, please fully ignore my last email!
>
> Fixes: 04416108ccea ("drm/i915/cnl: Add registers related to voltage
> swing sequences.")
> Reviewed-by: Rodrigo Vivi
>
> On Thu, Jun 29, 2017 at 9:13 PM, Rodrigo Vivi wrote:
> > the patch that introduces this error didn't land yet
> >
> > so, could we squash to the original patch whenever that is reworked to
> > be resent?
> >
> >
> > On Thu, Jun 29, 2017 at 6:14 PM, Manasi Navare
> > wrote:
> >> The Cursor Coeff is lower 6 bits in the PORT_TX_DW4 register
> >> and hence the CURSOR_COEFF_MASK should be (0x3F << 0)
> >>
> >> Signed-off-by: Manasi Navare
> >> Cc: Rodrigo Vivi
> >> ---
> >> drivers/gpu/drm/i915/i915_reg.h | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> >> b/drivers/gpu/drm/i915/i915_reg.h
> >> index c8647cf..64cc674 100644
> >> --- a/drivers/gpu/drm/i915/i915_reg.h
> >> +++ b/drivers/gpu/drm/i915/i915_reg.h
> >> @@ -1802,7 +1802,7 @@ enum skl_disp_power_wells {
> >> #define POST_CURSOR_2(x) ((x) << 6)
> >> #define POST_CURSOR_2_MASK (0x3F << 6)
> >> #define CURSOR_COEFF(x) ((x) << 0)
> >> -#define CURSOR_COEFF_MASK(0x3F << 6)
> >> +#define CURSOR_COEFF_MASK(0x3F << 0)
> >>
> >> #define _CNL_PORT_TX_DW5_GRP_AE0x162354
> >> #define _CNL_PORT_TX_DW5_GRP_B 0x1623D4
> >> --
> >> 2.1.4
> >>
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> >
> >
> > --
> > Rodrigo Vivi
> > Blog: http://blog.vivi.eng.br
>
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/vblank: Introduce drm_crtc_vblank_get_accurate()
On Fri, Jun 30, 2017 at 05:18:41PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Add drm_crtc_vblank_get_accurate() which is the same as
> drm_crtc_vblank_get() except that it will forcefully update the
> the current vblank counter/timestamp value even if the interrupt
> is already enabled.
>
> And we'll switch drm_wait_one_vblank() over to using it to make sure it
> will really wait at least one vblank even if it races with the irq
> handler.
>
> Cc: Daniel Vetter
> Signed-off-by: Ville Syrjälä
Hm, I just thought of doing an
s/drm_vblank_count/drm_crtc_accurate_vblank_count/ in
drm_crtc_arm_vblank_event.
What does this buy us above&beyond the other patch? And why isn't
vblank_get accurate always?
/me confused
Cheers, Daniel
> ---
> drivers/gpu/drm/drm_vblank.c | 37 -
> include/drm/drm_vblank.h | 1 +
> 2 files changed, 33 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 823c853de052..c57383b8753b 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -955,7 +955,8 @@ static int drm_vblank_enable(struct drm_device *dev,
> unsigned int pipe)
> return ret;
> }
>
> -static int drm_vblank_get(struct drm_device *dev, unsigned int pipe)
> +static int drm_vblank_get(struct drm_device *dev, unsigned int pipe,
> + bool force_update)
> {
> struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
> unsigned long irqflags;
> @@ -975,6 +976,10 @@ static int drm_vblank_get(struct drm_device *dev,
> unsigned int pipe)
> if (!vblank->enabled) {
> atomic_dec(&vblank->refcount);
> ret = -EINVAL;
> + } else if (force_update) {
> + spin_lock(&dev->vblank_time_lock);
> + drm_update_vblank_count(dev, pipe, false);
> + spin_unlock(&dev->vblank_time_lock);
> }
> }
> spin_unlock_irqrestore(&dev->vbl_lock, irqflags);
> @@ -994,10 +999,32 @@ static int drm_vblank_get(struct drm_device *dev,
> unsigned int pipe)
> */
> int drm_crtc_vblank_get(struct drm_crtc *crtc)
> {
> - return drm_vblank_get(crtc->dev, drm_crtc_index(crtc));
> + return drm_vblank_get(crtc->dev, drm_crtc_index(crtc), false);
> }
> EXPORT_SYMBOL(drm_crtc_vblank_get);
>
> +/**
> + * drm_crtc_vblank_get_accurate - get a reference count on vblank events and
> + *make sure the counter is uptodate
> + * @crtc: which CRTC to own
> + *
> + * Acquire a reference count on vblank events to avoid having them disabled
> + * while in use.
> + *
> + * Also make sure the current vblank counter is value is fully up to date
> + * even if we're already past the start of vblank but the irq hasn't fired
> + * yet, which may be the case with some hardware that raises the interrupt
> + * only some time after the start of vblank.
> + *
> + * Returns:
> + * Zero on success or a negative error code on failure.
> + */
> +int drm_crtc_vblank_get_accurate(struct drm_crtc *crtc)
> +{
> + return drm_vblank_get(crtc->dev, drm_crtc_index(crtc), true);
> +}
> +EXPORT_SYMBOL(drm_crtc_vblank_get_accurate);
> +
> static void drm_vblank_put(struct drm_device *dev, unsigned int pipe)
> {
> struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
> @@ -1053,7 +1080,7 @@ void drm_wait_one_vblank(struct drm_device *dev,
> unsigned int pipe)
> if (WARN_ON(pipe >= dev->num_crtcs))
> return;
>
> - ret = drm_vblank_get(dev, pipe);
> + ret = drm_vblank_get(dev, pipe, true);
> if (WARN(ret, "vblank not available on crtc %i, ret=%i\n", pipe, ret))
> return;
>
> @@ -1248,7 +1275,7 @@ static void drm_legacy_vblank_pre_modeset(struct
> drm_device *dev,
>*/
> if (!vblank->inmodeset) {
> vblank->inmodeset = 0x1;
> - if (drm_vblank_get(dev, pipe) == 0)
> + if (drm_vblank_get(dev, pipe, false) == 0)
> vblank->inmodeset |= 0x2;
> }
> }
> @@ -1448,7 +1475,7 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void
> *data,
> return 0;
> }
>
> - ret = drm_vblank_get(dev, pipe);
> + ret = drm_vblank_get(dev, pipe, false);
> if (ret) {
> DRM_DEBUG("crtc %d failed to acquire vblank counter, %d\n",
> pipe, ret);
> return ret;
> diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
> index 7fba9efe4951..5629e7841318 100644
> --- a/include/drm/drm_vblank.h
> +++ b/include/drm/drm_vblank.h
> @@ -162,6 +162,7 @@ void drm_crtc_arm_vblank_event(struct drm_crtc *crtc,
> bool drm_handle_vblank(struct drm_device *dev, unsigned int pipe);
> bool drm_crtc_handle_vblank(struct drm_crtc *crtc);
> int drm_crtc_vblank_get(struct drm_crtc *crtc);
> +int drm_crtc_vblank_get_accurate(struct drm_crtc *crtc);
>
Re: [Intel-gfx] [PATCH v4 5/5] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore
On Fri, Jun 30, 2017 at 04:53:19PM +0300, Ville Syrjälä wrote: > On Fri, Jun 30, 2017 at 03:35:03PM +0200, Daniel Vetter wrote: > > On Thu, Jun 29, 2017 at 10:26:08PM +0300, Ville Syrjälä wrote: > > > On Thu, Jun 29, 2017 at 06:57:30PM +0100, Chris Wilson wrote: > > > > Quoting ville.syrj...@linux.intel.com (2017-06-29 15:36:42) > > > > > From: Ville Syrjälä > > > > > > > > > > Introduce an rw_semaphore to protect the display commits. All normal > > > > > commits use down_read() and hence can proceed in parallel, but GPU > > > > > reset > > > > > will use down_write() making sure no other commits are in progress > > > > > when > > > > > we have to pull the plug on the display engine on pre-g4x platforms. > > > > > There are no modeset/gem locks taken inside > > > > > __intel_atomic_commit_tail() > > > > > itself, and we wait for all dependencies before the down_read(), and > > > > > thus there is no chance of deadlocks with this scheme. > > > > > > > > This matches what I thought should be done (I didn't think of using > > > > rwsem just a mutex, nice touch). The point I got stuck on was what > > > > should be done after the reset? I expected another modeset to return the > > > > state back or otherwise the inflight would get confused? > > > > > > I guess that can happen. For instance, if we have a crtc_enable() in > > > flight, > > > and then we do a reset before it gets committed we would end up doing > > > crtc_enable() twice in a row without a crtc_disable in between. For page > > > flips and such this shouldn't be a big deal in general. > > > > atomic commits are ordered. You have to wait for the previous ones to > > complete before you do a new one. If you don't do that, then all hell > > breaks loose. > > What we're effectively doing here is inserting two new commits in > the middle of the timeline, one to disable everything, and another > one to re-enable everything. At the end of the the re-enable we would > want the hardware state should match exactly what was there before > the disable, hence any commits still in the timeline should work > correctly. That is, their old_state will match the hardware state > when it comes time to commit them. > > But we can only do that properly after we start to track the committed > state. Without that tracking we can get into trouble wrt. the > hardware state not matching the old state when it comes time to > commit the new state. Yeah, but my point is that this here is an extremely fancy and fragile (and afaics in this form, incomplete) fix for something that in the past was fixed much, much simpler. Why do we need this massive amount of complexity now? Who's asking for all this (we don't even have anyone yet asking for fully queued atomic commits, much less on gen4)? I mean rewriting the entire modeset code is fun and all, but for gen3-4? > > What you really can't do with atomic (without rewriting everything once > > more) is cancel a commit. Pre-atomic we could do that on gen4 since the > > mmio flips died with the gpu, but that's the one design change we need to > > cope with (plus TDR insisting it can't force-complete requests anymore). > > > > > > > During reset we should be recommiting the state that was committed > > > > > last. > > > > > But for now we'll settle for recommiting the last state for each > > > > > object. > > > > > > > > Ah, I guess that explains the above. What is the complication with > > > > restoring the current state as opposed to the next state? > > > > > > Well the main thing is just tracking which is the current state. That > > > just needs refactoring the .atomic_duplicate_state() calling convention > > > across the whole tree so that we can then duplicate the committed state > > > rather than the latest state. > > > > > > Also due to the commit_hw_done() being potentially done after the > > > modeset locks have been dropped, I don't think we can be certain > > > of it getting called in the same order as swap_state(), hence > > > when we track the committed state in commit_hw_done() we'll have > > > to have some way to figure out if our new state is in fact the > > > latest committed state for each object or if the calls got > > > reordered. We don't insert any dependencies between two commits > > > unless they touch the same active crtc, thus this reordering > > > seems very much possible. Dunno if we should add some way to add > > > such dependeencies whenever the same object is part of two otherwise > > > independent commits, or if we just want to try and work with the > > > reordered calls. My idea for the latter was some kind of seqno/age > > > counter on the object states that allows me to recongnize which > > > state is more recent. The object states aren't refcounted so hanging > > > on to the wrong pointer could cause an oops the next time we have to > > > perform a GPU reset. > > > > Atomic commits are strongly ordered on a given CRTC, so stuff can't be > > out-of-order within one. Across them the i
Re: [Intel-gfx] [PATCH i-g-t 3/5] lib/cnl: Add Cannonlake PCI IDs for Y-skus.
series pushed to i-g-t. Thanks for the review.
On Thu, Jun 29, 2017 at 2:37 PM, Clint Taylor
wrote:
> Matches i915 support PCI device IDs
>
> Reviewed-by: Clinton Taylor
>
> -Clint
>
>
>
> On 06/29/2017 02:18 PM, Rodrigo Vivi wrote:
>>
>> By the Spec all CNL Y skus are 2+2, i.e. GT2.
>>
>> This is a copy of merged i915's
>> commit 95578277cbdb ("drm/i915/cnl: Add Cannonlake PCI IDs for Y-skus.")
>>
>> v2: Based on Anusha's kernel clean-up.
>>
>> Cc: Anusha Srivatsa
>> Cc: Clinton Taylor
>> Signed-off-by: Rodrigo Vivi
>> ---
>> lib/i915_pciids.h | 11 ++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/lib/i915_pciids.h b/lib/i915_pciids.h
>> index 8109e73..8a10a45 100644
>> --- a/lib/i915_pciids.h
>> +++ b/lib/i915_pciids.h
>> @@ -352,8 +352,17 @@
>> INTEL_VGA_DEVICE(0x5A42, info), \
>> INTEL_VGA_DEVICE(0x5A4A, info)
>> +#define INTEL_CNL_Y_GT2_IDS(info) \
>> + INTEL_VGA_DEVICE(0x5A51, info), \
>> + INTEL_VGA_DEVICE(0x5A59, info), \
>> + INTEL_VGA_DEVICE(0x5A41, info), \
>> + INTEL_VGA_DEVICE(0x5A49, info), \
>> + INTEL_VGA_DEVICE(0x5A71, info), \
>> + INTEL_VGA_DEVICE(0x5A79, info)
>> +
>> #define INTEL_CNL_IDS(info) \
>> - INTEL_CNL_U_GT2_IDS(info)
>> + INTEL_CNL_U_GT2_IDS(info), \
>> + INTEL_CNL_Y_GT2_IDS(info)
>> #define INTEL_CFL_U_IDS(info) \
>> INTEL_VGA_DEVICE(0x3EA5, info), /* ULT GT3 */ \
>
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [PATCH 2/4] intel: Add Cannonlake PCI IDs for Y-skus.
series pushed to libdrm. Thanks for the review.
On Thu, Jun 29, 2017 at 3:16 PM, Clint Taylor
wrote:
> Reviewed-by: Clinton Taylor
>
> -Clint
>
>
>
>
> On 06/29/2017 02:34 PM, Rodrigo Vivi wrote:
>>
>> By the Spec all CNL Y skus are 2+2, i.e. GT2.
>>
>> This is a copy of merged i915's
>> commit 95578277cbdb ("drm/i915/cnl: Add Cannonlake PCI IDs for Y-skus.")
>>
>> v2: Add kernel commit id for reference.
>>
>> Cc: Anusha Srivatsa
>> Cc: Clinton Taylor
>> Signed-off-by: Rodrigo Vivi
>> ---
>> intel/intel_chipset.h | 16 +++-
>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
>> index e6b49d7..37579c6 100644
>> --- a/intel/intel_chipset.h
>> +++ b/intel/intel_chipset.h
>> @@ -237,6 +237,12 @@
>> #define PCI_CHIP_CANNONLAKE_U_GT2_1 0x5A5A
>> #define PCI_CHIP_CANNONLAKE_U_GT2_2 0x5A42
>> #define PCI_CHIP_CANNONLAKE_U_GT2_3 0x5A4A
>> +#define PCI_CHIP_CANNONLAKE_Y_GT2_00x5A51
>> +#define PCI_CHIP_CANNONLAKE_Y_GT2_10x5A59
>> +#define PCI_CHIP_CANNONLAKE_Y_GT2_20x5A41
>> +#define PCI_CHIP_CANNONLAKE_Y_GT2_30x5A49
>> +#define PCI_CHIP_CANNONLAKE_Y_GT2_40x5A71
>> +#define PCI_CHIP_CANNONLAKE_Y_GT2_50x5A79
>> #define IS_MOBILE(devid)((devid) == PCI_CHIP_I855_GM || \
>> (devid) == PCI_CHIP_I915_GM || \
>> @@ -501,12 +507,20 @@
>> IS_GEN8(dev) || \
>> IS_GEN9(dev))
>> +#define IS_CNL_Y(devid) ((devid) ==
>> PCI_CHIP_CANNONLAKE_Y_GT2_0 || \
>> +(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_1 ||
>> \
>> +(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_2 ||
>> \
>> +(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_3 ||
>> \
>> +(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_4 ||
>> \
>> +(devid) == PCI_CHIP_CANNONLAKE_Y_GT2_5)
>> +
>> #define IS_CNL_U(devid) ((devid) ==
>> PCI_CHIP_CANNONLAKE_U_GT2_0 || \
>> (devid) == PCI_CHIP_CANNONLAKE_U_GT2_1 ||
>> \
>> (devid) == PCI_CHIP_CANNONLAKE_U_GT2_2 ||
>> \
>> (devid) == PCI_CHIP_CANNONLAKE_U_GT2_3)
>> -#define IS_CANNONLAKE(devid) (IS_CNL_U(devid))
>> +#define IS_CANNONLAKE(devid) (IS_CNL_U(devid) || \
>> +IS_CNL_Y(devid))
>> #define IS_GEN10(devid) (IS_CANNONLAKE(devid))
>>
>
>
> ___
> mesa-dev mailing list
> mesa-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [REGRESSION 4.12] i915 Oops at intel_fbdev_invalidate()
Hi,
I hit an Oops with the latest Linus tree (4.12-rc7+) on a HSW machine
like the following at boot:
BUG: unable to handle kernel NULL pointer dereference at 00b0
IP: intel_fbdev_invalidate.isra.3+0xc/0x40 [i915]
Oops: [#1] PREEMPT SMP
CPU: 2 PID: 833 Comm: X Not tainted 4.10.0-rc5-btest9+ #15
Hardware name: Hewlett-Packard HP ProBook 430 G1/1946, BIOS L73 Ver. 08.05
2013/03/15
task: 917313db8000 task.stack: b6e70379c000
RIP: 0010:intel_fbdev_invalidate.isra.3+0xc/0x40 [i915]
RSP: 0018:b6e70379fde0 EFLAGS: 00010246
RAX: RBX: 9172f70e1c00 RCX:
RDX: 917313db8000 RSI: RDI: 91731934d040
RBP: b6e70379fdf0 R08: 0002 R09: 91731934ead0
R10: 9173192f0368 R11: 0001 R12: 9173192f
R13: 9172f71016e8 R14: 9173227c8480 R15: 9172f71016c8
FS: 7f8cc8c3fa00() GS:9173c0a8() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 00b0 CR3: 6273b000 CR4: 001406e0
Call Trace:
? intel_fbdev_restore_mode+0x4e/0x70 [i915]
i915_driver_lastclose+0xe/0x20 [i915]
drm_lastclose+0x3b/0xf0 [drm]
drm_release+0x2b8/0x360 [drm]
__fput+0xd9/0x1e0
fput+0xe/0x10
task_work_run+0x83/0xa0
exit_to_usermode_loop+0x59/0x85
do_syscall_64+0xb3/0xd0
entry_SYSCALL64_slow_path+0x25/0x25
And git bisection leaded to the commit
fabef825626d7bd05a321e4427fdf31a169b5173
drm/i915: Drop struct_mutex around frontbuffer flushes
The band-aid patch below seems fixing it.
thanks,
Takashi
-- 8< --
From: Takashi Iwai
Subject: [PATCH] drm/i915: Fix NULL-dereference at intel_fbdev_invalidate()
The commit fabef825626d ("drm/i915: Drop struct_mutex around
frontbuffer flushes") caused an Oops at boot on a HSW machine like:
BUG: unable to handle kernel NULL pointer dereference at 00b0
IP: intel_fbdev_invalidate.isra.3+0xc/0x40 [i915]
Oops: [#1] PREEMPT SMP
CPU: 2 PID: 833 Comm: X Not tainted 4.10.0-rc5-btest9+ #15
Hardware name: Hewlett-Packard HP ProBook 430 G1/1946, BIOS L73 Ver. 08.05
2013/03/15
Call Trace:
? intel_fbdev_restore_mode+0x4e/0x70 [i915]
i915_driver_lastclose+0xe/0x20 [i915]
drm_lastclose+0x3b/0xf0 [drm]
drm_release+0x2b8/0x360 [drm]
__fput+0xd9/0x1e0
fput+0xe/0x10
task_work_run+0x83/0xa0
exit_to_usermode_loop+0x59/0x85
do_syscall_64+0xb3/0xd0
entry_SYSCALL64_slow_path+0x25/0x25
As this is a simple NULL dereference, check it before reference as a
band-aid fix.
Fixes: fabef825626d ("drm/i915: Drop struct_mutex around frontbuffer flushes")
Signed-off-by: Takashi Iwai
---
drivers/gpu/drm/i915/intel_fbdev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 332254a8eebe..fdefe6941912 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -48,8 +48,10 @@
static void intel_fbdev_invalidate(struct intel_fbdev *ifbdev)
{
struct drm_i915_gem_object *obj = ifbdev->fb->obj;
- unsigned int origin = ifbdev->vma->fence ? ORIGIN_GTT : ORIGIN_CPU;
+ unsigned int origin = ORIGIN_GTT;
+ if (ifbdev->vma && !ifbdev->vma->fence)
+ origin = ORIGIN_CPU;
intel_fb_obj_invalidate(obj, origin);
}
--
2.13.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 5/5] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore
Quoting Daniel Vetter (2017-06-30 16:30:59) > On Fri, Jun 30, 2017 at 04:53:19PM +0300, Ville Syrjälä wrote: > > On Fri, Jun 30, 2017 at 03:35:03PM +0200, Daniel Vetter wrote: > > > On Thu, Jun 29, 2017 at 10:26:08PM +0300, Ville Syrjälä wrote: > > > > On Thu, Jun 29, 2017 at 06:57:30PM +0100, Chris Wilson wrote: > > > > > Quoting ville.syrj...@linux.intel.com (2017-06-29 15:36:42) > > > > > > From: Ville Syrjälä > > > > > > > > > > > > Introduce an rw_semaphore to protect the display commits. All normal > > > > > > commits use down_read() and hence can proceed in parallel, but GPU > > > > > > reset > > > > > > will use down_write() making sure no other commits are in progress > > > > > > when > > > > > > we have to pull the plug on the display engine on pre-g4x platforms. > > > > > > There are no modeset/gem locks taken inside > > > > > > __intel_atomic_commit_tail() > > > > > > itself, and we wait for all dependencies before the down_read(), and > > > > > > thus there is no chance of deadlocks with this scheme. > > > > > > > > > > This matches what I thought should be done (I didn't think of using > > > > > rwsem just a mutex, nice touch). The point I got stuck on was what > > > > > should be done after the reset? I expected another modeset to return > > > > > the > > > > > state back or otherwise the inflight would get confused? > > > > > > > > I guess that can happen. For instance, if we have a crtc_enable() in > > > > flight, > > > > and then we do a reset before it gets committed we would end up doing > > > > crtc_enable() twice in a row without a crtc_disable in between. For page > > > > flips and such this shouldn't be a big deal in general. > > > > > > atomic commits are ordered. You have to wait for the previous ones to > > > complete before you do a new one. If you don't do that, then all hell > > > breaks loose. > > > > What we're effectively doing here is inserting two new commits in > > the middle of the timeline, one to disable everything, and another > > one to re-enable everything. At the end of the the re-enable we would > > want the hardware state should match exactly what was there before > > the disable, hence any commits still in the timeline should work > > correctly. That is, their old_state will match the hardware state > > when it comes time to commit them. > > > > But we can only do that properly after we start to track the committed > > state. Without that tracking we can get into trouble wrt. the > > hardware state not matching the old state when it comes time to > > commit the new state. > > Yeah, but my point is that this here is an extremely fancy and fragile > (and afaics in this form, incomplete) fix for something that in the past > was fixed much, much simpler. Why do we need this massive amount of > complexity now? Who's asking for all this (we don't even have anyone yet > asking for fully queued atomic commits, much less on gen4)? It was never "fixed", it was always borked; broken by design. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION 4.12] i915 Oops at intel_fbdev_invalidate()
Quoting Takashi Iwai (2017-06-30 16:38:46) > Hi, > > I hit an Oops with the latest Linus tree (4.12-rc7+) on a HSW machine > like the following at boot: > > BUG: unable to handle kernel NULL pointer dereference at 00b0 > IP: intel_fbdev_invalidate.isra.3+0xc/0x40 [i915] > Oops: [#1] PREEMPT SMP > CPU: 2 PID: 833 Comm: X Not tainted 4.10.0-rc5-btest9+ #15 > Hardware name: Hewlett-Packard HP ProBook 430 G1/1946, BIOS L73 Ver. 08.05 > 2013/03/15 > task: 917313db8000 task.stack: b6e70379c000 > RIP: 0010:intel_fbdev_invalidate.isra.3+0xc/0x40 [i915] > RSP: 0018:b6e70379fde0 EFLAGS: 00010246 > RAX: RBX: 9172f70e1c00 RCX: > RDX: 917313db8000 RSI: RDI: 91731934d040 > RBP: b6e70379fdf0 R08: 0002 R09: 91731934ead0 > R10: 9173192f0368 R11: 0001 R12: 9173192f > R13: 9172f71016e8 R14: 9173227c8480 R15: 9172f71016c8 > FS: 7f8cc8c3fa00() GS:9173c0a8() knlGS: > CS: 0010 DS: ES: CR0: 80050033 > CR2: 00b0 CR3: 6273b000 CR4: 001406e0 > Call Trace: > ? intel_fbdev_restore_mode+0x4e/0x70 [i915] > i915_driver_lastclose+0xe/0x20 [i915] > drm_lastclose+0x3b/0xf0 [drm] > drm_release+0x2b8/0x360 [drm] > __fput+0xd9/0x1e0 > fput+0xe/0x10 > task_work_run+0x83/0xa0 > exit_to_usermode_loop+0x59/0x85 > do_syscall_64+0xb3/0xd0 > entry_SYSCALL64_slow_path+0x25/0x25 > > And git bisection leaded to the commit > fabef825626d7bd05a321e4427fdf31a169b5173 > drm/i915: Drop struct_mutex around frontbuffer flushes > > The band-aid patch below seems fixing it. See https://patchwork.freedesktop.org/patch/163261/ -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore
On Fri, Jun 30, 2017 at 03:30:33PM +0200, Daniel Vetter wrote: > On Fri, Jun 30, 2017 at 03:25:58PM +0200, Daniel Vetter wrote: > > On Thu, Jun 29, 2017 at 04:49:48PM +0300, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > Introduce an rw_semaphore to protect the display commits. All normal > > > commits use down_read() and hence can proceed in parallel, but GPU reset > > > will use down_write() making sure no other commits are in progress when > > > we have to pull the plug on the display engine on pre-g4x platforms. > > > There are no modeset/gem locks taken inside __intel_atomic_commit_tail() > > > itself, and we wait for all dependencies before the down_read(), and > > > thus there is no chance of deadlocks with this scheme. > > > > How does this solve the deadlock? Afaiui the deadlock is that the gpu > > reset stopped unconditionally completing all requests before it did > > anything else, including anything with the hw or taking modeset locks. > > > > This ensured that any outstanding flips (we only had pageflips, no atomic > > ones back then) could complete (although maybe displaying garbage). The > > only thing we had to do was grab the locks (to avoid concurrent modesets) > > and then we could happily nuke the hw (since the flips where lost in the > > CS anyway), and restore it afterwards. > > > > Then the TDR rewrite came around and broke that, which now makes atomic > > time out waiting for the gpu to complete (because the gpu reset waits for > > the modeset to complete first). Which means if you want to fix this > > without breaking TDR, then you need to cancel the pending atomic commits. > > That seems somewhat what you're attempting here with trying to figure out > > what the latest hw-committed step is (but that function gets it wrong), > > and lots more locking and stuff on top. > > > > Why exactly can't we just go back to the old world of force-completing > > dead requests on gen4 and earlier? That would be tons simpler imo instead > > of throwing a pile of hacks (which really needs a complete rewrite of the > > atomic code in i915) in as a work-around. We didn't have TDR on gen4 and > > earlier for years, going back to that isn't going to hurt anyone. > > > > Making working gen4 gpu reset contigent on cancellable atomic commits and > > the full commit queue is imo nuts. > > And if the GEM folks insist the old behavior can't be restored, then we > just need a tailor-made get-out-of-jail card for gen4 gpu reset somewhere > in i915_sw_fence. Force-completing all render requests atomic updates > depend upon is imo the simplest solution to this, and we've had a driver > that worked like that for years. And it used to break all the time. I think we've had to fix it at least three times by now. So I tend to think it's better to fix it in a way that won't break so easily. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts
This patch fixes the DP AUX CH timeouts observed during CI IGT
tests thus fixing the CI failures. This is done by adding a
quirk for a particular PCI device that requires the panel power
cycle delay (T12) to be set to 800ms which is 300msecs more than
the minimum value specified in the eDP spec. So a quirk is
implemented for that specific PCI device.
v4:
* Add Bugzilla links for FDO bugs in the commit message (Ville, Jani)
v3:
* Change some comments, specify the delay as 800 * 10 (Ville)
v2:
* Change the function and variable names to from PPS_T12_
to _T12 since it is a T12 delay (Clint)
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101144
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101154
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101167
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101515
Cc: Ville Syrjala
Cc: Clinton Taylor
Signed-off-by: Manasi Navare
Reviewed-by: Clinton Taylor
Acked-by: Ville Syrjala
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_display.c | 14 ++
drivers/gpu/drm/i915/intel_dp.c | 11 +++
3 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index effbe4f..4bef5d3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1167,6 +1167,7 @@ enum intel_sbi_destination {
#define QUIRK_INVERT_BRIGHTNESS (1<<2)
#define QUIRK_BACKLIGHT_PRESENT (1<<3)
#define QUIRK_PIN_SWIZZLED_PAGES (1<<5)
+#define QUIRK_INCREASE_T12_DELAY (1<<6)
struct intel_fbdev;
struct intel_fbc_work;
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4e03ca6..87dfde9 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14765,6 +14765,17 @@ static void quirk_backlight_present(struct drm_device
*dev)
DRM_INFO("applying backlight present quirk\n");
}
+/* Toshiba Satellite P50-C-18C requires T12 delay to be min 800ms
+ * which is 300 ms greater than eDP spec T12 min.
+ */
+static void quirk_increase_t12_delay(struct drm_device *dev)
+{
+ struct drm_i915_private *dev_priv = to_i915(dev);
+
+ dev_priv->quirks |= QUIRK_INCREASE_T12_DELAY;
+ DRM_INFO("Applying T12 delay quirk\n");
+}
+
struct intel_quirk {
int device;
int subsystem_vendor;
@@ -14848,6 +14859,9 @@ static struct intel_quirk intel_quirks[] = {
/* Dell Chromebook 11 (2015 version) */
{ 0x0a16, 0x1028, 0x0a35, quirk_backlight_present },
+
+ /* Toshiba Satellite P50-C-18C */
+ { 0x191B, 0x1179, 0xF840, quirk_increase_t12_delay },
};
static void intel_init_quirks(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 67bc8a7a..538950c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5230,6 +5230,17 @@ intel_dp_init_panel_power_sequencer(struct drm_device
*dev,
intel_pps_dump_state("cur", &cur);
vbt = dev_priv->vbt.edp.pps;
+ /* On Toshiba Satellite P50-C-18C system the VBT T12 delay
+* of 500ms appears to be too short. Ocassionally the panel
+* just fails to power back on. Increasing the delay to 800ms
+* seems sufficient to avoid this problem.
+*/
+ if (dev_priv->quirks & QUIRK_INCREASE_T12_DELAY) {
+
+ vbt.t11_t12 = max_t(u16, vbt.t11_t12, 800 * 10);
+ DRM_DEBUG_KMS("Increasing T12 panel delay as per the quirk to
%d\n",
+ vbt.t11_t12);
+ }
/* T11_T12 delay is special and actually in units of 100ms, but zero
* based in the hw (so we need to add 100 ms). But the sw vbt
* table multiplies it with 1000 to make it in units of 100usec,
--
2.1.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts (rev3)
== Series Details == Series: drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts (rev3) URL : https://patchwork.freedesktop.org/series/26518/ State : success == Summary == Series 26518v3 drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts https://patchwork.freedesktop.org/api/1.0/series/26518/revisions/3/mbox/ Test kms_busy: Subgroup basic-flip-default-b: fail -> PASS (fi-skl-6700hq) fdo#101144 +2 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: fail -> PASS (fi-skl-6700hq) fdo#101154 +24 Test kms_flip: Subgroup basic-flip-vs-modeset: skip -> PASS (fi-skl-6700hq) Subgroup basic-flip-vs-wf_vblank: skip -> PASS (fi-skl-6700hq) Subgroup basic-plain-flip: skip -> PASS (fi-skl-6700hq) Test kms_frontbuffer_tracking: Subgroup basic: skip -> PASS (fi-skl-6700hq) Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: dmesg-warn -> PASS (fi-pnv-d510) fdo#101597 Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101516 fail -> PASS (fi-skl-6700hq) fdo#100461 +1 Test kms_setmode: Subgroup basic-clone-single-crtc: warn -> PASS (fi-skl-6700hq) fdo#101518 Test kms_sink_crc_basic: fail -> PASS (fi-skl-6700hq) fdo#101519 Test pm_rpm: Subgroup basic-pci-d3-state: skip -> PASS (fi-skl-6700hq) Subgroup basic-rte: skip -> PASS (fi-skl-6700hq) fdo#101144 https://bugs.freedesktop.org/show_bug.cgi?id=101144 fdo#101154 https://bugs.freedesktop.org/show_bug.cgi?id=101154 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fdo#101516 https://bugs.freedesktop.org/show_bug.cgi?id=101516 fdo#100461 https://bugs.freedesktop.org/show_bug.cgi?id=100461 fdo#101518 https://bugs.freedesktop.org/show_bug.cgi?id=101518 fdo#101519 https://bugs.freedesktop.org/show_bug.cgi?id=101519 fi-bdw-5557u total:279 pass:264 dwarn:0 dfail:0 fail:3 skip:11 time:446s fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 time:435s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:355s fi-bsw-n3050 total:279 pass:239 dwarn:0 dfail:0 fail:3 skip:36 time:513s fi-bxt-j4205 total:279 pass:256 dwarn:0 dfail:0 fail:3 skip:19 time:504s fi-byt-j1900 total:279 pass:250 dwarn:1 dfail:0 fail:3 skip:24 time:477s fi-byt-n2820 total:279 pass:246 dwarn:1 dfail:0 fail:3 skip:28 time:476s fi-glk-2atotal:279 pass:256 dwarn:0 dfail:0 fail:3 skip:19 time:583s fi-hsw-4770 total:279 pass:259 dwarn:0 dfail:0 fail:3 skip:16 time:431s fi-hsw-4770r total:279 pass:259 dwarn:0 dfail:0 fail:3 skip:16 time:413s fi-ilk-650 total:279 pass:225 dwarn:0 dfail:0 fail:3 skip:50 time:412s fi-ivb-3520m total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:495s fi-ivb-3770 total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:472s fi-kbl-7500u total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:459s fi-kbl-7560u total:279 pass:264 dwarn:1 dfail:0 fail:3 skip:10 time:560s fi-kbl-r total:279 pass:256 dwarn:1 dfail:0 fail:3 skip:18 time:573s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:552s fi-skl-6260u total:279 pass:265 dwarn:0 dfail:0 fail:3 skip:10 time:450s fi-skl-6700hqtotal:279 pass:257 dwarn:1 dfail:0 fail:3 skip:17 time:606s fi-skl-6700k total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:460s fi-skl-6770hqtotal:279 pass:265 dwarn:0 dfail:0 fail:3 skip:10 time:476s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:432s fi-snb-2520m total:279 pass:247 dwarn:0 dfail:0 fail:3 skip:28 time:536s fi-snb-2600 total:279 pass:246 dwarn:0 dfail:0 fail:3 skip:29 time:400s 6412bcb8e279d62b9d8ae2840712d6c85806369b drm-tip: 2017y-06m-30d-14h-56m-41s UTC integration manifest 1bda2ed drm/i915/edp: Add a T12 panel delay quirk to fix DP AUX CH timeouts == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5080/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/fb-helper: Restore first connection behaviour on deferred setup
Prior to commit b0aa06e9a7fd ("drm/fb-helper: Support deferred setup"),
if no output is connected at framebuffer setup time, we get a default
1024x768 mode that is going to be used when we first connect a monitor.
After the commit, on first connection after deferred setup, we probe
the monitor and get the preferred resolution, but no mode get set
because the drm_fb_helper_hotplug_event() function returns early
when the setup has been deferred. That is different from what happens
on a second re-connect of the monitor, when the native mode get set.
Create a more consistent behaviour by checking in the
drm_fb_helper_hotplug_event() function if the deferred setup is still
active. If not, that means we now have a valid framebuffer that can be
used for setting the correct mode.
Fixes: b0aa06e9a7fd ("drm/fb-helper: Support deferred setup")
Signed-off-by: Liviu Dudau
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_fb_helper.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
index d833eb2320d1..bb7b44d284ec 100644
--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2444,6 +2444,7 @@ static int __drm_fb_helper_initial_config(struct
drm_fb_helper *fb_helper,
if (ret == -EAGAIN) {
fb_helper->preferred_bpp = bpp_sel;
fb_helper->deferred_setup = true;
+ ret = 0;
}
mutex_unlock(&fb_helper->lock);
@@ -2565,7 +2566,13 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper
*fb_helper)
if (fb_helper->deferred_setup) {
err = __drm_fb_helper_initial_config(fb_helper,
fb_helper->preferred_bpp);
- return err;
+ /*
+* __drm_fb_helper_initial_config can change deferred_setup,
+* if 'false' that means we can go ahead with the rest of
+* the setup as normal
+*/
+ if (fb_helper->deferred_setup)
+ return err;
}
if (!fb_helper->fb || !drm_fb_helper_is_bound(fb_helper)) {
--
2.13.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION 4.12] i915 Oops at intel_fbdev_invalidate()
On Fri, 30 Jun 2017 17:40:43 +0200, Chris Wilson wrote: > > Quoting Takashi Iwai (2017-06-30 16:38:46) > > Hi, > > > > I hit an Oops with the latest Linus tree (4.12-rc7+) on a HSW machine > > like the following at boot: > > > > BUG: unable to handle kernel NULL pointer dereference at 00b0 > > IP: intel_fbdev_invalidate.isra.3+0xc/0x40 [i915] > > Oops: [#1] PREEMPT SMP > > CPU: 2 PID: 833 Comm: X Not tainted 4.10.0-rc5-btest9+ #15 > > Hardware name: Hewlett-Packard HP ProBook 430 G1/1946, BIOS L73 Ver. 08.05 > > 2013/03/15 > > task: 917313db8000 task.stack: b6e70379c000 > > RIP: 0010:intel_fbdev_invalidate.isra.3+0xc/0x40 [i915] > > RSP: 0018:b6e70379fde0 EFLAGS: 00010246 > > RAX: RBX: 9172f70e1c00 RCX: > > RDX: 917313db8000 RSI: RDI: 91731934d040 > > RBP: b6e70379fdf0 R08: 0002 R09: 91731934ead0 > > R10: 9173192f0368 R11: 0001 R12: 9173192f > > R13: 9172f71016e8 R14: 9173227c8480 R15: 9172f71016c8 > > FS: 7f8cc8c3fa00() GS:9173c0a8() > > knlGS: > > CS: 0010 DS: ES: CR0: 80050033 > > CR2: 00b0 CR3: 6273b000 CR4: 001406e0 > > Call Trace: > > ? intel_fbdev_restore_mode+0x4e/0x70 [i915] > > i915_driver_lastclose+0xe/0x20 [i915] > > drm_lastclose+0x3b/0xf0 [drm] > > drm_release+0x2b8/0x360 [drm] > > __fput+0xd9/0x1e0 > > fput+0xe/0x10 > > task_work_run+0x83/0xa0 > > exit_to_usermode_loop+0x59/0x85 > > do_syscall_64+0xb3/0xd0 > > entry_SYSCALL64_slow_path+0x25/0x25 > > > > And git bisection leaded to the commit > > fabef825626d7bd05a321e4427fdf31a169b5173 > > drm/i915: Drop struct_mutex around frontbuffer flushes > > > > The band-aid patch below seems fixing it. > > See https://patchwork.freedesktop.org/patch/163261/ Thanks, it worked. Tested-by: Takashi Iwai Could you guys pick it up to for-linus? For 4.12 it's likely too late, but there might be a miracle. Takashi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/5] x86/io: Include asm-generic/io.h to architectural code
asm-generic/io.h defines few helpers which would be useful in the drivers, such as writesb() and readsb(). Include it to the asm/io.h in architectural folder. Acked-by: Wolfram Sang Signed-off-by: Andy Shevchenko --- arch/x86/include/asm/io.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index c1c0880768f7..0558d81c177e 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -406,6 +406,9 @@ extern bool xen_biovec_phys_mergeable(const struct bio_vec *vec1, #define IO_SPACE_LIMIT 0x +#include +#undef PCI_IOBASE + #ifdef CONFIG_MTRR extern int __must_check arch_phys_wc_index(int handle); #define arch_phys_wc_index arch_phys_wc_index -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/5] x86/io: Rely on asm-generic/io.h
The series brings a bit of order to arch/x86/include/asm/io.h by re-using definitions in the generic header. The series has been tested on Intel Broxton hardware in 32- and 64-bit modes. Since v2: - add cleanup patches in accordance to re-use what's defined in generic header - split to few patches - hopefully nail down an issue kbuild bot complained about - append tags (Wolfram) Andy Shevchenko (5): x86/io: Define IO accessors by preprocessor x86/io: Include asm-generic/io.h to architectural code x86/io: Remove mem*io() duplications x86/io: Remove xlate_dev_kmem_ptr() duplication x86/io: Make readq() / writeq() API consistent arch/x86/include/asm/io.h | 98 +++ include/asm-generic/io.h | 27 + 2 files changed, 74 insertions(+), 51 deletions(-) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/5] x86/io: Remove mem*io() duplications
Generic header defines memset_io, memcpy_fromio(). and memcpy_toio().
Reuse them from generic header and remove in x86 code.
Move the descriptions to the generic header as well.
Signed-off-by: Andy Shevchenko
---
arch/x86/include/asm/io.h | 45 -
include/asm-generic/io.h | 24
2 files changed, 24 insertions(+), 45 deletions(-)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 0558d81c177e..252434b00fdb 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -220,51 +220,6 @@ extern void set_iounmap_nonlazy(void);
*/
#define xlate_dev_kmem_ptr(p) p
-/**
- * memset_io Set a range of I/O memory to a constant value
- * @addr: The beginning of the I/O-memory range to set
- * @val: The value to set the memory to
- * @count: The number of bytes to set
- *
- * Set a range of I/O memory to a given value.
- */
-static inline void
-memset_io(volatile void __iomem *addr, unsigned char val, size_t count)
-{
- memset((void __force *)addr, val, count);
-}
-#define memset_io(dst,c,count) memset_io(dst,c,count)
-
-/**
- * memcpy_fromio Copy a block of data from I/O memory
- * @dst: The (RAM) destination for the copy
- * @src: The (I/O memory) source for the data
- * @count: The number of bytes to copy
- *
- * Copy a block of data from I/O memory.
- */
-static inline void
-memcpy_fromio(void *dst, const volatile void __iomem *src, size_t count)
-{
- memcpy(dst, (const void __force *)src, count);
-}
-#define memcpy_fromio(to,from,count) memcpy_fromio(to,from,count)
-
-/**
- * memcpy_toio Copy a block of data into I/O memory
- * @dst: The (I/O memory) destination for the copy
- * @src: The (RAM) source for the data
- * @count: The number of bytes to copy
- *
- * Copy a block of data to I/O memory.
- */
-static inline void
-memcpy_toio(volatile void __iomem *dst, const void *src, size_t count)
-{
- memcpy((void __force *)dst, src, count);
-}
-#define memcpy_toio(to,from,count) memcpy_toio(to,from,count)
-
/*
* ISA space is 'always mapped' on a typical x86 system, no need to
* explicitly ioremap() it. The fact that the ISA IO space is mapped
diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
index 7ef015eb3403..395afc829409 100644
--- a/include/asm-generic/io.h
+++ b/include/asm-generic/io.h
@@ -954,6 +954,14 @@ static inline void *bus_to_virt(unsigned long address)
#ifndef memset_io
#define memset_io memset_io
+/**
+ * memset_io Set a range of I/O memory to a constant value
+ * @addr: The beginning of the I/O-memory range to set
+ * @val: The value to set the memory to
+ * @count: The number of bytes to set
+ *
+ * Set a range of I/O memory to a given value.
+ */
static inline void memset_io(volatile void __iomem *addr, int value,
size_t size)
{
@@ -963,6 +971,14 @@ static inline void memset_io(volatile void __iomem *addr,
int value,
#ifndef memcpy_fromio
#define memcpy_fromio memcpy_fromio
+/**
+ * memcpy_fromio Copy a block of data from I/O memory
+ * @dst: The (RAM) destination for the copy
+ * @src: The (I/O memory) source for the data
+ * @count: The number of bytes to copy
+ *
+ * Copy a block of data from I/O memory.
+ */
static inline void memcpy_fromio(void *buffer,
const volatile void __iomem *addr,
size_t size)
@@ -973,6 +989,14 @@ static inline void memcpy_fromio(void *buffer,
#ifndef memcpy_toio
#define memcpy_toio memcpy_toio
+/**
+ * memcpy_toio Copy a block of data into I/O memory
+ * @dst: The (I/O memory) destination for the copy
+ * @src: The (RAM) source for the data
+ * @count: The number of bytes to copy
+ *
+ * Copy a block of data to I/O memory.
+ */
static inline void memcpy_toio(volatile void __iomem *addr, const void *buffer,
size_t size)
{
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/5] x86/io: Make readq() / writeq() API consistent
Despite the commit 93093d099e5d x86: provide readq()/writeq() on 32-bit too, complete says ...Also, map all the APIs to the strongest ordering variant. It's way too easy to mess such details up in drivers and the difference between "memory" and "" constrained asm() constructs is in the noise range. we have for now only one user of this API (i.e. writeq_relaxed() in drivers/hwtracing/intel_th/sth.c) on x86 and it does care about "relaxed" part of it. Moreover 32-bit support has been removed from that header, though appeared later in specific headers that emphasizes its non-atomic context. The rest should keep in mind consistent picture of __raw_IO() vs. IO() vs. IO_relaxed() API. Signed-off-by: Andy Shevchenko --- arch/x86/include/asm/io.h | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index b3bba2f87e18..9ada93f01524 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -94,13 +94,15 @@ build_mmio_write(__writel, "l", unsigned int, "r", ) #ifdef CONFIG_X86_64 build_mmio_read(readq, "q", unsigned long, "=r", :"memory") +build_mmio_read(__readq, "q", unsigned long, "=r", ) build_mmio_write(writeq, "q", unsigned long, "r", :"memory") +build_mmio_write(__writeq, "q", unsigned long, "r", ) -#define readq_relaxed(a) readq(a) -#define writeq_relaxed(v, a) writeq(v, a) +#define readq_relaxed(a) __readq(a) +#define writeq_relaxed(v, a) __writeq(v, a) -#define __raw_readq(a) readq(a) -#define __raw_writeq(val, addr)writeq(val, addr) +#define __raw_readq__readq +#define __raw_writeq __writeq /* Let people know that we have them */ #define readq readq -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/5] x86/io: Define IO accessors by preprocessor
As a preparatory to use generic IO accessor helpers we need to define
architecture dependent functions via preprocessor to let world know we
have them.
Acked-by: Wolfram Sang
Signed-off-by: Andy Shevchenko
---
arch/x86/include/asm/io.h | 41 +
1 file changed, 41 insertions(+)
diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index 7afb0e2f07f4..c1c0880768f7 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -69,6 +69,9 @@ build_mmio_write(__writeb, "b", unsigned char, "q", )
build_mmio_write(__writew, "w", unsigned short, "r", )
build_mmio_write(__writel, "l", unsigned int, "r", )
+#define readb readb
+#define readw readw
+#define readl readl
#define readb_relaxed(a) __readb(a)
#define readw_relaxed(a) __readw(a)
#define readl_relaxed(a) __readl(a)
@@ -76,6 +79,9 @@ build_mmio_write(__writel, "l", unsigned int, "r", )
#define __raw_readw __readw
#define __raw_readl __readl
+#define writeb writeb
+#define writew writew
+#define writel writel
#define writeb_relaxed(v, a) __writeb(v, a)
#define writew_relaxed(v, a) __writew(v, a)
#define writel_relaxed(v, a) __writel(v, a)
@@ -119,6 +125,7 @@ static inline phys_addr_t virt_to_phys(volatile void
*address)
{
return __pa(address);
}
+#define virt_to_phys virt_to_phys
/**
* phys_to_virt- map physical address to virtual
@@ -137,6 +144,7 @@ static inline void *phys_to_virt(phys_addr_t address)
{
return __va(address);
}
+#define phys_to_virt phys_to_virt
/*
* Change "struct page" to physical address.
@@ -169,11 +177,14 @@ static inline unsigned int isa_virt_to_bus(volatile void
*address)
* else, you probably want one of the following.
*/
extern void __iomem *ioremap_nocache(resource_size_t offset, unsigned long
size);
+#define ioremap_nocache ioremap_nocache
extern void __iomem *ioremap_uc(resource_size_t offset, unsigned long size);
#define ioremap_uc ioremap_uc
extern void __iomem *ioremap_cache(resource_size_t offset, unsigned long size);
+#define ioremap_cache ioremap_cache
extern void __iomem *ioremap_prot(resource_size_t offset, unsigned long size,
unsigned long prot_val);
+#define ioremap_prot ioremap_prot
/**
* ioremap - map bus memory into CPU space
@@ -193,8 +204,10 @@ static inline void __iomem *ioremap(resource_size_t
offset, unsigned long size)
{
return ioremap_nocache(offset, size);
}
+#define ioremap ioremap
extern void iounmap(volatile void __iomem *addr);
+#define iounmap iounmap
extern void set_iounmap_nonlazy(void);
@@ -220,6 +233,7 @@ memset_io(volatile void __iomem *addr, unsigned char val,
size_t count)
{
memset((void __force *)addr, val, count);
}
+#define memset_io(dst,c,count) memset_io(dst,c,count)
/**
* memcpy_fromio Copy a block of data from I/O memory
@@ -234,6 +248,7 @@ memcpy_fromio(void *dst, const volatile void __iomem *src,
size_t count)
{
memcpy(dst, (const void __force *)src, count);
}
+#define memcpy_fromio(to,from,count) memcpy_fromio(to,from,count)
/**
* memcpy_toio Copy a block of data into I/O memory
@@ -248,6 +263,7 @@ memcpy_toio(volatile void __iomem *dst, const void *src,
size_t count)
{
memcpy((void __force *)dst, src, count);
}
+#define memcpy_toio(to,from,count) memcpy_toio(to,from,count)
/*
* ISA space is 'always mapped' on a typical x86 system, no need to
@@ -341,13 +357,38 @@ BUILDIO(b, b, char)
BUILDIO(w, w, short)
BUILDIO(l, , int)
+#define inb inb
+#define inw inw
+#define inl inl
+#define inb_p inb_p
+#define inw_p inw_p
+#define inl_p inl_p
+#define insb insb
+#define insw insw
+#define insl insl
+
+#define outb outb
+#define outw outw
+#define outl outl
+#define outb_p outb_p
+#define outw_p outw_p
+#define outl_p outl_p
+#define outsb outsb
+#define outsw outsw
+#define outsl outsl
+
extern void *xlate_dev_mem_ptr(phys_addr_t phys);
extern void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr);
+#define xlate_dev_mem_ptr xlate_dev_mem_ptr
+#define unxlate_dev_mem_ptr unxlate_dev_mem_ptr
+
extern int ioremap_change_attr(unsigned long vaddr, unsigned long size,
enum page_cache_mode pcm);
extern void __iomem *ioremap_wc(resource_size_t offset, unsigned long size);
+#define ioremap_wc ioremap_wc
extern void __iomem *ioremap_wt(resource_size_t offset, unsigned long size);
+#define ioremap_wt ioremap_wt
extern bool is_early_ioremap_ptep(pte_t *ptep);
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/5] x86/io: Remove xlate_dev_kmem_ptr() duplication
Generic header defines xlate_dev_kmem_ptr(). Reuse it from generic header and remove in x86 code. Move a description to the generic header as well. Signed-off-by: Andy Shevchenko --- arch/x86/include/asm/io.h | 5 - include/asm-generic/io.h | 3 +++ 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h index 252434b00fdb..b3bba2f87e18 100644 --- a/arch/x86/include/asm/io.h +++ b/arch/x86/include/asm/io.h @@ -216,11 +216,6 @@ extern void set_iounmap_nonlazy(void); #include /* - * Convert a virtual cached pointer to an uncached pointer - */ -#define xlate_dev_kmem_ptr(p) p - -/* * ISA space is 'always mapped' on a typical x86 system, no need to * explicitly ioremap() it. The fact that the ISA IO space is mapped * to PAGE_OFFSET is pure coincidence - it does not mean ISA values diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h index 395afc829409..b4531e3b2120 100644 --- a/include/asm-generic/io.h +++ b/include/asm-generic/io.h @@ -915,6 +915,9 @@ extern void ioport_unmap(void __iomem *p); #endif /* CONFIG_GENERIC_IOMAP */ #endif /* CONFIG_HAS_IOPORT_MAP */ +/* + * Convert a virtual cached pointer to an uncached pointer + */ #ifndef xlate_dev_kmem_ptr #define xlate_dev_kmem_ptr xlate_dev_kmem_ptr static inline void *xlate_dev_kmem_ptr(void *addr) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for x86/io: Rely on asm-generic/io.h
== Series Details == Series: x86/io: Rely on asm-generic/io.h URL : https://patchwork.freedesktop.org/series/26649/ State : success == Summary == Series 26649v1 x86/io: Rely on asm-generic/io.h https://patchwork.freedesktop.org/api/1.0/series/26649/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-b: dmesg-warn -> PASS (fi-pnv-d510) fdo#101597 Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101516 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fdo#101516 https://bugs.freedesktop.org/show_bug.cgi?id=101516 fi-bdw-5557u total:279 pass:264 dwarn:0 dfail:0 fail:3 skip:11 time:441s fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 time:426s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:357s fi-bsw-n3050 total:279 pass:239 dwarn:0 dfail:0 fail:3 skip:36 time:510s fi-bxt-j4205 total:279 pass:256 dwarn:0 dfail:0 fail:3 skip:19 time:501s fi-byt-j1900 total:279 pass:250 dwarn:1 dfail:0 fail:3 skip:24 time:484s fi-byt-n2820 total:279 pass:246 dwarn:1 dfail:0 fail:3 skip:28 time:473s fi-glk-2atotal:279 pass:256 dwarn:0 dfail:0 fail:3 skip:19 time:581s fi-hsw-4770 total:279 pass:259 dwarn:0 dfail:0 fail:3 skip:16 time:432s fi-hsw-4770r total:279 pass:259 dwarn:0 dfail:0 fail:3 skip:16 time:414s fi-ilk-650 total:279 pass:225 dwarn:0 dfail:0 fail:3 skip:50 time:417s fi-ivb-3520m total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:486s fi-ivb-3770 total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:474s fi-kbl-7500u total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:460s fi-kbl-7560u total:279 pass:264 dwarn:1 dfail:0 fail:3 skip:10 time:562s fi-kbl-r total:279 pass:256 dwarn:1 dfail:0 fail:3 skip:18 time:561s fi-pnv-d510 total:279 pass:222 dwarn:2 dfail:0 fail:0 skip:55 time:559s fi-skl-6260u total:279 pass:265 dwarn:0 dfail:0 fail:3 skip:10 time:451s fi-skl-6700hqtotal:279 pass:219 dwarn:1 dfail:0 fail:33 skip:24 time:331s fi-skl-6700k total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:467s fi-skl-6770hqtotal:279 pass:265 dwarn:0 dfail:0 fail:3 skip:10 time:472s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:435s fi-snb-2520m total:279 pass:247 dwarn:0 dfail:0 fail:3 skip:28 time:538s fi-snb-2600 total:279 pass:246 dwarn:0 dfail:0 fail:3 skip:29 time:403s 6412bcb8e279d62b9d8ae2840712d6c85806369b drm-tip: 2017y-06m-30d-14h-56m-41s UTC integration manifest 5c9d6dc x86/io: Make readq() / writeq() API consistent d47ceb1 x86/io: Remove xlate_dev_kmem_ptr() duplication 95a7ac2 x86/io: Remove mem*io() duplications fb67a5d x86/io: Include asm-generic/io.h to architectural code b34944e x86/io: Define IO accessors by preprocessor == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5081/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/guc: Prevent ggtt->invalidate assert during GuC reload
The driver reloads the GuC firmware after full gpu reset or
suspend/resume, but it never disables the GuC beforehand.
This leads us to hit the assert inside i915_ggtt_enable_guc added
by commit 04f7b24eccdf ("drm/i915/guc: Assert that we switch between
known ggtt->invalidate functions").
As a workaround, don't call i915_ggtt_enable_guc if there is a GuC
execbuf_client; because if there isn't one we are either loading in a
fresh system or we called intel_uc_fini_hw.
I'm inclined to this approach because even if intel_uc_fini_hw could be
added to the suspend path, we will still need to keep this for the
full gpu reset case.
Cc: Chris Wilson
Cc: Michal Winiarski
Cc: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/intel_uc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index a8930f2feacf..564b0d2b8842 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -339,8 +339,14 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
guc_disable_communication(guc);
gen9_reset_guc_interrupts(dev_priv);
- /* We need to notify the guc whenever we change the GGTT */
- i915_ggtt_enable_guc(dev_priv);
+ /*
+* We need to notify the guc whenever we change the GGTT; but if we
+* are reloading the firmware (after full gpu reset or suspend/resume),
+* we should skip this since gtt->invalidate was already set (or we hit
+* an assert).
+*/
+ if (!dev_priv->guc.execbuf_client)
+ i915_ggtt_enable_guc(dev_priv);
if (i915.enable_guc_submission) {
/*
--
2.11.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Prevent ggtt->invalidate assert during GuC reload
== Series Details == Series: drm/i915/guc: Prevent ggtt->invalidate assert during GuC reload URL : https://patchwork.freedesktop.org/series/26651/ State : success == Summary == Series 26651v1 drm/i915/guc: Prevent ggtt->invalidate assert during GuC reload https://patchwork.freedesktop.org/api/1.0/series/26651/revisions/1/mbox/ Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101516 fdo#101516 https://bugs.freedesktop.org/show_bug.cgi?id=101516 fi-bdw-5557u total:279 pass:264 dwarn:0 dfail:0 fail:3 skip:11 time:436s fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 time:429s fi-blb-e6850 total:279 pass:224 dwarn:1 dfail:0 fail:0 skip:54 time:354s fi-bsw-n3050 total:279 pass:239 dwarn:0 dfail:0 fail:3 skip:36 time:516s fi-bxt-j4205 total:279 pass:256 dwarn:0 dfail:0 fail:3 skip:19 time:499s fi-byt-j1900 total:279 pass:250 dwarn:1 dfail:0 fail:3 skip:24 time:475s fi-byt-n2820 total:279 pass:246 dwarn:1 dfail:0 fail:3 skip:28 time:481s fi-glk-2atotal:279 pass:256 dwarn:0 dfail:0 fail:3 skip:19 time:591s fi-hsw-4770 total:279 pass:259 dwarn:0 dfail:0 fail:3 skip:16 time:426s fi-hsw-4770r total:279 pass:259 dwarn:0 dfail:0 fail:3 skip:16 time:408s fi-ilk-650 total:279 pass:225 dwarn:0 dfail:0 fail:3 skip:50 time:415s fi-ivb-3520m total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:488s fi-ivb-3770 total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:469s fi-kbl-7500u total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:458s fi-kbl-7560u total:279 pass:264 dwarn:1 dfail:0 fail:3 skip:10 time:559s fi-kbl-r total:279 pass:256 dwarn:1 dfail:0 fail:3 skip:18 time:564s fi-pnv-d510 total:279 pass:221 dwarn:3 dfail:0 fail:0 skip:55 time:554s fi-skl-6260u total:279 pass:265 dwarn:0 dfail:0 fail:3 skip:10 time:452s fi-skl-6700hqtotal:279 pass:219 dwarn:1 dfail:0 fail:33 skip:24 time:330s fi-skl-6700k total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:461s fi-skl-6770hqtotal:279 pass:265 dwarn:0 dfail:0 fail:3 skip:10 time:471s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:437s fi-snb-2520m total:279 pass:247 dwarn:0 dfail:0 fail:3 skip:28 time:538s fi-snb-2600 total:279 pass:246 dwarn:0 dfail:0 fail:3 skip:29 time:402s 6412bcb8e279d62b9d8ae2840712d6c85806369b drm-tip: 2017y-06m-30d-14h-56m-41s UTC integration manifest 9fa53c2 drm/i915/guc: Prevent ggtt->invalidate assert during GuC reload == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5082/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 0/6] drm: add asynchrounous plane update
From: Gustavo Padovan Hi, Follow up after Daniel's comments. Here I move the common async code to drm_atomic_helper.c. i915 and msm now have to call the drm_atomic_helper_async_check() themselves. Please review! Thanks. Gustavo Gustavo Padovan (6): drm/atomic: initial support for asynchronous plane update drm/i915: update cursors asynchronously through atomic drm/i915: remove intel_cursor_plane_funcs drm/msm: update cursors asynchronously through atomic drm/msm: remove mdp5_cursor_plane_funcs drm/vc4: update cursors asynchronously through atomic drivers/gpu/drm/drm_atomic_helper.c | 122 + drivers/gpu/drm/i915/intel_atomic_plane.c | 73 + drivers/gpu/drm/i915/intel_display.c | 163 +--- drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 175 +++--- drivers/gpu/drm/msm/msm_atomic.c | 9 ++ drivers/gpu/drm/vc4/vc4_kms.c | 20 drivers/gpu/drm/vc4/vc4_plane.c | 128 +- include/drm/drm_atomic.h | 2 + include/drm/drm_atomic_helper.h | 4 + include/drm/drm_modeset_helper_vtables.h | 50 + 10 files changed, 423 insertions(+), 323 deletions(-) -- 2.9.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/6] drm/atomic: initial support for asynchronous plane update
From: Gustavo Padovan
In some cases, like cursor updates, it is interesting to update the
plane in an asynchronous fashion to avoid big delays. The current queued
update could be still waiting for a fence to signal and thus block any
subsequent update until its scan out. In cases like this if we update the
cursor synchronously through the atomic API it will cause significant
delays that would even be noticed by the final user.
This patch creates a fast path to jump ahead the current queued state and
do single planes updates without going through all atomic steps in
drm_atomic_helper_commit(). We take this path for legacy cursor updates.
For now only single plane updates are supported, but we plan to support
multiple planes updates and async PageFlips through this interface as well
in the near future.
v6: - move check code to drm_atomic_helper.c (Daniel Vetter)
v5:
- improve comments (Eric Anholt)
v4:
- fix state->crtc NULL check (Archit Taneja)
v3:
- fix iteration on the wrong crtc state
- put back code to forbid updates if there is a queued update for
the same plane (Ville Syrjälä)
- move size checks back to drivers (Ville Syrjälä)
- move ASYNC_UPDATE flag addition to its own patch (Ville Syrjälä)
v2:
- allow updates even if there is a queued update for the same
plane.
- fixes on the documentation (Emil Velikov)
- unconditionally call ->atomic_async_update (Emil Velikov)
- check for ->atomic_async_update earlier (Daniel Vetter)
- make ->atomic_async_check() the last step (Daniel Vetter)
- add ASYNC_UPDATE flag (Eric Anholt)
- update state in core after ->atomic_async_update (Eric Anholt)
- update docs (Eric Anholt)
Cc: Daniel Vetter
Cc: Rob Clark
Cc: Eric Anholt
Signed-off-by: Gustavo Padovan
Reviewed-by: Archit Taneja (v5)
Acked-by: Eric Anholt (v5)
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_atomic_helper.c | 122 +++
include/drm/drm_atomic.h | 2 +
include/drm/drm_atomic_helper.h | 4 +
include/drm/drm_modeset_helper_vtables.h | 50 +
4 files changed, 178 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 23e4661..4f6e529 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -795,6 +795,9 @@ int drm_atomic_helper_check(struct drm_device *dev,
if (ret)
return ret;
+ if (state->legacy_cursor_update)
+ state->async_update = !drm_atomic_helper_async_check(dev,
state);
+
return ret;
}
EXPORT_SYMBOL(drm_atomic_helper_check);
@@ -1353,6 +1356,114 @@ static void commit_work(struct work_struct *work)
}
/**
+ * drm_atomic_helper_async_check - check if state can be commited
asynchronously
+ * @dev: DRM device
+ * @state: the driver state object
+ *
+ * This helper will check if it is possible to commit the state asynchronously.
+ * Async commits are not supposed to swap the states like normal sync commits
+ * but just do in-place changes on the current state.
+ *
+ * It will return 0 if the commit can happen in an asynchronous fashion or
error
+ * if not. Note that error just mean it can't be commited asynchronously, if it
+ * fails the commit should be treated like a normal synchronous commit.
+ */
+int drm_atomic_helper_async_check(struct drm_device *dev,
+ struct drm_atomic_state *state)
+{
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+ struct drm_crtc_commit *commit;
+ struct drm_plane *__plane, *plane = NULL;
+ struct drm_plane_state *__plane_state, *plane_state = NULL;
+ const struct drm_plane_helper_funcs *funcs;
+ int i, j, n_planes = 0;
+
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+ if (drm_atomic_crtc_needs_modeset(crtc_state))
+ return -EINVAL;
+ }
+
+ for_each_new_plane_in_state(state, __plane, __plane_state, i) {
+ n_planes++;
+ plane = __plane;
+ plane_state = __plane_state;
+ }
+
+ /* FIXME: we support only single plane updates for now */
+ if (!plane || n_planes != 1)
+ return -EINVAL;
+
+ if (!plane_state->crtc)
+ return -EINVAL;
+
+ funcs = plane->helper_private;
+ if (!funcs->atomic_async_update)
+ return -EINVAL;
+
+ if (plane_state->fence)
+ return -EINVAL;
+
+ /*
+* Don't do an async update if there is an outstanding commit modifying
+* the plane. This prevents our async update's changes from getting
+* overridden by a previous synchronous update's state.
+*/
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+ if (plane->crtc != crtc)
+
[Intel-gfx] [PATCH v4 2/6] drm/i915: update cursors asynchronously through atomic
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
intel_legacy_cursor_update() did but through atomic.
v4:
- call drm_atomic_helper_async_check() from the check hook
v3:
- set correct vma to new state for cleanup
- move size checks back to drivers (Ville Syrjälä)
v2:
- move fb setting to core and use new state (Eric Anholt)
Cc: Daniel Vetter
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 73 ++
drivers/gpu/drm/i915/intel_display.c | 152 ++
2 files changed, 100 insertions(+), 125 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index 4325cb0..e9fa7ca 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -230,11 +230,84 @@ static void intel_plane_atomic_update(struct drm_plane
*plane,
}
}
+static int intel_plane_atomic_async_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct drm_crtc *crtc = plane->state->crtc;
+ struct drm_crtc_state *crtc_state = crtc->state;
+
+ if (plane->type != DRM_PLANE_TYPE_CURSOR)
+ return -EINVAL;
+
+ /*
+* When crtc is inactive or there is a modeset pending,
+* wait for it to complete in the slowpath
+*/
+ if (!crtc_state->active || to_intel_crtc_state(crtc_state)->update_pipe)
+ return -EINVAL;
+
+ /*
+* If any parameters change that may affect watermarks,
+* take the slowpath. Only changing fb or position should be
+* in the fastpath.
+*/
+ if (plane->state->crtc != state->crtc ||
+ plane->state->src_w != state->src_w ||
+ plane->state->src_h != state->src_h ||
+ plane->state->crtc_w != state->crtc_w ||
+ plane->state->crtc_h != state->crtc_h ||
+ !plane->state->fb != !state->fb)
+ return -EINVAL;
+
+ return 0;
+}
+
+static void intel_plane_atomic_async_update(struct drm_plane *plane,
+ struct drm_plane_state *new_state)
+{
+ struct intel_plane *intel_plane = to_intel_plane(plane);
+ struct drm_crtc *crtc = plane->state->crtc;
+ struct drm_framebuffer *old_fb;
+ struct i915_vma *old_vma;
+
+ old_vma = to_intel_plane_state(plane->state)->vma;
+ old_fb = plane->state->fb;
+
+ i915_gem_track_fb(intel_fb_obj(old_fb), intel_fb_obj(new_state->fb),
+ intel_plane->frontbuffer_bit);
+
+ plane->state->src_x = new_state->src_x;
+ plane->state->src_y = new_state->src_y;
+ plane->state->crtc_x = new_state->crtc_x;
+ plane->state->crtc_y = new_state->crtc_y;
+ plane->state->fb = new_state->fb;
+ *to_intel_plane_state(plane->state) = *to_intel_plane_state(new_state);
+
+ to_intel_plane_state(new_state)->vma = old_vma;
+ new_state->fb = old_fb;
+
+ if (plane->state->visible) {
+ trace_intel_update_plane(plane, to_intel_crtc(crtc));
+ intel_plane->update_plane(intel_plane,
+ to_intel_crtc_state(crtc->state),
+ to_intel_plane_state(plane->state));
+ } else {
+ trace_intel_disable_plane(plane, to_intel_crtc(crtc));
+ intel_plane->disable_plane(intel_plane, to_intel_crtc(crtc));
+ }
+
+ mutex_lock(&plane->dev->struct_mutex);
+ intel_cleanup_plane_fb(plane, new_state);
+ mutex_unlock(&plane->dev->struct_mutex);
+}
+
const struct drm_plane_helper_funcs intel_plane_helper_funcs = {
.prepare_fb = intel_prepare_plane_fb,
.cleanup_fb = intel_cleanup_plane_fb,
.atomic_check = intel_plane_atomic_check,
.atomic_update = intel_plane_atomic_update,
+ .atomic_async_check = intel_plane_atomic_async_check,
+ .atomic_async_update = intel_plane_atomic_async_update,
};
/**
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 4e03ca6..8817222 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12764,6 +12764,9 @@ static int intel_atomic_check(struct drm_device *dev,
if (ret)
return ret;
+ if (state->legacy_cursor_update)
+ state->async_update = !drm_atomic_helper_async_check(dev,
state);
+
intel_fbc_choose_crtc(dev_priv, state);
return calc_watermark_data(state);
}
@@ -13236,6 +13239,26 @@ static int intel_atomic_commit(struct drm_device *dev,
struct drm_i915_private *dev_priv = to_i915(dev);
int ret = 0;
+ /*
+* The atomic async update fast path takes care
+*
[Intel-gfx] [PATCH v4 5/6] drm/msm: remove mdp5_cursor_plane_funcs
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
mdp5_cursor_plane_funcs just duplicates mdp5_plane_funcs now.
Cc: Rob Clark
Cc: Archit Taneja
Signed-off-by: Gustavo Padovan
Tested-by: Archit Taneja
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 26 +++---
1 file changed, 3 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 60680e8..82aa887 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -246,19 +246,6 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
.atomic_print_state = mdp5_plane_atomic_print_state,
};
-static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
- .update_plane = drm_atomic_helper_update_plane,
- .disable_plane = drm_atomic_helper_disable_plane,
- .destroy = mdp5_plane_destroy,
- .set_property = drm_atomic_helper_plane_set_property,
- .atomic_set_property = mdp5_plane_atomic_set_property,
- .atomic_get_property = mdp5_plane_atomic_get_property,
- .reset = mdp5_plane_reset,
- .atomic_duplicate_state = mdp5_plane_duplicate_state,
- .atomic_destroy_state = mdp5_plane_destroy_state,
- .atomic_print_state = mdp5_plane_atomic_print_state,
-};
-
static int mdp5_plane_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *new_state)
{
@@ -1110,16 +1097,9 @@ struct drm_plane *mdp5_plane_init(struct drm_device *dev,
mdp5_plane->nformats = mdp_get_formats(mdp5_plane->formats,
ARRAY_SIZE(mdp5_plane->formats), false);
- if (type == DRM_PLANE_TYPE_CURSOR)
- ret = drm_universal_plane_init(dev, plane, 0xff,
- &mdp5_cursor_plane_funcs,
- mdp5_plane->formats, mdp5_plane->nformats,
- type, NULL);
- else
- ret = drm_universal_plane_init(dev, plane, 0xff,
- &mdp5_plane_funcs,
- mdp5_plane->formats, mdp5_plane->nformats,
- type, NULL);
+ ret = drm_universal_plane_init(dev, plane, 0xff, &mdp5_plane_funcs,
+ mdp5_plane->formats,
+ mdp5_plane->nformats, type, NULL);
if (ret)
goto fail;
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 3/6] drm/i915: remove intel_cursor_plane_funcs
From: Gustavo Padovan
After converting legacy cursor updates to atomic async commits
intel_cursor_plane_funcs just duplicates intel_plane_funcs now.
Cc: Daniel Vetter
Signed-off-by: Gustavo Padovan
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 8817222..73d2508 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13610,17 +13610,6 @@ const struct drm_plane_funcs intel_plane_funcs = {
.atomic_destroy_state = intel_plane_destroy_state,
};
-static const struct drm_plane_funcs intel_cursor_plane_funcs = {
- .update_plane = drm_atomic_helper_update_plane,
- .disable_plane = drm_atomic_helper_disable_plane,
- .destroy = intel_plane_destroy,
- .set_property = drm_atomic_helper_plane_set_property,
- .atomic_get_property = intel_plane_atomic_get_property,
- .atomic_set_property = intel_plane_atomic_set_property,
- .atomic_duplicate_state = intel_plane_duplicate_state,
- .atomic_destroy_state = intel_plane_destroy_state,
-};
-
static struct intel_plane *
intel_primary_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe)
{
@@ -13782,7 +13771,7 @@ intel_cursor_plane_create(struct drm_i915_private
*dev_priv,
cursor->cursor.size = ~0;
ret = drm_universal_plane_init(&dev_priv->drm, &cursor->base,
- 0, &intel_cursor_plane_funcs,
+ 0, &intel_plane_funcs,
intel_cursor_formats,
ARRAY_SIZE(intel_cursor_formats),
DRM_PLANE_TYPE_CURSOR,
--
2.9.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 4/6] drm/msm: update cursors asynchronously through atomic
From: Gustavo Padovan
Add support to async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
mdp5_update_cursor_plane_legacy() did but through atomic.
v5: call drm_atomic_helper_async_check() from the check hook
v4: add missing atomic async commit call to msm_atomic_commit(Archit Taneja)
v3: move size checks back to drivers (Ville Syrjälä)
v2: move fb setting to core and use new state (Eric Anholt)
Cc: Rob Clark
Cc: Archit Taneja
Signed-off-by: Gustavo Padovan
Tested-by: Archit Taneja (v4)
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 151 +-
drivers/gpu/drm/msm/msm_atomic.c | 9 ++
2 files changed, 72 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index fe3a4de..60680e8 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -31,15 +31,6 @@ static int mdp5_plane_mode_set(struct drm_plane *plane,
struct drm_crtc *crtc, struct drm_framebuffer *fb,
struct drm_rect *src, struct drm_rect *dest);
-static int mdp5_update_cursor_plane_legacy(struct drm_plane *plane,
- struct drm_crtc *crtc,
- struct drm_framebuffer *fb,
- int crtc_x, int crtc_y,
- unsigned int crtc_w, unsigned int crtc_h,
- uint32_t src_x, uint32_t src_y,
- uint32_t src_w, uint32_t src_h,
- struct drm_modeset_acquire_ctx *ctx);
-
static struct mdp5_kms *get_kms(struct drm_plane *plane)
{
struct msm_drm_private *priv = plane->dev->dev_private;
@@ -256,7 +247,7 @@ static const struct drm_plane_funcs mdp5_plane_funcs = {
};
static const struct drm_plane_funcs mdp5_cursor_plane_funcs = {
- .update_plane = mdp5_update_cursor_plane_legacy,
+ .update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
.destroy = mdp5_plane_destroy,
.set_property = drm_atomic_helper_plane_set_property,
@@ -489,11 +480,73 @@ static void mdp5_plane_atomic_update(struct drm_plane
*plane,
}
}
+static int mdp5_plane_atomic_async_check(struct drm_plane *plane,
+struct drm_plane_state *state)
+{
+ struct mdp5_plane_state *mdp5_state = to_mdp5_plane_state(state);
+ struct drm_crtc_state *crtc_state;
+
+ crtc_state = drm_atomic_get_existing_crtc_state(state->state,
+ state->crtc);
+ if (WARN_ON(!crtc_state))
+ return -EINVAL;
+
+ if (!crtc_state->active)
+ return -EINVAL;
+
+ mdp5_state = to_mdp5_plane_state(state);
+
+ /* don't use fast path if we don't have a hwpipe allocated yet */
+ if (!mdp5_state->hwpipe)
+ return -EINVAL;
+
+ /* only allow changing of position(crtc x/y or src x/y) in fast path */
+ if (plane->state->crtc != state->crtc ||
+ plane->state->src_w != state->src_w ||
+ plane->state->src_h != state->src_h ||
+ plane->state->crtc_w != state->crtc_w ||
+ plane->state->crtc_h != state->crtc_h ||
+ !plane->state->fb ||
+ plane->state->fb != state->fb)
+ return -EINVAL;
+
+ return 0;
+}
+
+static void mdp5_plane_atomic_async_update(struct drm_plane *plane,
+ struct drm_plane_state *new_state)
+{
+ plane->state->src_x = new_state->src_x;
+ plane->state->src_y = new_state->src_y;
+ plane->state->crtc_x = new_state->crtc_x;
+ plane->state->crtc_y = new_state->crtc_y;
+
+ if (plane_enabled(new_state)) {
+ struct mdp5_ctl *ctl;
+ struct mdp5_pipeline *pipeline =
+ mdp5_crtc_get_pipeline(plane->crtc);
+ int ret;
+
+ ret = mdp5_plane_mode_set(plane, new_state->crtc, new_state->fb,
+ &new_state->src, &new_state->dst);
+ WARN_ON(ret < 0);
+
+ ctl = mdp5_crtc_get_ctl(new_state->crtc);
+
+ mdp5_ctl_commit(ctl, pipeline, mdp5_plane_get_flush(plane));
+ }
+
+ *to_mdp5_plane_state(plane->state) =
+ *to_mdp5_plane_state(new_state);
+}
+
static const struct drm_plane_helper_funcs mdp5_plane_helper_funcs = {
.prepare_fb = mdp5_plane_prepare_fb,
.cleanup_fb = mdp5_plane_cleanup_fb,
.atomic_check = mdp5_plane_atomic_check,
.atomic_update = mdp5_plane_atomic_update,
+ .atomic_async_check = mdp5_plane_atomic_async_check,
+ .atomic_async_update = mdp5_plane_atomic_async_update,
};
static void set_scanout_locked(struct mdp5_kms *mdp5_kms,
@@ -998,84 +1051,6 @@
[Intel-gfx] [PATCH v4 6/6] drm/vc4: update cursors asynchronously through atomic
From: Gustavo Padovan
Add support for async updates of cursors by using the new atomic
interface for that. Basically what this commit does is do what
vc4_update_plane() did but through atomic.
v5: add missing call to vc4_plane_atomic_check() (Eric Anholt)
v4: add drm_atomic_helper_async() commit (Eric Anholt)
v3: move size checks back to drivers (Ville Syrjälä)
v2: move fb setting to core and use new state (Eric Anholt)
Cc: Eric Anholt
Signed-off-by: Gustavo Padovan
Reviewed-by: Eric Anholt
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_kms.c | 20 +++
drivers/gpu/drm/vc4/vc4_plane.c | 128
2 files changed, 71 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index 27edae4..efd2656 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -95,6 +95,26 @@ static int vc4_atomic_commit(struct drm_device *dev,
struct vc4_dev *vc4 = to_vc4_dev(dev);
int ret;
+ if (state->async_update) {
+ ret = down_interruptible(&vc4->async_modeset);
+ if (ret)
+ return ret;
+
+ ret = drm_atomic_helper_prepare_planes(dev, state);
+ if (ret) {
+ up(&vc4->async_modeset);
+ return ret;
+ }
+
+ drm_atomic_helper_async_commit(dev, state);
+
+ drm_atomic_helper_cleanup_planes(dev, state);
+
+ up(&vc4->async_modeset);
+
+ return 0;
+ }
+
ret = drm_atomic_helper_setup_commit(state, nonblock);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/vc4/vc4_plane.c b/drivers/gpu/drm/vc4/vc4_plane.c
index 8853e9a..52bf74c 100644
--- a/drivers/gpu/drm/vc4/vc4_plane.c
+++ b/drivers/gpu/drm/vc4/vc4_plane.c
@@ -759,87 +759,41 @@ void vc4_plane_async_set_fb(struct drm_plane *plane,
struct drm_framebuffer *fb)
vc4_state->dlist[vc4_state->ptr0_offset] = addr;
}
-static int vc4_prepare_fb(struct drm_plane *plane,
- struct drm_plane_state *state)
+static int vc4_plane_atomic_async_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
{
- struct vc4_bo *bo;
- struct dma_fence *fence;
+ if (plane != state->crtc->cursor)
+ return -EINVAL;
- if ((plane->state->fb == state->fb) || !state->fb)
- return 0;
+ if (!plane->state)
+ return -EINVAL;
- bo = to_vc4_bo(&drm_fb_cma_get_gem_obj(state->fb, 0)->base);
- fence = reservation_object_get_excl_rcu(bo->resv);
- drm_atomic_set_fence_for_plane(state, fence);
+ /* No configuring new scaling in the fast path. */
+ if (state->crtc_w != plane->state->crtc_w ||
+ state->crtc_h != plane->state->crtc_h ||
+ state->src_w != plane->state->src_w ||
+ state->src_h != plane->state->src_h) {
+ return -EINVAL;
+ }
return 0;
}
-static const struct drm_plane_helper_funcs vc4_plane_helper_funcs = {
- .atomic_check = vc4_plane_atomic_check,
- .atomic_update = vc4_plane_atomic_update,
- .prepare_fb = vc4_prepare_fb,
-};
-
-static void vc4_plane_destroy(struct drm_plane *plane)
-{
- drm_plane_helper_disable(plane);
- drm_plane_cleanup(plane);
-}
-
-/* Implements immediate (non-vblank-synced) updates of the cursor
- * position, or falls back to the atomic helper otherwise.
- */
-static int
-vc4_update_plane(struct drm_plane *plane,
-struct drm_crtc *crtc,
-struct drm_framebuffer *fb,
-int crtc_x, int crtc_y,
-unsigned int crtc_w, unsigned int crtc_h,
-uint32_t src_x, uint32_t src_y,
-uint32_t src_w, uint32_t src_h,
-struct drm_modeset_acquire_ctx *ctx)
+static void vc4_plane_atomic_async_update(struct drm_plane *plane,
+ struct drm_plane_state *new_state)
{
- struct drm_plane_state *plane_state;
- struct vc4_plane_state *vc4_state;
-
- if (plane != crtc->cursor)
- goto out;
-
- plane_state = plane->state;
- vc4_state = to_vc4_plane_state(plane_state);
-
- if (!plane_state)
- goto out;
-
- /* No configuring new scaling in the fast path. */
- if (crtc_w != plane_state->crtc_w ||
- crtc_h != plane_state->crtc_h ||
- src_w != plane_state->src_w ||
- src_h != plane_state->src_h) {
- goto out;
- }
-
- if (fb != plane_state->fb) {
- drm_atomic_set_fb_for_plane(plane->state, fb);
- vc4_plane_async_set_fb(plane, fb);
- }
+ struct vc4_plane_state *vc4_state = to_vc4_plane_state(plane->state);
- /* Set the cursor's position on the screen. Thi
Re: [Intel-gfx] [PATCH] drm/fb-helper: Restore first connection behaviour on deferred setup
On Fri, Jun 30, 2017 at 6:51 PM, Liviu Dudau wrote:
> Prior to commit b0aa06e9a7fd ("drm/fb-helper: Support deferred setup"),
> if no output is connected at framebuffer setup time, we get a default
> 1024x768 mode that is going to be used when we first connect a monitor.
> After the commit, on first connection after deferred setup, we probe
> the monitor and get the preferred resolution, but no mode get set
> because the drm_fb_helper_hotplug_event() function returns early
> when the setup has been deferred. That is different from what happens
> on a second re-connect of the monitor, when the native mode get set.
>
> Create a more consistent behaviour by checking in the
> drm_fb_helper_hotplug_event() function if the deferred setup is still
> active. If not, that means we now have a valid framebuffer that can be
> used for setting the correct mode.
>
> Fixes: b0aa06e9a7fd ("drm/fb-helper: Support deferred setup")
> Signed-off-by: Liviu Dudau
> Cc: Daniel Vetter
I thought the analysis over irc was that fbcon picked a different
driver as it's console, and that's why nothing shows up on the malidp
output in the deferred case? That's mildly annoying, but iirc fbcon
has always been rather erratic in multi-gpu setups. Although I thought
that it would by default bind all fbdev drivers as consoles (and then
you need to rebind the right console driver, if the right Kconfig is
enabled, through sysfs).
Either way if the register_framebuffer() call in initial_config isn't
good enough, then we need to add the set_par in initial_config
unconditionally, not just in the deferred probe case. Just disable
fbcon entirely for testing, in that case even without deferred probing
nothing will show up.
I'd say if this is still needed in the single gpu case then we need to
investigate more, but for multi-gpu it is what it is (aka fbcon is not
great).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/vblank: Introduce drm_crtc_vblank_get_accurate()
On Fri, Jun 30, 2017 at 5:26 PM, Daniel Vetter wrote: > On Fri, Jun 30, 2017 at 05:18:41PM +0300, ville.syrj...@linux.intel.com wrote: >> From: Ville Syrjälä >> >> Add drm_crtc_vblank_get_accurate() which is the same as >> drm_crtc_vblank_get() except that it will forcefully update the >> the current vblank counter/timestamp value even if the interrupt >> is already enabled. >> >> And we'll switch drm_wait_one_vblank() over to using it to make sure it >> will really wait at least one vblank even if it races with the irq >> handler. >> >> Cc: Daniel Vetter >> Signed-off-by: Ville Syrjälä > > Hm, I just thought of doing an > s/drm_vblank_count/drm_crtc_accurate_vblank_count/ in > drm_crtc_arm_vblank_event. > > What does this buy us above&beyond the other patch? And why isn't > vblank_get accurate always? This also seems to have the risk of not fixing the arm_vblank_event race if someone puts the vblank_get_accurate outside of the critical section. Then we're back to the same old race. And since that means you need to have a vblank_get_accurate right before the arm_vblank_event in all cases, we might as well just put it into the helper. You wrote in the other thread putting it into arm_vblank_event might be wasteful, but I don't see any scenario where that could be the case ... Or do I miss something? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore
On Fri, Jun 30, 2017 at 5:44 PM, Ville Syrjälä wrote: >> And if the GEM folks insist the old behavior can't be restored, then we >> just need a tailor-made get-out-of-jail card for gen4 gpu reset somewhere >> in i915_sw_fence. Force-completing all render requests atomic updates >> depend upon is imo the simplest solution to this, and we've had a driver >> that worked like that for years. > > And it used to break all the time. I think we've had to fix it at least > three times by now. So I tend to think it's better to fix it in a way > that won't break so easily. Why exactly is making the atomic code massive more tricky the easy fix? That's the part I don't get. Yes it got broken a bunch because no one runs CI and everyone forgets that gen3/4 reset the display in gpu reset, but in the end we do have a depency loop, and either the modeset side or the render side needs to bail out and cancel it's async stuff (whether that's a request or a nonblocking flip/atomic commit doesn't matter). In my opinion, cancelling the request (even if we're clever and only cancel the requests for the modeset waiters, which isn't to hard to pull off) seems about the simplest option. Especially since we need that code anyway, even TDR can't safe everything and resubmit under all circumstances (at least the buggy batch can't be resubmitted). Cancelling any kind of atomic commit otoh looks like a lot more complexity. Why do you think this is the easier, or at least less fragile option? This patch series is full of FIXMEs, and even the more complete set seems to have a pile of holes. Plus we need to stop using obj->state, and I don't see any easy way to test for that (since the gen3/4 gpu reset case is the only corner cases that currently needs that). So not seeing how this is easier or more robust at all. What do I miss? Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm: add asynchrounous plane update (rev5)
== Series Details == Series: drm: add asynchrounous plane update (rev5) URL : https://patchwork.freedesktop.org/series/25814/ State : failure == Summary == Series 25814v5 drm: add asynchrounous plane update https://patchwork.freedesktop.org/api/1.0/series/25814/revisions/5/mbox/ Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: pass -> INCOMPLETE (fi-blb-e6850) pass -> INCOMPLETE (fi-pnv-d510) Test prime_busy: Subgroup basic-wait-after-default: pass -> DMESG-WARN (fi-skl-6700hq) fdo#101515 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#101515 https://bugs.freedesktop.org/show_bug.cgi?id=101515 fi-bdw-5557u total:279 pass:264 dwarn:0 dfail:0 fail:3 skip:11 time:435s fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 time:429s fi-blb-e6850 total:200 pass:163 dwarn:1 dfail:0 fail:0 skip:35 fi-bsw-n3050 total:279 pass:239 dwarn:0 dfail:0 fail:3 skip:36 time:516s fi-bxt-j4205 total:279 pass:256 dwarn:0 dfail:0 fail:3 skip:19 time:502s fi-byt-j1900 total:279 pass:251 dwarn:0 dfail:0 fail:3 skip:24 time:482s fi-byt-n2820 total:279 pass:246 dwarn:1 dfail:0 fail:3 skip:28 time:478s fi-glk-2atotal:279 pass:256 dwarn:0 dfail:0 fail:3 skip:19 time:585s fi-hsw-4770 total:279 pass:259 dwarn:0 dfail:0 fail:3 skip:16 time:429s fi-hsw-4770r total:279 pass:259 dwarn:0 dfail:0 fail:3 skip:16 time:412s fi-ilk-650 total:279 pass:225 dwarn:0 dfail:0 fail:3 skip:50 time:420s fi-ivb-3520m total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:493s fi-ivb-3770 total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:471s fi-kbl-7500u total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:461s fi-kbl-7560u total:279 pass:265 dwarn:0 dfail:0 fail:3 skip:10 time:558s fi-kbl-r total:279 pass:256 dwarn:1 dfail:0 fail:3 skip:18 time:563s fi-pnv-d510 total:200 pass:162 dwarn:1 dfail:0 fail:0 skip:36 fi-skl-6260u total:279 pass:265 dwarn:0 dfail:0 fail:3 skip:10 time:449s fi-skl-6700hqtotal:279 pass:218 dwarn:2 dfail:0 fail:33 skip:24 time:331s fi-skl-6700k total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:459s fi-skl-6770hqtotal:279 pass:265 dwarn:0 dfail:0 fail:3 skip:10 time:469s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:435s fi-snb-2520m total:279 pass:247 dwarn:0 dfail:0 fail:3 skip:28 time:537s fi-snb-2600 total:279 pass:246 dwarn:0 dfail:0 fail:3 skip:29 time:408s 6412bcb8e279d62b9d8ae2840712d6c85806369b drm-tip: 2017y-06m-30d-14h-56m-41s UTC integration manifest 3ce1e3d drm/vc4: update cursors asynchronously through atomic e4a269c drm/msm: remove mdp5_cursor_plane_funcs 80359c8 drm/msm: update cursors asynchronously through atomic 179589c drm/i915: remove intel_cursor_plane_funcs 4abf84a drm/i915: update cursors asynchronously through atomic b92fb29 drm/atomic: initial support for asynchronous plane update == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5083/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Solve the GPU reset vs. modeset deadlocks with an rw_semaphore
On Fri, Jun 30, 2017 at 08:23:58PM +0200, Daniel Vetter wrote: > On Fri, Jun 30, 2017 at 5:44 PM, Ville Syrjälä > wrote: > >> And if the GEM folks insist the old behavior can't be restored, then we > >> just need a tailor-made get-out-of-jail card for gen4 gpu reset somewhere > >> in i915_sw_fence. Force-completing all render requests atomic updates > >> depend upon is imo the simplest solution to this, and we've had a driver > >> that worked like that for years. > > > > And it used to break all the time. I think we've had to fix it at least > > three times by now. So I tend to think it's better to fix it in a way > > that won't break so easily. > > Why exactly is making the atomic code massive more tricky the easy > fix? I don't see what this massive trickyness is. Compared to the rest of atomic what I have is absolutely trivial. Just the duplicate_committed_state() and the '.committed_state = foo' assignments in hw_done(). That's it really. > That's the part I don't get. Yes it got broken a bunch because no > one runs CI and everyone forgets that gen3/4 reset the display in gpu > reset, but in the end we do have a depency loop, and either the > modeset side or the render side needs to bail out and cancel it's > async stuff (whether that's a request or a nonblocking flip/atomic > commit doesn't matter). In my opinion, cancelling the request (even if > we're clever and only cancel the requests for the modeset waiters, > which isn't to hard to pull off) seems about the simplest option. > Especially since we need that code anyway, even TDR can't safe > everything and resubmit under all circumstances (at least the buggy > batch can't be resubmitted). > > Cancelling any kind of atomic commit otoh looks like a lot more > complexity. I'm not cancelling anything. > Why do you think this is the easier, or at least less > fragile option? This patch series is full of FIXMEs, and even the more > complete set seems to have a pile of holes. Plus we need to stop using > obj->state, and I don't see any easy way to test for that (since the > gen3/4 gpu reset case is the only corner cases that currently needs > that). We need to fix that stuff anyway if we ever want to queue up multiple commits for the same crtc. The stuff I have that is specific to this reset stuff is actually very simple. The rest is just fixing up the huge mess we've already made. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/4] drm/i915/edp: Allow alternate fixed mode for eDP if available.
Some fixed resolution panels actually support more than one mode,
with the only thing different being the refresh rate. Having this
alternate mode available to us is desirable, because it allows us to
test PSR on panels whose setup time at the preferred mode is too long.
With this patch we allow the use of the alternate mode if it's
available and it was specifically requested.
v2: Rebase
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Cc: Jani Nikula
Signed-off-by: Jim Bride
---
drivers/gpu/drm/i915/intel_dp.c| 34 +-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
drivers/gpu/drm/i915/intel_dsi.c | 2 +-
drivers/gpu/drm/i915/intel_dvo.c | 2 +-
drivers/gpu/drm/i915/intel_lvds.c | 3 ++-
drivers/gpu/drm/i915/intel_panel.c | 2 ++
6 files changed, 37 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 67bc8a7a..3560e97 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1606,6 +1606,19 @@ static int intel_dp_compute_bpp(struct intel_dp
*intel_dp,
return bpp;
}
+static bool intel_edp_compare_alt_mode(struct drm_display_mode *m1,
+ struct drm_display_mode *m2)
+{
+ return (m1->hdisplay == m2->hdisplay &&
+ m1->hsync_start == m2->hsync_start &&
+ m1->hsync_end == m2->hsync_end &&
+ m1->htotal == m2->htotal &&
+ m1->vdisplay == m2->vdisplay &&
+ m1->vsync_start == m2->vsync_start &&
+ m1->vsync_end == m2->vsync_end &&
+ m1->vtotal == m2->vtotal);
+}
+
bool
intel_dp_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
@@ -1652,8 +1665,16 @@ intel_dp_compute_config(struct intel_encoder *encoder,
pipe_config->has_audio = intel_conn_state->force_audio ==
HDMI_AUDIO_ON;
if (is_edp(intel_dp) && intel_connector->panel.fixed_mode) {
- intel_fixed_panel_mode(intel_connector->panel.fixed_mode,
- adjusted_mode);
+ struct drm_display_mode *panel_mode =
+ intel_connector->panel.alt_fixed_mode;
+ struct drm_display_mode *req_mode = &pipe_config->base.mode;
+
+ if (!intel_edp_compare_alt_mode(req_mode, panel_mode))
+ panel_mode = intel_connector->panel.fixed_mode;
+
+ drm_mode_debug_printmodeline(panel_mode);
+
+ intel_fixed_panel_mode(panel_mode, adjusted_mode);
if (INTEL_GEN(dev_priv) >= 9) {
int ret;
@@ -5772,6 +5793,7 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
struct drm_device *dev = intel_encoder->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_display_mode *fixed_mode = NULL;
+ struct drm_display_mode *alt_fixed_mode = NULL;
struct drm_display_mode *downclock_mode = NULL;
bool has_dpcd;
struct drm_display_mode *scan;
@@ -5827,13 +5849,14 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
}
intel_connector->edid = edid;
- /* prefer fixed mode from EDID if available */
+ /* prefer fixed mode from EDID if available, save an alt mode also */
list_for_each_entry(scan, &connector->probed_modes, head) {
if ((scan->type & DRM_MODE_TYPE_PREFERRED)) {
fixed_mode = drm_mode_duplicate(dev, scan);
downclock_mode = intel_dp_drrs_init(
intel_connector, fixed_mode);
- break;
+ } else {
+ alt_fixed_mode = drm_mode_duplicate(dev, scan);
}
}
@@ -5870,7 +5893,8 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
pipe_name(pipe));
}
- intel_panel_init(&intel_connector->panel, fixed_mode, downclock_mode);
+ intel_panel_init(&intel_connector->panel, fixed_mode, alt_fixed_mode,
+downclock_mode);
intel_connector->panel.backlight.power = intel_edp_backlight_power;
intel_panel_setup_backlight(connector, pipe);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index d17a324..0c14b05 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -265,6 +265,7 @@ struct intel_encoder {
struct intel_panel {
struct drm_display_mode *fixed_mode;
+ struct drm_display_mode *alt_fixed_mode;
struct drm_display_mode *downclock_mode;
/* backlight */
@@ -1696,6 +1697,7 @@ void intel_overlay_reset(struct drm_i915_private
*dev_priv);
/* intel_panel.c */
int intel_panel_init(struct intel_panel *panel,
struct drm_display_mode *f
[Intel-gfx] [PATCH v2 0/4] Kernel PSR Fix-ups
These patches, along with an upcoming series for IGT, enable our PSR IGT tests to run reliably once again on HSW, BDW, and SKL. The first change enables us to run the PSR tests on some RVP platforms whose panels have too slow of a setup time when running in their preferred mode. The second fixes a minor problem with the way that we were initializing SRD_CTL that caused us to clobber a bit that we are not supposed to change in that register on SKL and KBL. The third change re-introduces some changes to our link training code to be less aggressive about changing link state for eDP, because PSR depends on the link state being the same at PSR exit as it was at PSR entry. The fourth change greatly increases the reliability of reading the sink CRC generated by the eDP panel. v2 Highlights: * Rebased to current drm-tip * Greatly reduced looping around trying to read sink CRC (Jani) * Reduce amount of changes in the sink CRC patch (Jani) * Field-wise init of EDP_PSR_MAX_SLEEP_TIME (Rodrigo) * Minor commit message / cover letter tweaks Jim Bride (4): drm/i915/edp: Allow alternate fixed mode for eDP if available. drm/i915/psr: Clean-up intel_enable_source_psr1() drm/i915/edp: Be less aggressive about changing link config on eDP drm/i915/psr: Account for sink CRC raciness on some panels drivers/gpu/drm/i915/i915_reg.h | 4 ++ drivers/gpu/drm/i915/intel_dp.c | 78 +++ drivers/gpu/drm/i915/intel_dp_link_training.c | 11 +++- drivers/gpu/drm/i915/intel_drv.h | 4 ++ drivers/gpu/drm/i915/intel_dsi.c | 2 +- drivers/gpu/drm/i915/intel_dvo.c | 2 +- drivers/gpu/drm/i915/intel_lvds.c | 3 +- drivers/gpu/drm/i915/intel_panel.c| 2 + drivers/gpu/drm/i915/intel_psr.c | 21 +++- 9 files changed, 111 insertions(+), 16 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/4] drm/i915/edp: Be less aggressive about changing link config on eDP
This set of changes has some history to them. There were several attempts
to add what was called "fast link training" to i915, which actually wasn't
fast link training as per the DP spec. These changes were
5fa836a9d859 ("drm/i915: DP link training optimization")
4e96c97742f4 ("drm/i915: eDP link training optimization")
which were eventually hand-reverted by
34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
in kernel 4.7-rc4. The eDP pieces of the above revert, however, had some
very bad side-effects on PSR functionality on Skylake. The issue at
hand is that when PSR exits i915 briefly emits TP1 followed by TP2/3
(depending on the original link configuration) in order to quickly get
the source and sink back in synchronization across the link before handing
control back to the i915. There's an assumption that none of the link
configuration information has changed (and thus it's still valid) since the
last full link training operation. The revert above was identified via a
bisect as the cause of some of Skylake's PSR woes. This patch, largely
based on
commit 4e96c97742f4201edf1b0f8e1b1b6b2ac6ff33e7
Author: Mika Kahola
Date: Wed Apr 29 09:17:39 2015 +0300
drm/i915: eDP link training optimization
puts the eDP portions of this patch back in place. None of the flickering
issues that spurred the revert have been seen, and I suspect the real
culprits here were addressed by some of the recent link training changes
that Manasi has implemented, and PSR on Skylake is definitely more happy
with these changes in-place.
v2: Rebase
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Cc: Manasi D Navare
Cc: Mika Kahola
Cc: Jani Nikula
Fixes: 34511dce4 ("drm/i915: Revert DisplayPort fast link training feature")
Signed-off-by: Jim Bride
---
drivers/gpu/drm/i915/intel_dp.c | 4 +++-
drivers/gpu/drm/i915/intel_dp_link_training.c | 11 ++-
drivers/gpu/drm/i915/intel_drv.h | 2 ++
3 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 3560e97..b46fa03 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -106,7 +106,7 @@ static const int default_rates[] = { 162000, 27, 54
};
* If a CPU or PCH DP output is attached to an eDP panel, this function
* will return true, and false otherwise.
*/
-static bool is_edp(struct intel_dp *intel_dp)
+bool is_edp(struct intel_dp *intel_dp)
{
struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
@@ -4732,6 +4732,7 @@ intel_dp_long_pulse(struct intel_connector
*intel_connector)
intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
intel_dp->reset_link_params = false;
+ intel_dp->train_set_valid = false;
}
intel_dp_print_rates(intel_dp);
@@ -5995,6 +5996,7 @@ intel_dp_init_connector(struct intel_digital_port
*intel_dig_port,
intel_dp_set_source_rates(intel_dp);
intel_dp->reset_link_params = true;
+ intel_dp->train_set_valid = false;
intel_dp->pps_pipe = INVALID_PIPE;
intel_dp->active_pipe = INVALID_PIPE;
diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
b/drivers/gpu/drm/i915/intel_dp_link_training.c
index b79c1c0..60233e2 100644
--- a/drivers/gpu/drm/i915/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
@@ -94,7 +94,8 @@ static bool
intel_dp_reset_link_train(struct intel_dp *intel_dp,
uint8_t dp_train_pat)
{
- memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
+ if (!intel_dp->train_set_valid)
+ memset(intel_dp->train_set, 0, sizeof(intel_dp->train_set));
intel_dp_set_signal_levels(intel_dp);
return intel_dp_set_link_train(intel_dp, dp_train_pat);
}
@@ -162,6 +163,7 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp)
DP_TRAINING_PATTERN_1 |
DP_LINK_SCRAMBLING_DISABLE)) {
DRM_ERROR("failed to enable link training\n");
+ intel_dp->train_set_valid = false;
return false;
}
@@ -174,21 +176,25 @@ intel_dp_link_training_clock_recovery(struct intel_dp
*intel_dp)
if (!intel_dp_get_link_status(intel_dp, link_status)) {
DRM_ERROR("failed to get link status\n");
+ intel_dp->train_set_valid = false;
return false;
}
if (drm_dp_clock_recovery_ok(link_status,
intel_dp->lane_count)) {
DRM_DEBUG_KMS("clock recovery OK\n");
+ intel_dp->train_set_valid = is_edp(intel_dp);
return true;
}
if (voltage_tries == 5) {
DRM_DEBUG_KMS("Same voltage tried 5 times\n");
+
[Intel-gfx] [PATCH v2 2/4] drm/i915/psr: Clean-up intel_enable_source_psr1()
On SKL+ there is a bit in SRD_CTL that software is not supposed to
modify, but we currently clobber that bit when we enable PSR. In
order to preserve the value of that bit, go ahead and read SRD_CTL and
do a field-wise setting of the various bits that we need to initialize
before writing the register back out. Additionally, go ahead and
explicitly disable single-frame update since we aren't currently
supporting it.
v2: * Do a field-wise init on EDP_PSR_MAX_SLEEP_TIME even though we
always set it to the max value. (Rodrigo)
* Rebase
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Cc: Wayne Boyer
Cc: Jani Nikula
Signed-off-by: Jim Bride
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_psr.c | 21 +++--
2 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 64cc674..df58818 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3789,18 +3789,22 @@ enum {
#define EDP_PSR_MIN_LINK_ENTRY_TIME_4_LINES (1<<25)
#define EDP_PSR_MIN_LINK_ENTRY_TIME_2_LINES (2<<25)
#define EDP_PSR_MIN_LINK_ENTRY_TIME_0_LINES (3<<25)
+#define EDP_PSR_MAX_SLEEP_TIME_MASK (0x1f<<20)
#define EDP_PSR_MAX_SLEEP_TIME_SHIFT 20
#define EDP_PSR_SKIP_AUX_EXIT(1<<12)
#define EDP_PSR_TP1_TP2_SEL (0<<11)
#define EDP_PSR_TP1_TP3_SEL (1<<11)
+#define EDP_PSR_TP2_TP3_TIME_MASK (3<<8)
#define EDP_PSR_TP2_TP3_TIME_500us (0<<8)
#define EDP_PSR_TP2_TP3_TIME_100us (1<<8)
#define EDP_PSR_TP2_TP3_TIME_2500us (2<<8)
#define EDP_PSR_TP2_TP3_TIME_0us (3<<8)
+#define EDP_PSR_TP1_TIME_MASK (0x3<<4)
#define EDP_PSR_TP1_TIME_500us (0<<4)
#define EDP_PSR_TP1_TIME_100us (1<<4)
#define EDP_PSR_TP1_TIME_2500us (2<<4)
#define EDP_PSR_TP1_TIME_0us (3<<4)
+#define EDP_PSR_IDLE_FRAME_MASK (0xf<<0)
#define EDP_PSR_IDLE_FRAME_SHIFT 0
#define EDP_PSR_AUX_CTL
_MMIO(dev_priv->psr_mmio_base + 0x10)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 559f1ab..132987b 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -280,17 +280,32 @@ static void intel_enable_source_psr1(struct intel_dp
*intel_dp)
* with the 5 or 6 idle patterns.
*/
uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
- uint32_t val = EDP_PSR_ENABLE;
+ uint32_t val = I915_READ(EDP_PSR_CTL);
+ val |= EDP_PSR_ENABLE;
+
+ val &= ~EDP_PSR_MAX_SLEEP_TIME_MASK;
val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
+
+ val &= ~EDP_PSR_IDLE_FRAME_MASK;
val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
+ val &= ~EDP_PSR_MIN_LINK_ENTRY_TIME_MASK;
if (IS_HASWELL(dev_priv))
val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
- if (dev_priv->psr.link_standby)
+ if (dev_priv->psr.link_standby) {
val |= EDP_PSR_LINK_STANDBY;
+ /* SFU should only be enabled with link standby, but for
+* now we do not support it. */
+ val &= ~BDW_PSR_SINGLE_FRAME;
+ } else {
+ val &= ~EDP_PSR_LINK_STANDBY;
+ val &= ~BDW_PSR_SINGLE_FRAME;
+ }
+
+ val &= ~EDP_PSR_TP1_TIME_MASK;
if (dev_priv->vbt.psr.tp1_wakeup_time > 5)
val |= EDP_PSR_TP1_TIME_2500us;
else if (dev_priv->vbt.psr.tp1_wakeup_time > 1)
@@ -300,6 +315,7 @@ static void intel_enable_source_psr1(struct intel_dp
*intel_dp)
else
val |= EDP_PSR_TP1_TIME_0us;
+ val &= ~EDP_PSR_TP2_TP3_TIME_MASK;
if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR_TP2_TP3_TIME_2500us;
else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 1)
@@ -309,6 +325,7 @@ static void intel_enable_source_psr1(struct intel_dp
*intel_dp)
else
val |= EDP_PSR_TP2_TP3_TIME_0us;
+ val &= ~EDP_PSR_TP1_TP3_SEL;
if (intel_dp_source_supports_hbr2(intel_dp) &&
drm_dp_tps3_supported(intel_dp->dpcd))
val |= EDP_PSR_TP1_TP3_SEL;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/4] drm/i915/psr: Account for sink CRC raciness on some panels
According to the eDP spec, when the count field in TEST_SINK_MISC
increments then the six bytes of sink CRC information in the DPCD
should be valid. Unfortunately, this doesn't seem to be the case
on some panels, and as a result we get some incorrect and inconsistent
values from the sink CRC DPCD locations at times. This problem exhibits
itself more on faster processors (relative failure rates HSW < SKL < KBL.)
In order to try and account for this, we try a lot harder to read the sink
CRC until we get consistent values twice in a row before returning what we
read and delay for a time before trying to read. We still see some
occasional failures, but reading the sink CRC is much more reliable,
particularly on SKL and KBL, with these changes than without.
v2: * Reduce number of retries when reading the sink CRC (Jani)
* Refactor to minimize changes to the code (Jani)
* Rebase
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Cc: Jani Nikula
Signed-off-by: Jim Bride
---
drivers/gpu/drm/i915/intel_dp.c | 40
1 file changed, 36 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index b46fa03..1fe0975 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3927,6 +3927,14 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 *crc)
u8 buf;
int count, ret;
int attempts = 6;
+ u8 old_crc[6];
+
+ if (crc != NULL) {
+ memset(crc, 0, 6);
+ memset(old_crc, 0xff, 6);
+ } else {
+ return -ENOMEM;
+ }
ret = intel_dp_sink_crc_start(intel_dp);
if (ret)
@@ -3950,11 +3958,35 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
*crc)
goto stop;
}
- if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0) {
- ret = -EIO;
- goto stop;
- }
+ attempts = 6;
+
+ /*
+* Sometimes it takes a while for the "real" CRC values to land in
+* the DPCD, so try several times until we get two reads in a row
+* that are the same. If we're an eDP panel, delay between reads
+* for a while since the values take a bit longer to propagate.
+*/
+ do {
+ intel_wait_for_vblank(dev_priv, intel_crtc->pipe);
+ if (is_edp(intel_dp))
+ usleep_range(2, 25000);
+
+ if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR,
+crc, 6) < 0) {
+ ret = -EIO;
+ goto stop;
+ }
+
+ if (memcmp(old_crc, crc, 6) == 0) {
+ ret = 0;
+ goto stop;
+ } else {
+ memcpy(old_crc, crc, 6);
+ }
+ } while (--attempts);
+ DRM_DEBUG_KMS("Failed to get CRC after 6 attempts.\n");
+ ret = -ETIMEDOUT;
stop:
intel_dp_sink_crc_stop(intel_dp);
return ret;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH IGT v2 1/6] tests/kms_psr_sink_crc: Change assert_or_manual() to a macro
Make assert_or_manual() a macro so that we get accurate line number
information when this assertion fails.
v2: Rebase
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Jim Bride
---
tests/kms_psr_sink_crc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index bd3fa5e..1a03719 100644
--- a/tests/kms_psr_sink_crc.c
+++ b/tests/kms_psr_sink_crc.c
@@ -278,11 +278,11 @@ static bool is_green(char *crc)
(bh & mask) == 0);
}
-static void assert_or_manual(bool condition, const char *expected)
-{
- igt_debug_manual_check("no-crc", expected);
- igt_assert(igt_interactive_debug || condition);
-}
+#define assert_or_manual(condition, expected) \
+do { \
+ igt_debug_manual_check("no-crc", expected); \
+ igt_assert(igt_interactive_debug || condition); \
+} while (0)
static void run_test(data_t *data)
{
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH IGT v2 0/6] IGT PSR Fix-ups
These patches, along with the kernel series at https://patchwork.freedesktop.org/series/24049/ allow our PSR IGT tests to run more predictably on HSW, BDW, and SKL. These patches depend on the kernel series in order to run properly. On the systems I have available the following sets of tests run and pass. I still see some very sporadic (every few hundred tests executions or so) failures to read the sink CRC on SKL. HSW: * kms_psr_sink_crc (all) * kms_frontbuffer_tracking (subtests psr-1p*, my system doesn't support FBC) * kms_fbcon_fbt (subtests psr*) BDW and SKL: * kms_psr_sink_crc (all) * kms_frontbuffer_tracking (subtests psr-1p* and fbcpsr-1p*) * kms_fbcon_fbt (all) Jim Bride (6): tests/kms_psr_sink_crc: Change assert_or_manual() to a macro lib: Add PSR utility functions to igt library. tests/kms_psr_sink_crc: Refactor to use new PSR library primitives tests/kms_frontbuffer_tracking: Refactor to use IGT PSR library functions tests/kms_frontbuffer_tracking: Fix multidraw subtest tests/kms_fbcon_fbt: Refactor to use IGT PSR library functions lib/Makefile.sources | 2 + lib/igt.h| 1 + lib/igt_psr.c| 235 +++ lib/igt_psr.h| 43 +++ tests/kms_fbcon_fbt.c| 54 +++-- tests/kms_frontbuffer_tracking.c | 122 tests/kms_psr_sink_crc.c | 144 7 files changed, 391 insertions(+), 210 deletions(-) create mode 100644 lib/igt_psr.c create mode 100644 lib/igt_psr.h -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH IGT v2 4/6] tests/kms_frontbuffer_tracking: Refactor to use IGT PSR library functions
v2: * Minor functional tweaks and bug fixes
* Rebase
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Jim Bride
---
tests/kms_frontbuffer_tracking.c | 119 +++
1 file changed, 19 insertions(+), 100 deletions(-)
diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index c24e4a8..3a8b754 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -183,7 +183,7 @@ struct {
};
-#define SINK_CRC_SIZE 12
+#define SINK_CRC_SIZE 6
typedef struct {
char data[SINK_CRC_SIZE];
} sink_crc_t;
@@ -327,28 +327,6 @@ drmModeModeInfo std_1024_mode = {
.name = "Custom 1024x768",
};
-static drmModeModeInfoPtr get_connector_smallest_mode(drmModeConnectorPtr c)
-{
- int i;
- drmModeModeInfoPtr smallest = NULL;
-
- for (i = 0; i < c->count_modes; i++) {
- drmModeModeInfoPtr mode = &c->modes[i];
-
- if (!smallest)
- smallest = mode;
-
- if (mode->hdisplay * mode->vdisplay <
- smallest->hdisplay * smallest->vdisplay)
- smallest = mode;
- }
-
- if (c->connector_type == DRM_MODE_CONNECTOR_eDP)
- smallest = &std_1024_mode;
-
- return smallest;
-}
-
static drmModeConnectorPtr get_connector(uint32_t id)
{
int i;
@@ -421,30 +399,6 @@ static void init_mode_params(struct modeset_params
*params, uint32_t crtc_id,
params->sprite.h = 64;
}
-static bool connector_get_mode(drmModeConnectorPtr c, drmModeModeInfoPtr *mode)
-{
- *mode = NULL;
-
- if (c->connection != DRM_MODE_CONNECTED || !c->count_modes)
- return false;
-
- if (c->connector_type == DRM_MODE_CONNECTOR_eDP && opt.no_edp)
- return false;
-
- if (opt.small_modes)
- *mode = get_connector_smallest_mode(c);
- else
- *mode = &c->modes[0];
-
-/* On HSW the CRC WA is so awful that it makes you think everything is
- * bugged. */
- if (IS_HASWELL(intel_get_drm_devid(drm.fd)) &&
- c->connector_type == DRM_MODE_CONNECTOR_eDP)
- *mode = &std_1024_mode;
-
- return true;
-}
-
static bool connector_supports_pipe_a(drmModeConnectorPtr connector)
{
int i;
@@ -473,7 +427,7 @@ static bool find_connector(bool edp_only, bool pipe_a,
uint32_t forbidden_id,
continue;
if (c->connector_id == forbidden_id)
continue;
- if (!connector_get_mode(c, &mode))
+ if (!igt_psr_find_good_mode(c, &mode))
continue;
*ret_connector = c;
@@ -804,23 +758,6 @@ static void fbc_print_status(void)
igt_info("FBC status:\n%s\n", buf);
}
-static bool psr_is_enabled(void)
-{
- char buf[256];
-
- debugfs_read("i915_edp_psr_status", buf);
- return strstr(buf, "\nActive: yes\n") &&
- strstr(buf, "\nHW Enabled & Active bit: yes\n");
-}
-
-static void psr_print_status(void)
-{
- char buf[256];
-
- debugfs_read("i915_edp_psr_status", buf);
- igt_info("PSR status:\n%s\n", buf);
-}
-
static struct timespec fbc_get_last_action(void)
{
struct timespec ret = { 0, 0 };
@@ -926,44 +863,31 @@ static bool fbc_wait_until_enabled(void)
return igt_wait(fbc_is_enabled(), 2000, 1);
}
-static bool psr_wait_until_enabled(void)
-{
- return igt_wait(psr_is_enabled(), 5000, 1);
-}
-
#define fbc_enable() igt_set_module_param_int("enable_fbc", 1)
#define fbc_disable() igt_set_module_param_int("enable_fbc", 0)
-#define psr_enable() igt_set_module_param_int("enable_psr", 1)
-#define psr_disable() igt_set_module_param_int("enable_psr", 0)
static void get_sink_crc(sink_crc_t *crc, bool mandatory)
{
- int rc, errno_;
+ int rc;
if (!sink_crc.supported) {
memcpy(crc, "unsupported!", SINK_CRC_SIZE);
return;
}
- lseek(sink_crc.fd, 0, SEEK_SET);
-
- rc = read(sink_crc.fd, crc->data, SINK_CRC_SIZE);
- errno_ = errno;
-
- if (rc == -1 && errno_ == ENOTTY) {
+ rc = igt_psr_get_sink_crc(sink_crc.fd, crc->data);
+ if (rc == ENOTTY) {
igt_info("Sink CRC not supported: panel doesn't support it\n");
sink_crc.supported = false;
- } else if (rc == -1 && errno_ == ETIMEDOUT) {
- if (sink_crc.reliable) {
- igt_info("Sink CRC is unreliable on this machine.\n");
+ } else if (rc == ETIMEDOUT) {
+ if (sink_crc.reliable)
sink_crc.reliable = false;
- }
+
if (mandatory)
igt_skip("Sink CRC is unreliable on this machine.\n");
} else {
- igt_assert_f(rc != -1, "Unexpected error: %d\n", errno_);
- igt_ass
[Intel-gfx] [PATCH IGT v2 6/6] tests/kms_fbcon_fbt: Refactor to use IGT PSR library functions
v2: * Minor functional tweaks and bug fixes
* Rebase
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Jim Bride
---
tests/kms_fbcon_fbt.c | 54 +--
1 file changed, 18 insertions(+), 36 deletions(-)
diff --git a/tests/kms_fbcon_fbt.c b/tests/kms_fbcon_fbt.c
index d009091..593adb9 100644
--- a/tests/kms_fbcon_fbt.c
+++ b/tests/kms_fbcon_fbt.c
@@ -103,8 +103,9 @@ static bool fbc_is_enabled(int fd)
return strstr(buf, "FBC enabled\n");
}
-static bool fbc_wait_until_enabled(int fd)
+static bool fbc_wait_until_enabled(int fd, bool enabled)
{
+ enabled = enabled;
return igt_wait(fbc_is_enabled(fd), 5000, 1);
}
@@ -124,6 +125,13 @@ static void set_mode_for_one_screen(struct drm_info *drm,
struct igt_fb *fb,
if (c->connection == DRM_MODE_CONNECTED && c->count_modes &&
connector_possible(c)) {
+ if (c->connector_type == DRM_MODE_CONNECTOR_eDP) {
+ bool bret;
+
+ bret = igt_psr_find_good_mode(c, &mode);
+ if (bret)
+ break;
+ }
mode = &c->modes[0];
break;
}
@@ -147,35 +155,9 @@ static void set_mode_for_one_screen(struct drm_info *drm,
struct igt_fb *fb,
igt_assert_eq(rc, 0);
}
-static bool psr_supported_on_chipset(int fd)
-{
- char buf[256];
-
- igt_debugfs_read(fd, "i915_edp_psr_status", buf);
- return strstr(buf, "Sink_Support: yes\n");
-}
-
-static bool connector_can_psr(drmModeConnectorPtr connector)
-{
- return (connector->connector_type == DRM_MODE_CONNECTOR_eDP);
-}
-
-static bool psr_is_enabled(int fd)
-{
- char buf[256];
-
- igt_debugfs_read(fd, "i915_edp_psr_status", buf);
- return strstr(buf, "\nActive: yes\n");
-}
-
-static bool psr_wait_until_enabled(int fd)
-{
- return igt_wait(psr_is_enabled(fd), 5000, 1);
-}
-
struct feature {
bool (*supported_on_chipset)(int fd);
- bool (*wait_until_enabled)(int fd);
+ bool (*wait_until_enabled)(int fd, bool status);
bool (*connector_possible_fn)(drmModeConnectorPtr connector);
const char *param_name;
} fbc = {
@@ -184,9 +166,9 @@ struct feature {
.connector_possible_fn = connector_can_fbc,
.param_name = "enable_fbc",
}, psr = {
- .supported_on_chipset = psr_supported_on_chipset,
- .wait_until_enabled = psr_wait_until_enabled,
- .connector_possible_fn = connector_can_psr,
+ .supported_on_chipset = igt_psr_sink_support,
+ .wait_until_enabled = igt_psr_await_status,
+ .connector_possible_fn = igt_psr_valid_connector,
.param_name = "enable_psr",
};
@@ -210,17 +192,17 @@ static void subtest(struct feature *feature, bool suspend)
kmstest_unset_all_crtcs(drm.fd, drm.res);
wait_user("Modes unset.");
- igt_assert(!feature->wait_until_enabled(drm.fd));
+ igt_assert(!feature->wait_until_enabled(drm.fd, true));
set_mode_for_one_screen(&drm, &fb, feature->connector_possible_fn);
wait_user("Screen set.");
- igt_assert(feature->wait_until_enabled(drm.fd));
+ igt_assert(feature->wait_until_enabled(drm.fd, true));
if (suspend) {
igt_system_suspend_autoresume(SUSPEND_STATE_MEM,
SUSPEND_TEST_NONE);
sleep(5);
- igt_assert(feature->wait_until_enabled(drm.fd));
+ igt_assert(feature->wait_until_enabled(drm.fd, true));
}
igt_remove_fb(drm.fd, &fb);
@@ -230,13 +212,13 @@ static void subtest(struct feature *feature, bool suspend)
sleep(3);
wait_user("Back to fbcon.");
- igt_assert(!feature->wait_until_enabled(drm.fd));
+ igt_assert(!feature->wait_until_enabled(drm.fd, true));
if (suspend) {
igt_system_suspend_autoresume(SUSPEND_STATE_MEM,
SUSPEND_TEST_NONE);
sleep(5);
- igt_assert(!feature->wait_until_enabled(drm.fd));
+ igt_assert(!feature->wait_until_enabled(drm.fd, true));
}
}
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH IGT v2 2/6] lib: Add PSR utility functions to igt library.
Factor out some code that was replicated in three test utilities into
some new IGT library functions so that we are checking PSR status in
a consistent fashion across all of our PSR tests.
v2: * Add sink CRC helper function
* Misc. bug fixes
* Rebase
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Jim Bride
---
lib/Makefile.sources | 2 +
lib/igt.h| 1 +
lib/igt_psr.c| 235 +++
lib/igt_psr.h| 43 ++
4 files changed, 281 insertions(+)
create mode 100644 lib/igt_psr.c
create mode 100644 lib/igt_psr.h
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 53fdb54..6a73c8c 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -83,6 +83,8 @@ lib_source_list = \
uwildmat/uwildmat.c \
igt_kmod.c \
igt_kmod.h \
+ igt_psr.c \
+ igt_psr.h \
$(NULL)
.PHONY: version.h.tmp
diff --git a/lib/igt.h b/lib/igt.h
index a069deb..0b8e3a8 100644
--- a/lib/igt.h
+++ b/lib/igt.h
@@ -37,6 +37,7 @@
#include "igt_gt.h"
#include "igt_kms.h"
#include "igt_pm.h"
+#include "igt_psr.h"
#include "igt_stats.h"
#ifdef HAVE_CHAMELIUM
#include "igt_chamelium.h"
diff --git a/lib/igt_psr.c b/lib/igt_psr.c
new file mode 100644
index 000..a2823bf
--- /dev/null
+++ b/lib/igt_psr.c
@@ -0,0 +1,235 @@
+/*
+ * Copyright © 2017 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
+
+/**
+ * SECTION:igt_psr
+ * @short_description: Panel Self Refresh helpers
+ * @title: Panel Self Refresh
+ * @include: igt.h
+ *
+ * This library provides various helpers to enable Panel Self Refresh,
+ * as well as to check the state of PSR on the system (enabled vs.
+ * disabled, active vs. inactive) or to wait for PSR to be active
+ * or inactive.
+ */
+
+/**
+ * igt_psr_source_support:
+ *
+ * Returns true if the source supports PSR.
+ */
+bool igt_psr_source_support(int fd)
+{
+ char buf[512];
+
+ igt_debugfs_read(fd, "i915_edp_psr_status", buf);
+
+ return strstr(buf, "Source_OK: yes\n");
+}
+
+
+/**
+ * igt_psr_sink_support:
+ *
+ * Returns true if the current eDP panel supports PSR.
+ */
+bool igt_psr_sink_support(int fd)
+{
+ char buf[256];
+
+ igt_debugfs_read(fd, "i915_edp_psr_status", buf);
+ return strstr(buf, "Sink_Support: yes\n");
+}
+
+/**
+ * igt_psr_possible:
+ *
+ * Returns true if both the source and sink support PSR.
+ */
+bool igt_psr_possible(int fd)
+{
+ char buf[512];
+
+ igt_debugfs_read(fd, "i915_edp_psr_status", buf);
+
+ return igt_psr_source_support(fd) && igt_psr_sink_support(fd);
+}
+
+/**
+ * igt_psr_active:
+ *
+ * Returns true if PSR is active on the panel.
+ */
+bool igt_psr_active(int fd)
+{
+ char buf[512];
+ bool actret = false;
+ bool hwactret = false;
+
+ igt_debugfs_read(fd, "i915_edp_psr_status", buf);
+ hwactret = (strstr(buf, "HW Enabled & Active bit: yes\n") != NULL);
+ actret = (strstr(buf, "Active: yes\n") != NULL);
+ igt_debug("hwactret: %s actret: %s\n", hwactret ? "true" : "false",
+actret ? "true" : "false");
+ return hwactret && actret;
+}
+
+/**
+ * igt_psr_await_status:
+ * @active: A boolean that causes the function to wait for PSR to activate
+ * if set to true, or to wait for PSR to deactivate if false.
+ *
+ * Returns true if the requested condition is met.
+ */
+bool igt_psr_await_status(int fd, bool active)
+{
+ const int timeout = 10;
+ int count = 0;
+ while (count < timeout) {
+ if (igt_psr_active(fd) == active) {
+ igt_debug("PSR %s after %d seconds.\n",
+ active ? "Active" : "Inactive", count);
+
[Intel-gfx] [PATCH IGT v2 5/6] tests/kms_frontbuffer_tracking: Fix multidraw subtest
The multidraw subtest was not taking whether or not the GEM buffer had ever been in write-combining mode when checking for PSR state, so fix that. Signed-off-by: Jim Bride --- tests/kms_frontbuffer_tracking.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c index 3a8b754..c52d7a0 100644 --- a/tests/kms_frontbuffer_tracking.c +++ b/tests/kms_frontbuffer_tracking.c @@ -2059,7 +2059,8 @@ static void multidraw_subtest(const struct test_mode *t) assertions = used_method != IGT_DRAW_MMAP_GTT ? ASSERT_LAST_ACTION_CHANGED : ASSERT_NO_ACTION_CHANGE; - if (op_disables_psr(t, used_method)) + if (op_disables_psr(t, used_method) && + !wc_used) assertions |= ASSERT_PSR_DISABLED; do_assertions(assertions); -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH IGT v2 3/6] tests/kms_psr_sink_crc: Refactor to use new PSR library primitives
v2: * Minor functional tweaks & bug fixes
* Rebase
Cc: Rodrigo Vivi
Cc: Paulo Zanoni
Signed-off-by: Jim Bride
---
tests/kms_psr_sink_crc.c | 134 +++
1 file changed, 66 insertions(+), 68 deletions(-)
diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
index 1a03719..50d002d 100644
--- a/tests/kms_psr_sink_crc.c
+++ b/tests/kms_psr_sink_crc.c
@@ -33,8 +33,6 @@
bool running_with_psr_disabled;
-#define CRC_BLACK ""
-
enum operations {
PAGE_FLIP,
MMAP_GTT,
@@ -64,13 +62,15 @@ static const char *op_str(enum operations op)
typedef struct {
int drm_fd;
+ int debugfs_fd;
+ int crc_fd;
int test_plane;
enum operations op;
uint32_t devid;
uint32_t crtc_id;
igt_display_t display;
drm_intel_bufmgr *bufmgr;
- struct igt_fb fb_green, fb_white;
+ struct igt_fb fb_green, fb_white, fb_blue;
igt_plane_t *primary, *sprite, *cursor;
int mod_size;
int mod_stride;
@@ -98,6 +98,7 @@ static void setup_output(data_t *data)
{
igt_display_t *display = &data->display;
igt_output_t *output;
+ drmModeModeInfoPtr mode = NULL;
enum pipe pipe;
for_each_pipe_with_valid_output(display, pipe, output) {
@@ -106,10 +107,15 @@ static void setup_output(data_t *data)
if (c->connector_type != DRM_MODE_CONNECTOR_eDP)
continue;
+ if (!igt_psr_find_good_mode(c, &mode))
+ continue;
+
+ igt_assert(mode != NULL);
+ igt_output_override_mode(output, mode);
igt_output_set_pipe(output, pipe);
data->crtc_id = output->config.crtc->crtc_id;
data->output = output;
- data->mode = igt_output_get_mode(output);
+ data->mode = &output->override_mode;
return;
}
@@ -119,10 +125,33 @@ static void display_init(data_t *data)
{
igt_display_init(&data->display, data->drm_fd);
setup_output(data);
+
+ /* We need to be able to do a modeset before we enable PSR to
+* ensure that we are running at a mode such that PSR setup can
+* complete within a single vblank interval.
+*/
+ igt_debug("Selected mode:\n");
+ kmstest_dump_mode(data->mode);
+ igt_create_color_fb(data->drm_fd,
+ data->mode->hdisplay, data->mode->vdisplay,
+ DRM_FORMAT_XRGB,
+ LOCAL_I915_FORMAT_MOD_X_TILED,
+ 0.0, .0, 1.0,
+ &data->fb_blue);
+
+ data->primary = igt_output_get_plane_type(data->output,
+ DRM_PLANE_TYPE_PRIMARY);
+ igt_plane_set_fb(data->primary, &data->fb_blue);
+ igt_display_commit(&data->display);
+ igt_set_module_param_int("enable_psr", running_with_psr_disabled ?
+0 : 1);
}
static void display_fini(data_t *data)
{
+ close(data->crc_fd);
+ close(data->debugfs_fd);
+ igt_output_override_mode(data->output, NULL);
igt_display_fini(&data->display);
}
@@ -192,90 +221,59 @@ static void fill_render(data_t *data, uint32_t handle,
unsigned char color)
gem_bo_busy(data->drm_fd, handle);
}
-static bool psr_possible(data_t *data)
+static inline bool psr_possible(data_t *data)
{
- char buf[512];
-
- igt_debugfs_read(data->drm_fd, "i915_edp_psr_status", buf);
-
return running_with_psr_disabled ||
- strstr(buf, "Sink_Support: yes\n");
+ igt_psr_sink_support(data->drm_fd);
}
-static bool psr_active(data_t *data)
+static inline bool psr_active(data_t *data)
{
- char buf[512];
-
- igt_debugfs_read(data->drm_fd, "i915_edp_psr_status", buf);
-
return running_with_psr_disabled ||
- strstr(buf, "HW Enabled & Active bit: yes\n");
+ igt_psr_active(data->drm_fd);
}
-static bool wait_psr_entry(data_t *data)
+static inline bool wait_psr_entry(data_t *data)
{
- int timeout = 5;
- while (timeout--) {
- if (psr_active(data))
- return true;
- sleep(1);
- }
- return false;
+ return running_with_psr_disabled ||
+ igt_psr_await_status(data->drm_fd, true);
}
static void get_sink_crc(data_t *data, char *crc) {
- int dir;
+ int rc, tries = 10;
+ memset(crc, 0, 6);
if (igt_interactive_debug)
return;
- dir = igt_debugfs_dir(data->drm_fd);
- igt_require_f(igt_sysfs_scanf(dir, "i915_sink_crc_eDP1", "%s\n", crc),
- "Sink CRC is unreliable on this machine. Try manual debug
with --interactive-debug=no-crc\n");
- close(dir);
-
- igt_debug("%s\n", crc);
+ d
[Intel-gfx] ✗ Fi.CI.BAT: failure for Kernel PSR Fix-ups (rev2)
== Series Details == Series: Kernel PSR Fix-ups (rev2) URL : https://patchwork.freedesktop.org/series/24049/ State : failure == Summary == Series 24049v2 Kernel PSR Fix-ups https://patchwork.freedesktop.org/api/1.0/series/24049/revisions/2/mbox/ Test core_auth: Subgroup basic-auth: pass -> INCOMPLETE (fi-kbl-r) Test gem_ctx_create: Subgroup basic-files: pass -> INCOMPLETE (fi-byt-n2820) Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 Test kms_pipe_crc_basic: Subgroup hang-read-crc-pipe-a: dmesg-warn -> PASS (fi-pnv-d510) fdo#101597 +1 Subgroup suspend-read-crc-pipe-b: pass -> DMESG-WARN (fi-byt-j1900) fdo#101516 pass -> FAIL (fi-skl-6700k) fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#101597 https://bugs.freedesktop.org/show_bug.cgi?id=101597 fdo#101516 https://bugs.freedesktop.org/show_bug.cgi?id=101516 fi-bdw-5557u total:279 pass:264 dwarn:0 dfail:0 fail:3 skip:11 time:436s fi-bdw-gvtdvmtotal:279 pass:257 dwarn:8 dfail:0 fail:0 skip:14 time:432s fi-bsw-n3050 total:279 pass:239 dwarn:0 dfail:0 fail:3 skip:36 time:520s fi-bxt-j4205 total:279 pass:256 dwarn:0 dfail:0 fail:3 skip:19 time:502s fi-byt-j1900 total:279 pass:250 dwarn:1 dfail:0 fail:3 skip:24 time:480s fi-byt-n2820 total:17 pass:16 dwarn:0 dfail:0 fail:0 skip:0 fi-hsw-4770 total:279 pass:259 dwarn:0 dfail:0 fail:3 skip:16 time:427s fi-hsw-4770r total:279 pass:259 dwarn:0 dfail:0 fail:3 skip:16 time:417s fi-ilk-650 total:279 pass:225 dwarn:0 dfail:0 fail:3 skip:50 time:414s fi-ivb-3520m total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:492s fi-ivb-3770 total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:470s fi-kbl-7500u total:279 pass:257 dwarn:0 dfail:0 fail:3 skip:18 time:454s fi-kbl-7560u total:279 pass:265 dwarn:0 dfail:0 fail:3 skip:10 time:570s fi-kbl-r total:1pass:0dwarn:0 dfail:0 fail:0 skip:0 fi-pnv-d510 total:279 pass:223 dwarn:1 dfail:0 fail:0 skip:55 time:553s fi-skl-6260u total:279 pass:265 dwarn:0 dfail:0 fail:3 skip:10 time:449s fi-skl-6700k total:279 pass:256 dwarn:0 dfail:0 fail:4 skip:18 time:445s fi-skl-6770hqtotal:279 pass:265 dwarn:0 dfail:0 fail:3 skip:10 time:467s fi-skl-gvtdvmtotal:279 pass:266 dwarn:0 dfail:0 fail:0 skip:13 time:435s fi-snb-2520m total:279 pass:247 dwarn:0 dfail:0 fail:3 skip:28 time:529s fi-snb-2600 total:279 pass:246 dwarn:0 dfail:0 fail:3 skip:29 time:404s fi-skl-6700hq failed to connect after reboot 6412bcb8e279d62b9d8ae2840712d6c85806369b drm-tip: 2017y-06m-30d-14h-56m-41s UTC integration manifest ddb903c drm/i915/psr: Account for sink CRC raciness on some panels b8169fa drm/i915/edp: Be less aggressive about changing link config on eDP b92ab9e8 drm/i915/psr: Clean-up intel_enable_source_psr1() 2eb6962 drm/i915/edp: Allow alternate fixed mode for eDP if available. == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_5084/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/psr: Clean-up intel_enable_source_psr1()
Reviewed-by: Rodrigo Vivi
On Fri, Jun 30, 2017 at 12:08 PM, Jim Bride wrote:
> On SKL+ there is a bit in SRD_CTL that software is not supposed to
> modify, but we currently clobber that bit when we enable PSR. In
> order to preserve the value of that bit, go ahead and read SRD_CTL and
> do a field-wise setting of the various bits that we need to initialize
> before writing the register back out. Additionally, go ahead and
> explicitly disable single-frame update since we aren't currently
> supporting it.
>
> v2: * Do a field-wise init on EDP_PSR_MAX_SLEEP_TIME even though we
> always set it to the max value. (Rodrigo)
> * Rebase
>
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Cc: Wayne Boyer
> Cc: Jani Nikula
> Signed-off-by: Jim Bride
> ---
> drivers/gpu/drm/i915/i915_reg.h | 4
> drivers/gpu/drm/i915/intel_psr.c | 21 +++--
> 2 files changed, 23 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 64cc674..df58818 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3789,18 +3789,22 @@ enum {
> #define EDP_PSR_MIN_LINK_ENTRY_TIME_4_LINES (1<<25)
> #define EDP_PSR_MIN_LINK_ENTRY_TIME_2_LINES (2<<25)
> #define EDP_PSR_MIN_LINK_ENTRY_TIME_0_LINES (3<<25)
> +#define EDP_PSR_MAX_SLEEP_TIME_MASK (0x1f<<20)
> #define EDP_PSR_MAX_SLEEP_TIME_SHIFT 20
> #define EDP_PSR_SKIP_AUX_EXIT(1<<12)
> #define EDP_PSR_TP1_TP2_SEL (0<<11)
> #define EDP_PSR_TP1_TP3_SEL (1<<11)
> +#define EDP_PSR_TP2_TP3_TIME_MASK (3<<8)
> #define EDP_PSR_TP2_TP3_TIME_500us (0<<8)
> #define EDP_PSR_TP2_TP3_TIME_100us (1<<8)
> #define EDP_PSR_TP2_TP3_TIME_2500us (2<<8)
> #define EDP_PSR_TP2_TP3_TIME_0us (3<<8)
> +#define EDP_PSR_TP1_TIME_MASK (0x3<<4)
> #define EDP_PSR_TP1_TIME_500us (0<<4)
> #define EDP_PSR_TP1_TIME_100us (1<<4)
> #define EDP_PSR_TP1_TIME_2500us (2<<4)
> #define EDP_PSR_TP1_TIME_0us (3<<4)
> +#define EDP_PSR_IDLE_FRAME_MASK (0xf<<0)
> #define EDP_PSR_IDLE_FRAME_SHIFT 0
>
> #define EDP_PSR_AUX_CTL
> _MMIO(dev_priv->psr_mmio_base + 0x10)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 559f1ab..132987b 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -280,17 +280,32 @@ static void intel_enable_source_psr1(struct intel_dp
> *intel_dp)
> * with the 5 or 6 idle patterns.
> */
> uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> - uint32_t val = EDP_PSR_ENABLE;
> + uint32_t val = I915_READ(EDP_PSR_CTL);
>
> + val |= EDP_PSR_ENABLE;
> +
> + val &= ~EDP_PSR_MAX_SLEEP_TIME_MASK;
> val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
> +
> + val &= ~EDP_PSR_IDLE_FRAME_MASK;
> val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
>
> + val &= ~EDP_PSR_MIN_LINK_ENTRY_TIME_MASK;
> if (IS_HASWELL(dev_priv))
> val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
>
> - if (dev_priv->psr.link_standby)
> + if (dev_priv->psr.link_standby) {
> val |= EDP_PSR_LINK_STANDBY;
>
> + /* SFU should only be enabled with link standby, but for
> +* now we do not support it. */
> + val &= ~BDW_PSR_SINGLE_FRAME;
> + } else {
> + val &= ~EDP_PSR_LINK_STANDBY;
> + val &= ~BDW_PSR_SINGLE_FRAME;
> + }
> +
> + val &= ~EDP_PSR_TP1_TIME_MASK;
> if (dev_priv->vbt.psr.tp1_wakeup_time > 5)
> val |= EDP_PSR_TP1_TIME_2500us;
> else if (dev_priv->vbt.psr.tp1_wakeup_time > 1)
> @@ -300,6 +315,7 @@ static void intel_enable_source_psr1(struct intel_dp
> *intel_dp)
> else
> val |= EDP_PSR_TP1_TIME_0us;
>
> + val &= ~EDP_PSR_TP2_TP3_TIME_MASK;
> if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
> val |= EDP_PSR_TP2_TP3_TIME_2500us;
> else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 1)
> @@ -309,6 +325,7 @@ static void intel_enable_source_psr1(struct intel_dp
> *intel_dp)
> else
> val |= EDP_PSR_TP2_TP3_TIME_0us;
>
> + val &= ~EDP_PSR_TP1_TP3_SEL;
> if (intel_dp_source_supports_hbr2(intel_dp) &&
> drm_dp_tps3_supported(intel_dp->dpcd))
> val |= EDP_PSR_TP1_TP3_SEL;
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing l
Re: [Intel-gfx] [PATCH v2 4/4] drm/i915/psr: Account for sink CRC raciness on some panels
my only bikeshed here is the subject since this is not the psr feature itself...
anyways, I don't mind much since sink crc is only used to test psr...
Also yes, based on what I saw on sink crc behaviour I know that this
doesn't fix things for real because I remember reading hundreds or
thousand incorrect values with on increment on count...
But anyways I believe that this improve the situation
So,
Reviewed-by: Rodrigo Vivi
On Fri, Jun 30, 2017 at 12:08 PM, Jim Bride wrote:
> According to the eDP spec, when the count field in TEST_SINK_MISC
> increments then the six bytes of sink CRC information in the DPCD
> should be valid. Unfortunately, this doesn't seem to be the case
> on some panels, and as a result we get some incorrect and inconsistent
> values from the sink CRC DPCD locations at times. This problem exhibits
> itself more on faster processors (relative failure rates HSW < SKL < KBL.)
> In order to try and account for this, we try a lot harder to read the sink
> CRC until we get consistent values twice in a row before returning what we
> read and delay for a time before trying to read. We still see some
> occasional failures, but reading the sink CRC is much more reliable,
> particularly on SKL and KBL, with these changes than without.
>
> v2: * Reduce number of retries when reading the sink CRC (Jani)
> * Refactor to minimize changes to the code (Jani)
> * Rebase
>
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Cc: Jani Nikula
> Signed-off-by: Jim Bride
> ---
> drivers/gpu/drm/i915/intel_dp.c | 40
> 1 file changed, 36 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index b46fa03..1fe0975 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3927,6 +3927,14 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
> *crc)
> u8 buf;
> int count, ret;
> int attempts = 6;
> + u8 old_crc[6];
> +
> + if (crc != NULL) {
> + memset(crc, 0, 6);
> + memset(old_crc, 0xff, 6);
> + } else {
> + return -ENOMEM;
> + }
>
> ret = intel_dp_sink_crc_start(intel_dp);
> if (ret)
> @@ -3950,11 +3958,35 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8
> *crc)
> goto stop;
> }
>
> - if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR, crc, 6) < 0) {
> - ret = -EIO;
> - goto stop;
> - }
> + attempts = 6;
> +
> + /*
> +* Sometimes it takes a while for the "real" CRC values to land in
> +* the DPCD, so try several times until we get two reads in a row
> +* that are the same. If we're an eDP panel, delay between reads
> +* for a while since the values take a bit longer to propagate.
> +*/
> + do {
> + intel_wait_for_vblank(dev_priv, intel_crtc->pipe);
> + if (is_edp(intel_dp))
> + usleep_range(2, 25000);
> +
> + if (drm_dp_dpcd_read(&intel_dp->aux, DP_TEST_CRC_R_CR,
> +crc, 6) < 0) {
> + ret = -EIO;
> + goto stop;
> + }
> +
> + if (memcmp(old_crc, crc, 6) == 0) {
> + ret = 0;
> + goto stop;
> + } else {
> + memcpy(old_crc, crc, 6);
> + }
> + } while (--attempts);
>
> + DRM_DEBUG_KMS("Failed to get CRC after 6 attempts.\n");
> + ret = -ETIMEDOUT;
> stop:
> intel_dp_sink_crc_stop(intel_dp);
> return ret;
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH IGT v2 1/6] tests/kms_psr_sink_crc: Change assert_or_manual() to a macro
oh! at least one good reason why igt is full of macros! :(
Reviewed-by: Rodrigo Vivi
On Fri, Jun 30, 2017 at 12:12 PM, Jim Bride wrote:
> Make assert_or_manual() a macro so that we get accurate line number
> information when this assertion fails.
>
> v2: Rebase
>
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Signed-off-by: Jim Bride
> ---
> tests/kms_psr_sink_crc.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/tests/kms_psr_sink_crc.c b/tests/kms_psr_sink_crc.c
> index bd3fa5e..1a03719 100644
> --- a/tests/kms_psr_sink_crc.c
> +++ b/tests/kms_psr_sink_crc.c
> @@ -278,11 +278,11 @@ static bool is_green(char *crc)
> (bh & mask) == 0);
> }
>
> -static void assert_or_manual(bool condition, const char *expected)
> -{
> - igt_debug_manual_check("no-crc", expected);
> - igt_assert(igt_interactive_debug || condition);
> -}
> +#define assert_or_manual(condition, expected) \
> +do { \
> + igt_debug_manual_check("no-crc", expected); \
> + igt_assert(igt_interactive_debug || condition); \
> +} while (0)
>
> static void run_test(data_t *data)
> {
> --
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Rodrigo Vivi
Blog: http://blog.vivi.eng.br
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH IGT v2 2/6] lib: Add PSR utility functions to igt library.
On Fri, Jun 30, 2017 at 12:12 PM, Jim Bride wrote:
> Factor out some code that was replicated in three test utilities into
> some new IGT library functions so that we are checking PSR status in
> a consistent fashion across all of our PSR tests.
>
> v2: * Add sink CRC helper function
> * Misc. bug fixes
> * Rebase
>
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Signed-off-by: Jim Bride
> ---
> lib/Makefile.sources | 2 +
> lib/igt.h| 1 +
> lib/igt_psr.c| 235
> +++
> lib/igt_psr.h| 43 ++
> 4 files changed, 281 insertions(+)
> create mode 100644 lib/igt_psr.c
> create mode 100644 lib/igt_psr.h
>
> diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> index 53fdb54..6a73c8c 100644
> --- a/lib/Makefile.sources
> +++ b/lib/Makefile.sources
> @@ -83,6 +83,8 @@ lib_source_list = \
> uwildmat/uwildmat.c \
> igt_kmod.c \
> igt_kmod.h \
> + igt_psr.c \
> + igt_psr.h \
> $(NULL)
>
> .PHONY: version.h.tmp
> diff --git a/lib/igt.h b/lib/igt.h
> index a069deb..0b8e3a8 100644
> --- a/lib/igt.h
> +++ b/lib/igt.h
> @@ -37,6 +37,7 @@
> #include "igt_gt.h"
> #include "igt_kms.h"
> #include "igt_pm.h"
> +#include "igt_psr.h"
> #include "igt_stats.h"
> #ifdef HAVE_CHAMELIUM
> #include "igt_chamelium.h"
> diff --git a/lib/igt_psr.c b/lib/igt_psr.c
> new file mode 100644
> index 000..a2823bf
> --- /dev/null
> +++ b/lib/igt_psr.c
> @@ -0,0 +1,235 @@
> +/*
> + * Copyright © 2017 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
> +
> +/**
> + * SECTION:igt_psr
> + * @short_description: Panel Self Refresh helpers
> + * @title: Panel Self Refresh
> + * @include: igt.h
> + *
> + * This library provides various helpers to enable Panel Self Refresh,
> + * as well as to check the state of PSR on the system (enabled vs.
> + * disabled, active vs. inactive) or to wait for PSR to be active
> + * or inactive.
> + */
> +
> +/**
> + * igt_psr_source_support:
> + *
> + * Returns true if the source supports PSR.
> + */
> +bool igt_psr_source_support(int fd)
> +{
> + char buf[512];
> +
> + igt_debugfs_read(fd, "i915_edp_psr_status", buf);
> +
> + return strstr(buf, "Source_OK: yes\n");
> +}
> +
> +
> +/**
> + * igt_psr_sink_support:
> + *
> + * Returns true if the current eDP panel supports PSR.
> + */
> +bool igt_psr_sink_support(int fd)
> +{
> + char buf[256];
> +
> + igt_debugfs_read(fd, "i915_edp_psr_status", buf);
> + return strstr(buf, "Sink_Support: yes\n");
> +}
> +
> +/**
> + * igt_psr_possible:
> + *
> + * Returns true if both the source and sink support PSR.
> + */
> +bool igt_psr_possible(int fd)
> +{
> + char buf[512];
> +
> + igt_debugfs_read(fd, "i915_edp_psr_status", buf);
> +
> + return igt_psr_source_support(fd) && igt_psr_sink_support(fd);
> +}
> +
> +/**
> + * igt_psr_active:
> + *
> + * Returns true if PSR is active on the panel.
> + */
> +bool igt_psr_active(int fd)
> +{
> + char buf[512];
> + bool actret = false;
> + bool hwactret = false;
> +
> + igt_debugfs_read(fd, "i915_edp_psr_status", buf);
> + hwactret = (strstr(buf, "HW Enabled & Active bit: yes\n") != NULL);
> + actret = (strstr(buf, "Active: yes\n") != NULL);
> + igt_debug("hwactret: %s actret: %s\n", hwactret ? "true" : "false",
> +actret ? "true" : "false");
> + return hwactret && actret;
> +}
> +
> +/**
> + * igt_psr_await_status:
> + * @active: A boolean that causes the function to wait for PSR to activate
> + * if set to true, or to wait for PSR to deactivate if false.
> + *
> + * Returns true if
Re: [Intel-gfx] [PATCH IGT v2 4/6] tests/kms_frontbuffer_tracking: Refactor to use IGT PSR library functions
I believe it would be better to create the psr lib with only one
function at time and on every patch that adds the new function already
removes that from here and from frontbuffer tracking test as well...
easier to review and to make sure that we are not changing the behaviour.
also...
On Fri, Jun 30, 2017 at 12:12 PM, Jim Bride wrote:
> v2: * Minor functional tweaks and bug fixes
> * Rebase
>
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Signed-off-by: Jim Bride
> ---
> tests/kms_frontbuffer_tracking.c | 119
> +++
> 1 file changed, 19 insertions(+), 100 deletions(-)
>
> diff --git a/tests/kms_frontbuffer_tracking.c
> b/tests/kms_frontbuffer_tracking.c
> index c24e4a8..3a8b754 100644
> --- a/tests/kms_frontbuffer_tracking.c
> +++ b/tests/kms_frontbuffer_tracking.c
> @@ -183,7 +183,7 @@ struct {
> };
>
>
> -#define SINK_CRC_SIZE 12
> +#define SINK_CRC_SIZE 6
I believe this deserves a separated patch...
> typedef struct {
> char data[SINK_CRC_SIZE];
> } sink_crc_t;
> @@ -327,28 +327,6 @@ drmModeModeInfo std_1024_mode = {
> .name = "Custom 1024x768",
> };
>
> -static drmModeModeInfoPtr get_connector_smallest_mode(drmModeConnectorPtr c)
> -{
> - int i;
> - drmModeModeInfoPtr smallest = NULL;
> -
> - for (i = 0; i < c->count_modes; i++) {
> - drmModeModeInfoPtr mode = &c->modes[i];
> -
> - if (!smallest)
> - smallest = mode;
> -
> - if (mode->hdisplay * mode->vdisplay <
> - smallest->hdisplay * smallest->vdisplay)
> - smallest = mode;
> - }
> -
> - if (c->connector_type == DRM_MODE_CONNECTOR_eDP)
> - smallest = &std_1024_mode;
> -
> - return smallest;
> -}
> -
> static drmModeConnectorPtr get_connector(uint32_t id)
> {
> int i;
> @@ -421,30 +399,6 @@ static void init_mode_params(struct modeset_params
> *params, uint32_t crtc_id,
> params->sprite.h = 64;
> }
>
> -static bool connector_get_mode(drmModeConnectorPtr c, drmModeModeInfoPtr
> *mode)
> -{
> - *mode = NULL;
> -
> - if (c->connection != DRM_MODE_CONNECTED || !c->count_modes)
> - return false;
> -
> - if (c->connector_type == DRM_MODE_CONNECTOR_eDP && opt.no_edp)
> - return false;
> -
> - if (opt.small_modes)
> - *mode = get_connector_smallest_mode(c);
> - else
> - *mode = &c->modes[0];
> -
> -/* On HSW the CRC WA is so awful that it makes you think everything
> is
> - * bugged. */
> - if (IS_HASWELL(intel_get_drm_devid(drm.fd)) &&
> - c->connector_type == DRM_MODE_CONNECTOR_eDP)
> - *mode = &std_1024_mode;
> -
> - return true;
> -}
> -
> static bool connector_supports_pipe_a(drmModeConnectorPtr connector)
> {
> int i;
> @@ -473,7 +427,7 @@ static bool find_connector(bool edp_only, bool pipe_a,
> uint32_t forbidden_id,
> continue;
> if (c->connector_id == forbidden_id)
> continue;
> - if (!connector_get_mode(c, &mode))
> + if (!igt_psr_find_good_mode(c, &mode))
> continue;
>
> *ret_connector = c;
> @@ -804,23 +758,6 @@ static void fbc_print_status(void)
> igt_info("FBC status:\n%s\n", buf);
> }
>
> -static bool psr_is_enabled(void)
> -{
> - char buf[256];
> -
> - debugfs_read("i915_edp_psr_status", buf);
> - return strstr(buf, "\nActive: yes\n") &&
> - strstr(buf, "\nHW Enabled & Active bit: yes\n");
> -}
> -
> -static void psr_print_status(void)
> -{
> - char buf[256];
> -
> - debugfs_read("i915_edp_psr_status", buf);
> - igt_info("PSR status:\n%s\n", buf);
> -}
> -
> static struct timespec fbc_get_last_action(void)
> {
> struct timespec ret = { 0, 0 };
> @@ -926,44 +863,31 @@ static bool fbc_wait_until_enabled(void)
> return igt_wait(fbc_is_enabled(), 2000, 1);
> }
>
> -static bool psr_wait_until_enabled(void)
> -{
> - return igt_wait(psr_is_enabled(), 5000, 1);
> -}
> -
> #define fbc_enable() igt_set_module_param_int("enable_fbc", 1)
> #define fbc_disable() igt_set_module_param_int("enable_fbc", 0)
> -#define psr_enable() igt_set_module_param_int("enable_psr", 1)
> -#define psr_disable() igt_set_module_param_int("enable_psr", 0)
>
> static void get_sink_crc(sink_crc_t *crc, bool mandatory)
> {
> - int rc, errno_;
> + int rc;
>
> if (!sink_crc.supported) {
> memcpy(crc, "unsupported!", SINK_CRC_SIZE);
this doesn't fit anymore
> return;
> }
>
> - lseek(sink_crc.fd, 0, SEEK_SET);
> -
> - rc = read(sink_crc.fd, crc->data, SINK_CRC_SIZE);
> - errno_ = errno;
> -
> - if (rc == -1 && errno_ == ENOTTY) {
> + rc = igt_psr_get_sink_crc(sink_crc.fd, crc->data);
> + if
