Re: [Intel-gfx] [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm

[Zhang, Xiong Y]

> + David and Jon
> 
> On ti, 2017-04-25 at 18:34 +0800, Xiong Zhang wrote:
> 
> The blocking issue I see is that bisecting is still not pointing at
> relevant commits. Both bisected commits from Bugzilla are not related
> to changes in stolen memory usage behavior. I'd assume a successful
> bisect to land at the patches where we start creating kernel internal
> objects from stolen memory. Otherwise we could be ignoring a bug
> elsewhere. If it consistently lands on those patches, then there might
> be something wrong with them, in addition to stolen memory problems.
[Zhang, Xiong Y] I only try kernel 4.8 and 4.9 above, as the bugzilla 
descripted,
guest 4.8 kernel doesn't see gpu hang in guest dmesg, 4.9 kernel has gpu hang
in guest dmesg. From this point, we could do git bisect.
But tons of IOMMU DMA R/W exception to stolen memory exist in host dmesg 
when guest kernel is 4.8 and 4.9. This means guest domain iommu table doesn't 
have mapping for stolen memory and IGD fail in accessing stolen memory 
from guest kernel 4.8 and 4.9. From this point, this issue isn't a regression 
and
shouldn't go git bisect. You could check this host error message from the 
bugzilla 
attachment. And this should be fixed first.
Anyway, I will try my best to get the ideal commit through git bisect, but I'm 
afraid
the result is the same as past because we don't have a stable good point to 
start git
bisect.

> Disabling power saving makes many bugs go away, but we still don't
> disable power saving as a resolution to such bugs, but instead root
> cause and fix the individual bugs.
[Zhang, Xiong Y] I add i915.enable_rc6=0, i915.enable_dc=0, i915.enable_fbc=0,
I915.enable_psr=0, i915.disable_power_well=0,i915.enable_ips=0 to grub.
But gpu hang exist in guest and DMA R/W error exist in host.
> 
> > Stolen memory isn't a standard pci resource and exists in RMRR which has
> > identity mapping in iommu table when host boot up, so IGD could access
> > stolen memory in host OS. While according to 'commit c875d2c1b808
> > ("iommu/vt-d: Exclude devices using RMRRs from IOMMU API
> domains")',RMRR
> > isn't supported by kvm, then both EPT and guest iommu domain table lack
> > of maaping for stolen memory in kvm IGD passthrough environment.
> 
> Commit message text still fails to address that an exclusion was added
> by commit:
> 
> commit 18436afdc11a00ac881990b454cfb2eae81d6003
> Author: David Woodhouse 
> Date:   Wed Mar 25 15:05:47 2015 +
> 
> iommu/vt-d: Allow RMRR on graphics devices too
> 
>     Commit c875d2c1 ("iommu/vt-d: Exclude devices using RMRRs from
> IOMMU API
> domains") prevents certain options for devices with RMRRs. This even
> prevents those devices from getting a 1:1 mapping with 'iommu=pt',
> because we don't have the code to handle *preserving* the RMRR
> regions
> when moving the device between domains.
> 
> 
> 
> The quoted part of David's commit message leads me to believe it's
> simply lack of some code in kernel for juggling the RMRRs when moving a
> device between domains that is missing. Why is not that considered
> instead? With that implemented, we would have more transparent pass-
> through, which should be good.
[Zhang, Xiong Y] c875d2c1 ("iommu/vt-d: Exclude devices using RMRRs from
IOMMU API domains). This patch prevent devices associated with RMRRs from
assigning to a guest, the one of reason is it knows RMRR isn't supported in 
guest 
domain IOMMU table, If these device's driver still access RMRR from guest, 
serious error will happen.
18436afdc ("iommu/vt-d: Allow RMRR on graphics devices too "), add an exception
to above commit. So IGD could be assigned to a guest. But this doesn't mean IGD
1:1 mapping for RMRR will be support in guest domain iommu table
'iommu=pt' is to set 1:1 mapping for all pci device in host domain iommu table.

When one device is assigned to a guest and this guest boot up, this guest domain
Iommu table will take place of host domain iommu table on hardware. Our issue
is guest domain iommu table doesn't have 1:1 mapping for RMRR.
In order to set up 1:1 mapping for RMRR in guest domain iommu table, we have
to modify kvm and qemu and kvm community have declined this.
> 
> Also, was fixing the IGD driver loading with zero stolen memory
> considered instead? All this information should exist in the commit
> message.
[Zhang, Xiong Y] IGD and i915 driver read pci config register 0x50 to get 
the size of stolen memory. When guest read this register, qemu could trap
it and return one value to guest.
So in order to  " fixing the IGD driver loading with zero stolen memory ",
We have to modify both Qemu and IGD driver:
1) QEMU: trap read from pci cfg 0x50 register, then return zero to guest
2) IGD driver: when IGD driver see zero size of stolen memory, don't exit 
loading
and continue.
This doesn't give any benefit to i915, i915 will still disable stolen memory as 
i915
see zero size stolen memory . So I prefer to disable stolen memory 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Pre-calculate engine context size

[Zhi Wang]

Hi Daniele:
Thanks for the reply! Joonas and I did some researches in irc after 
the email. We found B-spec did say the context image for render engine 
consist 20 pages in context layout section. It looks like a mistake in 
b-spec. Another interesting we found is the context image size for KBL 
halo is weird, not the same with other KBL SKUs.


Thanks,
Zhi.

于 04/27/17 00:20, Daniele Ceraolo Spurio 写道:



On 26/04/17 02:57, Zhi Wang wrote:

Uh...sorry for not mentioning that before:), and stolen memory is not my
business. :(

Actually we root-caused it.

This is how we found this case:

The story is W driver directly allocated the ring buffer after the
context image, and the context image size in W driver is 19 pages. GVT-g
will do shadow context during submission, we copy 20 pages from guest
context image, so you can see, an extra page is copied here as the
context image size is actual 19 pages. The extra page belows to ring
buffer. When guest updates that page with new commands during GVT-g
executing the workload, the extra page ( which is ring buffer page) will
be over-written with old content, since GVT-g will copy the shadow
context (20 pages) back to guest at this time.

That's the full story. I send another email to Harsh. He should know if
the context image size of CHV is also 19 pages.

Thanks,
Zhi.



I did a quick check and according to the specs both the BDW and the 
CHV lrcs are formed by 18096 dwords plus the per-context HWSP, which 
converts to 19 pages for both platforms.


Regards,
Daniele


于 04/26/17 17:52, Joonas Lahtinen 写道:

On ke, 2017-04-26 at 17:10 +0800, Zhi Wang wrote:

Hi Joonas:
  Can you change GEN8_LR_CONTEXT_RENDER_SIZE = (19 * PAGE_SIZE)?
Then we don't need the hack in GVT-g. :P Actually it's 19 pages not
20 pages on BDW.

The exception is only made for BDW, not Gen8 overall. Has the change
been verified for CHV too?

Why hasn't a patch to fix above been sent for i915 in the past? Just
like in the stolen memory disabling case, bugs should be root caused
and then fixed, not just worked around quickly.

Regards, Joonas



___
intel-gvt-dev mailing list
intel-gvt-...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev


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

[Intel-gfx] ✗ Fi.CI.BAT: warning for Adding driver-private objects to atomic state (rev2)

[Patchwork]

== Series Details ==

Series: Adding driver-private objects to atomic state (rev2)
URL   : https://patchwork.freedesktop.org/series/23308/
State : warning

== Summary ==

Series 23308v2 Adding driver-private objects to atomic state
https://patchwork.freedesktop.org/api/1.0/series/23308/revisions/2/mbox/

Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-c:
pass   -> DMESG-WARN (fi-bsw-n3050) fdo#100651
Test pm_rpm:
Subgroup basic-pci-d3-state:
pass   -> DMESG-WARN (fi-bsw-n3050)

fdo#100651 https://bugs.freedesktop.org/show_bug.cgi?id=100651

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:433s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:427s
fi-bsw-n3050 total:278  pass:240  dwarn:2   dfail:0   fail:0   skip:36  
time:567s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:513s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:539s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:487s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:406s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:404s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:421s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:498s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:470s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:455s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:567s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:451s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:573s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:463s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:491s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:431s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:397s

459f7d04deb6549ed4f27957ec414b727dc763f3 drm-tip: 2017y-04m-26d-16h-05m-26s UTC 
integration manifest
2b1a423 drm/dp: Track MST link bandwidth
e13e106 drm/dp: Add DP MST helpers to atomically find and release vcpi slots
8c8e519 drm/dp: Introduce MST topology state to track available link bandwidth
5fd2a0b drm: Add driver-private objects to atomic state

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4560/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 0/4] Adding driver-private objects to atomic state

[Pandiyan, Dhinakaran]

On Mon, 2017-04-24 at 11:53 -0400, Harry Wentland wrote:
> Patches 1-3: Reviewed-by: Harry Wentland 
> Patch 4: Acked-by: Harry Wentland 
> 
> Harry
> 

Thanks for the review.

-DK



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

[Intel-gfx] [PATCH v8 1/4] drm: Add driver-private objects to atomic state

[Dhinakaran Pandiyan]

From: "Pandiyan, Dhinakaran" 

It is necessary to track states for objects other than connector, crtc
and plane for atomic modesets. But adding objects like DP MST link
bandwidth to drm_atomic_state would mean that a non-core object will be
modified by the core helper functions for swapping and clearing
it's state. So, lets add void * objects and helper functions that operate
on void * types to keep these objects and states private to the core.
Drivers can then implement specific functions to swap and clear states.
The other advantage having just void * for these objects in
drm_atomic_state is that objects of different types can be managed in the
same state array.

v6: More kernel-doc to keep 0-day happy
v5: Remove more NULL checks (Maarten)
v4: Avoid redundant NULL checks when private_objs array is empty (Maarten)
v3: Macro alignment (Chris)
v2: Added docs and new iterator to filter private objects (Daniel)

Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Archit Taneja 
Cc: Chris Wilson 
Cc: Harry Wentland 

Acked-by: Harry Wentland 
Suggested-by: Daniel Vetter 
Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_atomic.c| 65 +
 drivers/gpu/drm/drm_atomic_helper.c |  5 ++
 include/drm/drm_atomic.h| 95 +
 3 files changed, 165 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 30229ab..8e5f3eb 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct drm_atomic_state 
*state)
kfree(state->connectors);
kfree(state->crtcs);
kfree(state->planes);
+   kfree(state->private_objs);
 }
 EXPORT_SYMBOL(drm_atomic_state_default_release);
 
@@ -184,6 +185,17 @@ void drm_atomic_state_default_clear(struct 
drm_atomic_state *state)
state->planes[i].ptr = NULL;
state->planes[i].state = NULL;
}
+
+   for (i = 0; i < state->num_private_objs; i++) {
+   void *obj_state = state->private_objs[i].obj_state;
+
+   state->private_objs[i].funcs->destroy_state(obj_state);
+   state->private_objs[i].obj = NULL;
+   state->private_objs[i].obj_state = NULL;
+   state->private_objs[i].funcs = NULL;
+   }
+   state->num_private_objs = 0;
+
 }
 EXPORT_SYMBOL(drm_atomic_state_default_clear);
 
@@ -978,6 +990,59 @@ static void drm_atomic_plane_print_state(struct 
drm_printer *p,
 }
 
 /**
+ * drm_atomic_get_private_obj_state - get private object state
+ * @state: global atomic state
+ * @obj: private object to get the state for
+ * @funcs: pointer to the struct of function pointers that identify the object
+ * type
+ *
+ * This function returns the private object state for the given private object,
+ * allocating the state if needed. It does not grab any locks as the caller is
+ * expected to care of any required locking.
+ *
+ * RETURNS:
+ *
+ * Either the allocated state or the error code encoded into a pointer.
+ */
+void *
+drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj,
+ const struct drm_private_state_funcs *funcs)
+{
+   int index, num_objs, i;
+   size_t size;
+   struct __drm_private_objs_state *arr;
+
+   for (i = 0; i < state->num_private_objs; i++)
+   if (obj == state->private_objs[i].obj &&
+   state->private_objs[i].obj_state)
+   return state->private_objs[i].obj_state;
+
+   num_objs = state->num_private_objs + 1;
+   size = sizeof(*state->private_objs) * num_objs;
+   arr = krealloc(state->private_objs, size, GFP_KERNEL);
+   if (!arr)
+   return ERR_PTR(-ENOMEM);
+
+   state->private_objs = arr;
+   index = state->num_private_objs;
+   memset(>private_objs[index], 0, sizeof(*state->private_objs));
+
+   state->private_objs[index].obj_state = funcs->duplicate_state(state, 
obj);
+   if (!state->private_objs[index].obj_state)
+   return ERR_PTR(-ENOMEM);
+
+   state->private_objs[index].obj = obj;
+   state->private_objs[index].funcs = funcs;
+   state->num_private_objs = num_objs;
+
+   DRM_DEBUG_ATOMIC("Added new private object state %p to %p\n",
+state->private_objs[index].obj_state, state);
+
+   return state->private_objs[index].obj_state;
+}
+EXPORT_SYMBOL(drm_atomic_get_private_obj_state);
+
+/**
  * drm_atomic_get_connector_state - get connector state
  * @state: global atomic state object
  * @connector: connector to get state object for
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 

Re: [Intel-gfx] [PATCH v7 4/4] drm/dp: Track MST link bandwidth

[Pandiyan, Dhinakaran]

On Tue, 2017-04-25 at 09:51 +0200, Maarten Lankhorst wrote:
> On 21-04-17 07:51, Dhinakaran Pandiyan wrote:
> > From: "Pandiyan, Dhinakaran" 
> >
> > Use the added helpers to track MST link bandwidth for atomic modesets.
> > Link bw is acquired in the ->atomic_check() phase when CRTCs are being
> > enabled with drm_atomic_find_vcpi_slots() instead of drm_find_vcpi_slots().
> > Similarly, link bw is released during ->atomic_check() with the connector
> > helper callback ->atomic_release() when CRTCs are disabled.
> >
> > v5: Implement connector->atomic_check() in place of atomic_release()
> > v4: Return an int from intel_dp_mst_atomic_release() (Maarten)
> > v3:
> >  Handled the case where ->atomic_release() is called more than once
> >  during an atomic_check() for the same state.
> > v2:
> >  Squashed atomic_release() implementation and caller (Daniel)
> >  Fixed logic for connector-crtc switching case (Daniel)
> >  Fixed logic for suspend-resume case.
> >
> > Cc: Daniel Vetter 
> > Cc: Maarten Lankhorst 
> > Cc: Archit Taneja 
> > Cc: Chris Wilson 
> > Cc: Harry Wentland 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_mst.c | 57 
> > +
> >  1 file changed, 51 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> > b/drivers/gpu/drm/i915/intel_dp_mst.c
> > index 5af22a7..20c557c 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -39,9 +39,9 @@ static bool intel_dp_mst_compute_config(struct 
> > intel_encoder *encoder,
> > struct intel_dp *intel_dp = _dig_port->dp;
> > struct intel_connector *connector =
> > to_intel_connector(conn_state->connector);
> > -   struct drm_atomic_state *state;
> > +   struct drm_atomic_state *state = pipe_config->base.state;
> > int bpp;
> > -   int lane_count, slots;
> > +   int lane_count, slots = 0;
> > const struct drm_display_mode *adjusted_mode = 
> > _config->base.adjusted_mode;
> > int mst_pbn;
> >  
> > @@ -63,24 +63,68 @@ static bool intel_dp_mst_compute_config(struct 
> > intel_encoder *encoder,
> > pipe_config->pipe_bpp = bpp;
> > pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
> >  
> > -   state = pipe_config->base.state;
> > -
> > if (drm_dp_mst_port_has_audio(_dp->mst_mgr, connector->port))
> > pipe_config->has_audio = true;
> > -   mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
> >  
> > +   mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
> > pipe_config->pbn = mst_pbn;
> > -   slots = drm_dp_find_vcpi_slots(_dp->mst_mgr, mst_pbn);
> >  
> > intel_link_compute_m_n(bpp, lane_count,
> >adjusted_mode->crtc_clock,
> >pipe_config->port_clock,
> >_config->dp_m_n);
> >  
> > +   if (pipe_config->base.active) {
> Is this check needed? If so it needs a comment as to why.
> 
> I know that the output won't actually turn on, but if the crtc is configured 
> vcpi slots should be allocated if possible.
> 
> Else the following will fail in the wrong place:
> 1. Configure CRTC with a valid mode and DP-MST connector, but set 
> active=false. connectors_changed = true, mode_changed = true. Not enough VCPI 
> slots to enable all crtc's at the same time now, but this returns OK.
> 2. Commit with active property set to true. There are too few vcpi slots to 
> make this work, this atomic commit returns -EINVAL. This might happen on a 
> different crtc than the newly configured one in stap 1, if they were all 
> previously set to !active.
> 
Thanks for the review. 
 
I am not sure if it's supposed to fail earlier i.e, when active=false,
connectors_changed = true, mode_changed = true.

In your example, 
1. We have enough vcpi slots for crtc1 and crtc2- for both active=false
and enable=true.
2. Now, crtc3 is also configured with active=false and it does not have
enough bandwidth to be active along with crtc1 and crtc2. 
3. You are saying the problem is that if there is a commit with crtc3,
crtc2, crtc1, in that order, setting active=true, then the commit will
fail?


I don't know how likely this scenario is, but what if userspace is not
going to set crtc1 and crtc2 active=true at all and we return -EINVAL in
Step2 for crtc3?


iiuc we disable pipes, drop payload allocations, disable shared_dpll
when active goes from true->false, even if enable is still true. For eg.
this happens when I 'xset dpms force standby' without these patches. If
we are dropping resources when active goes true->false with enable=true,
shouldn't we also acquire only when active changes from false->true ?


-DK

> > +   slots = drm_dp_atomic_find_vcpi_slots(state, 

Re: [Intel-gfx] [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

[Logan Gunthorpe]

On 26/04/17 02:59 AM,   wrote:
> Good to know that somebody is working on this. Those problems troubled
> us as well.

Thanks Christian. It's a daunting problem and a there's a lot of work to
do before we will ever be where we need to be so any help, even an ack,
is greatly appreciated.

Logan

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

Re: [Intel-gfx] [PATCH 07/27] drm/i915: Squash repeated awaits on the same fence

[Chris Wilson]

On Wed, Apr 26, 2017 at 07:56:14PM +0100, Chris Wilson wrote:
> On Wed, Apr 26, 2017 at 01:13:41PM +0100, Tvrtko Ursulin wrote:
> > I was thinking of exactly the same thing as this patch does, u64
> > context id as key, u32 seqnos (wrapped in a container with
> > hlist_node).
> 
> #define NSYNC 32
> struct intel_timeline_sync { /* kmalloc-256 slab */
>   struct hlist_node node;
> u64 prefix;
>   u32 bitmap;
>   u32 seqno[NSYNC];
> };
> DECLARE_HASHTABLE(sync, 7);
> 
> If I squint, the numbers favour the idr. ;)

Hmm, it didn't take much to start running into misery with a static ht.
I know my testing is completely artificial but I am not going to be
happy with a static size, it will always be too big or too small and
never just Goldilocks.
-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 v8 1/2] ACPI / bus: Introduce a list of ids for "always present" devices

[Rafael J. Wysocki]

On Friday, April 21, 2017 01:43:51 PM Hans de Goede wrote:
> Hi,
> 
> On 21-04-17 13:38, Andy Shevchenko wrote:
> > On Fri, 2017-04-21 at 12:47 +0200, Hans de Goede wrote:
> >> Several Bay / Cherry Trail devices (all of which ship with Windows 10)
> >> hide
> >> the LPSS PWM controller in ACPI, typically the _STA method looks like
> >> this:
> >>
> >>  Method (_STA, 0, NotSerialized)  // _STA: Status
> >>  {
> >>  If (OSID == One)
> >>  {
> >>  Return (Zero)
> >>  }
> >>
> >>  Return (0x0F)
> >>  }
> >>
> >> Where OSID is some dark magic seen in all Cherry Trail ACPI tables
> >> making
> >> the machine behave differently depending on which OS it *thinks* it is
> >> booting, this gets set in a number of ways which we cannot control, on
> >> some newer machines it simple hardcoded to "One" aka win10.
> >>
> >> This causes the PWM controller to get hidden, which means Linux cannot
> >> control the backlight level on cht based tablets / laptops.
> >>
> >> Since loading the driver for this does no harm (the only in kernel
> >> user
> >> of it is the i915 driver, which will only uses it when it needs it),
> >> this
> >> commit makes acpi_bus_get_status() always set status to
> >> ACPI_STA_DEFAULT
> >> for the LPSS PWM device, fixing the lack of backlight control.
> >>
> > 
> >>   drivers/acpi/Makefile|  1 +
> >>   drivers/acpi/bus.c   |  5 +++
> >>   drivers/acpi/x86/x86_utils.c | 85
> >> 
> > 
> > Perhaps .../x86/utils.c ?
> 
> I thought that utils.c would be too generic,
> but that was mainly thinking about module kernel
> cmdline options which do not apply here, still
> having a somewhat unique basename seems useful.

I renamed it to util.c while applying the patches.

Thanks,
Rafael

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

Re: [Intel-gfx] [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions

[Logan Gunthorpe]

On 26/04/17 01:44 AM, Christoph Hellwig wrote:
> I think we'll at least need a draft of those to make sense of these
> patches.  Otherwise they just look very clumsy.

Ok, I'll work up a draft proposal and send it in a couple days. But
without a lot of cleanup such as this series it's not going to even be
able to compile.

> I'm sorry but this API is just a trainwreck.  Right now we have the
> nice little kmap_atomic API, which never fails and has a very nice
> calling convention where we just pass back the return address, but does
> not support sleeping inside the critical section.
> 
> And kmap, whіch may fail and requires the original page to be passed
> back.  Anything that mixes these two concepts up is simply a non-starter.

Ok, well for starters I think you are mistaken about kmap being able to
fail. I'm having a hard time finding many users of that function that
bother to check for an error when calling it. The main difficulty we
have now is that neither of those functions are expected to fail and we
need them to be able to in cases where the page doesn't map to system
RAM. This patch series is trying to address it for users of scatterlist.
I'm certainly open to other suggestions.

I also have to disagree that kmap and kmap_atomic are all that "nice".
Except for the sleeping restriction and performance, they effectively do
the same thing. And it was necessary to write a macro wrapper around
kunmap_atomic to ensure that users of that function don't screw it up.
(See 597781f3e5.) I'd say the kmap/kmap_atomic functions are the
trainwreck and I'm trying to do my best to cleanup a few cases.

There are a fair number of cases in the kernel that do something like:

if (something)
x = kmap(page);
else
x = kmap_atomic(page);
...
if (something)
kunmap(page)
else
kunmap_atomic(x)

Which just seems cumbersome to me.

In any case, if you can accept an sg_kmap and sg_kmap_atomic api just
say so and I'll make the change. But I'll still need a flags variable
for SG_MAP_MUST_NOT_FAIL to support legacy cases that have no fail path
and both of those functions will need to be pretty nearly replicas of
each other.

Logan


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

Re: [Intel-gfx] [PATCH 00/11] drm/i915: LPE audio runtime PM and multipipe

[Ville Syrjälä]

On Wed, Apr 26, 2017 at 03:47:44PM +0200, Takashi Iwai wrote:
> On Wed, 26 Apr 2017 15:38:53 +0200,
> Ville Syrjälä wrote:
> > 
> > On Wed, Apr 26, 2017 at 09:29:18AM +0200, Takashi Iwai wrote:
> > > On Tue, 25 Apr 2017 22:27:19 +0200,
> > > ville.syrj...@linux.intel.com wrote:
> > > > 
> > > > From: Ville Syrjälä 
> > > > 
> > > > I was wondering why my VLV no longer runtime suspended, and after some
> > > > thinking I decided it had to be the LPE audio preventing it. Turns out
> > > > I was right, so here's my attempt at fixing it.
> > > > 
> > > > And while looking at the code I couldn't help but notice that it
> > > > couldn't actually handle multiple pipes playing back audio at the
> > > > same time. And even having multiple displays active even if only
> > > > one was playing audio was probably a recipe for failure. So I
> > > > tried to fix that by registering a separate PCM device for each
> > > > pipe.
> > > > 
> > > > Note that the patch subjects may not reflect the subsystem
> > > > very well since most of these straddle the border between drm
> > > > and alsa. I think I just slapped on drm/i915 to most where
> > > > there was no clear winner.
> > > 
> > > A nice patchset, thanks for working on it!
> > > 
> > > One slight concern (other than the jack issue Pierre reported) is the
> > > incompatible behavior from the current version.  With the pipe-based
> > > multiple streams, user would need to choose another one even if the
> > > device has a single HDMI output, which is pretty common on BYT/CHV
> > > tablets.
> > > 
> > > Maybe it's no big problem as the users are still limited at the
> > > moment.  Or, we may need to handle a bit differently, e.g. assigning
> > > the PCM stream dynamically per hotplug.
> > 
> > Yeah, I tied the PCM device to the pipe to match the hardware. But we
> > could certainly register the PCM device per port, and then do a 
> > pipe<->port mapping somewhere to make it all work out. One slight
> > complication is that not all ports are necessarily present so we
> > might have eg. just port B and port D, but no port C. Not sure if
> > it would be a bad thing to register a PCM device even for the
> > missing ports anyway?
> > 
> > I don't recall which way HDA works. Device per port I guess? Well,
> > for DP SST/HDMI. But for DP MST I presume it's device per stream
> > (ie. pipe) even with HDA.
> 
> HD-audio creates the PCM device per HD-audio widget representation,
> and they correspond to ports, as it seems.  For MST, the situation is
> more complex, and we assign the PCM stream dynamically.  It's for
> keeping the behavior (more or less) consistent with non-MST.

OK, I hacked together something that seems to work. I'll still need
to squash it with the earlier patch, but in case you want to see what
the relative changes look like I pushed it to
git://github.com/vsyrjala/linux.git lpe_audio_multipipe

-- 
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 RESEND i-g-t 1/2] tests/kms_frontbuffer_tracking: Skip if CRTC not selected

[Zanoni, Paulo R]

Em Qua, 2017-04-26 às 15:40 -0300, Gabriel Krisman Bertazi escreveu:
> Paulo Zanoni  writes:
> 
> > 
> > Em Qui, 2017-04-20 às 11:11 -0300, Gabriel Krisman Bertazi
> > escreveu:
> > > 
> > > After Linux commit f7e9b004b8a3 ("drm/i915/fbc: inline
> > > intel_fbc_can_choose()"), no_fbc_reason will be updated to a new
> > > error
> > > message if we don't have a plane in the new state, which should
> > > make
> > > the
> > > test skip, but the test code doesn't catch that message and tries
> > > to
> > 
> > What was the previous message that was making the test skip? I was
> > not
> > expecting that patch would affect kms_frontbuffer_tracking
> > behavior.
> 
> The previous message was "FBC disabled: not enough stolen
> memory".  You
> got me wondering if we should even enter that function if
> intel_fbc_alloc_cfb failed.  The patch I mentioned starts triggering
> the
> failure because it changes the error message even if we never enter
> the
> for_each_new_plane_in_state loop in intel_fbc_choose_crtc.
> 
> Does that makes sense?  Let me take another look at the code and see
> what I can come up with.

I think I understand the problem now. My problem with the current
approach is that it changes the kms_frontbuffer_tracking behavior for
more cases than the one affected by this bug, so there's a risk we're
going to end up skipping when we should really be failing. Any case
where we end up not finding a suitable CRTC will be skipped, instead of
only skipping where we can't find a suitable CRTC due to not having
enough stolen memory.

I was already planning on maybe switching opt.small_modes to default as
true. This should help not only on cases where there's not enough
stolen memory, but also on cases where the monitor resolution is too
big for FBC. This would fix the bug.

The reason why I still didn't switch opt.small_modes to true by default
is because I didn't check if doing this will introduce any other
unintended regressions. It shouldn't, but we'll never know until we
actually try. Maybe we should check this with the CI team.

For our CI machines specifically, I think we should also consider just
going to their BIOSes and increasing the amount of stolen memory. We
really want to try to minimize the amount of SKIPs in cases where we
could be testing stuff, so increasing the amount of stolen memory
really sounds the ideal solution for CI.

So 3 possible solutions (and maybe we should do them all):

- Switch opt.small_modes to true by default, and check if this exposes
new problems.
- Increase the amount of stolen memory for CI machines.
- Somehow go back to the previous behavior where the Kernel tells us
that it tried to enable FBC but there's not enough stolen memory.

Thanks,
Paulo

> 
> 
> > 
> > 
> > > 
> > > execute the test, triggering a test failure.
> > 
> > Anyway, I'm trying to understand the situation here. I'm not sure
> > if
> > this fix is correct, I'm wondering if it's a problem in how the
> > Kernel
> > sets the messages. Please explain in more details why this patch
> > does
> > what it does.
> > 
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/27] drm/i915: Squash repeated awaits on the same fence

[Chris Wilson]

On Wed, Apr 26, 2017 at 01:13:41PM +0100, Tvrtko Ursulin wrote:
> I was thinking of exactly the same thing as this patch does, u64
> context id as key, u32 seqnos (wrapped in a container with
> hlist_node).

#define NSYNC 32
struct intel_timeline_sync { /* kmalloc-256 slab */
struct hlist_node node;
u64 prefix;
u32 bitmap;
u32 seqno[NSYNC];
};
DECLARE_HASHTABLE(sync, 7);

If I squint, the numbers favour the idr. ;)

Tbh, the precence of the squash is noticeable and well above the noise,
the difference between a hashtable and the idr, far below the noise
floor (in a testcase intended to stress the efficacy of this patch). The
cost of reference counting in execbuffer and the reservation_object hide
all ills. :(

What I am not happy with is the 1<<7 buckets I'm currently using.
Thinking about the idle pruning, there shouldn't be any reason to go
above 1<<3, I hope?

Do we start on GEM_STATS?
-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 RESEND i-g-t 1/2] tests/kms_frontbuffer_tracking: Skip if CRTC not selected

[Gabriel Krisman Bertazi]

Paulo Zanoni  writes:

> Em Qui, 2017-04-20 às 11:11 -0300, Gabriel Krisman Bertazi escreveu:
>> After Linux commit f7e9b004b8a3 ("drm/i915/fbc: inline
>> intel_fbc_can_choose()"), no_fbc_reason will be updated to a new
>> error
>> message if we don't have a plane in the new state, which should make
>> the
>> test skip, but the test code doesn't catch that message and tries to
>
> What was the previous message that was making the test skip? I was not
> expecting that patch would affect kms_frontbuffer_tracking behavior.

The previous message was "FBC disabled: not enough stolen memory".  You
got me wondering if we should even enter that function if
intel_fbc_alloc_cfb failed.  The patch I mentioned starts triggering the
failure because it changes the error message even if we never enter the
for_each_new_plane_in_state loop in intel_fbc_choose_crtc.

Does that makes sense?  Let me take another look at the code and see
what I can come up with.


>
>> execute the test, triggering a test failure.
>
> Anyway, I'm trying to understand the situation here. I'm not sure if
> this fix is correct, I'm wondering if it's a problem in how the Kernel
> sets the messages. Please explain in more details why this patch does
> what it does.
>

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

Re: [Intel-gfx] [PATCH RESEND i-g-t 2/2] kms_frontbuffer_tracking: Don't poke compressing status for old cpus

[Paulo Zanoni]

Em Qua, 2017-04-26 às 21:12 +0300, Ville Syrjälä escreveu:
> On Wed, Apr 26, 2017 at 02:57:49PM -0300, Gabriel Krisman Bertazi
> wrote:
> > 
> > Paulo Zanoni  writes:
> > 
> > > 
> > > Ouch... Good catch!
> > > 
> > > Can you please move the logic to the setup_fbc() function?
> > > 
> > > if (gen < 7)
> > >   opt.fbc_check_compression = false;
> > > 
> > > This way we avoid redoing the same check a trillion times during
> > > kms_frontbuffer_tracking execution.
> > > 
> > > Also, I think this one also lacks a Bugzilla tag:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=100677
> > 
> > Hmm, yeah, I forgot CC'ing the list when resending. Sorry about
> > that.
> > 
> > Thanks for reviewing.  Can you take a look at the following version
> > instead?
> > 
> > > 
> > > 8
> > Subject: [PATCH] kms_frontbuffer_tracking: Don't poke compressing
> > status for
> >  old cpus
> > 
> > Commit 2804afc606f8 ("kms_frontbuffer_tracking: fix compression
> > checking") removes the check whether the kernel supports reporting
> > the
> > compression status before asserting on it.  This breaks the test
> > for no
> > good reason on old CPUs (SNB and earlier) where the kernel can't
> > report
> > the compression status.  Instead, we can check if the cpu doesn't
> > support reporting and adopt the same behavior as if
> 
> I have a feeling I asked this before, but why aren't we just fixing
> the kernel to report it correctly? For any platform with FBC2 it
> should be trivial,

Right, I see there's a reg for that for ILK/SNB.

>  for FBC1 slightly more complicate as you probably
> have to check each individual tag.

I didn't check the docs for that.

Maybe we should change the comment from "early generations are not able
to report compression status" to something more accurate like "the
Kernel doesn't report compression status for early generations".


There are quite a few different ways to solve the problem involved in
this patch, and some of the would remove the need to check for platform
generations in the user space side. An example alternative would be to
always print "Compressing: " and then put "no" when FBC is disabled and
"unknown" for platforms where we don't know what to print. In fact it's
still on my TODO list to add a ton more information to i915_fbc_status,
but I'm not going to work on that soon. And there's always the problem
with having to sync Kernel and IGT.

Anyway, the current patch plugs the current hole, so I think further
improvements to this area can come on top of it:

Reviewed-by: Paulo Zanoni 


> 
> > 
> > --no-fbc-compression-check was used.
> > 
> > Changes since v1:
> >   - Move verification to setup_fbc (Paulo)
> > 
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100677
> > Signed-off-by: Gabriel Krisman Bertazi 
> > ---
> >  tests/kms_frontbuffer_tracking.c | 6 ++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/tests/kms_frontbuffer_tracking.c
> > b/tests/kms_frontbuffer_tracking.c
> > index b49f1abacae8..a655730b4ad3 100644
> > --- a/tests/kms_frontbuffer_tracking.c
> > +++ b/tests/kms_frontbuffer_tracking.c
> > @@ -1524,6 +1524,7 @@ static bool fbc_supported_on_chipset(void)
> >  static void setup_fbc(void)
> >  {
> >     drmModeConnectorPtr c =
> > get_connector(prim_mode_params.connector_id);
> > +   int devid = intel_get_drm_devid(drm.fd);
> >  
> >     if (!fbc_supported_on_chipset()) {
> >     igt_info("Can't test FBC: not supported on this
> > chipset\n");
> > @@ -1540,6 +1541,11 @@ static void setup_fbc(void)
> >      "pipe A\n");
> >     return;
> >     }
> > +
> > +   /* Early Generations are not able to report compression
> > status. */
> > +   if (!AT_LEAST_GEN(devid, 7))
> > +   opt.fbc_check_compression = false;
> > +
> >     fbc.can_test = true;
> >  
> >     fbc_setup_last_action();
> > -- 
> > 2.11.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH RESEND i-g-t 2/2] kms_frontbuffer_tracking: Don't poke compressing status for old cpus

[Ville Syrjälä]

On Wed, Apr 26, 2017 at 02:57:49PM -0300, Gabriel Krisman Bertazi wrote:
> Paulo Zanoni  writes:
> 
> > Ouch... Good catch!
> >
> > Can you please move the logic to the setup_fbc() function?
> >
> > if (gen < 7)
> > opt.fbc_check_compression = false;
> >
> > This way we avoid redoing the same check a trillion times during
> > kms_frontbuffer_tracking execution.
> >
> > Also, I think this one also lacks a Bugzilla tag:
> > https://bugs.freedesktop.org/show_bug.cgi?id=100677
> 
> Hmm, yeah, I forgot CC'ing the list when resending. Sorry about that.
> 
> Thanks for reviewing.  Can you take a look at the following version
> instead?
> 
> >8
> Subject: [PATCH] kms_frontbuffer_tracking: Don't poke compressing status for
>  old cpus
> 
> Commit 2804afc606f8 ("kms_frontbuffer_tracking: fix compression
> checking") removes the check whether the kernel supports reporting the
> compression status before asserting on it.  This breaks the test for no
> good reason on old CPUs (SNB and earlier) where the kernel can't report
> the compression status.  Instead, we can check if the cpu doesn't
> support reporting and adopt the same behavior as if

I have a feeling I asked this before, but why aren't we just fixing
the kernel to report it correctly? For any platform with FBC2 it
should be trivial, for FBC1 slightly more complicate as you probably
have to check each individual tag.

> --no-fbc-compression-check was used.
> 
> Changes since v1:
>   - Move verification to setup_fbc (Paulo)
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100677
> Signed-off-by: Gabriel Krisman Bertazi 
> ---
>  tests/kms_frontbuffer_tracking.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tests/kms_frontbuffer_tracking.c 
> b/tests/kms_frontbuffer_tracking.c
> index b49f1abacae8..a655730b4ad3 100644
> --- a/tests/kms_frontbuffer_tracking.c
> +++ b/tests/kms_frontbuffer_tracking.c
> @@ -1524,6 +1524,7 @@ static bool fbc_supported_on_chipset(void)
>  static void setup_fbc(void)
>  {
>   drmModeConnectorPtr c = get_connector(prim_mode_params.connector_id);
> + int devid = intel_get_drm_devid(drm.fd);
>  
>   if (!fbc_supported_on_chipset()) {
>   igt_info("Can't test FBC: not supported on this chipset\n");
> @@ -1540,6 +1541,11 @@ static void setup_fbc(void)
>"pipe A\n");
>   return;
>   }
> +
> + /* Early Generations are not able to report compression status. */
> + if (!AT_LEAST_GEN(devid, 7))
> + opt.fbc_check_compression = false;
> +
>   fbc.can_test = true;
>  
>   fbc_setup_last_action();
> -- 
> 2.11.0
> 
> ___
> 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

Re: [Intel-gfx] [PATCH RESEND i-g-t 2/2] kms_frontbuffer_tracking: Don't poke compressing status for old cpus

[Gabriel Krisman Bertazi]

Paulo Zanoni  writes:

> Ouch... Good catch!
>
> Can you please move the logic to the setup_fbc() function?
>
> if (gen < 7)
>   opt.fbc_check_compression = false;
>
> This way we avoid redoing the same check a trillion times during
> kms_frontbuffer_tracking execution.
>
> Also, I think this one also lacks a Bugzilla tag:
> https://bugs.freedesktop.org/show_bug.cgi?id=100677

Hmm, yeah, I forgot CC'ing the list when resending. Sorry about that.

Thanks for reviewing.  Can you take a look at the following version
instead?

>8
Subject: [PATCH] kms_frontbuffer_tracking: Don't poke compressing status for
 old cpus

Commit 2804afc606f8 ("kms_frontbuffer_tracking: fix compression
checking") removes the check whether the kernel supports reporting the
compression status before asserting on it.  This breaks the test for no
good reason on old CPUs (SNB and earlier) where the kernel can't report
the compression status.  Instead, we can check if the cpu doesn't
support reporting and adopt the same behavior as if
--no-fbc-compression-check was used.

Changes since v1:
  - Move verification to setup_fbc (Paulo)

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100677
Signed-off-by: Gabriel Krisman Bertazi 
---
 tests/kms_frontbuffer_tracking.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/tests/kms_frontbuffer_tracking.c b/tests/kms_frontbuffer_tracking.c
index b49f1abacae8..a655730b4ad3 100644
--- a/tests/kms_frontbuffer_tracking.c
+++ b/tests/kms_frontbuffer_tracking.c
@@ -1524,6 +1524,7 @@ static bool fbc_supported_on_chipset(void)
 static void setup_fbc(void)
 {
drmModeConnectorPtr c = get_connector(prim_mode_params.connector_id);
+   int devid = intel_get_drm_devid(drm.fd);
 
if (!fbc_supported_on_chipset()) {
igt_info("Can't test FBC: not supported on this chipset\n");
@@ -1540,6 +1541,11 @@ static void setup_fbc(void)
 "pipe A\n");
return;
}
+
+   /* Early Generations are not able to report compression status. */
+   if (!AT_LEAST_GEN(devid, 7))
+   opt.fbc_check_compression = false;
+
fbc.can_test = true;
 
fbc_setup_last_action();
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH] drm/i915: Update MOCS settings for gen 9

[Francisco Jerez]

Hi David,

David Weinehall  writes:

> Add a bunch of MOCS entries for gen 9 that were missing from intel_mocs.
> Some of these are used by media-sdk; if these entries are missing
> the default will instead be to do everything uncached.
>

Keep in mind that MOCS entries are not for free -- Once you expose a new
entry it will become part of the kernel ABI and we won't ever be able to
re-use them for another purpose.  What this means is we probably don't
want to add a bunch of entries if only "some" of them are actually
useful to the open-source stack.  Some more comments below.

> This patch improves media-sdk performance with up to 60%
> with the (admittedly synthetic) benchmarks we use in our nightly
> testing, without regressing any other benchmarks.
>
> Signed-off-by: David Weinehall 
>
> diff --git a/drivers/gpu/drm/i915/intel_mocs.c 
> b/drivers/gpu/drm/i915/intel_mocs.c
> index 92e461c68385..5236a442a14f 100644
> --- a/drivers/gpu/drm/i915/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/intel_mocs.c
> @@ -103,7 +103,6 @@ static const struct drm_i915_mocs_entry 
> skylake_mocs_table[] = {
>  LE_TGT_CACHE(LE_TC_LLC_ELLC) |
>  LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
>  LE_PFM(0) | LE_SCF(0),
> -
> /* 0x0010 */
> .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
>   },
> @@ -123,7 +122,133 @@ static const struct drm_i915_mocs_entry 
> skylake_mocs_table[] = {
>  LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
>  LE_PFM(0) | LE_SCF(0),
> /* 0x0030 */
> -   .l3cc_value =   L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
> +   .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
> + },
> + {

Apparently somebody started defining symbolic enums for the current MOCS
entries in i915_drm.h, which I guess makes this more obviously tied to
the kernel ABI.  I suppose it wouldn't hurt if you did the same.

> +   /* 0x0037 */
> +   .control_value = LE_CACHEABILITY(LE_WB) |
> +LE_TGT_CACHE(LE_TC_LLC) |
> +LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
> +LE_PFM(0) | LE_SCF(0),
> +   /* 0x0030 */
> +   .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
> + },
> + {
> +   /* 0x0039 */
> +   .control_value = LE_CACHEABILITY(LE_UC) |
> +LE_TGT_CACHE(LE_TC_LLC_ELLC) |
> +LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
> +LE_PFM(0) | LE_SCF(0),
> +   /* 0x0030 */
> +   .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
> + },
> + {
> +   /* 0x0033 */
> +   .control_value = LE_CACHEABILITY(LE_WB) |
> +LE_TGT_CACHE(LE_TC_PAGETABLE) |
> +LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
> +LE_PFM(0) | LE_SCF(0),
> +   /* 0x0030 */
> +   .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
> + },

What's the use of an entry with PTE-controlled target cache if you're
overriding the cacheability control to WB anyway?  Seems effectively
redundant with the current I915_MOCS_CACHED entry.  Same for the
0x33:0x10, 0x13:0x10 and 0x3:0x10 entries below.

> + {
> +   /* 0x0017 */
> +   .control_value = LE_CACHEABILITY(LE_WB) |
> +LE_TGT_CACHE(LE_TC_LLC) |
> +LE_LRUM(1) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
> +LE_PFM(0) | LE_SCF(0),
> +   /* 0x0030 */
> +   .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
> + },
> + {
> +   /* 0x0037 */
> +   .control_value = LE_CACHEABILITY(LE_WB) |
> +LE_TGT_CACHE(LE_TC_LLC) |
> +LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
> +LE_PFM(0) | LE_SCF(0),
> +   /* 0x0010 */
> +   .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
> + },
> + {
> +   /* 0x0039 */
> +   .control_value = LE_CACHEABILITY(LE_UC) |
> +LE_TGT_CACHE(LE_TC_LLC_ELLC) |
> +LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
> +LE_PFM(0) | LE_SCF(0),
> +   /* 0x0010 */
> +   .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
> + },

This entry is UC in all caches and seems redundant with the current
I915_MOCS_UNCACHED entry.  Why do you need it?

> + {
> +   /* 0x0017 */
> +   .control_value = LE_CACHEABILITY(LE_WB) |
> +LE_TGT_CACHE(LE_TC_LLC) |
> +LE_LRUM(1) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
> +LE_PFM(0) | LE_SCF(0),

[Intel-gfx] [PATCH v2] tests/pm_sseu: Re-enable the test

[Oscar Mateo]

This test got inadvertently disabled by commit 83884e97 (Restore
"lib: Open debugfs files for the given DRM device") when the
initialization order got changed (dbg_init before gem_init).

v2:
  - The asserts on fd are useless (Petri)
  - Deinit in inverse order.

Cc: Petri Latvala 
Signed-off-by: Oscar Mateo 
---
 tests/pm_sseu.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/tests/pm_sseu.c b/tests/pm_sseu.c
index 317bb26..7d4b33c 100644
--- a/tests/pm_sseu.c
+++ b/tests/pm_sseu.c
@@ -187,6 +187,7 @@ dbg_get_status(struct status *stat)
 static void
 dbg_init(void)
 {
+   igt_assert(gem.init);
dbg.status_fd = igt_debugfs_open(gem.drm_fd, "i915_sseu_status", 
O_RDONLY);
igt_skip_on_f(dbg.status_fd == -1,
  "debugfs entry 'i915_sseu_status' not found\n");
@@ -354,8 +355,8 @@ full_enable(void)
 static void
 exit_handler(int sig)
 {
-   gem_deinit();
dbg_deinit();
+   gem_deinit();
 }
 
 igt_main
@@ -363,8 +364,8 @@ igt_main
igt_fixture {
igt_install_exit_handler(exit_handler);
 
-   dbg_init();
gem_init();
+   dbg_init();
}
 
igt_subtest("full-enable")
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v2 7/8] drm/i915/lvds: Remove magic from PLL programming

[Ville Syrjälä]

On Wed, Apr 26, 2017 at 08:18:06PM +0300, Imre Deak wrote:
> This looks like a left-over from enabling work. The spec defines
> CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED as reserved set, so follow
> this in the programming.
> 
> v2:
> - Follow the spec to set CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED.
>   (Ville)
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Imre Deak 

Reviewed-by: Ville Syrjälä 

> ---
>  drivers/gpu/drm/i915/dvo_ch7017.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/dvo_ch7017.c 
> b/drivers/gpu/drm/i915/dvo_ch7017.c
> index b3c7c19..80b3e16 100644
> --- a/drivers/gpu/drm/i915/dvo_ch7017.c
> +++ b/drivers/gpu/drm/i915/dvo_ch7017.c
> @@ -280,10 +280,10 @@ static void ch7017_mode_set(struct intel_dvo_device 
> *dvo,
>   (0 << CH7017_PHASE_DETECTOR_SHIFT);
>   } else {
>   outputs_enable = CH7017_LVDS_CHANNEL_A | 
> CH7017_CHARGE_PUMP_HIGH;
> - lvds_pll_feedback_div = 
> CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED |
> + lvds_pll_feedback_div =
> + CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED |
>   (2 << CH7017_LVDS_PLL_FEED_BACK_DIVIDER_SHIFT) |
>   (3 << CH7017_LVDS_PLL_FEED_FORWARD_DIVIDER_SHIFT);
> - lvds_pll_feedback_div = 35;
>   lvds_control_2 = (3 << CH7017_LOOP_FILTER_SHIFT) |
>   (0 << CH7017_PHASE_DETECTOR_SHIFT);
>   if (1) { /* XXX: dual channel panel detection.  Assume yes for 
> now. */
> -- 
> 2.5.0

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 5/8] drm/i915: Check error return when converting pipe to connector

[Imre Deak]

An error from intel_get_pipe_from_connector() would mean a bug somewhere
else, but we still should check for it to prevent some other more
obscure bug later.

v2:
- Fall back to a reasonable default instead of bailing out in case of
  error. (Jani)

Cc: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_panel.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index cb50c52..3508f42 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -888,10 +888,14 @@ static void pch_enable_backlight(struct intel_connector 
*connector)
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
enum pipe pipe = intel_get_pipe_from_connector(connector);
-   enum transcoder cpu_transcoder =
-   intel_pipe_to_cpu_transcoder(dev_priv, pipe);
+   enum transcoder cpu_transcoder;
u32 cpu_ctl2, pch_ctl1, pch_ctl2;
 
+   if (!WARN_ON_ONCE(pipe == INVALID_PIPE))
+   cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv, pipe);
+   else
+   cpu_transcoder = TRANSCODER_EDP;
+
cpu_ctl2 = I915_READ(BLC_PWM_CPU_CTL2);
if (cpu_ctl2 & BLM_PWM_ENABLE) {
DRM_DEBUG_KMS("cpu backlight already enabled\n");
@@ -973,6 +977,9 @@ static void i965_enable_backlight(struct intel_connector 
*connector)
enum pipe pipe = intel_get_pipe_from_connector(connector);
u32 ctl, ctl2, freq;
 
+   if (WARN_ON_ONCE(pipe == INVALID_PIPE))
+   pipe = PIPE_A;
+
ctl2 = I915_READ(BLC_PWM_CTL2);
if (ctl2 & BLM_PWM_ENABLE) {
DRM_DEBUG_KMS("backlight already enabled\n");
@@ -1037,6 +1044,9 @@ static void bxt_enable_backlight(struct intel_connector 
*connector)
enum pipe pipe = intel_get_pipe_from_connector(connector);
u32 pwm_ctl, val;
 
+   if (WARN_ON_ONCE(pipe) == PIPE_INVALID)
+   pipe = PIPE_A;
+
/* Controller 1 uses the utility pin. */
if (panel->backlight.controller == 1) {
val = I915_READ(UTIL_PIN_CTL);
@@ -1093,7 +1103,8 @@ void intel_panel_enable_backlight(struct intel_connector 
*connector)
if (!panel->backlight.present)
return;
 
-   DRM_DEBUG_KMS("pipe %c\n", pipe_name(pipe));
+   if (!WARN_ON_ONCE(pipe == INVALID_PIPE))
+   DRM_DEBUG_KMS("pipe %c\n", pipe_name(pipe));
 
mutex_lock(_priv->backlight_lock);
 
-- 
2.5.0

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

[Intel-gfx] [PATCH v2 4/8] drm/i915: Check error return when setting DMA mask

[Imre Deak]

Even though an error from these functions isn't fatal we still want to
have a diagnostic message about it.

v2:
- Don't do assignments in if statements. (Jani)

Cc: Jani Nikula 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8bab4ae..0178c9e 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2741,13 +2741,17 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
struct pci_dev *pdev = dev_priv->drm.pdev;
unsigned int size;
u16 snb_gmch_ctl;
+   int err;
 
/* TODO: We're not aware of mappable constraints on gen8 yet */
ggtt->mappable_base = pci_resource_start(pdev, 2);
ggtt->mappable_end = pci_resource_len(pdev, 2);
 
-   if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(39)))
-   pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(39));
+   err = pci_set_dma_mask(pdev, DMA_BIT_MASK(39));
+   if (!err)
+   err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(39));
+   if (err)
+   DRM_ERROR("Can't set DMA mask/consistent mask (%d)\n", err);
 
pci_read_config_word(pdev, SNB_GMCH_CTRL, _gmch_ctl);
 
@@ -2790,6 +2794,7 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
struct pci_dev *pdev = dev_priv->drm.pdev;
unsigned int size;
u16 snb_gmch_ctl;
+   int err;
 
ggtt->mappable_base = pci_resource_start(pdev, 2);
ggtt->mappable_end = pci_resource_len(pdev, 2);
@@ -2802,8 +2807,11 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
return -ENXIO;
}
 
-   if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(40)))
-   pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(40));
+   err = pci_set_dma_mask(pdev, DMA_BIT_MASK(40));
+   if (!err)
+   err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(40));
+   if (err)
+   DRM_ERROR("Can't set DMA mask/consistent mask (%d)\n", err);
pci_read_config_word(pdev, SNB_GMCH_CTRL, _gmch_ctl);
 
ggtt->stolen_size = gen6_get_stolen_size(snb_gmch_ctl);
-- 
2.5.0

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

[Intel-gfx] [PATCH v2 3/8] drm/i915/sdvo: Check error return from intel_sdvo_get_value()

[Imre Deak]

The current code assumes that 'enhancements' won't change in case of an
error, but this isn't guaranteed. Fix things by treating any error as a
lack of the given capability.

v2:
- Remove the now redundant init of enhancements. (Ville)

Cc: Ville Syrjälä 
Signed-off-by: Imre Deak 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_sdvo.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index 816a6f5..496b24c 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -2892,11 +2892,10 @@ static bool intel_sdvo_create_enhance_property(struct 
intel_sdvo *intel_sdvo,
 
BUILD_BUG_ON(sizeof(enhancements) != 2);
 
-   enhancements.response = 0;
-   intel_sdvo_get_value(intel_sdvo,
-SDVO_CMD_GET_SUPPORTED_ENHANCEMENTS,
-, sizeof(enhancements));
-   if (enhancements.response == 0) {
+   if (!intel_sdvo_get_value(intel_sdvo,
+ SDVO_CMD_GET_SUPPORTED_ENHANCEMENTS,
+ , sizeof(enhancements)) ||
+   enhancements.response == 0) {
DRM_DEBUG_KMS("No enhancement is supported\n");
return true;
}
-- 
2.5.0

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

[Intel-gfx] [PATCH v2 7/8] drm/i915/lvds: Remove magic from PLL programming

[Imre Deak]

This looks like a left-over from enabling work. The spec defines
CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED as reserved set, so follow
this in the programming.

v2:
- Follow the spec to set CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED.
  (Ville)

Cc: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/dvo_ch7017.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/dvo_ch7017.c 
b/drivers/gpu/drm/i915/dvo_ch7017.c
index b3c7c19..80b3e16 100644
--- a/drivers/gpu/drm/i915/dvo_ch7017.c
+++ b/drivers/gpu/drm/i915/dvo_ch7017.c
@@ -280,10 +280,10 @@ static void ch7017_mode_set(struct intel_dvo_device *dvo,
(0 << CH7017_PHASE_DETECTOR_SHIFT);
} else {
outputs_enable = CH7017_LVDS_CHANNEL_A | 
CH7017_CHARGE_PUMP_HIGH;
-   lvds_pll_feedback_div = 
CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED |
+   lvds_pll_feedback_div =
+   CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED |
(2 << CH7017_LVDS_PLL_FEED_BACK_DIVIDER_SHIFT) |
(3 << CH7017_LVDS_PLL_FEED_FORWARD_DIVIDER_SHIFT);
-   lvds_pll_feedback_div = 35;
lvds_control_2 = (3 << CH7017_LOOP_FILTER_SHIFT) |
(0 << CH7017_PHASE_DETECTOR_SHIFT);
if (1) { /* XXX: dual channel panel detection.  Assume yes for 
now. */
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Pre-calculate engine context size

[Daniele Ceraolo Spurio]

On 26/04/17 02:57, Zhi Wang wrote:

Uh...sorry for not mentioning that before:), and stolen memory is not my
business. :(

Actually we root-caused it.

This is how we found this case:

The story is W driver directly allocated the ring buffer after the
context image, and the context image size in W driver is 19 pages. GVT-g
will do shadow context during submission, we copy 20 pages from guest
context image, so you can see, an extra page is copied here as the
context image size is actual 19 pages. The extra page belows to ring
buffer. When guest updates that page with new commands during GVT-g
executing the workload, the extra page ( which is ring buffer page) will
be over-written with old content, since GVT-g will copy the shadow
context (20 pages) back to guest at this time.

That's the full story. I send another email to Harsh. He should know if
the context image size of CHV is also 19 pages.

Thanks,
Zhi.



I did a quick check and according to the specs both the BDW and the CHV 
lrcs are formed by 18096 dwords plus the per-context HWSP, which 
converts to 19 pages for both platforms.


Regards,
Daniele


于 04/26/17 17:52, Joonas Lahtinen 写道:

On ke, 2017-04-26 at 17:10 +0800, Zhi Wang wrote:

Hi Joonas:
  Can you change GEN8_LR_CONTEXT_RENDER_SIZE = (19 * PAGE_SIZE)?
Then we don't need the hack in GVT-g. :P Actually it's 19 pages not
20 pages on BDW.

The exception is only made for BDW, not Gen8 overall. Has the change
been verified for CHV too?

Why hasn't a patch to fix above been sent for i915 in the past? Just
like in the stolen memory disabling case, bugs should be root caused
and then fixed, not just worked around quickly.

Regards, Joonas



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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: Don't allow 12 bpc when htotal is too big

[Ander Conselvan De Oliveira]

On Mon, 2017-04-24 at 11:22 +, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915/glk: Don't allow 12 bpc when htotal is too big
> URL   : https://patchwork.freedesktop.org/series/23451/
> State : success

Pushed, thanks for reviewing.

Ander

> 
> == Summary ==
> 
> Series 23451v1 drm/i915/glk: Don't allow 12 bpc when htotal is too big
> https://patchwork.freedesktop.org/api/1.0/series/23451/revisions/1/mbox/
> 
> Test gem_exec_flush:
> Subgroup basic-batch-kernel-default-uc:
> fail   -> PASS   (fi-snb-2600) fdo#17
> 
> fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
> time:429s
> fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
> time:430s
> fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
> time:576s
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time:506s
> fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
> time:564s
> fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
> time:490s
> fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:493s
> fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:415s
> fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
> time:410s
> fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
> time:425s
> fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:494s
> fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:464s
> fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:461s
> fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:562s
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:450s
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
> time:575s
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time:457s
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:497s
> fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
> time:429s
> fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
> time:529s
> fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
> time:398s
> 
> 9fb4b60bfa8c532ad6eda05af002c6b2f090d97f drm-tip: 2017y-04m-24d-09h-40m-53s 
> UTC integration manifest
> 7fa2f63 drm/i915/glk: Don't allow 12 bpc when htotal is too big
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4536/
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 8/8] drm: Remove redundant NULL check during atomic plane commit

[Ville Syrjälä]

On Wed, Apr 26, 2017 at 04:40:13PM +0300, Imre Deak wrote:
> plane_state can't be NULL anywhere in this function, so the NULL check
> at the end is redundant, remove it.
> 
> Cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/drm_plane_helper.c | 10 --
>  1 file changed, 4 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> b/drivers/gpu/drm/drm_plane_helper.c
> index 9854a50..2c27f6f 100644
> --- a/drivers/gpu/drm/drm_plane_helper.c
> +++ b/drivers/gpu/drm/drm_plane_helper.c
> @@ -511,12 +511,10 @@ int drm_plane_helper_commit(struct drm_plane *plane,
>   if (plane_funcs->cleanup_fb)
>   plane_funcs->cleanup_fb(plane, plane_state);
>  out:
> - if (plane_state) {
> - if (plane->funcs->atomic_destroy_state)
> - plane->funcs->atomic_destroy_state(plane, plane_state);
> - else
> - drm_atomic_helper_plane_destroy_state(plane, 
> plane_state);
> - }
> + if (plane->funcs->atomic_destroy_state)
> + plane->funcs->atomic_destroy_state(plane, plane_state);
> + else
> + drm_atomic_helper_plane_destroy_state(plane, plane_state);

Hmm. If plane->state was NULL, then we could swap that with plane_state,
and thus plane_state could become NULL. But that would actually oops in
drm_atomic_plane_disabling() already, so yeah, no way this could work.

My only concern is the buggy drm_atomic_helper_plane_reset() which can't
fail gracefully if the kmalloc fails. But failure that would probably
lead to explosions all over anyway.

Reviewed-by: Ville Syrjälä 


>  
>   return ret;
>  }
> -- 
> 2.5.0
> 
> ___
> 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

Re: [Intel-gfx] [PATCH 2/8] drm/i915/dp: Check error return during DPCD capability queries

[Ville Syrjälä]

On Wed, Apr 26, 2017 at 06:23:42PM +0300, Imre Deak wrote:
> On Wed, Apr 26, 2017 at 06:08:24PM +0300, Ville Syrjälä wrote:
> > On Wed, Apr 26, 2017 at 04:40:07PM +0300, Imre Deak wrote:
> > > The assumptions of these users of drm_dp_dpcd_readb() is that the passed
> > > in output buffer won't change in case of error, but this isn't
> > > guaranteed.
> > 
> > Hmm. We blindly copy as many bytes from the rxbuf into the user
> > provided buffer as the hardware told us to. 
> 
> Haven't checked this, but now looking at it doesn't the 
> 'bytes > recv_size' check in intel_dp_aux_ch() bound that?

Hmm. Right, so in the case of one byte read we will still copy the
actual data byte as well, if the hardware returned one. So it could
still clobber the byte we would like to preserve. I think.

> 
> > And whether the transfer
> > actually is considered a success or not depends on what the first
> > received byte says. I don't recall what the DP spec really says about
> > replying with more than one byte on failure, but I guess we shouldn't
> > depend on it anyway.
> > 
> > We could actually make that guarantee if we moved txbuf+rxbuf up
> > into drm_dp_dpcd_access() and did the copy to the user buffer
> > only on succes. But that would require changing all the DP
> > capable drivers at the same time, so would require someone
> > motivated enough.
> 
> Ok. I stopped at the ZR24w workaround in drm_dp_dpcd_read().. But that
> could also be used with a separate buffer. In any case I thought that
> even with the guarantee that the buffer doesn't change - which is in
> general a reasonable assumption - checking for the error return would
> be more robust.
> 
> > 
> > In the meantime
> > Reviewed-by: Ville Syrjälä 
> 
> Thanks.
> 
> > 
> > > Fix this by treating any error as the lack of the given
> > > capability.
> > > 
> > > In case of DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP an error would leave the
> > > buffer uninitialized even with the above assumption.
> > > 
> > > Signed-off-by: Imre Deak 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dp.c | 20 
> > >  1 file changed, 12 insertions(+), 8 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > > b/drivers/gpu/drm/i915/intel_dp.c
> > > index 08834f7..4a6feb6 100644
> > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > @@ -3088,7 +3088,8 @@ static bool intel_dp_get_y_cord_status(struct 
> > > intel_dp *intel_dp)
> > >  {
> > >   uint8_t psr_caps = 0;
> > >  
> > > - drm_dp_dpcd_readb(_dp->aux, DP_PSR_CAPS, _caps);
> > > + if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_CAPS, _caps) != 1)
> > > + return false;
> > >   return psr_caps & DP_PSR2_SU_Y_COORDINATE_REQUIRED;
> > >  }
> > >  
> > > @@ -3096,9 +3097,9 @@ static bool intel_dp_get_colorimetry_status(struct 
> > > intel_dp *intel_dp)
> > >  {
> > >   uint8_t dprx = 0;
> > >  
> > > - drm_dp_dpcd_readb(_dp->aux,
> > > - DP_DPRX_FEATURE_ENUMERATION_LIST,
> > > - );
> > > + if (drm_dp_dpcd_readb(_dp->aux, DP_DPRX_FEATURE_ENUMERATION_LIST,
> > > +   ) != 1)
> > > + return false;
> > >   return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
> > >  }
> > >  
> > > @@ -3106,7 +3107,9 @@ static bool intel_dp_get_alpm_status(struct 
> > > intel_dp *intel_dp)
> > >  {
> > >   uint8_t alpm_caps = 0;
> > >  
> > > - drm_dp_dpcd_readb(_dp->aux, DP_RECEIVER_ALPM_CAP, _caps);
> > > + if (drm_dp_dpcd_readb(_dp->aux, DP_RECEIVER_ALPM_CAP,
> > > +   _caps) != 1)
> > > + return false;
> > >   return alpm_caps & DP_ALPM_CAP;
> > >  }
> > >  
> > > @@ -3679,9 +3682,10 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > >   uint8_t frame_sync_cap;
> > >  
> > >   dev_priv->psr.sink_support = true;
> > > - drm_dp_dpcd_readb(_dp->aux,
> > > -   DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> > > -   _sync_cap);
> > > + if (drm_dp_dpcd_readb(_dp->aux,
> > > +   DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> > > +   _sync_cap) != 1)
> > > + frame_sync_cap = 0;
> > >   dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : false;
> > >   /* PSR2 needs frame sync as well */
> > >   dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
> > > -- 
> > > 2.5.0
> > > 
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > 
> > -- 
> > Ville Syrjälä
> > Intel OTC

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/8] drm/i915: Sanitize stolen memory size calculation

[Ville Syrjälä]

On Wed, Apr 26, 2017 at 04:40:11PM +0300, Imre Deak wrote:
> On GEN8+ (not counting CHV) the calculation can in theory result in an
> incorrect sign extension with all upper bits set. In practice this is
> unlikely to happen since it would require 4GB of stolen memory set
> aside. For consistency still prevent the sign extension explicitly
> everywhere.
> 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 13bf099..4b764b0 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2577,14 +2577,14 @@ static size_t gen6_get_stolen_size(u16 snb_gmch_ctl)
>  {
>   snb_gmch_ctl >>= SNB_GMCH_GMS_SHIFT;
>   snb_gmch_ctl &= SNB_GMCH_GMS_MASK;
> - return snb_gmch_ctl << 25; /* 32 MB units */
> + return (size_t)snb_gmch_ctl << 25; /* 32 MB units */

So the u16 gets promoted to int, which gets converted to size_t,
which may be larger than int, and thus things get sign extended.

Can't happen in the gen6 case actually due to SNB_GMCH_GMS_MASK being
small enough. But the gen8 case at least looks theoretically possible.
But having the case everywhere seems like the best way to avoid
someone copy-pasting the wrong thing when the next variant gets added.

Reviewed-by: Ville Syrjälä 

>  }
>  
>  static size_t gen8_get_stolen_size(u16 bdw_gmch_ctl)
>  {
>   bdw_gmch_ctl >>= BDW_GMCH_GMS_SHIFT;
>   bdw_gmch_ctl &= BDW_GMCH_GMS_MASK;
> - return bdw_gmch_ctl << 25; /* 32 MB units */
> + return (size_t)bdw_gmch_ctl << 25; /* 32 MB units */
>  }
>  
>  static size_t chv_get_stolen_size(u16 gmch_ctrl)
> @@ -2598,11 +2598,11 @@ static size_t chv_get_stolen_size(u16 gmch_ctrl)
>* 0x17 to 0x1d: 4MB increments start at 36MB
>*/
>   if (gmch_ctrl < 0x11)
> - return gmch_ctrl << 25;
> + return (size_t)gmch_ctrl << 25;
>   else if (gmch_ctrl < 0x17)
> - return (gmch_ctrl - 0x11 + 2) << 22;
> + return (size_t)(gmch_ctrl - 0x11 + 2) << 22;
>   else
> - return (gmch_ctrl - 0x17 + 9) << 22;
> + return (size_t)(gmch_ctrl - 0x17 + 9) << 22;
>  }
>  
>  static size_t gen9_get_stolen_size(u16 gen9_gmch_ctl)
> @@ -2611,10 +2611,10 @@ static size_t gen9_get_stolen_size(u16 gen9_gmch_ctl)
>   gen9_gmch_ctl &= BDW_GMCH_GMS_MASK;
>  
>   if (gen9_gmch_ctl < 0xf0)
> - return gen9_gmch_ctl << 25; /* 32 MB units */
> + return (size_t)gen9_gmch_ctl << 25; /* 32 MB units */
>   else
>   /* 4MB increments starting at 0xf0 for 4MB */
> - return (gen9_gmch_ctl - 0xf0 + 1) << 22;
> + return (size_t)(gen9_gmch_ctl - 0xf0 + 1) << 22;
>  }
>  
>  static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 size)
> -- 
> 2.5.0
> 
> ___
> 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

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Check error return when converting pipe to connector

[Imre Deak]

On Wed, Apr 26, 2017 at 05:53:52PM +0300, Jani Nikula wrote:
> On Wed, 26 Apr 2017, Imre Deak  wrote:
> > On Wed, Apr 26, 2017 at 05:12:32PM +0300, Jani Nikula wrote:
> >> On Wed, 26 Apr 2017, Imre Deak  wrote:
> >> > An error from intel_get_pipe_from_connector() would mean a bug somewhere
> >> > else, but we still should check for it to prevent some other more
> >> > obscure bug later.
> >> 
> >> Do check for invalid pipe, but please just limp on instead of bailing
> >> out of the functions. See notes inline.
> >> 
> >> BR,
> >> Jani.
> >> 
> >> >
> >> > Signed-off-by: Imre Deak 
> >> > ---
> >> >  drivers/gpu/drm/i915/intel_panel.c | 14 --
> >> >  1 file changed, 12 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> >> > b/drivers/gpu/drm/i915/intel_panel.c
> >> > index cb50c52..dbe05ec 100644
> >> > --- a/drivers/gpu/drm/i915/intel_panel.c
> >> > +++ b/drivers/gpu/drm/i915/intel_panel.c
> >> > @@ -888,10 +888,14 @@ static void pch_enable_backlight(struct 
> >> > intel_connector *connector)
> >> >  struct drm_i915_private *dev_priv = 
> >> > to_i915(connector->base.dev);
> >> >  struct intel_panel *panel = >panel;
> >> >  enum pipe pipe = intel_get_pipe_from_connector(connector);
> >> > -enum transcoder cpu_transcoder =
> >> > -intel_pipe_to_cpu_transcoder(dev_priv, pipe);
> >> > +enum transcoder cpu_transcoder;
> >> >  u32 cpu_ctl2, pch_ctl1, pch_ctl2;
> >> >  
> >> > +if (WARN_ON_ONCE(pipe == INVALID_PIPE))
> >> > +return;
> >> 
> >> Please just assign e.g. TRANSCODER_EDP to cpu_transcoder in this case,
> >> go on, and hope for the best. Do leave the warn in place though.
> >> 
> >> > +
> >> > +cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv, pipe);
> >> > +
> >> >  cpu_ctl2 = I915_READ(BLC_PWM_CPU_CTL2);
> >> >  if (cpu_ctl2 & BLM_PWM_ENABLE) {
> >> >  DRM_DEBUG_KMS("cpu backlight already enabled\n");
> >> > @@ -973,6 +977,9 @@ static void i965_enable_backlight(struct 
> >> > intel_connector *connector)
> >> >  enum pipe pipe = intel_get_pipe_from_connector(connector);
> >> >  u32 ctl, ctl2, freq;
> >> >  
> >> > +if (WARN_ON_ONCE(pipe == INVALID_PIPE))
> >> > +return;
> >> 
> >> Same here, please just assign e.g. PIPE_A here with the warning, and
> >> limp on.
> >> 
> >> > +
> >> >  ctl2 = I915_READ(BLC_PWM_CTL2);
> >> >  if (ctl2 & BLM_PWM_ENABLE) {
> >> >  DRM_DEBUG_KMS("backlight already enabled\n");
> >> > @@ -1093,6 +1100,9 @@ void intel_panel_enable_backlight(struct 
> >> > intel_connector *connector)
> >> >  if (!panel->backlight.present)
> >> >  return;
> >> >  
> >> > +if (WARN_ON_ONCE(pipe == INVALID_PIPE))
> >> > +return;
> >> 
> >> Here, pipe is only used for the debug logging, just skip that instead.
> >
> > Ok, can do. This would make things inconsistent wrt.
> > vlv_enable/disable_backlight() though, so are you ok if I change those
> > too accordingly?
> 
> Those are different in the sense that the *registers* are chosen based
> on the pipe, so it *must* be one of A or B. But in the paths changed
> here, pipe is only used for some bit fields of the registers being
> updated. IIRC they are not even crucial for fundamental operation of the
> backlight. So I don't want to bail out unless we really can't proceed.

Ok, will keep those as-is.

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

Re: [Intel-gfx] [PATCH 3/8] drm/i915/sdvo: Check error return from intel_sdvo_get_value()

[Imre Deak]

On Wed, Apr 26, 2017 at 06:12:09PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2017 at 04:40:08PM +0300, Imre Deak wrote:
> > The current code assumes that 'enhancements' won't change in case of an
> > error, but this isn't guaranteed. Fix things by treating any error as a
> > lack of the given capability.
> > 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/intel_sdvo.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> > b/drivers/gpu/drm/i915/intel_sdvo.c
> > index 816a6f5..0d1c511 100644
> > --- a/drivers/gpu/drm/i915/intel_sdvo.c
> > +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> > @@ -2893,10 +2893,10 @@ static bool 
> > intel_sdvo_create_enhance_property(struct intel_sdvo *intel_sdvo,
> > BUILD_BUG_ON(sizeof(enhancements) != 2);
> >  
> > enhancements.response = 0;
> 
> This initialization could be removed if we don't use the thing
> when the read fails.

Yep, missed this, will remove it.

> 
> Either way
> Reviewed-by: Ville Syrjälä 
> 
> > -   intel_sdvo_get_value(intel_sdvo,
> > -SDVO_CMD_GET_SUPPORTED_ENHANCEMENTS,
> > -, sizeof(enhancements));
> > -   if (enhancements.response == 0) {
> > +   if (!intel_sdvo_get_value(intel_sdvo,
> > + SDVO_CMD_GET_SUPPORTED_ENHANCEMENTS,
> > + , sizeof(enhancements)) ||
> > +   enhancements.response == 0) {
> > DRM_DEBUG_KMS("No enhancement is supported\n");
> > return true;
> > }
> > -- 
> > 2.5.0
> > 
> > ___
> > 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

Re: [Intel-gfx] [PATCH 2/8] drm/i915/dp: Check error return during DPCD capability queries

[Imre Deak]

On Wed, Apr 26, 2017 at 06:08:24PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2017 at 04:40:07PM +0300, Imre Deak wrote:
> > The assumptions of these users of drm_dp_dpcd_readb() is that the passed
> > in output buffer won't change in case of error, but this isn't
> > guaranteed.
> 
> Hmm. We blindly copy as many bytes from the rxbuf into the user
> provided buffer as the hardware told us to. 

Haven't checked this, but now looking at it doesn't the 
'bytes > recv_size' check in intel_dp_aux_ch() bound that?

> And whether the transfer
> actually is considered a success or not depends on what the first
> received byte says. I don't recall what the DP spec really says about
> replying with more than one byte on failure, but I guess we shouldn't
> depend on it anyway.
> 
> We could actually make that guarantee if we moved txbuf+rxbuf up
> into drm_dp_dpcd_access() and did the copy to the user buffer
> only on succes. But that would require changing all the DP
> capable drivers at the same time, so would require someone
> motivated enough.

Ok. I stopped at the ZR24w workaround in drm_dp_dpcd_read().. But that
could also be used with a separate buffer. In any case I thought that
even with the guarantee that the buffer doesn't change - which is in
general a reasonable assumption - checking for the error return would
be more robust.

> 
> In the meantime
> Reviewed-by: Ville Syrjälä 

Thanks.

> 
> > Fix this by treating any error as the lack of the given
> > capability.
> > 
> > In case of DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP an error would leave the
> > buffer uninitialized even with the above assumption.
> > 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c | 20 
> >  1 file changed, 12 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index 08834f7..4a6feb6 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3088,7 +3088,8 @@ static bool intel_dp_get_y_cord_status(struct 
> > intel_dp *intel_dp)
> >  {
> > uint8_t psr_caps = 0;
> >  
> > -   drm_dp_dpcd_readb(_dp->aux, DP_PSR_CAPS, _caps);
> > +   if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_CAPS, _caps) != 1)
> > +   return false;
> > return psr_caps & DP_PSR2_SU_Y_COORDINATE_REQUIRED;
> >  }
> >  
> > @@ -3096,9 +3097,9 @@ static bool intel_dp_get_colorimetry_status(struct 
> > intel_dp *intel_dp)
> >  {
> > uint8_t dprx = 0;
> >  
> > -   drm_dp_dpcd_readb(_dp->aux,
> > -   DP_DPRX_FEATURE_ENUMERATION_LIST,
> > -   );
> > +   if (drm_dp_dpcd_readb(_dp->aux, DP_DPRX_FEATURE_ENUMERATION_LIST,
> > + ) != 1)
> > +   return false;
> > return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
> >  }
> >  
> > @@ -3106,7 +3107,9 @@ static bool intel_dp_get_alpm_status(struct intel_dp 
> > *intel_dp)
> >  {
> > uint8_t alpm_caps = 0;
> >  
> > -   drm_dp_dpcd_readb(_dp->aux, DP_RECEIVER_ALPM_CAP, _caps);
> > +   if (drm_dp_dpcd_readb(_dp->aux, DP_RECEIVER_ALPM_CAP,
> > + _caps) != 1)
> > +   return false;
> > return alpm_caps & DP_ALPM_CAP;
> >  }
> >  
> > @@ -3679,9 +3682,10 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
> > uint8_t frame_sync_cap;
> >  
> > dev_priv->psr.sink_support = true;
> > -   drm_dp_dpcd_readb(_dp->aux,
> > - DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> > - _sync_cap);
> > +   if (drm_dp_dpcd_readb(_dp->aux,
> > + DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> > + _sync_cap) != 1)
> > +   frame_sync_cap = 0;
> > dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : false;
> > /* PSR2 needs frame sync as well */
> > dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
> > -- 
> > 2.5.0
> > 
> > ___
> > 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

Re: [Intel-gfx] [PATCH 3/8] drm/i915/sdvo: Check error return from intel_sdvo_get_value()

[Ville Syrjälä]

On Wed, Apr 26, 2017 at 04:40:08PM +0300, Imre Deak wrote:
> The current code assumes that 'enhancements' won't change in case of an
> error, but this isn't guaranteed. Fix things by treating any error as a
> lack of the given capability.
> 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_sdvo.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
> b/drivers/gpu/drm/i915/intel_sdvo.c
> index 816a6f5..0d1c511 100644
> --- a/drivers/gpu/drm/i915/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> @@ -2893,10 +2893,10 @@ static bool intel_sdvo_create_enhance_property(struct 
> intel_sdvo *intel_sdvo,
>   BUILD_BUG_ON(sizeof(enhancements) != 2);
>  
>   enhancements.response = 0;

This initialization could be removed if we don't use the thing
when the read fails.

Either way
Reviewed-by: Ville Syrjälä 

> - intel_sdvo_get_value(intel_sdvo,
> -  SDVO_CMD_GET_SUPPORTED_ENHANCEMENTS,
> -  , sizeof(enhancements));
> - if (enhancements.response == 0) {
> + if (!intel_sdvo_get_value(intel_sdvo,
> +   SDVO_CMD_GET_SUPPORTED_ENHANCEMENTS,
> +   , sizeof(enhancements)) ||
> + enhancements.response == 0) {
>   DRM_DEBUG_KMS("No enhancement is supported\n");
>   return true;
>   }
> -- 
> 2.5.0
> 
> ___
> 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

Re: [Intel-gfx] [PATCH 2/8] drm/i915/dp: Check error return during DPCD capability queries

[Ville Syrjälä]

On Wed, Apr 26, 2017 at 04:40:07PM +0300, Imre Deak wrote:
> The assumptions of these users of drm_dp_dpcd_readb() is that the passed
> in output buffer won't change in case of error, but this isn't
> guaranteed.

Hmm. We blindly copy as many bytes from the rxbuf into the user
provided buffer as the hardware told us to. And whether the transfer
actually is considered a success or not depends on what the first
received byte says. I don't recall what the DP spec really says about
replying with more than one byte on failure, but I guess we shouldn't
depend on it anyway.

We could actually make that guarantee if we moved txbuf+rxbuf up
into drm_dp_dpcd_access() and did the copy to the user buffer
only on succes. But that would require changing all the DP
capable drivers at the same time, so would require someone
motivated enough.

In the meantime
Reviewed-by: Ville Syrjälä 

> Fix this by treating any error as the lack of the given
> capability.
> 
> In case of DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP an error would leave the
> buffer uninitialized even with the above assumption.
> 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_dp.c | 20 
>  1 file changed, 12 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 08834f7..4a6feb6 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3088,7 +3088,8 @@ static bool intel_dp_get_y_cord_status(struct intel_dp 
> *intel_dp)
>  {
>   uint8_t psr_caps = 0;
>  
> - drm_dp_dpcd_readb(_dp->aux, DP_PSR_CAPS, _caps);
> + if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_CAPS, _caps) != 1)
> + return false;
>   return psr_caps & DP_PSR2_SU_Y_COORDINATE_REQUIRED;
>  }
>  
> @@ -3096,9 +3097,9 @@ static bool intel_dp_get_colorimetry_status(struct 
> intel_dp *intel_dp)
>  {
>   uint8_t dprx = 0;
>  
> - drm_dp_dpcd_readb(_dp->aux,
> - DP_DPRX_FEATURE_ENUMERATION_LIST,
> - );
> + if (drm_dp_dpcd_readb(_dp->aux, DP_DPRX_FEATURE_ENUMERATION_LIST,
> +   ) != 1)
> + return false;
>   return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
>  }
>  
> @@ -3106,7 +3107,9 @@ static bool intel_dp_get_alpm_status(struct intel_dp 
> *intel_dp)
>  {
>   uint8_t alpm_caps = 0;
>  
> - drm_dp_dpcd_readb(_dp->aux, DP_RECEIVER_ALPM_CAP, _caps);
> + if (drm_dp_dpcd_readb(_dp->aux, DP_RECEIVER_ALPM_CAP,
> +   _caps) != 1)
> + return false;
>   return alpm_caps & DP_ALPM_CAP;
>  }
>  
> @@ -3679,9 +3682,10 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
>   uint8_t frame_sync_cap;
>  
>   dev_priv->psr.sink_support = true;
> - drm_dp_dpcd_readb(_dp->aux,
> -   DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> -   _sync_cap);
> + if (drm_dp_dpcd_readb(_dp->aux,
> +   DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> +   _sync_cap) != 1)
> + frame_sync_cap = 0;
>   dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : false;
>   /* PSR2 needs frame sync as well */
>   dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
> -- 
> 2.5.0
> 
> ___
> 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

Re: [Intel-gfx] [PATCH 7/8] drm/i915/lvds: Remove magic from PLL programming

[Imre Deak]

On Wed, Apr 26, 2017 at 05:50:06PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2017 at 04:40:12PM +0300, Imre Deak wrote:
> > This looks like a left-over from enabling work. I don't have the
> > specification to check whether we have to set
> > CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED, for now just keep things
> > as-is, removing the magic so that static checkers don't complain.
> 
> The spec does list the top two bits as reserved with the default value
> of 10b. I don't see any mention of how reserved bits should be handled
> though. But I think I'd just change it to set them to the default value.

Ok, can change that based on the above.

--Imre

> 
> The whole thing just looks like an oversight in the original ddx commit,
> whose commit message isn't all that helpful:
> 
> commit 04e936935f0b0045600241424f1d04a6721a2432
> Author: Eric Anholt 
> Date:   Mon Oct 1 17:29:35 2007 -0700
> 
> Bring the CH7017 driver closer to spec.
> 
> This is also closer to what my hardware is programmed with, except for 
> some
> very confusing off-by-one bugs in an unexpected direction.
> 
> > 
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/dvo_ch7017.c | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/dvo_ch7017.c 
> > b/drivers/gpu/drm/i915/dvo_ch7017.c
> > index b3c7c19..c0712a5 100644
> > --- a/drivers/gpu/drm/i915/dvo_ch7017.c
> > +++ b/drivers/gpu/drm/i915/dvo_ch7017.c
> > @@ -280,10 +280,13 @@ static void ch7017_mode_set(struct intel_dvo_device 
> > *dvo,
> > (0 << CH7017_PHASE_DETECTOR_SHIFT);
> > } else {
> > outputs_enable = CH7017_LVDS_CHANNEL_A | 
> > CH7017_CHARGE_PUMP_HIGH;
> > -   lvds_pll_feedback_div = 
> > CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED |
> > +   /*
> > +* FIXME: Check if CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED
> > +* needs to be also set for the following.
> > +*/
> > +   lvds_pll_feedback_div =
> > (2 << CH7017_LVDS_PLL_FEED_BACK_DIVIDER_SHIFT) |
> > (3 << CH7017_LVDS_PLL_FEED_FORWARD_DIVIDER_SHIFT);
> > -   lvds_pll_feedback_div = 35;
> > lvds_control_2 = (3 << CH7017_LOOP_FILTER_SHIFT) |
> > (0 << CH7017_PHASE_DETECTOR_SHIFT);
> > if (1) { /* XXX: dual channel panel detection.  Assume yes for 
> > now. */
> > -- 
> > 2.5.0
> > 
> > ___
> > 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] drm/i915: Update MOCS settings for gen 9

[David Weinehall]

Add a bunch of MOCS entries for gen 9 that were missing from intel_mocs.
Some of these are used by media-sdk; if these entries are missing
the default will instead be to do everything uncached.

This patch improves media-sdk performance with up to 60%
with the (admittedly synthetic) benchmarks we use in our nightly
testing, without regressing any other benchmarks.

Signed-off-by: David Weinehall 

diff --git a/drivers/gpu/drm/i915/intel_mocs.c 
b/drivers/gpu/drm/i915/intel_mocs.c
index 92e461c68385..5236a442a14f 100644
--- a/drivers/gpu/drm/i915/intel_mocs.c
+++ b/drivers/gpu/drm/i915/intel_mocs.c
@@ -103,7 +103,6 @@ static const struct drm_i915_mocs_entry 
skylake_mocs_table[] = {
   LE_TGT_CACHE(LE_TC_LLC_ELLC) |
   LE_LRUM(0) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
   LE_PFM(0) | LE_SCF(0),
-
  /* 0x0010 */
  .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
},
@@ -123,7 +122,133 @@ static const struct drm_i915_mocs_entry 
skylake_mocs_table[] = {
   LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
   LE_PFM(0) | LE_SCF(0),
  /* 0x0030 */
- .l3cc_value =   L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+   },
+   {
+ /* 0x0037 */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0),
+ /* 0x0030 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+   },
+   {
+ /* 0x0039 */
+ .control_value = LE_CACHEABILITY(LE_UC) |
+  LE_TGT_CACHE(LE_TC_LLC_ELLC) |
+  LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0),
+ /* 0x0030 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+   },
+   {
+ /* 0x0033 */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+  LE_TGT_CACHE(LE_TC_PAGETABLE) |
+  LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0),
+ /* 0x0030 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+   },
+   {
+ /* 0x0017 */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(1) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0),
+ /* 0x0030 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_WB),
+   },
+   {
+ /* 0x0037 */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0),
+ /* 0x0010 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+   },
+   {
+ /* 0x0039 */
+ .control_value = LE_CACHEABILITY(LE_UC) |
+  LE_TGT_CACHE(LE_TC_LLC_ELLC) |
+  LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0),
+ /* 0x0010 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+   },
+   {
+ /* 0x0017 */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+  LE_TGT_CACHE(LE_TC_LLC) |
+  LE_LRUM(1) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0),
+ /* 0x0010 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+   },
+   {
+ /* 0x003b */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+  LE_TGT_CACHE(LE_TC_LLC_ELLC) |
+  LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0),
+ /* 0x0010 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+   },
+   {
+ /* 0x0033 */
+ .control_value = LE_CACHEABILITY(LE_WB) |
+  LE_TGT_CACHE(LE_TC_PAGETABLE) |
+  LE_LRUM(3) | LE_AOM(0) | LE_RSC(0) | LE_SCC(0) |
+  LE_PFM(0) | LE_SCF(0),
+ /* 0x0010 */
+ .l3cc_value =L3_ESC(0) | L3_SCC(0) | L3_CACHEABILITY(L3_UC),
+   },
+   {
+ /* 0x0019 */
+ .control_value = LE_CACHEABILITY(LE_UC) |
+  LE_TGT_CACHE(LE_TC_LLC_ELLC) |
+   

Re: [Intel-gfx] [PATCH 07/27] drm/i915: Squash repeated awaits on the same fence

[Chris Wilson]

On Wed, Apr 26, 2017 at 03:36:19PM +0100, Tvrtko Ursulin wrote:
> But yes, sounds easy to do it from the idle worker. Just walk
> everything and prune when engine seqno has advanced past it?

Hmm. I was thinking that sounded like a great idea and then realised we
are storing context.seqno not global_seqno. :|

But... Yes, from idle we know that the fences are completed and so if we
should have a request for an old sync point, it will be ignored anyway
because the fence is completed. So we can just throw away the ht
entirely at that point with no loss of optimisations.

Ok, I see what you were trying to tell me about i915_fence_release now.
The problem with handling at fence_release is doing the reverse map to
all contexts using it.

Thanks,
-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 07/27] drm/i915: Squash repeated awaits on the same fence

[Chris Wilson]

On Wed, Apr 26, 2017 at 03:36:19PM +0100, Tvrtko Ursulin wrote:
> 
> On 26/04/2017 13:23, Chris Wilson wrote:
> >Too early, it's the timeline (and syncs along it) that's interesting.
> >For our contexts, we can hook into context-close, but we still have some
> >foreign dma-fence-contexts to worry about. I was thinking of walking all
> >timelines from the idle_worker. And possibly forcibly prune across
> >suspend.
> 
> Hm I don't see why it is too early. If request is getting freed,
> there is no one waiting on it any longer, so how can it be OK to
> keep that seqno in the map?

The fence->seqno represents a known synchronisation point from our timeline to 
the
fence->timeline. In the future, we know that we can skip all
synchronisations onto that timeline that are older than the fence->seqno
because we already have synchronised. That coupling persists after the
fence itself is destroyed. It is why tracking it between timelines is
more effective than just squashing repeats within a request.

(This is perhaps more significant when we expend ring space to emit GPU
commands for each sync point, i.e. hw semaphores.)
-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/8] drm/i915/vlv: Fix port B PLL opamp initialization

[Ville Syrjälä]

On Wed, Apr 26, 2017 at 04:40:06PM +0300, Imre Deak wrote:
> The current code looks like a typo, the specification calls for setting
> bits 31:24 to 0x8C, while preserving bits 23:0. Fix things accordingly.

Yeah, as we checked there were a couple of things in the low 24 bits
with non-zero default values.

Reviewed-by: Ville Syrjälä 

> 
> I'm not aware of the typo causing a real problem, so the fix is only for
> consistency.
> 
> Cc: Ville Syrjälä 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 85b9e2f5..19a7a1e 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6369,8 +6369,8 @@ static void vlv_pllb_recal_opamp(struct 
> drm_i915_private *dev_priv, enum pipe
>   vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW9(1), reg_val);
>  
>   reg_val = vlv_dpio_read(dev_priv, pipe, VLV_REF_DW13);
> - reg_val &= 0x8cff;
> - reg_val = 0x8c00;
> + reg_val &= 0x00ff;
> + reg_val |= 0x8c00;
>   vlv_dpio_write(dev_priv, pipe, VLV_REF_DW13, reg_val);
>  
>   reg_val = vlv_dpio_read(dev_priv, pipe, VLV_PLL_DW9(1));
> -- 
> 2.5.0

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Check error return when converting pipe to connector

[Jani Nikula]

On Wed, 26 Apr 2017, Imre Deak  wrote:
> On Wed, Apr 26, 2017 at 05:12:32PM +0300, Jani Nikula wrote:
>> On Wed, 26 Apr 2017, Imre Deak  wrote:
>> > An error from intel_get_pipe_from_connector() would mean a bug somewhere
>> > else, but we still should check for it to prevent some other more
>> > obscure bug later.
>> 
>> Do check for invalid pipe, but please just limp on instead of bailing
>> out of the functions. See notes inline.
>> 
>> BR,
>> Jani.
>> 
>> >
>> > Signed-off-by: Imre Deak 
>> > ---
>> >  drivers/gpu/drm/i915/intel_panel.c | 14 --
>> >  1 file changed, 12 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/intel_panel.c 
>> > b/drivers/gpu/drm/i915/intel_panel.c
>> > index cb50c52..dbe05ec 100644
>> > --- a/drivers/gpu/drm/i915/intel_panel.c
>> > +++ b/drivers/gpu/drm/i915/intel_panel.c
>> > @@ -888,10 +888,14 @@ static void pch_enable_backlight(struct 
>> > intel_connector *connector)
>> >struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>> >struct intel_panel *panel = >panel;
>> >enum pipe pipe = intel_get_pipe_from_connector(connector);
>> > -  enum transcoder cpu_transcoder =
>> > -  intel_pipe_to_cpu_transcoder(dev_priv, pipe);
>> > +  enum transcoder cpu_transcoder;
>> >u32 cpu_ctl2, pch_ctl1, pch_ctl2;
>> >  
>> > +  if (WARN_ON_ONCE(pipe == INVALID_PIPE))
>> > +  return;
>> 
>> Please just assign e.g. TRANSCODER_EDP to cpu_transcoder in this case,
>> go on, and hope for the best. Do leave the warn in place though.
>> 
>> > +
>> > +  cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv, pipe);
>> > +
>> >cpu_ctl2 = I915_READ(BLC_PWM_CPU_CTL2);
>> >if (cpu_ctl2 & BLM_PWM_ENABLE) {
>> >DRM_DEBUG_KMS("cpu backlight already enabled\n");
>> > @@ -973,6 +977,9 @@ static void i965_enable_backlight(struct 
>> > intel_connector *connector)
>> >enum pipe pipe = intel_get_pipe_from_connector(connector);
>> >u32 ctl, ctl2, freq;
>> >  
>> > +  if (WARN_ON_ONCE(pipe == INVALID_PIPE))
>> > +  return;
>> 
>> Same here, please just assign e.g. PIPE_A here with the warning, and
>> limp on.
>> 
>> > +
>> >ctl2 = I915_READ(BLC_PWM_CTL2);
>> >if (ctl2 & BLM_PWM_ENABLE) {
>> >DRM_DEBUG_KMS("backlight already enabled\n");
>> > @@ -1093,6 +1100,9 @@ void intel_panel_enable_backlight(struct 
>> > intel_connector *connector)
>> >if (!panel->backlight.present)
>> >return;
>> >  
>> > +  if (WARN_ON_ONCE(pipe == INVALID_PIPE))
>> > +  return;
>> 
>> Here, pipe is only used for the debug logging, just skip that instead.
>
> Ok, can do. This would make things inconsistent wrt.
> vlv_enable/disable_backlight() though, so are you ok if I change those
> too accordingly?

Those are different in the sense that the *registers* are chosen based
on the pipe, so it *must* be one of A or B. But in the paths changed
here, pipe is only used for some bit fields of the registers being
updated. IIRC they are not even crucial for fundamental operation of the
backlight. So I don't want to bail out unless we really can't proceed.

BR,
Jani.


>
> --Imre
>
>> 
>> > +
>> >DRM_DEBUG_KMS("pipe %c\n", pipe_name(pipe));
>> >  
>> >mutex_lock(_priv->backlight_lock);
>> 
>> -- 
>> Jani Nikula, Intel Open Source Technology Center

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

Re: [Intel-gfx] [PATCH 0/7] Add Y-tiling support into IGTs

[Paulo Zanoni]

Em Qua, 2017-04-26 às 10:46 -0300, Paulo Zanoni escreveu:
> Em Sáb, 2017-03-18 às 00:45 +0530, Praveen Paneri escreveu:
> > 
> > This series adds Y-tiled buffer creation support into IGT libraries
> > and
> > goes on to use this capability to add support into FBC tests to use
> > Y-tiled buffers.
> 
> I applied this series and the Kernel patch. If I try to run
> kms_draw_crc it just gets stuck eating 100% of the CPU. I suppose
> this
> needs to be debugged, maybe some patch is wrong. Can you reproduce
> this
> behavior?

Just as a note, I tested on SKL. Maybe that's relevant.

> 
> > 
> > 
> > Akash Goel (1):
> >   lib/igt_draw: Add Y-tiling support for IGT_DRAW_BLT method
> > 
> > Paulo Zanoni (1):
> >   tests/kms_draw_crc: add support for Y tiling
> > 
> > Praveen Paneri (5):
> >   lib/igt_fb: Let others use igt_get_fb_tile_size
> >   lib/igt_fb: Add helper function for tile_to_mod
> >   lib/igt_draw: Add Y-tiling support
> >   igt/kms_frontbuffer_tracking: Add Y-tiling support
> >   igt/kms_fbc_crc.c : Add Y-tile tests
> > 
> >  lib/igt_draw.c   | 167
> > -
> > --
> >  lib/igt_fb.c |  29 ++-
> >  lib/igt_fb.h |   4 +-
> >  tests/kms_draw_crc.c |  58 ++
> >  tests/kms_fbc_crc.c  |  71 +
> >  tests/kms_frontbuffer_tracking.c |  46 ++-
> >  6 files changed, 262 insertions(+), 113 deletions(-)
> > 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 7/8] drm/i915/lvds: Remove magic from PLL programming

[Ville Syrjälä]

On Wed, Apr 26, 2017 at 04:40:12PM +0300, Imre Deak wrote:
> This looks like a left-over from enabling work. I don't have the
> specification to check whether we have to set
> CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED, for now just keep things
> as-is, removing the magic so that static checkers don't complain.

The spec does list the top two bits as reserved with the default value
of 10b. I don't see any mention of how reserved bits should be handled
though. But I think I'd just change it to set them to the default value.

The whole thing just looks like an oversight in the original ddx commit,
whose commit message isn't all that helpful:

commit 04e936935f0b0045600241424f1d04a6721a2432
Author: Eric Anholt 
Date:   Mon Oct 1 17:29:35 2007 -0700

Bring the CH7017 driver closer to spec.

This is also closer to what my hardware is programmed with, except for some
very confusing off-by-one bugs in an unexpected direction.

> 
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/dvo_ch7017.c | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/dvo_ch7017.c 
> b/drivers/gpu/drm/i915/dvo_ch7017.c
> index b3c7c19..c0712a5 100644
> --- a/drivers/gpu/drm/i915/dvo_ch7017.c
> +++ b/drivers/gpu/drm/i915/dvo_ch7017.c
> @@ -280,10 +280,13 @@ static void ch7017_mode_set(struct intel_dvo_device 
> *dvo,
>   (0 << CH7017_PHASE_DETECTOR_SHIFT);
>   } else {
>   outputs_enable = CH7017_LVDS_CHANNEL_A | 
> CH7017_CHARGE_PUMP_HIGH;
> - lvds_pll_feedback_div = 
> CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED |
> + /*
> +  * FIXME: Check if CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED
> +  * needs to be also set for the following.
> +  */
> + lvds_pll_feedback_div =
>   (2 << CH7017_LVDS_PLL_FEED_BACK_DIVIDER_SHIFT) |
>   (3 << CH7017_LVDS_PLL_FEED_FORWARD_DIVIDER_SHIFT);
> - lvds_pll_feedback_div = 35;
>   lvds_control_2 = (3 << CH7017_LOOP_FILTER_SHIFT) |
>   (0 << CH7017_PHASE_DETECTOR_SHIFT);
>   if (1) { /* XXX: dual channel panel detection.  Assume yes for 
> now. */
> -- 
> 2.5.0
> 
> ___
> 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] ✓ Fi.CI.BAT: success for drm: Fix/remove a few static checker error

[Patchwork]

== Series Details ==

Series: drm: Fix/remove a few static checker error
URL   : https://patchwork.freedesktop.org/series/23571/
State : success

== Summary ==

Series 23571v1 drm: Fix/remove a few static checker error
https://patchwork.freedesktop.org/api/1.0/series/23571/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:433s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:432s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:579s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:514s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:549s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:484s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:488s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:413s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:406s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:416s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:488s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:464s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:456s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:574s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:449s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:568s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:463s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:490s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:429s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:405s

9f955adc7ed1bbf9ada7dab63f39336a56ff1985 drm-tip: 2017y-04m-26d-13h-38m-52s UTC 
integration manifest
7ae111c drm: Remove redundant NULL check during atomic plane commit
c741171 drm/i915/lvds: Remove magic from PLL programming
a093053 drm/i915: Sanitize stolen memory size calculation
50f6722 drm/i915: Check error return when converting pipe to connector
96ec98c drm/i915: Check error return when setting DMA mask
0ff3bb1 drm/i915/sdvo: Check error return from intel_sdvo_get_value()
9a1b175 drm/i915/dp: Check error return during DPCD capability queries
cfccd23 drm/i915/vlv: Fix port B PLL opamp initialization

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4557/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/27] drm/i915: Squash repeated awaits on the same fence

[Tvrtko Ursulin]

On 26/04/2017 13:23, Chris Wilson wrote:

On Wed, Apr 26, 2017 at 01:13:41PM +0100, Tvrtko Ursulin wrote:


On 26/04/2017 12:18, Chris Wilson wrote:

On Wed, Apr 26, 2017 at 11:54:08AM +0100, Tvrtko Ursulin wrote:

+/* struct intel_timeline_sync is a layer of a radixtree that maps a u64 fence
+ * context id to the last u32 fence seqno waited upon from that context.
+ * Unlike lib/radixtree it uses a parent pointer that allows traversal back to
+ * the root. This allows us to access the whole tree via a single pointer
+ * to the most recently used layer. We expect fence contexts to be dense
+ * and most reuse to be on the same i915_gem_context but on neighbouring
+ * engines (i.e. on adjacent contexts) and reuse the same leaf, a very
+ * effective lookup cache. If the new lookup is not on the same leaf, we
+ * expect it to be on the neighbouring branch.
+ *
+ * A leaf holds an array of u32 seqno, and has height 0. The bitmap field
+ * allows us to store whether a particular seqno is valid (i.e. allows us
+ * to distinguish unset from 0).
+ *
+ * A branch holds an array of layer pointers, and has height > 0, and always
+ * has at least 2 layers (either branches or leaves) below it.
+ *
+ */


@_@ :)

Ok, so a map of u64 to u32. We can't use IDR or radixtree directly
because of u64 keys. :( How about a hash table? It would be much
simpler to review. :) Seriously, if it would perform close enough it
would be a much much simpler implementation.


You want a resizable hashtable. rht is appallingly slow, so you want a
custom resizeable ht. They are not as simple as this codewise ;)
(Plus a compressed radixtree is part of my plan for scalability
improvements for struct reservation_object.)


Why resizable? I was thinking a normal one. If at any given time we
have an active set of contexts, or at least lookups are as you say
below, to neighbouring contexts, that would mean we are talking
about lookups to different hash buckets.  And for the typical
working set we would expect many collisions so longer lists in each
bucket? So maybe NUM_ENGINES * some typical load constant number
buckets would not be that bad?


Consider a long running display server that will accumulate 10,000s of
thousands of clients in its lifetime, each with their own contents that
get shared by passing around fences/framebuffers. (Or on a shorter scale
any of the context stress tests in igt.) Due to the non-recycling of the
context ids, we can grow to very large tables - but we have no knowledge
of what contexts are no longer required.

To compensate we need to occasionally prune the sync points. For a ht we
could just scrap it, For an idr, we could store last use and delete
stale leaves.


Hm, pruning yes.. but you don't have pruning in this patch either.
So that's something which needs to be addressed either way.


I know, review is great for hindsight. The iterator/remove for the
compressed idr is going to be on the uglier side of the insertion. Ugly
enough to be a seperate patch.


But first we have a question of how many buckets do we give the static
ht? Most processes will be sharing between 2 contexts (render context,
presentation context) except for a display server who may have 10-100 of
clients - and possibly where eliminating repeated syncs is going to be
most valuable. That suggests 256 buckets for every timeline (assuming
just a pair of engines across shared contexts). Overkill for the
majority, and going to be miserable in stress tests.

Finally what do you store in the ht? Fences are the obvious candidate,
but need reaping. Or you just create a ht for the request and only
squash repeated fences inside a single request - that doesn't benefit

>from timeline tracking and squashing between requests (but does avoid

keeping fences around forever). Hence why I went with tracking seqno. To
avoid allocations for the ht nodes, we could create an open-addressed ht
with the {context, seqno} embedded in it. It would be efficient, but
needs online resizing and is a fair chunk of new code.


I was thinking of exactly the same thing as this patch does, u64
context id as key, u32 seqnos (wrapped in a container with
hlist_node).


Hmm, a hashed radixtree. I did read something about a hybrid approach.


Ok, so the key is pruning to keep the display server scenario in check.

Free the key from i915_fence_release?


Too early, it's the timeline (and syncs along it) that's interesting.
For our contexts, we can hook into context-close, but we still have some
foreign dma-fence-contexts to worry about. I was thinking of walking all
timelines from the idle_worker. And possibly forcibly prune across
suspend.


Hm I don't see why it is too early. If request is getting freed, there 
is no one waiting on it any longer, so how can it be OK to keep that 
seqno in the map?


But yes, sounds easy to do it from the idle worker. Just walk everything 
and prune when engine seqno has advanced past it?


Regards,

Tvrtko

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Check error return when converting pipe to connector

[Imre Deak]

On Wed, Apr 26, 2017 at 05:12:32PM +0300, Jani Nikula wrote:
> On Wed, 26 Apr 2017, Imre Deak  wrote:
> > An error from intel_get_pipe_from_connector() would mean a bug somewhere
> > else, but we still should check for it to prevent some other more
> > obscure bug later.
> 
> Do check for invalid pipe, but please just limp on instead of bailing
> out of the functions. See notes inline.
> 
> BR,
> Jani.
> 
> >
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/i915/intel_panel.c | 14 --
> >  1 file changed, 12 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> > b/drivers/gpu/drm/i915/intel_panel.c
> > index cb50c52..dbe05ec 100644
> > --- a/drivers/gpu/drm/i915/intel_panel.c
> > +++ b/drivers/gpu/drm/i915/intel_panel.c
> > @@ -888,10 +888,14 @@ static void pch_enable_backlight(struct 
> > intel_connector *connector)
> > struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> > struct intel_panel *panel = >panel;
> > enum pipe pipe = intel_get_pipe_from_connector(connector);
> > -   enum transcoder cpu_transcoder =
> > -   intel_pipe_to_cpu_transcoder(dev_priv, pipe);
> > +   enum transcoder cpu_transcoder;
> > u32 cpu_ctl2, pch_ctl1, pch_ctl2;
> >  
> > +   if (WARN_ON_ONCE(pipe == INVALID_PIPE))
> > +   return;
> 
> Please just assign e.g. TRANSCODER_EDP to cpu_transcoder in this case,
> go on, and hope for the best. Do leave the warn in place though.
> 
> > +
> > +   cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv, pipe);
> > +
> > cpu_ctl2 = I915_READ(BLC_PWM_CPU_CTL2);
> > if (cpu_ctl2 & BLM_PWM_ENABLE) {
> > DRM_DEBUG_KMS("cpu backlight already enabled\n");
> > @@ -973,6 +977,9 @@ static void i965_enable_backlight(struct 
> > intel_connector *connector)
> > enum pipe pipe = intel_get_pipe_from_connector(connector);
> > u32 ctl, ctl2, freq;
> >  
> > +   if (WARN_ON_ONCE(pipe == INVALID_PIPE))
> > +   return;
> 
> Same here, please just assign e.g. PIPE_A here with the warning, and
> limp on.
> 
> > +
> > ctl2 = I915_READ(BLC_PWM_CTL2);
> > if (ctl2 & BLM_PWM_ENABLE) {
> > DRM_DEBUG_KMS("backlight already enabled\n");
> > @@ -1093,6 +1100,9 @@ void intel_panel_enable_backlight(struct 
> > intel_connector *connector)
> > if (!panel->backlight.present)
> > return;
> >  
> > +   if (WARN_ON_ONCE(pipe == INVALID_PIPE))
> > +   return;
> 
> Here, pipe is only used for the debug logging, just skip that instead.

Ok, can do. This would make things inconsistent wrt.
vlv_enable/disable_backlight() though, so are you ok if I change those
too accordingly?

--Imre

> 
> > +
> > DRM_DEBUG_KMS("pipe %c\n", pipe_name(pipe));
> >  
> > mutex_lock(_priv->backlight_lock);
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 5/8] drm/i915: Check error return when converting pipe to connector

[Jani Nikula]

On Wed, 26 Apr 2017, Imre Deak  wrote:
> An error from intel_get_pipe_from_connector() would mean a bug somewhere
> else, but we still should check for it to prevent some other more
> obscure bug later.

Do check for invalid pipe, but please just limp on instead of bailing
out of the functions. See notes inline.

BR,
Jani.

>
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/intel_panel.c | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c 
> b/drivers/gpu/drm/i915/intel_panel.c
> index cb50c52..dbe05ec 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -888,10 +888,14 @@ static void pch_enable_backlight(struct intel_connector 
> *connector)
>   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
>   struct intel_panel *panel = >panel;
>   enum pipe pipe = intel_get_pipe_from_connector(connector);
> - enum transcoder cpu_transcoder =
> - intel_pipe_to_cpu_transcoder(dev_priv, pipe);
> + enum transcoder cpu_transcoder;
>   u32 cpu_ctl2, pch_ctl1, pch_ctl2;
>  
> + if (WARN_ON_ONCE(pipe == INVALID_PIPE))
> + return;

Please just assign e.g. TRANSCODER_EDP to cpu_transcoder in this case,
go on, and hope for the best. Do leave the warn in place though.

> +
> + cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv, pipe);
> +
>   cpu_ctl2 = I915_READ(BLC_PWM_CPU_CTL2);
>   if (cpu_ctl2 & BLM_PWM_ENABLE) {
>   DRM_DEBUG_KMS("cpu backlight already enabled\n");
> @@ -973,6 +977,9 @@ static void i965_enable_backlight(struct intel_connector 
> *connector)
>   enum pipe pipe = intel_get_pipe_from_connector(connector);
>   u32 ctl, ctl2, freq;
>  
> + if (WARN_ON_ONCE(pipe == INVALID_PIPE))
> + return;

Same here, please just assign e.g. PIPE_A here with the warning, and
limp on.

> +
>   ctl2 = I915_READ(BLC_PWM_CTL2);
>   if (ctl2 & BLM_PWM_ENABLE) {
>   DRM_DEBUG_KMS("backlight already enabled\n");
> @@ -1093,6 +1100,9 @@ void intel_panel_enable_backlight(struct 
> intel_connector *connector)
>   if (!panel->backlight.present)
>   return;
>  
> + if (WARN_ON_ONCE(pipe == INVALID_PIPE))
> + return;

Here, pipe is only used for the debug logging, just skip that instead.

> +
>   DRM_DEBUG_KMS("pipe %c\n", pipe_name(pipe));
>  
>   mutex_lock(_priv->backlight_lock);

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

Re: [Intel-gfx] [PATCH 4/7] lib/igt_draw: Add Y-tiling support for IGT_DRAW_BLT method

[Paulo Zanoni]

Em Sáb, 2017-03-18 às 00:45 +0530, Praveen Paneri escreveu:
> From: Akash Goel 
> 
> Signed-off-by: Akash Goel 
> Signed-off-by: Praveen Paneri 
> ---
>  lib/igt_draw.c | 35 +++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/lib/igt_draw.c b/lib/igt_draw.c
> index fcf8fba..17011d8 100644
> --- a/lib/igt_draw.c
> +++ b/lib/igt_draw.c
> @@ -31,6 +31,7 @@
>  #include "igt_core.h"
>  #include "igt_fb.h"
>  #include "ioctl_wrappers.h"
> +#include "i830_reg.h"
>  
>  /**
>   * SECTION:igt_draw
> @@ -487,6 +488,23 @@ static void draw_rect_blt(int fd, struct
> cmd_data *cmd_data,
>   blt_cmd_tiling = (tiling) ? XY_COLOR_BLT_TILED : 0;
>   pitch = (tiling) ? buf->stride / 4 : buf->stride;
>  
> + if (tiling == I915_TILING_Y) {
> + /* To change the tile register, insert an
> MI_FLUSH_DW followed by an MI_LOAD_REGISTER_IMM */
> + BEGIN_BATCH(4, 0);
> + OUT_BATCH(MI_FLUSH_DW | 2);
> + OUT_BATCH(0x0);
> + OUT_BATCH(0x0);
> + OUT_BATCH(0x0);
> + ADVANCE_BATCH();
> +
> + BEGIN_BATCH(4, 0);
> + OUT_BATCH(MI_LOAD_REGISTER_IMM);
> + OUT_BATCH(0x22200); /* BCS_SWCTRL */
> + OUT_BATCH(((0x3 << 16) | 0x3)); /* enable the Y
> tiling */
> + OUT_BATCH(MI_NOOP);
> + ADVANCE_BATCH();
> + }
> +
>   BEGIN_BATCH(6, 1);
>   OUT_BATCH(XY_COLOR_BLT_CMD_NOLEN | XY_COLOR_BLT_WRITE_ALPHA
> |
>     XY_COLOR_BLT_WRITE_RGB | blt_cmd_tiling |
> blt_cmd_len);
> @@ -497,6 +515,23 @@ static void draw_rect_blt(int fd, struct
> cmd_data *cmd_data,
>   OUT_BATCH(color);
>   ADVANCE_BATCH();
>  
> + if (tiling == I915_TILING_Y) {
> + /* To change the tile register, insert an
> MI_FLUSH_DW followed by an MI_LOAD_REGISTER_IMM */
> + BEGIN_BATCH(4, 0);
> + OUT_BATCH(MI_FLUSH_DW | 2);
> + OUT_BATCH(0x0);
> + OUT_BATCH(0x0);
> + OUT_BATCH(0x0);
> + ADVANCE_BATCH();
> +
> + BEGIN_BATCH(4, 0);
> + OUT_BATCH(MI_LOAD_REGISTER_IMM);
> + OUT_BATCH(0x22200); /* BCS_SWCTRL */
> + OUT_BATCH((0x3 << 16)); /* Reset back to X-Tiling
> (default) */
> + OUT_BATCH(MI_NOOP);
> + ADVANCE_BATCH();
> + }

These are two almost identical copies of the same code. Please extract
them to a function that takes the tiling as the argument.

> +
>   intel_batchbuffer_flush(batch);
>   intel_batchbuffer_free(batch);
>  }
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [alsa-devel] [PATCH 11/11] ALSA: x86: Register multiple PCM devices for the LPE audio card

[Takashi Iwai]

On Wed, 26 Apr 2017 15:49:06 +0200,
Ville Syrjälä wrote:
> 
> On Wed, Apr 26, 2017 at 09:19:21AM +0200, Takashi Iwai wrote:
> > On Wed, 26 Apr 2017 09:04:46 +0200,
> > Takashi Iwai wrote:
> > > 
> > > On Wed, 26 Apr 2017 03:58:57 +0200,
> > > Pierre-Louis Bossart wrote:
> > > > 
> > > > On 04/25/2017 03:27 PM, ville.syrj...@linux.intel.com wrote:
> > > > > From: Ville Syrjälä 
> > > > >
> > > > > Now that everything is in place let's register a PCM device for
> > > > > each pipe of the display engine. This will make it possible to
> > > > > actually output audio to multiple displays at the same time. And
> > > > > it avoids modesets on unrelated displays from clobbering up the
> > > > > ELD and whatnot for the display currently doing the playback.
> > > > >
> > > > > The alternative would be to have a PCM device per port, but per-pipe
> > > > > is easier since the hardware actually works that way.
> > > > Very nice. I just tested on a CHT Zotac box which has two connectors
> > > > (1 HDMI and 1 DP), and I get sound concurrently on both, with hdmi
> > > > being listed as device 2 and DP as device 0.
> > > > I thought there were hardware restrictions but you proved me wrong. 
> > > > Kudos.
> > > > 
> > > > The only point that I find weird is that the jacks are reported as
> > > > 'on' on the 3 pipes, is there a way to tie them to an actual cable
> > > > being used?
> > > 
> > > The pdata check was changed to check port=-1 as the monitor off in the
> > > patch 6.  Maybe the initialization is missing?
> > 
> > I guess the problem is that the hotplug wq is called at the
> > initialization to retrieve the pdata for all pipes.  It's called with
> > uninitialized port=0, so all flags are on at init.
> 
> Indeed. That will need to be fixed.
> 
> > 
> > And it implies the potential problem: the pdata contains the
> > information only for a single pipe.  Maybe it should keep the
> > status/ELD for all three pipes.
> 
> I already did that.

Oh then it' fine, I just didn't find it.

> That being said, the entire notify vs. wq is pretty racy. So I was
> thinking that maybe we could just eliminate the wq and do whatever is
> needed directly from the notify hook. And then we could eliminate the
> (ab)use of pdata to transfer the ELD and whatnot between the drivers.
> I guess the main complication is the driver load case. I didn't
> really think that one through so far.

One way would be to implement the get_eld() to call at the probe
time.  HD-audio calls such one (provided via component) at probe and
resume time to sync with the actual h/w state.  For LPE audio, it's
even easier, as we may call i915 exported function directly.


thanks,

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

Re: [Intel-gfx] [PATCH 6/7] igt/kms_frontbuffer_tracking: Add Y-tiling support

[Paulo Zanoni]

Em Sáb, 2017-03-18 às 00:45 +0530, Praveen Paneri escreveu:
> Allow tests to create Y-tiled bufferes using a separate
> argument to the test without increasing the number of
> subtests.
> 
> Signed-off-by: Praveen Paneri 
> ---
>  tests/kms_frontbuffer_tracking.c | 46 +++---
> --
>  1 file changed, 27 insertions(+), 19 deletions(-)
> 
> diff --git a/tests/kms_frontbuffer_tracking.c
> b/tests/kms_frontbuffer_tracking.c
> index 03c7710..0597f10 100644
> --- a/tests/kms_frontbuffer_tracking.c
> +++ b/tests/kms_frontbuffer_tracking.c
> @@ -250,6 +250,7 @@ struct {
>   int only_pipes;
>   int shared_fb_x_offset;
>   int shared_fb_y_offset;
> + uint64_t tiling;
>  } opt = {
>   .check_status = true,
>   .check_crc = true,
> @@ -262,6 +263,7 @@ struct {
>   .only_pipes = PIPE_COUNT,
>   .shared_fb_x_offset = 500,
>   .shared_fb_y_offset = 500,
> + .tiling = LOCAL_I915_FORMAT_MOD_X_TILED,
>  };
>  
>  struct modeset_params {
> @@ -576,7 +578,7 @@ static void create_fb(enum pixel_format pformat,
> int width, int height,
>   if (plane == PLANE_CUR)
>   tiling_for_size = LOCAL_DRM_FORMAT_MOD_NONE;
>   else
> - tiling_for_size = LOCAL_I915_FORMAT_MOD_X_TILED;
> + tiling_for_size = opt.tiling;
>  
>   igt_calc_fb_size(drm.fd, width, height, bpp,
> tiling_for_size, ,
>    );
> @@ -708,7 +710,7 @@ static void create_shared_fb(enum pixel_format
> format)
>  
>   big_h = prim_h + scnd_h + offs_h + opt.shared_fb_y_offset;
>  
> - create_fb(format, big_w, big_h,
> LOCAL_I915_FORMAT_MOD_X_TILED,
> + create_fb(format, big_w, big_h, opt.tiling,
>     PLANE_PRI, >big);
>  }
>  
> @@ -742,16 +744,16 @@ static void create_fbs(enum pixel_format
> format)
>  
>   create_fb(format, prim_mode_params.mode->hdisplay,
>     prim_mode_params.mode->vdisplay,
> -   LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_PRI, 
> >prim_pri);
> +   opt.tiling, PLANE_PRI, >prim_pri);
>   create_fb(format, prim_mode_params.cursor.w,
>     prim_mode_params.cursor.h,
> LOCAL_DRM_FORMAT_MOD_NONE,
>     PLANE_CUR, >prim_cur);
>   create_fb(format, prim_mode_params.sprite.w,
> -   prim_mode_params.sprite.h,
> LOCAL_I915_FORMAT_MOD_X_TILED,
> +   prim_mode_params.sprite.h, opt.tiling,
>     PLANE_SPR, >prim_spr);
>  
>   create_fb(format, offscreen_fb.w, offscreen_fb.h,
> -   LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_PRI, 
> >offscreen);
> +   opt.tiling, PLANE_PRI, >offscreen);
>  
>   create_shared_fb(format);
>  
> @@ -760,11 +762,11 @@ static void create_fbs(enum pixel_format
> format)
>  
>   create_fb(format, scnd_mode_params.mode->hdisplay,
>     scnd_mode_params.mode->vdisplay,
> -   LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_PRI, 
> >scnd_pri);
> +   opt.tiling, PLANE_PRI, >scnd_pri);
>   create_fb(format, scnd_mode_params.cursor.w,
> scnd_mode_params.cursor.h,
>     LOCAL_DRM_FORMAT_MOD_NONE, PLANE_CUR, 
> >scnd_cur);
>   create_fb(format, scnd_mode_params.sprite.w,
> scnd_mode_params.sprite.h,
> -   LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_SPR, 
> >scnd_spr);
> +   opt.tiling, PLANE_SPR, >scnd_spr);
>  }
>  
>  static bool set_mode_for_params(struct modeset_params *params)
> @@ -1241,7 +1243,7 @@ static void init_blue_crc(enum pixel_format
> format, bool mandatory_sink_crc)
>  
>   create_fb(format, prim_mode_params.mode->hdisplay,
>     prim_mode_params.mode->vdisplay,
> -   LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_PRI, );
> +   opt.tiling, PLANE_PRI, );
>  
>   fill_fb(, COLOR_PRIM_BG);
>  
> @@ -1276,7 +1278,7 @@ static void init_crcs(enum pixel_format format,
>   for (r = 0; r < pattern->n_rects; r++)
>   create_fb(format, prim_mode_params.mode->hdisplay,
>     prim_mode_params.mode->vdisplay,
> -   LOCAL_I915_FORMAT_MOD_X_TILED, PLANE_PRI,
> _fbs[r]);
> +   opt.tiling, PLANE_PRI, _fbs[r]);
>  
>   for (r = 0; r < pattern->n_rects; r++)
>   fill_fb(_fbs[r], COLOR_PRIM_BG);
> @@ -2374,7 +2376,7 @@ static void flip_subtest(const struct test_mode
> *t)
>   prepare_subtest(t, pattern);
>  
>   create_fb(t->format, params->fb.fb->width, params->fb.fb-
> >height,
> -   LOCAL_I915_FORMAT_MOD_X_TILED, t->plane, );
> +   opt.tiling, t->plane, );
>   fill_fb(, bg_color);
>   orig_fb = params->fb.fb;
>  
> @@ -2420,7 +2422,7 @@ static void fliptrack_subtest(const struct
> test_mode *t, enum flip_type type)
>   prepare_subtest(t, pattern);
>  
>   create_fb(t->format, params->fb.fb->width, params->fb.fb-
> >height,
> -   LOCAL_I915_FORMAT_MOD_X_TILED, t->plane, );
> +   

Re: [Intel-gfx] [PATCH 4/8] drm/i915: Check error return when setting DMA mask

[Jani Nikula]

On Wed, 26 Apr 2017, Imre Deak  wrote:
> Even though an error from these functions isn't fatal we still want to
> have a diagnostic message about it.
>
> Signed-off-by: Imre Deak 
> ---
>  drivers/gpu/drm/i915/i915_gem_gtt.c | 14 ++
>  1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index 8bab4ae..13bf099 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -2741,13 +2741,16 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
>   struct pci_dev *pdev = dev_priv->drm.pdev;
>   unsigned int size;
>   u16 snb_gmch_ctl;
> + int err;
>  
>   /* TODO: We're not aware of mappable constraints on gen8 yet */
>   ggtt->mappable_base = pci_resource_start(pdev, 2);
>   ggtt->mappable_end = pci_resource_len(pdev, 2);
>  
> - if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(39)))
> - pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(39));
> + if (!(err = pci_set_dma_mask(pdev, DMA_BIT_MASK(39

Please split out the assignment to a line of its own, in both places.

BR,
Jani.

> + err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(39));
> + if (err)
> + DRM_ERROR("Can't set DMA mask/consistent mask (%d)\n", err);
>  
>   pci_read_config_word(pdev, SNB_GMCH_CTRL, _gmch_ctl);
>  
> @@ -2790,6 +2793,7 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
>   struct pci_dev *pdev = dev_priv->drm.pdev;
>   unsigned int size;
>   u16 snb_gmch_ctl;
> + int err;
>  
>   ggtt->mappable_base = pci_resource_start(pdev, 2);
>   ggtt->mappable_end = pci_resource_len(pdev, 2);
> @@ -2802,8 +2806,10 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
>   return -ENXIO;
>   }
>  
> - if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(40)))
> - pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(40));
> + if (!(err = pci_set_dma_mask(pdev, DMA_BIT_MASK(40
> + err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(40));
> + if (err)
> + DRM_ERROR("Can't set DMA mask/consistent mask (%d)\n", err);
>   pci_read_config_word(pdev, SNB_GMCH_CTRL, _gmch_ctl);
>  
>   ggtt->stolen_size = gen6_get_stolen_size(snb_gmch_ctl);

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

Re: [Intel-gfx] [PATCH 00/11] drm/i915: LPE audio runtime PM and multipipe

[Ville Syrjälä]

On Wed, Apr 26, 2017 at 03:47:44PM +0200, Takashi Iwai wrote:
> On Wed, 26 Apr 2017 15:38:53 +0200,
> Ville Syrjälä wrote:
> > 
> > On Wed, Apr 26, 2017 at 09:29:18AM +0200, Takashi Iwai wrote:
> > > On Tue, 25 Apr 2017 22:27:19 +0200,
> > > ville.syrj...@linux.intel.com wrote:
> > > > 
> > > > From: Ville Syrjälä 
> > > > 
> > > > I was wondering why my VLV no longer runtime suspended, and after some
> > > > thinking I decided it had to be the LPE audio preventing it. Turns out
> > > > I was right, so here's my attempt at fixing it.
> > > > 
> > > > And while looking at the code I couldn't help but notice that it
> > > > couldn't actually handle multiple pipes playing back audio at the
> > > > same time. And even having multiple displays active even if only
> > > > one was playing audio was probably a recipe for failure. So I
> > > > tried to fix that by registering a separate PCM device for each
> > > > pipe.
> > > > 
> > > > Note that the patch subjects may not reflect the subsystem
> > > > very well since most of these straddle the border between drm
> > > > and alsa. I think I just slapped on drm/i915 to most where
> > > > there was no clear winner.
> > > 
> > > A nice patchset, thanks for working on it!
> > > 
> > > One slight concern (other than the jack issue Pierre reported) is the
> > > incompatible behavior from the current version.  With the pipe-based
> > > multiple streams, user would need to choose another one even if the
> > > device has a single HDMI output, which is pretty common on BYT/CHV
> > > tablets.
> > > 
> > > Maybe it's no big problem as the users are still limited at the
> > > moment.  Or, we may need to handle a bit differently, e.g. assigning
> > > the PCM stream dynamically per hotplug.
> > 
> > Yeah, I tied the PCM device to the pipe to match the hardware. But we
> > could certainly register the PCM device per port, and then do a 
> > pipe<->port mapping somewhere to make it all work out. One slight
> > complication is that not all ports are necessarily present so we
> > might have eg. just port B and port D, but no port C. Not sure if
> > it would be a bad thing to register a PCM device even for the
> > missing ports anyway?
> > 
> > I don't recall which way HDA works. Device per port I guess? Well,
> > for DP SST/HDMI. But for DP MST I presume it's device per stream
> > (ie. pipe) even with HDA.
> 
> HD-audio creates the PCM device per HD-audio widget representation,
> and they correspond to ports, as it seems.

With the slight exception of old stuff like ctg/elk where there is just
one audio device IIRC, and that one gets fed into whichever port enables
audio, and if both enable it it goes to /dev/null.

> For MST, the situation is
> more complex, and we assign the PCM stream dynamically.  It's for
> keeping the behavior (more or less) consistent with non-MST.
> 
> > > In anyway, with the support of multi streams, alsa-lib config needs to
> > > be updated.
> > 
> > Hmm. I suppose I'll have to take a gander at what's there.
> 
> The HDMI PCM definition itself is easy, just just adding more (hdmi.1,
> hdmi.2, etc).  The difficult part would be the front and the default
> PCM definition, and I have no good idea about it, so far.
> 
> 
> Takashi

-- 
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] [alsa-devel] [PATCH 11/11] ALSA: x86: Register multiple PCM devices for the LPE audio card

[Ville Syrjälä]

On Wed, Apr 26, 2017 at 09:19:21AM +0200, Takashi Iwai wrote:
> On Wed, 26 Apr 2017 09:04:46 +0200,
> Takashi Iwai wrote:
> > 
> > On Wed, 26 Apr 2017 03:58:57 +0200,
> > Pierre-Louis Bossart wrote:
> > > 
> > > On 04/25/2017 03:27 PM, ville.syrj...@linux.intel.com wrote:
> > > > From: Ville Syrjälä 
> > > >
> > > > Now that everything is in place let's register a PCM device for
> > > > each pipe of the display engine. This will make it possible to
> > > > actually output audio to multiple displays at the same time. And
> > > > it avoids modesets on unrelated displays from clobbering up the
> > > > ELD and whatnot for the display currently doing the playback.
> > > >
> > > > The alternative would be to have a PCM device per port, but per-pipe
> > > > is easier since the hardware actually works that way.
> > > Very nice. I just tested on a CHT Zotac box which has two connectors
> > > (1 HDMI and 1 DP), and I get sound concurrently on both, with hdmi
> > > being listed as device 2 and DP as device 0.
> > > I thought there were hardware restrictions but you proved me wrong. Kudos.
> > > 
> > > The only point that I find weird is that the jacks are reported as
> > > 'on' on the 3 pipes, is there a way to tie them to an actual cable
> > > being used?
> > 
> > The pdata check was changed to check port=-1 as the monitor off in the
> > patch 6.  Maybe the initialization is missing?
> 
> I guess the problem is that the hotplug wq is called at the
> initialization to retrieve the pdata for all pipes.  It's called with
> uninitialized port=0, so all flags are on at init.

Indeed. That will need to be fixed.

> 
> And it implies the potential problem: the pdata contains the
> information only for a single pipe.  Maybe it should keep the
> status/ELD for all three pipes.

I already did that.

That being said, the entire notify vs. wq is pretty racy. So I was
thinking that maybe we could just eliminate the wq and do whatever is
needed directly from the notify hook. And then we could eliminate the
(ab)use of pdata to transfer the ELD and whatnot between the drivers.
I guess the main complication is the driver load case. I didn't
really think that one through so far.

-- 
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 00/11] drm/i915: LPE audio runtime PM and multipipe

[Takashi Iwai]

On Wed, 26 Apr 2017 15:38:53 +0200,
Ville Syrjälä wrote:
> 
> On Wed, Apr 26, 2017 at 09:29:18AM +0200, Takashi Iwai wrote:
> > On Tue, 25 Apr 2017 22:27:19 +0200,
> > ville.syrj...@linux.intel.com wrote:
> > > 
> > > From: Ville Syrjälä 
> > > 
> > > I was wondering why my VLV no longer runtime suspended, and after some
> > > thinking I decided it had to be the LPE audio preventing it. Turns out
> > > I was right, so here's my attempt at fixing it.
> > > 
> > > And while looking at the code I couldn't help but notice that it
> > > couldn't actually handle multiple pipes playing back audio at the
> > > same time. And even having multiple displays active even if only
> > > one was playing audio was probably a recipe for failure. So I
> > > tried to fix that by registering a separate PCM device for each
> > > pipe.
> > > 
> > > Note that the patch subjects may not reflect the subsystem
> > > very well since most of these straddle the border between drm
> > > and alsa. I think I just slapped on drm/i915 to most where
> > > there was no clear winner.
> > 
> > A nice patchset, thanks for working on it!
> > 
> > One slight concern (other than the jack issue Pierre reported) is the
> > incompatible behavior from the current version.  With the pipe-based
> > multiple streams, user would need to choose another one even if the
> > device has a single HDMI output, which is pretty common on BYT/CHV
> > tablets.
> > 
> > Maybe it's no big problem as the users are still limited at the
> > moment.  Or, we may need to handle a bit differently, e.g. assigning
> > the PCM stream dynamically per hotplug.
> 
> Yeah, I tied the PCM device to the pipe to match the hardware. But we
> could certainly register the PCM device per port, and then do a 
> pipe<->port mapping somewhere to make it all work out. One slight
> complication is that not all ports are necessarily present so we
> might have eg. just port B and port D, but no port C. Not sure if
> it would be a bad thing to register a PCM device even for the
> missing ports anyway?
> 
> I don't recall which way HDA works. Device per port I guess? Well,
> for DP SST/HDMI. But for DP MST I presume it's device per stream
> (ie. pipe) even with HDA.

HD-audio creates the PCM device per HD-audio widget representation,
and they correspond to ports, as it seems.  For MST, the situation is
more complex, and we assign the PCM stream dynamically.  It's for
keeping the behavior (more or less) consistent with non-MST.

> > In anyway, with the support of multi streams, alsa-lib config needs to
> > be updated.
> 
> Hmm. I suppose I'll have to take a gander at what's there.

The HDMI PCM definition itself is easy, just just adding more (hdmi.1,
hdmi.2, etc).  The difficult part would be the front and the default
PCM definition, and I have no good idea about it, so far.


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

Re: [Intel-gfx] [PATCH 0/7] Add Y-tiling support into IGTs

[Paulo Zanoni]

Em Sáb, 2017-03-18 às 00:45 +0530, Praveen Paneri escreveu:
> This series adds Y-tiled buffer creation support into IGT libraries
> and
> goes on to use this capability to add support into FBC tests to use
> Y-tiled buffers.

I applied this series and the Kernel patch. If I try to run
kms_draw_crc it just gets stuck eating 100% of the CPU. I suppose this
needs to be debugged, maybe some patch is wrong. Can you reproduce this
behavior?

> 
> Akash Goel (1):
>   lib/igt_draw: Add Y-tiling support for IGT_DRAW_BLT method
> 
> Paulo Zanoni (1):
>   tests/kms_draw_crc: add support for Y tiling
> 
> Praveen Paneri (5):
>   lib/igt_fb: Let others use igt_get_fb_tile_size
>   lib/igt_fb: Add helper function for tile_to_mod
>   lib/igt_draw: Add Y-tiling support
>   igt/kms_frontbuffer_tracking: Add Y-tiling support
>   igt/kms_fbc_crc.c : Add Y-tile tests
> 
>  lib/igt_draw.c   | 167 -
> --
>  lib/igt_fb.c |  29 ++-
>  lib/igt_fb.h |   4 +-
>  tests/kms_draw_crc.c |  58 ++
>  tests/kms_fbc_crc.c  |  71 +
>  tests/kms_frontbuffer_tracking.c |  46 ++-
>  6 files changed, 262 insertions(+), 113 deletions(-)
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Sanitize engine context sizes

[Tvrtko Ursulin]

On 26/04/2017 14:16, Tvrtko Ursulin wrote:

On 26/04/2017 13:20, Joonas Lahtinen wrote:

Pre-calculate engine context size based on engine class and device
generation and store it in the engine instance.

v2:
- Squash and get rid of hw_context_size (Chris)

Signed-off-by: Joonas Lahtinen 
Cc: Paulo Zanoni 
Cc: Rodrigo Vivi 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Oscar Mateo 
Cc: Zhenyu Wang 
Cc: intel-gvt-...@lists.freedesktop.org
---
 drivers/gpu/drm/i915/gvt/scheduler.c   |  6 +--
 drivers/gpu/drm/i915/i915_drv.h|  1 -
 drivers/gpu/drm/i915/i915_gem_context.c| 59 +++---
 drivers/gpu/drm/i915/i915_guc_submission.c |  3 +-
 drivers/gpu/drm/i915/i915_reg.h| 10 
 drivers/gpu/drm/i915/intel_engine_cs.c | 78
++
 drivers/gpu/drm/i915/intel_lrc.c   | 54 +
 drivers/gpu/drm/i915/intel_lrc.h   |  2 -
 drivers/gpu/drm/i915/intel_ringbuffer.h|  7 +--
 9 files changed, 93 insertions(+), 127 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
b/drivers/gpu/drm/i915/gvt/scheduler.c
index a77db23..ac538dc 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -69,8 +69,7 @@ static int populate_shadow_context(struct
intel_vgpu_workload *workload)
 gvt_dbg_sched("ring id %d workload lrca %x", ring_id,
 workload->ctx_desc.lrca);

-context_page_num = intel_lr_context_size(
-gvt->dev_priv->engine[ring_id]);
+context_page_num = gvt->dev_priv->engine[ring_id]->context_size;

 context_page_num = context_page_num >> PAGE_SHIFT;

@@ -333,8 +332,7 @@ static void update_guest_context(struct
intel_vgpu_workload *workload)
 gvt_dbg_sched("ring id %d workload lrca %x\n", ring_id,
 workload->ctx_desc.lrca);

-context_page_num = intel_lr_context_size(
-gvt->dev_priv->engine[ring_id]);
+context_page_num = gvt->dev_priv->engine[ring_id]->context_size;

 context_page_num = context_page_num >> PAGE_SHIFT;

diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 357b6c6..4b54b92 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2359,7 +2359,6 @@ struct drm_i915_private {
  */
 struct mutex av_mutex;

-uint32_t hw_context_size;
 struct list_head context_list;

 u32 fdi_rx_config;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8bd0c49..b69a026 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -92,33 +92,6 @@

 #define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1

-static int get_context_size(struct drm_i915_private *dev_priv)
-{
-int ret;
-u32 reg;
-
-switch (INTEL_GEN(dev_priv)) {
-case 6:
-reg = I915_READ(CXT_SIZE);
-ret = GEN6_CXT_TOTAL_SIZE(reg) * 64;
-break;
-case 7:
-reg = I915_READ(GEN7_CXT_SIZE);
-if (IS_HASWELL(dev_priv))
-ret = HSW_CXT_TOTAL_SIZE;
-else
-ret = GEN7_CXT_TOTAL_SIZE(reg) * 64;
-break;
-case 8:
-ret = GEN8_CXT_TOTAL_SIZE;
-break;
-default:
-BUG();
-}
-
-return ret;
-}
-
 void i915_gem_context_free(struct kref *ctx_ref)
 {
 struct i915_gem_context *ctx = container_of(ctx_ref,
typeof(*ctx), ref);
@@ -266,11 +239,12 @@ __create_hw_context(struct drm_i915_private
*dev_priv,
 list_add_tail(>link, _priv->context_list);
 ctx->i915 = dev_priv;

-if (dev_priv->hw_context_size) {
+if (dev_priv->engine[RCS]->context_size) {
 struct drm_i915_gem_object *obj;
 struct i915_vma *vma;

-obj = alloc_context_obj(dev_priv, dev_priv->hw_context_size);
+obj = alloc_context_obj(dev_priv,
+dev_priv->engine[RCS]->context_size);
 if (IS_ERR(obj)) {
 ret = PTR_ERR(obj);
 goto err_out;
@@ -443,21 +417,6 @@ int i915_gem_context_init(struct drm_i915_private
*dev_priv)
 BUILD_BUG_ON(MAX_CONTEXT_HW_ID > INT_MAX);
 ida_init(_priv->context_hw_ida);

-if (i915.enable_execlists) {
-/* NB: intentionally left blank. We will allocate our own
- * backing objects as we need them, thank you very much */
-dev_priv->hw_context_size = 0;
-} else if (HAS_HW_CONTEXTS(dev_priv)) {
-dev_priv->hw_context_size =
-round_up(get_context_size(dev_priv),
- I915_GTT_PAGE_SIZE);


Is this rounding up lost when used from __create_hw_context?


Also lost seems keeping hw_context_size at zero when !HAS_HW_CONTEXT, 
deliberate? Looks like the replacement of contexts_enabled 

[Intel-gfx] [PATCH 7/8] drm/i915/lvds: Remove magic from PLL programming

[Imre Deak]

This looks like a left-over from enabling work. I don't have the
specification to check whether we have to set
CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED, for now just keep things
as-is, removing the magic so that static checkers don't complain.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/dvo_ch7017.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/dvo_ch7017.c 
b/drivers/gpu/drm/i915/dvo_ch7017.c
index b3c7c19..c0712a5 100644
--- a/drivers/gpu/drm/i915/dvo_ch7017.c
+++ b/drivers/gpu/drm/i915/dvo_ch7017.c
@@ -280,10 +280,13 @@ static void ch7017_mode_set(struct intel_dvo_device *dvo,
(0 << CH7017_PHASE_DETECTOR_SHIFT);
} else {
outputs_enable = CH7017_LVDS_CHANNEL_A | 
CH7017_CHARGE_PUMP_HIGH;
-   lvds_pll_feedback_div = 
CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED |
+   /*
+* FIXME: Check if CH7017_LVDS_PLL_FEEDBACK_DEFAULT_RESERVED
+* needs to be also set for the following.
+*/
+   lvds_pll_feedback_div =
(2 << CH7017_LVDS_PLL_FEED_BACK_DIVIDER_SHIFT) |
(3 << CH7017_LVDS_PLL_FEED_FORWARD_DIVIDER_SHIFT);
-   lvds_pll_feedback_div = 35;
lvds_control_2 = (3 << CH7017_LOOP_FILTER_SHIFT) |
(0 << CH7017_PHASE_DETECTOR_SHIFT);
if (1) { /* XXX: dual channel panel detection.  Assume yes for 
now. */
-- 
2.5.0

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

[Intel-gfx] [PATCH 8/8] drm: Remove redundant NULL check during atomic plane commit

[Imre Deak]

plane_state can't be NULL anywhere in this function, so the NULL check
at the end is redundant, remove it.

Cc: dri-de...@lists.freedesktop.org
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/drm_plane_helper.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 9854a50..2c27f6f 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -511,12 +511,10 @@ int drm_plane_helper_commit(struct drm_plane *plane,
if (plane_funcs->cleanup_fb)
plane_funcs->cleanup_fb(plane, plane_state);
 out:
-   if (plane_state) {
-   if (plane->funcs->atomic_destroy_state)
-   plane->funcs->atomic_destroy_state(plane, plane_state);
-   else
-   drm_atomic_helper_plane_destroy_state(plane, 
plane_state);
-   }
+   if (plane->funcs->atomic_destroy_state)
+   plane->funcs->atomic_destroy_state(plane, plane_state);
+   else
+   drm_atomic_helper_plane_destroy_state(plane, plane_state);
 
return ret;
 }
-- 
2.5.0

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

[Intel-gfx] [PATCH 6/8] drm/i915: Sanitize stolen memory size calculation

[Imre Deak]

On GEN8+ (not counting CHV) the calculation can in theory result in an
incorrect sign extension with all upper bits set. In practice this is
unlikely to happen since it would require 4GB of stolen memory set
aside. For consistency still prevent the sign extension explicitly
everywhere.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 13bf099..4b764b0 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2577,14 +2577,14 @@ static size_t gen6_get_stolen_size(u16 snb_gmch_ctl)
 {
snb_gmch_ctl >>= SNB_GMCH_GMS_SHIFT;
snb_gmch_ctl &= SNB_GMCH_GMS_MASK;
-   return snb_gmch_ctl << 25; /* 32 MB units */
+   return (size_t)snb_gmch_ctl << 25; /* 32 MB units */
 }
 
 static size_t gen8_get_stolen_size(u16 bdw_gmch_ctl)
 {
bdw_gmch_ctl >>= BDW_GMCH_GMS_SHIFT;
bdw_gmch_ctl &= BDW_GMCH_GMS_MASK;
-   return bdw_gmch_ctl << 25; /* 32 MB units */
+   return (size_t)bdw_gmch_ctl << 25; /* 32 MB units */
 }
 
 static size_t chv_get_stolen_size(u16 gmch_ctrl)
@@ -2598,11 +2598,11 @@ static size_t chv_get_stolen_size(u16 gmch_ctrl)
 * 0x17 to 0x1d: 4MB increments start at 36MB
 */
if (gmch_ctrl < 0x11)
-   return gmch_ctrl << 25;
+   return (size_t)gmch_ctrl << 25;
else if (gmch_ctrl < 0x17)
-   return (gmch_ctrl - 0x11 + 2) << 22;
+   return (size_t)(gmch_ctrl - 0x11 + 2) << 22;
else
-   return (gmch_ctrl - 0x17 + 9) << 22;
+   return (size_t)(gmch_ctrl - 0x17 + 9) << 22;
 }
 
 static size_t gen9_get_stolen_size(u16 gen9_gmch_ctl)
@@ -2611,10 +2611,10 @@ static size_t gen9_get_stolen_size(u16 gen9_gmch_ctl)
gen9_gmch_ctl &= BDW_GMCH_GMS_MASK;
 
if (gen9_gmch_ctl < 0xf0)
-   return gen9_gmch_ctl << 25; /* 32 MB units */
+   return (size_t)gen9_gmch_ctl << 25; /* 32 MB units */
else
/* 4MB increments starting at 0xf0 for 4MB */
-   return (gen9_gmch_ctl - 0xf0 + 1) << 22;
+   return (size_t)(gen9_gmch_ctl - 0xf0 + 1) << 22;
 }
 
 static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 size)
-- 
2.5.0

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

[Intel-gfx] [PATCH 3/8] drm/i915/sdvo: Check error return from intel_sdvo_get_value()

[Imre Deak]

The current code assumes that 'enhancements' won't change in case of an
error, but this isn't guaranteed. Fix things by treating any error as a
lack of the given capability.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_sdvo.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_sdvo.c 
b/drivers/gpu/drm/i915/intel_sdvo.c
index 816a6f5..0d1c511 100644
--- a/drivers/gpu/drm/i915/intel_sdvo.c
+++ b/drivers/gpu/drm/i915/intel_sdvo.c
@@ -2893,10 +2893,10 @@ static bool intel_sdvo_create_enhance_property(struct 
intel_sdvo *intel_sdvo,
BUILD_BUG_ON(sizeof(enhancements) != 2);
 
enhancements.response = 0;
-   intel_sdvo_get_value(intel_sdvo,
-SDVO_CMD_GET_SUPPORTED_ENHANCEMENTS,
-, sizeof(enhancements));
-   if (enhancements.response == 0) {
+   if (!intel_sdvo_get_value(intel_sdvo,
+ SDVO_CMD_GET_SUPPORTED_ENHANCEMENTS,
+ , sizeof(enhancements)) ||
+   enhancements.response == 0) {
DRM_DEBUG_KMS("No enhancement is supported\n");
return true;
}
-- 
2.5.0

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

[Intel-gfx] [PATCH 2/8] drm/i915/dp: Check error return during DPCD capability queries

[Imre Deak]

The assumptions of these users of drm_dp_dpcd_readb() is that the passed
in output buffer won't change in case of error, but this isn't
guaranteed. Fix this by treating any error as the lack of the given
capability.

In case of DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP an error would leave the
buffer uninitialized even with the above assumption.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_dp.c | 20 
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 08834f7..4a6feb6 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3088,7 +3088,8 @@ static bool intel_dp_get_y_cord_status(struct intel_dp 
*intel_dp)
 {
uint8_t psr_caps = 0;
 
-   drm_dp_dpcd_readb(_dp->aux, DP_PSR_CAPS, _caps);
+   if (drm_dp_dpcd_readb(_dp->aux, DP_PSR_CAPS, _caps) != 1)
+   return false;
return psr_caps & DP_PSR2_SU_Y_COORDINATE_REQUIRED;
 }
 
@@ -3096,9 +3097,9 @@ static bool intel_dp_get_colorimetry_status(struct 
intel_dp *intel_dp)
 {
uint8_t dprx = 0;
 
-   drm_dp_dpcd_readb(_dp->aux,
-   DP_DPRX_FEATURE_ENUMERATION_LIST,
-   );
+   if (drm_dp_dpcd_readb(_dp->aux, DP_DPRX_FEATURE_ENUMERATION_LIST,
+ ) != 1)
+   return false;
return dprx & DP_VSC_SDP_EXT_FOR_COLORIMETRY_SUPPORTED;
 }
 
@@ -3106,7 +3107,9 @@ static bool intel_dp_get_alpm_status(struct intel_dp 
*intel_dp)
 {
uint8_t alpm_caps = 0;
 
-   drm_dp_dpcd_readb(_dp->aux, DP_RECEIVER_ALPM_CAP, _caps);
+   if (drm_dp_dpcd_readb(_dp->aux, DP_RECEIVER_ALPM_CAP,
+ _caps) != 1)
+   return false;
return alpm_caps & DP_ALPM_CAP;
 }
 
@@ -3679,9 +3682,10 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp)
uint8_t frame_sync_cap;
 
dev_priv->psr.sink_support = true;
-   drm_dp_dpcd_readb(_dp->aux,
- DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
- _sync_cap);
+   if (drm_dp_dpcd_readb(_dp->aux,
+ DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
+ _sync_cap) != 1)
+   frame_sync_cap = 0;
dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : false;
/* PSR2 needs frame sync as well */
dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
-- 
2.5.0

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

[Intel-gfx] [PATCH 1/8] drm/i915/vlv: Fix port B PLL opamp initialization

[Imre Deak]

The current code looks like a typo, the specification calls for setting
bits 31:24 to 0x8C, while preserving bits 23:0. Fix things accordingly.

I'm not aware of the typo causing a real problem, so the fix is only for
consistency.

Cc: Ville Syrjälä 
Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_display.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 85b9e2f5..19a7a1e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6369,8 +6369,8 @@ static void vlv_pllb_recal_opamp(struct drm_i915_private 
*dev_priv, enum pipe
vlv_dpio_write(dev_priv, pipe, VLV_PLL_DW9(1), reg_val);
 
reg_val = vlv_dpio_read(dev_priv, pipe, VLV_REF_DW13);
-   reg_val &= 0x8cff;
-   reg_val = 0x8c00;
+   reg_val &= 0x00ff;
+   reg_val |= 0x8c00;
vlv_dpio_write(dev_priv, pipe, VLV_REF_DW13, reg_val);
 
reg_val = vlv_dpio_read(dev_priv, pipe, VLV_PLL_DW9(1));
-- 
2.5.0

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

[Intel-gfx] [PATCH 5/8] drm/i915: Check error return when converting pipe to connector

[Imre Deak]

An error from intel_get_pipe_from_connector() would mean a bug somewhere
else, but we still should check for it to prevent some other more
obscure bug later.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/intel_panel.c | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index cb50c52..dbe05ec 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -888,10 +888,14 @@ static void pch_enable_backlight(struct intel_connector 
*connector)
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
enum pipe pipe = intel_get_pipe_from_connector(connector);
-   enum transcoder cpu_transcoder =
-   intel_pipe_to_cpu_transcoder(dev_priv, pipe);
+   enum transcoder cpu_transcoder;
u32 cpu_ctl2, pch_ctl1, pch_ctl2;
 
+   if (WARN_ON_ONCE(pipe == INVALID_PIPE))
+   return;
+
+   cpu_transcoder = intel_pipe_to_cpu_transcoder(dev_priv, pipe);
+
cpu_ctl2 = I915_READ(BLC_PWM_CPU_CTL2);
if (cpu_ctl2 & BLM_PWM_ENABLE) {
DRM_DEBUG_KMS("cpu backlight already enabled\n");
@@ -973,6 +977,9 @@ static void i965_enable_backlight(struct intel_connector 
*connector)
enum pipe pipe = intel_get_pipe_from_connector(connector);
u32 ctl, ctl2, freq;
 
+   if (WARN_ON_ONCE(pipe == INVALID_PIPE))
+   return;
+
ctl2 = I915_READ(BLC_PWM_CTL2);
if (ctl2 & BLM_PWM_ENABLE) {
DRM_DEBUG_KMS("backlight already enabled\n");
@@ -1093,6 +1100,9 @@ void intel_panel_enable_backlight(struct intel_connector 
*connector)
if (!panel->backlight.present)
return;
 
+   if (WARN_ON_ONCE(pipe == INVALID_PIPE))
+   return;
+
DRM_DEBUG_KMS("pipe %c\n", pipe_name(pipe));
 
mutex_lock(_priv->backlight_lock);
-- 
2.5.0

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

[Intel-gfx] [PATCH 4/8] drm/i915: Check error return when setting DMA mask

[Imre Deak]

Even though an error from these functions isn't fatal we still want to
have a diagnostic message about it.

Signed-off-by: Imre Deak 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8bab4ae..13bf099 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2741,13 +2741,16 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
struct pci_dev *pdev = dev_priv->drm.pdev;
unsigned int size;
u16 snb_gmch_ctl;
+   int err;
 
/* TODO: We're not aware of mappable constraints on gen8 yet */
ggtt->mappable_base = pci_resource_start(pdev, 2);
ggtt->mappable_end = pci_resource_len(pdev, 2);
 
-   if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(39)))
-   pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(39));
+   if (!(err = pci_set_dma_mask(pdev, DMA_BIT_MASK(39
+   err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(39));
+   if (err)
+   DRM_ERROR("Can't set DMA mask/consistent mask (%d)\n", err);
 
pci_read_config_word(pdev, SNB_GMCH_CTRL, _gmch_ctl);
 
@@ -2790,6 +2793,7 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
struct pci_dev *pdev = dev_priv->drm.pdev;
unsigned int size;
u16 snb_gmch_ctl;
+   int err;
 
ggtt->mappable_base = pci_resource_start(pdev, 2);
ggtt->mappable_end = pci_resource_len(pdev, 2);
@@ -2802,8 +2806,10 @@ static int gen6_gmch_probe(struct i915_ggtt *ggtt)
return -ENXIO;
}
 
-   if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(40)))
-   pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(40));
+   if (!(err = pci_set_dma_mask(pdev, DMA_BIT_MASK(40
+   err = pci_set_consistent_dma_mask(pdev, DMA_BIT_MASK(40));
+   if (err)
+   DRM_ERROR("Can't set DMA mask/consistent mask (%d)\n", err);
pci_read_config_word(pdev, SNB_GMCH_CTRL, _gmch_ctl);
 
ggtt->stolen_size = gen6_get_stolen_size(snb_gmch_ctl);
-- 
2.5.0

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

[Intel-gfx] [PATCH 0/8] drm: Fix/remove a few static checker error

[Imre Deak]

The patchset fixes static checker errors all over the place. All of them
are minor, mostly missing error return checks, with the exception of the
first which could fix a real use case.

Imre Deak (8):
  drm/i915/vlv: Fix port B PLL opamp initialization
  drm/i915/dp: Check error return during DPCD capability queries
  drm/i915/sdvo: Check error return from intel_sdvo_get_value()
  drm/i915: Check error return when setting DMA mask
  drm/i915: Check error return when converting pipe to connector
  drm/i915: Sanitize stolen memory size calculation
  drm/i915/lvds: Remove magic from PLL programming
  drm: Remove redundant NULL check during atomic plane commit

 drivers/gpu/drm/drm_plane_helper.c   | 10 --
 drivers/gpu/drm/i915/dvo_ch7017.c|  7 +--
 drivers/gpu/drm/i915/i915_gem_gtt.c  | 28 +---
 drivers/gpu/drm/i915/intel_display.c |  4 ++--
 drivers/gpu/drm/i915/intel_dp.c  | 20 
 drivers/gpu/drm/i915/intel_panel.c   | 14 --
 drivers/gpu/drm/i915/intel_sdvo.c|  8 
 7 files changed, 56 insertions(+), 35 deletions(-)

-- 
2.5.0

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

Re: [Intel-gfx] [PATCH 00/11] drm/i915: LPE audio runtime PM and multipipe

[Ville Syrjälä]

On Wed, Apr 26, 2017 at 09:29:18AM +0200, Takashi Iwai wrote:
> On Tue, 25 Apr 2017 22:27:19 +0200,
> ville.syrj...@linux.intel.com wrote:
> > 
> > From: Ville Syrjälä 
> > 
> > I was wondering why my VLV no longer runtime suspended, and after some
> > thinking I decided it had to be the LPE audio preventing it. Turns out
> > I was right, so here's my attempt at fixing it.
> > 
> > And while looking at the code I couldn't help but notice that it
> > couldn't actually handle multiple pipes playing back audio at the
> > same time. And even having multiple displays active even if only
> > one was playing audio was probably a recipe for failure. So I
> > tried to fix that by registering a separate PCM device for each
> > pipe.
> > 
> > Note that the patch subjects may not reflect the subsystem
> > very well since most of these straddle the border between drm
> > and alsa. I think I just slapped on drm/i915 to most where
> > there was no clear winner.
> 
> A nice patchset, thanks for working on it!
> 
> One slight concern (other than the jack issue Pierre reported) is the
> incompatible behavior from the current version.  With the pipe-based
> multiple streams, user would need to choose another one even if the
> device has a single HDMI output, which is pretty common on BYT/CHV
> tablets.
> 
> Maybe it's no big problem as the users are still limited at the
> moment.  Or, we may need to handle a bit differently, e.g. assigning
> the PCM stream dynamically per hotplug.

Yeah, I tied the PCM device to the pipe to match the hardware. But we
could certainly register the PCM device per port, and then do a 
pipe<->port mapping somewhere to make it all work out. One slight
complication is that not all ports are necessarily present so we
might have eg. just port B and port D, but no port C. Not sure if
it would be a bad thing to register a PCM device even for the
missing ports anyway?

I don't recall which way HDA works. Device per port I guess? Well,
for DP SST/HDMI. But for DP MST I presume it's device per stream
(ie. pipe) even with HDA.

> In anyway, with the support of multi streams, alsa-lib config needs to
> be updated.

Hmm. I suppose I'll have to take a gander at what's there.

-- 
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] [alsa-devel] [PATCH 05/11] drm/i915: Replace tmds_clock_speed and link_rate with just ls_clock

[Ville Syrjälä]

On Tue, Apr 25, 2017 at 08:09:34PM -0500, Pierre-Louis Bossart wrote:
> On 4/25/17 3:27 PM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > There's no need to distinguish between the DP link rate and HDMI TMDS
> > clock for the purposes of the LPE audio. Both are actually the same
> > thing more or less, which is the link symbol clock. So let's just
> > call the thing ls_clock and simplify the code.
> 
> there are still occurences of 'tmds' in sound/x86 and there are are 
> couple of debug messages that don't make sense any longer.

I was being a bit lazy and didn't remove the tmds vs. link_rate
distinction from the audio driver side. Not quite sure if we
want to do it not.

> 
> >
> > Cc: Takashi Iwai 
> > Cc: Pierre-Louis Bossart 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h|  4 ++--
> >  drivers/gpu/drm/i915/intel_audio.c | 19 ---
> >  drivers/gpu/drm/i915/intel_lpe_audio.c | 14 ++
> >  include/drm/intel_lpe_audio.h  |  3 +--
> >  sound/x86/intel_hdmi_audio.c   | 11 ---
> >  5 files changed, 21 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 357b6c6c2f04..876eee56a958 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -3721,8 +3721,8 @@ int  intel_lpe_audio_init(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);
> >  void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
> > -   void *eld, int port, int pipe, int tmds_clk_speed,
> > -   bool dp_output, int link_rate);
> > +   void *eld, int port, int pipe, int ls_clock,
> > +   bool dp_output);
> >
> >  /* intel_i2c.c */
> >  extern int intel_setup_gmbus(struct drm_i915_private *dev_priv);
> > diff --git a/drivers/gpu/drm/i915/intel_audio.c 
> > b/drivers/gpu/drm/i915/intel_audio.c
> > index 52c207e81f41..79eeef25321f 100644
> > --- a/drivers/gpu/drm/i915/intel_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > @@ -632,20 +632,9 @@ void intel_audio_codec_enable(struct intel_encoder 
> > *intel_encoder,
> >  (int) port, (int) pipe);
> > }
> >
> > -   switch (intel_encoder->type) {
> > -   case INTEL_OUTPUT_HDMI:
> > -   intel_lpe_audio_notify(dev_priv, connector->eld, port, pipe,
> > -  crtc_state->port_clock,
> > -  false, 0);
> > -   break;
> > -   case INTEL_OUTPUT_DP:
> > -   intel_lpe_audio_notify(dev_priv, connector->eld, port, pipe,
> > -  adjusted_mode->crtc_clock,
> > -  true, crtc_state->port_clock);
> > -   break;
> > -   default:
> > -   break;
> > -   }
> > +   intel_lpe_audio_notify(dev_priv, connector->eld, port, pipe,
> > +  crtc_state->port_clock,
> > +  intel_encoder->type == INTEL_OUTPUT_DP);
> >  }
> >
> >  /**
> > @@ -680,7 +669,7 @@ void intel_audio_codec_disable(struct intel_encoder 
> > *intel_encoder)
> >  (int) port, (int) pipe);
> > }
> >
> > -   intel_lpe_audio_notify(dev_priv, NULL, port, pipe, 0, false, 0);
> > +   intel_lpe_audio_notify(dev_priv, NULL, port, pipe, 0, false);
> >  }
> >
> >  /**
> > diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c 
> > b/drivers/gpu/drm/i915/intel_lpe_audio.c
> > index 79b9dca985ff..5a1a37e963f1 100644
> > --- a/drivers/gpu/drm/i915/intel_lpe_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
> > @@ -309,13 +309,14 @@ void intel_lpe_audio_teardown(struct drm_i915_private 
> > *dev_priv)
> >   * @eld : ELD data
> >   * @pipe: pipe id
> >   * @port: port id
> > - * @tmds_clk_speed: tmds clock frequency in Hz
> > + * @ls_clock: Link symbol clock in kHz
> > + * @dp_output: Driving a DP output?
> >   *
> >   * Notify lpe audio driver of eld change.
> >   */
> >  void intel_lpe_audio_notify(struct drm_i915_private *dev_priv,
> > -   void *eld, int port, int pipe, int tmds_clk_speed,
> > -   bool dp_output, int link_rate)
> > +   void *eld, int port, int pipe, int ls_clock,
> > +   bool dp_output)
> >  {
> > unsigned long irq_flags;
> > struct intel_hdmi_lpe_audio_pdata *pdata = NULL;
> > @@ -337,12 +338,8 @@ void intel_lpe_audio_notify(struct drm_i915_private 
> > *dev_priv,
> > pdata->eld.port_id = port;
> > pdata->eld.pipe_id = pipe;
> > pdata->hdmi_connected = true;
> > -

Re: [Intel-gfx] [PATCH 03/11] drm/i915: Stop pretending to mask/unmask LPE audio interrupts

[Ville Syrjälä]

On Tue, Apr 25, 2017 at 07:27:32PM -0500, Pierre-Louis Bossart wrote:
> On 4/25/17 3:27 PM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > vlv_display_irq_postinstall() enables the LPE audio interrupts
> > regardless of whether the LPE audio irq chip has masked/unmasked
> > them. Also the irqchip masking/unmasking doesn't consider the state
> > of the display power well or the device, and hence just leads to
> > dmesg spew when it tries to access the hardware while it's powered
> > down.
> >
> > If the current way works, then we don't need to do anything in the
> > mask/unmask hooks. If it doesn't work, well, then we'd need to properly
> > track whether the irqchip has masked/unmasked the interrupts when
> > we enable display interrupts. And the mask/unmask hooks would need
> > to check whether display interrupts are even enabled before frobbing
> > with he registers.
> >
> > So let's just assume the current way works and neuter the mask/unmask
> > hooks. Also clean up vlv_display_irq_postinstall() a bit and stop
> > it from trying to unmask/enable the LPE C interrupt on VLV since it
> > doesn't exist.
> 
> No objections, I assumed that we did want to update VLV_IMR and VLV_IIR 
> in the mask/unmask, that was the initial recommendation IIRC
> 
> There was also a comment where we removed all tests in 
> vlv_display_irq_postinstall:
> 
>  >> + if (IS_LPE_AUDIO_ENABLED(dev_priv))
>  >> + if (IS_LPE_AUDIO_IRQ_VALID(dev_priv))
>  >
>  >I think both of these checks can be removed. We won't unmask the
>  >interrupts unless lpe is enabled, so the IIR bits will never be set in
>  >that case.

Hmm. Right, so I guess the idea originally was to just enable the
LPE interrupts in IER, but leave them masked in IMR until the
irqchip unmasks them. But the code wasn't actually doing that
because it was appending the bits to 'enable_mask' before it
assigned the value to irq_mask. Hence the interrupts were always
enabled and unmasked.

> 
> 
> 
> 
> >
> > Cc: Takashi Iwai 
> > Cc: Pierre-Louis Bossart 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_irq.c| 15 ++
> >  drivers/gpu/drm/i915/intel_lpe_audio.c | 36 
> > --
> >  2 files changed, 6 insertions(+), 45 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c 
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index fd97fe00cd0d..190f6aa5d15e 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -2953,7 +2953,6 @@ static void vlv_display_irq_postinstall(struct 
> > drm_i915_private *dev_priv)
> > u32 pipestat_mask;
> > u32 enable_mask;
> > enum pipe pipe;
> > -   u32 val;
> >
> > pipestat_mask = PLANE_FLIP_DONE_INT_STATUS_VLV |
> > PIPE_CRC_DONE_INTERRUPT_STATUS;
> > @@ -2964,18 +2963,16 @@ static void vlv_display_irq_postinstall(struct 
> > drm_i915_private *dev_priv)
> >
> > enable_mask = I915_DISPLAY_PORT_INTERRUPT |
> > I915_DISPLAY_PIPE_A_EVENT_INTERRUPT |
> > -   I915_DISPLAY_PIPE_B_EVENT_INTERRUPT;
> > +   I915_DISPLAY_PIPE_B_EVENT_INTERRUPT |
> > +   I915_LPE_PIPE_A_INTERRUPT |
> > +   I915_LPE_PIPE_B_INTERRUPT;
> > +
> > if (IS_CHERRYVIEW(dev_priv))
> > -   enable_mask |= I915_DISPLAY_PIPE_C_EVENT_INTERRUPT;
> > +   enable_mask |= I915_DISPLAY_PIPE_C_EVENT_INTERRUPT |
> > +   I915_LPE_PIPE_C_INTERRUPT;
> >
> > WARN_ON(dev_priv->irq_mask != ~0);
> >
> > -   val = (I915_LPE_PIPE_A_INTERRUPT |
> > -   I915_LPE_PIPE_B_INTERRUPT |
> > -   I915_LPE_PIPE_C_INTERRUPT);
> > -
> > -   enable_mask |= val;
> > -
> > dev_priv->irq_mask = ~enable_mask;
> >
> > GEN5_IRQ_INIT(VLV_, dev_priv->irq_mask, enable_mask);
> > diff --git a/drivers/gpu/drm/i915/intel_lpe_audio.c 
> > b/drivers/gpu/drm/i915/intel_lpe_audio.c
> > index 668f00480d97..292fedf30b00 100644
> > --- a/drivers/gpu/drm/i915/intel_lpe_audio.c
> > +++ b/drivers/gpu/drm/i915/intel_lpe_audio.c
> > @@ -149,44 +149,10 @@ static void lpe_audio_platdev_destroy(struct 
> > drm_i915_private *dev_priv)
> >
> >  static void lpe_audio_irq_unmask(struct irq_data *d)
> >  {
> > -   struct drm_i915_private *dev_priv = d->chip_data;
> > -   unsigned long irqflags;
> > -   u32 val = (I915_LPE_PIPE_A_INTERRUPT |
> > -   I915_LPE_PIPE_B_INTERRUPT);
> > -
> > -   if (IS_CHERRYVIEW(dev_priv))
> > -   val |= I915_LPE_PIPE_C_INTERRUPT;
> > -
> > -   spin_lock_irqsave(_priv->irq_lock, irqflags);
> > -
> > -   dev_priv->irq_mask &= ~val;
> > -   I915_WRITE(VLV_IIR, val);
> > -   I915_WRITE(VLV_IIR, val);
> > -   I915_WRITE(VLV_IMR, dev_priv->irq_mask);
> > -   POSTING_READ(VLV_IMR);
> > -
> > -   spin_unlock_irqrestore(_priv->irq_lock, irqflags);
> >  }
> >
> >  static void 

Re: [Intel-gfx] [PATCH v2] drm/i915: Sanitize engine context sizes

[Tvrtko Ursulin]

On 26/04/2017 13:20, Joonas Lahtinen wrote:

Pre-calculate engine context size based on engine class and device
generation and store it in the engine instance.

v2:
- Squash and get rid of hw_context_size (Chris)

Signed-off-by: Joonas Lahtinen 
Cc: Paulo Zanoni 
Cc: Rodrigo Vivi 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Oscar Mateo 
Cc: Zhenyu Wang 
Cc: intel-gvt-...@lists.freedesktop.org
---
 drivers/gpu/drm/i915/gvt/scheduler.c   |  6 +--
 drivers/gpu/drm/i915/i915_drv.h|  1 -
 drivers/gpu/drm/i915/i915_gem_context.c| 59 +++---
 drivers/gpu/drm/i915/i915_guc_submission.c |  3 +-
 drivers/gpu/drm/i915/i915_reg.h| 10 
 drivers/gpu/drm/i915/intel_engine_cs.c | 78 ++
 drivers/gpu/drm/i915/intel_lrc.c   | 54 +
 drivers/gpu/drm/i915/intel_lrc.h   |  2 -
 drivers/gpu/drm/i915/intel_ringbuffer.h|  7 +--
 9 files changed, 93 insertions(+), 127 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index a77db23..ac538dc 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -69,8 +69,7 @@ static int populate_shadow_context(struct intel_vgpu_workload 
*workload)
gvt_dbg_sched("ring id %d workload lrca %x", ring_id,
workload->ctx_desc.lrca);

-   context_page_num = intel_lr_context_size(
-   gvt->dev_priv->engine[ring_id]);
+   context_page_num = gvt->dev_priv->engine[ring_id]->context_size;

context_page_num = context_page_num >> PAGE_SHIFT;

@@ -333,8 +332,7 @@ static void update_guest_context(struct intel_vgpu_workload 
*workload)
gvt_dbg_sched("ring id %d workload lrca %x\n", ring_id,
workload->ctx_desc.lrca);

-   context_page_num = intel_lr_context_size(
-   gvt->dev_priv->engine[ring_id]);
+   context_page_num = gvt->dev_priv->engine[ring_id]->context_size;

context_page_num = context_page_num >> PAGE_SHIFT;

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 357b6c6..4b54b92 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2359,7 +2359,6 @@ struct drm_i915_private {
 */
struct mutex av_mutex;

-   uint32_t hw_context_size;
struct list_head context_list;

u32 fdi_rx_config;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8bd0c49..b69a026 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -92,33 +92,6 @@

 #define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1

-static int get_context_size(struct drm_i915_private *dev_priv)
-{
-   int ret;
-   u32 reg;
-
-   switch (INTEL_GEN(dev_priv)) {
-   case 6:
-   reg = I915_READ(CXT_SIZE);
-   ret = GEN6_CXT_TOTAL_SIZE(reg) * 64;
-   break;
-   case 7:
-   reg = I915_READ(GEN7_CXT_SIZE);
-   if (IS_HASWELL(dev_priv))
-   ret = HSW_CXT_TOTAL_SIZE;
-   else
-   ret = GEN7_CXT_TOTAL_SIZE(reg) * 64;
-   break;
-   case 8:
-   ret = GEN8_CXT_TOTAL_SIZE;
-   break;
-   default:
-   BUG();
-   }
-
-   return ret;
-}
-
 void i915_gem_context_free(struct kref *ctx_ref)
 {
struct i915_gem_context *ctx = container_of(ctx_ref, typeof(*ctx), ref);
@@ -266,11 +239,12 @@ __create_hw_context(struct drm_i915_private *dev_priv,
list_add_tail(>link, _priv->context_list);
ctx->i915 = dev_priv;

-   if (dev_priv->hw_context_size) {
+   if (dev_priv->engine[RCS]->context_size) {
struct drm_i915_gem_object *obj;
struct i915_vma *vma;

-   obj = alloc_context_obj(dev_priv, dev_priv->hw_context_size);
+   obj = alloc_context_obj(dev_priv,
+   dev_priv->engine[RCS]->context_size);
if (IS_ERR(obj)) {
ret = PTR_ERR(obj);
goto err_out;
@@ -443,21 +417,6 @@ int i915_gem_context_init(struct drm_i915_private 
*dev_priv)
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > INT_MAX);
ida_init(_priv->context_hw_ida);

-   if (i915.enable_execlists) {
-   /* NB: intentionally left blank. We will allocate our own
-* backing objects as we need them, thank you very much */
-   dev_priv->hw_context_size = 0;
-   } else if (HAS_HW_CONTEXTS(dev_priv)) {
-   

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Pre-calculate engine context size

[Chris Wilson]

On Wed, Apr 26, 2017 at 12:43:18PM +, Saarinen, Jani wrote:
> Hi, 
> > -Original Message-
> > From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> > Sent: Wednesday, April 26, 2017 3:36 PM
> > To: Saarinen, Jani ; 
> > intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2]
> > drm/i915: Pre-calculate engine context size
> > 
> > On ke, 2017-04-26 at 10:43 +, Saarinen, Jani wrote:
> > > >
> > > > -Original Message-
> > > > Subject: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2]
> > drm/i915:
> > > > Pre-calculate engine context size
> > > >
> > > > == Series Details ==
> > > >
> > > > Series: series starting with [1/2] drm/i915: Pre-calculate engine
> > > > context size URL   : https://patchwork.freedesktop.org/series/23559/
> > > > State : warning
> > > >
> > > > == Summary ==
> > > >
> > > > Series 23559v1 Series without cover letter
> > > > https://patchwork.freedesktop.org/api/1.0/series/23559/revisions/1/m
> > > > box/
> > > >
> > >
> > > How about trybot first?
> > 
> > What exactly is the point of running CI on intel-gfx traffic if everything 
> > is
> > supposed to be sent to trybot first? Sending trivial series to trybot first 
> > would
> > double the already untolerable latency of the system. intel-gfx is supposed 
> > to be
> Well I am thinking that first most obvious failures are caught by trybot and 
> when 
> passing there then sending for review, this is what eg. Chris is doing a lot. 
> So that trybot serves developers pre-pre-criteria. 
> But agree there is latency is there are work in the queue but not if drm, 
> dif, dinf and pw and clean,
> then is just matter of 10+ minutes. 
> 
> > a place to discuss the patches among the developers, or you think we should
> > have intel-gfx-dev for that and everything but ready-to-merge series are 
> > sent
> > there?
> Well it is up to developers to decide, just saying that if patches are 
> totally bogus, maybe test first 
> not on the list but try-bot list ;)

Don't forget that Joonas also wanted to validate the design choice,
which is something we want to do as early as possible as well. Nearly
complete code is fine for sampling on whether the entire approach is
heading in the right direction. And CI results are useful here as well,
they catch oversights they may escape us mere humans.
-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] ✗ Fi.CI.BAT: failure for drm/i915: Sanitize engine context sizes

[Patchwork]

== Series Details ==

Series: drm/i915: Sanitize engine context sizes
URL   : https://patchwork.freedesktop.org/series/23567/
State : failure

== Summary ==

Series 23567v1 drm/i915: Sanitize engine context sizes
https://patchwork.freedesktop.org/api/1.0/series/23567/revisions/1/mbox/

Test core_auth:
Subgroup basic-auth:
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-bxt-t5700)
Test core_prop_blob:
Subgroup basic:
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-bxt-t5700)
Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-bxt-t5700)
Subgroup basic-subslice-total:
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-bxt-t5700)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-bxt-t5700)
Test drv_module_reload:
Subgroup basic-no-display:
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> FAIL   (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-ilk-650)
pass   -> FAIL   (fi-bdw-gvtdvm)
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> FAIL   (fi-bxt-t5700)
Subgroup basic-reload:
pass   -> FAIL   (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> INCOMPLETE (fi-byt-n2820)
pass   -> DMESG-WARN (fi-ilk-650)
dmesg-warn -> FAIL   (fi-bdw-gvtdvm) fdo#99938
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> INCOMPLETE (fi-byt-j1900)
pass   -> INCOMPLETE (fi-snb-2600)
pass   -> INCOMPLETE (fi-kbl-7500u)
pass   -> INCOMPLETE (fi-snb-2520m)
pass   -> FAIL   (fi-bxt-t5700)
Subgroup basic-reload-final:
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> FAIL   (fi-skl-gvtdvm)
pass   -> DMESG-WARN (fi-ilk-650)
dmesg-warn -> FAIL   (fi-bdw-gvtdvm) fdo#99938
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> FAIL   (fi-bxt-t5700)
Subgroup basic-reload-inject:
dmesg-warn -> PASS   (fi-bdw-gvtdvm) fdo#99938
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-ilk-650)
Test gem_basic:
Subgroup bad-close:
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-skl-gvtdvm)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-kbl-7500u)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-bxt-t5700)
Subgroup create-close:

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915: Pre-calculate engine context size

[Saarinen, Jani]

Hi, 
> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Wednesday, April 26, 2017 3:36 PM
> To: Saarinen, Jani ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2]
> drm/i915: Pre-calculate engine context size
> 
> On ke, 2017-04-26 at 10:43 +, Saarinen, Jani wrote:
> > >
> > > -Original Message-
> > > Subject: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2]
> drm/i915:
> > > Pre-calculate engine context size
> > >
> > > == Series Details ==
> > >
> > > Series: series starting with [1/2] drm/i915: Pre-calculate engine
> > > context size URL   : https://patchwork.freedesktop.org/series/23559/
> > > State : warning
> > >
> > > == Summary ==
> > >
> > > Series 23559v1 Series without cover letter
> > > https://patchwork.freedesktop.org/api/1.0/series/23559/revisions/1/m
> > > box/
> > >
> >
> > How about trybot first?
> 
> What exactly is the point of running CI on intel-gfx traffic if everything is
> supposed to be sent to trybot first? Sending trivial series to trybot first 
> would
> double the already untolerable latency of the system. intel-gfx is supposed 
> to be
Well I am thinking that first most obvious failures are caught by trybot and 
when 
passing there then sending for review, this is what eg. Chris is doing a lot. 
So that trybot serves developers pre-pre-criteria. 
But agree there is latency is there are work in the queue but not if drm, dif, 
dinf and pw and clean,
then is just matter of 10+ minutes. 

> a place to discuss the patches among the developers, or you think we should
> have intel-gfx-dev for that and everything but ready-to-merge series are sent
> there?
Well it is up to developers to decide, just saying that if patches are totally 
bogus, maybe test first 
not on the list but try-bot list ;)

> 
> Regards, Joonas
> --

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: Pre-calculate engine context size

[Joonas Lahtinen]

On ke, 2017-04-26 at 10:43 +, Saarinen, Jani wrote:
> > 
> > -Original Message-
> > Subject: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] 
> > drm/i915:
> > Pre-calculate engine context size
> > 
> > == Series Details ==
> > 
> > Series: series starting with [1/2] drm/i915: Pre-calculate engine context 
> > size
> > URL   : https://patchwork.freedesktop.org/series/23559/
> > State : warning
> > 
> > == Summary ==
> > 
> > Series 23559v1 Series without cover letter
> > https://patchwork.freedesktop.org/api/1.0/series/23559/revisions/1/mbox/
> > 
> > Test drv_module_reload:
> > Subgroup basic-no-display:
> > pass   -> DMESG-WARN (fi-hsw-4770r)
> > pass   -> DMESG-WARN (fi-byt-j1900)
> > pass   -> DMESG-WARN (fi-byt-n2820)
> > pass   -> DMESG-WARN (fi-ivb-3520m)
> > pass   -> DMESG-WARN (fi-ilk-650)
> > pass   -> DMESG-WARN (fi-snb-2520m)
> > pass   -> DMESG-WARN (fi-hsw-4770)
> > pass   -> DMESG-WARN (fi-ivb-3770)
> > pass   -> DMESG-WARN (fi-snb-2600)
> > Subgroup basic-reload:
> > pass   -> DMESG-WARN (fi-hsw-4770r)
> > pass   -> DMESG-WARN (fi-byt-j1900)
> > pass   -> DMESG-WARN (fi-byt-n2820)
> > pass   -> DMESG-WARN (fi-ivb-3520m)
> > pass   -> DMESG-WARN (fi-ilk-650)
> > pass   -> DMESG-WARN (fi-snb-2520m)
> > pass   -> DMESG-WARN (fi-hsw-4770)
> > pass   -> DMESG-WARN (fi-ivb-3770)
> > pass   -> DMESG-WARN (fi-snb-2600)
> > Subgroup basic-reload-final:
> > pass   -> DMESG-WARN (fi-hsw-4770r)
> > pass   -> DMESG-WARN (fi-byt-j1900)
> > pass   -> DMESG-WARN (fi-byt-n2820)
> > pass   -> DMESG-WARN (fi-ivb-3520m)
> > pass   -> DMESG-WARN (fi-ilk-650)
> > pass   -> DMESG-WARN (fi-snb-2520m)
> > pass   -> DMESG-WARN (fi-hsw-4770)
> > pass   -> DMESG-WARN (fi-ivb-3770)
> > pass   -> DMESG-WARN (fi-snb-2600)
> > Subgroup basic-reload-inject:
> > pass   -> DMESG-WARN (fi-hsw-4770r)
> > pass   -> DMESG-WARN (fi-byt-j1900)
> > pass   -> DMESG-WARN (fi-byt-n2820)
> > pass   -> DMESG-WARN (fi-ivb-3520m)
> > pass   -> DMESG-WARN (fi-ilk-650)
> > pass   -> DMESG-WARN (fi-snb-2520m)
> > pass   -> DMESG-WARN (fi-hsw-4770)
> > pass   -> DMESG-WARN (fi-ivb-3770)
> > pass   -> DMESG-WARN (fi-snb-2600)
> > Test gem_exec_suspend:
> > Subgroup basic-s4-devices:
> > pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
> 
> How about trybot first?

What exactly is the point of running CI on intel-gfx traffic if
everything is supposed to be sent to trybot first? Sending trivial
series to trybot first would double the already untolerable latency of
the system. intel-gfx is supposed to be a place to discuss the patches
among the developers, or you think we should have intel-gfx-dev for
that and everything but ready-to-merge series are sent there?

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 1/2] drm: Make fbdev inherit the crtc's initial rotation

[Bastien Nocera]

On Mon, 2017-04-24 at 15:48 +0300, Ville Syrjälä wrote:
> 


> > I've a patch for iio-sensor-proxy which fixes the rotation under
> > Xorg /
> > Wayland when using a desktop environment which honors iio-sensor-
> > proxy's
> > rotation detection:
> > https://github.com/hadess/iio-sensor-proxy/pull/162
> 
> Or is it just this thing that clobbers what the DDX inherited from
> the
> kernel as the initial rotation?

I think it's mostly got to do with the compositor (or X) not knowing
what "normal" or "0 degrees rotation" corresponds to.

I would expect the baseline test for this wouldn't involve iio-sensor-
proxy at all, and boot to the desktop with the expected orientation
showing up in the desktop env/XRandR as "not rotated".

Eg. for the GPD Win which does have this problem, this should appear as
being rotated (image 1):
https://c.slashgear.com/wp-content/uploads/2016/11/gpd-win-book-2.jpg
But not this (image 2):
https://c.slashgear.com/wp-content/uploads/2016/11/gpd-win-0-800x420.jpg

After that, the problem is whether the accelerometer is mounted the
same way as the "non-rotated screen" (option 2), or the "non-rotated
screen" (option 1), which would show what quirking is needed.

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

Re: [Intel-gfx] [PATCH 07/27] drm/i915: Squash repeated awaits on the same fence

[Chris Wilson]

On Wed, Apr 26, 2017 at 01:13:41PM +0100, Tvrtko Ursulin wrote:
> 
> On 26/04/2017 12:18, Chris Wilson wrote:
> >On Wed, Apr 26, 2017 at 11:54:08AM +0100, Tvrtko Ursulin wrote:
> >+/* struct intel_timeline_sync is a layer of a radixtree that maps a u64 
> >fence
> >+ * context id to the last u32 fence seqno waited upon from that context.
> >+ * Unlike lib/radixtree it uses a parent pointer that allows traversal 
> >back to
> >+ * the root. This allows us to access the whole tree via a single 
> >pointer
> >+ * to the most recently used layer. We expect fence contexts to be dense
> >+ * and most reuse to be on the same i915_gem_context but on neighbouring
> >+ * engines (i.e. on adjacent contexts) and reuse the same leaf, a very
> >+ * effective lookup cache. If the new lookup is not on the same leaf, we
> >+ * expect it to be on the neighbouring branch.
> >+ *
> >+ * A leaf holds an array of u32 seqno, and has height 0. The bitmap 
> >field
> >+ * allows us to store whether a particular seqno is valid (i.e. allows 
> >us
> >+ * to distinguish unset from 0).
> >+ *
> >+ * A branch holds an array of layer pointers, and has height > 0, and 
> >always
> >+ * has at least 2 layers (either branches or leaves) below it.
> >+ *
> >+ */
> 
> @_@ :)
> 
> Ok, so a map of u64 to u32. We can't use IDR or radixtree directly
> because of u64 keys. :( How about a hash table? It would be much
> simpler to review. :) Seriously, if it would perform close enough it
> would be a much much simpler implementation.
> >>>
> >>>You want a resizable hashtable. rht is appallingly slow, so you want a
> >>>custom resizeable ht. They are not as simple as this codewise ;)
> >>>(Plus a compressed radixtree is part of my plan for scalability
> >>>improvements for struct reservation_object.)
> >>
> >>Why resizable? I was thinking a normal one. If at any given time we
> >>have an active set of contexts, or at least lookups are as you say
> >>below, to neighbouring contexts, that would mean we are talking
> >>about lookups to different hash buckets.  And for the typical
> >>working set we would expect many collisions so longer lists in each
> >>bucket? So maybe NUM_ENGINES * some typical load constant number
> >>buckets would not be that bad?
> >
> >Consider a long running display server that will accumulate 10,000s of
> >thousands of clients in its lifetime, each with their own contents that
> >get shared by passing around fences/framebuffers. (Or on a shorter scale
> >any of the context stress tests in igt.) Due to the non-recycling of the
> >context ids, we can grow to very large tables - but we have no knowledge
> >of what contexts are no longer required.
> >
> >To compensate we need to occasionally prune the sync points. For a ht we
> >could just scrap it, For an idr, we could store last use and delete
> >stale leaves.
> 
> Hm, pruning yes.. but you don't have pruning in this patch either.
> So that's something which needs to be addressed either way.

I know, review is great for hindsight. The iterator/remove for the
compressed idr is going to be on the uglier side of the insertion. Ugly
enough to be a seperate patch.
 
> >But first we have a question of how many buckets do we give the static
> >ht? Most processes will be sharing between 2 contexts (render context,
> >presentation context) except for a display server who may have 10-100 of
> >clients - and possibly where eliminating repeated syncs is going to be
> >most valuable. That suggests 256 buckets for every timeline (assuming
> >just a pair of engines across shared contexts). Overkill for the
> >majority, and going to be miserable in stress tests.
> >
> >Finally what do you store in the ht? Fences are the obvious candidate,
> >but need reaping. Or you just create a ht for the request and only
> >squash repeated fences inside a single request - that doesn't benefit
> >from timeline tracking and squashing between requests (but does avoid
> >keeping fences around forever). Hence why I went with tracking seqno. To
> >avoid allocations for the ht nodes, we could create an open-addressed ht
> >with the {context, seqno} embedded in it. It would be efficient, but
> >needs online resizing and is a fair chunk of new code.
> 
> I was thinking of exactly the same thing as this patch does, u64
> context id as key, u32 seqnos (wrapped in a container with
> hlist_node).

Hmm, a hashed radixtree. I did read something about a hybrid approach.

> Ok, so the key is pruning to keep the display server scenario in check.
> 
> Free the key from i915_fence_release?

Too early, it's the timeline (and syncs along it) that's interesting.
For our contexts, we can hook into context-close, but we still have some
foreign dma-fence-contexts to worry about. I was thinking of walking all
timelines from the idle_worker. And possibly forcibly prune across
suspend.
-Chris

-- 
Chris Wilson, 

[Intel-gfx] [PATCH v2] drm/i915: Sanitize engine context sizes

[Joonas Lahtinen]

Pre-calculate engine context size based on engine class and device
generation and store it in the engine instance.

v2:
- Squash and get rid of hw_context_size (Chris)

Signed-off-by: Joonas Lahtinen 
Cc: Paulo Zanoni 
Cc: Rodrigo Vivi 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Oscar Mateo 
Cc: Zhenyu Wang 
Cc: intel-gvt-...@lists.freedesktop.org
---
 drivers/gpu/drm/i915/gvt/scheduler.c   |  6 +--
 drivers/gpu/drm/i915/i915_drv.h|  1 -
 drivers/gpu/drm/i915/i915_gem_context.c| 59 +++---
 drivers/gpu/drm/i915/i915_guc_submission.c |  3 +-
 drivers/gpu/drm/i915/i915_reg.h| 10 
 drivers/gpu/drm/i915/intel_engine_cs.c | 78 ++
 drivers/gpu/drm/i915/intel_lrc.c   | 54 +
 drivers/gpu/drm/i915/intel_lrc.h   |  2 -
 drivers/gpu/drm/i915/intel_ringbuffer.h|  7 +--
 9 files changed, 93 insertions(+), 127 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index a77db23..ac538dc 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -69,8 +69,7 @@ static int populate_shadow_context(struct intel_vgpu_workload 
*workload)
gvt_dbg_sched("ring id %d workload lrca %x", ring_id,
workload->ctx_desc.lrca);
 
-   context_page_num = intel_lr_context_size(
-   gvt->dev_priv->engine[ring_id]);
+   context_page_num = gvt->dev_priv->engine[ring_id]->context_size;
 
context_page_num = context_page_num >> PAGE_SHIFT;
 
@@ -333,8 +332,7 @@ static void update_guest_context(struct intel_vgpu_workload 
*workload)
gvt_dbg_sched("ring id %d workload lrca %x\n", ring_id,
workload->ctx_desc.lrca);
 
-   context_page_num = intel_lr_context_size(
-   gvt->dev_priv->engine[ring_id]);
+   context_page_num = gvt->dev_priv->engine[ring_id]->context_size;
 
context_page_num = context_page_num >> PAGE_SHIFT;
 
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 357b6c6..4b54b92 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2359,7 +2359,6 @@ struct drm_i915_private {
 */
struct mutex av_mutex;
 
-   uint32_t hw_context_size;
struct list_head context_list;
 
u32 fdi_rx_config;
diff --git a/drivers/gpu/drm/i915/i915_gem_context.c 
b/drivers/gpu/drm/i915/i915_gem_context.c
index 8bd0c49..b69a026 100644
--- a/drivers/gpu/drm/i915/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/i915_gem_context.c
@@ -92,33 +92,6 @@
 
 #define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
 
-static int get_context_size(struct drm_i915_private *dev_priv)
-{
-   int ret;
-   u32 reg;
-
-   switch (INTEL_GEN(dev_priv)) {
-   case 6:
-   reg = I915_READ(CXT_SIZE);
-   ret = GEN6_CXT_TOTAL_SIZE(reg) * 64;
-   break;
-   case 7:
-   reg = I915_READ(GEN7_CXT_SIZE);
-   if (IS_HASWELL(dev_priv))
-   ret = HSW_CXT_TOTAL_SIZE;
-   else
-   ret = GEN7_CXT_TOTAL_SIZE(reg) * 64;
-   break;
-   case 8:
-   ret = GEN8_CXT_TOTAL_SIZE;
-   break;
-   default:
-   BUG();
-   }
-
-   return ret;
-}
-
 void i915_gem_context_free(struct kref *ctx_ref)
 {
struct i915_gem_context *ctx = container_of(ctx_ref, typeof(*ctx), ref);
@@ -266,11 +239,12 @@ __create_hw_context(struct drm_i915_private *dev_priv,
list_add_tail(>link, _priv->context_list);
ctx->i915 = dev_priv;
 
-   if (dev_priv->hw_context_size) {
+   if (dev_priv->engine[RCS]->context_size) {
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
 
-   obj = alloc_context_obj(dev_priv, dev_priv->hw_context_size);
+   obj = alloc_context_obj(dev_priv,
+   dev_priv->engine[RCS]->context_size);
if (IS_ERR(obj)) {
ret = PTR_ERR(obj);
goto err_out;
@@ -443,21 +417,6 @@ int i915_gem_context_init(struct drm_i915_private 
*dev_priv)
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > INT_MAX);
ida_init(_priv->context_hw_ida);
 
-   if (i915.enable_execlists) {
-   /* NB: intentionally left blank. We will allocate our own
-* backing objects as we need them, thank you very much */
-   dev_priv->hw_context_size = 0;
-   } else if (HAS_HW_CONTEXTS(dev_priv)) {
-   dev_priv->hw_context_size =
-

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Make get_initial_plane_config also get the initial rotation config

[Bastien Nocera]

On Sun, 2017-04-23 at 18:11 +0200, Hans de Goede wrote:
> From: Ville Syrjala 

> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 344f238..63623dd 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -418,6 +418,7 @@ struct intel_initial_plane_config {
>   unsigned int tiling;
>   int size;
>   u32 base;
> + uint8_t rotation;

Mentioning what this is (DRM_ROTATE_* or something else) is even more
important here.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/fb-helper: Make fbdev inherit the crtc's rotation

[Bastien Nocera]

On Sun, 2017-04-23 at 18:11 +0200, Hans de Goede wrote:
> From: Ville Syrjala 
> 
> If a connector added through drm_fb_helper_add_one_connector() has
> a crtc attached and that crtc has a rotation configured make the
> fbdev inherit the crtc's rotation.
> 
> This is useful on e.g. some tablets which have their lcd panel
> mounted
> upside down, which before this commit would result in the kernel boot
> messages switching from being shown the right way up in efifb to
> being
> shown upside down as soon as a native kms driver loads.
> 
> BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=94894
> Cc: Ville Syrjala 
> [hdego...@redhat.com: Split the drm/fb-helper bits out of Ville's
>  "drm/fb-helper: Inherit rotation wip" patch]
> Tested-by: Hans de Goede 
> Signed-off-by: Hans de Goede 
> ---
>  drivers/gpu/drm/drm_fb_helper.c | 51
> ++---
>  include/drm/drm_fb_helper.h |  2 ++
>  2 files changed, 50 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_helper.c
> b/drivers/gpu/drm/drm_fb_helper.c
> index 324a688..c97e00ab 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -159,6 +159,8 @@ int drm_fb_helper_add_one_connector(struct
> drm_fb_helper *fb_helper, struct drm_
>  {
>   struct drm_fb_helper_connector **temp;
>   struct drm_fb_helper_connector *fb_helper_connector;
> + struct drm_crtc *crtc = connector->encoder ?
> + connector->encoder->crtc : NULL;
>  
>   if (!drm_fbdev_emulation)
>   return 0;
> @@ -180,6 +182,11 @@ int drm_fb_helper_add_one_connector(struct
> drm_fb_helper *fb_helper, struct drm_
>  
>   drm_connector_reference(connector);
>   fb_helper_connector->connector = connector;
> + if (crtc && crtc->primary->state)
> + fb_helper_connector->rotation = crtc->primary-
> >state->rotation;
> + if (!fb_helper_connector->rotation)
> + fb_helper_connector->rotation = DRM_ROTATE_0;

That's equivalent to:
if (fb_helper_connector->rotation = DRM_ROTATE_0)
   fb_helper_connector->rotation = DRM_ROTATE_0;

Maybe:
if (crtc && crtc->primary->state)
   ...
else
   ...->rotation = DRM_ROTATE_0;
would be clearer? Or simply omit it if the connector is zero'ed.   


> diff --git a/include/drm/drm_fb_helper.h
> b/include/drm/drm_fb_helper.h
> index 6f5aceb..19fc313 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -48,6 +48,7 @@ struct drm_fb_helper_crtc {
>   struct drm_mode_set mode_set;
>   struct drm_display_mode *desired_mode;
>   int x, y;
> + uint8_t rotation;
>  };
>  
>  /**
> @@ -159,6 +160,7 @@ struct drm_fb_helper_funcs {
>  
>  struct drm_fb_helper_connector {
>   struct drm_connector *connector;
> + uint8_t rotation;

In both those cases, I'd add a mention of the type of enum/mask etc.
for the rotation, for example:
uint8_t rotation; /* DRM_ROTATE_* */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 07/27] drm/i915: Squash repeated awaits on the same fence

[Tvrtko Ursulin]

On 26/04/2017 12:18, Chris Wilson wrote:

On Wed, Apr 26, 2017 at 11:54:08AM +0100, Tvrtko Ursulin wrote:

+/* struct intel_timeline_sync is a layer of a radixtree that maps a u64 fence
+ * context id to the last u32 fence seqno waited upon from that context.
+ * Unlike lib/radixtree it uses a parent pointer that allows traversal back to
+ * the root. This allows us to access the whole tree via a single pointer
+ * to the most recently used layer. We expect fence contexts to be dense
+ * and most reuse to be on the same i915_gem_context but on neighbouring
+ * engines (i.e. on adjacent contexts) and reuse the same leaf, a very
+ * effective lookup cache. If the new lookup is not on the same leaf, we
+ * expect it to be on the neighbouring branch.
+ *
+ * A leaf holds an array of u32 seqno, and has height 0. The bitmap field
+ * allows us to store whether a particular seqno is valid (i.e. allows us
+ * to distinguish unset from 0).
+ *
+ * A branch holds an array of layer pointers, and has height > 0, and always
+ * has at least 2 layers (either branches or leaves) below it.
+ *
+ */


@_@ :)

Ok, so a map of u64 to u32. We can't use IDR or radixtree directly
because of u64 keys. :( How about a hash table? It would be much
simpler to review. :) Seriously, if it would perform close enough it
would be a much much simpler implementation.


You want a resizable hashtable. rht is appallingly slow, so you want a
custom resizeable ht. They are not as simple as this codewise ;)
(Plus a compressed radixtree is part of my plan for scalability
improvements for struct reservation_object.)


Why resizable? I was thinking a normal one. If at any given time we
have an active set of contexts, or at least lookups are as you say
below, to neighbouring contexts, that would mean we are talking
about lookups to different hash buckets.  And for the typical
working set we would expect many collisions so longer lists in each
bucket? So maybe NUM_ENGINES * some typical load constant number
buckets would not be that bad?


Consider a long running display server that will accumulate 10,000s of
thousands of clients in its lifetime, each with their own contents that
get shared by passing around fences/framebuffers. (Or on a shorter scale
any of the context stress tests in igt.) Due to the non-recycling of the
context ids, we can grow to very large tables - but we have no knowledge
of what contexts are no longer required.

To compensate we need to occasionally prune the sync points. For a ht we
could just scrap it, For an idr, we could store last use and delete
stale leaves.


Hm, pruning yes.. but you don't have pruning in this patch either. So 
that's something which needs to be addressed either way.



But first we have a question of how many buckets do we give the static
ht? Most processes will be sharing between 2 contexts (render context,
presentation context) except for a display server who may have 10-100 of
clients - and possibly where eliminating repeated syncs is going to be
most valuable. That suggests 256 buckets for every timeline (assuming
just a pair of engines across shared contexts). Overkill for the
majority, and going to be miserable in stress tests.

Finally what do you store in the ht? Fences are the obvious candidate,
but need reaping. Or you just create a ht for the request and only
squash repeated fences inside a single request - that doesn't benefit
from timeline tracking and squashing between requests (but does avoid
keeping fences around forever). Hence why I went with tracking seqno. To
avoid allocations for the ht nodes, we could create an open-addressed ht
with the {context, seqno} embedded in it. It would be efficient, but
needs online resizing and is a fair chunk of new code.


I was thinking of exactly the same thing as this patch does, u64 context 
id as key, u32 seqnos (wrapped in a container with hlist_node).


Ok, so the key is pruning to keep the display server scenario in check.

Free the key from i915_fence_release?

Regards,

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

Re: [Intel-gfx] [PATCH 07/27] drm/i915: Squash repeated awaits on the same fence

[Chris Wilson]

On Wed, Apr 26, 2017 at 11:54:08AM +0100, Tvrtko Ursulin wrote:
> 
> On 26/04/2017 11:38, Chris Wilson wrote:
> >On Wed, Apr 26, 2017 at 11:20:16AM +0100, Tvrtko Ursulin wrote:
> >>
> >>On 19/04/2017 10:41, Chris Wilson wrote:
> >>>Track the latest fence waited upon on each context, and only add a new
> >>>asynchronous wait if the new fence is more recent than the recorded
> >>>fence for that context. This requires us to filter out unordered
> >>>timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
> >>>absence of a universal identifier, we have to use our own
> >>>i915->mm.unordered_timeline token.
> >>>
> >>>v2: Throw around the debug crutches
> >>>v3: Inline the likely case of the pre-allocation cache being full.
> >>>v4: Drop the pre-allocation support, we can lose the most recent fence
> >>>in case of allocation failure -- it just means we may emit more awaits
> >>>than strictly necessary but will not break.
> >>>v5: Trim allocation size for leaf nodes, they only need an array of u32
> >>>not pointers.
> >>>
> >>>Signed-off-by: Chris Wilson 
> >>>Cc: Tvrtko Ursulin 
> >>>Cc: Joonas Lahtinen 
> >>>---
> >>>drivers/gpu/drm/i915/i915_gem_request.c|  67 +++---
> >>>drivers/gpu/drm/i915/i915_gem_timeline.c   | 260 
> >>>+
> >>>drivers/gpu/drm/i915/i915_gem_timeline.h   |  14 ++
> >>>drivers/gpu/drm/i915/selftests/i915_gem_timeline.c | 123 ++
> >>>.../gpu/drm/i915/selftests/i915_mock_selftests.h   |   1 +
> >>>5 files changed, 438 insertions(+), 27 deletions(-)
> >>>create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
> >>>
> >>>diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> >>>b/drivers/gpu/drm/i915/i915_gem_request.c
> >>>index 97c07986b7c1..fb6c31ba3ef9 100644
> >>>--- a/drivers/gpu/drm/i915/i915_gem_request.c
> >>>+++ b/drivers/gpu/drm/i915/i915_gem_request.c
> >>>@@ -730,9 +730,7 @@ int
> >>>i915_gem_request_await_dma_fence(struct drm_i915_gem_request *req,
> >>>struct dma_fence *fence)
> >>>{
> >>>-  struct dma_fence_array *array;
> >>>   int ret;
> >>>-  int i;
> >>>
> >>>   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
> >>>   return 0;
> >>>@@ -744,39 +742,54 @@ i915_gem_request_await_dma_fence(struct 
> >>>drm_i915_gem_request *req,
> >>>   if (fence->context == req->fence.context)
> >>>   return 0;
> >>>
> >>>-  if (dma_fence_is_i915(fence))
> >>>-  return i915_gem_request_await_request(req, to_request(fence));
> >>>+  /* Squash repeated waits to the same timelines, picking the latest */
> >>>+  if (fence->context != req->i915->mm.unordered_timeline &&
> >>>+  intel_timeline_sync_get(req->timeline,
> >>>+  fence->context, fence->seqno))
> >>
> >>Function name is non-intuitive to me. It doesn't seem to get
> >>anything, but is more like query? Since it ends up with
> >>i915_seqno_passed, maybe intel_timeline_sync_is_newer/older ? (give
> >>or take)
> >
> >_get was choosen as the partner for _set, which seemed to make sense.
> >Keep intel_timeline_sync_set() and replace _get with
> >intel_timeline_sync_passed() ?
> >intel_timeline_sync_is_later() ?
> 
> Both are better in my opinion. _get just makes it sounds like it is
> returning something from the object, which it is not. So whichever
> you prefer.
> 
> >>>diff --git a/drivers/gpu/drm/i915/i915_gem_timeline.c 
> >>>b/drivers/gpu/drm/i915/i915_gem_timeline.c
> >>>index b596ca7ee058..f2b734dda895 100644
> >>>--- a/drivers/gpu/drm/i915/i915_gem_timeline.c
> >>>+++ b/drivers/gpu/drm/i915/i915_gem_timeline.c
> >>>@@ -24,6 +24,254 @@
> >>>
> >>>#include "i915_drv.h"
> >>>
> >>>+#define NSYNC 16
> >>>+#define SHIFT ilog2(NSYNC)
> >>>+#define MASK (NSYNC - 1)
> >>>+
> >>>+/* struct intel_timeline_sync is a layer of a radixtree that maps a u64 
> >>>fence
> >>>+ * context id to the last u32 fence seqno waited upon from that context.
> >>>+ * Unlike lib/radixtree it uses a parent pointer that allows traversal 
> >>>back to
> >>>+ * the root. This allows us to access the whole tree via a single pointer
> >>>+ * to the most recently used layer. We expect fence contexts to be dense
> >>>+ * and most reuse to be on the same i915_gem_context but on neighbouring
> >>>+ * engines (i.e. on adjacent contexts) and reuse the same leaf, a very
> >>>+ * effective lookup cache. If the new lookup is not on the same leaf, we
> >>>+ * expect it to be on the neighbouring branch.
> >>>+ *
> >>>+ * A leaf holds an array of u32 seqno, and has height 0. The bitmap field
> >>>+ * allows us to store whether a particular seqno is valid (i.e. allows us
> >>>+ * to distinguish unset from 0).
> >>>+ *
> >>>+ * A branch holds an array of layer pointers, and has height > 0, and 
> >>>always
> >>>+ * has at least 2 layers (either branches or leaves) below it.
> >>>+ *
> >>>+ */
> >>
> >>@_@ :)
> >>
> >>Ok, so a map of 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Do a quick check on whether the fence is already signaled first

[Patchwork]

== Series Details ==

Series: drm/i915: Do a quick check on whether the fence is already signaled 
first
URL   : https://patchwork.freedesktop.org/series/23561/
State : success

== Summary ==

Series 23561v1 drm/i915: Do a quick check on whether the fence is already 
signaled first
https://patchwork.freedesktop.org/api/1.0/series/23561/revisions/1/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:430s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:424s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:572s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:507s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:578s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:486s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:417s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:404s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:416s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:497s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:468s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:453s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:563s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:449s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:572s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:463s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:494s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:528s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:399s
fi-byt-j1900 failed to collect. IGT log at Patchwork_4555/fi-byt-j1900/igt.log

a7faf88a24720743c713acdbaaa15dbb9f60d79e drm-tip: 2017y-04m-26d-10h-04m-44s UTC 
integration manifest
ccf8653 drm/i915: Do a quick check on whether the fence is already signaled 
first

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4555/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Do a quick check on whether the fence is already signaled first

[Tvrtko Ursulin]

On 26/04/2017 11:48, Chris Wilson wrote:

On Wed, Apr 26, 2017 at 11:43:03AM +0100, Tvrtko Ursulin wrote:


On 26/04/2017 11:15, Chris Wilson wrote:

Now that we try to signal the fence from inside the interrupt handler,
when we reach the signaler thread, the fence is most likely already
signaled. Skip manipulating the bottom-half locks if this is so.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
drivers/gpu/drm/i915/intel_breadcrumbs.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 8f52fd5f6102..5f79c8135b3f 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -616,9 +616,12 @@ static int intel_breadcrumbs_signaler(void *arg)
request = i915_gem_request_get_rcu(request);
rcu_read_unlock();
if (signal_complete(request)) {
-   local_bh_disable();
-   dma_fence_signal(>fence);
-   local_bh_enable(); /* kick start the tasklets */
+   if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
+ >fence.flags)) {
+   local_bh_disable();
+   dma_fence_signal(>fence);
+   local_bh_enable(); /* kick start the tasklet */
+   }

spin_lock_irq(>rb_lock);




What are you referring to by "bottom-half locks" in the commit msg?
AFAICS it would only skip kicking the tasklets with this change.
That may be worth it, I haven't measured, but I don't see a
difference wrt any locks.


It's just the preempt enable/disable pair plus the function call


Okay then, with a corrected commit message:

Reviewed-by: Tvrtko Ursulin 


In fact we could change this to:

if (!dma_fence_signal(...)) {
local_bh_disable();
local_bh_enable();
}

If we wanted to avoid touching the flags directly, but then would
have a function call..


Yeah, plus that looks ridiculous ;)


Hey, we can always hide it in a wrapper! :))

Regards,

Tvrtko


The biggest cost in the signaler thread is going to sleep.
-Chris


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

Re: [Intel-gfx] [PATCH] drm/i915: Skip waking the signaler when enabling before request submission

[Chris Wilson]

On Wed, Apr 26, 2017 at 11:35:33AM +0100, Tvrtko Ursulin wrote:
> 
> On 26/04/2017 09:06, Chris Wilson wrote:
> >If we are enabling the breadcrumbs signaling prior to submitting the
> >request, we know that we cannot have missed the interrupt and can
> >therefore skip immediately waking the signaler to check.
> >
> >This reduces a significant chunk of the __i915_gem_request_submit()
> >overhead for inter-engine synchronisation, for example in gem_exec_whisper.
> >
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> >---
> > drivers/gpu/drm/i915/i915_gem_request.c| 4 ++--
> > drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
> > drivers/gpu/drm/i915/intel_breadcrumbs.c   | 7 ---
> > drivers/gpu/drm/i915/intel_ringbuffer.h| 3 ++-
> > 4 files changed, 9 insertions(+), 7 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> >b/drivers/gpu/drm/i915/i915_gem_request.c
> >index 8bbec19e267a..7b9a509f00f3 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_request.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_request.c
> >@@ -61,7 +61,7 @@ static bool i915_fence_enable_signaling(struct dma_fence 
> >*fence)
> > if (i915_fence_signaled(fence))
> > return false;
> >
> >-intel_engine_enable_signaling(to_request(fence));
> >+intel_engine_enable_signaling(to_request(fence), true);
> > return true;
> > }
> >
> >@@ -448,7 +448,7 @@ void __i915_gem_request_submit(struct 
> >drm_i915_gem_request *request)
> > spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
> > request->global_seqno = seqno;
> > if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
> >-intel_engine_enable_signaling(request);
> >+intel_engine_enable_signaling(request, false);
> > spin_unlock(>lock);
> >
> > engine->emit_breadcrumb(request,
> >diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> >b/drivers/gpu/drm/i915/i915_guc_submission.c
> >index a4eca6ac449b..7ccb22709efb 100644
> >--- a/drivers/gpu/drm/i915/i915_guc_submission.c
> >+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> >@@ -649,7 +649,7 @@ static void nested_enable_signaling(struct 
> >drm_i915_gem_request *rq)
> > trace_dma_fence_enable_signal(>fence);
> >
> > spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
> >-intel_engine_enable_signaling(rq);
> >+intel_engine_enable_signaling(rq, true);
> > spin_unlock(>lock);
> > }
> >
> >diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
> >b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >index 0839f928bc57..8f52fd5f6102 100644
> >--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >@@ -683,12 +683,13 @@ static int intel_breadcrumbs_signaler(void *arg)
> > return 0;
> > }
> >
> >-void intel_engine_enable_signaling(struct drm_i915_gem_request *request)
> >+void intel_engine_enable_signaling(struct drm_i915_gem_request *request,
> >+   bool wakeup)
> > {
> > struct intel_engine_cs *engine = request->engine;
> > struct intel_breadcrumbs *b = >breadcrumbs;
> > struct rb_node *parent, **p;
> >-bool first, wakeup;
> >+bool first;
> > u32 seqno;
> >
> > /* Note that we may be called from an interrupt handler on another
> >@@ -721,7 +722,7 @@ void intel_engine_enable_signaling(struct 
> >drm_i915_gem_request *request)
> >  * If we are the oldest waiter, enable the irq (after which we
> >  * must double check that the seqno did not complete).
> >  */
> >-wakeup = __intel_engine_add_wait(engine, >signaling.wait);
> >+wakeup &= __intel_engine_add_wait(engine, >signaling.wait);
> >
> > /* Now insert ourselves into the retirement ordered list of signals
> >  * on this engine. We track the oldest seqno as that will be the
> >diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
> >b/drivers/gpu/drm/i915/intel_ringbuffer.h
> >index 3f7d5666bcf6..de5b968f508a 100644
> >--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
> >+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
> >@@ -672,7 +672,8 @@ bool intel_engine_add_wait(struct intel_engine_cs 
> >*engine,
> >struct intel_wait *wait);
> > void intel_engine_remove_wait(struct intel_engine_cs *engine,
> >   struct intel_wait *wait);
> >-void intel_engine_enable_signaling(struct drm_i915_gem_request *request);
> >+void intel_engine_enable_signaling(struct drm_i915_gem_request *request,
> >+   bool wakeup);
> > void intel_engine_cancel_signaling(struct drm_i915_gem_request *request);
> >
> > static inline bool intel_engine_has_waiter(const struct intel_engine_cs 
> > *engine)
> >
> 
> Reviewed-by: Tvrtko Ursulin 

Ta, pushed this one as it's been the only thing to give a clear
improvement to gem_exec_whisper + execlist in yonks :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [Intel-gfx] [PATCH 07/27] drm/i915: Squash repeated awaits on the same fence

[Tvrtko Ursulin]

On 26/04/2017 11:38, Chris Wilson wrote:

On Wed, Apr 26, 2017 at 11:20:16AM +0100, Tvrtko Ursulin wrote:


On 19/04/2017 10:41, Chris Wilson wrote:

Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
absence of a universal identifier, we have to use our own
i915->mm.unordered_timeline token.

v2: Throw around the debug crutches
v3: Inline the likely case of the pre-allocation cache being full.
v4: Drop the pre-allocation support, we can lose the most recent fence
in case of allocation failure -- it just means we may emit more awaits
than strictly necessary but will not break.
v5: Trim allocation size for leaf nodes, they only need an array of u32
not pointers.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
drivers/gpu/drm/i915/i915_gem_request.c|  67 +++---
drivers/gpu/drm/i915/i915_gem_timeline.c   | 260 +
drivers/gpu/drm/i915/i915_gem_timeline.h   |  14 ++
drivers/gpu/drm/i915/selftests/i915_gem_timeline.c | 123 ++
.../gpu/drm/i915/selftests/i915_mock_selftests.h   |   1 +
5 files changed, 438 insertions(+), 27 deletions(-)
create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 97c07986b7c1..fb6c31ba3ef9 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -730,9 +730,7 @@ int
i915_gem_request_await_dma_fence(struct drm_i915_gem_request *req,
 struct dma_fence *fence)
{
-   struct dma_fence_array *array;
int ret;
-   int i;

if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
return 0;
@@ -744,39 +742,54 @@ i915_gem_request_await_dma_fence(struct 
drm_i915_gem_request *req,
if (fence->context == req->fence.context)
return 0;

-   if (dma_fence_is_i915(fence))
-   return i915_gem_request_await_request(req, to_request(fence));
+   /* Squash repeated waits to the same timelines, picking the latest */
+   if (fence->context != req->i915->mm.unordered_timeline &&
+   intel_timeline_sync_get(req->timeline,
+   fence->context, fence->seqno))


Function name is non-intuitive to me. It doesn't seem to get
anything, but is more like query? Since it ends up with
i915_seqno_passed, maybe intel_timeline_sync_is_newer/older ? (give
or take)


_get was choosen as the partner for _set, which seemed to make sense.
Keep intel_timeline_sync_set() and replace _get with
intel_timeline_sync_passed() ?
intel_timeline_sync_is_later() ?


Both are better in my opinion. _get just makes it sounds like it is 
returning something from the object, which it is not. So whichever you 
prefer.



diff --git a/drivers/gpu/drm/i915/i915_gem_timeline.c 
b/drivers/gpu/drm/i915/i915_gem_timeline.c
index b596ca7ee058..f2b734dda895 100644
--- a/drivers/gpu/drm/i915/i915_gem_timeline.c
+++ b/drivers/gpu/drm/i915/i915_gem_timeline.c
@@ -24,6 +24,254 @@

#include "i915_drv.h"

+#define NSYNC 16
+#define SHIFT ilog2(NSYNC)
+#define MASK (NSYNC - 1)
+
+/* struct intel_timeline_sync is a layer of a radixtree that maps a u64 fence
+ * context id to the last u32 fence seqno waited upon from that context.
+ * Unlike lib/radixtree it uses a parent pointer that allows traversal back to
+ * the root. This allows us to access the whole tree via a single pointer
+ * to the most recently used layer. We expect fence contexts to be dense
+ * and most reuse to be on the same i915_gem_context but on neighbouring
+ * engines (i.e. on adjacent contexts) and reuse the same leaf, a very
+ * effective lookup cache. If the new lookup is not on the same leaf, we
+ * expect it to be on the neighbouring branch.
+ *
+ * A leaf holds an array of u32 seqno, and has height 0. The bitmap field
+ * allows us to store whether a particular seqno is valid (i.e. allows us
+ * to distinguish unset from 0).
+ *
+ * A branch holds an array of layer pointers, and has height > 0, and always
+ * has at least 2 layers (either branches or leaves) below it.
+ *
+ */


@_@ :)

Ok, so a map of u64 to u32. We can't use IDR or radixtree directly
because of u64 keys. :( How about a hash table? It would be much
simpler to review. :) Seriously, if it would perform close enough it
would be a much much simpler implementation.


You want a resizable hashtable. rht is appallingly slow, so you want a
custom resizeable ht. They are not as simple as this codewise ;)
(Plus a compressed radixtree is part of my plan for scalability
improvements for struct reservation_object.)


Why resizable? I was 

Re: [Intel-gfx] [PATCH] drm/i915: Do a quick check on whether the fence is already signaled first

[Chris Wilson]

On Wed, Apr 26, 2017 at 11:43:03AM +0100, Tvrtko Ursulin wrote:
> 
> On 26/04/2017 11:15, Chris Wilson wrote:
> >Now that we try to signal the fence from inside the interrupt handler,
> >when we reach the signaler thread, the fence is most likely already
> >signaled. Skip manipulating the bottom-half locks if this is so.
> >
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> >---
> > drivers/gpu/drm/i915/intel_breadcrumbs.c | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
> >b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >index 8f52fd5f6102..5f79c8135b3f 100644
> >--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
> >@@ -616,9 +616,12 @@ static int intel_breadcrumbs_signaler(void *arg)
> > request = i915_gem_request_get_rcu(request);
> > rcu_read_unlock();
> > if (signal_complete(request)) {
> >-local_bh_disable();
> >-dma_fence_signal(>fence);
> >-local_bh_enable(); /* kick start the tasklets */
> >+if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
> >+  >fence.flags)) {
> >+local_bh_disable();
> >+dma_fence_signal(>fence);
> >+local_bh_enable(); /* kick start the tasklet */
> >+}
> >
> > spin_lock_irq(>rb_lock);
> >
> >
> 
> What are you referring to by "bottom-half locks" in the commit msg?
> AFAICS it would only skip kicking the tasklets with this change.
> That may be worth it, I haven't measured, but I don't see a
> difference wrt any locks.

It's just the preempt enable/disable pair plus the function call
 
> In fact we could change this to:
> 
>   if (!dma_fence_signal(...)) {
>   local_bh_disable();
>   local_bh_enable();
>   }
> 
> If we wanted to avoid touching the flags directly, but then would
> have a function call..

Yeah, plus that looks ridiculous ;)

The biggest cost in the signaler thread is going to sleep.
-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 series starting with [1/2] drm/i915: Pre-calculate engine context size

[Saarinen, Jani]

> -Original Message-
> Subject: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] 
> drm/i915:
> Pre-calculate engine context size
> 
> == Series Details ==
> 
> Series: series starting with [1/2] drm/i915: Pre-calculate engine context size
> URL   : https://patchwork.freedesktop.org/series/23559/
> State : warning
> 
> == Summary ==
> 
> Series 23559v1 Series without cover letter
> https://patchwork.freedesktop.org/api/1.0/series/23559/revisions/1/mbox/
> 
> Test drv_module_reload:
> Subgroup basic-no-display:
> pass   -> DMESG-WARN (fi-hsw-4770r)
> pass   -> DMESG-WARN (fi-byt-j1900)
> pass   -> DMESG-WARN (fi-byt-n2820)
> pass   -> DMESG-WARN (fi-ivb-3520m)
> pass   -> DMESG-WARN (fi-ilk-650)
> pass   -> DMESG-WARN (fi-snb-2520m)
> pass   -> DMESG-WARN (fi-hsw-4770)
> pass   -> DMESG-WARN (fi-ivb-3770)
> pass   -> DMESG-WARN (fi-snb-2600)
> Subgroup basic-reload:
> pass   -> DMESG-WARN (fi-hsw-4770r)
> pass   -> DMESG-WARN (fi-byt-j1900)
> pass   -> DMESG-WARN (fi-byt-n2820)
> pass   -> DMESG-WARN (fi-ivb-3520m)
> pass   -> DMESG-WARN (fi-ilk-650)
> pass   -> DMESG-WARN (fi-snb-2520m)
> pass   -> DMESG-WARN (fi-hsw-4770)
> pass   -> DMESG-WARN (fi-ivb-3770)
> pass   -> DMESG-WARN (fi-snb-2600)
> Subgroup basic-reload-final:
> pass   -> DMESG-WARN (fi-hsw-4770r)
> pass   -> DMESG-WARN (fi-byt-j1900)
> pass   -> DMESG-WARN (fi-byt-n2820)
> pass   -> DMESG-WARN (fi-ivb-3520m)
> pass   -> DMESG-WARN (fi-ilk-650)
> pass   -> DMESG-WARN (fi-snb-2520m)
> pass   -> DMESG-WARN (fi-hsw-4770)
> pass   -> DMESG-WARN (fi-ivb-3770)
> pass   -> DMESG-WARN (fi-snb-2600)
> Subgroup basic-reload-inject:
> pass   -> DMESG-WARN (fi-hsw-4770r)
> pass   -> DMESG-WARN (fi-byt-j1900)
> pass   -> DMESG-WARN (fi-byt-n2820)
> pass   -> DMESG-WARN (fi-ivb-3520m)
> pass   -> DMESG-WARN (fi-ilk-650)
> pass   -> DMESG-WARN (fi-snb-2520m)
> pass   -> DMESG-WARN (fi-hsw-4770)
> pass   -> DMESG-WARN (fi-ivb-3770)
> pass   -> DMESG-WARN (fi-snb-2600)
> Test gem_exec_suspend:
> Subgroup basic-s4-devices:
> pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125

How about trybot first?

> 
> fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125
> 
> fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
> time:430s
> fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
> time:426s
> fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
> time:569s
> fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
> time:474s
> fi-byt-j1900 total:278  pass:250  dwarn:4   dfail:0   fail:0   skip:24  
> time:485s
> fi-byt-n2820 total:278  pass:246  dwarn:4   dfail:0   fail:0   skip:28  
> time:477s
> fi-hsw-4770  total:278  pass:258  dwarn:4   dfail:0   fail:0   skip:16  
> time:410s
> fi-hsw-4770r total:278  pass:258  dwarn:4   dfail:0   fail:0   skip:16  
> time:398s
> fi-ilk-650   total:278  pass:224  dwarn:4   dfail:0   fail:0   skip:50  
> time:413s
> fi-ivb-3520m total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time:481s
> fi-ivb-3770  total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time:448s
> fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
> time:438s
> fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
> time:568s
> fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:455s
> fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
> time:578s
> fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
> time:463s
> fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
> time:489s
> fi-snb-2520m total:278  pass:246  dwarn:4   dfail:0   fail:0   skip:28  
> time:532s
> fi-snb-2600  total:278  pass:245  dwarn:4   dfail:0   fail:0   skip:29  
> time:406s
> 
> 7ffb3045557cbc7b49695b20416351e4e812179c drm-tip: 2017y-04m-25d-
> 14h-42m-59s UTC integration manifest 9e12aca drm/i915: Sanitize hardware
> context computation
> fc81a53 drm/i915: Pre-calculate engine context size
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4553/

Re: [Intel-gfx] [PATCH] drm/i915: Do a quick check on whether the fence is already signaled first

[Tvrtko Ursulin]

On 26/04/2017 11:15, Chris Wilson wrote:

Now that we try to signal the fence from inside the interrupt handler,
when we reach the signaler thread, the fence is most likely already
signaled. Skip manipulating the bottom-half locks if this is so.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 8f52fd5f6102..5f79c8135b3f 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -616,9 +616,12 @@ static int intel_breadcrumbs_signaler(void *arg)
request = i915_gem_request_get_rcu(request);
rcu_read_unlock();
if (signal_complete(request)) {
-   local_bh_disable();
-   dma_fence_signal(>fence);
-   local_bh_enable(); /* kick start the tasklets */
+   if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
+ >fence.flags)) {
+   local_bh_disable();
+   dma_fence_signal(>fence);
+   local_bh_enable(); /* kick start the tasklet */
+   }

spin_lock_irq(>rb_lock);




What are you referring to by "bottom-half locks" in the commit msg? 
AFAICS it would only skip kicking the tasklets with this change. That 
may be worth it, I haven't measured, but I don't see a difference wrt 
any locks.


In fact we could change this to:

if (!dma_fence_signal(...)) {
local_bh_disable();
local_bh_enable();
}

If we wanted to avoid touching the flags directly, but then would have a 
function call..


Regards,

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

Re: [Intel-gfx] [PATCH 07/27] drm/i915: Squash repeated awaits on the same fence

[Chris Wilson]

On Wed, Apr 26, 2017 at 11:20:16AM +0100, Tvrtko Ursulin wrote:
> 
> On 19/04/2017 10:41, Chris Wilson wrote:
> >Track the latest fence waited upon on each context, and only add a new
> >asynchronous wait if the new fence is more recent than the recorded
> >fence for that context. This requires us to filter out unordered
> >timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
> >absence of a universal identifier, we have to use our own
> >i915->mm.unordered_timeline token.
> >
> >v2: Throw around the debug crutches
> >v3: Inline the likely case of the pre-allocation cache being full.
> >v4: Drop the pre-allocation support, we can lose the most recent fence
> >in case of allocation failure -- it just means we may emit more awaits
> >than strictly necessary but will not break.
> >v5: Trim allocation size for leaf nodes, they only need an array of u32
> >not pointers.
> >
> >Signed-off-by: Chris Wilson 
> >Cc: Tvrtko Ursulin 
> >Cc: Joonas Lahtinen 
> >---
> > drivers/gpu/drm/i915/i915_gem_request.c|  67 +++---
> > drivers/gpu/drm/i915/i915_gem_timeline.c   | 260 
> > +
> > drivers/gpu/drm/i915/i915_gem_timeline.h   |  14 ++
> > drivers/gpu/drm/i915/selftests/i915_gem_timeline.c | 123 ++
> > .../gpu/drm/i915/selftests/i915_mock_selftests.h   |   1 +
> > 5 files changed, 438 insertions(+), 27 deletions(-)
> > create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
> >b/drivers/gpu/drm/i915/i915_gem_request.c
> >index 97c07986b7c1..fb6c31ba3ef9 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_request.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_request.c
> >@@ -730,9 +730,7 @@ int
> > i915_gem_request_await_dma_fence(struct drm_i915_gem_request *req,
> >  struct dma_fence *fence)
> > {
> >-struct dma_fence_array *array;
> > int ret;
> >-int i;
> >
> > if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
> > return 0;
> >@@ -744,39 +742,54 @@ i915_gem_request_await_dma_fence(struct 
> >drm_i915_gem_request *req,
> > if (fence->context == req->fence.context)
> > return 0;
> >
> >-if (dma_fence_is_i915(fence))
> >-return i915_gem_request_await_request(req, to_request(fence));
> >+/* Squash repeated waits to the same timelines, picking the latest */
> >+if (fence->context != req->i915->mm.unordered_timeline &&
> >+intel_timeline_sync_get(req->timeline,
> >+fence->context, fence->seqno))
> 
> Function name is non-intuitive to me. It doesn't seem to get
> anything, but is more like query? Since it ends up with
> i915_seqno_passed, maybe intel_timeline_sync_is_newer/older ? (give
> or take)

_get was choosen as the partner for _set, which seemed to make sense.
Keep intel_timeline_sync_set() and replace _get with
intel_timeline_sync_passed() ?
intel_timeline_sync_is_later() ?

> >diff --git a/drivers/gpu/drm/i915/i915_gem_timeline.c 
> >b/drivers/gpu/drm/i915/i915_gem_timeline.c
> >index b596ca7ee058..f2b734dda895 100644
> >--- a/drivers/gpu/drm/i915/i915_gem_timeline.c
> >+++ b/drivers/gpu/drm/i915/i915_gem_timeline.c
> >@@ -24,6 +24,254 @@
> >
> > #include "i915_drv.h"
> >
> >+#define NSYNC 16
> >+#define SHIFT ilog2(NSYNC)
> >+#define MASK (NSYNC - 1)
> >+
> >+/* struct intel_timeline_sync is a layer of a radixtree that maps a u64 
> >fence
> >+ * context id to the last u32 fence seqno waited upon from that context.
> >+ * Unlike lib/radixtree it uses a parent pointer that allows traversal back 
> >to
> >+ * the root. This allows us to access the whole tree via a single pointer
> >+ * to the most recently used layer. We expect fence contexts to be dense
> >+ * and most reuse to be on the same i915_gem_context but on neighbouring
> >+ * engines (i.e. on adjacent contexts) and reuse the same leaf, a very
> >+ * effective lookup cache. If the new lookup is not on the same leaf, we
> >+ * expect it to be on the neighbouring branch.
> >+ *
> >+ * A leaf holds an array of u32 seqno, and has height 0. The bitmap field
> >+ * allows us to store whether a particular seqno is valid (i.e. allows us
> >+ * to distinguish unset from 0).
> >+ *
> >+ * A branch holds an array of layer pointers, and has height > 0, and always
> >+ * has at least 2 layers (either branches or leaves) below it.
> >+ *
> >+ */
> 
> @_@ :)
> 
> Ok, so a map of u64 to u32. We can't use IDR or radixtree directly
> because of u64 keys. :( How about a hash table? It would be much
> simpler to review. :) Seriously, if it would perform close enough it
> would be a much much simpler implementation.

You want a resizable hashtable. rht is appallingly slow, so you want a
custom resizeable ht. They are not as simple as this codewise ;)
(Plus a compressed radixtree is part of my plan for scalability
improvements 

Re: [Intel-gfx] [PATCH] drm/i915: Skip waking the signaler when enabling before request submission

[Tvrtko Ursulin]

On 26/04/2017 09:06, Chris Wilson wrote:

If we are enabling the breadcrumbs signaling prior to submitting the
request, we know that we cannot have missed the interrupt and can
therefore skip immediately waking the signaler to check.

This reduces a significant chunk of the __i915_gem_request_submit()
overhead for inter-engine synchronisation, for example in gem_exec_whisper.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_gem_request.c| 4 ++--
 drivers/gpu/drm/i915/i915_guc_submission.c | 2 +-
 drivers/gpu/drm/i915/intel_breadcrumbs.c   | 7 ---
 drivers/gpu/drm/i915/intel_ringbuffer.h| 3 ++-
 4 files changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 8bbec19e267a..7b9a509f00f3 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -61,7 +61,7 @@ static bool i915_fence_enable_signaling(struct dma_fence 
*fence)
if (i915_fence_signaled(fence))
return false;

-   intel_engine_enable_signaling(to_request(fence));
+   intel_engine_enable_signaling(to_request(fence), true);
return true;
 }

@@ -448,7 +448,7 @@ void __i915_gem_request_submit(struct drm_i915_gem_request 
*request)
spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
request->global_seqno = seqno;
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
-   intel_engine_enable_signaling(request);
+   intel_engine_enable_signaling(request, false);
spin_unlock(>lock);

engine->emit_breadcrumb(request,
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index a4eca6ac449b..7ccb22709efb 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -649,7 +649,7 @@ static void nested_enable_signaling(struct 
drm_i915_gem_request *rq)
trace_dma_fence_enable_signal(>fence);

spin_lock_nested(>lock, SINGLE_DEPTH_NESTING);
-   intel_engine_enable_signaling(rq);
+   intel_engine_enable_signaling(rq, true);
spin_unlock(>lock);
 }

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 0839f928bc57..8f52fd5f6102 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -683,12 +683,13 @@ static int intel_breadcrumbs_signaler(void *arg)
return 0;
 }

-void intel_engine_enable_signaling(struct drm_i915_gem_request *request)
+void intel_engine_enable_signaling(struct drm_i915_gem_request *request,
+  bool wakeup)
 {
struct intel_engine_cs *engine = request->engine;
struct intel_breadcrumbs *b = >breadcrumbs;
struct rb_node *parent, **p;
-   bool first, wakeup;
+   bool first;
u32 seqno;

/* Note that we may be called from an interrupt handler on another
@@ -721,7 +722,7 @@ void intel_engine_enable_signaling(struct 
drm_i915_gem_request *request)
 * If we are the oldest waiter, enable the irq (after which we
 * must double check that the seqno did not complete).
 */
-   wakeup = __intel_engine_add_wait(engine, >signaling.wait);
+   wakeup &= __intel_engine_add_wait(engine, >signaling.wait);

/* Now insert ourselves into the retirement ordered list of signals
 * on this engine. We track the oldest seqno as that will be the
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index 3f7d5666bcf6..de5b968f508a 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -672,7 +672,8 @@ bool intel_engine_add_wait(struct intel_engine_cs *engine,
   struct intel_wait *wait);
 void intel_engine_remove_wait(struct intel_engine_cs *engine,
  struct intel_wait *wait);
-void intel_engine_enable_signaling(struct drm_i915_gem_request *request);
+void intel_engine_enable_signaling(struct drm_i915_gem_request *request,
+  bool wakeup);
 void intel_engine_cancel_signaling(struct drm_i915_gem_request *request);

 static inline bool intel_engine_has_waiter(const struct intel_engine_cs 
*engine)



Reviewed-by: Tvrtko Ursulin 

Regards,

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

Re: [Intel-gfx] [PATCH 07/27] drm/i915: Squash repeated awaits on the same fence

[Tvrtko Ursulin]

On 19/04/2017 10:41, Chris Wilson wrote:

Track the latest fence waited upon on each context, and only add a new
asynchronous wait if the new fence is more recent than the recorded
fence for that context. This requires us to filter out unordered
timelines, which are noted by DMA_FENCE_NO_CONTEXT. However, in the
absence of a universal identifier, we have to use our own
i915->mm.unordered_timeline token.

v2: Throw around the debug crutches
v3: Inline the likely case of the pre-allocation cache being full.
v4: Drop the pre-allocation support, we can lose the most recent fence
in case of allocation failure -- it just means we may emit more awaits
than strictly necessary but will not break.
v5: Trim allocation size for leaf nodes, they only need an array of u32
not pointers.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_request.c|  67 +++---
 drivers/gpu/drm/i915/i915_gem_timeline.c   | 260 +
 drivers/gpu/drm/i915/i915_gem_timeline.h   |  14 ++
 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c | 123 ++
 .../gpu/drm/i915/selftests/i915_mock_selftests.h   |   1 +
 5 files changed, 438 insertions(+), 27 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/selftests/i915_gem_timeline.c

diff --git a/drivers/gpu/drm/i915/i915_gem_request.c 
b/drivers/gpu/drm/i915/i915_gem_request.c
index 97c07986b7c1..fb6c31ba3ef9 100644
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -730,9 +730,7 @@ int
 i915_gem_request_await_dma_fence(struct drm_i915_gem_request *req,
 struct dma_fence *fence)
 {
-   struct dma_fence_array *array;
int ret;
-   int i;

if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >flags))
return 0;
@@ -744,39 +742,54 @@ i915_gem_request_await_dma_fence(struct 
drm_i915_gem_request *req,
if (fence->context == req->fence.context)
return 0;

-   if (dma_fence_is_i915(fence))
-   return i915_gem_request_await_request(req, to_request(fence));
+   /* Squash repeated waits to the same timelines, picking the latest */
+   if (fence->context != req->i915->mm.unordered_timeline &&
+   intel_timeline_sync_get(req->timeline,
+   fence->context, fence->seqno))


Function name is non-intuitive to me. It doesn't seem to get anything, 
but is more like query? Since it ends up with i915_seqno_passed, maybe 
intel_timeline_sync_is_newer/older ? (give or take)


And kerneldoc for intel_timeline_sync_get and set are needed as well.


+   return 0;

-   if (!dma_fence_is_array(fence)) {
+   if (dma_fence_is_i915(fence)) {
+   ret = i915_gem_request_await_request(req, to_request(fence));
+   if (ret < 0)
+   return ret;
+   } else if (!dma_fence_is_array(fence)) {
ret = i915_sw_fence_await_dma_fence(>submit,
fence, I915_FENCE_TIMEOUT,
GFP_KERNEL);
-   return ret < 0 ? ret : 0;
-   }
-
-   /* Note that if the fence-array was created in signal-on-any mode,
-* we should *not* decompose it into its individual fences. However,
-* we don't currently store which mode the fence-array is operating
-* in. Fortunately, the only user of signal-on-any is private to
-* amdgpu and we should not see any incoming fence-array from
-* sync-file being in signal-on-any mode.
-*/
-
-   array = to_dma_fence_array(fence);
-   for (i = 0; i < array->num_fences; i++) {
-   struct dma_fence *child = array->fences[i];
-
-   if (dma_fence_is_i915(child))
-   ret = i915_gem_request_await_request(req,
-to_request(child));
-   else
-   ret = i915_sw_fence_await_dma_fence(>submit,
-   child, 
I915_FENCE_TIMEOUT,
-   GFP_KERNEL);
if (ret < 0)
return ret;
+   } else {
+   struct dma_fence_array *array = to_dma_fence_array(fence);
+   int i;
+
+   /* Note that if the fence-array was created in signal-on-any
+* mode, we should *not* decompose it into its individual
+* fences. However, we don't currently store which mode the
+* fence-array is operating in. Fortunately, the only user of
+* signal-on-any is private to amdgpu and we should not see any
+* incoming fence-array from sync-file being in 

[Intel-gfx] [PATCH] drm/i915: Do a quick check on whether the fence is already signaled first

[Chris Wilson]

Now that we try to signal the fence from inside the interrupt handler,
when we reach the signaler thread, the fence is most likely already
signaled. Skip manipulating the bottom-half locks if this is so.

Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_breadcrumbs.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c 
b/drivers/gpu/drm/i915/intel_breadcrumbs.c
index 8f52fd5f6102..5f79c8135b3f 100644
--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c
@@ -616,9 +616,12 @@ static int intel_breadcrumbs_signaler(void *arg)
request = i915_gem_request_get_rcu(request);
rcu_read_unlock();
if (signal_complete(request)) {
-   local_bh_disable();
-   dma_fence_signal(>fence);
-   local_bh_enable(); /* kick start the tasklets */
+   if (!test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
+ >fence.flags)) {
+   local_bh_disable();
+   dma_fence_signal(>fence);
+   local_bh_enable(); /* kick start the tasklet */
+   }
 
spin_lock_irq(>rb_lock);
 
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Pre-calculate engine context size

[Zhi Wang]

Uh...sorry for not mentioning that before:), and stolen memory is not my 
business. :(


Actually we root-caused it.

This is how we found this case:

The story is W driver directly allocated the ring buffer after the 
context image, and the context image size in W driver is 19 pages. GVT-g 
will do shadow context during submission, we copy 20 pages from guest 
context image, so you can see, an extra page is copied here as the 
context image size is actual 19 pages. The extra page belows to ring 
buffer. When guest updates that page with new commands during GVT-g 
executing the workload, the extra page ( which is ring buffer page) will 
be over-written with old content, since GVT-g will copy the shadow 
context (20 pages) back to guest at this time.


That's the full story. I send another email to Harsh. He should know if 
the context image size of CHV is also 19 pages.


Thanks,
Zhi.

于 04/26/17 17:52, Joonas Lahtinen 写道:

On ke, 2017-04-26 at 17:10 +0800, Zhi Wang wrote:

Hi Joonas:
  Can you change GEN8_LR_CONTEXT_RENDER_SIZE = (19 * PAGE_SIZE)?
Then we don't need the hack in GVT-g. :P Actually it's 19 pages not
20 pages on BDW.

The exception is only made for BDW, not Gen8 overall. Has the change
been verified for CHV too?

Why hasn't a patch to fix above been sent for i915 in the past? Just
like in the stolen memory disabling case, bugs should be root caused
and then fixed, not just worked around quickly.

Regards, Joonas


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

Re: [Intel-gfx] [RESEND][GIT PULL] GVT-g next fixes for 4.12

[Jani Nikula]

On Thu, 20 Apr 2017, Zhenyu Wang  wrote:
> Hi,
>  
> Please pull gvt next fixes for 4.12.
>
> (resend with subscribed mail address.)

Pulled to drm-intel-next-fixes, thanks.

BR,
Jani.

>
> Thanks.
>
> --
> The following changes since commit b35f34d1da4e77637869c8041a355da810f69fb6:
>
>   drm/i915/gvt: control the scheduler by timeslice usage (2017-03-30 13:34:10 
> +0800)
>
> are available in the git repository at:
>
>   https://github.com/01org/gvt-linux.git tags/gvt-next-fixes-2017-04-20
>
> for you to fetch changes up to c821ee6d2bb4cfc9991bf285f53103cde9d3593a:
>
>   drm/i915/gvt: fix a bounds check in ring_id_to_context_switch_event() 
> (2017-04-18 17:50:05 +0800)
>
> 
> gvt-next-fixes-2017-04-20
>
> - some code optimization from Changbin
> - debug message cleanup after QoS merge
> - misc fixes for display mmio init, reset vgpu warning, etc.
>
> 
> Changbin Du (4):
>   drm/i915/gvt: Align render mmio list to cacheline
>   drm/i915/gvt: remove redundant platform check for mocs load/restore
>   drm/i915/gvt: remove redundant ring id check which cause significant 
> CPU misprediction
>   drm/i915/gvt: use directly assignment for structure copying
>
> Dan Carpenter (1):
>   drm/i915/gvt: fix a bounds check in ring_id_to_context_switch_event()
>
> Pei Zhang (1):
>   drm/i915/gvt: add mmio init for virtual display
>
> Zhenyu Wang (3):
>   drm/i915/gvt: cleanup some too chatty scheduler message
>   drm/i915/gvt: remove some debug messages in scheduler timer handler
>   drm/i915/gvt: Fix PTE write flush for taking runtime pm properly
>
>  drivers/gpu/drm/i915/gvt/cmd_parser.c   |  8 +---
>  drivers/gpu/drm/i915/gvt/display.c  | 29 -
>  drivers/gpu/drm/i915/gvt/execlist.c |  8 +++-
>  drivers/gpu/drm/i915/gvt/gtt.c  |  5 +
>  drivers/gpu/drm/i915/gvt/render.c   | 10 ++
>  drivers/gpu/drm/i915/gvt/sched_policy.c | 17 ++---
>  drivers/gpu/drm/i915/gvt/scheduler.c|  5 +
>  7 files changed, 42 insertions(+), 40 deletions(-)

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

[Intel-gfx] About the context image size on GEN8+

[Zhi Wang]

Hi Harsh:
Thanks for your help last time. You show us the size of context 
image is actual 19 pages on BDW. Is it the same also on CHV?


Thanks,
Zhi.

于 04/26/17 17:52, Joonas Lahtinen 写道:

On ke, 2017-04-26 at 17:10 +0800, Zhi Wang wrote:

Hi Joonas:
  Can you change GEN8_LR_CONTEXT_RENDER_SIZE = (19 * PAGE_SIZE)?
Then we don't need the hack in GVT-g. :P Actually it's 19 pages not
20 pages on BDW.

The exception is only made for BDW, not Gen8 overall. Has the change
been verified for CHV too?

Why hasn't a patch to fix above been sent for i915 in the past? Just
like in the stolen memory disabling case, bugs should be root caused
and then fixed, not just worked around quickly.

Regards, Joonas


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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Pre-calculate engine context size

[Joonas Lahtinen]

On ke, 2017-04-26 at 17:10 +0800, Zhi Wang wrote:
> Hi Joonas:
>  Can you change GEN8_LR_CONTEXT_RENDER_SIZE = (19 * PAGE_SIZE)?
> Then we don't need the hack in GVT-g. :P Actually it's 19 pages not
> 20 pages on BDW.

The exception is only made for BDW, not Gen8 overall. Has the change
been verified for CHV too?

Why hasn't a patch to fix above been sent for i915 in the past? Just
like in the stolen memory disabling case, bugs should be root caused
and then fixed, not just worked around quickly.

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 series starting with [1/2] drm/i915: Pre-calculate engine context size

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Pre-calculate engine context size
URL   : https://patchwork.freedesktop.org/series/23559/
State : warning

== Summary ==

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

Test drv_module_reload:
Subgroup basic-no-display:
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-byt-j1900)
pass   -> DMESG-WARN (fi-byt-n2820)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-snb-2520m)
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-snb-2600)
Subgroup basic-reload:
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-byt-j1900)
pass   -> DMESG-WARN (fi-byt-n2820)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-snb-2520m)
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-snb-2600)
Subgroup basic-reload-final:
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-byt-j1900)
pass   -> DMESG-WARN (fi-byt-n2820)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-snb-2520m)
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-snb-2600)
Subgroup basic-reload-inject:
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-byt-j1900)
pass   -> DMESG-WARN (fi-byt-n2820)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-snb-2520m)
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-snb-2600)
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125

fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:430s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:426s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:569s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:474s
fi-byt-j1900 total:278  pass:250  dwarn:4   dfail:0   fail:0   skip:24  
time:485s
fi-byt-n2820 total:278  pass:246  dwarn:4   dfail:0   fail:0   skip:28  
time:477s
fi-hsw-4770  total:278  pass:258  dwarn:4   dfail:0   fail:0   skip:16  
time:410s
fi-hsw-4770r total:278  pass:258  dwarn:4   dfail:0   fail:0   skip:16  
time:398s
fi-ilk-650   total:278  pass:224  dwarn:4   dfail:0   fail:0   skip:50  
time:413s
fi-ivb-3520m total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:481s
fi-ivb-3770  total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:448s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:438s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:568s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:455s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:578s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:463s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:489s
fi-snb-2520m total:278  pass:246  dwarn:4   dfail:0   fail:0   skip:28  
time:532s
fi-snb-2600  total:278  pass:245  dwarn:4   dfail:0   fail:0   skip:29  
time:406s

7ffb3045557cbc7b49695b20416351e4e812179c drm-tip: 2017y-04m-25d-14h-42m-59s UTC 
integration manifest
9e12aca drm/i915: Sanitize hardware context computation
fc81a53 drm/i915: Pre-calculate engine context size

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4553/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Pre-calculate engine context size

[Chris Wilson]

On Wed, Apr 26, 2017 at 12:11:53PM +0300, Joonas Lahtinen wrote:
> Pre-calculate engine context size based on engine class and device
> generation and store it in the engine instance.
> 
> Signed-off-by: Joonas Lahtinen 
> Cc: Paulo Zanoni 
> Cc: Rodrigo Vivi 
> Cc: Chris Wilson 
> Cc: Daniele Ceraolo Spurio 
> Cc: Tvrtko Ursulin 
> Cc: Oscar Mateo 
> Cc: Zhenyu Wang 
> Cc: intel-gvt-...@lists.freedesktop.org
> ---
>  drivers/gpu/drm/i915/gvt/scheduler.c   |  6 ++--
>  drivers/gpu/drm/i915/i915_guc_submission.c |  3 +-
>  drivers/gpu/drm/i915/intel_engine_cs.c | 46 +
>  drivers/gpu/drm/i915/intel_lrc.c   | 54 
> +-
>  drivers/gpu/drm/i915/intel_lrc.h   |  2 --
>  drivers/gpu/drm/i915/intel_ringbuffer.h|  5 +--
>  6 files changed, 53 insertions(+), 63 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index a77db23..ac538dc 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -69,8 +69,7 @@ static int populate_shadow_context(struct 
> intel_vgpu_workload *workload)
>   gvt_dbg_sched("ring id %d workload lrca %x", ring_id,
>   workload->ctx_desc.lrca);
>  
> - context_page_num = intel_lr_context_size(
> - gvt->dev_priv->engine[ring_id]);
> + context_page_num = gvt->dev_priv->engine[ring_id]->context_size;
>  
>   context_page_num = context_page_num >> PAGE_SHIFT;
>  
> @@ -333,8 +332,7 @@ static void update_guest_context(struct 
> intel_vgpu_workload *workload)
>   gvt_dbg_sched("ring id %d workload lrca %x\n", ring_id,
>   workload->ctx_desc.lrca);
>  
> - context_page_num = intel_lr_context_size(
> - gvt->dev_priv->engine[ring_id]);
> + context_page_num = gvt->dev_priv->engine[ring_id]->context_size;
>  
>   context_page_num = context_page_num >> PAGE_SHIFT;
>  
> diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
> b/drivers/gpu/drm/i915/i915_guc_submission.c
> index ab5140b..6c78637 100644
> --- a/drivers/gpu/drm/i915/i915_guc_submission.c
> +++ b/drivers/gpu/drm/i915/i915_guc_submission.c
> @@ -1051,8 +1051,7 @@ static int guc_ads_create(struct intel_guc *guc)
>   dev_priv->engine[RCS]->status_page.ggtt_offset;
>  
>   for_each_engine(engine, dev_priv, id)
> - blob->ads.eng_state_size[engine->guc_id] =
> - intel_lr_context_size(engine);
> + blob->ads.eng_state_size[engine->guc_id] = engine->context_size;
>  
>   base = guc_ggtt_offset(vma);
>   blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
> diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
> b/drivers/gpu/drm/i915/intel_engine_cs.c
> index 82a274b..091c0c7 100644
> --- a/drivers/gpu/drm/i915/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/intel_engine_cs.c
> @@ -26,6 +26,10 @@
>  #include "intel_ringbuffer.h"
>  #include "intel_lrc.h"
>  
> +#define GEN9_LR_CONTEXT_RENDER_SIZE  (22 * PAGE_SIZE)
> +#define GEN8_LR_CONTEXT_RENDER_SIZE  (20 * PAGE_SIZE)
> +#define GEN8_LR_CONTEXT_OTHER_SIZE   ( 2 * PAGE_SIZE)
> +
>  struct engine_class_info {
>   const char *name;
>   int (*init_legacy)(struct intel_engine_cs *engine);
> @@ -107,6 +111,46 @@ static const struct engine_info intel_engines[] = {
>   },
>  };
>  
> +/**
> + * ___intel_engine_context_size() - return the size of the context for an 
> engine
> + * @dev_priv: i915 device private
> + * @class: engine class
> + *
> + * Each engine class may require a different amount of space for a context
> + * image.
> + *
> + * Return: size (in bytes) of an engine class specific context image
> + *
> + * Note: this size includes the HWSP, which is part of the context image
> + * in LRC mode, but does not include the "shared data page" used with
> + * GuC submission. The caller should account for this if using the GuC.
> + */
> +static u32
> +__intel_engine_context_size(struct drm_i915_private *dev_priv, u8 class)
> +{
> + WARN_ON(INTEL_GEN(dev_priv) < 8);
> +
> + switch (class) {
> + case RENDER_CLASS:
> + switch (INTEL_GEN(dev_priv)) {
> + default:
> + MISSING_CASE(INTEL_GEN(dev_priv));
> + case 9:
> + return GEN9_LR_CONTEXT_RENDER_SIZE;
> + case 8:
> + return GEN8_LR_CONTEXT_RENDER_SIZE;
> + }
> + break;
> + case VIDEO_DECODE_CLASS:
> + case VIDEO_ENHANCEMENT_CLASS:
> + case COPY_ENGINE_CLASS:
> + return GEN8_LR_CONTEXT_OTHER_SIZE;
> + }
> +
> + MISSING_CASE(class);
> + return GEN8_LR_CONTEXT_OTHER_SIZE;
> +}
> +
>  

Re: [Intel-gfx] GPU hangs and X shot down with 4.11-rc6

[Michal Hocko]

On Tue 25-04-17 21:03:32, Chris Wilson wrote:
> On Tue, Apr 25, 2017 at 06:41:20PM +0200, Michal Hocko wrote:
> > Hi,
> > I have just experienced X being shut down once with 4.11-rc2 and 2 times
> > with 4.11-rc6 kernel.  I do not remember seeing something like this
> > before but it is quite possible I was just lucky to not trigger this
> > issue before. It always happened while I was working on a presentation
> > in LibreOffice which I do very seldom. The kernel log contains:
> > 
> > [ 7456.721893] [drm] GPU HANG: ecode 9:0:0x86dd, in Xorg [3594], 
> > reason: Hang on render ring, action: reset
> > [ 7456.721897] [drm] GPU hangs can indicate a bug anywhere in the entire 
> > gfx stack, including userspace.
> > [ 7456.721898] [drm] Please file a _new_ bug report on bugs.freedesktop.org 
> > against DRI -> DRM/Intel
> > [ 7456.721900] [drm] drm/i915 developers can then reassign to the right 
> > component if it's not a kernel issue.
> > [ 7456.721901] [drm] The gpu crash dump is required to analyze gpu hangs, 
> > so please always attach it.
> > [ 7456.721902] [drm] GPU crash dump saved to /sys/class/drm/card0/error
> > [ 7456.721925] drm/i915: Resetting chip after gpu hang
> > [ 7456.722117] [drm] RC6 on
> > [ 7456.734588] [drm] GuC firmware load skipped
> > [ 7464.686209] drm/i915: Resetting chip after gpu hang
> > [ 7464.686284] [drm] RC6 on
> > [ 7464.702469] [drm] GuC firmware load skipped
> > [ 7472.686180] drm/i915: Resetting chip after gpu hang
> > [ 7472.686241] [drm] RC6 on
> > [ 7472.704565] [drm] GuC firmware load skipped
> > [ 7480.686179] drm/i915: Resetting chip after gpu hang
> > [ 7480.686241] [drm] RC6 on
> > [ 7480.704583] [drm] GuC firmware load skipped
> > [ 7493.678130] drm/i915: Resetting chip after gpu hang
> > [ 7493.678206] [drm] RC6 on
> > [ 7493.696505] [drm] GuC firmware load skipped
> > 
> > The kernel message tells that the problem might be anywhere and I should
> > report to freedesktop but I haven't changed the userspace recently so it
> > smells more like a kernel bug to me. Does this ring bells? The GPU crash
> > dump is attached in case it is useful.
> 
> There are lots of very similar GPU hangs for mesa across a wide range of
> kernels, with several reports noting a correlation with libreoffice.
> 
> At first glance, I would say you were just unlucky to hit it.

OK, good to know. Thanks!
-- 
Michal Hocko
SUSE Labs
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Avoid the branch in computing intel_ring_space() (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [1/3] drm/i915: Avoid the branch in computing 
intel_ring_space() (rev2)
URL   : https://patchwork.freedesktop.org/series/23555/
State : success

== Summary ==

Series 23555v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/23555/revisions/2/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:418s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:428s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:524s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:476s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:475s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:555s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:440s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:550s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:445s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:475s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:403s
fi-skl-gvtdvm failed to connect after reboot

7ffb3045557cbc7b49695b20416351e4e812179c drm-tip: 2017y-04m-25d-14h-42m-59s UTC 
integration manifest
dac888b drm/i915: Micro-optimise hotpath through intel_ring_begin()
f29e6ba drm/i915: Report the ring->space from intel_ring_update_space()
7145680 drm/i915: Avoid the branch in computing intel_ring_space()

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4552/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Pre-calculate engine context size

[Zhi Wang]

Hi Joonas:
Can you change GEN8_LR_CONTEXT_RENDER_SIZE = (19 * PAGE_SIZE)? Then we 
don't need the hack in GVT-g. :P Actually it's 19 pages not 20 pages on BDW.

Thanks,
Zhi.

于 04/26/17 17:11, Joonas Lahtinen 写道:

Pre-calculate engine context size based on engine class and device
generation and store it in the engine instance.

Signed-off-by: Joonas Lahtinen 
Cc: Paulo Zanoni 
Cc: Rodrigo Vivi 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Oscar Mateo 
Cc: Zhenyu Wang 
Cc: intel-gvt-...@lists.freedesktop.org
---
  drivers/gpu/drm/i915/gvt/scheduler.c   |  6 ++--
  drivers/gpu/drm/i915/i915_guc_submission.c |  3 +-
  drivers/gpu/drm/i915/intel_engine_cs.c | 46 +
  drivers/gpu/drm/i915/intel_lrc.c   | 54 +-
  drivers/gpu/drm/i915/intel_lrc.h   |  2 --
  drivers/gpu/drm/i915/intel_ringbuffer.h|  5 +--
  6 files changed, 53 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index a77db23..ac538dc 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -69,8 +69,7 @@ static int populate_shadow_context(struct intel_vgpu_workload 
*workload)
gvt_dbg_sched("ring id %d workload lrca %x", ring_id,
workload->ctx_desc.lrca);
  
-	context_page_num = intel_lr_context_size(

-   gvt->dev_priv->engine[ring_id]);
+   context_page_num = gvt->dev_priv->engine[ring_id]->context_size;
  
  	context_page_num = context_page_num >> PAGE_SHIFT;
  
@@ -333,8 +332,7 @@ static void update_guest_context(struct intel_vgpu_workload *workload)

gvt_dbg_sched("ring id %d workload lrca %x\n", ring_id,
workload->ctx_desc.lrca);
  
-	context_page_num = intel_lr_context_size(

-   gvt->dev_priv->engine[ring_id]);
+   context_page_num = gvt->dev_priv->engine[ring_id]->context_size;
  
  	context_page_num = context_page_num >> PAGE_SHIFT;
  
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c

index ab5140b..6c78637 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1051,8 +1051,7 @@ static int guc_ads_create(struct intel_guc *guc)
dev_priv->engine[RCS]->status_page.ggtt_offset;
  
  	for_each_engine(engine, dev_priv, id)

-   blob->ads.eng_state_size[engine->guc_id] =
-   intel_lr_context_size(engine);
+   blob->ads.eng_state_size[engine->guc_id] = engine->context_size;
  
  	base = guc_ggtt_offset(vma);

blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 82a274b..091c0c7 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -26,6 +26,10 @@
  #include "intel_ringbuffer.h"
  #include "intel_lrc.h"
  
+#define GEN9_LR_CONTEXT_RENDER_SIZE	(22 * PAGE_SIZE)

+#define GEN8_LR_CONTEXT_RENDER_SIZE(20 * PAGE_SIZE)
+#define GEN8_LR_CONTEXT_OTHER_SIZE ( 2 * PAGE_SIZE)
+
  struct engine_class_info {
const char *name;
int (*init_legacy)(struct intel_engine_cs *engine);
@@ -107,6 +111,46 @@ static const struct engine_info intel_engines[] = {
},
  };
  
+/**

+ * ___intel_engine_context_size() - return the size of the context for an 
engine
+ * @dev_priv: i915 device private
+ * @class: engine class
+ *
+ * Each engine class may require a different amount of space for a context
+ * image.
+ *
+ * Return: size (in bytes) of an engine class specific context image
+ *
+ * Note: this size includes the HWSP, which is part of the context image
+ * in LRC mode, but does not include the "shared data page" used with
+ * GuC submission. The caller should account for this if using the GuC.
+ */
+static u32
+__intel_engine_context_size(struct drm_i915_private *dev_priv, u8 class)
+{
+   WARN_ON(INTEL_GEN(dev_priv) < 8);
+
+   switch (class) {
+   case RENDER_CLASS:
+   switch (INTEL_GEN(dev_priv)) {
+   default:
+   MISSING_CASE(INTEL_GEN(dev_priv));
+   case 9:
+   return GEN9_LR_CONTEXT_RENDER_SIZE;
+   case 8:
+   return GEN8_LR_CONTEXT_RENDER_SIZE;
+   }
+   break;
+   case VIDEO_DECODE_CLASS:
+   case VIDEO_ENHANCEMENT_CLASS:
+   case COPY_ENGINE_CLASS:
+   return GEN8_LR_CONTEXT_OTHER_SIZE;
+   }
+
+   MISSING_CASE(class);
+   return GEN8_LR_CONTEXT_OTHER_SIZE;
+}
+
  static int
  

[Intel-gfx] [PATCH 1/2] drm/i915: Pre-calculate engine context size

[Joonas Lahtinen]

Pre-calculate engine context size based on engine class and device
generation and store it in the engine instance.

Signed-off-by: Joonas Lahtinen 
Cc: Paulo Zanoni 
Cc: Rodrigo Vivi 
Cc: Chris Wilson 
Cc: Daniele Ceraolo Spurio 
Cc: Tvrtko Ursulin 
Cc: Oscar Mateo 
Cc: Zhenyu Wang 
Cc: intel-gvt-...@lists.freedesktop.org
---
 drivers/gpu/drm/i915/gvt/scheduler.c   |  6 ++--
 drivers/gpu/drm/i915/i915_guc_submission.c |  3 +-
 drivers/gpu/drm/i915/intel_engine_cs.c | 46 +
 drivers/gpu/drm/i915/intel_lrc.c   | 54 +-
 drivers/gpu/drm/i915/intel_lrc.h   |  2 --
 drivers/gpu/drm/i915/intel_ringbuffer.h|  5 +--
 6 files changed, 53 insertions(+), 63 deletions(-)

diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c 
b/drivers/gpu/drm/i915/gvt/scheduler.c
index a77db23..ac538dc 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -69,8 +69,7 @@ static int populate_shadow_context(struct intel_vgpu_workload 
*workload)
gvt_dbg_sched("ring id %d workload lrca %x", ring_id,
workload->ctx_desc.lrca);
 
-   context_page_num = intel_lr_context_size(
-   gvt->dev_priv->engine[ring_id]);
+   context_page_num = gvt->dev_priv->engine[ring_id]->context_size;
 
context_page_num = context_page_num >> PAGE_SHIFT;
 
@@ -333,8 +332,7 @@ static void update_guest_context(struct intel_vgpu_workload 
*workload)
gvt_dbg_sched("ring id %d workload lrca %x\n", ring_id,
workload->ctx_desc.lrca);
 
-   context_page_num = intel_lr_context_size(
-   gvt->dev_priv->engine[ring_id]);
+   context_page_num = gvt->dev_priv->engine[ring_id]->context_size;
 
context_page_num = context_page_num >> PAGE_SHIFT;
 
diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index ab5140b..6c78637 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -1051,8 +1051,7 @@ static int guc_ads_create(struct intel_guc *guc)
dev_priv->engine[RCS]->status_page.ggtt_offset;
 
for_each_engine(engine, dev_priv, id)
-   blob->ads.eng_state_size[engine->guc_id] =
-   intel_lr_context_size(engine);
+   blob->ads.eng_state_size[engine->guc_id] = engine->context_size;
 
base = guc_ggtt_offset(vma);
blob->ads.scheduler_policies = base + ptr_offset(blob, policies);
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 82a274b..091c0c7 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -26,6 +26,10 @@
 #include "intel_ringbuffer.h"
 #include "intel_lrc.h"
 
+#define GEN9_LR_CONTEXT_RENDER_SIZE(22 * PAGE_SIZE)
+#define GEN8_LR_CONTEXT_RENDER_SIZE(20 * PAGE_SIZE)
+#define GEN8_LR_CONTEXT_OTHER_SIZE ( 2 * PAGE_SIZE)
+
 struct engine_class_info {
const char *name;
int (*init_legacy)(struct intel_engine_cs *engine);
@@ -107,6 +111,46 @@ static const struct engine_info intel_engines[] = {
},
 };
 
+/**
+ * ___intel_engine_context_size() - return the size of the context for an 
engine
+ * @dev_priv: i915 device private
+ * @class: engine class
+ *
+ * Each engine class may require a different amount of space for a context
+ * image.
+ *
+ * Return: size (in bytes) of an engine class specific context image
+ *
+ * Note: this size includes the HWSP, which is part of the context image
+ * in LRC mode, but does not include the "shared data page" used with
+ * GuC submission. The caller should account for this if using the GuC.
+ */
+static u32
+__intel_engine_context_size(struct drm_i915_private *dev_priv, u8 class)
+{
+   WARN_ON(INTEL_GEN(dev_priv) < 8);
+
+   switch (class) {
+   case RENDER_CLASS:
+   switch (INTEL_GEN(dev_priv)) {
+   default:
+   MISSING_CASE(INTEL_GEN(dev_priv));
+   case 9:
+   return GEN9_LR_CONTEXT_RENDER_SIZE;
+   case 8:
+   return GEN8_LR_CONTEXT_RENDER_SIZE;
+   }
+   break;
+   case VIDEO_DECODE_CLASS:
+   case VIDEO_ENHANCEMENT_CLASS:
+   case COPY_ENGINE_CLASS:
+   return GEN8_LR_CONTEXT_OTHER_SIZE;
+   }
+
+   MISSING_CASE(class);
+   return GEN8_LR_CONTEXT_OTHER_SIZE;
+}
+
 static int
 intel_engine_setup(struct drm_i915_private *dev_priv,
   enum intel_engine_id id)
@@ -134,6 +178,8 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
engine->irq_shift = info->irq_shift;