Re: [Intel-gfx] [PATCH 11/41] drm/i915: Introduce an internal allocator for disposable private objects

[Chris Wilson]

On Mon, Oct 17, 2016 at 10:47:09AM +0100, Tvrtko Ursulin wrote:
> 
> On 14/10/2016 15:42, Chris Wilson wrote:
> >On Fri, Oct 14, 2016 at 03:35:59PM +0100, Tvrtko Ursulin wrote:
> >>On 14/10/2016 14:53, Chris Wilson wrote:
> >We do pass NORETRY | NOWARN for the higher order allocations, so it
> >shouldn't be as bad it seems?
> I don't know for sure without looking into the implementation
> details. But I assumed even with NORETRY it does some extra work to
> try and free up the space. And if it fails, and we ask for it again,
> it is just doing that extra work for nothing. Because within a
> single allocation it sounds unlikely that something would change so
> dramatically that it would start working.
> >>>iirc, NORETRY means abort after failure. In effect, it does
> >>>2 attempts from the freelist, a direct reclaim, and may then repeat
> >>>if the task's allowed set of nodes were concurrently changed.
> >>Do you think it makes sense doing all that after it started failing,
> >>within our single get_pages allocation?
> >I was thinking about skipping the DIRECT_RECLAIM for high order, but it
> >seems like that is beneficial for THP, so I'm presuming it should also
> >be for ourselves. Trimming back max_order seems sensible, but I still
> >like the idea of taking advantage of contiguous pages where possible
> >(primarily these will be used for ringbuffers and shadow batches).
> 
> Can we agree then to try larger order first and fall back gradually?

I thought we had already agreed on that! I thought we were looking at
what else we might do. :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Use fence_write() from rpm resume

[Daniel Vetter]

On Thu, Oct 13, 2016 at 04:41:01PM +0100, Chris Wilson wrote:
> On Thu, Oct 13, 2016 at 05:28:13PM +0200, Daniel Vetter wrote:
> > On Thu, Oct 13, 2016 at 04:25:18PM +0100, Chris Wilson wrote:
> > > On Thu, Oct 13, 2016 at 05:10:21PM +0200, Daniel Vetter wrote:
> > > > On Wed, Oct 12, 2016 at 12:16:33PM +0100, Chris Wilson wrote:
> > > > > @@ -379,10 +389,17 @@ void i915_gem_restore_fences(struct drm_device 
> > > > > *dev)
> > > > >* Commit delayed tiling changes if we have an object 
> > > > > still
> > > > >* attached to the fence, otherwise just clear the 
> > > > > fence.
> > > > >*/
> > > > > - if (vma && !i915_gem_object_is_tiled(vma->obj))
> > > > > + if (vma && !i915_gem_object_is_tiled(vma->obj)) {
> > > > > + GEM_BUG_ON(!reg->dirty);
> > > > > + 
> > > > > GEM_BUG_ON(!list_empty(>obj->userfault_link));
> > > > > +
> > > > > + list_move(>link, _priv->mm.fence_list);
> > > > > + vma->fence = NULL;
> > > > >   vma = NULL;
> > > > > + }
> > > > >  
> > > > > - fence_update(reg, vma);
> > > > > + fence_write(reg, vma);
> > > > > + reg->vma = vma;
> > > > 
> > > > Same comments as with the userfault_list: Using rpm ordering to enforce
> > > > consistency causes mild panic attacks here with me ;-)
> > > > 
> > > > Is the above (delayed tiling change commit) even possible here, at least
> > > > for rpm resume? Same for system s/r (both s3 and s4) since the 
> > > > pagetables
> > > > won't survive anyway. Can't we simply make this an impossibility?
> > > 
> > > We also use this from reset to rewrite the old fences, and we know there
> > > we can hit the delayed fence write [4fc788f5ee3d]. It would also be
> > > possible to hit it on suspend as well.
> > > 
> > > I've been thinking about whether we should be bothering to write the
> > > fence registers with the correct value or just cancel the fences. But we
> > > have to restore anything that is pinned, and we have to write something
> > > into the fences (just to be safe), and if we have to write something we
> > > may as well use the most recent information we have as that has a good
> > > chance of being used again.
> > > 
> > > Long story short, I don't have a better idea for restoring or avoiding
> > > the restore of fences.
> > 
> > What about a rpm_resume only version that just does a blind fence_write?
> > It is something, and we can update the book-keeping once we do get to one
> > of the real synchronization points again.
> > 
> > With that we can leave the versions for reset and system s/r alone ... Or
> > is there trickery even with rpm going on?
> 
> For rpm suspend, we only zap the user's mmap and not mark the fence as
> lost. I think that's the missing piece as to why this is not as simple as
> it could be for rpm-resume. On rpm-resume we only need to restore pinned
> fences, and fences should only be pinned for hw access, and so there
> should never be any if we were rpm-suspended. (Assuming that all pinned
> fences are active, which on the surface seems a reasonable assumption.)
> 
> If that holds true, we do not need this at all for runtime pm (we still
> need it across full system suspend/reset) and just need to doctor the
> existing scary i915_gem_release_all_mmaps() (aka
> i915_gem_runtime_suspend()!) to both release the mmap and throw away the
> fence tracing. At least then we only have one dragon nest.

Yeah, would be great to unify this stuff a bit ... Making fence semantics
the same for rpm suspend as for normal suspend would definitely be nice,
and the hw will forget about the registers anyway.
-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 0/8] dim: move -nigthly into drm-nighly.git

[Daniel Vetter]

On Sun, Oct 16, 2016 at 08:48:02PM +0200, Daniel Vetter wrote:
> Hi all,
> 
> This is the first step to split out the drm-misc trees into their own git 
> repo.
> This just moves the integration trees into drm-nightly.git. Those are separate
> since I really like the idea of sharing one integration tree related to gfx.
> 
> Next up is teaching all the branch related dim commands to figure out the 
> right
> remote. But I think it'd be good to frist roll out this change, actually
> splitting out drm-misc.git will then not affect any of the drm-intel 
> committers.

People asked why on irc, so here's a bit more context: I want to extract
drm-misc into a separate repo for a bunch of reasons. Doing the committer
model for drm-misc within the drm-intel.git repo was really just for a
quick test-drive to see whether it would work. But before scaling it out I
need to fix that:
- separate git repos is the only way to do acls on fd.o
- I want the same model like for drm-intel-next-queued where the main
  branch is always open for drm-misc, with a -next-fixes as needed.
- "eww, intel" reactions from the arm side, so better separation ;-)

Now I still think the shared integration tree is really useful, hence why
I want to keep just one for both trees. Which means step 1 is to first
split out integration tree stuff into a new drm-nightly.git, which both
groups can push to.
-Daniel

> 
> Cheers, Daniel
> 
> Daniel Vetter (8):
>   dim: Extract TODO
>   dim: Autocheck for up-to-dateness
>   dim: autodetect remotes, first part for dim_setup
>   dim: support git worktree for aux checkouts
>   dim: Nuke nightly-forget
>   dim: autodetect branches in rebuild-nightly
>   dim: remove integration-tree remotes
>   dim: Split out drm-nightly.git
> 
>  TODO |  25 
>  dim  | 227 
> +++
>  qf   |  11 
>  3 files changed, 144 insertions(+), 119 deletions(-)
>  create mode 100644 TODO
> 
> -- 
> 2.9.3
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

[Daniel Vetter]

On Fri, Oct 14, 2016 at 07:27:39PM +, Pandiyan, Dhinakaran wrote:
> On Thu, 2016-10-13 at 11:30 -0700, Jim Bride wrote:
> > On Thu, Oct 13, 2016 at 11:04:19AM -0700, Dhinakaran Pandiyan wrote:
> > > According to BSpec, cdclk has to be not less than 432 MHz with DP audio
> > > enabled, port width x4, and link rate HBR2 (5.4 GHz)
> > > 
> > > Having a lower cdclk triggers pipe underruns, which then lead to displays
> > > continuously cycling off and on. This is essential for DP MST audio as the
> > > link is trained at HBR2 and 4 lanes by default.
> > > 
> > > This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907
> > > 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 47 
> > > +---
> > >  1 file changed, 43 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index cfcb03f..6a05183 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -6603,14 +6603,43 @@ static int valleyview_modeset_calc_cdclk(struct 
> > > drm_atomic_state *state)
> > >   return 0;
> > >  }
> > >  
> > > +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state)
> > > +{
> > > +
> > > + struct drm_crtc_state *crtc_state;
> > > + struct drm_crtc *crtc;
> > > + int i;
> > > +
> > > + /* BSpec says "Do not use DisplayPort with CDCLK less than 432 MHz,
> > > +  * audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else
> > > +  * there may be audio corruption or screen corruption."
> > > +  */
> > 
> > It's probably worth mentioning that this limitation really only applies for
> > SKL (at least that I can see) and BXT A (which I don't think we even care
> > about anymore since it's not a production part.)  Were we seeing underruns
> > on non-SKL platforms that increasing CDCLK fixed?   In any event, I'd rather
> > see this only implemented for SKL (see BDW code below) unless we've 
> > empirically
> > noticed a similar problem on BDW (or the B-Spec says something about this 
> > and I
> > missed it.)
> > 
> > Jim
> > 
> > 
> Yes, Libin saw the problem when testing a BDW NUC. And, the patch is
> applicable to BDW according to the BSpec. I will try to get a
> confirmation on whether this is needed BXT production parts.

Please also check docs for hsw, that's where dp mst support started.
-Daniel

> 
> > > +
> > > + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > > + struct intel_crtc_state *pipe_config =
> > > + to_intel_crtc_state(crtc_state);
> > > +
> > > + return (intel_crtc_has_dp_encoder(pipe_config) &&
> > > + pipe_config->has_audio &&
> > > + pipe_config->port_clock == 54 &&
> > > + pipe_config->lane_count == 4);
> > > + }
> > > +
> > > + return false;
> > > +}
> > > +
> > >  static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state)
> > >  {
> > >   int max_pixclk = ilk_max_pixel_rate(state);
> > > + int cdclk, min_cdclk = 0;
> > >   struct intel_atomic_state *intel_state =
> > >   to_intel_atomic_state(state);
> > >  
> > > - intel_state->cdclk = intel_state->dev_cdclk =
> > > - bxt_calc_cdclk(max_pixclk);
> > > + if (cdclk_min_for_dp_audio(state))
> > > + min_cdclk = bxt_calc_cdclk(432000);
> > > +
> > > + cdclk = bxt_calc_cdclk(max_pixclk);
> > > + intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk, cdclk);
> > >  
> > >   if (!intel_state->active_crtcs)
> > >   intel_state->dev_cdclk = bxt_calc_cdclk(0);
> > > @@ -10374,7 +10403,10 @@ static int broadwell_modeset_calc_cdclk(struct 
> > > drm_atomic_state *state)
> > >   struct drm_i915_private *dev_priv = to_i915(state->dev);
> > >   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> > >   int max_pixclk = ilk_max_pixel_rate(state);
> > > - int cdclk;
> > > + int cdclk, min_cdclk = 0;
> > > +
> > > + if (cdclk_min_for_dp_audio(state))
> > > + min_cdclk = broadwell_calc_cdclk(432000);
> > >  
> > >   /*
> > >* FIXME should also account for plane ratio
> > > @@ -10382,6 +10414,8 @@ static int broadwell_modeset_calc_cdclk(struct 
> > > drm_atomic_state *state)
> > >*/
> > >   cdclk = broadwell_calc_cdclk(max_pixclk);
> > >  
> > > + cdclk = max(min_cdclk, cdclk);
> > > +
> > >   if (cdclk > dev_priv->max_cdclk_freq) {
> > >   DRM_DEBUG_KMS("requested cdclk (%d kHz) exceeds max (%d kHz)\n",
> > > cdclk, dev_priv->max_cdclk_freq);
> > > @@ -10411,7 +10445,10 @@ static int skl_modeset_calc_cdclk(struct 
> > > drm_atomic_state *state)
> > >   struct drm_i915_private *dev_priv = to_i915(state->dev);
> > >   const int max_pixclk = ilk_max_pixel_rate(state);
> > >   int vco = intel_state->cdclk_pll_vco;
> > > - int cdclk;
> > > + int cdclk, min_cdclk = 0;
> > > +
> > > + if 

Re: [Intel-gfx] [PULL] GVT-g device model core

[Daniel Vetter]

On Fri, Oct 14, 2016 at 06:30:30PM +0800, Zhenyu Wang wrote:
> 
> Hi,
> 
> This is first pull request to merge GVT-g device model in i915
> which contains core GVT-g device model work to virtualize GPU
> resources. This tries to add feature of Intel GVT-g technology
> for full GPU virtualization. This version will support KVM based
> virtualization solution named as KVMGT.
> 
> More background is on official project home: https://01.org/igvt-g
> 
> To manage mediated device between virtual GPU and physical device it
> will rely on VFIO/mdev framework, this version has not included GVT-g
> device model integration work for VFIO/mdev yet as VFIO community is
> still under work to refine code base. Currently we're basing on
> VFIO/mdev v8 patch series (http://www.spinics.net/lists/kvm/msg138515.html)
> and doing more testings on that.
> 
> There're also several KVM change dependences. KVM maintainer has
> merged two and we will ensure left hits KVM tree before sending new
> pull request to enable that.
> 
> p.s, There would require some coordinate work for VFIO/mdev. We will
> send device model work for that after Alex merged mdev framework in
> VFIO tree. Alex has promised to merge that in early of Nov.
> 
> Let me know if there's any issue with this our first pull request.

Ok applied, but a few things to keep in mind before your next pull
request:

- Dont rebase everything 5 seconds before sending out the pull request.
  That just invalidates all the testing you've done, so not a good idea.
  In general try to avoid rebases as much as possible, and only rebase to
  take out a truly embarassing mistake. And then only rebase up to the
  patch that needs a hotfix, not your entire tree.

- Similar, don't base your pull requests upon a random commit of the day
  (that's why I noticed you rebased). Instead pick something meaningful,
  like a tag I (or Dave Airlie or Linus Torvalds) push out. Or another
  good option is to base it right on top of the last merge commit from
  gvt. Once you've picked a baseline, don't change it (except when you
  have a good reason). And if you need a patch from upstream also don't
  rebase, just send out a pull request with your current patch pile, and
  then continue applying more stuff on top once I merged that.

- One technical nit on the integration: My idea was that i915 core code
  only calls a few specific functions and structures exposed through
  intel_gvt.h. But that file now seems to include gvt-internal headers,
  which is a bit a mess. Please clean that up in the next pull request:

  * Anything that core i915 code or headers needs must be moved into
intel_gvt.h.
  * Everything else, including the 2 gvt includes we now have (gvt/gvt.h
and i915_pvinfo.h) should only be included from code in
drm/i915/gvt.h. So either sprinkle include directives over your source
files for everything, or make gvt/gvt.h the main gvt header that pulls
in everything.

  The idea here is similar to drm core vs. i915: drm core headers never
  pull in i915 headers, and all communication happens through the
  well-defined interfaces in drm core header files. I think our goal with
  gvt should be similar, with all the interfaces being in intel_gvt.h.
  Otherwise I fear the submaintainer model will be a bit painful, if we
  don't aim for strict separation here.

- There's not yet a MAINTAINERS entry for i915/gvt with gvt mailing lists,
  git repos and your name on it. Please fix that in the next pull request,
  too.

- gvt seems to lack kernel-doc entirely. I think we need at least an
  overview file and interface documentation for the stuff in
  intel_gvt.[hc]. Please run

$ make hmtldocs

  to make sure it all looks pretty (you need to add stanzas in
  Documenation/gpu/i915.rst to include things). Another item for the next
  pull request please.

Also, this is the first time ever I've taken a pull request, so some
learning involved on my side too. Please bear with me ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Uevent for retraining in case of link training failure in atomic commit phase

[Daniel Vetter]

On Sun, Oct 16, 2016 at 10:51:30PM -0700, Manasi Navare wrote:
> Hi,
> 
> I am working on adding a link rate fallback in case of link training failure.
> If the link training fails at a specific link rate/lane count in atomic
> commit phase, I validate the modes again based on the link rate lower than
> the failed link rate and prune the invalid modes accordingly to update the
> connector->modes list. I then send a hotplug uevent to the userspace, 
> expecting
> it to detect the change in the mode list and trigger a modeset during which
> the link would be retrained to a lower link rate.
> 
> After looking at the userspace debug logs, I see that after it recieves this
> uevent on link failure, 
> xf86-video-intel/src/sna/sna_mode_display.c/sna_mode_discover(),
> calls output_check_status() which only detects a state change if it is 
> changed from 
> connected to disconnected or vice versa. So change in the modelist does not 
> get detected 
> as connector status changed and it notifies "state retained", does not call 
> RRGetInfo() 
> and does not trigger a new modeset.
> 
> If in case of link train failure, I force the connector status to be 
> disconnected
> then it clears the state, disables all the PLLs, triggers a new modeset. 
> However during
> this time, the CTS test times out (10ms) and hence compliance fails.
> 
> Is there any other way, we can force the userspace to detect a change in the 
> connector
> state so that it triggers a full modeset without forcing the connector state 
> to be disconnected?

I'd say we need to change userspace to be able to handle this. One idea I
tossed around with Chris Wilson for these kind of changes is a
connector epoch counter: Every time anything changes (mode list, link
limits, edid, mst routing, whatever) we increment that connector property.
That way userspace can just compare the old epoch value it has with the
new one, and if it changed it knows something is different with that
specific connector. And it needs to re-read all the state.

That's the only reliable way to send such changes to userspace. It's quite
a bit more workt though (since also we need to update userspace and all
that).

I think one option might be to do upfront link training (if the link isn't
on or otherwise in use) for now, at least if it's not too invasive. And
then work on the full solution with uevents and userspace changes. But I
leave the judgement on "not too invasive" up to you, Jani (since I
haven't looked at the last round of patches at all).
-Daniel

> The pieces of  /var/log/Xorg.0.log that capture the sna_mode_discover are 
> pasted here:
> http://paste.ubuntu.com/23337284/
> In this log, the third call to sna_mode_discover maps to the uevent sent due 
> to link
> failure where it indicates state retained and does not do anything further.
> 
> The Kernel dmesg log in case of forcing the connector status to disconnected 
> is:
> http://paste.ubuntu.com/23337285/
> 
> Please let me know if any of you have suggestions, I am not a userspace 
> expert.
> This test is done with Ubuntu 16.04 and CTS run using DPR-120 test 4.3.1.3
> 
> Regards
> Manasi
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Remove superfluous locking around userfault_list

[Joonas Lahtinen]

On pe, 2016-10-14 at 12:05 +0100, Chris Wilson wrote:
> Now that we have reduced the access to the list to either (a) under the
> struct_mutex whilst holding the RPM wakeref (so that concurrent writers to
> the list are serialised by struct_mutex) and (b) under the atomic
> runtime suspend (which cannot run concurrently with any other accessor due
> to the atomic nature of the runtime suspend) we can remove the extra
> locking around the list itself.
> 
> Signed-off-by: Chris Wilson 

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/4] drm: Add and handle new aspect ratios in DRM layer

[Sharma, Shashank]

> r-b with that bikeshed addressed or not?
Hello Daniel, 
I have already acknowledged this comment, and I am publishing next set today 
with rebase, addressing this comment. 
So you can consider this one done. 

Regards
Shashank
-Original Message-
From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
Sent: Monday, October 17, 2016 11:33 AM
To: Jim Bride 
Cc: Sharma, Shashank ; 
dri-de...@lists.freedesktop.org; seanp...@chromium.org; 
jose.ab...@synopsys.com; Daniel Vetter ; 
intel-gfx@lists.freedesktop.org; Vetter, Daniel 
Subject: Re: [Intel-gfx] [PATCH v2 4/4] drm: Add and handle new aspect ratios 
in DRM layer

On Thu, Oct 13, 2016 at 10:28:14AM -0700, Jim Bride wrote:
> On Tue, Aug 09, 2016 at 08:25:50PM +0530, Shashank Sharma wrote:
> > HDMI 2.0/CEA-861-F introduces two new aspect ratios:
> > - 64:27
> > - 256:135
> > 
> > This patch:
> > -  Adds new DRM flags for to represent these new aspect ratios.
> > -  Adds new cases to handle these aspect ratios while converting 
> > from user->kernel mode or vise versa.
> > 
> > V2: Rebase
> > 
> > Signed-off-by: Shashank Sharma 
> > Reviewed-by: Sean Paul 
> > Cc: Daniel Vetter 
> > Cc: Emil Velikov 
> > ---
> >  drivers/gpu/drm/drm_modes.c | 12   
> > include/uapi/drm/drm_mode.h |  6 ++
> >  2 files changed, 18 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_modes.c 
> > b/drivers/gpu/drm/drm_modes.c index 9d8f00d..ed1b07b 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -1481,6 +1481,12 @@ void drm_mode_convert_to_umode(struct 
> > drm_mode_modeinfo *out,
> > case HDMI_PICTURE_ASPECT_16_9:
> > out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
> > break;
> > +   case HDMI_PICTURE_ASPECT_64_27:
> > +   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
> > +   break;
> > +   case DRM_MODE_PICTURE_ASPECT_256_135:
> > +   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
> > +   break;
> > case HDMI_PICTURE_ASPECT_RESERVED:
> > default:
> > out->flags |= DRM_MODE_FLAG_PIC_AR_NONE; @@ -1542,6 +1548,12 @@ 
> > int drm_mode_convert_umode(struct drm_display_mode *out,
> > case DRM_MODE_FLAG_PIC_AR_16_9:
> > out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
> > break;
> > +   case DRM_MODE_FLAG_PIC_AR_64_27:
> > +   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
> > +   break;
> > +   case DRM_MODE_FLAG_PIC_AR_256_135:
> > +   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
> > +   break;
> > default:
> > out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> > break;
> > diff --git a/include/uapi/drm/drm_mode.h 
> > b/include/uapi/drm/drm_mode.h index 77c869d6..4d3429b 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -81,6 +81,8 @@ extern "C" {
> >  #define DRM_MODE_PICTURE_ASPECT_NONE   0
> >  #define DRM_MODE_PICTURE_ASPECT_4_31
> >  #define DRM_MODE_PICTURE_ASPECT_16_9   2
> > +#define DRM_MODE_PICTURE_ASPECT_64_27  3
> > +#define DRM_MODE_PICTURE_ASPECT_256_1354
> 
> Minor nit here, but in my tree the '4' above doesn't line up with the 
> three previous definitions.  I downloaded the series as a mbox from 
> patchwork.

r-b with that bikeshed addressed or not? Also any reason you didn't r-b patch 3?
-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 11/41] drm/i915: Introduce an internal allocator for disposable private objects

[Tvrtko Ursulin]

On 14/10/2016 15:42, Chris Wilson wrote:

On Fri, Oct 14, 2016 at 03:35:59PM +0100, Tvrtko Ursulin wrote:

On 14/10/2016 14:53, Chris Wilson wrote:

We do pass NORETRY | NOWARN for the higher order allocations, so it
shouldn't be as bad it seems?

I don't know for sure without looking into the implementation
details. But I assumed even with NORETRY it does some extra work to
try and free up the space. And if it fails, and we ask for it again,
it is just doing that extra work for nothing. Because within a
single allocation it sounds unlikely that something would change so
dramatically that it would start working.

iirc, NORETRY means abort after failure. In effect, it does
2 attempts from the freelist, a direct reclaim, and may then repeat
if the task's allowed set of nodes were concurrently changed.

Do you think it makes sense doing all that after it started failing,
within our single get_pages allocation?

I was thinking about skipping the DIRECT_RECLAIM for high order, but it
seems like that is beneficial for THP, so I'm presuming it should also
be for ourselves. Trimming back max_order seems sensible, but I still
like the idea of taking advantage of contiguous pages where possible
(primarily these will be used for ringbuffers and shadow batches).


Can we agree then to try larger order first and fall back gradually?

Regards,

Tvrtko

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Bump object bookkeeping to u64 from size_t

[Joonas Lahtinen]

On ma, 2016-10-17 at 09:00 +0100, Chris Wilson wrote:
> Internally we allow for using more objects than a single process can
> allocate, i.e. we allow for a 64bit GPU address space even on a 32bit
> system. Using size_t may oveerflow.
> 
> Signed-off-by: Chris Wilson 

How might we get more than size_t passed in? I only notice a single
instance which uses obj.base->size which is size_t.

So I'd not change the function parameters, only the sum. With that;

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Bump object bookkeeping to u64 from size_t

[Chris Wilson]

On Mon, Oct 17, 2016 at 12:48:17PM +0300, Joonas Lahtinen wrote:
> On ma, 2016-10-17 at 09:00 +0100, Chris Wilson wrote:
> > Internally we allow for using more objects than a single process can
> > allocate, i.e. we allow for a 64bit GPU address space even on a 32bit
> > system. Using size_t may oveerflow.
> > 
> > Signed-off-by: Chris Wilson 
> 
> How might we get more than size_t passed in? I only notice a single
> instance which uses obj.base->size which is size_t.
> 
> So I'd not change the function parameters, only the sum. With that;

Our ABI is u64. The values we pass around are u64. Only we chose to use
size_t for the object, go figure.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Fix cxsr_latency_table reorg

[Joonas Lahtinen]

On pe, 2016-10-14 at 14:55 +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> I have re-ordered some struct members in patch:
> 
>   commit 44a655cae3043453f9dd8076538712d52e2e0ce4
> >   Author: Tvrtko Ursulin 
>   Date:   Thu Oct 13 11:09:23 2016 +0100
> 
>   drm/i915: Shrink cxsr_latency_table
> 
> but that particular one is not initialized with named
> initializers which broke it.
> 

Wrong commit message above this line?

Patch itself is;

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] GVT-g device model core

[Daniel Vetter]

On Mon, Oct 17, 2016 at 09:30:45AM +0200, Daniel Vetter wrote:
> On Fri, Oct 14, 2016 at 06:30:30PM +0800, Zhenyu Wang wrote:
> > 
> > Hi,
> > 
> > This is first pull request to merge GVT-g device model in i915
> > which contains core GVT-g device model work to virtualize GPU
> > resources. This tries to add feature of Intel GVT-g technology
> > for full GPU virtualization. This version will support KVM based
> > virtualization solution named as KVMGT.
> > 
> > More background is on official project home: https://01.org/igvt-g
> > 
> > To manage mediated device between virtual GPU and physical device it
> > will rely on VFIO/mdev framework, this version has not included GVT-g
> > device model integration work for VFIO/mdev yet as VFIO community is
> > still under work to refine code base. Currently we're basing on
> > VFIO/mdev v8 patch series (http://www.spinics.net/lists/kvm/msg138515.html)
> > and doing more testings on that.
> > 
> > There're also several KVM change dependences. KVM maintainer has
> > merged two and we will ensure left hits KVM tree before sending new
> > pull request to enable that.
> > 
> > p.s, There would require some coordinate work for VFIO/mdev. We will
> > send device model work for that after Alex merged mdev framework in
> > VFIO tree. Alex has promised to merge that in early of Nov.
> > 
> > Let me know if there's any issue with this our first pull request.
> 
> Ok applied, but a few things to keep in mind before your next pull
> request:
> 
> - Dont rebase everything 5 seconds before sending out the pull request.
>   That just invalidates all the testing you've done, so not a good idea.
>   In general try to avoid rebases as much as possible, and only rebase to
>   take out a truly embarassing mistake. And then only rebase up to the
>   patch that needs a hotfix, not your entire tree.
> 
> - Similar, don't base your pull requests upon a random commit of the day
>   (that's why I noticed you rebased). Instead pick something meaningful,
>   like a tag I (or Dave Airlie or Linus Torvalds) push out. Or another
>   good option is to base it right on top of the last merge commit from
>   gvt. Once you've picked a baseline, don't change it (except when you
>   have a good reason). And if you need a patch from upstream also don't
>   rebase, just send out a pull request with your current patch pile, and
>   then continue applying more stuff on top once I merged that.
> 
> - One technical nit on the integration: My idea was that i915 core code
>   only calls a few specific functions and structures exposed through
>   intel_gvt.h. But that file now seems to include gvt-internal headers,
>   which is a bit a mess. Please clean that up in the next pull request:
> 
>   * Anything that core i915 code or headers needs must be moved into
> intel_gvt.h.
>   * Everything else, including the 2 gvt includes we now have (gvt/gvt.h
> and i915_pvinfo.h) should only be included from code in
> drm/i915/gvt.h. So either sprinkle include directives over your source
> files for everything, or make gvt/gvt.h the main gvt header that pulls
> in everything.
> 
>   The idea here is similar to drm core vs. i915: drm core headers never
>   pull in i915 headers, and all communication happens through the
>   well-defined interfaces in drm core header files. I think our goal with
>   gvt should be similar, with all the interfaces being in intel_gvt.h.
>   Otherwise I fear the submaintainer model will be a bit painful, if we
>   don't aim for strict separation here.
> 
> - There's not yet a MAINTAINERS entry for i915/gvt with gvt mailing lists,
>   git repos and your name on it. Please fix that in the next pull request,
>   too.
> 
> - gvt seems to lack kernel-doc entirely. I think we need at least an
>   overview file and interface documentation for the stuff in
>   intel_gvt.[hc]. Please run
> 
>   $ make hmtldocs
> 
>   to make sure it all looks pretty (you need to add stanzas in
>   Documenation/gpu/i915.rst to include things). Another item for the next
>   pull request please.

Quick addition: Since this will be a patch touching i915 core code pls
submit it to intel-gfx for review. You can then apply it to your tree once
it's reviewed (or Joonas or someone can commit directly to
drm-intel-next-queued).

And another item:
- Please add me to the moderation whitelist of igt-g-dev, I don't want to
  be spammed by moderation mails every time I reply to your pull requests
  ;-)

Cheers, Daniel

> 
> Also, this is the first time ever I've taken a pull request, so some
> learning involved on my side too. Please bear with me ;-)
> 
> Cheers, Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] GVT-g device model core

[Zhenyu Wang]

On 2016.10.17 09:33:19 +0200, Daniel Vetter wrote:
> On Mon, Oct 17, 2016 at 09:30:45AM +0200, Daniel Vetter wrote:
> > On Fri, Oct 14, 2016 at 06:30:30PM +0800, Zhenyu Wang wrote:
> > > 
> > > Hi,
> > > 
> > > This is first pull request to merge GVT-g device model in i915
> > > which contains core GVT-g device model work to virtualize GPU
> > > resources. This tries to add feature of Intel GVT-g technology
> > > for full GPU virtualization. This version will support KVM based
> > > virtualization solution named as KVMGT.
> > > 
> > > More background is on official project home: https://01.org/igvt-g
> > > 
> > > To manage mediated device between virtual GPU and physical device it
> > > will rely on VFIO/mdev framework, this version has not included GVT-g
> > > device model integration work for VFIO/mdev yet as VFIO community is
> > > still under work to refine code base. Currently we're basing on
> > > VFIO/mdev v8 patch series 
> > > (http://www.spinics.net/lists/kvm/msg138515.html)
> > > and doing more testings on that.
> > > 
> > > There're also several KVM change dependences. KVM maintainer has
> > > merged two and we will ensure left hits KVM tree before sending new
> > > pull request to enable that.
> > > 
> > > p.s, There would require some coordinate work for VFIO/mdev. We will
> > > send device model work for that after Alex merged mdev framework in
> > > VFIO tree. Alex has promised to merge that in early of Nov.
> > > 
> > > Let me know if there's any issue with this our first pull request.
> > 
> > Ok applied, but a few things to keep in mind before your next pull
> > request:
> > 
> > - Dont rebase everything 5 seconds before sending out the pull request.
> >   That just invalidates all the testing you've done, so not a good idea.
> >   In general try to avoid rebases as much as possible, and only rebase to
> >   take out a truly embarassing mistake. And then only rebase up to the
> >   patch that needs a hotfix, not your entire tree.
> > 
> > - Similar, don't base your pull requests upon a random commit of the day
> >   (that's why I noticed you rebased). Instead pick something meaningful,
> >   like a tag I (or Dave Airlie or Linus Torvalds) push out. Or another
> >   good option is to base it right on top of the last merge commit from
> >   gvt. Once you've picked a baseline, don't change it (except when you
> >   have a good reason). And if you need a patch from upstream also don't
> >   rebase, just send out a pull request with your current patch pile, and
> >   then continue applying more stuff on top once I merged that.
> >

Sorry for that although we liked to include only core GVT-g device
model in first pull request, we do have continual testing internally
to cover GVT-g features. Will do as you said.

> > - One technical nit on the integration: My idea was that i915 core code
> >   only calls a few specific functions and structures exposed through
> >   intel_gvt.h. But that file now seems to include gvt-internal headers,
> >   which is a bit a mess. Please clean that up in the next pull request:
> > 
> >   * Anything that core i915 code or headers needs must be moved into
> > intel_gvt.h.
> >   * Everything else, including the 2 gvt includes we now have (gvt/gvt.h
> > and i915_pvinfo.h) should only be included from code in
> > drm/i915/gvt.h. So either sprinkle include directives over your source
> > files for everything, or make gvt/gvt.h the main gvt header that pulls
> > in everything.
> > 
> >   The idea here is similar to drm core vs. i915: drm core headers never
> >   pull in i915 headers, and all communication happens through the
> >   well-defined interfaces in drm core header files. I think our goal with
> >   gvt should be similar, with all the interfaces being in intel_gvt.h.
> >   Otherwise I fear the submaintainer model will be a bit painful, if we
> >   don't aim for strict separation here.
> >

yeah, that's a little messy, we will try to clean it up.

> > - There's not yet a MAINTAINERS entry for i915/gvt with gvt mailing lists,
> >   git repos and your name on it. Please fix that in the next pull request,
> >   too.

Will add that.

> > 
> > - gvt seems to lack kernel-doc entirely. I think we need at least an
> >   overview file and interface documentation for the stuff in
> >   intel_gvt.[hc]. Please run
> > 
> > $ make hmtldocs
> > 
> >   to make sure it all looks pretty (you need to add stanzas in
> >   Documenation/gpu/i915.rst to include things). Another item for the next
> >   pull request please.
> 
> Quick addition: Since this will be a patch touching i915 core code pls
> submit it to intel-gfx for review. You can then apply it to your tree once
> it's reviewed (or Joonas or someone can commit directly to
> drm-intel-next-queued).
>

Will fix kernel-doc too.

> And another item:
> - Please add me to the moderation whitelist of igt-g-dev, I don't want to
>   be spammed by moderation mails every time I reply to your pull requests
>   

Re: [Intel-gfx] [PATCH v2 05/10] drm/i915/gen9: Get rid of redundant watermark values

[Maarten Lankhorst]

Op 17-10-16 om 08:05 schreef Daniel Vetter:
> On Thu, Oct 13, 2016 at 05:04:03PM -0300, Paulo Zanoni wrote:
>> Em Qui, 2016-10-13 às 15:39 +0200, Maarten Lankhorst escreveu:
>>> Op 08-10-16 om 02:11 schreef Lyude:
 Now that we've make skl_wm_levels make a little more sense, we can
 remove all of the redundant wm information. Up until now we'd been
 storing two copies of all of the skl watermarks: one being the
 skl_pipe_wm structs, the other being the global wm struct in
 drm_i915_private containing the raw register values. This is
 confusing
 and problematic, since it means we're prone to accidentally letting
 the
 two copies go out of sync. So, get rid of all of the functions
 responsible for computing the register values and just use a single
 helper, skl_write_wm_level(), to convert and write the new
 watermarks on
 the fly.

 Changes since v1:
 - Fixup skl_write_wm_level()
 - Fixup skl_wm_level_from_reg_val()
 - Don't forget to copy *active to intel_crtc->wm.active.skl

 Signed-off-by: Lyude 
 Reviewed-by: Maarten Lankhorst 
 Cc: Ville Syrjälä 
 Cc: Paulo Zanoni 
 ---
  drivers/gpu/drm/i915/i915_drv.h  |   2 -
  drivers/gpu/drm/i915/intel_display.c |  14 ++-
  drivers/gpu/drm/i915/intel_drv.h |   6 +-
  drivers/gpu/drm/i915/intel_pm.c  | 204 ---
 
  drivers/gpu/drm/i915/intel_sprite.c  |   8 +-
  5 files changed, 90 insertions(+), 144 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_drv.h
 b/drivers/gpu/drm/i915/i915_drv.h
 index 0287c93..76583b2 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1644,8 +1644,6 @@ struct skl_ddb_allocation {
  struct skl_wm_values {
unsigned dirty_pipes;
struct skl_ddb_allocation ddb;
 -  uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
 -  uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES];
  };
  
  struct skl_wm_level {
 diff --git a/drivers/gpu/drm/i915/intel_display.c
 b/drivers/gpu/drm/i915/intel_display.c
 index a71d05a..39400a0 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -3378,6 +3378,8 @@ static void
 skylake_update_primary_plane(struct drm_plane *plane,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state-
> base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
const struct skl_wm_values *wm = _priv-
> wm.skl_results;
 +  const struct skl_plane_wm *p_wm =
 +  _state->wm.skl.optimal.planes[0];
int pipe = intel_crtc->pipe;
u32 plane_ctl;
unsigned int rotation = plane_state->base.rotation;
 @@ -3414,7 +3416,7 @@ static void
 skylake_update_primary_plane(struct drm_plane *plane,
intel_crtc->adjusted_y = src_y;
  
if (wm->dirty_pipes & drm_crtc_mask(_crtc->base))
 -  skl_write_plane_wm(intel_crtc, wm, 0);
 +  skl_write_plane_wm(intel_crtc, p_wm, >ddb, 0);
  
I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) | src_x);
 @@ -3448,6 +3450,8 @@ static void
 skylake_disable_primary_plane(struct drm_plane *primary,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 +  struct intel_crtc_state *cstate =
 to_intel_crtc_state(crtc->state);
 +  const struct skl_plane_wm *p_wm = 
> wm.skl.optimal.planes[0];
int pipe = intel_crtc->pipe;
  
/*
 @@ -3455,7 +3459,8 @@ static void
 skylake_disable_primary_plane(struct drm_plane *primary,
 * plane's visiblity isn't actually changing neither is
 its watermarks.
 */
if (!crtc->primary->state->visible)
 -  skl_write_plane_wm(intel_crtc, _priv-
> wm.skl_results, 0);
 +  skl_write_plane_wm(intel_crtc, p_wm,
 + _priv->wm.skl_results.ddb,
 0);
  
I915_WRITE(PLANE_CTL(pipe, 0), 0);
I915_WRITE(PLANE_SURF(pipe, 0), 0);
 @@ -10819,12 +10824,15 @@ static void i9xx_update_cursor(struct
 drm_crtc *crtc, u32 base,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
 +  struct intel_crtc_state *cstate =
 to_intel_crtc_state(crtc->state);
const struct skl_wm_values *wm = _priv-
> wm.skl_results;
 +  const struct skl_plane_wm *p_wm =
 +  >wm.skl.optimal.planes[PLANE_CURSOR];
int pipe = intel_crtc->pipe;
uint32_t cntl = 0;
  
if 

Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

[Ville Syrjälä]

On Fri, Oct 14, 2016 at 08:33:37PM +, Pandiyan, Dhinakaran wrote:
> On Thu, 2016-10-13 at 21:44 +0300, Ville Syrjälä wrote:
> > On Thu, Oct 13, 2016 at 11:04:19AM -0700, Dhinakaran Pandiyan wrote:
> > > According to BSpec, cdclk has to be not less than 432 MHz with DP audio
> > > enabled, port width x4, and link rate HBR2 (5.4 GHz)
> > > 
> > > Having a lower cdclk triggers pipe underruns, which then lead to displays
> > > continuously cycling off and on. This is essential for DP MST audio as the
> > > link is trained at HBR2 and 4 lanes by default.
> > > 
> > > This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907
> > > 
> > > Signed-off-by: Dhinakaran Pandiyan 
> > > ---
> > >  drivers/gpu/drm/i915/intel_display.c | 47 
> > > +---
> > >  1 file changed, 43 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index cfcb03f..6a05183 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -6603,14 +6603,43 @@ static int valleyview_modeset_calc_cdclk(struct 
> > > drm_atomic_state *state)
> > >   return 0;
> > >  }
> > >  
> > > +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state)
> > > +{
> > > +
> > > + struct drm_crtc_state *crtc_state;
> > > + struct drm_crtc *crtc;
> > > + int i;
> > > +
> > > + /* BSpec says "Do not use DisplayPort with CDCLK less than 432 MHz,
> > > +  * audio enabled, port width x4, and link rate HBR2 (5.4 GHz), or else
> > > +  * there may be audio corruption or screen corruption."
> > > +  */
> > > +
> > > + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > > + struct intel_crtc_state *pipe_config =
> > > + to_intel_crtc_state(crtc_state);
> > > +
> > > + return (intel_crtc_has_dp_encoder(pipe_config) &&
> > > + pipe_config->has_audio &&
> > > + pipe_config->port_clock == 54 &&
> > > + pipe_config->lane_count == 4);
> > > + }
> > 
> > That's not good enough on account of crtcs not part of the state
> > potentially needing the workaround as well. However, since we only do
> > this when there's a modeset, I think we'll be covered by the
> > connection_mutex, and so we should be able to peek at the current state
> > of all crtcs without grabbing the corresponding crtc locks.
> > 
> 
> Please correct me if I am wrong. Won't the first modeset that has all
> the conditions met (DP + HBR2 + 4 lanes + audio) include the crtc
> driving the display which triggered the modeset?
> 
> Since, the new cdclk freq that will be set is common for all the crtcs,
> we don't need the workaround for crtcs that are not in state. 

There can be another modeset afterwards that doesn't need the w/a and
that would then end up reducing cdclk below the required frequency.

> 
> > So I think we'd be OK with something like:
> > 
> > WARN_ON(!locked(connection_mutex));
> > 
> > for_each_intel_crtc() {
> > /*
> >  * Peeking at the current state is safe since
> >  * we can only get here while holding the
> >  * connection_mutex.
> >  */
> > crtc_state = intel_get_existing_crtc_state();
> > if (!crtc_state)
> > crtc_state = to_intel_crtc_state(crtc->base.state);
> > 
> > ...
> > }
> > 
> > The other option would be to track the min cdclk for each pipe in the
> > top level state I suppose. We already do that for the pixel rate
> > actually so that we can calculate the cdclk to begin with. Hmm. Maybe
> > we should just switch to tracking the min cdclk per pipe instead of the
> > pixel rate. Or did we need to the pixel rate itself for something else,
> > Maarten?
> > 
> > Or we could perhaps replace the pixel rate/pixclk tracking with the peek
> > approach entirely. Not quite sure. Would have to read the entire thing
> > through.
> > 
> 
> I thought of this, but the work around applies for only three platforms
> (potentially just two) as of now. Does it warrant a driver wide change?
> I have to check if mincdclk is useful elsewhere.

We need to do one of these options. No way around it if we need this
w/a. Though I guess it's a little bit of an open question at the moment
since on SKL it only supposedly applies up to D stepping which we don't
care about. On BDW it seems to be for everything though.

> 
> > > +
> > > + return false;
> > > +}
> > > +
> > >  static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state)
> > >  {
> > >   int max_pixclk = ilk_max_pixel_rate(state);
> > > + int cdclk, min_cdclk = 0;
> > >   struct intel_atomic_state *intel_state =
> > >   to_intel_atomic_state(state);
> > >  
> > > - intel_state->cdclk = intel_state->dev_cdclk =
> > > - bxt_calc_cdclk(max_pixclk);
> > > + if (cdclk_min_for_dp_audio(state))
> > > + min_cdclk = bxt_calc_cdclk(432000);
> > > +
> > > + cdclk = 

Re: [Intel-gfx] [PATCH 14/41] drm/i915: Use a radixtree for random access to the object's backing storage

[Tvrtko Ursulin]

On 14/10/2016 15:07, Chris Wilson wrote:

On Fri, Oct 14, 2016 at 02:32:03PM +0100, Tvrtko Ursulin wrote:

On 14/10/2016 13:18, Chris Wilson wrote:

A while ago we switched from a contiguous array of pages into an sglist,
for that was both more convenient for mapping to hardware and avoided
the requirement for a vmalloc array of pages on every object. However,
certain GEM API calls (like pwrite, pread as well as performing
relocations) do desire access to individual struct pages. A quick hack
was to introduce a cache of the last access such that finding the
following page was quick - this works so long as the caller desired
sequential access. Walking backwards, or multiple callers, still hits a
slow linear search for each page. One solution is to store each
successful lookup in a radix tree.

v2: Rewrite building the radixtree for clarity, hopefully.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_drv.h |  69 +---
  drivers/gpu/drm/i915/i915_gem.c | 179 +---
  drivers/gpu/drm/i915/i915_gem_stolen.c  |   4 +-
  drivers/gpu/drm/i915/i915_gem_userptr.c |   4 +-
  4 files changed, 193 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 38467dde1efe..53cf4b0e5359 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2273,9 +2273,12 @@ struct drm_i915_gem_object {
struct sg_table *pages;
int pages_pin_count;
-   struct get_page {
-   struct scatterlist *sg;
-   int last;
+   struct i915_gem_object_page_iter {
+   struct scatterlist *sg_pos;
+   unsigned long sg_idx;

We are not consistent in the code with type used for number of pages
in an object. sg_alloc_table even takes an unsigned int for it, so
for as long as we build them as we do, unsigned long is a waste.

I know. It's worrying, today there is a possibility that we overflow a
32bit size. If this was counting in pages, we would have a few more
years of grace. All I can say is that we are fortunate that memory
remains expensive in the exabyte range.


@@ -4338,6 +4349,8 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj,
obj->frontbuffer_ggtt_origin = ORIGIN_GTT;
obj->madv = I915_MADV_WILLNEED;
+   INIT_RADIX_TREE(>get_page.radix, GFP_ATOMIC | __GFP_NOWARN);

Pros & cons of GFP_ATOMIC here? Versus perhaps going with the mutex?
I don't know how much data radix tree allocates with this, per node,
but we can have a lot of pages. Would this create extra pressure on
slab shrinking, and in turn out objects?

The problem is that we require sg lookup on a !pagefault path, hence
mutexes and GFP_KERNEL turn out to be illegal. :|


Bummer.  I don't know enough about the atomic reserve to judge how bad 
this might be then. Because userspace could drain it easily after this 
work by just pread/pwrite on large objects.



+   /* If we cannot allocate and insert this entry, or the
+* individual pages from this range, cancel updating the
+* sg_idx so that on this lookup we are forced to linearly
+* scan onwards, but on future lookups we will try the
+* insertion again (in which case we need to be careful of
+* the error return reporting that we have already inserted
+* this index).
+*/
+   ret = radix_tree_insert(>radix, idx, sg);
+   if (ret && ret != -EEXIST)
+   goto scan;

What other error can we get here? Internal allocation failure?

Yes. ENOMEM is the only other error.

+
+   exception =
+   RADIX_TREE_EXCEPTIONAL_ENTRY |
+   idx << RADIX_TREE_EXCEPTIONAL_SHIFT;
+   for (i = 1; i < count; i++) {
+   ret = radix_tree_insert(>radix, idx + i,
+   (void *)exception);
+   if (ret && ret != -EEXIST)
+   goto scan;
+   }
+
+   idx += count;
+   sg = sg_next(sg);
+   count = __sg_page_count(sg);
+   }
+
+scan:
+   iter->sg_pos = sg;
+   iter->sg_idx = idx;
+
+   spin_unlock(>lock);
+
+   if (unlikely(n < idx)) /* insertion completed by another thread */
+   goto lookup;
+
+   /* In case we failed to insert the entry into the radixtree, we need
+* to look beyond the current sg.
+*/
+   while (idx + count <= n) {
+   idx += count;
+   sg = sg_next(sg);
+   count = __sg_page_count(sg);
+   }
+

Hmm... I assume failures happen then since you added this fallback.
Due GFP_ATOMIC?

No, this was always in the code, because malloc failures happen. Quite
often if you run igt ;)
  


But GFP_ATOMIC failures 

Re: [Intel-gfx] [PATCH 8/8] drm/i915/get_params: Add HuC status to getparams

[Daniel Vetter]

On Thu, Oct 13, 2016 at 02:47:32PM -0700, Jeff McGee wrote:
> On Mon, Oct 03, 2016 at 11:43:02AM -0700, Anusha Srivatsa wrote:
> > From: Peter Antoine 
> > 
> > This patch will allow for getparams to return the status of the HuC.
> > As the HuC has to be validated by the GuC this patch uses the validated
> > status to show when the HuC is loaded and ready for use. You cannot use
> > the loaded status as with the GuC as the HuC is verified after it is
> > loaded and is not usable until it is verified.
> > 
> > v2: removed the forewakes as the registers are already force-woken.
> >  (T.Ursulin)
> > v4: rebased.
> > v5: rebased.
> > 
> > Tested-by: Xiang Haihao 
> > Signed-off-by: Anusha Srivatsa 
> > Signed-off-by: Peter Antoine 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.c |  4 
> >  drivers/gpu/drm/i915/intel_huc.h|  2 +-
> >  drivers/gpu/drm/i915/intel_huc_loader.c | 14 ++
> >  include/uapi/drm/i915_drm.h |  1 +
> >  4 files changed, 20 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index ff1c18d..0d7b290 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -49,6 +49,7 @@
> >  #include "i915_trace.h"
> >  #include "i915_vgpu.h"
> >  #include "intel_drv.h"
> > +#include "intel_huc.h"
> >  #include "intel_guc.h"
> >  
> >  static struct drm_driver driver;
> > @@ -343,6 +344,9 @@ static int i915_getparam(struct drm_device *dev, void 
> > *data,
> > case I915_PARAM_HAS_GUC:
> > value = intel_is_guc_valid(dev_priv);
> > break;
> > +   case I915_PARAM_HAS_HUC:
> > +   value = intel_is_huc_valid(dev_priv);
> > +   break;
> > default:
> > DRM_DEBUG("Unknown parameter %d\n", param->param);
> > return -EINVAL;
> > diff --git a/drivers/gpu/drm/i915/intel_huc.h 
> > b/drivers/gpu/drm/i915/intel_huc.h
> > index 946caa7..5eac625 100644
> > --- a/drivers/gpu/drm/i915/intel_huc.h
> > +++ b/drivers/gpu/drm/i915/intel_huc.h
> > @@ -40,5 +40,5 @@ extern void intel_huc_init(struct drm_device *dev);
> >  extern int intel_huc_load(struct drm_device *dev);
> >  extern void intel_huc_auth(struct drm_device *dev);
> >  extern void intel_huc_fini(struct drm_device *dev);
> > -
> > +extern int intel_is_huc_valid(struct drm_i915_private *dev_priv);
> >  #endif
> > diff --git a/drivers/gpu/drm/i915/intel_huc_loader.c 
> > b/drivers/gpu/drm/i915/intel_huc_loader.c
> > index 87a6948..d574183 100644
> > --- a/drivers/gpu/drm/i915/intel_huc_loader.c
> > +++ b/drivers/gpu/drm/i915/intel_huc_loader.c
> > @@ -273,3 +273,17 @@ void intel_huc_fini(struct drm_device *dev)
> >  
> > huc_fw->fetch_status = UC_FIRMWARE_NONE;
> >  }
> > +
> > +/**
> > + * intel_is_huc_valid() - Check to see if the HuC is fully loaded.
> > + * @dev_priv:  drm device to check.
> > + *
> > + * This function will return true if the guc has been loaded and
> > + * has valid firmware. The simplest way of doing this is to check
> > + * if the HuC has been validated, if so it must have been loaded.
> > + */
> > +int intel_is_huc_valid(struct drm_i915_private *dev_priv)
> I'm still unclear on the 'intel' vs. 'i915' prefix usage. But it seems
> that intel prefixed functions accept drm_device instead of drm_i915_private.

intel_ is core and modeset, i915_ is gem stuff. mostly. Absolutely nothing
to do with drm_device vs. drm_i915_private, that should only be a question
of whether it's a drm vfunc or an internal one (we're transitioning to
that pattern, so atm it's a bit a mess).

> Also, need to see the userspace usage of this new GETPARAM.

+1 ;-)

Cheers, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/8] drm/i915/get_params: Add GuC status to getparams

[Daniel Vetter]

On Thu, Oct 13, 2016 at 02:42:46PM -0700, Jeff McGee wrote:
> On Fri, Oct 07, 2016 at 09:11:03AM +0200, Daniel Vetter wrote:
> > On Wed, Oct 05, 2016 at 01:51:14PM -0700, Rodrigo Vivi wrote:
> > > 
> > > 
> > > Reviewed-by: Rodrigo Vivi 
> > 
> > This is new uabi. Where's the userspace?
> > 
> > Checking this is part of the review.
> > -Daniel
> > 
> I'm not sure that GuC status is strictly needed by userspace. No
> direct dependencies that I am aware of. HuC status is needed and that
> is the subsequent patch.

I'd say we drop this one then.
-Daniel

> -Jeff
> 
> > > 
> > > On Mon, Oct 03, 2016 at 11:43:01AM -0700, Anusha Srivatsa wrote:
> > > > From: Peter Antoine 
> > > > 
> > > > This patch returns the GuC status to the caller. It is used so
> > > > that the userspace knows if the GuC has been loaded.
> > > > 
> > > > v4: rebase.
> > > > v5: rebased.
> > > > 
> > > > Signed-off-by: Anusha Srivatsa 
> > > > Signed-off-by: Peter Antoine 
> > > > ---
> > > >  drivers/gpu/drm/i915/i915_drv.c |  4 
> > > >  drivers/gpu/drm/i915/intel_guc.h|  2 +-
> > > >  drivers/gpu/drm/i915/intel_guc_loader.c | 18 ++
> > > >  include/uapi/drm/i915_drm.h |  1 +
> > > >  4 files changed, 24 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.c 
> > > > b/drivers/gpu/drm/i915/i915_drv.c
> > > > index 7af7bd6..ff1c18d 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.c
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > > > @@ -49,6 +49,7 @@
> > > >  #include "i915_trace.h"
> > > >  #include "i915_vgpu.h"
> > > >  #include "intel_drv.h"
> > > > +#include "intel_guc.h"
> > > >  
> > > >  static struct drm_driver driver;
> > > >  
> > > > @@ -339,6 +340,9 @@ static int i915_getparam(struct drm_device *dev, 
> > > > void *data,
> > > >  */
> > > > value = 1;
> > > > break;
> > > > +   case I915_PARAM_HAS_GUC:
> > > > +   value = intel_is_guc_valid(dev_priv);
> > > > +   break;
> > > > default:
> > > > DRM_DEBUG("Unknown parameter %d\n", param->param);
> > > > return -EINVAL;
> > > > diff --git a/drivers/gpu/drm/i915/intel_guc.h 
> > > > b/drivers/gpu/drm/i915/intel_guc.h
> > > > index af76ffe..3a7fa7e 100644
> > > > --- a/drivers/gpu/drm/i915/intel_guc.h
> > > > +++ b/drivers/gpu/drm/i915/intel_guc.h
> > > > @@ -168,5 +168,5 @@ int i915_guc_submission_enable(struct 
> > > > drm_i915_private *dev_priv);
> > > >  int i915_guc_wq_reserve(struct drm_i915_gem_request *rq);
> > > >  void i915_guc_submission_disable(struct drm_i915_private *dev_priv);
> > > >  void i915_guc_submission_fini(struct drm_i915_private *dev_priv);
> > > > -
> > > > +int intel_is_guc_valid(struct drm_i915_private *dev_priv);
> > > >  #endif
> > > > diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
> > > > b/drivers/gpu/drm/i915/intel_guc_loader.c
> > > > index 31a2b0a..5d2a703 100644
> > > > --- a/drivers/gpu/drm/i915/intel_guc_loader.c
> > > > +++ b/drivers/gpu/drm/i915/intel_guc_loader.c
> > > > @@ -801,3 +801,21 @@ void intel_guc_fini(struct drm_device *dev)
> > > >  
> > > > guc_fw->fetch_status = UC_FIRMWARE_NONE;
> > > >  }
> > > > +
> > > > +/**
> > > > + * intel_is_guc_valid() - Check to see if the GuC is fully loaded.
> > > > + * @dev:   drm dedvice to check.
> > > > + *
> > > > + * This function will return true if the guc has been loaded and
> > > > + * has valid firmware.
> > > > + */
> > > > +int intel_is_guc_valid(struct drm_i915_private *dev_priv)
> > > > +{
> > > > +   struct intel_uc_fw *guc_fw = _priv->guc.guc_fw;
> > > > +
> > > > +   if (guc_fw->load_status == UC_FIRMWARE_SUCCESS)
> > > > +   return 1;
> > > > +   else
> > > > +   return 0;
> > > > +}
> > > > +
> > > > diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> > > > index 03725fe..629fb5e 100644
> > > > --- a/include/uapi/drm/i915_drm.h
> > > > +++ b/include/uapi/drm/i915_drm.h
> > > > @@ -388,6 +388,7 @@ typedef struct drm_i915_irq_wait {
> > > >  #define I915_PARAM_HAS_POOLED_EU38
> > > >  #define I915_PARAM_MIN_EU_IN_POOL   39
> > > >  #define I915_PARAM_MMAP_GTT_VERSION 40
> > > > +#define I915_PARAM_HAS_GUC  41
> > > >  
> > > >  typedef struct drm_i915_getparam {
> > > > __s32 param;
> > > > -- 
> > > > 2.7.4
> > > > 
> > > > ___
> > > > 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
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > 

Re: [Intel-gfx] 4.9-r1: gpu hangs after hibernation

[Jani Nikula]

On Sun, 16 Oct 2016, zieg...@uni-freiburg.de wrote:
> If I hibernate from the console, thaw, and switch between the console
> and X, the gpu hangs itself. The machine becomes unresponsive except
> for the power button.

Please file a bug at [1], and attach the error state there.

Thanks,
Jani.


[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI=DRM/Intel


-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 1/3] drm/i915: Bump object bookkeeping to u64 from size_t

[Chris Wilson]

Internally we allow for using more objects than a single process can
allocate, i.e. we allow for a 64bit GPU address space even on a 32bit
system. Using size_t may oveerflow.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
 drivers/gpu/drm/i915/i915_drv.h | 2 +-
 drivers/gpu/drm/i915/i915_gem.c | 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 515c206ba653..dc057c770146 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -392,7 +392,7 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
if (ret)
return ret;
 
-   seq_printf(m, "%u objects, %zu bytes\n",
+   seq_printf(m, "%u objects, %llu bytes\n",
   dev_priv->mm.object_count,
   dev_priv->mm.object_memory);
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4d1133ffe093..092c5a0a44f0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1389,7 +1389,7 @@ struct i915_gem_mm {
 
/* accounting, useful for userland debugging */
spinlock_t object_stat_lock;
-   size_t object_memory;
+   u64 object_memory;
u32 object_count;
 };
 
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index fe92e28ea0a8..838dc159a2d1 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -82,7 +82,7 @@ remove_mappable_node(struct drm_mm_node *node)
 
 /* some bookkeeping */
 static void i915_gem_info_add_obj(struct drm_i915_private *dev_priv,
- size_t size)
+ u64 size)
 {
spin_lock(_priv->mm.object_stat_lock);
dev_priv->mm.object_count++;
@@ -91,7 +91,7 @@ static void i915_gem_info_add_obj(struct drm_i915_private 
*dev_priv,
 }
 
 static void i915_gem_info_remove_obj(struct drm_i915_private *dev_priv,
-size_t size)
+u64 size)
 {
spin_lock(_priv->mm.object_stat_lock);
dev_priv->mm.object_count--;
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 2/3] drm/i915: Document our internal limit on object size

[Chris Wilson]

In many places, we try to count pages using a 32 bit integer. That
implies if we are asked to create an object larger than 43bits, we will
subtly crash much later. Catch this on the boundary, and add a warning
to remind ourselves later on our exabyte systems.

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_drv.h |  2 +-
 drivers/gpu/drm/i915/i915_gem.c | 17 +++--
 2 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 092c5a0a44f0..a2b5fc72fdd9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3105,7 +3105,7 @@ void i915_gem_object_free(struct drm_i915_gem_object 
*obj);
 void i915_gem_object_init(struct drm_i915_gem_object *obj,
 const struct drm_i915_gem_object_ops *ops);
 struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
- size_t size);
+  u64 size);
 struct drm_i915_gem_object *i915_gem_object_create_from_data(
struct drm_device *dev, const void *data, size_t size);
 void i915_gem_close_object(struct drm_gem_object *gem, struct drm_file *file);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 838dc159a2d1..181bda2db587 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4131,14 +4131,27 @@ static const struct drm_i915_gem_object_ops 
i915_gem_object_ops = {
.put_pages = i915_gem_object_put_pages_gtt,
 };
 
-struct drm_i915_gem_object *i915_gem_object_create(struct drm_device *dev,
- size_t size)
+#define overflows_type(x, T) \
+   (sizeof(x) > sizeof(T) && (x) >> (sizeof(T) * BITS_PER_BYTE))
+
+struct drm_i915_gem_object *
+i915_gem_object_create(struct drm_device *dev, u64 size)
 {
struct drm_i915_gem_object *obj;
struct address_space *mapping;
gfp_t mask;
int ret;
 
+   /* There is a prevalence of the assumption that we fit the object's
+* page count inside a 32bit variable. Let's document this and catch
+* if we ever need to fix it.
+*/
+   if (WARN_ON(size >> PAGE_SHIFT > INT_MAX))
+   return ERR_PTR(-E2BIG);
+
+   if (overflows_type(size, obj->base.size))
+   return ERR_PTR(-E2BIG);
+
obj = i915_gem_object_alloc(dev);
if (obj == NULL)
return ERR_PTR(-ENOMEM);
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 3/3] drm/i915: Limit the scattergather coalescing to 32bits

[Chris Wilson]

The scattergather list uses a 32bit size counter, we should avoid
exceeding it.

v2: Also we should use unsigned int to match sg->length.

Fixes: 871dfbd67d4e ("drm/i915: Allow compaction upto SWIOTLB max segment size")
Signed-off-by: Chris Wilson 
Reviewed-by: Tvrtko Ursulin  # v1
---
 drivers/gpu/drm/i915/i915_gem.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 181bda2db587..a74ec10a5370 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2205,7 +2205,7 @@ i915_gem_object_put_pages(struct drm_i915_gem_object *obj)
return 0;
 }
 
-static unsigned long swiotlb_max_size(void)
+static unsigned int swiotlb_max_size(void)
 {
 #if IS_ENABLED(CONFIG_SWIOTLB)
return rounddown(swiotlb_nr_tbl() << IO_TLB_SHIFT, PAGE_SIZE);
@@ -2225,7 +2225,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
struct sgt_iter sgt_iter;
struct page *page;
unsigned long last_pfn = 0; /* suppress gcc warning */
-   unsigned long max_segment;
+   unsigned int max_segment;
int ret;
gfp_t gfp;
 
@@ -2238,7 +2238,7 @@ i915_gem_object_get_pages_gtt(struct drm_i915_gem_object 
*obj)
 
max_segment = swiotlb_max_size();
if (!max_segment)
-   max_segment = obj->base.size;
+   max_segment = rounddown(UINT_MAX, PAGE_SIZE);
 
st = kmalloc(sizeof(*st), GFP_KERNEL);
if (st == NULL)
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/dp: Increase cdclk when DP audio is enabled with 4 lanes and HBR2

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 08:55:51AM +0200, Daniel Vetter wrote:
> On Fri, Oct 14, 2016 at 07:27:39PM +, Pandiyan, Dhinakaran wrote:
> > On Thu, 2016-10-13 at 11:30 -0700, Jim Bride wrote:
> > > On Thu, Oct 13, 2016 at 11:04:19AM -0700, Dhinakaran Pandiyan wrote:
> > > > According to BSpec, cdclk has to be not less than 432 MHz with DP audio
> > > > enabled, port width x4, and link rate HBR2 (5.4 GHz)
> > > > 
> > > > Having a lower cdclk triggers pipe underruns, which then lead to 
> > > > displays
> > > > continuously cycling off and on. This is essential for DP MST audio as 
> > > > the
> > > > link is trained at HBR2 and 4 lanes by default.
> > > > 
> > > > This should fix https://bugs.freedesktop.org/show_bug.cgi?id=97907
> > > > 
> > > > Signed-off-by: Dhinakaran Pandiyan 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_display.c | 47 
> > > > +---
> > > >  1 file changed, 43 insertions(+), 4 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index cfcb03f..6a05183 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -6603,14 +6603,43 @@ static int valleyview_modeset_calc_cdclk(struct 
> > > > drm_atomic_state *state)
> > > > return 0;
> > > >  }
> > > >  
> > > > +static bool cdclk_min_for_dp_audio(struct drm_atomic_state *state)
> > > > +{
> > > > +
> > > > +   struct drm_crtc_state *crtc_state;
> > > > +   struct drm_crtc *crtc;
> > > > +   int i;
> > > > +
> > > > +   /* BSpec says "Do not use DisplayPort with CDCLK less than 432 
> > > > MHz,
> > > > +* audio enabled, port width x4, and link rate HBR2 (5.4 GHz), 
> > > > or else
> > > > +* there may be audio corruption or screen corruption."
> > > > +*/
> > > 
> > > It's probably worth mentioning that this limitation really only applies 
> > > for
> > > SKL (at least that I can see) and BXT A (which I don't think we even care
> > > about anymore since it's not a production part.)  Were we seeing underruns
> > > on non-SKL platforms that increasing CDCLK fixed?   In any event, I'd 
> > > rather
> > > see this only implemented for SKL (see BDW code below) unless we've 
> > > empirically
> > > noticed a similar problem on BDW (or the B-Spec says something about this 
> > > and I
> > > missed it.)
> > > 
> > > Jim
> > > 
> > > 
> > Yes, Libin saw the problem when testing a BDW NUC. And, the patch is
> > applicable to BDW according to the BSpec. I will try to get a
> > confirmation on whether this is needed BXT production parts.
> 
> Please also check docs for hsw, that's where dp mst support started.

s/mst/hbr2/, otherwise we've veering off topic.

Not applicable to HSW, at least directly, since we don't support changing
cdclk there. Only HSW-ULX has cdclk below this limit, and that can't do
HBR2 anyway. But it's best to double check anyway, in case there are
other related limits on HSW.

> -Daniel
> 
> > 
> > > > +
> > > > +   for_each_crtc_in_state(state, crtc, crtc_state, i) {
> > > > +   struct intel_crtc_state *pipe_config =
> > > > +   to_intel_crtc_state(crtc_state);
> > > > +
> > > > +   return (intel_crtc_has_dp_encoder(pipe_config) &&
> > > > +   pipe_config->has_audio &&
> > > > +   pipe_config->port_clock == 54 &&
> > > > +   pipe_config->lane_count == 4);
> > > > +   }
> > > > +
> > > > +   return false;
> > > > +}
> > > > +
> > > >  static int bxt_modeset_calc_cdclk(struct drm_atomic_state *state)
> > > >  {
> > > > int max_pixclk = ilk_max_pixel_rate(state);
> > > > +   int cdclk, min_cdclk = 0;
> > > > struct intel_atomic_state *intel_state =
> > > > to_intel_atomic_state(state);
> > > >  
> > > > -   intel_state->cdclk = intel_state->dev_cdclk =
> > > > -   bxt_calc_cdclk(max_pixclk);
> > > > +   if (cdclk_min_for_dp_audio(state))
> > > > +   min_cdclk = bxt_calc_cdclk(432000);
> > > > +
> > > > +   cdclk = bxt_calc_cdclk(max_pixclk);
> > > > +   intel_state->cdclk = intel_state->dev_cdclk = max(min_cdclk, 
> > > > cdclk);
> > > >  
> > > > if (!intel_state->active_crtcs)
> > > > intel_state->dev_cdclk = bxt_calc_cdclk(0);
> > > > @@ -10374,7 +10403,10 @@ static int broadwell_modeset_calc_cdclk(struct 
> > > > drm_atomic_state *state)
> > > > struct drm_i915_private *dev_priv = to_i915(state->dev);
> > > > struct intel_atomic_state *intel_state = 
> > > > to_intel_atomic_state(state);
> > > > int max_pixclk = ilk_max_pixel_rate(state);
> > > > -   int cdclk;
> > > > +   int cdclk, min_cdclk = 0;
> > > > +
> > > > +   if (cdclk_min_for_dp_audio(state))
> > > > +   min_cdclk = broadwell_calc_cdclk(432000);
> > 

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v2,1/3] drm/i915: Bump object bookkeeping to u64 from size_t

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/3] drm/i915: Bump object bookkeeping to u64 
from size_t
URL   : https://patchwork.freedesktop.org/series/13853/
State : warning

== Summary ==

Series 13853v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/13853/revisions/1/mbox/

Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-skl-6770hq)
pass   -> SKIP   (fi-hsw-4770)

fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:246  pass:212  dwarn:2   dfail:0   fail:1   skip:31 
fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14 
fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 

Results at /archive/results/CI_IGT_test/Patchwork_2733/

15dfed2b90e84e7c277f81842fc3f19355293061 drm-intel-nightly: 
2016y-10m-16d-23h-15m-00s UTC integration manifest
f67f72a drm/i915: Limit the scattergather coalescing to 32bits
21a9dbe drm/i915: Document our internal limit on object size
f70eb45 drm/i915: Bump object bookkeeping to u64 from size_t

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t] intel-ci: Reorder tests to have vgem-basic@unload tested first

[Petri Latvala]

Signed-off-by: Petri Latvala 
CC: Chris Wilson 
---

(Possible duplicate, I didn't see this arrive on the mailing list myself)

To match Chris's intention.

The test itself will receive fixes later, and another module loading
test will be added at the end. This change is just for mitigation.



tests/intel-ci/fast-feedback.testlist | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/intel-ci/fast-feedback.testlist 
b/tests/intel-ci/fast-feedback.testlist
index f59ec98..711245b 100644
--- a/tests/intel-ci/fast-feedback.testlist
+++ b/tests/intel-ci/fast-feedback.testlist
@@ -1,3 +1,4 @@
+igt@vgem_basic@unload
 igt@core_auth@basic-auth
 igt@core_prop_blob@basic
 igt@drv_getparams_basic@basic-eu-total
@@ -243,4 +244,3 @@ igt@vgem_basic@dmabuf-mmap
 igt@vgem_basic@mmap
 igt@vgem_basic@second-client
 igt@vgem_basic@sysfs
-igt@vgem_basic@unload
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] linux-next: build failure after merge of the drm-intel tree

[Stephen Rothwell]

j->base));
  ^
In file included from drivers/gpu/drm/i915/gvt/execlist.c:35:0:
drivers/gpu/drm/i915/i915_drv.h:2344:13: note: declared here
 extern void drm_gem_object_unreference(struct drm_gem_object *);
 ^
drivers/gpu/drm/i915/gvt/execlist.c: In function 'init_vgpu_execlist':
drivers/gpu/drm/i915/gvt/execlist.c:42:33: error: request for member 
'mmio_base' in something not a structure or union
  (gvt->dev_priv->engine[ring_id].mmio_base + (offset))
 ^
drivers/gpu/drm/i915/gvt/execlist.c:248:19: note: in expansi
on of macro 'execlist_ring_mmio'
  u32 status_reg = execlist_ring_mmio(vgpu->gvt, ring_id,
   ^
drivers/gpu/drm/i915/gvt/execlist.c: In function 'release_sh
adow_batch_buffer':
drivers/gpu/drm/i915/gvt/execlist.c:501:4: warning: 'drm_gem
_object_unreference' is deprecated [-Wdeprecated-declarations]
drm_gem_object_unreference(&(entry_obj->obj->base));
^
In file included from drivers/gpu/drm/i915/gvt/execlist.c:35
:0:
drivers/gpu/drm/i915/i915_drv.h:2344:13: note: declared here
 extern void drm_gem_object_unreference(struct drm_gem_object *);
 ^
drivers/gpu/drm/i915/gvt/execlist.c: In function 'release_sh
adow_wa_ctx':
drivers/gpu/drm/i915/gvt/execlist.c:514:2: warning: 
'drm_gem_object_unreference' is deprecated [-Wdeprecated-declarations]
  drm_gem_object_unreference(&(wa_ctx->indirect_ctx.obj->base));
  ^
In file included from drivers/gpu/drm/i915/gvt/execlist.c:35:0:
drivers/gpu/drm/i915/i915_drv.h:2344:13: note: declared here
 extern void drm_gem_object_unreference(struct drm_gem_object *);
 ^
drivers/gpu/drm/i915/gvt/execlist.c: In function 'init_vgpu_execlist':
drivers/gpu/drm/i915/gvt/execlist.c:42:33: error: request for member 
'mmio_base' in something not a structure or union
  (gvt->dev_priv->engine[ring_id].mmio_base + (offset))
 ^
drivers/gpu/drm/i915/gvt/execlist.c:798:23: note: in expansion of macro 
'execlist_ring_mmio'
  ctx_status_ptr_reg = execlist_ring_mmio(vgpu->gvt, ring_id,
   ^

Caused by commit

  3b3f1650b1ca ("drm/i915: Allocate intel_engine_cs structure only for the 
enabled engines")

interacting with some other commits that were merged without fixes being 
applied (probably) in commit

  06a75ace46e2 ("Merge tag 'gvt-next-2016-10-14' of 
https://github.com/01org/gvt-linux into drm-intel-next-queued")

I have used the version of the drm-intel tree from next-20161017 for
today.

-- 
Cheers,
Stephen Rothwell
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: KBL - Recommended buffer translation programming for DisplayPort

[Manasi Navare]

On Thu, Oct 06, 2016 at 10:54:01AM -0700, Rodrigo Vivi wrote:
> According to spec: "KBL re-uses SKL values, except where
> specific KBL values are listed."
> 
> And recently spec has changed adding different table for Display Port only.
> But for all SKUs (H,S,U,Y) we have slightly different values.
> 
> v2: Fix wrong condition spotted by Jani.
> 
> Cc: Jani Nikula 
> Cc: Manasi Navare 
> Signed-off-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_ddi.c | 88 
> +++-
>  1 file changed, 78 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 35f0b7c..195aa70 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -167,8 +167,47 @@ static const struct ddi_buf_trans 
> skl_y_ddi_translations_dp[] = {
>   { 0x80005012, 0x00C0, 0x3 },
>  };
>  
> +/* Kabylake H and S */
> +static const struct ddi_buf_trans kbl_ddi_translations_dp[] = {
> + { 0x2016, 0x00A0, 0x0 },
> + { 0x5012, 0x009B, 0x0 },
> + { 0x7011, 0x0088, 0x0 },
> + { 0x80009010, 0x00C0, 0x1 },
> + { 0x2016, 0x009B, 0x0 },
> + { 0x5012, 0x0088, 0x0 },
> + { 0x80007011, 0x00C0, 0x1 },
> + { 0x2016, 0x009F, 0x0 },

This entry according to the Bspec should be 0x2016, 0x0097, 0x0

Manasi


> + { 0x80005012, 0x00C0, 0x1 },
> +};
> +
> +/* Kabylake U */
> +static const struct ddi_buf_trans kbl_u_ddi_translations_dp[] = {
> + { 0x201B, 0x00A1, 0x0 },
> + { 0x5012, 0x0088, 0x0 },
> + { 0x80007011, 0x00CD, 0x3 },
> + { 0x80009010, 0x00C0, 0x3 },
> + { 0x201B, 0x009D, 0x0 },
> + { 0x80005012, 0x00C0, 0x3 },
> + { 0x80007011, 0x00C0, 0x3 },
> + { 0x2016, 0x004F, 0x0 },
> + { 0x80005012, 0x00C0, 0x3 },
> +};
> +
> +/* Kabylake Y */
> +static const struct ddi_buf_trans kbl_y_ddi_translations_dp[] = {
> + { 0x1017, 0x00A1, 0x0 },
> + { 0x5012, 0x0088, 0x0 },
> + { 0x80007011, 0x00CD, 0x3 },
> + { 0x8000800F, 0x00C0, 0x3 },
> + { 0x1017, 0x009D, 0x0 },
> + { 0x80005012, 0x00C0, 0x3 },
> + { 0x80007011, 0x00C0, 0x3 },
> + { 0x1017, 0x004C, 0x0 },
> + { 0x80005012, 0x00C0, 0x3 },
> +};
> +
>  /*
> - * Skylake H and S
> + * Skylake/Kabylake H and S
>   * eDP 1.4 low vswing translation parameters
>   */
>  static const struct ddi_buf_trans skl_ddi_translations_edp[] = {
> @@ -185,7 +224,7 @@ static const struct ddi_buf_trans 
> skl_ddi_translations_edp[] = {
>  };
>  
>  /*
> - * Skylake U
> + * Skylake/Kabylake U
>   * eDP 1.4 low vswing translation parameters
>   */
>  static const struct ddi_buf_trans skl_u_ddi_translations_edp[] = {
> @@ -202,7 +241,7 @@ static const struct ddi_buf_trans 
> skl_u_ddi_translations_edp[] = {
>  };
>  
>  /*
> - * Skylake Y
> + * Skylake/Kabylake Y
>   * eDP 1.4 low vswing translation parameters
>   */
>  static const struct ddi_buf_trans skl_y_ddi_translations_edp[] = {
> @@ -218,7 +257,7 @@ static const struct ddi_buf_trans 
> skl_y_ddi_translations_edp[] = {
>   { 0x0018, 0x008A, 0x0 },
>  };
>  
> -/* Skylake U, H and S */
> +/* Skylake/Kabylake U, H and S */
>  static const struct ddi_buf_trans skl_ddi_translations_hdmi[] = {
>   { 0x0018, 0x00AC, 0x0 },
>   { 0x5012, 0x009D, 0x0 },
> @@ -233,7 +272,7 @@ static const struct ddi_buf_trans 
> skl_ddi_translations_hdmi[] = {
>   { 0x8018, 0x00C0, 0x1 },
>  };
>  
> -/* Skylake Y */
> +/* Skylake/Kabylake Y */
>  static const struct ddi_buf_trans skl_y_ddi_translations_hdmi[] = {
>   { 0x0018, 0x00A1, 0x0 },
>   { 0x5012, 0x00DF, 0x0 },
> @@ -334,10 +373,10 @@ bdw_get_buf_trans_edp(struct drm_i915_private 
> *dev_priv, int *n_entries)
>  static const struct ddi_buf_trans *
>  skl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
>  {
> - if (IS_SKL_ULX(dev_priv) || IS_KBL_ULX(dev_priv)) {
> + if (IS_SKL_ULX(dev_priv)) {
>   *n_entries = ARRAY_SIZE(skl_y_ddi_translations_dp);
>   return skl_y_ddi_translations_dp;
> - } else if (IS_SKL_ULT(dev_priv) || IS_KBL_ULT(dev_priv)) {
> + } else if (IS_SKL_ULT(dev_priv)) {
>   *n_entries = ARRAY_SIZE(skl_u_ddi_translations_dp);
>   return skl_u_ddi_translations_dp;
>   } else {
> @@ -347,6 +386,21 @@ skl_get_buf_trans_dp(struct drm_i915_private *dev_priv, 
> int *n_entries)
>  }
>  
>  static const struct ddi_buf_trans *
> +kbl_get_buf_trans_dp(struct drm_i915_private *dev_priv, int *n_entries)
> +{
> + if (IS_KBL_ULX(dev_priv)) {
> + *n_entries = ARRAY_SIZE(kbl_y_ddi_translations_dp);
> + return kbl_y_ddi_translations_dp;
> + } else if 

Re: [Intel-gfx] [PATCH 1/2] drm/i915/gen9: fix watermarks when using the pipe scaler

[Matt Roper]

On Fri, Oct 07, 2016 at 05:28:57PM -0300, Paulo Zanoni wrote:
> Luckily, the necessary adjustments for when we're using the scaler are
> exactly the same as the ones needed on ILK+, so just reuse the
> function we already have.
> 
> v2: Invert the patch order so stable backports get easier.
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Paulo Zanoni 

I thought there was a patch floating around to fix this back before I
went on break a couple months ago, but I can't find it now, so this
looks good.

For both patches:

Reviewed-by: Matt Roper 

> ---
>  drivers/gpu/drm/i915/intel_pm.c | 12 +++-
>  1 file changed, 3 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index fe6c1c6..000b033 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3470,12 +3470,6 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
>   return 0;
>  }
>  
> -static uint32_t skl_pipe_pixel_rate(const struct intel_crtc_state *config)
> -{
> - /* TODO: Take into account the scalers once we support them */
> - return config->base.adjusted_mode.crtc_clock;
> -}
> -
>  /*
>   * The max latency should be 257 (max the punit can code is 255 and we add 
> 2us
>   * for the read latency) and cpp should always be <= 8, so that
> @@ -3526,7 +3520,7 @@ static uint32_t skl_adjusted_plane_pixel_rate(const 
> struct intel_crtc_state *cst
>* Adjusted plane pixel rate is just the pipe's adjusted pixel rate
>* with additional adjustments for plane-specific scaling.
>*/
> - adjusted_pixel_rate = skl_pipe_pixel_rate(cstate);
> + adjusted_pixel_rate = ilk_pipe_pixel_rate(cstate);
>   downscale_amount = skl_plane_downscale_amount(pstate);
>  
>   pixel_rate = adjusted_pixel_rate * downscale_amount >> 16;
> @@ -3742,11 +3736,11 @@ skl_compute_linetime_wm(struct intel_crtc_state 
> *cstate)
>   if (!cstate->base.active)
>   return 0;
>  
> - if (WARN_ON(skl_pipe_pixel_rate(cstate) == 0))
> + if (WARN_ON(ilk_pipe_pixel_rate(cstate) == 0))
>   return 0;
>  
>   return DIV_ROUND_UP(8 * cstate->base.adjusted_mode.crtc_htotal * 1000,
> - skl_pipe_pixel_rate(cstate));
> + ilk_pipe_pixel_rate(cstate));
>  }
>  
>  static void skl_compute_transition_wm(struct intel_crtc_state *cstate,
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Matt Roper
Graphics Software Engineer
IoTG Platform Enabling & Development
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [drm-intel:for-linux-next 0/3] drivers/gpu/drm/i915/gvt/handlers.c:137: error: request for member 'mmio_base' in something not a structure or union

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel for-linux-next
head:   bfd02b3c557caa083be0d55a3164ede706a446e1
commit: 06a75ace46e2fdd1d93b06228df0e2dfe526cc27 [0/3] Merge tag 
'gvt-next-2016-10-14' of https://github.com/01org/gvt-linux into 
drm-intel-next-queued
config: x86_64-randconfig-s0-10180350 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 06a75ace46e2fdd1d93b06228df0e2dfe526cc27
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/gvt/handlers.c: In function 'render_mmio_to_ring_id':
>> drivers/gpu/drm/i915/gvt/handlers.c:137: error: request for member 
>> 'mmio_base' in something not a structure or union
--
   drivers/gpu/drm/i915/gvt/execlist.c: In function 'emulate_execlist_status':
>> drivers/gpu/drm/i915/gvt/execlist.c:97: error: request for member 
>> 'mmio_base' in something not a structure or union
   drivers/gpu/drm/i915/gvt/execlist.c: In function 'emulate_csb_update':
   drivers/gpu/drm/i915/gvt/execlist.c:136: error: request for member 
'mmio_base' in something not a structure or union
   drivers/gpu/drm/i915/gvt/execlist.c:138: error: request for member 
'mmio_base' in something not a structure or union
   drivers/gpu/drm/i915/gvt/execlist.c: In function 'get_next_execlist_slot':
   drivers/gpu/drm/i915/gvt/execlist.c:248: error: request for member 
'mmio_base' in something not a structure or union
   drivers/gpu/drm/i915/gvt/execlist.c: In function 'init_vgpu_execlist':
   drivers/gpu/drm/i915/gvt/execlist.c:798: error: request for member 
'mmio_base' in something not a structure or union
--
   drivers/gpu/drm/i915/gvt/scheduler.c: In function 'populate_shadow_context':
>> drivers/gpu/drm/i915/gvt/scheduler.c:71: warning: passing argument 1 of 
>> 'intel_lr_context_size' from incompatible pointer type
   drivers/gpu/drm/i915/intel_lrc.h:84: note: expected 'struct intel_engine_cs 
*' but argument is of type 'struct intel_engine_cs **'
   drivers/gpu/drm/i915/gvt/scheduler.c: In function 'dispatch_workload':
>> drivers/gpu/drm/i915/gvt/scheduler.c:175: warning: passing argument 1 of 
>> 'i915_gem_request_alloc' from incompatible pointer type
   drivers/gpu/drm/i915/i915_gem_request.h:156: note: expected 'struct 
intel_engine_cs *' but argument is of type 'struct intel_engine_cs **'
   drivers/gpu/drm/i915/gvt/scheduler.c: In function 'update_guest_context':
   drivers/gpu/drm/i915/gvt/scheduler.c:301: warning: passing argument 1 of 
'intel_lr_context_size' from incompatible pointer type
   drivers/gpu/drm/i915/intel_lrc.h:84: note: expected 'struct intel_engine_cs 
*' but argument is of type 'struct intel_engine_cs **'
   drivers/gpu/drm/i915/gvt/scheduler.o: warning: objtool: 
complete_current_workload()+0x771: function has unreachable instruction

vim +/mmio_base +137 drivers/gpu/drm/i915/gvt/handlers.c

28c4c6ca Zhi Wang 2016-05-01  131  static int render_mmio_to_ring_id(struct 
intel_gvt *gvt, unsigned int reg)
28c4c6ca Zhi Wang 2016-05-01  132  {
28c4c6ca Zhi Wang 2016-05-01  133   int i;
28c4c6ca Zhi Wang 2016-05-01  134  
28c4c6ca Zhi Wang 2016-05-01  135   reg &= ~GENMASK(11, 0);
28c4c6ca Zhi Wang 2016-05-01  136   for (i = 0; i < I915_NUM_ENGINES; i++) {
28c4c6ca Zhi Wang 2016-05-01 @137   if 
(gvt->dev_priv->engine[i].mmio_base == reg)
28c4c6ca Zhi Wang 2016-05-01  138   return i;
28c4c6ca Zhi Wang 2016-05-01  139   }
28c4c6ca Zhi Wang 2016-05-01  140   return -1;

:: The code at line 137 was first introduced by commit
:: 28c4c6ca7f794b2d5ac8773d43311e95f6518415 drm/i915/gvt: vGPU workload 
submission

:: TO: Zhi Wang 
:: CC: Zhenyu Wang 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/gvt: Fix build failure after intel_engine_cs change

[Zhenyu Wang]

Change GVT-g code reference for intel_engine_cs from static array to
allocated pointer after commit 3b3f1650b1ca ("drm/i915: Allocate
intel_engine_cs structure only for the enabled engines").

Signed-off-by: Zhenyu Wang 
---
 drivers/gpu/drm/i915/gvt/execlist.c  | 2 +-
 drivers/gpu/drm/i915/gvt/handlers.c  | 2 +-
 drivers/gpu/drm/i915/gvt/scheduler.c | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/execlist.c 
b/drivers/gpu/drm/i915/gvt/execlist.c
index 4a00ee7..c50a3d1 100644
--- a/drivers/gpu/drm/i915/gvt/execlist.c
+++ b/drivers/gpu/drm/i915/gvt/execlist.c
@@ -39,7 +39,7 @@
 #define _EL_OFFSET_STATUS_PTR   0x3A0
 
 #define execlist_ring_mmio(gvt, ring_id, offset) \
-   (gvt->dev_priv->engine[ring_id].mmio_base + (offset))
+   (gvt->dev_priv->engine[ring_id]->mmio_base + (offset))
 
 #define valid_context(ctx) ((ctx)->valid)
 #define same_context(a, b) (((a)->context_id == (b)->context_id) && \
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
b/drivers/gpu/drm/i915/gvt/handlers.c
index d59a934..e8ec403 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -134,7 +134,7 @@ static int render_mmio_to_ring_id(struct intel_gvt *gvt, 
unsigned int reg)
 
reg &= ~GENMASK(11, 0);
for (i = 0; i < I915_NUM_ENGINES; i++) {
-   if (gvt->dev_priv->engine[i].mmio_base == reg)
+   if (gvt->dev_priv->engine[i]->mmio_base == reg)
return i;
}
return -1;
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 732672b..b15cdf5 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -68,7 +68,7 @@ static int populate_shadow_context(struct intel_vgpu_workload 
*workload)
workload->ctx_desc.lrca);
 
context_page_num = intel_lr_context_size(
-   >dev_priv->engine[ring_id]);
+   gvt->dev_priv->engine[ring_id]);
 
context_page_num = context_page_num >> PAGE_SHIFT;
 
@@ -171,7 +171,7 @@ static int dispatch_workload(struct intel_vgpu_workload 
*workload)
shadow_ctx->desc_template = workload->ctx_desc.addressing_mode <<
GEN8_CTX_ADDRESSING_MODE_SHIFT;
 
-   workload->req = i915_gem_request_alloc(_priv->engine[ring_id],
+   workload->req = i915_gem_request_alloc(dev_priv->engine[ring_id],
   shadow_ctx);
if (IS_ERR_OR_NULL(workload->req)) {
gvt_err("fail to allocate gem request\n");
@@ -298,7 +298,7 @@ static void update_guest_context(struct intel_vgpu_workload 
*workload)
workload->ctx_desc.lrca);
 
context_page_num = intel_lr_context_size(
-   >dev_priv->engine[ring_id]);
+   gvt->dev_priv->engine[ring_id]);
 
context_page_num = context_page_num >> PAGE_SHIFT;
 
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PULL] GVT-g device model core

[Zhenyu Wang]

On 2016.10.17 16:07:50 +0200, Daniel Vetter wrote:
> Yeah might be best to have a new branch with upstreaming stuff (now you
> need to at least split out bugfixes for the already merged stuff) and
> treat that like a mostly stable branch. And the still unmerged features
> (vfio and all that) would then get rebased on top of that.
>

yeah, plan to do so, vfio part hasn't been merged, will rebase on new branch.

> 
> Also I already screwed up the merge, it doesn't even compile :( Sorry
> about that. Can you pls create a quick fixup patch just to make it work
> again and submit to intel-gfx? That way I can apply it directly.
> 

Done. As currently GVT-g code is closed bound to some i915 struct and
interface, any change for i915 interface might be possible to affect
GVT-g. As general rule API changer should cover for us too, but we might
try to capture that earlier, well at least 0day guy will shout out loudly.

-- 
Open Source Technology Center, Intel ltd.

$gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827


signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix build failure after intel_engine_cs change

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: Fix build failure after intel_engine_cs change
URL   : https://patchwork.freedesktop.org/series/13910/
State : failure

== Summary ==

Series 13910v1 drm/i915/gvt: Fix build failure after intel_engine_cs change
https://patchwork.freedesktop.org/api/1.0/series/13910/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s3:
incomplete -> DMESG-WARN (fi-byt-n2820)
dmesg-warn -> INCOMPLETE (fi-byt-j1900)
Test vgem_basic:
Subgroup unload:
skip   -> PASS   (fi-hsw-4770r)
pass   -> SKIP   (fi-bdw-5557u)

fi-bdw-5557u total:246  pass:230  dwarn:0   dfail:0   fail:0   skip:16 
fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42 
fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
fi-byt-j1900 total:76   pass:62   dwarn:0   dfail:0   fail:1   skip:12 
fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35 
fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
fi-skl-6260u failed to connect after reboot
fi-skl-6770hq failed to connect after reboot

Results at /archive/results/CI_IGT_test/Patchwork_2740/

7ec75289774dec48c46c37271fb334b7caed3d32 drm-intel-nightly: 
2016y-10m-17d-14h-07m-32s UTC integration manifest
ae305ca drm/i915/gvt: Fix build failure after intel_engine_cs change

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [i-g-t PATCH] igt/tools: Update intel_watermark with SKL support

[Dhinakaran Pandiyan]

Added support to print SKL watermark and DDB registers.

Signed-off-by: Dhinakaran Pandiyan 
---
 tools/intel_watermark.c | 104 +++-
 1 file changed, 103 insertions(+), 1 deletion(-)

diff --git a/tools/intel_watermark.c b/tools/intel_watermark.c
index e9a2b05..903a0b2 100644
--- a/tools/intel_watermark.c
+++ b/tools/intel_watermark.c
@@ -120,6 +120,11 @@ static const char *endis(bool enabled)
return enabled ? "enabled" : "disabled";
 }
 
+static const char endis_ast(bool enabled)
+{
+   return enabled ? '*' : ' ';
+}
+
 static int is_gen7_plus(uint32_t d)
 {
return !(IS_GEN5(d) || IS_GEN6(d));
@@ -130,6 +135,101 @@ static int is_hsw_plus(uint32_t d)
return !(IS_GEN5(d) || IS_GEN6(d) || IS_IVYBRIDGE(d));
 }
 
+
+static void skl_wm_dump(void)
+{
+   int pipe, plane, level;
+   int num_pipes = 3;
+   int num_planes = 5;
+   int num_levels = 8;
+   uint32_t base_addr = 0x7, addr, wm_offset;
+
+   uint32_t wm[num_levels][num_pipes][num_planes];
+   uint32_t wm_trans[num_pipes][num_planes];
+   uint32_t buf_cfg[num_pipes][num_planes];
+
+   intel_register_access_init(intel_get_pci_device(), 0);
+
+   for (pipe = 0; pipe < num_pipes; pipe++) {
+   for (plane = 0; plane < num_planes; plane++) {
+   addr =  base_addr +  pipe * 0x1000 + plane * 0x100;
+
+   wm_trans[pipe][plane] = read_reg(addr + 0x00168);
+   buf_cfg[pipe][plane] = read_reg(addr + 0x0017C);
+   for (level = 0; level < num_levels; level++) {
+   wm_offset = addr + 0x00140 + level * 0x4;
+   wm[level][pipe][plane] = read_reg(wm_offset);
+   }
+   }
+   }
+
+   for (pipe = 0; pipe < num_pipes; pipe++) {
+   uint32_t start, end, size;
+   uint32_t lines, blocks, enable;
+
+   printf("PIPE_%c\n", pipe_name(pipe));
+   printf("LEVEL   CURSOR   PLANE_A   PLANE_B   PLANE_C   
PLANE_D\n");
+   for (level = 0; level < num_levels; level++) {
+   printf("%5d  ", level);
+   for (plane = 0; plane < num_planes; plane++) {
+   blocks = REG_DECODE1(wm[level][pipe][plane], 0, 
9);
+   lines = REG_DECODE1(wm[level][pipe][plane], 14, 
5);
+   enable = REG_DECODE1(wm[level][pipe][plane], 
31, 1);
+
+   printf("%3d", blocks);
+   printf("%c", endis_ast(enable));
+   if (!REG_DECODE1(wm[level][pipe][plane], 30, 1))
+   printf("(%2d)  ", lines);
+   else
+   printf("(--)  ");
+   }
+   printf("\n");
+   }
+
+   printf("TRANS: ");
+   for (plane = 0; plane < num_planes; plane++) {
+   blocks = REG_DECODE1(wm_trans[pipe][plane], 0, 9);
+   lines = REG_DECODE1(wm_trans[pipe][plane], 14, 5);
+   enable = REG_DECODE1(wm_trans[pipe][plane], 31, 1);
+
+   printf("%3d", blocks);
+   printf("%c", endis_ast(enable));
+   if (!REG_DECODE1(wm_trans[pipe][plane], 30, 1))
+   printf("(%2d)  ", lines);
+   else
+   printf("(--)  ");
+   }
+
+   printf("\nDDB allocation:");
+
+   printf("\nstart ");
+   for (plane = 0; plane < num_planes; plane++) {
+   start = REG_DECODE1(buf_cfg[pipe][plane], 0, 10);
+   printf("%7d   ", start);
+   }
+
+   printf("\nend   ");
+   for (plane = 0; plane < num_planes; plane++) {
+   end = REG_DECODE1(buf_cfg[pipe][plane], 16, 10);
+   printf("%7d   ", end);
+   }
+
+   printf("\nsize  ");
+   for (plane = 0; plane < num_planes; plane++) {
+   start = REG_DECODE1(buf_cfg[pipe][plane], 0, 10);
+   end =  REG_DECODE1(buf_cfg[pipe][plane], 16, 10);
+   size = end - start + 1;
+   printf("%7d   ", (end == 0 && size == 1) ? 0 : size);
+   }
+
+   printf("\n\n\n");
+   }
+
+   printf("* plane watermark enabled\n");
+   printf("(x) line watermark if enabled\n");
+
+}
+
 static void ilk_wm_dump(void)
 {
int i;
@@ -900,7 +1000,9 @@ int main(int argc, char *argv[])
 {
devid = intel_get_pci_device()->device_id;
 
-   if (IS_VALLEYVIEW(devid) || IS_CHERRYVIEW(devid)) {
+   

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix build failure after intel_engine_cs change

[Saarinen, Jani]

> == Series Details ==
> 
> Series: drm/i915/gvt: Fix build failure after intel_engine_cs change
> URL   : https://patchwork.freedesktop.org/series/13910/
> State : failure
> 
> == Summary ==
> 
> Series 13910v1 drm/i915/gvt: Fix build failure after intel_engine_cs change
> https://patchwork.freedesktop.org/api/1.0/series/13910/revisions/1/mbox/
> 
> Test gem_exec_suspend:
> Subgroup basic-s3:
> incomplete -> DMESG-WARN (fi-byt-n2820)
Command /opt/igt/tests/gem_exec_suspend --run-subtest basic-S3
dmesg   
 [  363.532729] Suspending console(s) (use no_console_suspend to debug)
[  363.539402] sd 0:0:0:0: [sda] Synchronizing SCSI cache
[  363.540866] sd 0:0:0:0: [sda] Stopping disk
[  364.370247] Broke affinity for irq 19
[  364.370265] Broke affinity for irq 87
[  364.370272] Broke affinity for irq 88
[  364.370278] Broke affinity for irq 89
[  364.388813]  cache: parent cpu1 should not be sleeping
[  364.638398] [ cut here ]
[  364.638409] WARNING: CPU: 1 PID: 0 at kernel/locking/lockdep.c:2729 
trace_hardirqs_on_caller+0x113/0x1b0
[  364.638412] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
[  364.638440] Modules linked in: snd_hda_intel i915 intel_powerclamp coretemp 
crct10dif_pclmul crc32_pclmul snd_hda_codec_hdmi ghash_clmulni_intel 
snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec lpc_ich snd_hwdep 
snd_hda_core snd_pcm i2c_designware_platform i2c_designware_core r8169 mii 
sdhci_acpi sdhci i2c_hid mmc_core [last unloaded: i915]
[  364.638444] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G U  
4.9.0-rc1-CI-Patchwork_2740+ #1
[  364.638446] Hardware name: 
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x
 
\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x/DN2820FYK,
 BIOS FYBYT10H.86A.0038.2014.0717.1455 07/17/2014
[  364.638453]  88013fd03d68 8142df05 88013fd03db8 

[  364.638458]  88013fd03da8 8107e496 0aa93fd03e08 
81e249a0
[  364.638463]  8181d137 82e7e280  
0004
[  364.638464] Call Trace:
[  364.638472]   
[  364.638473]  [] dump_stack+0x67/0x92
[  364.638477]  [] __warn+0xc6/0xe0
[  364.638483]  [] ? _raw_spin_unlock_irq+0x27/0x50
[  364.638487]  [] warn_slowpath_fmt+0x4a/0x50
[  364.638491]  [] ? rtc_handler+0x1d/0xa0
[  364.638495]  [] trace_hardirqs_on_caller+0x113/0x1b0
[  364.638499]  [] trace_hardirqs_on+0xd/0x10
[  364.638502]  [] _raw_spin_unlock_irq+0x27/0x50
[  364.638505]  [] rtc_handler+0x32/0xa0
[  364.638509]  [] acpi_ev_fixed_event_detect+0xd4/0xfb
[  364.638513]  [] acpi_ev_sci_xrupt_handler+0xf/0x2d
[  364.638517]  [] acpi_irq+0x11/0x2c
[  364.638521]  [] __handle_irq_event_percpu+0x58/0x370
[  364.638525]  [] handle_irq_event_percpu+0x1e/0x50
[  364.638528]  [] handle_irq_event+0x34/0x60
[  364.638531]  [] handle_fasteoi_irq+0xa6/0x170
[  364.638536]  [] handle_irq+0x15/0x20
[  364.638539]  [] do_IRQ+0x68/0x130
[  364.638542]  [] common_interrupt+0x89/0x89
[  364.638548]   
[  364.638548]  [] ? mwait_idle+0x93/0x210
[  364.638551]  [] ? mwait_idle+0x8a/0x210
[  364.638555]  [] arch_cpu_idle+0xa/0x10
[  364.638558]  [] default_idle_call+0x1e/0x30
[  364.638561]  [] cpu_startup_entry+0x17c/0x1f0
[  364.638565]  [] start_secondary+0x102/0x120
[  364.638568] ---[ end trace 302f2b5e754e367a ]---

> dmesg-warn -> INCOMPLETE (fi-byt-j1900)

[075/246] skip: 12, pass: 62, fail: 1 -
running: igt/gem_exec_suspend/basic-s3 

[075/246] skip: 12, pass: 62, fail: 1 \
Build timed out (after 18 minutes). Marking the build as aborted.

> Test vgem_basic:
> Subgroup unload:
> skip   -> PASS   (fi-hsw-4770r)
> pass   -> SKIP   (fi-bdw-5557u)
> 
> fi-bdw-5557u total:246  pass:230  dwarn:0   dfail:0   fail:0   skip:16
> fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> fi-byt-j1900 total:76   pass:62   dwarn:0   dfail:0   fail:1   skip:12
> fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35
> fi-hsw-4770  total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-hsw-4770r total:246  pass:223  dwarn:1   dfail:0   fail:0   skip:22
> fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0  

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gvt: Fix build failure after intel_engine_cs change

[Zhenyu Wang]

On 2016.10.18 05:39:11 +, Saarinen, Jani wrote:
> > == Series Details ==
> > 
> > Series: drm/i915/gvt: Fix build failure after intel_engine_cs change
> > URL   : https://patchwork.freedesktop.org/series/13910/
> > State : failure
> > 
> > == Summary ==
> > 
> > Series 13910v1 drm/i915/gvt: Fix build failure after intel_engine_cs change
> > https://patchwork.freedesktop.org/api/1.0/series/13910/revisions/1/mbox/
> > 
> > Test gem_exec_suspend:
> > Subgroup basic-s3:
> > incomplete -> DMESG-WARN (fi-byt-n2820)
> Command   /opt/igt/tests/gem_exec_suspend --run-subtest basic-S3
> dmesg 
>  [  363.532729] Suspending console(s) (use no_console_suspend to debug)
> [  363.539402] sd 0:0:0:0: [sda] Synchronizing SCSI cache
> [  363.540866] sd 0:0:0:0: [sda] Stopping disk
> [  364.370247] Broke affinity for irq 19
> [  364.370265] Broke affinity for irq 87
> [  364.370272] Broke affinity for irq 88
> [  364.370278] Broke affinity for irq 89
> [  364.388813]  cache: parent cpu1 should not be sleeping
> [  364.638398] [ cut here ]
> [  364.638409] WARNING: CPU: 1 PID: 0 at kernel/locking/lockdep.c:2729 
> trace_hardirqs_on_caller+0x113/0x1b0
> [  364.638412] DEBUG_LOCKS_WARN_ON(current->hardirq_context)
> [  364.638440] Modules linked in: snd_hda_intel i915 intel_powerclamp 
> coretemp crct10dif_pclmul crc32_pclmul snd_hda_codec_hdmi ghash_clmulni_intel 
> snd_hda_codec_realtek snd_hda_codec_generic snd_hda_codec lpc_ich snd_hwdep 
> snd_hda_core snd_pcm i2c_designware_platform i2c_designware_core r8169 mii 
> sdhci_acpi sdhci i2c_hid mmc_core [last unloaded: i915]
> [  364.638444] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G U  
> 4.9.0-rc1-CI-Patchwork_2740+ #1
> [  364.638446] Hardware name: 
> \x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x
>  
> \x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x\x/DN2820FYK,
>  BIOS FYBYT10H.86A.0038.2014.0717.1455 07/17/2014
> [  364.638453]  88013fd03d68 8142df05 88013fd03db8 
> 
> [  364.638458]  88013fd03da8 8107e496 0aa93fd03e08 
> 81e249a0
> [  364.638463]  8181d137 82e7e280  
> 0004
> [  364.638464] Call Trace:
> [  364.638472]   
> [  364.638473]  [] dump_stack+0x67/0x92
> [  364.638477]  [] __warn+0xc6/0xe0
> [  364.638483]  [] ? _raw_spin_unlock_irq+0x27/0x50
> [  364.638487]  [] warn_slowpath_fmt+0x4a/0x50
> [  364.638491]  [] ? rtc_handler+0x1d/0xa0
> [  364.638495]  [] trace_hardirqs_on_caller+0x113/0x1b0
> [  364.638499]  [] trace_hardirqs_on+0xd/0x10
> [  364.638502]  [] _raw_spin_unlock_irq+0x27/0x50
> [  364.638505]  [] rtc_handler+0x32/0xa0
> [  364.638509]  [] acpi_ev_fixed_event_detect+0xd4/0xfb
> [  364.638513]  [] acpi_ev_sci_xrupt_handler+0xf/0x2d
> [  364.638517]  [] acpi_irq+0x11/0x2c
> [  364.638521]  [] __handle_irq_event_percpu+0x58/0x370
> [  364.638525]  [] handle_irq_event_percpu+0x1e/0x50
> [  364.638528]  [] handle_irq_event+0x34/0x60
> [  364.638531]  [] handle_fasteoi_irq+0xa6/0x170
> [  364.638536]  [] handle_irq+0x15/0x20
> [  364.638539]  [] do_IRQ+0x68/0x130
> [  364.638542]  [] common_interrupt+0x89/0x89
> [  364.638548]   
> [  364.638548]  [] ? mwait_idle+0x93/0x210
> [  364.638551]  [] ? mwait_idle+0x8a/0x210
> [  364.638555]  [] arch_cpu_idle+0xa/0x10
> [  364.638558]  [] default_idle_call+0x1e/0x30
> [  364.638561]  [] cpu_startup_entry+0x17c/0x1f0
> [  364.638565]  [] start_secondary+0x102/0x120
> [  364.638568] ---[ end trace 302f2b5e754e367a ]---
> 
> > dmesg-warn -> INCOMPLETE (fi-byt-j1900)
> 
> [075/246] skip: 12, pass: 62, fail: 1 -
> running: igt/gem_exec_suspend/basic-s3 
> 
> [075/246] skip: 12, pass: 62, fail: 1 \
> Build timed out (after 18 minutes). Marking the build as aborted.
> 
> > Test vgem_basic:
> > Subgroup unload:
> > skip   -> PASS   (fi-hsw-4770r)
> > pass   -> SKIP   (fi-bdw-5557u)
> > 
> > fi-bdw-5557u total:246  pass:230  dwarn:0   dfail:0   fail:0   skip:16
> > fi-bsw-n3050 total:246  pass:203  dwarn:1   dfail:0   fail:0   skip:42
> > fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> > fi-byt-j1900 total:76   pass:62   dwarn:0   dfail:0   fail:1   skip:12
> > fi-byt-n2820 total:246  pass:209  dwarn:1   dfail:0   fail:1   skip:35
> > fi-hsw-4770  total:246  pass:224  dwarn:0   

[Intel-gfx] [PATCH v3 3/4] drm/i915: Clean up DDI DDC/AUX CH sanitation

[ville . syrjala]

From: Ville Syrjälä 

Now that we use the AUX and GMBUS assignment from VBT for all ports,
let's clean up the sanitization of the port information a bit.
Previosuly we only did this for port E, and only complained about a
non-standard assignment for the other ports. But as we know that
non-standard assignments are a fact of life, let's expand the
sanitization to all the ports.

v2: Include a commit message, fix up the comments a bit
v3: Don't clobber other ports if the current port has no alternate aux ch/ddc 
pin

Cc: sta...@vger.kernel.org
Cc: Maarten Maathuis 
Tested-by: Maarten Maathuis 
References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
Signed-off-by: Ville Syrjälä 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1476208368-5710-4-git-send-email-ville.syrj...@linux.intel.com
Reviewed-by: Jim Bride  (v2)
---
 drivers/gpu/drm/i915/intel_bios.c | 122 --
 1 file changed, 77 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_bios.c 
b/drivers/gpu/drm/i915/intel_bios.c
index 83667e8cdd6b..a8ff8c099685 100644
--- a/drivers/gpu/drm/i915/intel_bios.c
+++ b/drivers/gpu/drm/i915/intel_bios.c
@@ -1035,6 +1035,77 @@ static u8 translate_iboost(u8 val)
return mapping[val];
 }
 
+static void sanitize_ddc_pin(struct drm_i915_private *dev_priv,
+enum port port)
+{
+   const struct ddi_vbt_port_info *info =
+   _priv->vbt.ddi_port_info[port];
+   enum port p;
+
+   if (!info->alternate_ddc_pin)
+   return;
+
+   for_each_port_masked(p, (1 << port) - 1) {
+   struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
+
+   if (info->alternate_ddc_pin != i->alternate_ddc_pin)
+   continue;
+
+   DRM_DEBUG_KMS("port %c trying to use the same DDC pin (0x%x) as 
port %c, "
+ "disabling port %c DVI/HDMI support\n",
+ port_name(p), i->alternate_ddc_pin,
+ port_name(port), port_name(p));
+
+   /*
+* If we have multiple ports supposedly sharing the
+* pin, then dvi/hdmi couldn't exist on the shared
+* port. Otherwise they share the same ddc bin and
+* system couldn't communicate with them separately.
+*
+* Due to parsing the ports in alphabetical order,
+* a higher port will always clobber a lower one.
+*/
+   i->supports_dvi = false;
+   i->supports_hdmi = false;
+   i->alternate_ddc_pin = 0;
+   }
+}
+
+static void sanitize_aux_ch(struct drm_i915_private *dev_priv,
+   enum port port)
+{
+   const struct ddi_vbt_port_info *info =
+   _priv->vbt.ddi_port_info[port];
+   enum port p;
+
+   if (!info->alternate_aux_channel)
+   return;
+
+   for_each_port_masked(p, (1 << port) - 1) {
+   struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
+
+   if (info->alternate_aux_channel != i->alternate_aux_channel)
+   continue;
+
+   DRM_DEBUG_KMS("port %c trying to use the same AUX CH (0x%x) as 
port %c, "
+ "disabling port %c DP support\n",
+ port_name(p), i->alternate_aux_channel,
+ port_name(port), port_name(p));
+
+   /*
+* If we have multiple ports supposedlt sharing the
+* aux channel, then DP couldn't exist on the shared
+* port. Otherwise they share the same aux channel
+* and system couldn't communicate with them separately.
+*
+* Due to parsing the ports in alphabetical order,
+* a higher port will always clobber a lower one.
+*/
+   i->supports_dp = false;
+   i->alternate_aux_channel = 0;
+   }
+}
+
 static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port,
   const struct bdb_header *bdb)
 {
@@ -1109,54 +1180,15 @@ static void parse_ddi_port(struct drm_i915_private 
*dev_priv, enum port port,
DRM_DEBUG_KMS("Port %c is internal DP\n", port_name(port));
 
if (is_dvi) {
-   if (port == PORT_E) {
-   info->alternate_ddc_pin = ddc_pin;
-   /* if DDIE share ddc pin with other port, then
-* dvi/hdmi couldn't exist on the shared port.
-* Otherwise they share the same ddc bin and system
-* couldn't communicate with them seperately. */
-   if (ddc_pin == DDC_PIN_B) 

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Clean up DDI DDC/AUX CH sanitation

[Ville Syrjälä]

On Tue, Oct 11, 2016 at 08:52:47PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Now that we use the AUX and GMBUS assignment from VBT for all ports,
> let's clean up the sanitization of the port information a bit.
> Previosuly we only did this for port E, and only complained about a
> non-standard assignment for the other ports. But as we know that
> non-standard assignments are a fact of life, let's expand the
> sanitization to all the ports.
> 
> v2: Include a commit message, fix up the comments a bit
> 
> Cc: sta...@vger.kernel.org
> Cc: Maarten Maathuis 
> Tested-by: Maarten Maathuis 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=97877
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_bios.c | 116 
> +++---
>  1 file changed, 71 insertions(+), 45 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
> b/drivers/gpu/drm/i915/intel_bios.c
> index 83667e8cdd6b..6d1ffa815e97 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -1035,6 +1035,71 @@ static u8 translate_iboost(u8 val)
>   return mapping[val];
>  }
>  
> +static void sanitize_ddc_pin(struct drm_i915_private *dev_priv,
> +  enum port port)
> +{
> + const struct ddi_vbt_port_info *info =
> + _priv->vbt.ddi_port_info[port];
> + enum port p;
> +

Hmm. And I just realized this code is probably slightly garbage. If the
current port doesn't have alternate_ddc_pin/alternate_aux_channel, then
we'd proceed to clobber any lower port without the thing as well. Now,
potentially all DDI platforms have this stuff fully decked out in VBT so
it might not matter in practice. But better safe that sorry, so I'll
send out a new version of this patch that checks here for the zero
case in both of these functions.

> + for_each_port_masked(p, (1 << port) - 1) {
> + struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
> +
> + if (info->alternate_ddc_pin != i->alternate_ddc_pin)
> + continue;
> +
> + DRM_DEBUG_KMS("port %c trying to use the same DDC pin (0x%x) as 
> port %c, "
> +   "disabling port %c DVI/HDMI support\n",
> +   port_name(p), i->alternate_ddc_pin,
> +   port_name(port), port_name(p));
> +
> + /*
> +  * If we have multiple ports supposedly sharing the
> +  * pin, then dvi/hdmi couldn't exist on the shared
> +  * port. Otherwise they share the same ddc bin and
> +  * system couldn't communicate with them separately.
> +  *
> +  * Due to parsing the ports in alphabetical order,
> +  * a higher port will always clobber a lower one.
> +  */
> + i->supports_dvi = false;
> + i->supports_hdmi = false;
> + i->alternate_ddc_pin = 0;
> + }
> +}
> +
> +static void sanitize_aux_ch(struct drm_i915_private *dev_priv,
> + enum port port)
> +{
> + const struct ddi_vbt_port_info *info =
> + _priv->vbt.ddi_port_info[port];
> + enum port p;
> +
> + for_each_port_masked(p, (1 << port) - 1) {
> + struct ddi_vbt_port_info *i = _priv->vbt.ddi_port_info[p];
> +
> + if (info->alternate_aux_channel != i->alternate_aux_channel)
> + continue;
> +
> + DRM_DEBUG_KMS("port %c trying to use the same AUX CH (0x%x) as 
> port %c, "
> +   "disabling port %c DP support\n",
> +   port_name(p), i->alternate_aux_channel,
> +   port_name(port), port_name(p));
> +
> + /*
> +  * If we have multiple ports supposedlt sharing the
> +  * aux channel, then DP couldn't exist on the shared
> +  * port. Otherwise they share the same aux channel
> +  * and system couldn't communicate with them separately.
> +  *
> +  * Due to parsing the ports in alphabetical order,
> +  * a higher port will always clobber a lower one.
> +  */
> + i->supports_dp = false;
> + i->alternate_aux_channel = 0;
> + }
> +}
> +
>  static void parse_ddi_port(struct drm_i915_private *dev_priv, enum port port,
>  const struct bdb_header *bdb)
>  {
> @@ -1109,54 +1174,15 @@ static void parse_ddi_port(struct drm_i915_private 
> *dev_priv, enum port port,
>   DRM_DEBUG_KMS("Port %c is internal DP\n", port_name(port));
>  
>   if (is_dvi) {
> - if (port == PORT_E) {
> - info->alternate_ddc_pin = ddc_pin;
> - /* if DDIE share ddc pin with other port, then
> -  

[Intel-gfx] [PATCH xf86-video-intel] sna: Reprobe if kernel updates the connector mode list

[Manasi Navare]

Output_check_status() should return a false if it detects
that the connector mode list has changed so that sna_mode_discover
can reprobe.

Fixes: eb01cc549d4d (sna: Refresh mode list if the kernel updates)

Signed-off-by: Manasi Navare 
Cc: Chris Wilson 
Cc: Ville Syrjala 
---
 src/sna/sna_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/sna/sna_display.c b/src/sna/sna_display.c
index 15be27c..ea7e287 100644
--- a/src/sna/sna_display.c
+++ b/src/sna/sna_display.c
@@ -5191,7 +5191,7 @@ output_check_status(struct sna *sna, struct sna_output 
*output)
return true;
 
if (output->num_modes != compat_conn.conn.count_modes)
-   return true;
+   return false;
 
if (output->edid_len == 0)
return false;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 12/15] drm: RIP mode_config->rotation_property

[Laurent Pinchart]

Hi Ville,

On Friday 22 Jul 2016 16:43:13 ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
> 
> Now that all drivers have been converted over to the per-plane rotation
> property, we can just nuke the global rotation property.
> 
> Signed-off-by: Ville Syrjälä 

Stupid question, but how does this work when the hardware supports global 
rotation only, not per-plane rotation ?

> ---
>  drivers/gpu/drm/drm_atomic.c|  6 ++
>  drivers/gpu/drm/drm_crtc.c  | 18 --
>  drivers/gpu/drm/drm_fb_helper.c |  7 +--
>  include/drm/drm_crtc.h  |  7 ---
>  4 files changed, 3 insertions(+), 35 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 116f940a9267..81061fcdb984 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -709,8 +709,7 @@ int drm_atomic_plane_set_property(struct drm_plane
> *plane, state->src_w = val;
>   } else if (property == config->prop_src_h) {
>   state->src_h = val;
> - } else if (property == config->rotation_property ||
> -property == plane->rotation_property) {
> + } else if (property == plane->rotation_property) {
>   if (!is_power_of_2(val & DRM_ROTATE_MASK))
>   return -EINVAL;
>   state->rotation = val;
> @@ -768,8 +767,7 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
>   *val = state->src_w;
>   } else if (property == config->prop_src_h) {
>   *val = state->src_h;
> - } else if (property == config->rotation_property ||
> -property == plane->rotation_property) {
> + } else if (property == plane->rotation_property) {
>   *val = state->rotation;
>   } else if (plane->funcs->atomic_get_property) {
>   return plane->funcs->atomic_get_property(plane, state, 
property, val);
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 9e20a52ece7c..c1df75caf72f 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -5783,24 +5783,6 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>  }
>  EXPORT_SYMBOL(drm_mode_config_cleanup);
> 
> -struct drm_property *drm_mode_create_rotation_property(struct drm_device
> *dev, -  unsigned int 
supported_rotations)
> -{
> - static const struct drm_prop_enum_list props[] = {
> - { DRM_ROTATE_0,   "rotate-0" },
> - { DRM_ROTATE_90,  "rotate-90" },
> - { DRM_ROTATE_180, "rotate-180" },
> - { DRM_ROTATE_270, "rotate-270" },
> - { DRM_REFLECT_X,  "reflect-x" },
> - { DRM_REFLECT_Y,  "reflect-y" },
> - };
> -
> - return drm_property_create_bitmask(dev, 0, "rotation",
> -props, ARRAY_SIZE(props),
> -supported_rotations);
> -}
> -EXPORT_SYMBOL(drm_mode_create_rotation_property);
> -
>  int drm_plane_create_rotation_property(struct drm_plane *plane,
>  unsigned int rotation,
>  unsigned int supported_rotations)
> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> b/drivers/gpu/drm/drm_fb_helper.c index ce536c0553e5..cf5f071ffae1 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -392,15 +392,10 @@ static int restore_fbdev_mode(struct drm_fb_helper
> *fb_helper) if (plane->type != DRM_PLANE_TYPE_PRIMARY)
>   drm_plane_force_disable(plane);
> 
> - if (plane->rotation_property) {
> + if (plane->rotation_property)
>   drm_mode_plane_set_obj_prop(plane,
>   plane->rotation_property,
>   BIT(DRM_ROTATE_0));
> - } else if (dev->mode_config.rotation_property) {
> - drm_mode_plane_set_obj_prop(plane,
> - dev-
>mode_config.rotation_property,
> - BIT(DRM_ROTATE_0));
> - }
>   }
> 
>   for (i = 0; i < fb_helper->crtc_count; i++) {
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 01cf0673f6c8..00a93e44f854 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -2480,11 +2480,6 @@ struct drm_mode_config {
>*/
>   struct drm_property *plane_type_property;
>   /**
> -  * @rotation_property: Optional property for planes or CRTCs to 
specify
> -  * rotation.
> -  */
> - struct drm_property *rotation_property;
> - /**
>* @prop_src_x: Default atomic plane property for the plane source
>* position in the connected _framebuffer.
>*/
> @@ -2960,8 +2955,6 @@ 

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for Start of skl watermark cleanup (rev3)

[Saarinen, Jani]

> == Series Details ==
> 
> Series: Start of skl watermark cleanup (rev3)
> URL   : https://patchwork.freedesktop.org/series/1/
> State : warning
> 
> == Summary ==
> 
> Series 1v3 Start of skl watermark cleanup
> https://patchwork.freedesktop.org/api/1.0/series/1/revisions/3/mbox/
> 
> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> dmesg-warn -> PASS   (fi-skl-6700k)
> dmesg-warn -> PASS   (fi-skl-6770hq)
> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-a-frame-sequence:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup read-crc-pipe-b:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup suspend-read-crc-pipe-c:
> incomplete -> PASS   (fi-skl-6700k)
> Test vgem_basic:
> Subgroup unload:
> pass   -> SKIP   (fi-hsw-4770)
> pass   -> SKIP   (fi-bdw-5557u)
> skip   -> PASS   (fi-skl-6770hq)
Known un-stable. Will be worked on still. 
> 
> fi-bdw-5557u total:246  pass:230  dwarn:0   dfail:0   fail:0   skip:16
> fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35
> fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60
> fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24
> fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14
> fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24
> fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14
> fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36
> fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37
> fi-byt-j1900 failed to connect after reboot
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2729/
> 
> 38ecbe9082e477953fe165265c76e6c6061aeaf6 drm-intel-nightly: 2016y-10m-
> 14d-16h-23m-48s UTC integration manifest e6ec3db drm/i915/gen9: Don't
> wrap strings in verify_wm_state() be9c54e drm/i915/gen9: Actually verify
> WM levels in verify_wm_state()
> 158bb87 drm/i915/gen9: Add skl_wm_level_equals() 95570fd
> drm/i915/gen9: Make skl_pipe_wm_get_hw_state() reusable
> 1f4ad42 drm/i915/gen9: Add ddb changes to atomic debug output 9fd875d
> drm/i915/gen9: Get rid of redundant watermark values aaf254a
> drm/i915/gen9: Cleanup skl_pipe_wm_active_state 6e1087f drm/i915/gen9:
> Make skl_wm_level per-plane b1399ab drm/i915/skl: Remove linetime from
> skl_wm_values
> 599c303 drm/i915/skl: Move per-pipe ddb allocations into crtc states
> 

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 4/4] drm: Add and handle new aspect ratios in DRM layer

[Daniel Vetter]

On Thu, Oct 13, 2016 at 10:28:14AM -0700, Jim Bride wrote:
> On Tue, Aug 09, 2016 at 08:25:50PM +0530, Shashank Sharma wrote:
> > HDMI 2.0/CEA-861-F introduces two new aspect ratios:
> > - 64:27
> > - 256:135
> > 
> > This patch:
> > -  Adds new DRM flags for to represent these new aspect ratios.
> > -  Adds new cases to handle these aspect ratios while converting
> > from user->kernel mode or vise versa.
> > 
> > V2: Rebase
> > 
> > Signed-off-by: Shashank Sharma 
> > Reviewed-by: Sean Paul 
> > Cc: Daniel Vetter 
> > Cc: Emil Velikov 
> > ---
> >  drivers/gpu/drm/drm_modes.c | 12 
> >  include/uapi/drm/drm_mode.h |  6 ++
> >  2 files changed, 18 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> > index 9d8f00d..ed1b07b 100644
> > --- a/drivers/gpu/drm/drm_modes.c
> > +++ b/drivers/gpu/drm/drm_modes.c
> > @@ -1481,6 +1481,12 @@ void drm_mode_convert_to_umode(struct 
> > drm_mode_modeinfo *out,
> > case HDMI_PICTURE_ASPECT_16_9:
> > out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
> > break;
> > +   case HDMI_PICTURE_ASPECT_64_27:
> > +   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
> > +   break;
> > +   case DRM_MODE_PICTURE_ASPECT_256_135:
> > +   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
> > +   break;
> > case HDMI_PICTURE_ASPECT_RESERVED:
> > default:
> > out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
> > @@ -1542,6 +1548,12 @@ int drm_mode_convert_umode(struct drm_display_mode 
> > *out,
> > case DRM_MODE_FLAG_PIC_AR_16_9:
> > out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
> > break;
> > +   case DRM_MODE_FLAG_PIC_AR_64_27:
> > +   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
> > +   break;
> > +   case DRM_MODE_FLAG_PIC_AR_256_135:
> > +   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
> > +   break;
> > default:
> > out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> > break;
> > diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> > index 77c869d6..4d3429b 100644
> > --- a/include/uapi/drm/drm_mode.h
> > +++ b/include/uapi/drm/drm_mode.h
> > @@ -81,6 +81,8 @@ extern "C" {
> >  #define DRM_MODE_PICTURE_ASPECT_NONE   0
> >  #define DRM_MODE_PICTURE_ASPECT_4_31
> >  #define DRM_MODE_PICTURE_ASPECT_16_9   2
> > +#define DRM_MODE_PICTURE_ASPECT_64_27  3
> > +#define DRM_MODE_PICTURE_ASPECT_256_1354
> 
> Minor nit here, but in my tree the '4' above doesn't line up
> with the three previous definitions.  I downloaded the series as
> a mbox from patchwork.

r-b with that bikeshed addressed or not? Also any reason you didn't r-b
patch 3?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/1] drm/i915/guc: Sanitory checks for platform that dont have GuC

[Saarinen, Jani]

> == Series Details ==
> 
> Series: series starting with [1/1] drm/i915/guc: Sanitory checks for platform
> that dont have GuC
> URL   : https://patchwork.freedesktop.org/series/13815/
> State : warning
> 
> == Summary ==
> 
> Series 13815v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/13815/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> pass   -> SKIP   (fi-skl-6770hq)
Known unstable still. 

> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> dmesg-warn -> PASS   (fi-skl-6770hq)
> dmesg-warn -> PASS   (fi-skl-6700k)
> Subgroup basic-plain-flip:
> pass   -> DMESG-WARN (fi-ilk-650)
dmesg   
[  395.814348] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU 
pipe B FIFO underrun
https://bugs.freedesktop.org/show_bug.cgi?id=98251

[  395.814464] [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH 
transcoder B FIFO underrun

> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-a-frame-sequence:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup read-crc-pipe-b:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup suspend-read-crc-pipe-c:
> incomplete -> PASS   (fi-skl-6700k)
> Test vgem_basic:
> Subgroup unload:
> pass   -> SKIP   (fi-hsw-4770)
> skip   -> PASS   (fi-skl-6770hq)
Still unstable.

> 
> fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15
> fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31
> fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35
> fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-ilk-650   total:246  pass:183  dwarn:1   dfail:0   fail:2   skip:60
> fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24
> fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14
> fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24
> fi-skl-6770hqtotal:246  pass:229  dwarn:1   dfail:0   fail:1   skip:15
> fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36
> fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2730/
> 
> 38ecbe9082e477953fe165265c76e6c6061aeaf6 drm-intel-nightly: 2016y-10m-
> 14d-16h-23m-48s UTC integration manifest
> 1392686 drm/i915/guc: Sanitory checks for platform that dont have GuC
> 

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/dmc: Make no_stepping_info an array

[Saarinen, Jani]

> == Series Details ==
> 
> Series: series starting with [1/2] drm/i915/dmc: Make no_stepping_info an
> array
> URL   : https://patchwork.freedesktop.org/series/13818/
> State : warning
> 
> == Summary ==
> 
> Series 13818v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/13818/revisions/1/mbox/
> 
> Test drv_module_reload_basic:
> pass   -> SKIP   (fi-skl-6770hq)
Unstable
> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> dmesg-warn -> PASS   (fi-skl-6700k)
> dmesg-warn -> PASS   (fi-skl-6770hq)
> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-a-frame-sequence:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup read-crc-pipe-b:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup suspend-read-crc-pipe-a:
> pass   -> DMESG-WARN (fi-byt-j1900)
https://bugs.freedesktop.org/show_bug.cgi?id=98040

> Subgroup suspend-read-crc-pipe-c:
> incomplete -> PASS   (fi-skl-6700k)
> Test vgem_basic:
> Subgroup unload:
> pass   -> SKIP   (fi-bdw-5557u)
> pass   -> SKIP   (fi-hsw-4770)
> skip   -> PASS   (fi-skl-6770hq)
Unstable...

> 
> fi-bdw-5557u total:246  pass:230  dwarn:0   dfail:0   fail:0   skip:16
> fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> fi-byt-j1900 total:246  pass:212  dwarn:2   dfail:0   fail:1   skip:31
> fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35
> fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60
> fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24
> fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14
> fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24
> fi-skl-6770hqtotal:246  pass:229  dwarn:1   dfail:0   fail:1   skip:15
> fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36
> fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2731/
> 
> 38ecbe9082e477953fe165265c76e6c6061aeaf6 drm-intel-nightly: 2016y-10m-
> 14d-16h-23m-48s UTC integration manifest 6c7e89b drm/i915/DMC/KBL:
> Load DMC on KBL using he no_stepping_info array
> a43c6e5 drm/i915/dmc: Make no_stepping_info an array
> 

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 05/10] drm/i915/gen9: Get rid of redundant watermark values

[Daniel Vetter]

On Thu, Oct 13, 2016 at 05:04:03PM -0300, Paulo Zanoni wrote:
> Em Qui, 2016-10-13 às 15:39 +0200, Maarten Lankhorst escreveu:
> > Op 08-10-16 om 02:11 schreef Lyude:
> > > 
> > > Now that we've make skl_wm_levels make a little more sense, we can
> > > remove all of the redundant wm information. Up until now we'd been
> > > storing two copies of all of the skl watermarks: one being the
> > > skl_pipe_wm structs, the other being the global wm struct in
> > > drm_i915_private containing the raw register values. This is
> > > confusing
> > > and problematic, since it means we're prone to accidentally letting
> > > the
> > > two copies go out of sync. So, get rid of all of the functions
> > > responsible for computing the register values and just use a single
> > > helper, skl_write_wm_level(), to convert and write the new
> > > watermarks on
> > > the fly.
> > > 
> > > Changes since v1:
> > > - Fixup skl_write_wm_level()
> > > - Fixup skl_wm_level_from_reg_val()
> > > - Don't forget to copy *active to intel_crtc->wm.active.skl
> > > 
> > > Signed-off-by: Lyude 
> > > Reviewed-by: Maarten Lankhorst 
> > > Cc: Ville Syrjälä 
> > > Cc: Paulo Zanoni 
> > > ---
> > >  drivers/gpu/drm/i915/i915_drv.h  |   2 -
> > >  drivers/gpu/drm/i915/intel_display.c |  14 ++-
> > >  drivers/gpu/drm/i915/intel_drv.h |   6 +-
> > >  drivers/gpu/drm/i915/intel_pm.c  | 204 ---
> > > 
> > >  drivers/gpu/drm/i915/intel_sprite.c  |   8 +-
> > >  5 files changed, 90 insertions(+), 144 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > b/drivers/gpu/drm/i915/i915_drv.h
> > > index 0287c93..76583b2 100644
> > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > @@ -1644,8 +1644,6 @@ struct skl_ddb_allocation {
> > >  struct skl_wm_values {
> > >   unsigned dirty_pipes;
> > >   struct skl_ddb_allocation ddb;
> > > - uint32_t plane[I915_MAX_PIPES][I915_MAX_PLANES][8];
> > > - uint32_t plane_trans[I915_MAX_PIPES][I915_MAX_PLANES];
> > >  };
> > >  
> > >  struct skl_wm_level {
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index a71d05a..39400a0 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -3378,6 +3378,8 @@ static void
> > > skylake_update_primary_plane(struct drm_plane *plane,
> > >   struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state-
> > > >base.crtc);
> > >   struct drm_framebuffer *fb = plane_state->base.fb;
> > >   const struct skl_wm_values *wm = _priv-
> > > >wm.skl_results;
> > > + const struct skl_plane_wm *p_wm =
> > > + _state->wm.skl.optimal.planes[0];
> > >   int pipe = intel_crtc->pipe;
> > >   u32 plane_ctl;
> > >   unsigned int rotation = plane_state->base.rotation;
> > > @@ -3414,7 +3416,7 @@ static void
> > > skylake_update_primary_plane(struct drm_plane *plane,
> > >   intel_crtc->adjusted_y = src_y;
> > >  
> > >   if (wm->dirty_pipes & drm_crtc_mask(_crtc->base))
> > > - skl_write_plane_wm(intel_crtc, wm, 0);
> > > + skl_write_plane_wm(intel_crtc, p_wm, >ddb, 0);
> > >  
> > >   I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
> > >   I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) | src_x);
> > > @@ -3448,6 +3450,8 @@ static void
> > > skylake_disable_primary_plane(struct drm_plane *primary,
> > >   struct drm_device *dev = crtc->dev;
> > >   struct drm_i915_private *dev_priv = to_i915(dev);
> > >   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > > + struct intel_crtc_state *cstate =
> > > to_intel_crtc_state(crtc->state);
> > > + const struct skl_plane_wm *p_wm = 
> > > >wm.skl.optimal.planes[0];
> > >   int pipe = intel_crtc->pipe;
> > >  
> > >   /*
> > > @@ -3455,7 +3459,8 @@ static void
> > > skylake_disable_primary_plane(struct drm_plane *primary,
> > >    * plane's visiblity isn't actually changing neither is
> > > its watermarks.
> > >    */
> > >   if (!crtc->primary->state->visible)
> > > - skl_write_plane_wm(intel_crtc, _priv-
> > > >wm.skl_results, 0);
> > > + skl_write_plane_wm(intel_crtc, p_wm,
> > > +    _priv->wm.skl_results.ddb,
> > > 0);
> > >  
> > >   I915_WRITE(PLANE_CTL(pipe, 0), 0);
> > >   I915_WRITE(PLANE_SURF(pipe, 0), 0);
> > > @@ -10819,12 +10824,15 @@ static void i9xx_update_cursor(struct
> > > drm_crtc *crtc, u32 base,
> > >   struct drm_device *dev = crtc->dev;
> > >   struct drm_i915_private *dev_priv = to_i915(dev);
> > >   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> > > + struct intel_crtc_state *cstate =
> > > to_intel_crtc_state(crtc->state);
> > >   const struct skl_wm_values *wm = _priv-
> > > >wm.skl_results;
> > > + const struct skl_plane_wm *p_wm =
> > > + >wm.skl.optimal.planes[PLANE_CURSOR];
> > >   int pipe = intel_crtc->pipe;
> > >   uint32_t 

Re: [Intel-gfx] [PATCH] drm/edid: Only print the bad edid when aborting

[Daniel Vetter]

On Thu, Oct 13, 2016 at 08:43:55PM +0100, Chris Wilson wrote:
> Currently, if drm.debug is enabled, we get a DRM_ERROR message on the
> intermediate edid reads. This causes transient failures in CI which
> flags up the sporadic EDID read failures, which are recovered by
> rereading the EDID automatically. This patch combines the reporting done
> by drm_do_get_edid() itself with the bad block printing from
> get_edid_block(), into a single warning associated with the connector
> once all attempts to retrieve the EDID fail.
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=98228
> Signed-off-by: Chris Wilson 

Can I haz a version of this patch without the s/block/edid/? It confuses
me this early. If you want it, please split out.
-Daniel

> ---
>  drivers/gpu/drm/drm_edid.c | 82 
> +-
>  1 file changed, 44 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index ec77bd3e1f08..51dd10c65b53 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1260,6 +1260,26 @@ drm_do_probe_ddc_edid(void *data, u8 *buf, unsigned 
> int block, size_t len)
>   return ret == xfers ? 0 : -1;
>  }
>  
> +static void connector_add_bad_edid(struct drm_connector *connector,
> +u8 *block, int num)
> +{
> + if (connector->bad_edid_counter++ && !(drm_debug & DRM_UT_KMS))
> + return;
> +
> + if (drm_edid_is_zero(block, EDID_LENGTH)) {
> + dev_warn(connector->dev->dev,
> +  "%s: EDID block %d is all zeroes.\n",
> +  connector->name, num);
> + } else {
> + dev_warn(connector->dev->dev,
> +  "%s: EDID block %d invalid:\n",
> +  connector->name, num);
> + print_hex_dump(KERN_WARNING,
> +" \t", DUMP_PREFIX_NONE, 16, 1,
> +block, EDID_LENGTH, false);
> + }
> +}
> +
>  /**
>   * drm_do_get_edid - get EDID data using a custom EDID block read function
>   * @connector: connector we're probing
> @@ -1282,20 +1302,19 @@ struct edid *drm_do_get_edid(struct drm_connector 
> *connector,
>   void *data)
>  {
>   int i, j = 0, valid_extensions = 0;
> - u8 *block, *new;
> - bool print_bad_edid = !connector->bad_edid_counter || (drm_debug & 
> DRM_UT_KMS);
> + u8 *edid, *new;
>  
> - if ((block = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> + if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
>   return NULL;
>  
>   /* base block fetch */
>   for (i = 0; i < 4; i++) {
> - if (get_edid_block(data, block, 0, EDID_LENGTH))
> + if (get_edid_block(data, edid, 0, EDID_LENGTH))
>   goto out;
> - if (drm_edid_block_valid(block, 0, print_bad_edid,
> + if (drm_edid_block_valid(edid, 0, false,
>>edid_corrupt))
>   break;
> - if (i == 0 && drm_edid_is_zero(block, EDID_LENGTH)) {
> + if (i == 0 && drm_edid_is_zero(edid, EDID_LENGTH)) {
>   connector->null_edid_counter++;
>   goto carp;
>   }
> @@ -1304,58 +1323,45 @@ struct edid *drm_do_get_edid(struct drm_connector 
> *connector,
>   goto carp;
>  
>   /* if there's no extensions, we're done */
> - if (block[0x7e] == 0)
> - return (struct edid *)block;
> + if (edid[0x7e] == 0)
> + return (struct edid *)edid;
>  
> - new = krealloc(block, (block[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL);
> + new = krealloc(edid, (edid[0x7e] + 1) * EDID_LENGTH, GFP_KERNEL);
>   if (!new)
>   goto out;
> - block = new;
> + edid = new;
> +
> + for (j = 1; j <= edid[0x7e]; j++) {
> + u8 *block = edid + (valid_extensions + 1) * EDID_LENGTH;
>  
> - for (j = 1; j <= block[0x7e]; j++) {
>   for (i = 0; i < 4; i++) {
> - if (get_edid_block(data,
> -   block + (valid_extensions + 1) * EDID_LENGTH,
> -   j, EDID_LENGTH))
> + if (get_edid_block(data, block, j, EDID_LENGTH))
>   goto out;
> - if (drm_edid_block_valid(block + (valid_extensions + 1)
> -  * EDID_LENGTH, j,
> -  print_bad_edid,
> -  NULL)) {
> + if (drm_edid_block_valid(block, j, false, NULL)) {
>   valid_extensions++;
>   break;
>   }
>   }
>  
> - if (i == 4 && print_bad_edid) {
> - dev_warn(connector->dev->dev,
> - 

Re: [Intel-gfx] [PATCH 26/41] drm: Add reference counting to drm_atomic_state

[Daniel Vetter]

On Fri, Oct 14, 2016 at 01:18:18PM +0100, Chris Wilson wrote:
> drm_atomic_state has a complicated single owner model that tracks the
> single reference from allocation through to destruction on another
> thread - or perhaps on a local error path. We can simplify this tracking
> by using reference counting (at a cost of a few more atomics). This is
> even more beneficial when the lifetime of the state becomes more
> convoluted than being passed to a single worker thread for the commit.
> 
> v2: Double check !intel atomic_commit functions for missing gets
> v3: Update kerneldocs
> 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: dri-de...@lists.freedesktop.org
> Reviewed-by: Eric Engestrom 
> Reviewed-by: Sean Paul 

Applied to drm-misc, thanks.
-Daniel

> ---
>  drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c |  3 +-
>  drivers/gpu/drm/drm_atomic.c | 25 +++
>  drivers/gpu/drm/drm_atomic_helper.c  | 98 
> +++-
>  drivers/gpu/drm/drm_fb_helper.c  |  9 +--
>  drivers/gpu/drm/exynos/exynos_drm_drv.c  |  3 +-
>  drivers/gpu/drm/i915/i915_debugfs.c  |  5 +-
>  drivers/gpu/drm/i915/intel_display.c | 31 +
>  drivers/gpu/drm/i915/intel_sprite.c  |  4 +-
>  drivers/gpu/drm/mediatek/mtk_drm_drv.c   |  3 +-
>  drivers/gpu/drm/msm/msm_atomic.c |  3 +-
>  drivers/gpu/drm/omapdrm/omap_drv.c   |  3 +-
>  drivers/gpu/drm/rcar-du/rcar_du_kms.c|  3 +-
>  drivers/gpu/drm/sti/sti_drv.c|  3 +-
>  drivers/gpu/drm/tegra/drm.c  |  3 +-
>  drivers/gpu/drm/tilcdc/tilcdc_drv.c  |  2 -
>  drivers/gpu/drm/vc4/vc4_kms.c|  3 +-
>  include/drm/drm_atomic.h | 31 -
>  include/drm/drm_plane.h  |  1 -
>  18 files changed, 102 insertions(+), 131 deletions(-)
> 
> diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c 
> b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> index 5f484310bee9..9f6222895212 100644
> --- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> +++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c
> @@ -464,7 +464,7 @@ atmel_hlcdc_dc_atomic_complete(struct 
> atmel_hlcdc_dc_commit *commit)
>  
>   drm_atomic_helper_cleanup_planes(dev, old_state);
>  
> - drm_atomic_state_free(old_state);
> + drm_atomic_state_put(old_state);
>  
>   /* Complete the commit, wake up any waiter. */
>   spin_lock(>commit.wait.lock);
> @@ -521,6 +521,7 @@ static int atmel_hlcdc_dc_atomic_commit(struct drm_device 
> *dev,
>   /* Swap the state, this is the point of no return. */
>   drm_atomic_helper_swap_state(state, true);
>  
> + drm_atomic_state_get(state);
>   if (async)
>   queue_work(dc->wq, >work);
>   else
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 23739609427d..5dd70540219c 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -74,6 +74,8 @@ EXPORT_SYMBOL(drm_atomic_state_default_release);
>  int
>  drm_atomic_state_init(struct drm_device *dev, struct drm_atomic_state *state)
>  {
> + kref_init(>ref);
> +
>   /* TODO legacy paths should maybe do a better job about
>* setting this appropriately?
>*/
> @@ -215,22 +217,16 @@ void drm_atomic_state_clear(struct drm_atomic_state 
> *state)
>  EXPORT_SYMBOL(drm_atomic_state_clear);
>  
>  /**
> - * drm_atomic_state_free - free all memory for an atomic state
> - * @state: atomic state to deallocate
> + * __drm_atomic_state_free - free all memory for an atomic state
> + * @ref: This atomic state to deallocate
>   *
>   * This frees all memory associated with an atomic state, including all the
>   * per-object state for planes, crtcs and connectors.
>   */
> -void drm_atomic_state_free(struct drm_atomic_state *state)
> +void __drm_atomic_state_free(struct kref *ref)
>  {
> - struct drm_device *dev;
> - struct drm_mode_config *config;
> -
> - if (!state)
> - return;
> -
> - dev = state->dev;
> - config = >mode_config;
> + struct drm_atomic_state *state = container_of(ref, typeof(*state), ref);
> + struct drm_mode_config *config = >dev->mode_config;
>  
>   drm_atomic_state_clear(state);
>  
> @@ -243,7 +239,7 @@ void drm_atomic_state_free(struct drm_atomic_state *state)
>   kfree(state);
>   }
>  }
> -EXPORT_SYMBOL(drm_atomic_state_free);
> +EXPORT_SYMBOL(__drm_atomic_state_free);
>  
>  /**
>   * drm_atomic_get_crtc_state - get crtc state
> @@ -1742,7 +1738,7 @@ retry:
>   if (arg->flags & DRM_MODE_ATOMIC_TEST_ONLY) {
>   /*
>* Unlike commit, check_only does not clean up state.
> -  * Below we call drm_atomic_state_free for it.
> +  * Below we call drm_atomic_state_put for it.
>*/
>   

Re: [Intel-gfx] [PATCH v2 3/4] video: Add new aspect ratios for HDMI 2.0

[Tomi Valkeinen]

On 09/08/16 17:55, Shashank Sharma wrote:
> HDMI 2.0/CEA-861-F introduces two new aspect ratios:
> - 64:27
> - 256:135
> 
> This patch adds enumeration for the new aspect ratios
> in the existing aspect ratio list.
> 
> V2: rebase
> 
> Signed-off-by: Shashank Sharma 
> Reviewed-by: Sean Paul 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> ---
>  drivers/video/hdmi.c | 4 
>  include/linux/hdmi.h | 2 ++
>  2 files changed, 6 insertions(+)
> 
> diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
> index 1626892..1cf907e 100644
> --- a/drivers/video/hdmi.c
> +++ b/drivers/video/hdmi.c
> @@ -533,6 +533,10 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect 
> picture_aspect)
>   return "4:3";
>   case HDMI_PICTURE_ASPECT_16_9:
>   return "16:9";
> + case HDMI_PICTURE_ASPECT_64_27:
> + return "64:27";
> + case HDMI_PICTURE_ASPECT_256_135:
> + return "256:135";
>   case HDMI_PICTURE_ASPECT_RESERVED:
>   return "Reserved";
>   }
> diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
> index e974420..edbb4fc 100644
> --- a/include/linux/hdmi.h
> +++ b/include/linux/hdmi.h
> @@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
>   HDMI_PICTURE_ASPECT_NONE,
>   HDMI_PICTURE_ASPECT_4_3,
>   HDMI_PICTURE_ASPECT_16_9,
> + HDMI_PICTURE_ASPECT_64_27,
> + HDMI_PICTURE_ASPECT_256_135,
>   HDMI_PICTURE_ASPECT_RESERVED,
>  };
>  
> 

Acked-by: Tomi Valkeinen 

 Tomi



signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH v2 1/8] drm/i915: setup bridge for HDMI LPE audio driver

[Daniel Vetter]

On Sat, Oct 01, 2016 at 05:52:35AM +0530, Jerome Anand wrote:
> Enable support for HDMI LPE audio mode on Baytrail and
> Cherrytrail when HDaudio controller is not detected
> 
> Setup minimum required resources during i915_driver_load:
> 1. Create a platform device to share MMIO/IRQ resources
> 2. Make the platform device child of i915 device for runtime PM.
> 3. Create IRQ chip to forward HDMI LPE audio irqs.
> 
> HDMI LPE audio driver (a standalone sound driver) probes the
> LPE audio device and creates a new sound card.
> 
> Signed-off-by: Pierre-Louis Bossart 
> Signed-off-by: Jerome Anand 

You need to add an include-stanza to Documentation/gpu/i915.rst,
otherwise the kerneldoc won't show up. Please also do some docs for the
structures, and then run

$ make htmldocs

to check the output looks reasonable.

Thanks, Daniel

> ---
>  drivers/gpu/drm/i915/Makefile  |   3 +
>  drivers/gpu/drm/i915/i915_drv.c|  13 +-
>  drivers/gpu/drm/i915/i915_drv.h|  19 ++
>  drivers/gpu/drm/i915/i915_irq.c|  14 ++
>  drivers/gpu/drm/i915/i915_reg.h|   3 +
>  drivers/gpu/drm/i915/intel_lpe_audio.c | 357 
> +
>  include/drm/intel_lpe_audio.h  |  45 +
>  7 files changed, 452 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_lpe_audio.c
>  create mode 100644 include/drm/intel_lpe_audio.h
> 
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index e6fe004..11f9741 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -115,6 +115,9 @@ i915-y += intel_gvt.o
>  include $(src)/gvt/Makefile
>  endif
>  
> +# LPE Audio for VLV and CHT
> +i915-y += intel_lpe_audio.o
> +
>  obj-$(CONFIG_DRM_I915) += i915.o
>  
>  CFLAGS_i915_trace_points.o := -I$(src)
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 31b2b63..ab1e4768 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1141,7 +1141,13 @@ static void i915_driver_register(struct 
> drm_i915_private *dev_priv)
>   if (IS_GEN5(dev_priv))
>   intel_gpu_ips_init(dev_priv);
>  
> - i915_audio_component_init(dev_priv);
> + if (intel_lpe_audio_detect(dev_priv)) {
> + if (intel_lpe_audio_setup(dev_priv) < 0)
> + DRM_ERROR("failed to setup LPE Audio bridge\n");
> + }
> +
> + if (!IS_LPE_AUDIO_ENABLED(dev_priv))
> + i915_audio_component_init(dev_priv);
>  
>   /*
>* Some ports require correctly set-up hpd registers for detection to
> @@ -1159,7 +1165,10 @@ static void i915_driver_register(struct 
> drm_i915_private *dev_priv)
>   */
>  static void i915_driver_unregister(struct drm_i915_private *dev_priv)
>  {
> - i915_audio_component_cleanup(dev_priv);
> + if (IS_LPE_AUDIO_ENABLED(dev_priv))
> + intel_lpe_audio_teardown(dev_priv);
> + else
> + i915_audio_component_cleanup(dev_priv);
>  
>   intel_gpu_ips_teardown();
>   acpi_video_unregister();
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 91ff3d7..399a8ee 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2087,6 +2087,12 @@ struct drm_i915_private {
>   /* Used to save the pipe-to-encoder mapping for audio */
>   struct intel_encoder *av_enc_map[I915_MAX_PIPES];
>  
> + /* necessary resource sharing with HDMI LPE audio driver. */
> + struct {
> + struct platform_device *platdev;
> + int irq;
> + } lpe_audio;
> +
>   /*
>* NOTE: This is the dri1/ums dungeon, don't add stuff here. Your patch
>* will be rejected. Instead look for a better place.
> @@ -2827,6 +2833,13 @@ struct drm_i915_cmd_table {
>  
>  #define HAS_POOLED_EU(dev)   (INTEL_INFO(dev)->has_pooled_eu)
>  
> +#define HAS_LPE_AUDIO(dev)   (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(dev))
> +#define IS_LPE_AUDIO_ENABLED(dev_priv) \
> + (__I915__(dev_priv)->lpe_audio.platdev != NULL)
> +#define IS_LPE_AUDIO_IRQ_VALID(dev_priv) \
> + (__I915__(dev_priv)->lpe_audio.irq >= 0)
> +
> +
>  #define INTEL_PCH_DEVICE_ID_MASK 0xff00
>  #define INTEL_PCH_IBX_DEVICE_ID_TYPE 0x3b00
>  #define INTEL_PCH_CPT_DEVICE_ID_TYPE 0x1c00
> @@ -3579,6 +3592,12 @@ extern int i915_restore_state(struct drm_device *dev);
>  void i915_setup_sysfs(struct drm_i915_private *dev_priv);
>  void i915_teardown_sysfs(struct drm_i915_private *dev_priv);
>  
> +/* i915_lpe_audio.c */
> +int  intel_lpe_audio_setup(struct drm_i915_private *dev_priv);
> +void intel_lpe_audio_teardown(struct drm_i915_private *dev_priv);
> +void intel_lpe_audio_irq_handler(struct drm_i915_private *dev_priv);
> +int intel_lpe_audio_detect(struct drm_i915_private *dev_priv);
> +
>  

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Respect alternate_ddc_pin for all DDI ports

[Daniel Vetter]

On Thu, Oct 13, 2016 at 09:29:30PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 13, 2016 at 11:06:55AM -0700, Jim Bride wrote:
> > On Tue, Oct 11, 2016 at 08:52:46PM +0300, ville.syrj...@linux.intel.com 
> > wrote:
> > > From: Ville Syrjälä 
> > > 
> > > The VBT provides the platform a way to mix and match the DDI ports vs.
> > > GMBUS pins. Currently we only trust the VBT for DDI E, which I suppose
> > > has no standard GMBUS pin assignment. However, there are machines out
> > > there that use a non-standard mapping for the other ports as well.
> > > Let's start trusting the VBT on this one for all ports on DDI platforms.
> > > 
> > > I've structured the code such that other platforms could easily start
> > > using this as well, by simply filling in the ddi_port_info. IIRC there
> > > may be CHV system that might actually need this.
> > > 
> > > v2: Include a commit message, include a debug message during init
> > > 
> > > Cc: sta...@vger.kernel.org
> > > Cc: Maarten Maathuis 
> > > Tested-by: Maarten Maatt show huis 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97877
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  drivers/gpu/drm/i915/intel_hdmi.c | 84 
> > > ++-
> > >  1 file changed, 48 insertions(+), 36 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
> > > b/drivers/gpu/drm/i915/intel_hdmi.c
> > > index 8d46f5836746..9ca86e901fc8 100644
> > > --- a/drivers/gpu/drm/i915/intel_hdmi.c
> > > +++ b/drivers/gpu/drm/i915/intel_hdmi.c
> > > @@ -1799,6 +1799,50 @@ intel_hdmi_add_properties(struct intel_hdmi 
> > > *intel_hdmi, struct drm_connector *c
> > >   intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> > >  }
> > >  
> > > +static u8 intel_hdmi_ddc_pin(struct drm_i915_private *dev_priv,
> > > +  enum port port)
> > > +{
> > > + const struct ddi_vbt_port_info *info =
> > > + _priv->vbt.ddi_port_info[port];
> > > + u8 ddc_pin;
> > > +
> > > + if (info->alternate_ddc_pin) {
> > > + DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c (VBT)\n",
> > > +   info->alternate_ddc_pin, port_name(port));
> > > + return info->alternate_ddc_pin;
> > > + }
> > > +
> > > + switch (port) {
> > > + case PORT_B:
> > > + if (IS_BROXTON(dev_priv))
> > > + ddc_pin = GMBUS_PIN_1_BXT;
> > > + else
> > > + ddc_pin = GMBUS_PIN_DPB;
> > > + break;
> > > + case PORT_C:
> > > + if (IS_BROXTON(dev_priv))
> > > + ddc_pin = GMBUS_PIN_2_BXT;
> > > + else
> > > + ddc_pin = GMBUS_PIN_DPC;
> > > + break;
> > > + case PORT_D:
> > > + if (IS_CHERRYVIEW(dev_priv))
> > > + ddc_pin = GMBUS_PIN_DPD_CHV;
> > > + else
> > > + ddc_pin = GMBUS_PIN_DPD;
> > 
> > In the code removed below there's a specific case covering Broxton that
> > isn't accounted for here.  Are we sure that we don't need that logic here?
> 
> Yeah, BXT doesn't have port D.
> 
> I guess we could split this up into a few platform specific functions that
> could then have the MISSING_CASE() for the impossible ports. A bit like
> the AUX ctl/data register setup functions we have. Do pople want that
> level of paranoia here?

tbh seems overkill, we should go boom in the platform gmbus code if you
end up with an impossible port.
-Daniel

> 
> > 
> > Jim
> > 
> > > + break;
> > > + default:
> > > + MISSING_CASE(port);
> > > + ddc_pin = GMBUS_PIN_DPB;
> > > + break;
> > > + }
> > > +
> > > + DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c (platform default)\n",
> > > +   ddc_pin, port_name(port));
> > > +
> > > + return ddc_pin;
> > > +}
> > > +
> > >  void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
> > >  struct intel_connector *intel_connector)
> > >  {
> > > @@ -1808,7 +1852,6 @@ void intel_hdmi_init_connector(struct 
> > > intel_digital_port *intel_dig_port,
> > >   struct drm_device *dev = intel_encoder->base.dev;
> > >   struct drm_i915_private *dev_priv = to_i915(dev);
> > >   enum port port = intel_dig_port->port;
> > > - uint8_t alternate_ddc_pin;
> > >  
> > >   DRM_DEBUG_KMS("Adding HDMI connector on port %c\n",
> > > port_name(port));
> > > @@ -1826,12 +1869,10 @@ void intel_hdmi_init_connector(struct 
> > > intel_digital_port *intel_dig_port,
> > >   connector->doublescan_allowed = 0;
> > >   connector->stereo_allowed = 1;
> > >  
> > > + intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
> > > +
> > >   switch (port) {
> > >   case PORT_B:
> > > - if (IS_BROXTON(dev_priv))
> > > - intel_hdmi->ddc_bus = GMBUS_PIN_1_BXT;
> > > - else
> > > - intel_hdmi->ddc_bus = GMBUS_PIN_DPB;
> > >   /*
> > >

[Intel-gfx] [PATCH v3 2/4] drm: Add aspect ratio parsing in DRM layer

[Shashank Sharma]

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Addressed review comments from Sean:
- Fix spellings/typo
- No need to handle aspect ratio none
- Add a break, for default case too

V3: Rebase
---
 drivers/gpu/drm/drm_modes.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 53f07ac..fde927a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
drm_display_mode *mode1,
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
+   mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
 (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
@@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 }
@@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 
+   /* Clearing picture aspect ratio bits from out flags */
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
+   case DRM_MODE_FLAG_PIC_AR_4_3:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_16_9:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+   break;
+   default:
+   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   break;
+   }
+
out->status = drm_mode_validate_basic(out);
if (out->status != MODE_OK)
goto out;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 3/4] video: Add new aspect ratios for HDMI 2.0

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: rebase
V3: rebase
---
 drivers/video/hdmi.c | 4 
 include/linux/hdmi.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1626892..1cf907e 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -533,6 +533,10 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect 
picture_aspect)
return "4:3";
case HDMI_PICTURE_ASPECT_16_9:
return "16:9";
+   case HDMI_PICTURE_ASPECT_64_27:
+   return "64:27";
+   case HDMI_PICTURE_ASPECT_256_135:
+   return "256:135";
case HDMI_PICTURE_ASPECT_RESERVED:
return "Reserved";
}
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index e974420..edbb4fc 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
HDMI_PICTURE_ASPECT_NONE,
HDMI_PICTURE_ASPECT_4_3,
HDMI_PICTURE_ASPECT_16_9,
+   HDMI_PICTURE_ASPECT_64_27,
+   HDMI_PICTURE_ASPECT_256_135,
HDMI_PICTURE_ASPECT_RESERVED,
 };
 
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 4/4] drm: Add and handle new aspect ratios in DRM layer

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch:
-  Adds new DRM flags for to represent these new aspect ratios.
-  Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Rebase
V3: Align macro for DRM_MODE_PICTURE_ASPECT_256_135 (Jim Bride)
---
 drivers/gpu/drm/drm_modes.c | 12 
 include/uapi/drm/drm_mode.h |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index fde927a..173b7d3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1509,6 +1509,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
break;
+   case HDMI_PICTURE_ASPECT_64_27:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
+   break;
+   case DRM_MODE_PICTURE_ASPECT_256_135:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
+   break;
case HDMI_PICTURE_ASPECT_RESERVED:
default:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
@@ -1570,6 +1576,12 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
case DRM_MODE_FLAG_PIC_AR_16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_FLAG_PIC_AR_64_27:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_256_135:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
break;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 5c142b1..084b50a 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -81,6 +81,8 @@ extern "C" {
 #define DRM_MODE_PICTURE_ASPECT_NONE   0
 #define DRM_MODE_PICTURE_ASPECT_4_31
 #define DRM_MODE_PICTURE_ASPECT_16_9   2
+#define DRM_MODE_PICTURE_ASPECT_64_27  3
+#define DRM_MODE_PICTURE_ASPECT_256_1354
 
 /* Aspect ratio flag bitmask (4 bits 22:19) */
 #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
@@ -90,6 +92,10 @@ extern "C" {
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
 #define  DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
+#define  DRM_MODE_FLAG_PIC_AR_64_27 \
+   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
+#define  DRM_MODE_FLAG_PIC_AR_256_135 \
+   (DRM_MODE_PICTURE_ASPECT_256_135<<19)
 
 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 1/4] drm/i915: Add lspcon resume function

[Shashank Sharma]

As per the software design, we are driving lspcon in
PCON mode. But while resuming from suspend, lspcon can go
in LS mode (which is its default operating mode on power on)

This patch adds a resume function for lspcon, which makes sure
its operating in PCON mode, post resume.

V2: Address review comments from Imre
- move lspcon_resume call to encoder->reset()
- use early returns

Signed-off-by: Shashank Sharma 
---
 drivers/gpu/drm/i915/intel_dp.c | 7 ++-
 drivers/gpu/drm/i915/intel_drv.h| 1 +
 drivers/gpu/drm/i915/intel_lspcon.c | 8 
 3 files changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index bc03f61..25f4060 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -4755,11 +4755,16 @@ static void intel_edp_panel_vdd_sanitize(struct 
intel_dp *intel_dp)
 void intel_dp_encoder_reset(struct drm_encoder *encoder)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
-   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
+   struct intel_lspcon *lspcon = _dig_port->lspcon;
+   struct intel_dp *intel_dp = _dig_port->dp;
 
if (!HAS_DDI(dev_priv))
intel_dp->DP = I915_READ(intel_dp->output_reg);
 
+   if (IS_GEN9(dev_priv) && lspcon->active)
+   lspcon_resume(lspcon);
+
if (to_intel_encoder(encoder)->type != INTEL_OUTPUT_EDP)
return;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cde05ff..ea43512 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1856,4 +1856,5 @@ void intel_color_load_luts(struct drm_crtc_state 
*crtc_state);
 
 /* intel_lspcon.c */
 bool lspcon_init(struct intel_digital_port *intel_dig_port);
+void lspcon_resume(struct intel_lspcon *lspcon);
 #endif /* __INTEL_DRV_H__ */
diff --git a/drivers/gpu/drm/i915/intel_lspcon.c 
b/drivers/gpu/drm/i915/intel_lspcon.c
index 628ae6fb..d606f1a 100644
--- a/drivers/gpu/drm/i915/intel_lspcon.c
+++ b/drivers/gpu/drm/i915/intel_lspcon.c
@@ -89,6 +89,14 @@ static bool lspcon_probe(struct intel_lspcon *lspcon)
return true;
 }
 
+void lspcon_resume(struct intel_lspcon *lspcon)
+{
+   if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON, true))
+   DRM_ERROR("LSPCON resume failed\n");
+   else
+   DRM_DEBUG_KMS("LSPCON resume success\n");
+}
+
 bool lspcon_init(struct intel_digital_port *intel_dig_port)
 {
struct intel_dp *dp = _dig_port->dp;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 0/4] Picture aspect ratio support in DRM layer

[Shashank Sharma]

This patch series adds 4 patches.
- The first two patches add aspect ratio support in DRM layes
- Next two patches add new aspect ratios defined in CEA-861-F
  supported for HDMI 2.0 4k modes.

Adding aspect ratio support in DRM layer:
- The CEA videmodes contain aspect ratio information, which we
  parse when we read the modes from EDID. But while transforming
  user_mode to kernel_mode or viceversa, DRM layer lose this
  information.
- HDMI compliance testing for CEA modes, expects the AVI info frames
  to contain exact VIC no for the 'video mode under test'. Now CEA
  modes have different VIC for same modes but different aspect ratio
  for example:
VIC 2 = 720x480@60 4:3
VIC 3 = 720x480@60 16:9
  In this way, lack of aspect ratio information, can cause wrong VIC
  no in AVI IF, causing HDMI complaince test to fail.
- This patch set adds code, which embeds the aspect ratio information
  also in DRM video mode flags, and uses it while comparing two modes.

Adding new aspect ratios for HDMI 2.0
- CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
  modes.
- 64:27
- 256:135
Last two patches in the series, adds code to handle these new
aspect ratios.

V2: Fixed review comments from Sean, Emil, Daniel

V3: Fixed review comment from Jim Bride, got r-b for all patches

Shashank Sharma (4):
  drm/i915: Add lspcon resume function
  drm: Add aspect ratio parsing in DRM layer
  video: Add new aspect ratios for HDMI 2.0
  drm: Add and handle new aspect ratios in DRM layer

 drivers/gpu/drm/drm_modes.c | 43 +
 drivers/gpu/drm/i915/intel_dp.c |  7 +-
 drivers/gpu/drm/i915/intel_drv.h|  1 +
 drivers/gpu/drm/i915/intel_lspcon.c |  8 +++
 drivers/video/hdmi.c|  4 
 include/linux/hdmi.h|  2 ++
 include/uapi/drm/drm_mode.h |  6 ++
 7 files changed, 70 insertions(+), 1 deletion(-)

-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 0/4]: Picture aspect ratio support in DRM layer

[Sharma, Shashank]

Regards

Shashank

On 10/17/2016 5:01 PM, Jose Abreu wrote:

Hi Shashank,


On 17-10-2016 12:32, Shashank Sharma wrote:

This patch series adds 4 patches.
- The first two patches add aspect ratio support in DRM layes
- Next two patches add new aspect ratios defined in CEA-861-F
   supported for HDMI 2.0 4k modes.

Adding aspect ratio support in DRM layer:
- The CEA videmodes contain aspect ratio information, which we
   parse when we read the modes from EDID. But while transforming
   user_mode to kernel_mode or viceversa, DRM layer lose this
   information.
- HDMI compliance testing for CEA modes, expects the AVI info frames
   to contain exact VIC no for the 'video mode under test'. Now CEA
   modes have different VIC for same modes but different aspect ratio
   for example:
 VIC 2 = 720x480@60 4:3
 VIC 3 = 720x480@60 16:9
   In this way, lack of aspect ratio information, can cause wrong VIC
   no in AVI IF, causing HDMI complaince test to fail.
- This patch set adds code, which embeds the aspect ratio information
   also in DRM video mode flags, and uses it while comparing two modes.

Adding new aspect ratios for HDMI 2.0
- CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
   modes.
 - 64:27
 - 256:135
Last two patches in the series, adds code to handle these new
aspect ratios.

V2: Fixed review comments from Sean, Emil, Daniel
V3: Fixed review comments from Jim Bride, got r-b for all patches

Shashank Sharma (4):
   drm: add picture aspect ratio flags
   drm: Add aspect ratio parsing in DRM layer
   video: Add new aspect ratios for HDMI 2.0
   drm: Add and handle new aspect ratios in DRM layer

I am using the previous version of these patches, the
functionality remains the same so you can add my reviewed-by for
the whole series if you want.

Thanks Joes. I will add a V4 with your r-b.

Are you still planning in sending
the patches for the new VIC's introduced in CEA-861-F?

Yes, the very next step is the patch with new VICs.

Regards
Shashank

  drivers/gpu/drm/drm_modes.c | 43 +++
  drivers/video/hdmi.c|  4 
  include/linux/hdmi.h|  2 ++
  include/uapi/drm/drm_mode.h | 24 +++-
  4 files changed, 68 insertions(+), 5 deletions(-)


Best regards,
Jose Miguel Abreu


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 38/41] drm/i915: Defer setting of global seqno on request to submission

[Joonas Lahtinen]

On pe, 2016-10-14 at 13:18 +0100, Chris Wilson wrote:
> Defer the assignment of the global seqno on a request to its submission.
> In the next patch, we will only allocate the global seqno at that time,
> here we are just enabling the wait-for-submission before wait-for-seqno
> paths.
> 
> Signed-off-by: Chris Wilson 

This was already;

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] RFC drm/i915: Add a sunset clause to GPU hang logging

[Joonas Lahtinen]

On pe, 2016-10-14 at 14:44 +0100, Chris Wilson wrote:
> If the kernel is old, more than a few releases old, chances are that the
> user is using an old kernel for a good reason, despite there being GPU
> hangs. After 180days since driver release stop suggesting that they
> should send those reports upstream.
> 
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 

Maybe we could even explicitly state that bugs should be reported to
the distro bugzilla because of running an old kernel?

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] intel-ci: Reorder tests to have vgem-basic@unload tested first

[Chris Wilson]

On Mon, Oct 17, 2016 at 12:53:10PM +0300, Petri Latvala wrote:
> Signed-off-by: Petri Latvala 
> CC: Chris Wilson 
> ---
> 
> (Possible duplicate, I didn't see this arrive on the mailing list myself)
> 
> To match Chris's intention.
> 
> The test itself will receive fixes later, and another module loading
> test will be added at the end. This change is just for mitigation.

The test itself is fine, and working correctly to explain that the
machine setup is unable to even run the controlled unload test. What we
are missing is the information why the CI machines are unhappy.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 0/4]: Picture aspect ratio support in DRM layer

[Shashank Sharma]

This patch series adds 4 patches.
- The first two patches add aspect ratio support in DRM layes
- Next two patches add new aspect ratios defined in CEA-861-F
  supported for HDMI 2.0 4k modes.

Adding aspect ratio support in DRM layer:
- The CEA videmodes contain aspect ratio information, which we
  parse when we read the modes from EDID. But while transforming
  user_mode to kernel_mode or viceversa, DRM layer lose this
  information.
- HDMI compliance testing for CEA modes, expects the AVI info frames
  to contain exact VIC no for the 'video mode under test'. Now CEA
  modes have different VIC for same modes but different aspect ratio
  for example:
VIC 2 = 720x480@60 4:3
VIC 3 = 720x480@60 16:9
  In this way, lack of aspect ratio information, can cause wrong VIC
  no in AVI IF, causing HDMI complaince test to fail.
- This patch set adds code, which embeds the aspect ratio information
  also in DRM video mode flags, and uses it while comparing two modes.

Adding new aspect ratios for HDMI 2.0
- CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
  modes.
- 64:27
- 256:135
Last two patches in the series, adds code to handle these new
aspect ratios.

V2: Fixed review comments from Sean, Emil, Daniel
V3: Fixed review comments from Jim Bride, got r-b for all patches

Shashank Sharma (4):
  drm: add picture aspect ratio flags
  drm: Add aspect ratio parsing in DRM layer
  video: Add new aspect ratios for HDMI 2.0
  drm: Add and handle new aspect ratios in DRM layer

 drivers/gpu/drm/drm_modes.c | 43 +++
 drivers/video/hdmi.c|  4 
 include/linux/hdmi.h|  2 ++
 include/uapi/drm/drm_mode.h | 24 +++-
 4 files changed, 68 insertions(+), 5 deletions(-)

-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 2/4] drm: Add aspect ratio parsing in DRM layer

[Shashank Sharma]

Current DRM layer functions don't parse aspect ratio information
while converting a user mode->kernel mode or vice versa. This
causes modeset to pick mode with wrong aspect ratio, eventually
causing failures in HDMI compliance test cases, due to wrong VIC.

This patch adds aspect ratio information in DRM's mode conversion
and mode comparision functions, to make sure kernel picks mode
with right aspect ratio (as per the VIC).

Signed-off-by: Shashank Sharma 
Signed-off-by: Lin, Jia 
Signed-off-by: Akashdeep Sharma 
Reviewed-by: Jim Bride 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Addressed review comments from Sean:
- Fix spellings/typo
- No need to handle aspect ratio none
- Add a break, for default case too

V3: Rebase
---
 drivers/gpu/drm/drm_modes.c | 31 +++
 1 file changed, 31 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 53f07ac..fde927a 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
drm_display_mode *mode1,
mode1->vsync_end == mode2->vsync_end &&
mode1->vtotal == mode2->vtotal &&
mode1->vscan == mode2->vscan &&
+   mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
(mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
 (mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
return true;
@@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
out->vrefresh = in->vrefresh;
out->flags = in->flags;
out->type = in->type;
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->picture_aspect_ratio) {
+   case HDMI_PICTURE_ASPECT_4_3:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
+   break;
+   case HDMI_PICTURE_ASPECT_16_9:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
+   break;
+   case HDMI_PICTURE_ASPECT_RESERVED:
+   default:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
+   break;
+   }
+
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 }
@@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
 
+   /* Clearing picture aspect ratio bits from out flags */
+   out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
+
+   switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
+   case DRM_MODE_FLAG_PIC_AR_4_3:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_16_9:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
+   break;
+   default:
+   out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
+   break;
+   }
+
out->status = drm_mode_validate_basic(out);
if (out->status != MODE_OK)
goto out;
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Suppress underrun reporting around DP link retraining

[Ville Syrjälä]

On Fri, Oct 14, 2016 at 06:51:37PM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: Suppress underrun reporting around DP link retraining
> URL   : https://patchwork.freedesktop.org/series/13805/
> State : warning

OK, but...

> 
> == Summary ==
> 
> Series 13805v1 drm/i915: Suppress underrun reporting around DP link retraining
> https://patchwork.freedesktop.org/api/1.0/series/13805/revisions/1/mbox/
> 
> Test kms_flip:
> Subgroup basic-flip-vs-wf_vblank:
> dmesg-warn -> PASS   (fi-skl-6770hq)
> dmesg-warn -> PASS   (fi-skl-6700k)
> Test kms_pipe_crc_basic:
> Subgroup read-crc-pipe-a-frame-sequence:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup read-crc-pipe-b:
> dmesg-warn -> PASS   (fi-ilk-650)
> Subgroup suspend-read-crc-pipe-c:
> incomplete -> PASS   (fi-skl-6700k)
> Test vgem_basic:
> Subgroup unload:
> pass   -> SKIP   (fi-hsw-4770)

... where is the warn here?

> 
> fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15 
> fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42 
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30 
> fi-byt-j1900 total:246  pass:213  dwarn:1   dfail:0   fail:1   skip:31 
> fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35 
> fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
> fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22 
> fi-ilk-650   total:246  pass:184  dwarn:0   dfail:0   fail:2   skip:60 
> fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
> fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25 
> fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24 
> fi-skl-6260u total:246  pass:232  dwarn:0   dfail:0   fail:0   skip:14 
> fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23 
> fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24 
> fi-skl-6770hqtotal:246  pass:229  dwarn:1   dfail:0   fail:1   skip:15 
> fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36 
> fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37 
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2727/
> 
> 38ecbe9082e477953fe165265c76e6c6061aeaf6 drm-intel-nightly: 
> 2016y-10m-14d-16h-23m-48s UTC integration manifest
> 171418c drm/i915: Suppress underruns during DP link retraining
> 2a576f6 drm/i915: Extract intel_crtc_pch_transcoder()

-- 
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 v6 5/5] drm/i915: Add lspcon resume function

[Imre Deak]

On pe, 2016-10-14 at 19:56 +0530, Shashank Sharma wrote:
> As per the software design, we are driving lspcon in
> PCON mode. But while resuming from suspend, lspcon can go
> in LS mode (which is its default operating mode on power on)
> 
> This patch adds a resume function for lspcon, which makes sure
> its operating in PCON mode, post resume.
> 
> V2: Address review comments from Imre
>   - move lspcon_resume call to encoder->reset()
>   - use early returns
> 
> Signed-off-by: Shashank Sharma 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/intel_dp.c | 7 ++-
>  drivers/gpu/drm/i915/intel_drv.h| 1 +
>  drivers/gpu/drm/i915/intel_lspcon.c | 8 
>  3 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c
> index bc03f61..25f4060 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -4755,11 +4755,16 @@ static void
> intel_edp_panel_vdd_sanitize(struct intel_dp *intel_dp)
>  void intel_dp_encoder_reset(struct drm_encoder *encoder)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->dev);
> - struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> + struct intel_digital_port *intel_dig_port =
> enc_to_dig_port(encoder);
> + struct intel_lspcon *lspcon = _dig_port->lspcon;
> + struct intel_dp *intel_dp = _dig_port->dp;
>  
>   if (!HAS_DDI(dev_priv))
>   intel_dp->DP = I915_READ(intel_dp->output_reg);
>  
> + if (IS_GEN9(dev_priv) && lspcon->active)
> + lspcon_resume(lspcon);
> +
>   if (to_intel_encoder(encoder)->type != INTEL_OUTPUT_EDP)
>   return;
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index abff78f..0d0de3a 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1850,4 +1850,5 @@ void intel_color_load_luts(struct
> drm_crtc_state *crtc_state);
>  
>  /* intel_lspcon.c */
>  bool lspcon_init(struct intel_digital_port *intel_dig_port);
> +void lspcon_resume(struct intel_lspcon *lspcon);
>  #endif /* __INTEL_DRV_H__ */
> diff --git a/drivers/gpu/drm/i915/intel_lspcon.c
> b/drivers/gpu/drm/i915/intel_lspcon.c
> index 628ae6fb..d606f1a 100644
> --- a/drivers/gpu/drm/i915/intel_lspcon.c
> +++ b/drivers/gpu/drm/i915/intel_lspcon.c
> @@ -89,6 +89,14 @@ static bool lspcon_probe(struct intel_lspcon
> *lspcon)
>   return true;
>  }
>  
> +void lspcon_resume(struct intel_lspcon *lspcon)
> +{
> + if (lspcon_change_mode(lspcon, DRM_LSPCON_MODE_PCON, true))
> + DRM_ERROR("LSPCON resume failed\n");
> + else
> + DRM_DEBUG_KMS("LSPCON resume success\n");
> +}
> +
>  bool lspcon_init(struct intel_digital_port *intel_dig_port)
>  {
>   struct intel_dp *dp = _dig_port->dp;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 14/41] drm/i915: Use a radixtree for random access to the object's backing storage

[Chris Wilson]

On Mon, Oct 17, 2016 at 10:56:27AM +0100, Tvrtko Ursulin wrote:
> 
> On 14/10/2016 15:07, Chris Wilson wrote:
> >On Fri, Oct 14, 2016 at 02:32:03PM +0100, Tvrtko Ursulin wrote:
> >>On 14/10/2016 13:18, Chris Wilson wrote:
> >>>A while ago we switched from a contiguous array of pages into an sglist,
> >>>for that was both more convenient for mapping to hardware and avoided
> >>>the requirement for a vmalloc array of pages on every object. However,
> >>>certain GEM API calls (like pwrite, pread as well as performing
> >>>relocations) do desire access to individual struct pages. A quick hack
> >>>was to introduce a cache of the last access such that finding the
> >>>following page was quick - this works so long as the caller desired
> >>>sequential access. Walking backwards, or multiple callers, still hits a
> >>>slow linear search for each page. One solution is to store each
> >>>successful lookup in a radix tree.
> >>>
> >>>v2: Rewrite building the radixtree for clarity, hopefully.
> >>>
> >>>Signed-off-by: Chris Wilson 
> >>>---
> >>>  drivers/gpu/drm/i915/i915_drv.h |  69 +---
> >>>  drivers/gpu/drm/i915/i915_gem.c | 179 
> >>> +---
> >>>  drivers/gpu/drm/i915/i915_gem_stolen.c  |   4 +-
> >>>  drivers/gpu/drm/i915/i915_gem_userptr.c |   4 +-
> >>>  4 files changed, 193 insertions(+), 63 deletions(-)
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >>>b/drivers/gpu/drm/i915/i915_drv.h
> >>>index 38467dde1efe..53cf4b0e5359 100644
> >>>--- a/drivers/gpu/drm/i915/i915_drv.h
> >>>+++ b/drivers/gpu/drm/i915/i915_drv.h
> >>>@@ -2273,9 +2273,12 @@ struct drm_i915_gem_object {
> >>>   struct sg_table *pages;
> >>>   int pages_pin_count;
> >>>-  struct get_page {
> >>>-  struct scatterlist *sg;
> >>>-  int last;
> >>>+  struct i915_gem_object_page_iter {
> >>>+  struct scatterlist *sg_pos;
> >>>+  unsigned long sg_idx;
> >>We are not consistent in the code with type used for number of pages
> >>in an object. sg_alloc_table even takes an unsigned int for it, so
> >>for as long as we build them as we do, unsigned long is a waste.
> >I know. It's worrying, today there is a possibility that we overflow a
> >32bit size. If this was counting in pages, we would have a few more
> >years of grace. All I can say is that we are fortunate that memory
> >remains expensive in the exabyte range.
> >
> >>>@@ -4338,6 +4349,8 @@ void i915_gem_object_init(struct drm_i915_gem_object 
> >>>*obj,
> >>>   obj->frontbuffer_ggtt_origin = ORIGIN_GTT;
> >>>   obj->madv = I915_MADV_WILLNEED;
> >>>+  INIT_RADIX_TREE(>get_page.radix, GFP_ATOMIC | __GFP_NOWARN);
> >>Pros & cons of GFP_ATOMIC here? Versus perhaps going with the mutex?
> >>I don't know how much data radix tree allocates with this, per node,
> >>but we can have a lot of pages. Would this create extra pressure on
> >>slab shrinking, and in turn out objects?
> >The problem is that we require sg lookup on a !pagefault path, hence
> >mutexes and GFP_KERNEL turn out to be illegal. :|
> 
> Bummer.  I don't know enough about the atomic reserve to judge how
> bad this might be then. Because userspace could drain it easily
> after this work by just pread/pwrite on large objects.

Yes. The pathological case of touching the last page (and only the last
page) will cause large amount of allocation (one page for every 512
pages in the object, and so on recursively - a 64MiB object will require
32 + 1 atomic page allocations, aiui). Not that bad really.

> >>Hmm... I assume failures happen then since you added this fallback.
> >>Due GFP_ATOMIC?
> >No, this was always in the code, because malloc failures happen. Quite
> >often if you run igt ;)
> 
> But GFP_ATOMIC failures primarily, yes?

GFP_ATOMIC certainly increases the likelihood of failure (by removing
the direct reclaim and sleep paths), on the other hand we do get a
reserve pool.
 
> It is a bit unfortunate that with this fancy lookup we can easily
> and silently fall back to linear lookup and lose the performance
> benefit. Do you know how often this happens? Should we have some
> stats collected and exported via debugfs to evaluate on
> realistically busy/loaded systems?

Hmm, in my head I had it wrongly sketched out as basically falling back
to the old behaviour after allocation failure. Ok, if I stored the last
successful allocation (currently sg_idx-1) and the current scan position
separately, we can keep the old style scheme in place for allocation
failure and so not degrade performance for the worst case.

I wasn't planning on seeing failures outside of igt/gem_shrink (with the
exception of people running firefox or chrome!)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 17/42] drm/i915: Pass around sg_table to get_pages/put_pages backend

[Chris Wilson]

On Mon, Oct 17, 2016 at 11:52:27AM +0100, Tvrtko Ursulin wrote:
> 
> On 14/10/2016 10:43, Chris Wilson wrote:
> >On Fri, Oct 14, 2016 at 10:28:42AM +0100, Tvrtko Ursulin wrote:
> >>  diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >>  index 3c22d49005fe..271e63c8f037 100644
> >>  --- a/drivers/gpu/drm/i915/i915_drv.h
> >>  +++ b/drivers/gpu/drm/i915/i915_drv.h
> >>  @@ -2175,8 +2175,8 @@ struct drm_i915_gem_object_ops {
> >>   * being released or under memory pressure (where we attempt to
> >>   * reap pages for the shrinker).
> >>   */
> >>  -   int (*get_pages)(struct drm_i915_gem_object *);
> >>  -   void (*put_pages)(struct drm_i915_gem_object *);
> >>  +   struct sg_table *(*get_pages)(struct drm_i915_gem_object *);
> >>  +   void (*put_pages)(struct drm_i915_gem_object *, struct sg_table 
> >> *);
> >>
> >>Idea is that put_pages vfunc does not need struct mutex?  Or it acquires
> >>it on demand inside it, which means struct mutex will nest inside the
> >>mm.lock?
> >Right, it loses the mutex within get/put pages and I am no longer
> >concerned about the number of workers. Though that is mainly because of
> >another patch to improve execbuf + userptr workloads.
> 
> Is that other patch before or after this one? Or in a different
> series altogether? In any case, why should this change be in this
> patch, especially when it is not commented anywhere?

Actually, it follows from 

commit 364c8172edb5ff0b4650bbd4c45eaab46b84b008
Author: Chris Wilson 
Date:   Thu Aug 18 17:16:58 2016 +0100

drm/i915/userptr: Make gup errors stickier

which was the prelude to the patch I was thinking of. The current code
already doesn't use more than one worker simultaneously.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Suppress underrun reporting around DP link retraining

[Tomi Sarvela]

On Monday, 17 October 2016 14:33:28 EEST Ville Syrjälä wrote:
> On Fri, Oct 14, 2016 at 06:51:37PM -, Patchwork wrote:
> > == Series Details ==
> > 
> > Series: drm/i915: Suppress underrun reporting around DP link retraining
> > URL   : https://patchwork.freedesktop.org/series/13805/
> > State : warning
> 
> OK, but...
> 
> > == Summary ==
> > 
> > Series 13805v1 drm/i915: Suppress underrun reporting around DP link
> > retraining
> > https://patchwork.freedesktop.org/api/1.0/series/13805/revisions/1/mbox/> 
> > 
> > Test vgem_basic:
> > Subgroup unload:
> > pass   -> SKIP   (fi-hsw-4770)
> 
> ... where is the warn here?

This was added to comparison code because I was asked to:

# pass -> SKIP
if testresult < 1 and (lastres == 'pass' and res == 'skip'):
testresult = 1

Unintuitive, but there you go.

Tomi

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 32/41] drm/i915: Rename ->emit_request to ->emit_breadcrumb

[Joonas Lahtinen]

On pe, 2016-10-14 at 13:18 +0100, Chris Wilson wrote:
> Now that the emission of the request tail and its submission to hardware
> are two separate steps, engine->emit_request() is confusing.
> engine->emit_request() is called to emit the breadcrumb commands for the
> request into the ring, name it such (engine->emit_breadcrumb).
> 
> Signed-off-by: Chris Wilson 

Oh my, a patch does precisely what it says in the commit message,
nothing else, nothing less!

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: warning for mm/vmalloc: Replace opencoded 4-level page walkers

[Patchwork]

== Series Details ==

Series: mm/vmalloc: Replace opencoded 4-level page walkers
URL   : https://patchwork.freedesktop.org/series/13822/
State : warning

== Summary ==

Series 13822v1 mm/vmalloc: Replace opencoded 4-level page walkers
https://patchwork.freedesktop.org/api/1.0/series/13822/revisions/1/mbox/

Test drv_module_reload_basic:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
dmesg-warn -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-kbl-7200u)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6770hq)
Test gem_basic:
Subgroup bad-close:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-kbl-7200u)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6770hq)
Subgroup create-close:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-kbl-7200u)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6770hq)
Subgroup create-fd-close:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-kbl-7200u)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6770hq)
Test gem_busy:
Subgroup basic-busy-default:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-kbl-7200u)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6770hq)
Subgroup basic-hang-default:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-kbl-7200u)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6770hq)
Test gem_close_race:
Subgroup basic-process:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-kbl-7200u)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6770hq)
Subgroup basic-threads:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-bdw-5557u)
pass   -> SKIP   (fi-kbl-7200u)
pass   -> SKIP   (fi-skl-6260u)
pass   -> SKIP   (fi-skl-6770hq)
Test gem_cpu_reloc:
Subgroup basic:
pass   -> SKIP   (fi-bxt-t5700)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-skl-6700k)
pass   -> SKIP   (fi-bsw-n3050)
 

[Intel-gfx] [PATCH 10/19] drm/rcar-du: Use new atomic iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/rcar-du/rcar_du_kms.c   | 2 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c 
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index c76ed9ee6a01..153dafac753c 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -312,7 +312,7 @@ static int rcar_du_atomic_commit(struct drm_device *dev,
/* Wait until all affected CRTCs have completed previous commits and
 * mark them as pending.
 */
-   for_each_crtc_in_state(state, crtc, crtc_state, i)
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
commit->crtcs |= drm_crtc_mask(crtc);
 
spin_lock(>commit.wait.lock);
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index a74f8ed8ca2e..b8c35ad9db34 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -144,7 +144,7 @@ int rcar_du_atomic_check_planes(struct drm_device *dev,
struct drm_plane_state *drm_plane_state;
 
/* Check if hardware planes need to be reallocated. */
-   for_each_plane_in_state(state, drm_plane, drm_plane_state, i) {
+   for_each_new_plane_in_state(state, drm_plane, drm_plane_state, i) {
struct rcar_du_plane_state *plane_state;
struct rcar_du_plane *plane;
unsigned int index;
@@ -246,7 +246,7 @@ int rcar_du_atomic_check_planes(struct drm_device *dev,
}
 
/* Reallocate hardware planes for each plane that needs it. */
-   for_each_plane_in_state(state, drm_plane, drm_plane_state, i) {
+   for_each_new_plane_in_state(state, drm_plane, drm_plane_state, i) {
struct rcar_du_plane_state *plane_state;
struct rcar_du_plane *plane;
unsigned int crtc_planes;
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 01/19] drm/atomic: Add new iterators over all state

[Maarten Lankhorst]

Add for_each_(old)(new)_(plane,connector,crtc)_in_state iterators to
replace the old for_each_xxx_in_state ones. This is useful for >1 flip
depth and getting rid of all xxx->state dereferences.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic.c |  6 +++
 drivers/gpu/drm/drm_atomic_helper.c  | 52 +--
 drivers/gpu/drm/i915/intel_display.c | 11 ++---
 include/drm/drm_atomic.h | 81 ++--
 include/drm/drm_atomic_helper.h  |  3 ++
 5 files changed, 142 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 5dd70540219c..120775fcfb70 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -278,6 +278,8 @@ drm_atomic_get_crtc_state(struct drm_atomic_state *state,
return ERR_PTR(-ENOMEM);
 
state->crtcs[index].state = crtc_state;
+   state->crtcs[index].old_state = crtc->state;
+   state->crtcs[index].new_state = crtc_state;
state->crtcs[index].ptr = crtc;
crtc_state->state = state;
 
@@ -640,6 +642,8 @@ drm_atomic_get_plane_state(struct drm_atomic_state *state,
 
state->planes[index].state = plane_state;
state->planes[index].ptr = plane;
+   state->planes[index].old_state = plane->state;
+   state->planes[index].new_state = plane_state;
plane_state->state = state;
 
DRM_DEBUG_ATOMIC("Added [PLANE:%d:%s] %p state to %p\n",
@@ -931,6 +935,8 @@ drm_atomic_get_connector_state(struct drm_atomic_state 
*state,
 
drm_connector_reference(connector);
state->connectors[index].state = connector_state;
+   state->connectors[index].old_state = connector->state;
+   state->connectors[index].new_state = connector_state;
state->connectors[index].ptr = connector;
connector_state->state = state;
 
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 07b432f43b98..fcb6e5b55217 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2495,7 +2495,7 @@ EXPORT_SYMBOL(drm_atomic_helper_disable_all);
  *
  * See also:
  * drm_atomic_helper_duplicate_state(), drm_atomic_helper_disable_all(),
- * drm_atomic_helper_resume()
+ * drm_atomic_helper_resume(), drm_atomic_helper_commit_duplicated_state()
  */
 struct drm_atomic_state *drm_atomic_helper_suspend(struct drm_device *dev)
 {
@@ -2536,6 +2536,52 @@ unlock:
 EXPORT_SYMBOL(drm_atomic_helper_suspend);
 
 /**
+ * drm_atomic_helper_commit_duplicated_state - commit duplicated state
+ * @state: duplicated atomic state to commit
+ * @ctx: pointer to acquire_ctx to use for commit.
+ * @nonblock: commit the state non-blocking.
+ *
+ * The state returned by drm_atomic_helper_duplicate_state() and
+ * drm_atomic_helper_suspend() is partially invalid, and needs to
+ * be fixed up before commit.
+ *
+ * Returns:
+ * 0 on success or a negative error code on failure.
+ *
+ * See also:
+ * drm_atomic_helper_suspend()
+ */
+int drm_atomic_helper_commit_duplicated_state(struct drm_atomic_state *state,
+ struct drm_modeset_acquire_ctx 
*ctx,
+ bool nonblock)
+{
+   int i;
+   struct drm_plane *plane;
+   struct drm_plane_state *plane_state;
+   struct drm_connector *connector;
+   struct drm_connector_state *conn_state;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+
+   state->acquire_ctx = ctx;
+
+   for_each_new_plane_in_state(state, plane, plane_state, i)
+   state->planes[i].old_state = plane->state;
+
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
+   state->crtcs[i].old_state = crtc->state;
+
+   for_each_new_connector_in_state(state, connector, conn_state, i)
+   state->connectors[i].old_state = connector->state;
+
+   if (nonblock)
+   return drm_atomic_nonblocking_commit(state);
+   else
+   return drm_atomic_commit(state);
+}
+EXPORT_SYMBOL(drm_atomic_helper_commit_duplicated_state);
+
+/**
  * drm_atomic_helper_resume - subsystem-level resume helper
  * @dev: DRM device
  * @state: atomic state to resume to
@@ -2558,9 +2604,9 @@ int drm_atomic_helper_resume(struct drm_device *dev,
int err;
 
drm_mode_config_reset(dev);
+
drm_modeset_lock_all(dev);
-   state->acquire_ctx = config->acquire_ctx;
-   err = drm_atomic_commit(state);
+   err = drm_atomic_helper_commit_duplicated_state(state, 
config->acquire_ctx, false);
drm_modeset_unlock_all(dev);
 
return err;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a12e093c54cf..3bd3f6a93c12 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3497,7 +3497,8 @@ static void 

[Intel-gfx] [PATCH 04/19] drm/blend: Use new atomic iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_blend.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index 85172a977bf3..70c03eb032fc 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -367,27 +367,27 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
  struct drm_atomic_state *state)
 {
struct drm_crtc *crtc;
-   struct drm_crtc_state *crtc_state;
+   struct drm_crtc_state *old_crtc_state, *new_crtc_state;
struct drm_plane *plane;
-   struct drm_plane_state *plane_state;
+   struct drm_plane_state *old_plane_state, *new_plane_state;
int i, ret = 0;
 
-   for_each_plane_in_state(state, plane, plane_state, i) {
-   crtc = plane_state->crtc;
+   for_each_oldnew_plane_in_state(state, plane, old_plane_state, 
new_plane_state, i) {
+   crtc = new_plane_state->crtc;
if (!crtc)
continue;
-   if (plane->state->zpos != plane_state->zpos) {
-   crtc_state =
+   if (old_plane_state->zpos != new_plane_state->zpos) {
+   new_crtc_state =
drm_atomic_get_existing_crtc_state(state, crtc);
-   crtc_state->zpos_changed = true;
+   new_crtc_state->zpos_changed = true;
}
}
 
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
-   if (crtc_state->plane_mask != crtc->state->plane_mask ||
-   crtc_state->zpos_changed) {
+   for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   if (old_crtc_state->plane_mask != new_crtc_state->plane_mask ||
+   new_crtc_state->zpos_changed) {
ret = drm_atomic_helper_crtc_normalize_zpos(crtc,
-   crtc_state);
+   
new_crtc_state);
if (ret)
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 08/19] drm/vc4: Use new atomic iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/vc4/vc4_kms.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index f31f72af8551..76cc9b374215 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -111,7 +111,7 @@ static int vc4_atomic_commit(struct drm_device *dev,
uint64_t wait_seqno = 0;
struct vc4_commit *c;
struct drm_plane *plane;
-   struct drm_plane_state *new_state;
+   struct drm_plane_state *old_state, *new_state;
 
c = commit_init(state);
if (!c)
@@ -139,8 +139,8 @@ static int vc4_atomic_commit(struct drm_device *dev,
return ret;
}
 
-   for_each_plane_in_state(state, plane, new_state, i) {
-   if ((plane->state->fb != new_state->fb) && new_state->fb) {
+   for_each_oldnew_plane_in_state(state, plane, old_state, new_state, i) {
+   if (old_state->fb != new_state->fb && new_state->fb) {
struct drm_gem_cma_object *cma_bo =
drm_fb_cma_get_gem_obj(new_state->fb, 0);
struct vc4_bo *bo = to_vc4_bo(_bo->base);
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 07/19] drm/atomic: Fix atomic helpers to use the new iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c | 302 +++-
 1 file changed, 157 insertions(+), 145 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index fcb6e5b55217..c8aba493fc17 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -103,7 +103,7 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
 * part of the state. If the same encoder is assigned to multiple
 * connectors bail out.
 */
-   for_each_connector_in_state(state, connector, conn_state, i) {
+   for_each_new_connector_in_state(state, connector, conn_state, i) {
const struct drm_connector_helper_funcs *funcs = 
connector->helper_private;
struct drm_encoder *new_encoder;
 
@@ -238,22 +238,22 @@ steal_encoder(struct drm_atomic_state *state,
 {
struct drm_crtc_state *crtc_state;
struct drm_connector *connector;
-   struct drm_connector_state *connector_state;
+   struct drm_connector_state *old_connector_state, *new_connector_state;
int i;
 
-   for_each_connector_in_state(state, connector, connector_state, i) {
+   for_each_oldnew_connector_in_state(state, connector, 
old_connector_state, new_connector_state, i) {
struct drm_crtc *encoder_crtc;
 
-   if (connector_state->best_encoder != encoder)
+   if (new_connector_state->best_encoder != encoder)
continue;
 
-   encoder_crtc = connector->state->crtc;
+   encoder_crtc = old_connector_state->crtc;
 
DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] in use on [CRTC:%d:%s], 
stealing it\n",
 encoder->base.id, encoder->name,
 encoder_crtc->base.id, encoder_crtc->name);
 
-   set_best_encoder(state, connector_state, NULL);
+   set_best_encoder(state, new_connector_state, NULL);
 
crtc_state = drm_atomic_get_existing_crtc_state(state, 
encoder_crtc);
crtc_state->connectors_changed = true;
@@ -265,7 +265,8 @@ steal_encoder(struct drm_atomic_state *state,
 static int
 update_connector_routing(struct drm_atomic_state *state,
 struct drm_connector *connector,
-struct drm_connector_state *connector_state)
+struct drm_connector_state *old_connector_state,
+struct drm_connector_state *new_connector_state)
 {
const struct drm_connector_helper_funcs *funcs;
struct drm_encoder *new_encoder;
@@ -275,24 +276,24 @@ update_connector_routing(struct drm_atomic_state *state,
 connector->base.id,
 connector->name);
 
-   if (connector->state->crtc != connector_state->crtc) {
-   if (connector->state->crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
connector->state->crtc);
+   if (old_connector_state->crtc != new_connector_state->crtc) {
+   if (old_connector_state->crtc) {
+   crtc_state = drm_atomic_get_existing_crtc_state(state, 
old_connector_state->crtc);
crtc_state->connectors_changed = true;
}
 
-   if (connector_state->crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
connector_state->crtc);
+   if (new_connector_state->crtc) {
+   crtc_state = drm_atomic_get_existing_crtc_state(state, 
new_connector_state->crtc);
crtc_state->connectors_changed = true;
}
}
 
-   if (!connector_state->crtc) {
+   if (!new_connector_state->crtc) {
DRM_DEBUG_ATOMIC("Disabling [CONNECTOR:%d:%s]\n",
connector->base.id,
connector->name);
 
-   set_best_encoder(state, connector_state, NULL);
+   set_best_encoder(state, new_connector_state, NULL);
 
return 0;
}
@@ -301,7 +302,7 @@ update_connector_routing(struct drm_atomic_state *state,
 
if (funcs->atomic_best_encoder)
new_encoder = funcs->atomic_best_encoder(connector,
-connector_state);
+new_connector_state);
else if (funcs->best_encoder)
new_encoder = funcs->best_encoder(connector);
else
@@ -314,33 +315,33 @@ update_connector_routing(struct drm_atomic_state *state,
return -EINVAL;
}
 
-   if (!drm_encoder_crtc_ok(new_encoder, connector_state->crtc)) {
+   if (!drm_encoder_crtc_ok(new_encoder, new_connector_state->crtc)) {
  

[Intel-gfx] [PATCH 02/19] drm/atmel-hlcdc: Use new atomic iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
index 9b17a66cf0e1..b5af77097033 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c
@@ -268,7 +268,7 @@ static int atmel_hlcdc_crtc_select_output_mode(struct 
drm_crtc_state *state)
 
crtc = drm_crtc_to_atmel_hlcdc_crtc(state->crtc);
 
-   for_each_connector_in_state(state->state, connector, cstate, i) {
+   for_each_new_connector_in_state(state->state, connector, cstate, i) {
struct drm_display_info *info = >display_info;
unsigned int supported_fmts = 0;
int j;
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 19/19] drm/atomic: Rename atomic oldnew iterator

[Maarten Lankhorst]

With the old users of for_each_obj_in_state gone, we can rename
for_each_oldnew_obj_in_state back to that name. It's slightly less
ugly.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c | 34 ++---
 drivers/gpu/drm/drm_blend.c |  4 ++--
 drivers/gpu/drm/i915/intel_display.c| 16 +++---
 drivers/gpu/drm/imx/imx-drm-core.c  |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c |  2 +-
 drivers/gpu/drm/msm/msm_atomic.c|  2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  2 +-
 drivers/gpu/drm/vc4/vc4_kms.c   |  2 +-
 include/drm/drm_atomic.h| 30 +++--
 9 files changed, 35 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index c8aba493fc17..8fb955181641 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -241,7 +241,7 @@ steal_encoder(struct drm_atomic_state *state,
struct drm_connector_state *old_connector_state, *new_connector_state;
int i;
 
-   for_each_oldnew_connector_in_state(state, connector, 
old_connector_state, new_connector_state, i) {
+   for_each_connector_in_state(state, connector, old_connector_state, 
new_connector_state, i) {
struct drm_crtc *encoder_crtc;
 
if (new_connector_state->best_encoder != encoder)
@@ -482,7 +482,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
struct drm_connector_state *old_connector_state, *new_connector_state;
int i, ret;
 
-   for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   for_each_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) {
if (!drm_mode_equal(_crtc_state->mode, 
_crtc_state->mode)) {
DRM_DEBUG_ATOMIC("[CRTC:%d:%s] mode changed\n",
 crtc->base.id, crtc->name);
@@ -510,7 +510,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (ret)
return ret;
 
-   for_each_oldnew_connector_in_state(state, connector, 
old_connector_state, new_connector_state, i) {
+   for_each_connector_in_state(state, connector, old_connector_state, 
new_connector_state, i) {
/*
 * This only sets crtc->connectors_changed for routing changes,
 * drivers must set crtc->connectors_changed themselves when
@@ -529,7 +529,7 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
 * configuration. This must be done before calling mode_fixup in case a
 * crtc only changed its mode but has the same set of connectors.
 */
-   for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   for_each_crtc_in_state(state, crtc, old_crtc_state, new_crtc_state, i) {
bool has_connectors =
!!new_crtc_state->connector_mask;
 
@@ -685,7 +685,7 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
struct drm_crtc_state *old_crtc_state, *new_crtc_state;
int i;
 
-   for_each_oldnew_connector_in_state(old_state, connector, 
old_conn_state, new_conn_state, i) {
+   for_each_connector_in_state(old_state, connector, old_conn_state, 
new_conn_state, i) {
const struct drm_encoder_helper_funcs *funcs;
struct drm_encoder *encoder;
 
@@ -733,7 +733,7 @@ disable_outputs(struct drm_device *dev, struct 
drm_atomic_state *old_state)
drm_bridge_post_disable(encoder->bridge);
}
 
-   for_each_oldnew_crtc_in_state(old_state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   for_each_crtc_in_state(old_state, crtc, old_crtc_state, new_crtc_state, 
i) {
const struct drm_crtc_helper_funcs *funcs;
 
/* Shut down everything that needs a full modeset. */
@@ -785,7 +785,7 @@ drm_atomic_helper_update_legacy_modeset_state(struct 
drm_device *dev,
int i;
 
/* clear out existing links and update dpms */
-   for_each_oldnew_connector_in_state(old_state, connector, 
old_conn_state, new_conn_state, i) {
+   for_each_connector_in_state(old_state, connector, old_conn_state, 
new_conn_state, i) {
if (connector->encoder) {
WARN_ON(!connector->encoder->crtc);
 
@@ -1074,7 +1074,7 @@ bool drm_atomic_helper_framebuffer_changed(struct 
drm_device *dev,
struct drm_plane_state *old_plane_state, *new_plane_state;
int i;
 
-   for_each_oldnew_plane_in_state(old_state, plane, old_plane_state, 
new_plane_state, i) {
+   for_each_plane_in_state(old_state, plane, old_plane_state, 
new_plane_state, i) {
if (new_plane_state->crtc != crtc &&
old_plane_state->crtc != crtc)
  

[Intel-gfx] [PATCH 09/19] drm/rockchip: Use new atomic iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index c7eba305c488..5c0625e5dca1 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1009,7 +1009,7 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
  struct drm_crtc_state *old_crtc_state)
 {
struct drm_atomic_state *old_state = old_crtc_state->state;
-   struct drm_plane_state *old_plane_state;
+   struct drm_plane_state *old_plane_state, *new_plane_state;
struct vop *vop = to_vop(crtc);
struct drm_plane *plane;
int i;
@@ -1040,11 +1040,11 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
}
spin_unlock_irq(>dev->event_lock);
 
-   for_each_plane_in_state(old_state, plane, old_plane_state, i) {
+   for_each_oldnew_plane_in_state(old_state, plane, old_plane_state, 
new_plane_state, i) {
if (!old_plane_state->fb)
continue;
 
-   if (old_plane_state->fb == plane->state->fb)
+   if (old_plane_state->fb == new_plane_state->fb)
continue;
 
drm_framebuffer_reference(old_plane_state->fb);
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 15/19] drm/i915: Use new atomic iterator macros in ddi

[Maarten Lankhorst]

Also make the function static, it's only used inside intel_ddi.c

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
 drivers/gpu/drm/i915/intel_drv.h | 2 --
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 15d47c87def6..0e79c84e14e0 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -740,7 +740,7 @@ intel_ddi_get_crtc_encoder(struct drm_crtc *crtc)
return ret;
 }
 
-struct intel_encoder *
+static struct intel_encoder *
 intel_ddi_get_crtc_new_encoder(struct intel_crtc_state *crtc_state)
 {
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
@@ -753,7 +753,7 @@ intel_ddi_get_crtc_new_encoder(struct intel_crtc_state 
*crtc_state)
 
state = crtc_state->base.state;
 
-   for_each_connector_in_state(state, connector, connector_state, i) {
+   for_each_new_connector_in_state(state, connector, connector_state, i) {
if (connector_state->crtc != crtc_state->base.crtc)
continue;
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 8fd16adf069b..588d8af68043 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1156,8 +1156,6 @@ void intel_ddi_prepare_link_retrain(struct intel_dp 
*intel_dp);
 bool intel_ddi_connector_get_hw_state(struct intel_connector *intel_connector);
 void intel_ddi_get_config(struct intel_encoder *encoder,
  struct intel_crtc_state *pipe_config);
-struct intel_encoder *
-intel_ddi_get_crtc_new_encoder(struct intel_crtc_state *crtc_state);
 
 void intel_ddi_init_dp_buf_reg(struct intel_encoder *encoder);
 void intel_ddi_clock_get(struct intel_encoder *encoder,
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 18/19] drm/i915: Use new atomic iterator macros in display code

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 156 ++-
 1 file changed, 80 insertions(+), 76 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 3bd3f6a93c12..d310abace86a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3510,7 +3510,12 @@ __intel_display_resume(struct drm_device *dev,
if (!state)
return 0;
 
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   /*
+* We've duplicated the state, pointers to the old state are invalid.
+*
+* Don't attempt to use the old state until we commit the duplicated 
state.
+*/
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
/*
 * Force recalculation even if we restore
 * current state. With fast modeset this may not result
@@ -5078,13 +5083,12 @@ static void intel_post_plane_update(struct 
intel_crtc_state *old_crtc_state)
}
 }
 
-static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state)
+static void intel_pre_plane_update(struct intel_crtc_state *old_crtc_state,
+  struct intel_crtc_state *pipe_config)
 {
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   struct intel_crtc_state *pipe_config =
-   to_intel_crtc_state(crtc->base.state);
struct drm_atomic_state *old_state = old_crtc_state->base.state;
struct drm_plane *primary = crtc->base.primary;
struct drm_plane_state *old_pri_state =
@@ -5186,12 +5190,11 @@ static void intel_encoders_pre_pll_enable(struct 
drm_crtc *crtc,
  struct intel_crtc_state *crtc_state,
  struct drm_atomic_state *old_state)
 {
-   struct drm_connector_state *old_conn_state;
+   struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;
 
-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
-   struct drm_connector_state *conn_state = conn->state;
+   for_each_new_connector_in_state(old_state, conn, conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(conn_state->best_encoder);
 
@@ -5207,12 +5210,11 @@ static void intel_encoders_pre_enable(struct drm_crtc 
*crtc,
  struct intel_crtc_state *crtc_state,
  struct drm_atomic_state *old_state)
 {
-   struct drm_connector_state *old_conn_state;
+   struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;
 
-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
-   struct drm_connector_state *conn_state = conn->state;
+   for_each_new_connector_in_state(old_state, conn, conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(conn_state->best_encoder);
 
@@ -5228,12 +5230,11 @@ static void intel_encoders_enable(struct drm_crtc *crtc,
  struct intel_crtc_state *crtc_state,
  struct drm_atomic_state *old_state)
 {
-   struct drm_connector_state *old_conn_state;
+   struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;
 
-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
-   struct drm_connector_state *conn_state = conn->state;
+   for_each_new_connector_in_state(old_state, conn, conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(conn_state->best_encoder);
 
@@ -5253,7 +5254,7 @@ static void intel_encoders_disable(struct drm_crtc *crtc,
struct drm_connector *conn;
int i;
 
-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
+   for_each_old_connector_in_state(old_state, conn, old_conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(old_conn_state->best_encoder);
 
@@ -5273,7 +5274,7 @@ static void intel_encoders_post_disable(struct drm_crtc 
*crtc,
struct drm_connector *conn;
int i;
 
-   for_each_connector_in_state(old_state, conn, old_conn_state, i) {
+   for_each_old_connector_in_state(old_state, conn, old_conn_state, i) {
struct intel_encoder *encoder =
to_intel_encoder(old_conn_state->best_encoder);
 
@@ -5293,7 +5294,7 @@ static void intel_encoders_post_pll_disable(struct 
drm_crtc *crtc,
struct drm_connector *conn;
int i;
 
-   

[Intel-gfx] [PATCH 12/19] drm/msm: Use new atomic iterator macros

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c   |  4 ++--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   |  6 +++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h   |  3 ++-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c |  4 ++--
 drivers/gpu/drm/msm/msm_atomic.c  | 16 
 5 files changed, 17 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
index 571a91ee9607..d18d0a0e0a35 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c
@@ -113,7 +113,7 @@ static void mdp4_prepare_commit(struct msm_kms *kms, struct 
drm_atomic_state *st
mdp4_enable(mdp4_kms);
 
/* see 119ecb7fd */
-   for_each_crtc_in_state(state, crtc, crtc_state, i)
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
drm_crtc_vblank_get(crtc);
 }
 
@@ -125,7 +125,7 @@ static void mdp4_complete_commit(struct msm_kms *kms, 
struct drm_atomic_state *s
struct drm_crtc_state *crtc_state;
 
/* see 119ecb7fd */
-   for_each_crtc_in_state(state, crtc, crtc_state, i)
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
drm_crtc_vblank_put(crtc);
 
mdp4_disable(mdp4_kms);
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index ed7143d35b25..7cfeb0455039 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -82,10 +82,10 @@ static void mdp5_complete_commit(struct msm_kms *kms, 
struct drm_atomic_state *s
int i;
struct mdp5_kms *mdp5_kms = to_mdp5_kms(to_mdp_kms(kms));
struct drm_plane *plane;
-   struct drm_plane_state *plane_state;
+   struct drm_plane_state *old_state, *new_state;
 
-   for_each_plane_in_state(state, plane, plane_state, i)
-   mdp5_plane_complete_commit(plane, plane_state);
+   for_each_oldnew_plane_in_state(state, plane, old_state, new_state, i)
+   mdp5_plane_complete_commit(plane, old_state, new_state);
 
mdp5_disable(mdp5_kms);
 }
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
index 03738927be10..90e80619fc54 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.h
@@ -198,7 +198,8 @@ void mdp5_irq_domain_fini(struct mdp5_kms *mdp5_kms);
 uint32_t mdp5_plane_get_flush(struct drm_plane *plane);
 void mdp5_plane_complete_flip(struct drm_plane *plane);
 void mdp5_plane_complete_commit(struct drm_plane *plane,
-   struct drm_plane_state *state);
+   struct drm_plane_state *old_state,
+   struct drm_plane_state *new_state);
 enum mdp5_pipe mdp5_plane_pipe(struct drm_plane *plane);
 struct drm_plane *mdp5_plane_init(struct drm_device *dev,
enum mdp5_pipe pipe, bool private_plane,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index 951c002b05df..19c44b968f4e 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -859,13 +859,13 @@ uint32_t mdp5_plane_get_flush(struct drm_plane *plane)
 
 /* called after vsync in thread context */
 void mdp5_plane_complete_commit(struct drm_plane *plane,
-   struct drm_plane_state *state)
+   struct drm_plane_state *old_state, struct drm_plane_state *new_state)
 {
struct mdp5_kms *mdp5_kms = get_kms(plane);
struct mdp5_plane *mdp5_plane = to_mdp5_plane(plane);
enum mdp5_pipe pipe = mdp5_plane->pipe;
 
-   if (!plane_enabled(plane->state) && mdp5_kms->smp) {
+   if (!plane_enabled(new_state) && mdp5_kms->smp) {
DBG("%s: free SMP", mdp5_plane->name);
mdp5_smp_release(mdp5_kms->smp, pipe);
}
diff --git a/drivers/gpu/drm/msm/msm_atomic.c b/drivers/gpu/drm/msm/msm_atomic.c
index db193f835298..333c379e6561 100644
--- a/drivers/gpu/drm/msm/msm_atomic.c
+++ b/drivers/gpu/drm/msm/msm_atomic.c
@@ -89,8 +89,8 @@ static void msm_atomic_wait_for_commit_done(struct drm_device 
*dev,
struct msm_kms *kms = priv->kms;
int i;
 
-   for_each_crtc_in_state(old_state, crtc, crtc_state, i) {
-   if (!crtc->state->enable)
+   for_each_new_crtc_in_state(old_state, crtc, crtc_state, i) {
+   if (!crtc_state->enable)
continue;
 
/* Legacy cursor ioctls are completely unsynced, and userspace
@@ -191,7 +191,7 @@ int msm_atomic_commit(struct drm_device *dev,
struct drm_crtc *crtc;
struct drm_crtc_state *crtc_state;
struct drm_plane *plane;
-   struct drm_plane_state *plane_state;
+   struct drm_plane_state *new_plane_state, *old_plane_state;
int i, ret;
 
ret = drm_atomic_helper_prepare_planes(dev, state);
@@ -207,18 +207,18 @@ int 

[Intel-gfx] [PATCH 13/19] drm/imx: Use new atomic iterator macros

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/imx/imx-drm-core.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/imx/imx-drm-core.c 
b/drivers/gpu/drm/imx/imx-drm-core.c
index 98df09c2b388..d484af773460 100644
--- a/drivers/gpu/drm/imx/imx-drm-core.c
+++ b/drivers/gpu/drm/imx/imx-drm-core.c
@@ -155,7 +155,7 @@ static int imx_drm_atomic_commit(struct drm_device *dev,
 struct drm_atomic_state *state,
 bool nonblock)
 {
-   struct drm_plane_state *plane_state;
+   struct drm_plane_state *old_plane_state, *new_plane_state;
struct drm_plane *plane;
struct dma_buf *dma_buf;
int i;
@@ -164,13 +164,13 @@ static int imx_drm_atomic_commit(struct drm_device *dev,
 * If the plane fb has an dma-buf attached, fish out the exclusive
 * fence for the atomic helper to wait on.
 */
-   for_each_plane_in_state(state, plane, plane_state, i) {
-   if ((plane->state->fb != plane_state->fb) && plane_state->fb) {
-   dma_buf = drm_fb_cma_get_gem_obj(plane_state->fb,
+   for_each_oldnew_plane_in_state(state, plane, old_plane_state, 
new_plane_state, i) {
+   if ((old_plane_state->fb != new_plane_state->fb) && 
new_plane_state->fb) {
+   dma_buf = drm_fb_cma_get_gem_obj(new_plane_state->fb,
 0)->base.dma_buf;
if (!dma_buf)
continue;
-   plane_state->fence =
+   new_plane_state->fence =
reservation_object_get_excl_rcu(dma_buf->resv);
}
}
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 05/19] drm/atomic: Make add_affected_connectors look at crtc_state.

[Maarten Lankhorst]

This kills another dereference of connector->state. connector_mask
holds all unchanged connectors at least and any changed connectors
are already in state anyway.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 120775fcfb70..1915ec44f7eb 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1230,8 +1230,13 @@ drm_atomic_add_affected_connectors(struct 
drm_atomic_state *state,
struct drm_mode_config *config = >dev->mode_config;
struct drm_connector *connector;
struct drm_connector_state *conn_state;
+   struct drm_crtc_state *crtc_state;
int ret;
 
+   crtc_state = drm_atomic_get_crtc_state(state, crtc);
+   if (IS_ERR(crtc_state))
+   return PTR_ERR(crtc_state);
+
ret = drm_modeset_lock(>connection_mutex, state->acquire_ctx);
if (ret)
return ret;
@@ -1240,11 +1245,11 @@ drm_atomic_add_affected_connectors(struct 
drm_atomic_state *state,
 crtc->base.id, crtc->name, state);
 
/*
-* Changed connectors are already in @state, so only need to look at the
-* current configuration.
+* Changed connectors are already in @state, so only need to look
+* at the connector_mask in crtc_state.
 */
drm_for_each_connector(connector, state->dev) {
-   if (connector->state->crtc != crtc)
+   if (!(crtc_state->connector_mask & (1 << 
drm_connector_index(connector
continue;
 
conn_state = drm_atomic_get_connector_state(state, connector);
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] Uevent for retraining in case of link training failure in atomic commit phase

[Ville Syrjälä]

On Sun, Oct 16, 2016 at 10:51:30PM -0700, Manasi Navare wrote:
> Hi,
> 
> I am working on adding a link rate fallback in case of link training failure.
> If the link training fails at a specific link rate/lane count in atomic
> commit phase, I validate the modes again based on the link rate lower than
> the failed link rate and prune the invalid modes accordingly to update the
> connector->modes list. I then send a hotplug uevent to the userspace, 
> expecting
> it to detect the change in the mode list and trigger a modeset during which
> the link would be retrained to a lower link rate.
> 
> After looking at the userspace debug logs, I see that after it recieves this
> uevent on link failure, 
> xf86-video-intel/src/sna/sna_mode_display.c/sna_mode_discover(),
> calls output_check_status() which only detects a state change if it is 
> changed from 
> connected to disconnected or vice versa. So change in the modelist does not 
> get detected 
> as connector status changed and it notifies "state retained", does not call 
> RRGetInfo() 
> and does not trigger a new modeset.

Hmm. The code definitely checks if the number of modes has changed. Oh,
but maybe there's just a little bug:

if (output->num_modes != compat_conn.conn.count_modes)
-   return true;
+   return false;

Chris, does that look right?

> 
> If in case of link train failure, I force the connector status to be 
> disconnected
> then it clears the state, disables all the PLLs, triggers a new modeset. 
> However during
> this time, the CTS test times out (10ms) and hence compliance fails.
> 
> Is there any other way, we can force the userspace to detect a change in the 
> connector
> state so that it triggers a full modeset without forcing the connector state 
> to be disconnected?
> 
> The pieces of  /var/log/Xorg.0.log that capture the sna_mode_discover are 
> pasted here:
> http://paste.ubuntu.com/23337284/
> In this log, the third call to sna_mode_discover maps to the uevent sent due 
> to link
> failure where it indicates state retained and does not do anything further.
> 
> The Kernel dmesg log in case of forcing the connector status to disconnected 
> is:
> http://paste.ubuntu.com/23337285/
> 
> Please let me know if any of you have suggestions, I am not a userspace 
> expert.
> This test is done with Ubuntu 16.04 and CTS run using DPR-120 test 4.3.1.3
> 
> Regards
> Manasi

-- 
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 17/41] drm/i915: Pass around sg_table to get_pages/put_pages backend

[Tvrtko Ursulin]

On 14/10/2016 13:18, Chris Wilson wrote:

The plan is to move obj->pages out from under the struct_mutex into its
own per-object lock. We need to prune any assumption of the struct_mutex
from the get_pages/put_pages backends, and to make it easier we pass
around the sg_table to operate on rather than indirectly via the obj.

Signed-off-by: Chris Wilson 
---
  drivers/gpu/drm/i915/i915_drv.h  |  36 +--
  drivers/gpu/drm/i915/i915_gem.c  | 172 +++
  drivers/gpu/drm/i915/i915_gem_dmabuf.c   |  20 ++--
  drivers/gpu/drm/i915/i915_gem_fence.c|  17 +--
  drivers/gpu/drm/i915/i915_gem_gtt.c  |  19 ++--
  drivers/gpu/drm/i915/i915_gem_gtt.h  |   6 +-
  drivers/gpu/drm/i915/i915_gem_internal.c |  23 ++---
  drivers/gpu/drm/i915/i915_gem_shrinker.c |  11 +-
  drivers/gpu/drm/i915/i915_gem_stolen.c   |  43 
  drivers/gpu/drm/i915/i915_gem_userptr.c  |  88 
  10 files changed, 227 insertions(+), 208 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 95ad35773b2a..ebadb5e55476 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2172,8 +2172,8 @@ struct drm_i915_gem_object_ops {
 * being released or under memory pressure (where we attempt to
 * reap pages for the shrinker).
 */
-   int (*get_pages)(struct drm_i915_gem_object *);
-   void (*put_pages)(struct drm_i915_gem_object *);
+   struct sg_table *(*get_pages)(struct drm_i915_gem_object *);
+   void (*put_pages)(struct drm_i915_gem_object *, struct sg_table *);
  
  	int (*dmabuf_export)(struct drm_i915_gem_object *);

void (*release)(struct drm_i915_gem_object *);
@@ -2308,8 +2308,6 @@ struct drm_i915_gem_object {
struct i915_gem_userptr {
uintptr_t ptr;
unsigned read_only :1;
-   unsigned workers :4;
-#define I915_GEM_USERPTR_MAX_WORKERS 15


Open in another thread.

  
  		struct i915_mm_struct *mm;

struct i915_mmu_object *mmu_object;
@@ -2371,6 +2369,19 @@ __deprecated
  extern void drm_gem_object_unreference_unlocked(struct drm_gem_object *);
  
  static inline bool

+i915_gem_object_is_dead(const struct drm_i915_gem_object *obj)
+{
+   return atomic_read(>base.refcount.refcount) == 0;
+}
+
+#if IS_ENABLED(CONFIG_LOCKDEP)
+#define lockdep_assert_held_unless(lock, cond) \
+   GEM_BUG_ON(debug_locks && !lockdep_is_held(lock) && !(cond))
+#else
+#define lockdep_assert_held_unless(lock, cond)
+#endif
+
+static inline bool
  i915_gem_object_has_struct_page(const struct drm_i915_gem_object *obj)
  {
return obj->ops->flags & I915_GEM_OBJECT_HAS_STRUCT_PAGE;
@@ -3196,6 +3207,8 @@ dma_addr_t
  i915_gem_object_get_dma_address(struct drm_i915_gem_object *obj,
unsigned long n);
  
+void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,

+struct sg_table *pages);
  int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj);
  
  static inline int __must_check

@@ -3212,7 +3225,8 @@ i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
  static inline void
  __i915_gem_object_pin_pages(struct drm_i915_gem_object *obj)
  {
-   lockdep_assert_held(>base.dev->struct_mutex);
+   lockdep_assert_held_unless(>base.dev->struct_mutex,
+  i915_gem_object_is_dead(obj));
GEM_BUG_ON(!obj->mm.pages);
  
  	obj->mm.pages_pin_count++;

@@ -3227,7 +3241,8 @@ i915_gem_object_has_pinned_pages(struct 
drm_i915_gem_object *obj)
  static inline void
  __i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)
  {
-   lockdep_assert_held(>base.dev->struct_mutex);
+   lockdep_assert_held_unless(>base.dev->struct_mutex,
+  i915_gem_object_is_dead(obj));
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
GEM_BUG_ON(!obj->mm.pages);
  
@@ -3239,7 +3254,8 @@ static inline void i915_gem_object_unpin_pages(struct drm_i915_gem_object *obj)

__i915_gem_object_unpin_pages(obj);
  }
  
-int __i915_gem_object_put_pages(struct drm_i915_gem_object *obj);

+void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj);
+void __i915_gem_object_invalidate(struct drm_i915_gem_object *obj);
  
  enum i915_map_type {

I915_MAP_WB = 0,
@@ -3462,8 +3478,10 @@ i915_vma_unpin_fence(struct i915_vma *vma)
  void i915_gem_restore_fences(struct drm_device *dev);
  
  void i915_gem_detect_bit_6_swizzle(struct drm_device *dev);

-void i915_gem_object_do_bit_17_swizzle(struct drm_i915_gem_object *obj);
-void i915_gem_object_save_bit_17_swizzle(struct drm_i915_gem_object *obj);
+void i915_gem_object_do_bit_17_swizzle(struct drm_i915_gem_object *obj,
+  struct sg_table *pages);
+void i915_gem_object_save_bit_17_swizzle(struct drm_i915_gem_object *obj,
+ 

Re: [Intel-gfx] [PATCH v3 0/4] Picture aspect ratio support in DRM layer

[Sharma, Shashank]

Please ignore this series, I mixed up one patch from LSPCON in here. 
Will send the right series in few minutes. 

Regards
Shashank
-Original Message-
From: Sharma, Shashank 
Sent: Monday, October 17, 2016 4:52 PM
To: dri-de...@lists.freedesktop.org; jim.br...@linux.intel.com
Cc: intel-gfx@lists.freedesktop.org; Vetter, Daniel ; 
Sharma, Shashank 
Subject: [PATCH v3 0/4] Picture aspect ratio support in DRM layer

This patch series adds 4 patches.
- The first two patches add aspect ratio support in DRM layes
- Next two patches add new aspect ratios defined in CEA-861-F
  supported for HDMI 2.0 4k modes.

Adding aspect ratio support in DRM layer:
- The CEA videmodes contain aspect ratio information, which we
  parse when we read the modes from EDID. But while transforming
  user_mode to kernel_mode or viceversa, DRM layer lose this
  information.
- HDMI compliance testing for CEA modes, expects the AVI info frames
  to contain exact VIC no for the 'video mode under test'. Now CEA
  modes have different VIC for same modes but different aspect ratio
  for example:
VIC 2 = 720x480@60 4:3
VIC 3 = 720x480@60 16:9
  In this way, lack of aspect ratio information, can cause wrong VIC
  no in AVI IF, causing HDMI complaince test to fail.
- This patch set adds code, which embeds the aspect ratio information
  also in DRM video mode flags, and uses it while comparing two modes.

Adding new aspect ratios for HDMI 2.0
- CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
  modes.
- 64:27
- 256:135
Last two patches in the series, adds code to handle these new aspect ratios.

V2: Fixed review comments from Sean, Emil, Daniel

V3: Fixed review comment from Jim Bride, got r-b for all patches

Shashank Sharma (4):
  drm/i915: Add lspcon resume function
  drm: Add aspect ratio parsing in DRM layer
  video: Add new aspect ratios for HDMI 2.0
  drm: Add and handle new aspect ratios in DRM layer

 drivers/gpu/drm/drm_modes.c | 43 +
 drivers/gpu/drm/i915/intel_dp.c |  7 +-
 drivers/gpu/drm/i915/intel_drv.h|  1 +
 drivers/gpu/drm/i915/intel_lspcon.c |  8 +++
 drivers/video/hdmi.c|  4 
 include/linux/hdmi.h|  2 ++
 include/uapi/drm/drm_mode.h |  6 ++
 7 files changed, 70 insertions(+), 1 deletion(-)

--
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_plane_multiple: CRC based atomic correctness test

[Mika Kahola]

On Wed, 2016-10-12 at 14:54 +0200, Maarten Lankhorst wrote:
> Op 07-10-16 om 13:45 schreef Mika Kahola:
> > 
> > This is a testcase with multiple planes. The idea here is the
> > following
> > 
> >  - draw a uniform frame with blue color
> >  - grab crc for reference
> >  - put planes randomly on top with the same blue color
> >  - punch holes with black color into the primary framebuffer
> >  - ideally the planes should cover these holes so that the output
> > is the
> >    identical to reference crc
> >  - composite all with one ioctl call
> >  - grab crc and verify that the reference crc is equal
> >  - repeat this for dozen iterations to maximize coverage
> > 
> > Signed-off-by: Mika Kahola 
> > ---
> >  tests/Makefile.sources |   1 +
> >  tests/kms_plane_multiple.c | 332
> > +
> >  2 files changed, 333 insertions(+)
> >  create mode 100644 tests/kms_plane_multiple.c
> > 
> > diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> > index 598ec6f..aed0f3a 100644
> > --- a/tests/Makefile.sources
> > +++ b/tests/Makefile.sources
> > @@ -105,6 +105,7 @@ TESTS_progs_M = \
> >     kms_pipe_color \
> >     kms_pipe_crc_basic \
> >     kms_plane \
> > +   kms_plane_multiple \
> >     kms_properties \
> >     kms_psr_sink_crc \
> >     kms_render \
> > diff --git a/tests/kms_plane_multiple.c
> > b/tests/kms_plane_multiple.c
> > new file mode 100644
> > index 000..153d6d1
> > --- /dev/null
> > +++ b/tests/kms_plane_multiple.c
> > @@ -0,0 +1,332 @@
> > +/*
> > + * Copyright © 2016 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 "drmtest.h"
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define SIZE 128
> > +
> > +typedef struct {
> > +   float red;
> > +   float green;
> > +   float blue;
> > +} color_t;
> > +
> > +typedef struct {
> > +   int drm_fd;
> > +   igt_display_t display;
> > +   igt_pipe_crc_t *pipe_crc;
> > +   igt_plane_t *primary;
> > +   igt_plane_t *sprite[IGT_MAX_PLANES-1];
> > +   struct igt_fb primary_fb;
> > +   struct igt_fb sprite_fb[IGT_MAX_PLANES-1];
> Single array, instead of primary/sprite separate? See also below for
> index change..
Indeed, it does look cleaner that way.
> > 
> > +} data_t;
> > +
> > +typedef struct {
> > +   data_t *data;
> > +   igt_crc_t reference_crc;
> > +} test_position_t;
> > +
> > +/*
> > + * Common code across all tests, acting on data_t
> > + */
> > +static void test_init(data_t *data, enum pipe pipe)
> > +{
> > +   data->pipe_crc = igt_pipe_crc_new(pipe,
> > INTEL_PIPE_CRC_SOURCE_AUTO);
> > +}
> > +
> > +static void test_fini(data_t *data, igt_output_t *output, int
> > nplanes)
> > +{
> > +   igt_plane_set_fb(data->primary, NULL);
> > +
> > +   for (int i = 0; i < nplanes; i++)
> > +   igt_plane_set_fb(data->sprite[i], NULL);
> > +
> > +   /* reset the constraint on the pipe */
> > +   igt_output_set_pipe(output, PIPE_ANY);
> > +
> > +   igt_pipe_crc_free(data->pipe_crc);
> > +}
> > +
> > +static void
> > +test_grab_crc(data_t *data, igt_output_t *output, enum pipe pipe,
> > +     color_t *color, uint64_t tiling, int commit,
> > +     igt_crc_t *crc /* out */)
> > +{
> > +   struct igt_fb fb;
> > +   drmModeModeInfo *mode;
> > +   igt_plane_t *primary;
> > +
> > +   igt_output_set_pipe(output, pipe);
> > +
> > +   primary = igt_output_get_plane(output, IGT_PLANE_PRIMARY);
> > +
> > +   mode = igt_output_get_mode(output);
> > +
> > +   igt_create_color_fb(data->drm_fd, mode->hdisplay, mode-
> > >vdisplay,
> > +   DRM_FORMAT_XRGB,
> > +   LOCAL_DRM_FORMAT_MOD_NONE,
> > +   color->red, 

[Intel-gfx] [PATCH i-g-t] tests/kms_plane_multiple: CRC based atomic correctness test

[Mika Kahola]

This is a testcase with multiple planes. The idea here is the following

 - draw a uniform frame with blue color
 - grab crc for reference
 - put planes randomly on top with the same blue color
 - punch holes with black color into the primary framebuffer
 - ideally the planes should cover these holes so that the output is the
   identical to reference crc
 - composite all with one ioctl call
 - grab crc and verify that the reference crc is equal
 - repeat this for dozen iterations to maximize coverage

v3: Cleanup by removing separate plane array
For atomic, pass DRM_MODE_PAGE_FLIP_EVENT
Grab crc by using igt_pipe_crc_get_crc instead of igt_pipe_crc_collect_crc
Rename nplanes variable to max_planes
To optimize test execution, run iterations after the modeset

v2: Keep a logfile on random number seeds per subtest that are not skipped
due to unmet test requirements

Signed-off-by: Mika Kahola 
---
 tests/Makefile.sources |   1 +
 tests/kms_plane_multiple.c | 423 +
 2 files changed, 424 insertions(+)
 create mode 100644 tests/kms_plane_multiple.c

diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 6d081c3..ffd59c1 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -105,6 +105,7 @@ TESTS_progs_M = \
kms_pipe_color \
kms_pipe_crc_basic \
kms_plane \
+   kms_plane_multiple \
kms_properties \
kms_psr_sink_crc \
kms_render \
diff --git a/tests/kms_plane_multiple.c b/tests/kms_plane_multiple.c
new file mode 100644
index 000..0cb7552
--- /dev/null
+++ b/tests/kms_plane_multiple.c
@@ -0,0 +1,423 @@
+/*
+ * Copyright © 2016 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 "drmtest.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+IGT_TEST_DESCRIPTION("Test atomic mode setting with multiple planes ");
+
+#define SIZE 128
+
+typedef struct {
+   float red;
+   float green;
+   float blue;
+} color_t;
+
+typedef struct {
+   int drm_fd;
+   igt_display_t display;
+   igt_pipe_crc_t *pipe_crc;
+   igt_plane_t *plane[IGT_MAX_PLANES];
+   struct igt_fb fb[IGT_MAX_PLANES];
+} data_t;
+
+typedef struct {
+   data_t *data;
+   igt_crc_t reference_crc;
+} test_position_t;
+
+/* Command line parameters. */
+struct {
+   bool user_seed;
+   int seed;
+   bool user_logfile;
+   char logfile[SIZE];
+} opt = {
+   .user_seed = false,
+   .seed = 1,
+   .user_logfile = false,
+   .logfile = "kms_plane_multiple.log",
+};
+
+
+static int logwrite(const char *testname)
+{
+   time_t curr_time;
+   FILE *fid;
+   char *time_str;
+
+   fid = fopen(opt.logfile, "a");
+
+   if (fid == NULL) {
+   igt_debug("Could not open file %s\n", opt.logfile);
+   return -1;
+   }
+
+   curr_time = time(NULL);
+
+   time_str = ctime(_time);
+   time_str[strlen(time_str)-1] = '\0';
+
+   fprintf(fid, "%s: kms_plane_multiple --run-subtest %s --seed %d\n",
+   time_str, testname, opt.seed);
+
+   fclose(fid);
+
+   return 0;
+}
+
+/*
+ * Common code across all tests, acting on data_t
+ */
+static void test_init(data_t *data, enum pipe pipe)
+{
+   data->pipe_crc = igt_pipe_crc_new(pipe, INTEL_PIPE_CRC_SOURCE_AUTO);
+}
+
+static void test_fini(data_t *data, igt_output_t *output, int max_planes)
+{
+   igt_plane_set_fb(data->plane[IGT_PLANE_PRIMARY], NULL);
+
+   for (int i = IGT_PLANE_2; i <= max_planes; i++)
+   igt_plane_set_fb(data->plane[i], NULL);
+
+   /* reset the constraint on the pipe */
+   igt_output_set_pipe(output, PIPE_ANY);
+
+   igt_pipe_crc_free(data->pipe_crc);
+}
+
+static bool test_is_atomic(const char *testname)
+{
+   if (strncmp(testname, 

Re: [Intel-gfx] [PATCH 17/41] drm/i915: Pass around sg_table to get_pages/put_pages backend

[Chris Wilson]

On Mon, Oct 17, 2016 at 11:55:54AM +0100, Tvrtko Ursulin wrote:
> On 14/10/2016 13:18, Chris Wilson wrote:
> >  static void
> >-i915_gem_object_put_pages_gtt(struct drm_i915_gem_object *obj)
> >+i915_gem_object_put_pages_gtt(struct drm_i915_gem_object *obj,
> >+  struct sg_table *pages)
> >  {
> > struct sgt_iter sgt_iter;
> > struct page *page;
> >-int ret;
> >-GEM_BUG_ON(obj->mm.madv == __I915_MADV_PURGED);
> >-
> >-ret = i915_gem_object_set_to_cpu_domain(obj, true);
> >-if (WARN_ON(ret)) {
> >-/* In the event of a disaster, abandon all caches and
> >- * hope for the best.
> >- */
> >-i915_gem_clflush_object(obj, true);
> >-obj->base.read_domains = obj->base.write_domain = 
> >I915_GEM_DOMAIN_CPU;
> >-}
> >+__i915_gem_object_release_shmem(obj);
> 
> Waiting for the object to become inactive is now gone. It did not
> spot that that changed with this patch. Did it?

There's no wait here. We have BUG_ONs today (that remain in place)
to catch trying to free pages that are in use by the GPU. This is just a
change of domains (and I wanted to keep the set-to-cpu-domain asserts,
and avoid the other side effects).
 
> >  int __i915_gem_object_get_pages(struct drm_i915_gem_object *obj)
> >  {
> >-struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> >-const struct drm_i915_gem_object_ops *ops = obj->ops;
> >-int ret;
> >+int err;
> > lockdep_assert_held(>base.dev->struct_mutex);
> > if (obj->mm.pages)
> > return 0;
> >-if (obj->mm.madv != I915_MADV_WILLNEED) {
> >-DRM_DEBUG("Attempting to obtain a purgeable object\n");
> >-__i915_gem_object_unpin_pages(obj);
> >-return -EFAULT;
> >-}
> >-
> >-ret = ops->get_pages(obj);
> >-if (ret) {
> >+err = i915_gem_object_get_pages(obj);
> >+if (err)
> > __i915_gem_object_unpin_pages(obj);
> >-return ret;
> >-}
> >-list_add_tail(>global_list, _priv->mm.unbound_list);
> 
> Objects will no longer appear on the unbound list when they have
> backing store?

They still do. We don't hold the struct_mutex here, so we defer the
global list tracking to the domain management which is slightly later. 

However, there is still a window of opportunity where we have pages
pinned for our use but not yet visible to the shrinker. A bit of
rejigging should be mean we only need to move the unbound upon
pages_pin_count==0 and it will require a spinlock, but that make
actually work out to be less code. But it won't yet reduce the
struct_mutex hold time in the shrinker, so I'm not seeing the upside
yet.

> >+static bool unsafe_drop_pages(struct drm_i915_gem_object *obj)
> >+{
> >+if (i915_gem_object_unbind(obj) == 0)
> >+__i915_gem_object_put_pages(obj);
> >+return !obj->mm.pages;
> >+}
> 
> Can we have some comments with this function?

It may or may not result in the pages being freed, and it may or may
result in the object being unreferenced. There used to be a function
called drop_pages (which the same caveats) that got misused so I removed
it and wanted to be sure that they didn't repeat their mistakes.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v3 0/4]: Picture aspect ratio support in DRM layer

[Jose Abreu]

Hi Shashank,


On 17-10-2016 12:32, Shashank Sharma wrote:
> This patch series adds 4 patches.
> - The first two patches add aspect ratio support in DRM layes
> - Next two patches add new aspect ratios defined in CEA-861-F
>   supported for HDMI 2.0 4k modes.
>
> Adding aspect ratio support in DRM layer:
> - The CEA videmodes contain aspect ratio information, which we
>   parse when we read the modes from EDID. But while transforming
>   user_mode to kernel_mode or viceversa, DRM layer lose this
>   information.
> - HDMI compliance testing for CEA modes, expects the AVI info frames
>   to contain exact VIC no for the 'video mode under test'. Now CEA
>   modes have different VIC for same modes but different aspect ratio
>   for example:
> VIC 2 = 720x480@60 4:3
> VIC 3 = 720x480@60 16:9
>   In this way, lack of aspect ratio information, can cause wrong VIC
>   no in AVI IF, causing HDMI complaince test to fail.
> - This patch set adds code, which embeds the aspect ratio information
>   also in DRM video mode flags, and uses it while comparing two modes.
>
> Adding new aspect ratios for HDMI 2.0
> - CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
>   modes.
> - 64:27
> - 256:135
> Last two patches in the series, adds code to handle these new
> aspect ratios.
>
> V2: Fixed review comments from Sean, Emil, Daniel
> V3: Fixed review comments from Jim Bride, got r-b for all patches
>
> Shashank Sharma (4):
>   drm: add picture aspect ratio flags
>   drm: Add aspect ratio parsing in DRM layer
>   video: Add new aspect ratios for HDMI 2.0
>   drm: Add and handle new aspect ratios in DRM layer

I am using the previous version of these patches, the
functionality remains the same so you can add my reviewed-by for
the whole series if you want. Are you still planning in sending
the patches for the new VIC's introduced in CEA-861-F?

>
>  drivers/gpu/drm/drm_modes.c | 43 +++
>  drivers/video/hdmi.c|  4 
>  include/linux/hdmi.h|  2 ++
>  include/uapi/drm/drm_mode.h | 24 +++-
>  4 files changed, 68 insertions(+), 5 deletions(-)
>

Best regards,
Jose Miguel Abreu
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 08/41] drm/i915: Rearrange i915_wait_request() accounting with callers

[Joonas Lahtinen]

On pe, 2016-10-14 at 13:18 +0100, Chris Wilson wrote:
> Our low-level wait routine has evolved from our generic wait interface
> that handled unlocked, RPS boosting, waits with time tracking. If we
> push our GEM fence tracking to use reservation_objects (required for
> handling multiple timelines), we lose the ability to pass the required
> information down to i915_wait_request(). However, if we push the extra
> functionality from i915_wait_request() to the individual callsites
> (i915_gem_object_wait_rendering and i915_gem_wait_ioctl) that make use
> of those extras, we can both simplify our low level wait and prepare for
> extending the GEM interface for use of reservation_objects.
> 
> Signed-off-by: Chris Wilson 

No changelog so I assume only whitespace fixes were made, and hopefully
not to the worse.

So;

Reviewed-by: Joonas Lahtinen 

If you split the i915_gem_wait_for_error removal to own patch with
"Fixes:" you can add my R-b there too.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 0/4] Picture aspect ratio support in DRM layer

[Daniel Vetter]

On Mon, Oct 17, 2016 at 05:34:36PM +0530, Shashank Sharma wrote:
> This patch series adds 4 patches.
> - The first two patches add aspect ratio support in DRM layes
> - Next two patches add new aspect ratios defined in CEA-861-F
>   supported for HDMI 2.0 4k modes.
> 
> Adding aspect ratio support in DRM layer:
> - The CEA videmodes contain aspect ratio information, which we
>   parse when we read the modes from EDID. But while transforming
>   user_mode to kernel_mode or viceversa, DRM layer lose this
>   information.
> - HDMI compliance testing for CEA modes, expects the AVI info frames
>   to contain exact VIC no for the 'video mode under test'. Now CEA
>   modes have different VIC for same modes but different aspect ratio
>   for example:
> VIC 2 = 720x480@60 4:3
> VIC 3 = 720x480@60 16:9
>   In this way, lack of aspect ratio information, can cause wrong VIC
>   no in AVI IF, causing HDMI complaince test to fail.
> - This patch set adds code, which embeds the aspect ratio information
>   also in DRM video mode flags, and uses it while comparing two modes.
> 
> Adding new aspect ratios for HDMI 2.0
> - CEA-861-F defines two new aspect ratios, to be used for 4k HDMI 2.0
>   modes.
> - 64:27
> - 256:135
> Last two patches in the series, adds code to handle these new
> aspect ratios.
> 
> V2: Fixed review comments from Sean, Emil, Daniel
> V3: Fixed review comments from Jim Bride, got r-b for all patches
> V4: Added r-b from Jose for the series, and ack-by from Tomi on patch 3
> 
> Shashank Sharma (4):
>   drm: add picture aspect ratio flags
>   drm: Add aspect ratio parsing in DRM layer
>   video: Add new aspect ratios for HDMI 2.0
>   drm: Add and handle new aspect ratios in DRM layer

Applied to drm-misc, thanks. I guess you'll follow up with i915 patches to
remove the picture aspect ratio for overrides eventually?

Thanks, Daniel

> 
>  drivers/gpu/drm/drm_modes.c | 43 +++
>  drivers/video/hdmi.c|  4 
>  include/linux/hdmi.h|  2 ++
>  include/uapi/drm/drm_mode.h | 24 +++-
>  4 files changed, 68 insertions(+), 5 deletions(-)
> 
> -- 
> 1.9.1
> 
> ___
> 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 v6 3/5] drm/i915: Parse VBT data for lspcon

[Jani Nikula]

On Fri, 14 Oct 2016, "Sharma, Shashank"  wrote:
> Regards
>
> Shashank
>
>
> On 10/14/2016 8:02 PM, Jani Nikula wrote:
>> On Fri, 14 Oct 2016, Shashank Sharma  wrote:
>>> Many GEN9 boards come with on-board lspcon cards.
>>> Fot these boards, VBT configuration should properly point out
>>> if a particular port contains lspcon device, so that driver can
>>> initialize it properly.
>>>
>>> This patch adds a utility function, which checks the VBT flag
>>> for lspcon bit, and tells us if a port is configured to have a
>>> lspcon device or not.
>>>
>>> V2: Fixed review comments from Ville
>>> - Do not forget PORT_D while checking lspcon for GEN9
>>>
>>> V3: Addressed review comments from Rodrigo
>>> - Create a HAS_LSPCON() macro for better use case handling.
>>> - Do not dump warnings for non-gen-9 platforms, it will be noise.
>>>
>>> V4: Rebase
>>> V5: Rebase
>>> V6: Pass dev_priv to HAS_LSPCON() macro
>>>
>>> Signed-off-by: Shashank Sharma 
>>> Reviewed-by: Rodrigo Vivi 
>> I was hoping you'd use the version I rebased and sent, put it first in
>> the series, and rebase the rest on that. The point is, this series has
>> taken so long that lspcon devices have proliferated all over the place,
>> and we'll be getting more and more bugs about them. If this patch was
>> first, with the debug logging, we could at least get that to 4.9, maybe
>> stable kernels, and we'd immediately know the reason. I think it'll be a
>> hard sell to get the whole series to 4.9 kernel.
>>
>> BR,
>> Jani.
> Jani,
> The patch got its first r-b since a long time.
> After that, it was waiting to be merged, for long time.
>
> Recently, when Imre was asked to test the patches, and he found one 
> issue specific to APL.
> We were trying to fix a suspend-resume issue, which was fixed with the 
> last patch.
> Now this patch is ready to be merged, just waiting for Imre's r-b.
>
> Third patch just gives information about if LSPCON is available or not, 
> which is not a big help for anything as such.
> So instead of changing the sequence, and confusing the reviewers, I 
> thought it would be better to send the whole series and
> get this merged as-it-is.

Fine, let's merge this as-is... after patch 1/5 has been posted to
dri-devel and/or has received an ack from Dave Airlie that it's fine to
merge through our tree.

In the bigger scheme of things, if this patch 3/5 had been first in the
series all along, we could have merged this *months* ago. This is how
series should be organized. Simple things first.

Having the debug information *is* valuable. You'd see that if you had to
go through our incoming bugs. We've had plenty of LSPCON bugs since the
day Skylake was launched. Yes, quite a long time now. If 3/5 was first
in the series, we could backport that to v4.9 and older and reduce our
debugging time.

BR,
Jani.






>
> Regards
> Shashank
>>
>>> ---
>>>   drivers/gpu/drm/i915/i915_drv.h   |  5 
>>>   drivers/gpu/drm/i915/intel_bios.c | 49 
>>> +++
>>>   2 files changed, 54 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>>> b/drivers/gpu/drm/i915/i915_drv.h
>>> index fe875b2..7bab2f1 100644
>>> --- a/drivers/gpu/drm/i915/i915_drv.h
>>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>>> @@ -2864,6 +2864,8 @@ struct drm_i915_cmd_table {
>>>   
>>>   #define HAS_GMCH_DISPLAY(dev_priv) ((dev_priv)->info.has_gmch_display)
>>>   
>>> +#define HAS_LSPCON(dev_priv) (IS_GEN9(dev_priv))
>>> +
>>>   /* DPF == dynamic parity feature */
>>>   #define HAS_L3_DPF(dev_priv) ((dev_priv)->info.has_l3_dpf)
>>>   #define NUM_L3_SLICES(dev_priv) (IS_HSW_GT3(dev_priv) ? \
>>> @@ -3631,6 +3633,9 @@ bool intel_bios_is_port_dp_dual_mode(struct 
>>> drm_i915_private *dev_priv, enum por
>>>   bool intel_bios_is_dsi_present(struct drm_i915_private *dev_priv, enum 
>>> port *port);
>>>   bool intel_bios_is_port_hpd_inverted(struct drm_i915_private *dev_priv,
>>>  enum port port);
>>> +bool intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
>>> +   enum port port);
>>> +
>>>   
>>>   /* intel_opregion.c */
>>>   #ifdef CONFIG_ACPI
>>> diff --git a/drivers/gpu/drm/i915/intel_bios.c 
>>> b/drivers/gpu/drm/i915/intel_bios.c
>>> index 83667e8..32e1def 100644
>>> --- a/drivers/gpu/drm/i915/intel_bios.c
>>> +++ b/drivers/gpu/drm/i915/intel_bios.c
>>> @@ -1763,3 +1763,52 @@ intel_bios_is_port_hpd_inverted(struct 
>>> drm_i915_private *dev_priv,
>>>   
>>> return false;
>>>   }
>>> +
>>> +/**
>>> + * intel_bios_is_lspcon_present - if LSPCON is attached on %port
>>> + * @dev_priv:  i915 device instance
>>> + * @port:  port to check
>>> + *
>>> + * Return true if LSPCON is present on this port
>>> + */
>>> +bool
>>> +intel_bios_is_lspcon_present(struct drm_i915_private *dev_priv,
>>> +   enum port port)
>>> +{
>>> +   int i;
>>> 

[Intel-gfx] [PATCH v3 3/4] video: Add new aspect ratios for HDMI 2.0

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: rebase
V3: rebase
---
 drivers/video/hdmi.c | 4 
 include/linux/hdmi.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index 1626892..1cf907e 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -533,6 +533,10 @@ hdmi_picture_aspect_get_name(enum hdmi_picture_aspect 
picture_aspect)
return "4:3";
case HDMI_PICTURE_ASPECT_16_9:
return "16:9";
+   case HDMI_PICTURE_ASPECT_64_27:
+   return "64:27";
+   case HDMI_PICTURE_ASPECT_256_135:
+   return "256:135";
case HDMI_PICTURE_ASPECT_RESERVED:
return "Reserved";
}
diff --git a/include/linux/hdmi.h b/include/linux/hdmi.h
index e974420..edbb4fc 100644
--- a/include/linux/hdmi.h
+++ b/include/linux/hdmi.h
@@ -78,6 +78,8 @@ enum hdmi_picture_aspect {
HDMI_PICTURE_ASPECT_NONE,
HDMI_PICTURE_ASPECT_4_3,
HDMI_PICTURE_ASPECT_16_9,
+   HDMI_PICTURE_ASPECT_64_27,
+   HDMI_PICTURE_ASPECT_256_135,
HDMI_PICTURE_ASPECT_RESERVED,
 };
 
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 1/4] drm: add picture aspect ratio flags

[Shashank Sharma]

This patch adds drm flag bits for aspect ratio information

Currently drm flag bits don't have field for mode's picture
aspect ratio. This field will help the driver to pick mode with
right aspect ratio, and help in setting right VIC field in avi
infoframes.

Signed-off-by: Shashank Sharma 
Reviewed-by: Jim Bride 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Addressed review comments from Sean
- Changed PAR-> PIC_AR
V3: Rebase
---
 include/uapi/drm/drm_mode.h | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index df0e350..5c142b1 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -77,6 +77,19 @@ extern "C" {
 #define  DRM_MODE_FLAG_3D_TOP_AND_BOTTOM   (7<<14)
 #define  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF(8<<14)
 
+/* Picture aspect ratio options */
+#define DRM_MODE_PICTURE_ASPECT_NONE   0
+#define DRM_MODE_PICTURE_ASPECT_4_31
+#define DRM_MODE_PICTURE_ASPECT_16_9   2
+
+/* Aspect ratio flag bitmask (4 bits 22:19) */
+#define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
+#define  DRM_MODE_FLAG_PIC_AR_NONE \
+   (DRM_MODE_PICTURE_ASPECT_NONE<<19)
+#define  DRM_MODE_FLAG_PIC_AR_4_3 \
+   (DRM_MODE_PICTURE_ASPECT_4_3<<19)
+#define  DRM_MODE_FLAG_PIC_AR_16_9 \
+   (DRM_MODE_PICTURE_ASPECT_16_9<<19)
 
 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
@@ -92,11 +105,6 @@ extern "C" {
 #define DRM_MODE_SCALE_CENTER  2 /* Centered, no scaling */
 #define DRM_MODE_SCALE_ASPECT  3 /* Full screen, preserve aspect */
 
-/* Picture aspect ratio options */
-#define DRM_MODE_PICTURE_ASPECT_NONE   0
-#define DRM_MODE_PICTURE_ASPECT_4_31
-#define DRM_MODE_PICTURE_ASPECT_16_9   2
-
 /* Dithering mode options */
 #define DRM_MODE_DITHERING_OFF 0
 #define DRM_MODE_DITHERING_ON  1
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v3 4/4] drm: Add and handle new aspect ratios in DRM layer

[Shashank Sharma]

HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135

This patch:
-  Adds new DRM flags for to represent these new aspect ratios.
-  Adds new cases to handle these aspect ratios while converting
from user->kernel mode or vise versa.

Signed-off-by: Shashank Sharma 
Reviewed-by: Sean Paul 
Cc: Daniel Vetter 
Cc: Emil Velikov 

V2: Rebase
V3: Align macro for DRM_MODE_PICTURE_ASPECT_256_135 (Jim Bride)
---
 drivers/gpu/drm/drm_modes.c | 12 
 include/uapi/drm/drm_mode.h |  6 ++
 2 files changed, 18 insertions(+)

diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index fde927a..173b7d3 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1509,6 +1509,12 @@ void drm_mode_convert_to_umode(struct drm_mode_modeinfo 
*out,
case HDMI_PICTURE_ASPECT_16_9:
out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
break;
+   case HDMI_PICTURE_ASPECT_64_27:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_64_27;
+   break;
+   case DRM_MODE_PICTURE_ASPECT_256_135:
+   out->flags |= DRM_MODE_FLAG_PIC_AR_256_135;
+   break;
case HDMI_PICTURE_ASPECT_RESERVED:
default:
out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
@@ -1570,6 +1576,12 @@ int drm_mode_convert_umode(struct drm_display_mode *out,
case DRM_MODE_FLAG_PIC_AR_16_9:
out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
break;
+   case DRM_MODE_FLAG_PIC_AR_64_27:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_64_27;
+   break;
+   case DRM_MODE_FLAG_PIC_AR_256_135:
+   out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_256_135;
+   break;
default:
out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
break;
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 5c142b1..084b50a 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -81,6 +81,8 @@ extern "C" {
 #define DRM_MODE_PICTURE_ASPECT_NONE   0
 #define DRM_MODE_PICTURE_ASPECT_4_31
 #define DRM_MODE_PICTURE_ASPECT_16_9   2
+#define DRM_MODE_PICTURE_ASPECT_64_27  3
+#define DRM_MODE_PICTURE_ASPECT_256_1354
 
 /* Aspect ratio flag bitmask (4 bits 22:19) */
 #define DRM_MODE_FLAG_PIC_AR_MASK  (0x0F<<19)
@@ -90,6 +92,10 @@ extern "C" {
(DRM_MODE_PICTURE_ASPECT_4_3<<19)
 #define  DRM_MODE_FLAG_PIC_AR_16_9 \
(DRM_MODE_PICTURE_ASPECT_16_9<<19)
+#define  DRM_MODE_FLAG_PIC_AR_64_27 \
+   (DRM_MODE_PICTURE_ASPECT_64_27<<19)
+#define  DRM_MODE_FLAG_PIC_AR_256_135 \
+   (DRM_MODE_PICTURE_ASPECT_256_135<<19)
 
 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
-- 
1.9.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Suppress underrun reporting around DP link retraining

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 02:38:01PM +0300, Tomi Sarvela wrote:
> On Monday, 17 October 2016 14:33:28 EEST Ville Syrjälä wrote:
> > On Fri, Oct 14, 2016 at 06:51:37PM -, Patchwork wrote:
> > > == Series Details ==
> > > 
> > > Series: drm/i915: Suppress underrun reporting around DP link retraining
> > > URL   : https://patchwork.freedesktop.org/series/13805/
> > > State : warning
> > 
> > OK, but...
> > 
> > > == Summary ==
> > > 
> > > Series 13805v1 drm/i915: Suppress underrun reporting around DP link
> > > retraining
> > > https://patchwork.freedesktop.org/api/1.0/series/13805/revisions/1/mbox/> 
> > > 
> > > Test vgem_basic:
> > > Subgroup unload:
> > > pass   -> SKIP   (fi-hsw-4770)
> > 
> > ... where is the warn here?
> 
> This was added to comparison code because I was asked to:
> 
> # pass -> SKIP
> if testresult < 1 and (lastres == 'pass' and res == 
> 'skip'):
> testresult = 1
> 
> Unintuitive, but there you go.

OK. Well, this test seems to skip<->pass quite a lot, so I'll put it
down as already busted somehow.

-- 
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] ✗ Fi.CI.BAT: warning for : Picture aspect ratio support in DRM layer (rev2)

[Saarinen, Jani]

> == Series Details ==
> 
> Series: : Picture aspect ratio support in DRM layer (rev2)
> URL   : https://patchwork.freedesktop.org/series/10587/
> State : warning
> 
> == Summary ==
> 
> Series 10587v2 : Picture aspect ratio support in DRM layer
> https://patchwork.freedesktop.org/api/1.0/series/10587/revisions/2/mbox/
> 
> Test kms_pipe_crc_basic:
> Subgroup bad-source:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup read-crc-pipe-a-frame-sequence:
> pass   -> DMESG-WARN (fi-ilk-650)
> Subgroup read-crc-pipe-b-frame-sequence:
> pass   -> DMESG-WARN (fi-ilk-650)
Same old https://bugs.freedesktop.org/show_bug.cgi?id=98251 to all

 [drm:intel_pch_fifo_underrun_irq_handler [i915]] *ERROR* PCH transcoder B FIFO 
underrun
 [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe B FIFO 
underrun

> Test vgem_basic:
> Subgroup unload:
> pass   -> SKIP   (fi-skl-6260u)
> skip   -> PASS   (fi-skl-6770hq)
> pass   -> SKIP   (fi-hsw-4770)
> 
> fi-bdw-5557u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15
> fi-bsw-n3050 total:246  pass:204  dwarn:0   dfail:0   fail:0   skip:42
> fi-bxt-t5700 total:246  pass:216  dwarn:0   dfail:0   fail:0   skip:30
> fi-byt-j1900 total:246  pass:212  dwarn:2   dfail:0   fail:1   skip:31
> fi-byt-n2820 total:246  pass:210  dwarn:0   dfail:0   fail:1   skip:35
> fi-hsw-4770  total:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-hsw-4770r total:246  pass:224  dwarn:0   dfail:0   fail:0   skip:22
> fi-ilk-650   total:246  pass:181  dwarn:3   dfail:0   fail:2   skip:60
> fi-ivb-3520m total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-ivb-3770  total:246  pass:221  dwarn:0   dfail:0   fail:0   skip:25
> fi-kbl-7200u total:246  pass:222  dwarn:0   dfail:0   fail:0   skip:24
> fi-skl-6260u total:246  pass:231  dwarn:0   dfail:0   fail:0   skip:15
> fi-skl-6700hqtotal:246  pass:223  dwarn:0   dfail:0   fail:0   skip:23
> fi-skl-6700k total:246  pass:221  dwarn:1   dfail:0   fail:0   skip:24
> fi-skl-6770hqtotal:246  pass:230  dwarn:1   dfail:0   fail:1   skip:14
> fi-snb-2520m total:246  pass:210  dwarn:0   dfail:0   fail:0   skip:36
> fi-snb-2600  total:246  pass:209  dwarn:0   dfail:0   fail:0   skip:37
> 
> Results at /archive/results/CI_IGT_test/Patchwork_2734/
> 
> 15dfed2b90e84e7c277f81842fc3f19355293061 drm-intel-nightly: 2016y-10m-
> 16d-23h-15m-00s UTC integration manifest 5c0848b drm: Add and handle
> new aspect ratios in DRM layer
> dca13e5 video: Add new aspect ratios for HDMI 2.0
> 69f5805 drm: Add aspect ratio parsing in DRM layer b38c91c drm: add picture
> aspect ratio flags
> 

Jani Saarinen
Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo



___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 06/41] drm/i915: Support asynchronous waits on struct fence from i915_gem_request

[Joonas Lahtinen]

On pe, 2016-10-14 at 13:17 +0100, Chris Wilson wrote:
> We will need to wait on DMA completion (as signaled via struct fence)
> before executing our i915_gem_request. Therefore we want to expose a
> method for adding the await on the fence itself to the request.
> 
> v2: Add a comment detailing a failure to handle a signal-on-any
> fence-array.
> 
> Signed-off-by: Chris Wilson 

With the magic removed (10*HZ), this was already;

Reviewed-by: Joonas Lahtinen 

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v4 2/4] drm: Add aspect ratio parsing in DRM layer

[Ville Syrjälä]

On Mon, Oct 17, 2016 at 05:34:38PM +0530, Shashank Sharma wrote:
> Current DRM layer functions don't parse aspect ratio information
> while converting a user mode->kernel mode or vice versa. This
> causes modeset to pick mode with wrong aspect ratio, eventually
> causing failures in HDMI compliance test cases, due to wrong VIC.
> 
> This patch adds aspect ratio information in DRM's mode conversion
> and mode comparision functions, to make sure kernel picks mode
> with right aspect ratio (as per the VIC).
> 
> Signed-off-by: Shashank Sharma 
> Signed-off-by: Lin, Jia 
> Signed-off-by: Akashdeep Sharma 
> Reviewed-by: Jim Bride 
> Reviewed-by: Jose Abreu 
> Cc: Daniel Vetter 
> Cc: Emil Velikov 
> 
> V2: Addressed review comments from Sean:
> - Fix spellings/typo
> - No need to handle aspect ratio none
> - Add a break, for default case too
> V3: Rebase
> V4: Added r-b from Jose
> ---
>  drivers/gpu/drm/drm_modes.c | 31 +++
>  1 file changed, 31 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 53f07ac..fde927a 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -997,6 +997,7 @@ bool drm_mode_equal_no_clocks_no_stereo(const struct 
> drm_display_mode *mode1,
>   mode1->vsync_end == mode2->vsync_end &&
>   mode1->vtotal == mode2->vtotal &&
>   mode1->vscan == mode2->vscan &&
> + mode1->picture_aspect_ratio == mode2->picture_aspect_ratio &&
>   (mode1->flags & ~DRM_MODE_FLAG_3D_MASK) ==
>(mode2->flags & ~DRM_MODE_FLAG_3D_MASK))
>   return true;
> @@ -1499,6 +1500,21 @@ void drm_mode_convert_to_umode(struct 
> drm_mode_modeinfo *out,
>   out->vrefresh = in->vrefresh;
>   out->flags = in->flags;
>   out->type = in->type;
> + out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
> +
> + switch (in->picture_aspect_ratio) {
> + case HDMI_PICTURE_ASPECT_4_3:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_4_3;
> + break;
> + case HDMI_PICTURE_ASPECT_16_9:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_16_9;
> + break;
> + case HDMI_PICTURE_ASPECT_RESERVED:
> + default:
> + out->flags |= DRM_MODE_FLAG_PIC_AR_NONE;
> + break;
> + }
> +
>   strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>   out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
>  }
> @@ -1544,6 +1560,21 @@ int drm_mode_convert_umode(struct drm_display_mode 
> *out,
>   strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
>   out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
>  
> + /* Clearing picture aspect ratio bits from out flags */
> + out->flags &= ~DRM_MODE_FLAG_PIC_AR_MASK;
> +
> + switch (in->flags & DRM_MODE_FLAG_PIC_AR_MASK) {
> + case DRM_MODE_FLAG_PIC_AR_4_3:
> + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_4_3;
> + break;
> + case DRM_MODE_FLAG_PIC_AR_16_9:
> + out->picture_aspect_ratio |= HDMI_PICTURE_ASPECT_16_9;
> + break;
> + default:
> + out->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
> + break;
> + }

Hmm. So now we have the mode aspect ratio infromation duplicated
in two different places. Not sure that won't lead to some confusion.
Although we do want the user to be able to override via the property I
suppose, so we'd have to change that (+ the inforframe code) to
look at the mode flags instead if we would eliminate
'picture_aspect_ratio'.

And that brings me to the other point. At least i915 will simply
override the mode's aspect ration with the property. So this looks like
a big no-op for now on i915. It's looking like we might need a new
propetty value to differentiate between "auto" and "none" for real.

> +
>   out->status = drm_mode_validate_basic(out);
>   if (out->status != MODE_OK)
>   goto out;
> -- 
> 1.9.1
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 14/19] drm/mediatek: Use new atomic iterator macros

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index db61aa5f32ef..414e848d8cbf 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -50,8 +50,8 @@ static void mtk_atomic_wait_for_fences(struct 
drm_atomic_state *state)
struct drm_plane_state *plane_state;
int i;
 
-   for_each_plane_in_state(state, plane, plane_state, i)
-   mtk_fb_wait(plane->state->fb);
+   for_each_new_plane_in_state(state, plane, plane_state, i)
+   mtk_fb_wait(plane_state->fb);
 }
 
 static void mtk_atomic_complete(struct mtk_drm_private *private,
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 03/19] drm/exynos: Use new atomic iterator macros.

[Maarten Lankhorst]

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 4a21a745c373..fc54f3f0a42c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -243,7 +243,7 @@ int exynos_atomic_commit(struct drm_device *dev, struct 
drm_atomic_state *state,
/* Wait until all affected CRTCs have completed previous commits and
 * mark them as pending.
 */
-   for_each_crtc_in_state(state, crtc, crtc_state, i)
+   for_each_new_crtc_in_state(state, crtc, crtc_state, i)
commit->crtcs |= drm_crtc_mask(crtc);
 
wait_event(priv->wait, !commit_is_pending(priv, commit->crtcs));
-- 
2.7.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx