[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm: Plumb modifiers through plane init

== Series Details == Series: series starting with [1/3] drm: Plumb modifiers through plane init URL : https://patchwork.freedesktop.org/series/23862/ State : success == Summary == Series 23862v1 Series without cover letter

[Intel-gfx] [PATCH 3/3] drm/i915: Add format modifiers for Intel

This was based on a patch originally by Kristian. It has been modified pretty heavily to use the new callbacks from the previous patch. v2: - Add LINEAR and Yf modifiers to list (Ville) - Combine i8xx and i965 into one list of formats (Ville) - Allow 1010102 formats for Y/Yf tiled (Ville)

[Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob

Updated blob layout (Rob, Daniel, Kristian, xerpi) Cc: Rob Clark Cc: Daniel Stone Cc: Kristian H. Kristensen Signed-off-by: Ben Widawsky --- drivers/gpu/drm/drm_mode_config.c | 7 +++

[Intel-gfx] [PATCH 1/3] drm: Plumb modifiers through plane init

v2: A minor addition from Daniel Cc: Daniel Stone Signed-off-by: Ben Widawsky --- drivers/gpu/drm/arc/arcpgu_crtc.c | 1 + drivers/gpu/drm/arm/hdlcd_crtc.c| 1 + drivers/gpu/drm/arm/malidp_planes.c | 2 +-

Re: [Intel-gfx] [PATCH RESEND v4 6/6] drm/i915: Set PWM divider to match desired frequency in vbt

On Wed, May 03, 2017 at 02:15:06AM +, Pandiyan, Dhinakaran wrote: > On Tue, 2017-04-18 at 16:48 -0700, Puthikorn Voravootivat wrote: > > Read desired PWM frequency from panel vbt and calculate the > > value for divider in DPCD address 0x724 and 0x728 to match > > that frequency as close as

Re: [Intel-gfx] [PATCH RESEND v4 3/6] drm/i915: Support dynamic backlight via DPCD register

On Tue, 2017-04-18 at 16:48 -0700, Puthikorn Voravootivat wrote: > This patch enables dynamic backlight by default for eDP > panel that supports this feature via DPCD register and > set minimum / maximum brightness to 0% and 100% of the > normal brightness. What does dynamic backlight do? I am

Re: [Intel-gfx] [PATCH RESEND v4 6/6] drm/i915: Set PWM divider to match desired frequency in vbt

On Tue, 2017-04-18 at 16:48 -0700, Puthikorn Voravootivat wrote: > Read desired PWM frequency from panel vbt and calculate the > value for divider in DPCD address 0x724 and 0x728 to match > that frequency as close as possible. > > Signed-off-by: Puthikorn Voravootivat > ---

Re: [Intel-gfx] [PATCH RESEND v4 2/6] drm/i915: Correctly enable blacklight adjustment via DPCD

On Tue, Apr 18, 2017 at 04:48:20PM -0700, Puthikorn Voravootivat wrote: > intel_dp_aux_enable_backlight() assumed that the register > BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has value 01 > (DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET) when initialize. > > This patch fixed that by handling all cases

Re: [Intel-gfx] [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

>-Original Message- >From: Gerd Hoffmann [mailto:kra...@redhat.com] >Sent: Tuesday, May 02, 2017 5:51 PM >To: Chen, Xiaoguang >Cc: alex.william...@redhat.com; intel-gfx@lists.freedesktop.org; intel-gvt- >d...@lists.freedesktop.org; Wang, Zhi A

Re: [Intel-gfx] [PATCH RESEND v4 5/6] drm: Add definition for eDP backlight frequency

On Tue, Apr 18, 2017 at 04:48:23PM -0700, Puthikorn Voravootivat wrote: Since this adds definitions in the DRM layer, you need to copy the dri-de...@lists.freedesktop.org M-L. > This patch adds the following definition > - Bit mask for EDP_PWMGEN_BIT_COUNT and min/max cap > register which only

Re: [Intel-gfx] [PATCH RESEND v4 1/6] drm/i915: Add DPCD preferred mode for backlight control

On Wed, 2017-05-03 at 00:54 +, Pandiyan, Dhinakaran wrote: > Sorry for the wait. This is not a complete review, just some quick > comments for now. > > > On Tue, 2017-04-18 at 16:48 -0700, Puthikorn Voravootivat wrote: > > Currently the intel_dp_aux_backlight driver requires eDP panel > > to

Re: [Intel-gfx] [PATCH RESEND v4 2/6] drm/i915: Correctly enable blacklight adjustment via DPCD

Adjusting "blacklight" probably won't make a lot of difference even if done correctly:) Typo in the patch subject. -DK On Tue, 2017-04-18 at 16:48 -0700, Puthikorn Voravootivat wrote: > intel_dp_aux_enable_backlight() assumed that the register > BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: return the actual aperture size under gvt environment (rev3)

== Series Details == Series: drm/i915/gvt: return the actual aperture size under gvt environment (rev3) URL : https://patchwork.freedesktop.org/series/22910/ State : success == Summary == Series 22910v3 drm/i915/gvt: return the actual aperture size under gvt environment

[Intel-gfx] [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt environment

I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace. In gvt environment, each vm only use the ballooned part of aperture, so we should return the actual available aperture size exclude the reserved part by balloon. v2: add 'reserved' in struct i915_address_space to record

Re: [Intel-gfx] [PATCH RESEND v4 2/6] drm/i915: Correctly enable blacklight adjustment via DPCD

On Tue, 2017-04-18 at 16:48 -0700, Puthikorn Voravootivat wrote: > intel_dp_aux_enable_backlight() assumed that the register > BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has value 01 > (DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET) when initialize. > > This patch fixed that by handling all cases of that

Re: [Intel-gfx] [PATCH RESEND v4 1/6] drm/i915: Add DPCD preferred mode for backlight control

Sorry for the wait. This is not a complete review, just some quick comments for now. On Tue, 2017-04-18 at 16:48 -0700, Puthikorn Voravootivat wrote: > Currently the intel_dp_aux_backlight driver requires eDP panel > to not also support backlight adjustment via PWM pin to use > this driver. > >

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915: Mark up clflushes as belonging to an unordered timeline

== Series Details == Series: series starting with [1/7] drm/i915: Mark up clflushes as belonging to an unordered timeline URL : https://patchwork.freedesktop.org/series/23853/ State : success == Summary == Series 23853v1 Series without cover letter

[Intel-gfx] [PATCH 4/7] drm/i915: Squash repeated awaits on the same fence

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

[Intel-gfx] [PATCH 2/7] drm/i915: Unwrap top level fence-array

By first unwrapping an incoming fence-array into its child fences, we can simplify the internal branching, and so avoid triggering a potential in the next patch when not squashing the child fences on the same timeline. It will also have the advantage of keeping the (top-level) fence arrays out of

[Intel-gfx] [PATCH 7/7] drm/i915: Switch the global i915.semaphores check to a local predicate

Rather than use a global modparam, we can just check to see if the engine has semaphores configured upon it. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem_request.c | 4 +++- 1 file changed,

[Intel-gfx] [PATCH 5/7] drm/i915: Rename intel_timeline.sync_seqno[] to .global_sync[]

With the addition of the inter-context intel_time.sync map, having a very similar sync_seqno[] is confusing. Aide the reader by denoting that this a pre-allocated array for storing semaphore sync points wrt to the global seqno. Signed-off-by: Chris Wilson Reviewed-by:

[Intel-gfx] [PATCH 1/7] drm/i915: Mark up clflushes as belonging to an unordered timeline

2 clflushes on two different objects are not ordered, and so do not belong to the same timeline (context). Either we use a unique context for each, or we reserve a special global context to mean unordered. Ideally, we would reserve 0 to mean unordered (DMA_FENCE_NO_CONTEXT) to have the same

[Intel-gfx] [PATCH 6/7] drm/i915: Do not record a successful syncpoint for a dma-await

As we may unwind the requests, even though the request we are awaiting has a global_seqno that seqno may be revoked during the await and so we can not reliably use it as a barrier for all future awaits on the same timeline. Signed-off-by: Chris Wilson Cc: Michał

[Intel-gfx] [PATCH 3/7] drm/i915: Lift timeline ordering to await_dma_fence

Currently we filter out repeated use of the same timeline in the low level i915_gem_request_await_request(), after having added the dependency on the old request. However, we can lift this to i915_gem_request_await_dma_fence() (before the dependency is added) using the observation that requests

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Allow the UMD to configure their own power clock state

== Series Details == Series: drm/i915: Allow the UMD to configure their own power clock state URL : https://patchwork.freedesktop.org/series/23846/ State : success == Summary == Series 23846v1 drm/i915: Allow the UMD to configure their own power clock state

Re: [Intel-gfx] [PATCH] drm/i915: New vfunc prepare_request

On 05/02/2017 08:59 AM, Chris Wilson wrote: On Mon, May 01, 2017 at 07:28:12AM +, Oscar Mateo wrote: On 04/29/2017 08:31 AM, Chris Wilson wrote: On Fri, Apr 28, 2017 at 05:26:09PM +, Oscar Mateo wrote: This will be more useful later to support platforms that need to emit HW

[Intel-gfx] [RFC] drm/i915: Allow the UMD to configure their own power clock state

This allows userspace to shutdown slices at will for performance/power reasons (because it doesn't have a use for more slices). Cc: Dmitry Rogozhkin Cc: Chris Wilson Signed-off-by: Oscar Mateo ---

[Intel-gfx] [RFC] tests/pm_sseu: Add subtest to verify UMD can configure render powerclock state

Cc: Dmitry Rogozhkin Cc: Chris Wilson Signed-off-by: Oscar Mateo --- tests/pm_sseu.c | 105 1 file changed, 105 insertions(+) diff --git a/tests/pm_sseu.c

[Intel-gfx] [RFC] benchmarks/gem_slice_shutdown: microbenchmark for slice shutdown delays

Cc: Dmitry Rogozhkin Cc: Chris Wilson Signed-off-by: Oscar Mateo --- benchmarks/Makefile.sources | 1 + benchmarks/gem_slice_shutdown.c | 295 2 files changed, 296

Re: [Intel-gfx] [RFC 4/4] drm/i915: Expose RPCS (SSEU) configuration to userspace

On 05/02/2017 07:55 PM, Chris Wilson wrote: On Tue, May 02, 2017 at 10:33:19AM +, Oscar Mateo wrote: On 05/02/2017 11:49 AM, Chris Wilson wrote: We want to allow userspace to reconfigure the subslice configuration for its own use case. To do so, we expose a context parameter to allow

[Intel-gfx] [PATCH v10 12/15] drm/i915/perf: Add OA unit support for Gen 8+

From: Robert Bragg Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all share (more-or-less) the same OA unit design. Of particular note in comparison to Haswell: some OA unit HW config state has become per-context state and as a consequence it is somewhat

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Move notification code into virtual function

On Tue, May 02, 2017 at 09:37:45AM -0700, Daniele Ceraolo Spurio wrote: > > > On 02/05/17 05:39, Michal Wajdeczko wrote: > > Prepare for alternate GuC notification mechanism. > > > > Signed-off-by: Michal Wajdeczko > > Cc: Joonas Lahtinen

[Intel-gfx] Overscan problem : Intel HD Graphics 610 + Wayland + Fedora 25

Hello, I would like to thank you for the good driver you provide. There is only one thing missing for my complete joy...I would like to know how to adjust overcan parameter (dunno if it's the right word : the output display is a little bit larger than the physical screen by maybe an inch

Re: [Intel-gfx] [PATCH v4 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

On Tuesday, May 02, 2017 03:04:08 PM Imre Deak wrote: > Some drivers - like i915 - may not support the system suspend direct > complete optimization due to differences in their runtime and system > suspend sequence. Add a flag that when set resumes the device before > calling the driver's system

Re: [Intel-gfx] [PATCH v3 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

On Tuesday, May 02, 2017 12:05:38 PM Imre Deak wrote: > On Mon, May 01, 2017 at 10:36:13PM +0200, Rafael J. Wysocki wrote: > > On Sunday, April 30, 2017 03:57:13 PM Imre Deak wrote: > > > On Sat, Apr 29, 2017 at 12:21:57PM +0200, Rafael J. Wysocki wrote: > > > > On Friday, April 28, 2017 11:33:02

Re: [Intel-gfx] [alsa-devel] [PATCH v2 00/11] drm/i915: LPE audio runtime PM and multipipe (v2)

On Tue, 02 May 2017 22:15:20 +0200, Pierre-Louis Bossart wrote: > > On 5/2/17 1:27 PM, Ville Syrjälä wrote: > > On Mon, May 01, 2017 at 08:29:10PM -0500, Pierre-Louis Bossart wrote: > >> > >> > >> On 04/28/2017 02:37 PM, Ville Syrjälä wrote: > >>> On Fri, Apr 28, 2017 at 12:10:31PM -0500,

Re: [Intel-gfx] [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform

On Tue, May 02, 2017 at 10:02:07AM -0700, Laura Abbott wrote: > The existing drm_gem_prime_import function uses the underlying > struct device of a drm_device for attaching to a dma_buf. Some drivers > (notably vgem) may not have an underlying device structure. Offer > an alternate function to

Re: [Intel-gfx] [alsa-devel] [PATCH v2 00/11] drm/i915: LPE audio runtime PM and multipipe (v2)

On 5/2/17 1:27 PM, Ville Syrjälä wrote: On Mon, May 01, 2017 at 08:29:10PM -0500, Pierre-Louis Bossart wrote: On 04/28/2017 02:37 PM, Ville Syrjälä wrote: On Fri, Apr 28, 2017 at 12:10:31PM -0500, Pierre-Louis Bossart wrote: On 04/28/2017 03:41 AM, Takashi Iwai wrote: On Thu, 27 Apr 2017

Re: [Intel-gfx] [PATCH v9 12/15] drm/i915/perf: Add OA unit support for Gen 8+

On Mon, May 01, 2017 at 06:17:09PM -0700, Lionel Landwerlin wrote: Focusing on the bit I know best and leaving the hw mumbo jumbo to one side... > +static int gen8_configure_all_contexts(struct drm_i915_private *dev_priv) > +{ > + struct intel_engine_cs *engine = dev_priv->engine[RCS]; > +

Re: [Intel-gfx] [RFC 4/4] drm/i915: Expose RPCS (SSEU) configuration to userspace

On Tue, May 02, 2017 at 10:33:19AM +, Oscar Mateo wrote: > > > On 05/02/2017 11:49 AM, Chris Wilson wrote: > >We want to allow userspace to reconfigure the subslice configuration for > >its own use case. To do so, we expose a context parameter to allow > >adjustment of the RPCS register

Re: [Intel-gfx] [RFC 2/4] drm/i915: Program RPCS for Broadwell

On 02/05/17 04:49, Chris Wilson wrote: Currently we only configure the power gating for Skylake and above, but the configuration should equally apply to Broadwell and Braswell. Even though, there is not as much variation as for later generations, we want to expose control over the configuration

Re: [Intel-gfx] [alsa-devel] [PATCH v2 00/11] drm/i915: LPE audio runtime PM and multipipe (v2)

On Mon, May 01, 2017 at 08:29:10PM -0500, Pierre-Louis Bossart wrote: > > > On 04/28/2017 02:37 PM, Ville Syrjälä wrote: > > On Fri, Apr 28, 2017 at 12:10:31PM -0500, Pierre-Louis Bossart wrote: > >> > >> On 04/28/2017 03:41 AM, Takashi Iwai wrote: > >>> On Thu, 27 Apr 2017 18:02:19 +0200, > >>>

[Intel-gfx] [maintainer-tools PATCH v2] dim: Add pull request tag headers

Add some standard headers to the pull request tag annotation. Changes in v2: - Tweaked the template var name s/PULL/TAG/ (Daniel) Signed-off-by: Sean Paul --- dim | 25 - dim.rst | 4 2 files changed, 28 insertions(+), 1 deletion(-)

Re: [Intel-gfx] [RFC 4/4] drm/i915: Expose RPCS (SSEU) configuration to userspace

On 05/02/2017 11:49 AM, Chris Wilson wrote: We want to allow userspace to reconfigure the subslice configuration for its own use case. To do so, we expose a context parameter to allow adjustment of the RPCS register stored within the context image (and currently not accessible via LRI).

[Intel-gfx] ✓ Fi.CI.BAT: success for dma_buf import support for vgem

== Series Details == Series: dma_buf import support for vgem URL : https://patchwork.freedesktop.org/series/23824/ State : success == Summary == Series 23824v1 dma_buf import support for vgem https://patchwork.freedesktop.org/api/1.0/series/23824/revisions/1/mbox/ Test gem_exec_suspend:

[Intel-gfx] [PATCHv3 3/3] drm/vgem: Enable dmabuf import interfaces

Enable the GEM dma-buf import interfaces in addition to the export interfaces. This lets vgem be used as a test source for other allocators (e.g. Ion). Cc: intel-gfx@lists.freedesktop.org Reviewed-by: Chris Wilson Signed-off-by: Laura Abbott --- v3:

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Prevent the system suspend complete optimization

On Tue, May 02, 2017 at 06:51:01PM +0200, Daniel Vetter wrote: > On Tue, May 02, 2017 at 03:04:09PM +0300, Imre Deak wrote: > > Since > > > > commit bac2a909a096c9110525c18cbb8ce73c660d5f71 > > Author: Rafael J. Wysocki > > Date: Wed Jan 21 02:17:42 2015 +0100 > >

[Intel-gfx] [PATCHv3 2/3] drm/prime: Introduce drm_gem_prime_import_platform

The existing drm_gem_prime_import function uses the underlying struct device of a drm_device for attaching to a dma_buf. Some drivers (notably vgem) may not have an underlying device structure. Offer an alternate function to attach using a platform device associated with drm_device. Cc:

[Intel-gfx] [PATCHv3 1/3] drm/vgem: Add a dummy platform device

The vgem driver is currently registered independent of any actual device. Some usage of the dmabuf APIs require an actual device structure to do anything. Register a dummy platform device for use with dmabuf. Cc: intel-gfx@lists.freedesktop.org Reviewed-by: Chris Wilson

[Intel-gfx] [PATCHv3 0/3] dma_buf import support for vgem

Hi, This is v3 of the series to add dma_buf import functions for vgem. This is mostly a rebase to drm-misc/drm-misc-next with a fixup of the resulting conflicts. More details can be found on the individual patches. Thanks, Laura Laura Abbott (3): drm/vgem: Add a dummy platform device

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Make scratch register base and count flexible

On 02/05/17 05:39, Michal Wajdeczko wrote: We are using some scratch registers in MMIO based send function. Make their base and count flexible in preparation of upcoming GuC firmware/hardware changes. Signed-off-by: Michal Wajdeczko Suggested-by: Daniele Ceraolo

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Prevent the system suspend complete optimization

On Tue, May 02, 2017 at 03:04:09PM +0300, Imre Deak wrote: > Since > > commit bac2a909a096c9110525c18cbb8ce73c660d5f71 > Author: Rafael J. Wysocki > Date: Wed Jan 21 02:17:42 2015 +0100 > > PCI / PM: Avoid resuming PCI devices during system suspend > > PCI

Re: [Intel-gfx] [PATCH 1/3] drm/i915/guc: Move notification code into virtual function

On 02/05/17 05:39, Michal Wajdeczko wrote: Prepare for alternate GuC notification mechanism. Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Daniele Ceraolo Spurio ---

Re: [Intel-gfx] [PATCH] drm/i915: Allow null render state batchbuffers bigger than one page

On 05/02/2017 09:17 AM, Mika Kuoppala wrote: Chris Wilson writes: On Fri, Apr 28, 2017 at 09:11:06AM +, Oscar Mateo wrote: The new batchbuffer for CNL surpasses the 4096 byte mark. Cc: Mika Kuoppala Cc: Ben Widawsky

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v4,1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

On Tue, May 02, 2017 at 03:10:29PM +, Patchwork wrote: > == Series Details == > > Series: series starting with [v4,1/2] PCI / PM: Add needs_resume flag to > avoid suspend complete optimization > URL : https://patchwork.freedesktop.org/series/23803/ > State : warning > > == Summary == > >

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

== Series Details == Series: series starting with [v4,1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization URL : https://patchwork.freedesktop.org/series/23803/ State : success == Summary == Series 23803v1 Series without cover letter

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

On 02/05/2017 15:45, Chris Wilson wrote: On Tue, May 02, 2017 at 01:24:58PM +0100, Tvrtko Ursulin wrote: On 28/04/2017 20:02, Chris Wilson wrote: + if (!p->height) { + for (bits = p->bitmap; (i = ffs(bits)); bits &= ~0u << i) { Would for_each_set_bit be more readable?

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

On Tue, May 02, 2017 at 03:45:23PM +0100, Chris Wilson wrote: > On Tue, May 02, 2017 at 01:24:58PM +0100, Tvrtko Ursulin wrote: > > On 28/04/2017 20:02, Chris Wilson wrote: > > >+ if (!p->height) { > > >+ for (bits = p->bitmap; (i = ffs(bits)); bits &= ~0u << i) { > > > > Would

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v4,1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

== Series Details == Series: series starting with [v4,1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization URL : https://patchwork.freedesktop.org/series/23803/ State : warning == Summary == Series 23803v1 Series without cover letter

Re: [Intel-gfx] [maintainer-tools PATCH] dim: Add pull request tag headers

On Tue, May 2, 2017 at 10:55 AM, Sean Paul wrote: > Add some standard headers to the pull request tag annotation. > > Signed-off-by: Sean Paul > --- This time to Daniel's actual address. Note that I couldn't add the headers as comments since git

[Intel-gfx] [maintainer-tools PATCH] dim: Add pull request tag headers

Add some standard headers to the pull request tag annotation. Signed-off-by: Sean Paul --- dim | 25 - dim.rst | 4 2 files changed, 28 insertions(+), 1 deletion(-) diff --git a/dim b/dim index 8937803..0d52e9d 100755 --- a/dim +++ b/dim

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

On Tue, May 02, 2017 at 01:24:58PM +0100, Tvrtko Ursulin wrote: > On 28/04/2017 20:02, Chris Wilson wrote: > >+prandom_seed_state(, i915_selftest.random_seed); > >+count = 0; > >+kt = ktime_get(); > >+end_time = jiffies + HZ/10; > >+do { > >+u32 id =

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

On Tue, May 02, 2017 at 01:24:58PM +0100, Tvrtko Ursulin wrote: > On 28/04/2017 20:02, Chris Wilson wrote: > >+if (!p->height) { > >+for (bits = p->bitmap; (i = ffs(bits)); bits &= ~0u << i) { > > Would for_each_set_bit be more readable? Downside is that we have to cast bitmap to

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework (rev4)

== Series Details == Series: series starting with [1/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework (rev4) URL : https://patchwork.freedesktop.org/series/22571/ State : success == Summary == Series 22571v4 Series without cover letter

[Intel-gfx] [PATCH 2/2] drm/i915: Use wait_for_atomic_us when waiting for gt fifo

From: Mika Kuoppala Replace the handcrafter loop when checking for fifo slots with atomic wait for. This brings this wait in line with the other waits on register access. We also get a readable timeout constraint, so make it to fail after 10ms. Chris suggested

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/guc: Move notification code into virtual function

== Series Details == Series: series starting with [1/3] drm/i915/guc: Move notification code into virtual function URL : https://patchwork.freedesktop.org/series/23805/ State : success == Summary == Series 23805v1 Series without cover letter

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v4,1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

On Tue, May 02, 2017 at 01:21:41PM +, Patchwork wrote: > == Series Details == > > Series: series starting with [v4,1/2] PCI / PM: Add needs_resume flag to > avoid suspend complete optimization > URL : https://patchwork.freedesktop.org/series/23803/ > State : failure > > == Summary == > >

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework

== Series Details == Series: series starting with [CI,1/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework URL : https://patchwork.freedesktop.org/series/23804/ State : success == Summary == Series 23804v1 Series without cover letter

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v4,1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

== Series Details == Series: series starting with [v4,1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization URL : https://patchwork.freedesktop.org/series/23803/ State : failure == Summary == Series 23803v1 Series without cover letter

[Intel-gfx] [PATCH 3/3] HAX Enable GuC loading & submission

This is just for CI testing, *** DO NOT MERGE *** Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c

[Intel-gfx] [PATCH 2/3] drm/i915/guc: Make scratch register base and count flexible

We are using some scratch registers in MMIO based send function. Make their base and count flexible in preparation of upcoming GuC firmware/hardware changes. Signed-off-by: Michal Wajdeczko Suggested-by: Daniele Ceraolo Spurio Cc:

[Intel-gfx] [PATCH 1/3] drm/i915/guc: Move notification code into virtual function

Prepare for alternate GuC notification mechanism. Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen Cc: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/intel_uc.c | 10 +-

[Intel-gfx] [CI 2/2] drm/i915: Use wait_for_atomic_us when waiting for gt fifo

From: Mika Kuoppala Replace the handcrafter loop when checking for fifo slots with atomic wait for. This brings this wait in line with the other waits on register access. We also get a readable timeout constraint, so make it to fail after 10ms. Chris suggested

[Intel-gfx] [CI 1/2] drm/i915: Move the GTFIFODBG to the common mmio dbg framework

From: Mika Kuoppala Remove the per-mmio checking of the FIFO debug register into the common conditional mmio debug handling. Based on patch from Chris Wilson. v2: postpone warn on fifodbg for unclaimed reg debugs Signed-off-by: Mika Kuoppala

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

On 28/04/2017 20:02, 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

Re: [Intel-gfx] [RFC 2/4] drm/i915: Program RPCS for Broadwell

On ti, 2017-05-02 at 12:49 +0100, Chris Wilson wrote: > Currently we only configure the power gating for Skylake and above, but > the configuration should equally apply to Broadwell and Braswell. Even > though, there is not as much variation as for later generations, we want > to expose control

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Do not leak dev_priv->l3_parity.remap_info[]

On pe, 2017-04-28 at 10:46 +, Patchwork wrote: > == Series Details == > > Series: drm/i915: Do not leak dev_priv->l3_parity.remap_info[] > URL   : https://patchwork.freedesktop.org/series/23679/ > State : success Merged the patch. Thanks for the review. > == Summary == > > Series 23679v1

Re: [Intel-gfx] [RFC 1/4] drm/i915: Record both min/max eu_per_subslice in sseu_dev_info

On ti, 2017-05-02 at 12:49 +0100, Chris Wilson wrote: > When we query the available eu on each subslice, we currently only > report the max. It would also be useful to report the minimum found as > well. > > When we set RPCS (power gating over the EU), we can also specify both > the min and max

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RFC,1/4] drm/i915: Record both min/max eu_per_subslice in sseu_dev_info

== Series Details == Series: series starting with [RFC,1/4] drm/i915: Record both min/max eu_per_subslice in sseu_dev_info URL : https://patchwork.freedesktop.org/series/23802/ State : success == Summary == Series 23802v1 Series without cover letter

Re: [Intel-gfx] [CI 1/2] drm/i915/guc: Enable send function only after successful init

On Tue, May 02, 2017 at 10:32:42AM +, Michal Wajdeczko wrote: > It is safer to setup valid send function after successful GuC > hardware initialization. In addition we prepare placeholder > where we can setup any alternate GuC communication mechanism. > > Signed-off-by: Michal Wajdeczko

[Intel-gfx] [PATCH v4 2/2] drm/i915: Prevent the system suspend complete optimization

Since commit bac2a909a096c9110525c18cbb8ce73c660d5f71 Author: Rafael J. Wysocki Date: Wed Jan 21 02:17:42 2015 +0100 PCI / PM: Avoid resuming PCI devices during system suspend PCI devices will default to allowing the system suspend complete optimization where

[Intel-gfx] [PATCH v4 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

Some drivers - like i915 - may not support the system suspend direct complete optimization due to differences in their runtime and system suspend sequence. Add a flag that when set resumes the device before calling the driver's system suspend handlers which effectively disables the optimization.

[Intel-gfx] [RFC 3/4] drm/i915: Record the sseu configuration per-context

In the next patch, we will expose the ability to reconfigure the slices, subslice and eu per context. To facilitate that, store the current configuration on the context, which is initially set to the device default upon creation. Signed-off-by: Chris Wilson ---

[Intel-gfx] [RFC 2/4] drm/i915: Program RPCS for Broadwell

Currently we only configure the power gating for Skylake and above, but the configuration should equally apply to Broadwell and Braswell. Even though, there is not as much variation as for later generations, we want to expose control over the configuration to userspace and may want to opt out of

[Intel-gfx] [RFC 1/4] drm/i915: Record both min/max eu_per_subslice in sseu_dev_info

When we query the available eu on each subslice, we currently only report the max. It would also be useful to report the minimum found as well. When we set RPCS (power gating over the EU), we can also specify both the min and max number of eu to configure on each slice; currently we just set it

[Intel-gfx] [RFC 4/4] drm/i915: Expose RPCS (SSEU) configuration to userspace

We want to allow userspace to reconfigure the subslice configuration for its own use case. To do so, we expose a context parameter to allow adjustment of the RPCS register stored within the context image (and currently not accessible via LRI). If the context is adjusted before first use, the

Re: [Intel-gfx] [PATCH v6 02/12] drm/atomic: Add support for custom scaling mode properties, v2

Op 02-05-17 om 11:44 schreef Daniel Vetter: > On Mon, May 01, 2017 at 03:37:54PM +0200, Maarten Lankhorst wrote: >> Some connectors may not allow all scaling mode properties, this function >> will allow >> creating the scaling mode property with only the supported subset. It also >> wires up >>

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915/guc: Enable send function only after successful init

== Series Details == Series: series starting with [CI,1/2] drm/i915/guc: Enable send function only after successful init URL : https://patchwork.freedesktop.org/series/23799/ State : success == Summary == Series 23799v1 Series without cover letter

[Intel-gfx] [CI 1/2] drm/i915/guc: Enable send function only after successful init

It is safer to setup valid send function after successful GuC hardware initialization. In addition we prepare placeholder where we can setup any alternate GuC communication mechanism. Signed-off-by: Michal Wajdeczko Cc: Joonas Lahtinen

[Intel-gfx] [CI 2/2] HAX Enable GuC loading & submission

This is just for CI testing, *** DO NOT MERGE *** Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: disable GVT-g if host GuC submission is enabled

== Series Details == Series: drm/i915/gvt: disable GVT-g if host GuC submission is enabled URL : https://patchwork.freedesktop.org/series/23796/ State : success == Summary == Series 23796v1 drm/i915/gvt: disable GVT-g if host GuC submission is enabled

Re: [Intel-gfx] [PATCH v6 05/12] drm/i915: Add plumbing for digital connector state, v3.

On Mon, May 01, 2017 at 03:37:57PM +0200, Maarten Lankhorst wrote: > Some atomic properties are common between the various kinds of > connectors, for example a lot of them use panel fitting mode. > It makes sense to put a lot of it in a common place, so each > connector can use it while they're

Re: [Intel-gfx] [PATCH v6 01/12] drm/atomic: Handle picture_aspect_ratio in atomic core

On Mon, May 01, 2017 at 03:37:53PM +0200, Maarten Lankhorst wrote: > This is only used in i915, which had used its own non-taomic way to > deal with the picture aspect ratio. Move selected aspect_ratio to > atomic state and use the atomic state in the affected i915 connectors. > > Signed-off-by:

Re: [Intel-gfx] [PATCH i-g-t 05/13] chamelium: Fix build issues on Android

On Wed, Apr 19, 2017 at 01:01:47PM +0200, Arkadiusz Hiler wrote: > Also igt_chamelium.h included config.h without proper "HAVE_CONFIG_H" > guard, and the file itself was included unconditionally. I see unconditional config.h inclusion in several other places, is igt_chamelium.h the only file

Re: [Intel-gfx] [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

On Fr, 2017-04-28 at 17:35 +0800, Xiaoguang Chen wrote: > +static size_t intel_vgpu_reg_rw_gvtg(struct intel_vgpu *vgpu, char > *buf, > + size_t count, loff_t *ppos, bool iswrite) > +{ > + unsigned int i = VFIO_PCI_OFFSET_TO_INDEX(*ppos) - > +

Re: [Intel-gfx] [PATCH v6 02/12] drm/atomic: Add support for custom scaling mode properties, v2

On Mon, May 01, 2017 at 03:37:54PM +0200, Maarten Lankhorst wrote: > Some connectors may not allow all scaling mode properties, this function will > allow > creating the scaling mode property with only the supported subset. It also > wires up > this state for atomic. > > This will make it

Re: [Intel-gfx] [RFC PATCH 5/6] drm/i915/gvt: dmabuf support for GVT-g

Hi, > > +#ifndef _GVT_DMABUF_H_ > > +#define _GVT_DMABUF_H_ > > + > > +#define INTEL_VGPU_QUERY_DMABUF0 > > +#define INTEL_VGPU_GENERATE_DMABUF 1 > > + > > +struct intel_vgpu_dmabuf { > > This looks to be uapi. What's it doing here? It is indeed, should go to include/uapi/

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

On Tue, May 2, 2017 at 10:55 AM, Arnd Bergmann wrote: > On Tue, May 2, 2017 at 10:41 AM, Stephen Rothwell > wrote: >> Hi Daniel, >> >> On Tue, 2 May 2017 10:25:18 +0200 Daniel Vetter wrote: >>> >>> Since this is an all-new driver it might

Re: [Intel-gfx] [PATCH] drm/i915: Allow null render state batchbuffers bigger than one page

Chris Wilson writes: > On Fri, Apr 28, 2017 at 09:11:06AM +, Oscar Mateo wrote: >> The new batchbuffer for CNL surpasses the 4096 byte mark. >> >> Cc: Mika Kuoppala >> Cc: Ben Widawsky >> Signed-off-by: Oscar Mateo

Re: [Intel-gfx] [PATCH v3 1/2] PCI / PM: Add needs_resume flag to avoid suspend complete optimization

On Mon, May 01, 2017 at 10:36:13PM +0200, Rafael J. Wysocki wrote: > On Sunday, April 30, 2017 03:57:13 PM Imre Deak wrote: > > On Sat, Apr 29, 2017 at 12:21:57PM +0200, Rafael J. Wysocki wrote: > > > On Friday, April 28, 2017 11:33:02 PM Rafael J. Wysocki wrote: > > > > On Friday, April 28, 2017

  1   2   >