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

== Series Details == Series: Adding driver-private objects to atomic state (rev6) URL : https://patchwork.freedesktop.org/series/22177/ State : failure == Summary == CC drivers/usb/host/xhci-dbg.o CC net/ipv4/udp_diag.o CC net/ipv4/tcp_cubic.o CC

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Typo fix - 'pipe bpc' to 'pipe bpp'

== Series Details == Series: drm/i915: Typo fix - 'pipe bpc' to 'pipe bpp' URL : https://patchwork.freedesktop.org/series/22462/ State : success == Summary == Series 22462v1 drm/i915: Typo fix - 'pipe bpc' to 'pipe bpp' https://patchwork.freedesktop.org/api/1.0/series/22462/revisions/1/mbox/

Re: [Intel-gfx] [PATCH v3 03/14] drm/i915/dp: rename rate_to_index() to intel_dp_rate_index() and reuse

On Tue, Mar 28, 2017 at 05:59:03PM +0300, Jani Nikula wrote: > Rename the function, move it at the top, and reuse in > intel_dp_link_rate_index(). If there was a reason in the past to use > reverse search order here, there isn't now. > > The names may be slightly confusing now, but

Re: [Intel-gfx] [PATCH v3 02/14] drm/i915/dp: return errors from rate_to_index()

On Wed, Mar 29, 2017 at 10:17:41AM +0300, Jani Nikula wrote: > On Tue, 28 Mar 2017, Manasi Navare wrote: > > Won't it make more sense to squash this patch with Patch 01 in this series? > > When i was reading Patch 1, I almost was going to comment about > > handling the

Re: [Intel-gfx] [PATCH v3 01/14] drm/i915/dp: use known correct array size in rate_to_index

Looks good to me. Reviewed-by: Manasi On Tue, Mar 28, 2017 at 05:59:01PM +0300, Jani Nikula wrote: > I can't think of a real world bug this could cause now, but this will be > required in follow-up work. While at it, change the parameter order to > be slightly more

[Intel-gfx] [PATCH v6 3/5] drm/dp: Add DP MST helpers to atomically find and release vcpi slots

From: "Pandiyan, Dhinakaran" drm_dp_atomic_find_vcpi_slots() should be called from ->atomic_check() to check there are sufficient vcpi slots for a mode and to add that to the state. This should be followed by a call to drm_dp_mst_allocate_vcpi() in

[Intel-gfx] [PATCH v6 5/5] drm/dp: Track MST link bandwidth

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

[Intel-gfx] [PATCH v6 4/5] drm: Connector helper function to release resources

From: "Pandiyan, Dhinakaran" Having an ->atomic_release callback is useful to release shared resources that get allocated in compute_config(). This function is expected to be called in the atomic_check() phase before new resources are acquired. v5: Return an int

[Intel-gfx] [PATCH v6 2/5] drm/dp: Introduce MST topology state to track available link bandwidth

From: "Pandiyan, Dhinakaran" Link bandwidth is shared between multiple display streams in DP MST configurations. The DP MST topology manager structure maintains the shared link bandwidth for a primary link directly connected to the GPU. For atomic modesetting

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

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

Re: [Intel-gfx] [PATCH 11/11] drm/doc: Small markup fixup

On Tue, Apr 04, 2017 at 05:12:59PM +0200, Neil Armstrong wrote: > On 04/04/2017 11:53 AM, Daniel Vetter wrote: > > Drive-by cleanup. > > > > Signed-off-by: Daniel Vetter > > --- > > drivers/gpu/drm/drm_probe_helper.c | 2 +- > > 1 file changed, 1 insertion(+), 1

Re: [Intel-gfx] [maintainer-tools PATCH] dim: Add examples section to dim.rst

On Mon, Apr 03, 2017 at 01:42:18PM -0400, Sean Paul wrote: > Along with a recipe for creating a topic branch and sending a pull > request from it. > > Signed-off-by: Sean Paul > --- > dim.rst | 50 ++ > 1 file changed, 50

[Intel-gfx] [PATCH v3 2/2] drm/i915/scheduler: add gvt notification for guc

GVT request needs a manual mmio load/restore. Before GuC submit a request, send notification to gvt for mmio loading. And after the GuC finished this GVT request, notify gvt again for mmio restore. This follows the usage when using execlists submission. Cc: xiao.zh...@intel.com Cc:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enhanced disable access to stolen memory as a guest (rev4)

== Series Details == Series: drm/i915: Enhanced disable access to stolen memory as a guest (rev4) URL : https://patchwork.freedesktop.org/series/21818/ State : success == Summary == Series 21818v4 drm/i915: Enhanced disable access to stolen memory as a guest

Re: [Intel-gfx] [PATCH] drm/i915/dp: do not limit rate seek when not needed

The commit message looks good now. Reviewed-by: Manasi On Wed, Mar 29, 2017 at 12:23:10PM +0300, Jani Nikula wrote: > In link training fallback, we're trying to find a rate that we know is > in a sorted array of common link rates. We don't need to limit the array >

Re: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value manually for KBL.

>-Original Message- >From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >Sent: Tuesday, April 4, 2017 6:55 PM >To: Wang, Quanxian ; intel- >g...@lists.freedesktop.org >Cc: Yang, Libin >Subject: Re: [Intel-gfx] [PATCH] drm/i915/audio: not

Re: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value manually for KBL.

Hi, Libin We don't have 4K resolution monitor. We will double check others resolutions. -Original Message- From: Yang, Libin Sent: Wednesday, April 5, 2017 10:22 AM To: Jani Nikula ; Wang, Quanxian ; intel-gfx@lists.freedesktop.org

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/2] drm/i915/scheduler: add gvt force-single-submission for guc

== Series Details == Series: series starting with [v3,1/2] drm/i915/scheduler: add gvt force-single-submission for guc URL : https://patchwork.freedesktop.org/series/22482/ State : success == Summary == Series 22482v1 Series without cover letter

Re: [Intel-gfx] [PATCH v3 07/14] drm/i915/dp: cache common rates with sink rates

Reviewed-by: Manasi On Tue, Mar 28, 2017 at 05:59:07PM +0300, Jani Nikula wrote: > Now that source rates are static and sink rates are updated whenever > DPCD is updated, we can do and cache the intersection of them whenever > sink rates are updated. This reduces code

[Intel-gfx] [PATCH v3 1/2] drm/i915/scheduler: add gvt force-single-submission for guc

GVT needs single submission and cannot allow merge. So when GuC submitting a GVT request, the next one should be submitted to guc later until the previous one is completed. This is following the usage when using execlist mode submission. v2: make force-single-submission specific to gvt (Chris)

[Intel-gfx] [PATCH v3 0/2] drm/i915/scheduler: add gvt force-single-submission and notification for guc

GVT requires force-single-submission and notification when i915 using execlist submit, and these should be extended to GuC when i915 using GuC submit. Below two patches are used to implement this Chuanxiao Dong (2): drm/i915/scheduler: add gvt force-single-submission for guc

[Intel-gfx] linux-next: build warning after merge of the drm-misc tree

Hi all, After merging the drm-misc tree, today's linux-next build (arm_multi_v7_defconfig) produced this warning: drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:608:13: warning: 'hdmi_bus_fmt_is_yuv420' defined but not used [-Wunused-function] static bool hdmi_bus_fmt_is_yuv420(unsigned int

Re: [Intel-gfx] [PATCH v3 13/14] drm/i915/dp: use readb and writeb calls for single byte DPCD access

Yes this is a good optimization. Manasi On Tue, Mar 28, 2017 at 05:59:13PM +0300, Jani Nikula wrote: > This is what we have the readb and writeb variants for. Do some minor > return value and variable cleanup while at it. > > Cc: Manasi Navare > Cc: Ville Syrjälä

Re: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value manually for KBL.

Sorry, I don't find them in bspec. With our testing, SKL/APL works and KBL failed. The commit 6014ac122ed081feca99217bc57b2e15c7fc1a51 mentioned should not do testing on KBL DP audio. We found the issue in the testing for Ubuntu latest release 17.04. (Almost upstream) But really I don't

[Intel-gfx] [PATCH 12/18] drm/i915: disable GTT cache for huge-pages

As hinted by the comment and from actually testing 2M pages on a BDW machine with the GTT cache enabled, we are definitely going to need keep it disabled. Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/intel_pm.c | 12 ++-- 1 file changed, 6 insertions(+),

[Intel-gfx] [PATCH 04/18] drm/i915: s/i915_gtt_color_adjust/i915_ggtt_color_adjust

Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 0c8350f709da..0989af4a17e4 100644 ---

[Intel-gfx] [PATCH 14/18] drm/i915/selftests: modify the gtt tests to also exercise huge pages

v2: s/roundup/round_up s/rounddown/round_down Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 123 ++ drivers/gpu/drm/i915/selftests/mock_gtt.c | 3 + 2 files changed, 89 insertions(+), 37 deletions(-)

[Intel-gfx] [PATCH 08/18] drm/i915: handle evict-for-node with page coloring

Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_evict.c | 24 1 file changed, 24 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c b/drivers/gpu/drm/i915/i915_gem_evict.c index 0c9c51be0f6a..817acff2fb6c 100644 ---

[Intel-gfx] [PATCH 06/18] drm/i915: export color_differs

Export color_differs so that we can use it elsewhere. v2: better naming Signed-off-by: Matthew Auld Cc: Mika Kuoppala --- drivers/gpu/drm/i915/i915_vma.c | 11 --- drivers/gpu/drm/i915/i915_vma.h | 6 ++ 2 files changed, 10

[Intel-gfx] [PATCH 01/18] drm/i915: add page_size_mask to dev_info

v2: - move out pde/pdpe bit definitions until later - tidyup the page size definitions, use BIT - introduce helper for detecting invalid page sizes Signed-off-by: Matthew Auld Cc: Mika Kuoppala Cc: Chris Wilson

[Intel-gfx] [PATCH 17/18] mm/shmem: tweak the huge-page interface

In its current form huge-pages through shmemfs are controlled at the super-block level, and are currently disabled by default, so to enable huge-pages for a shmem backed gem object we would need to re-mount the fs with the huge= argument, but for drm the mount is not user visible, so good luck

[Intel-gfx] [PATCH 16/18] drm/i915/debugfs: include some huge-page metrics

Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_debugfs.c | 38 ++--- 1 file changed, 35 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index

[Intel-gfx] [PATCH 18/18] drm/i915: support transparent-huge-pages through shmemfs

Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_gem.c | 187 +--- drivers/gpu/drm/i915/i915_vma.c | 8 ++ 3 files changed, 166 insertions(+), 32 deletions(-) diff --git

[Intel-gfx] [PATCH 13/18] drm/i915/selftests: exercise 4K and 64K mm insertion

Mock test filling an address space with 4K and 64K objects, in the hope of exercising the page color adjust fun. v2: s/roundup/round_up Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 68 +++ 1 file changed, 68

[Intel-gfx] [PATCH 05/18] drm/i915: clean up cache coloring

Rid the code of any mm.color_adjust assumptions to allow adding another flavour of coloring. v2: better naming Signed-off-by: Matthew Auld Cc: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.h | 2 +-

[Intel-gfx] [PATCH 15/18] drm/i915/selftests: exercise evict-for-node page coloring

Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 117 ++-- 1 file changed, 111 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c

[Intel-gfx] [PATCH 03/18] drm/i915: pass page_size to insert_entries

Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 33 ++- drivers/gpu/drm/i915/i915_gem_gtt.h | 1 + drivers/gpu/drm/i915/i915_vma.c | 1 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 3

[Intel-gfx] [PATCH 09/18] drm/i915: support inserting 64K pages in the ppgtt

Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 70 + drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++ 2 files changed, 72 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c

[Intel-gfx] [PATCH 02/18] drm/i915: introduce drm_i915_gem_object page_size members

Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem.c| 5 + drivers/gpu/drm/i915/i915_gem_object.h | 3 +++ 2 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index

[Intel-gfx] [RFC PATCH 00/18] drm/i915: initial support for huge gtt pages V2

Same as before, folding in review comments. Notably we now hook in transparent huge pages through by shmem, and *attempt* to deal with all the fun which that brings. Again should be considered very much RFC. So far I have only gone as far as testing 2M pages on my BDW machine. Thanks, Matt

[Intel-gfx] [PATCH 07/18] drm/i915: introduce ppgtt page coloring

To enable 64K pages we need to set the intermediate-page-size(IPS) bit of the pde, therefore a page table is said to be either operating in 64K or 4K mode. To accommodate this vm placement restriction we introduce a color for pages and corresponding color_adjust callback. Signed-off-by: Matthew

[Intel-gfx] [PATCH 10/18] drm/i915: support inserting 2M pages in the ppgtt

Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 53 + drivers/gpu/drm/i915/i915_gem_gtt.h | 1 + 2 files changed, 54 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c

[Intel-gfx] [PATCH 11/18] drm/i915: support inserting 1G pages in the ppgtt

Signed-off-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 45 + drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++ 2 files changed, 47 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c

Re: [Intel-gfx] [PATCH v3 05/14] drm/i915/dp: generate and cache sink rate array for all DP, not just eDP 1.4

I agree with disentangling the fallback rate limiting from sink rates and instead just limiting the common_rates array based on max link rate. Reviewed-by: Manasi On Tue, Mar 28, 2017 at 05:59:05PM +0300, Jani Nikula wrote: > There is some conflation related to sink

Re: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value manually for KBL.

Hi Quanxian, >-Original Message- >From: Wang, Quanxian >Sent: Wednesday, April 5, 2017 10:21 AM >To: Jani Nikula ; intel-gfx@lists.freedesktop.org >Cc: Yang, Libin >Subject: RE: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value

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

On Tue, 2017-04-04 at 20:36 +, Patchwork wrote: > == Series Details == > > Series: Adding driver-private objects to atomic state (rev6) > URL : https://patchwork.freedesktop.org/series/22177/ > State : failure > I guess the in-reply-to confused CI. Here's the result for the same series

Re: [Intel-gfx] [PATCH v3 04/14] drm/i915/dp: cache source rates at init

Reviewed-by: Manasi On Tue, Mar 28, 2017 at 05:59:04PM +0300, Jani Nikula wrote: > We need the source rates array so often that it makes sense to set it > once at init. This reduces function calls when we need the rates, making > the code easier to follow. > > Cc:

Re: [Intel-gfx] [PATCH v3 12/14] drm/i915/dp: localize link rate index variable more

On Wed, Mar 29, 2017 at 10:22:32AM +0300, Jani Nikula wrote: > On Wed, 29 Mar 2017, Manasi Navare wrote: > > Why not squash this with patch 08/14? and call it cleanup for obtaining the > > rate index using intel_dp_rate_index() > > Just a thought.. > > Again, usually

[Intel-gfx] [PATCH V4] drm/i915: Enhanced disable access to stolen memory as a guest

Stolen memory is in RMRR and has identity mapping in iommu, so gt could access stolen memory in host OS. While RMRR isn't supported by kvm, both EPT and guest iommu domain lack of maaping for stolen memory, so both vcpu and gt couldn't access stolen memory in guest. commit "04a68a3 drm/i915/gvt:

Re: [Intel-gfx] [PATCH 03/11] drm: Extract drm_ioctl.h

On Tue, Apr 04, 2017 at 04:46:06PM +0200, Neil Armstrong wrote: > On 04/04/2017 11:52 AM, Daniel Vetter wrote: > > To match the drm_ioctl.c we already have. > > > > v2: Remove spurious space (Ville). > > > > Cc: Ville Syrjälä > > Reviewed-by: Ville Syrjälä

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/1] drm/i915: Suspend GuC during GEM Suspend prior to GPU Reset

== Series Details == Series: series starting with [1/1] drm/i915: Suspend GuC during GEM Suspend prior to GPU Reset URL : https://patchwork.freedesktop.org/series/22488/ State : success == Summary == Series 22488v1 Series without cover letter

Re: [Intel-gfx] [maintainer-tools PATCH] dim: Add examples section to dim.rst

On Mon, Apr 03, 2017 at 01:42:18PM -0400, Sean Paul wrote: > Along with a recipe for creating a topic branch and sending a pull > request from it. > > Signed-off-by: Sean Paul One more: The maintainer's duties section in drm-misc.rst talks about topic branches, pls add a

Re: [Intel-gfx] [maintainer-tools PATCH v2] dim: Use mktemp for pull-request mails

On Mon, Apr 03, 2017 at 03:42:50PM -0400, Sean Paul wrote: > Instead of hardcoding ~/tmp in dim (and failing when it doesn't > exist), use mktemp to create the pull-request mail file. > > Signed-off-by: Sean Paul lgtm, I'll push it in a bit. -Daniel > --- > dim | 33

[Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround

From: Madhav Chauhan As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz. Practically we can achive only 99% of these cdclk values (HW team checking on this). So cdclk should be calculated for the given pixclk as per that otherwise it may lead to screen

[Intel-gfx] [PATCH 06/11] drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp

It's overkill to have a flag parameter which is essentially used just as a boolean. This takes care of core + adjusting drivers. Adjusting the scanout position callback is a bit harder, since radeon also supplies it's own driver-private flags in there. Cc: Mario Kleiner

[Intel-gfx] [PATCH 07/11] drm/vblank: Add FIXME comments about moving the vblank ts hooks

This is going to be a bit too much, but good to have at least a small note about where this should all head towards. Signed-off-by: Daniel Vetter --- include/drm/drm_drv.h | 10 ++ 1 file changed, 10 insertions(+) diff --git a/include/drm/drm_drv.h

Re: [Intel-gfx] [PATCH] drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos

On Thu, Mar 30, 2017 at 08:27:40PM +0200, Daniel Vetter wrote: > On Thu, Mar 30, 2017 at 04:41:57PM +0300, Ville Syrjälä wrote: > > On Thu, Mar 30, 2017 at 03:27:57PM +0200, Daniel Vetter wrote: > > > On Thu, Mar 30, 2017 at 2:03 PM, Ville Syrjälä > > > wrote: > > >

[Intel-gfx] [PATCH 10/11] drm/vblank: Lock down vblank->hwmode more

In the previous patch we've implemented hwmode tracking a la i915 for the vblank timestamp calculations. But that was just the basic semantics, i915 has some nice sanity checks to make sure we keep getting this right. Move them over too. Cc: Ville Syrjälä

[Intel-gfx] [PATCH 08/11] drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos

If we restrict this helper to only kms drivers (which is the case) we can look up the correct mode easily ourselves. But it's a bit tricky: - All legacy drivers look at crtc->hwmode. But that is update already at the beginning of the modeset helper, which means when we disable a pipe. Hence

[Intel-gfx] [PATCH 01/11] drm: update todo.rst

Just drive-by, but we have gsoc running so better to update it now. Great news is that two entries can be removed because essentially all done. v2: Keep a bunch of the todos, Gabriel is working on them. Cc: Gabriel Krisman Bertazi Signed-off-by: Daniel Vetter

[Intel-gfx] [PATCH 02/11] drm: Consolidate and document sysfs support

- remove docs for internal func, doesn't add value - add short overview snippet instead explaining that drivers don't have to bother themselves with reg/unreg concerns - drop the ttm comment about drmP.h, drmP.h is disappearing ... Signed-off-by: Daniel Vetter ---

[Intel-gfx] [PATCH 04/11] drm: document drm_ioctl.[hc]

Also unify/merge with the existing stuff. I was a bit torn where to put this, but in the end I decided to put all the ioctl/sysfs/debugfs stuff into drm-uapi.rst. That means we have a bit a split with the other uapi related stuff used internally, like drm_file.[hc], but I think overall this makes

[Intel-gfx] [PATCH 09/11] drm/vblank: Simplify the get_scanout_position helper hook

- We can drop the different return value flags, the only caller only cares about whether the scanout position is valid or not. Also, it's entirely undefined what "accurate" means, if we'd really care we should probably wire the max_error through. But since we never even report this to

[Intel-gfx] [PATCH 11/11] drm/doc: Small markup fixup

Drive-by cleanup. Signed-off-by: Daniel Vetter --- drivers/gpu/drm/drm_probe_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c index 85005d57bde6..efb5e5e8ce62 100644 ---

[Intel-gfx] [PATCH 2/2] drm/i915: support DRIVER_PRIME_SCANOUT.

From: Christopher James Halse Rogers CC: intel-gfx@lists.freedesktop.org Signed-off-by: Christopher James Halse Rogers --- drivers/gpu/drm/i915/i915_drv.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: [Intel-gfx] [PATCH] dim: Add apply-pull command

On Tue, 04 Apr 2017, Daniel Vetter wrote: > On Mon, Apr 03, 2017 at 06:17:51PM +0300, Jani Nikula wrote: >> On Thu, 30 Mar 2017, Daniel Vetter wrote: >> > I'm getting real lazy, let's start scripting this. Very rough draft, >> > but adds a Link:

Re: [Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround

On Tue, 2017-04-04 at 11:15 +0300, Jani Nikula wrote: > From: Madhav Chauhan > > As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz. > Practically we can achive only 99% of these cdclk values (HW team > checking on this). So cdclk should be calculated

Re: [Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround

On Tue, 04 Apr 2017, Ander Conselvan De Oliveira wrote: > On Tue, 2017-04-04 at 11:15 +0300, Jani Nikula wrote: >> From: Madhav Chauhan >> >> As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz. >> Practically we can achive only

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: limit pixel clock to 99% of cdclk workaround

== Series Details == Series: drm/i915/glk: limit pixel clock to 99% of cdclk workaround URL : https://patchwork.freedesktop.org/series/22404/ State : success == Summary == Series 22404v1 drm/i915/glk: limit pixel clock to 99% of cdclk workaround

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove user-triggerable WARN from i915_gem_object_create

On 30/03/2017 17:49, Patchwork wrote: == Series Details == Series: drm/i915: Remove user-triggerable WARN from i915_gem_object_create URL : https://patchwork.freedesktop.org/series/1/ State : success == Summary == Series 1v1 drm/i915: Remove user-triggerable WARN from

[Intel-gfx] [PATCH 1/2] drm/i915: Suspend GuC during GEM Suspend prior to GPU Reset

During S3/S4 suspend, i915 sends HOST2GUC with ENTER_S_STATE action for suspending GuC. GuC stops scheduling at this point. i915 is currently doing explicit GPU reset during suspend ensuring GEM is idle. Suspend GuC prior to triggering GPU Reset. Signed-off-by: Sagar Arun Kamble

[Intel-gfx] install HD Graphics 520 (Skylake GT2) driver on Ubuntu 16.04

Dear intel-gfx, I have some problem with the Intel Graphics. Anyone who could tell me how to download and install the latest version HD Graphics 520 (Skylake GT2) driver on Ubuntu 16.04? Thanks, Cunbo ___ Intel-gfx mailing list

Re: [Intel-gfx] [PATCH] drm/i915: Park the signaler before sleeping

On 03/04/2017 11:51, Chris Wilson wrote: If the signal to park arrives before we sleep, then we need to check kthread_should_park() before sleeping to avoid missing the signal. Otherwise, if the signal arrives whilst we are processing completed requests, we will reset the current->state back to

[Intel-gfx] [PATCH] dim: Align apply-pull with apply-branch workflow

Don't fire up an editor by default. Requested by Jani. Cc: Jani Nikula Acked-by: Jani Nikula Signed-off-by: Daniel Vetter --- dim | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/dim b/dim index

[Intel-gfx] [PATCH] dim: Fixup Link: tag in apply-pull

Somehow fell apart again in testing, let's do the same thing as with apply-branch, where we also apply the Link: after the sob is added. Cc: Jani Nikula Signed-off-by: Daniel Vetter --- dim | 4 ++-- 1 file changed, 2 insertions(+), 2

[Intel-gfx] [PATCH 03/11] drm: Extract drm_ioctl.h

To match the drm_ioctl.c we already have. v2: Remove spurious space (Ville). Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä Signed-off-by: Daniel Vetter --- include/drm/drmP.h | 1 + 1 file changed, 1

[Intel-gfx] [PATCH 05/11] drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool

There's really no reason for anything more: - Calling this while the crtc vblank stuff isn't set up is a driver bug. Those places arlready DRM_ERROR. - Calling this when the crtc is off is either a driver bug (callin drm_crtc_handle_vblank at the wrong time) or a core bug (for anything

[Intel-gfx] [PATCH] hmm

--- drivers/gpu/drm/i915/intel_breadcrumbs.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c b/drivers/gpu/drm/i915/intel_breadcrumbs.c index 2044dee3cce4..39f585abd3fd 100644 --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c

Re: [Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround

On Tue, 2017-04-04 at 10:27 +, Chauhan, Madhav wrote: > > -Original Message- > > From: Nikula, Jani > > Sent: Tuesday, April 4, 2017 3:48 PM > > To: Ander Conselvan De Oliveira ; intel- > > g...@lists.freedesktop.org > > Cc: Chauhan, Madhav

Re: [Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround

> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Tuesday, April 4, 2017 5:09 PM > To: Chauhan, Madhav > Cc: Nikula, Jani ; Ander Conselvan De Oliveira > ;

[Intel-gfx] [PATCH v2] drm/i915: Apply a cond_resched() to the saturated signaler

If the engine is continually completing nops, we can saturate the signaler and keep it working indefinitely. This angers the NMI watchdog! A good example is to disable semaphores on snb and run igt/gem_exec_nop - the parallel, multi-engine workloads are more than sufficient to hog the CPU,

Re: [Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround

On Tue, 2017-04-04 at 11:40 +0300, Jani Nikula wrote: > On Tue, 04 Apr 2017, Ander Conselvan De Oliveira wrote: > > On Tue, 2017-04-04 at 11:15 +0300, Jani Nikula wrote: > > > From: Madhav Chauhan > > > > > > As per BSPEC, valid cdclk values for

Re: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value manually for KBL.

On Sat, 01 Apr 2017, Quanxian Wang wrote: > It doesn't work on KBL. Just using automatic N/M. Please provide a more elaborate commit message. In particular, have a look at commit 6014ac122ed081feca99217bc57b2e15c7fc1a51 Author: Libin Yang

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes, v2.

== Series Details == Series: drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes, v2. URL : https://patchwork.freedesktop.org/series/22423/ State : success == Summary == Series 22423v1 drm/atomic: Acquire connection_mutex lock in

Re: [Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround

> -Original Message- > From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com] > Sent: Tuesday, April 4, 2017 4:13 PM > To: Chauhan, Madhav ; Nikula, Jani > ; intel-gfx@lists.freedesktop.org > Cc: Ville Syrjälä

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Apply a cond_resched() to the saturated signaler

== Series Details == Series: drm/i915: Apply a cond_resched() to the saturated signaler URL : https://patchwork.freedesktop.org/series/22418/ State : success == Summary == Series 22418v1 drm/i915: Apply a cond_resched() to the saturated signaler

[Intel-gfx] [PATCH i-g-t v2] tests/kms_atomic_allow_modeset: Add DRM_MODE_ATOMIC_ALLOW_MODESET test

When doing a full atomic modeset, kernel should fail if the flag DRM_MODE_ATOMIC_ALLOW_MODESET is not set. Let's add this test as part of Intel-GPU-Tools. The test procedure is the following: - Try to do atomic commit without DRM_MODE_ATOMIC_ALLOW_MODESET flag. Kernel should reject this

[Intel-gfx] [PATCH] drm/i915: Apply a cond_resched() to the saturated signaler

If the engine is continually completing nops, we can saturate the signaler and keep it working indefinitely. This angers the NMI watchdog! A good example is to disable semaphores on snb and run igt/gem_exec_nop - the parallel, multi-engine workloads are more than sufficient to hog the CPU,

Re: [Intel-gfx] [PATCH] dim: Fixup Link: tag in apply-pull

On Tue, 04 Apr 2017, Daniel Vetter wrote: > Somehow fell apart again in testing, let's do the same thing as with > apply-branch, where we also apply the Link: after the sob is added. > > Cc: Jani Nikula > Signed-off-by: Daniel Vetter

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/11] drm: update todo.rst

== Series Details == Series: series starting with [01/11] drm: update todo.rst URL : https://patchwork.freedesktop.org/series/22416/ State : success == Summary == Series 22416v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/22416/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround

On Tue, 04 Apr 2017, Ander Conselvan De Oliveira wrote: > On Tue, 2017-04-04 at 11:40 +0300, Jani Nikula wrote: >> On Tue, 04 Apr 2017, Ander Conselvan De Oliveira >> wrote: >> > On Tue, 2017-04-04 at 11:15 +0300, Jani Nikula wrote: >> > > From:

Re: [Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround

> -Original Message- > From: Nikula, Jani > Sent: Tuesday, April 4, 2017 3:48 PM > To: Ander Conselvan De Oliveira ; intel- > g...@lists.freedesktop.org > Cc: Chauhan, Madhav ; Ville Syrjälä > > Subject: Re:

Re: [Intel-gfx] [PATCH 08/15] drm/i915: Nuke intel_atomic_legacy_gamma_set

Op 03-04-17 om 10:32 schreef Daniel Vetter: > We do set DRIVER_ATOMIC now. > > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/i915/intel_display.c | 44 > +--- > 1 file changed, 1 insertion(+), 43 deletions(-) > > diff --git

[Intel-gfx] [PATCH] drm/atomic: Acquire connection_mutex lock in drm_helper_probe_single_connector_modes, v2.

mode_valid() called from drm_helper_probe_single_connector_modes() may need to look at connector->state because what a valid mode is may depend on connector properties being set. For example some HDMI modes might be rejected when a connector property forces the connector into DVI mode. Some

[Intel-gfx] ✓ Fi.CI.BAT: success for hmm

== Series Details == Series: hmm URL : https://patchwork.freedesktop.org/series/22419/ State : success == Summary == Series 22419v1 hmm https://patchwork.freedesktop.org/api/1.0/series/22419/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc:

Re: [Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround

On Tue, Apr 04, 2017 at 10:27:57AM +, Chauhan, Madhav wrote: > > -Original Message- > > From: Nikula, Jani > > Sent: Tuesday, April 4, 2017 3:48 PM > > To: Ander Conselvan De Oliveira ; intel- > > g...@lists.freedesktop.org > > Cc: Chauhan, Madhav

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Apply a cond_resched() to the saturated signaler (rev2)

== Series Details == Series: drm/i915: Apply a cond_resched() to the saturated signaler (rev2) URL : https://patchwork.freedesktop.org/series/22418/ State : success == Summary == Series 22418v2 drm/i915: Apply a cond_resched() to the saturated signaler

Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_atomic_allow_modeset: Add DRM_MODE_ATOMIC_ALLOW_MODESET test

Hey, Op 04-04-17 om 13:59 schreef Mika Kahola: > When doing a full atomic modeset, kernel should fail if the flag > DRM_MODE_ATOMIC_ALLOW_MODESET is not set. Let's add this test as part of > Intel-GPU-Tools. The test procedure is the following: > > - Try to do atomic commit without

Re: [Intel-gfx] [PATCH] drm/i915: Park the signaler before sleeping

On Tue, Apr 04, 2017 at 10:57:15AM +0100, Tvrtko Ursulin wrote: > > On 03/04/2017 11:51, Chris Wilson wrote: > >If the signal to park arrives before we sleep, then we need to check > >kthread_should_park() before sleeping to avoid missing the signal. > >Otherwise, if the signal arrives whilst we

Re: [Intel-gfx] [PATCH v2] drm/i915: Apply a cond_resched() to the saturated signaler

On 04/04/2017 13:05, Chris Wilson wrote: If the engine is continually completing nops, we can saturate the signaler and keep it working indefinitely. This angers the NMI watchdog! A good example is to disable semaphores on snb and run igt/gem_exec_nop - the parallel, multi-engine workloads are

  1   2   >