Re: [Intel-gfx] [PATCH v6 6/6] drm/i915/gvt: Adding interface so user space can get the dma-buf

On Fri, 2 Jun 2017 03:24:35 + "Chen, Xiaoguang" wrote: > Hi Alex, > > >-Original Message- > >From: Alex Williamson [mailto:alex.william...@redhat.com] > >Sent: Friday, June 02, 2017 2:08 AM > >To: Chen, Xiaoguang > >Cc:

Re: [Intel-gfx] [PATCH v6 6/6] drm/i915/gvt: Adding interface so user space can get the dma-buf

Hi Alex, >-Original Message- >From: Alex Williamson [mailto:alex.william...@redhat.com] >Sent: Friday, June 02, 2017 2:08 AM >To: Chen, Xiaoguang >Cc: kra...@redhat.com; ch...@chris-wilson.co.uk; intel- >g...@lists.freedesktop.org; linux-ker...@vger.kernel.org;

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/dp: Generalize intel_dp_link_params function to accept arguments to be validated

== Series Details == Series: series starting with [1/2] drm/i915/dp: Generalize intel_dp_link_params function to accept arguments to be validated URL : https://patchwork.freedesktop.org/series/25191/ State : success == Summary == Series 25191v1 Series without cover letter

[Intel-gfx] [PATCH 1/2] drm/i915/dp: Generalize intel_dp_link_params function to accept arguments to be validated

This function now takes the link rate and lane ocunt to be validated as an argument so that this can be used for validating even the compliance test link parameters. Signed-off-by: Manasi Navare Cc: Ville Syrjala Cc: Jani Nikula

[Intel-gfx] [PATCH 2/2] drm/i915/dp: Validate the compliance test link parameters

Validate the compliance test link parameters when the compliance test dpcd registers are read. Also validate them in compute_config before using them since the max values might have been reduced due to link training fallback. Signed-off-by: Manasi Navare ---

Re: [Intel-gfx] [PATCH 07/13] drm/i915/cfl: Introduce Coffee Lake platform definition.

>-Original Message- >From: Vivi, Rodrigo >Sent: Thursday, June 1, 2017 4:20 PM >To: Srivatsa, Anusha >Cc: intel-gfx@lists.freedesktop.org; rodrigo.v...@gmail.com >Subject: Re: [Intel-gfx] [PATCH 07/13] drm/i915/cfl: Introduce Coffee Lake >platform definition.

Re: [Intel-gfx] [PATCH 07/13] drm/i915/cfl: Introduce Coffee Lake platform definition.

On Thu, 2017-06-01 at 23:14 +, Srivatsa, Anusha wrote: > > >-Original Message- > >From: Rodrigo Vivi [mailto:rodrigo.v...@gmail.com] > >Sent: Thursday, June 1, 2017 3:48 PM > >To: Srivatsa, Anusha > >Cc: Vivi, Rodrigo ;

Re: [Intel-gfx] [PATCH 07/13] drm/i915/cfl: Introduce Coffee Lake platform definition.

>-Original Message- >From: Rodrigo Vivi [mailto:rodrigo.v...@gmail.com] >Sent: Thursday, June 1, 2017 3:48 PM >To: Srivatsa, Anusha >Cc: Vivi, Rodrigo ; intel-gfx@lists.freedesktop.org >Subject: Re: [Intel-gfx] [PATCH 07/13]

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915/cnp: Introduce Cannonpoint PCH.

On Thu, 2017-06-01 at 22:50 +, Patchwork wrote: > == Series Details == > > Series: series starting with [1/6] drm/i915/cnp: Introduce Cannonpoint PCH. > URL : https://patchwork.freedesktop.org/series/25188/ > State : failure > > == Summary == > > Series 25188v1 Series without cover letter

Re: [Intel-gfx] [PATCH RESEND] drm: i915: Preserve old FBC status for update without new planes

The modified commit message looks good to me. Reviewed-by: Manasi Navare On Thu, Jun 01, 2017 at 12:36:08PM -0300, Gabriel Krisman Bertazi wrote: > If the atomic commit doesn't include any new plane, there is no need to > choose a new CRTC for FBC, and the

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915/cnp: Introduce Cannonpoint PCH.

== Series Details == Series: series starting with [1/6] drm/i915/cnp: Introduce Cannonpoint PCH. URL : https://patchwork.freedesktop.org/series/25188/ State : failure == Summary == Series 25188v1 Series without cover letter

Re: [Intel-gfx] [PATCH 07/13] drm/i915/cfl: Introduce Coffee Lake platform definition.

On Thu, Jun 1, 2017 at 3:27 PM, Srivatsa, Anusha wrote: > > >>-Original Message- >>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >>Rodrigo Vivi >>Sent: Tuesday, May 30, 2017 3:43 PM >>To: intel-gfx@lists.freedesktop.org >>Cc:

Re: [Intel-gfx] [PATCH 4/6] drm/i915/cnp: Backlight support for CNP.

Reviewed-by: Dhinakaran Pandiyan -DK On Thu, 2017-06-01 at 15:33 -0700, Rodrigo Vivi wrote: > Split out BXT and CNP's setup_backlight(),enable_backlight(), > disable_backlight() and hz_to_pwm() into > two separate functions instead of reusing BXT function. > >

[Intel-gfx] [PATCH 6/6] drm/i915/cnp: Panel Power sequence changes for CNP PCH.

Panel Power sequences for CNP is similar to Broxton, but with only one sequencer. Main difference from SPT is that PP_DIVISOR was removed and power cycle delay has been moved to PP_CONTROL. v2: Add missed pp_div write, that is now part of PP_CONTROL[8:4] as on Broxton. (Found by DK) v3:

[Intel-gfx] [PATCH 2/6] drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH

From: Dhinakaran Pandiyan The first two bytes of PCI ID for CNP_LP PCH are the same as that of SPT_LP. We should really be looking at the first 9 bits instead of the first 8 to identify platforms, although this seems to have not caused any problems on earlier

[Intel-gfx] [PATCH 4/6] drm/i915/cnp: Backlight support for CNP.

Split out BXT and CNP's setup_backlight(),enable_backlight(), disable_backlight() and hz_to_pwm() into two separate functions instead of reusing BXT function. Reuse set_backlight() and get_backlight() since they have no reference to the utility pin. v2: Reuse BXT functions with controller 0

[Intel-gfx] [PATCH 1/6] drm/i915/cnp: Introduce Cannonpoint PCH.

Most of south engine display that is in PCH is still the same as SPT and KBP, except for this key differences: - Backlight: Backlight programming changed in CNP PCH. - Panel Power: Sligh programming changed in CNP PCH. - GMBUS and GPIO: The pin mapping has changed in CNP PCH. All of these

[Intel-gfx] [PATCH 3/6] drm/i915/cnp: Get/set proper Raw clock frequency on CNP.

RAWCLK_FREQ register has changed for platforms with CNP+. [29:26] This field provides the denominator for the fractional part of the microsecond counter divider. The numerator is fixed at 1. Program this field to the denominator of the fractional portion of reference

[Intel-gfx] [PATCH 5/6] drm/i915/cnp: add CNP gmbus support

On CNP PCH based platforms the gmbus is on the south display that is on PCH. The existing implementation for previous platforms already covers the need for CNP expect for the pin pair configuration that follows similar definitions that we had on BXT. v2: Don't drop "_BXT" as the indicator of the

Re: [Intel-gfx] [PATCH 07/13] drm/i915/cfl: Introduce Coffee Lake platform definition.

>-Original Message- >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of >Rodrigo Vivi >Sent: Tuesday, May 30, 2017 3:43 PM >To: intel-gfx@lists.freedesktop.org >Cc: Vivi, Rodrigo >Subject: [Intel-gfx] [PATCH 07/13] drm/i915/cfl:

Re: [Intel-gfx] [PATCH] drm/i915: Remove dead code from runtime resume handler

Reviewed-by: Rodrigo Vivi On Thu, 2017-06-01 at 21:30 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Remove the SNB PCH refclock init call from the runtime resume handler. > I don't think it was actually needed even

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Fix logical inversion for gen4 quirking

== Series Details == Series: series starting with [1/6] drm/i915: Fix logical inversion for gen4 quirking URL : https://patchwork.freedesktop.org/series/25187/ State : success == Summary == Series 25187v1 Series without cover letter

[Intel-gfx] [PATCH 5/6] drm/i915/cnp: Get/set proper Raw clock frequency on CNP.

RAWCLK_FREQ register has changed for platforms with CNP+. [29:26] This field provides the denominator for the fractional part of the microsecond counter divider. The numerator is fixed at 1. Program this field to the denominator of the fractional portion of reference

[Intel-gfx] [PATCH 3/6] drm/i915/cnp: Introduce Cannonpoint PCH.

Most of south engine display that is in PCH is still the same as SPT and KBP, except for this key differences: - Backlight: Backlight programming changed in CNP PCH. - Panel Power: Sligh programming changed in CNP PCH. - GMBUS and GPIO: The pin mapping has changed in CNP PCH. All of these

[Intel-gfx] [PATCH 6/6] drm/i915/cnp: Backlight support for CNP.

Split out BXT and CNP's setup_backlight(),enable_backlight(), disable_backlight() and hz_to_pwm() into two separate functions instead of reusing BXT function. Reuse set_backlight() and get_backlight() since they have no reference to the utility pin. v2: Reuse BXT functions with controller 0

[Intel-gfx] [PATCH 4/6] drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH

From: Dhinakaran Pandiyan The first two bytes of PCI ID for CNP_LP PCH are the same as that of SPT_LP. We should really be looking at the first 9 bits instead of the first 8 to identify platforms, although this seems to have not caused any problems on earlier

[Intel-gfx] [PATCH 1/6] drm/i915: Fix logical inversion for gen4 quirking

From: Chris Wilson The assertion that we want to make before disabling the pin of the pages for the unknown swizzling quirk is that the quirk is indeed active, and that the quirk is disabled before we do apply it to the pages. Fixes: 2c3a3f44dc13 ("drm/i915: Fix pages

[Intel-gfx] [PATCH 2/6] drm-tip: 2017y-06m-01d-13h-29m-05s UTC integration manifest

From: Chris Wilson --- integration-manifest | 26 ++ 1 file changed, 26 insertions(+) create mode 100644 integration-manifest diff --git a/integration-manifest b/integration-manifest new file mode 100644 index 000..bb20fc4 --- /dev/null

Re: [Intel-gfx] [PATCH v2 01/11] drm: Add HDMI 2.0 VIC support for AVI info-frames

On Wed, May 31, 2017 at 09:06:12PM +0530, Sharma, Shashank wrote: > Regards > > Shashank > > > On 5/31/2017 6:11 PM, Ville Syrjälä wrote: > > On Tue, May 30, 2017 at 10:00:12PM +0530, Sharma, Shashank wrote: > >> Regards > >> > >> Shashank > >> > >> > >> On 5/30/2017 9:43 PM, Ville Syrjälä

[Intel-gfx] [PATCH i-g-t] tests/kms_cursor_crc: Test non-square cursors on IVB+

From: Ville Syrjälä IVB+ have the cursor "FBC" feature, meaning they support a somewhat limited form of non-square cursors. Let's test that. Signed-off-by: Ville Syrjälä --- tests/kms_cursor_crc.c | 8 +++- 1 file changed, 7

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove dead code from runtime resume handler

== Series Details == Series: drm/i915: Remove dead code from runtime resume handler URL : https://patchwork.freedesktop.org/series/25182/ State : success == Summary == Series 25182v1 drm/i915: Remove dead code from runtime resume handler

Re: [Intel-gfx] [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations

On 6/1/2017 10:08 PM, Alex Williamson wrote: > On Thu, 1 Jun 2017 03:01:28 + > "Chen, Xiaoguang" wrote: > >> Hi Kirti, >> >>> -Original Message- >>> From: Kirti Wankhede [mailto:kwankh...@nvidia.com] >>> Sent: Thursday, June 01, 2017 1:23 AM >>> To: Chen,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Implement fbc_status "Compressing" info for all platforms

== Series Details == Series: drm/i915: Implement fbc_status "Compressing" info for all platforms URL : https://patchwork.freedesktop.org/series/25176/ State : success == Summary == Series 25176v1 drm/i915: Implement fbc_status "Compressing" info for all platforms

[Intel-gfx] [PATCH] drm/i915: Remove dead code from runtime resume handler

From: Ville Syrjälä Remove the SNB PCH refclock init call from the runtime resume handler. I don't think it was actually needed even when we had SNB runtime PM, and if definitely isn't needed ever since SNB runtime PM was nuked in commit d4c5636e7447 ("drm/i915:

Re: [Intel-gfx] [PATCH v6 6/6] drm/i915/gvt: Adding interface so user space can get the dma-buf

On Sat, 27 May 2017 16:38:52 +0800 Xiaoguang Chen wrote: > User space should create the management fd for the dma-buf operation first. > Then user can query the plane information and create dma-buf if necessary > using the management fd. > > Signed-off-by: Xiaoguang

[Intel-gfx] [PATCH] drm/i915: Implement fbc_status "Compressing" info for all platforms

From: Ville Syrjälä The number of compressed segments has been available ever since FBC2 was introduced in g4x, it just moved from the STATUS register into STATUS2 on IVB. For FBC1 if we really wanted the number of compressed segments we'd have to trawl through

Re: [Intel-gfx] [PATCH 04/13] drm/i915/cnp: Backlight support for CNP.

Based on your clarification the second option feels like the right choice, with a relevant comment in code. Like you said, we get to retain BXT register definitions and clarify that the register is on a PCH for CNP. -DK -Original Message- From: Vivi, Rodrigo Sent: Thursday, June 1,

Re: [Intel-gfx] [PATCH] drm/i915/glk: Fix dotclock calculation in skl_check_pipe_max_pixel_rate

Op 01-06-17 om 15:52 schreef Ville Syrjälä: > On Thu, Jun 01, 2017 at 12:34:13PM +0200, Maarten Lankhorst wrote: >> Seems that GLK has a dotclock that's twice the display clock. >> skl_max_scale checks for IS_GEMINILAKE, so perform the same check here. >> >> While at it, change the DRM_ERROR to

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

== Series Details == Series: series starting with [1/2] drm/i915: Mark CPU cache as dirty on every transition for CPU writes URL : https://patchwork.freedesktop.org/series/25173/ State : success == Summary == Series 25173v1 Series without cover letter

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Plumb the correct acquire ctx into intel_crtc_disable_noatomic()

On Thu, Jun 01, 2017 at 07:05:41PM +0300, Ville Syrjälä wrote: > On Thu, Jun 01, 2017 at 05:48:16PM +0300, Jani Nikula wrote: > > On Thu, 01 Jun 2017, ville.syrj...@linux.intel.com wrote: > > > From: Ville Syrjälä > > > > > > If intel_crtc_disable_noatomic() were to

[Intel-gfx] [PATCH 2/2] drm/i915: Store i915_gem_object_is_coherent() as a bit next to cache-dirty

For ease of use (i.e. avoiding a few checks and function calls), store the object's cache coherency next to the cache is dirty bit. Signed-off-by: Chris Wilson Cc: Dongwon Kim Cc: Matt Roper Tested-by: Dongwon Kim

[Intel-gfx] [PATCH 1/2] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

Currently, we only mark the CPU cache as dirty if we skip a clflush. This leads to some confusion where we have to ask if the object is in the write domain or missed a clflush. If we always mark the cache as dirty, this becomes a much simply question to answer. The goal remains to do as few

Re: [Intel-gfx] [PATCH v6 4/6] vfio: Define vfio based vgpu's dma-buf operations

On Thu, 1 Jun 2017 03:01:28 + "Chen, Xiaoguang" wrote: > Hi Kirti, > > >-Original Message- > >From: Kirti Wankhede [mailto:kwankh...@nvidia.com] > >Sent: Thursday, June 01, 2017 1:23 AM > >To: Chen, Xiaoguang ; Gerd Hoffmann >

Re: [Intel-gfx] [PATCH 04/13] drm/i915/cnp: Backlight support for CNP.

On Thu, 2017-06-01 at 02:15 +, Pandiyan, Dhinakaran wrote: > On Tue, 2017-05-30 at 15:42 -0700, Rodrigo Vivi wrote: > > Split out BXT and CNP's setup_backlight(),enable_backlight(), > > disable_backlight() and hz_to_pwm() into > > two separate functions instead of reusing BXT function. > > >

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Add i830 "pipes power well"

On Thu, Jun 01, 2017 at 03:46:43PM +0100, Chris Wilson wrote: > On Thu, Jun 01, 2017 at 05:36:16PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > 830 more or less requires both pipes and DPLLs to remain on as long > > as either pipe is

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Use a loop for the "three times for luck" DPLL procedure

On Thu, Jun 01, 2017 at 03:48:51PM +0100, Chris Wilson wrote: > On Thu, Jun 01, 2017 at 05:36:15PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > The magic "enable the DPLL three times" sequence feels like it > > deserves a loop. > >

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_setmode: increase MAX_CRTCS to 6

Please ignore what I wrote. Looks like I was a bit hasty in my judgement. The code just doesn't read easily but seems correct, other than the array size. Harry On 2017-05-31 04:17 PM, Harry Wentland wrote: On 2017-05-31 09:32 AM, Harry Wentland wrote: On 2017-05-31 05:37 AM, Daniel Vetter

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Plumb the correct acquire ctx into intel_crtc_disable_noatomic()

On Thu, Jun 01, 2017 at 05:48:16PM +0300, Jani Nikula wrote: > On Thu, 01 Jun 2017, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > If intel_crtc_disable_noatomic() were to ever get called during resume > > e'd end up deadlocking since resume

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Fix deadlock witha the pipe A quirk during resume

On Thu, Jun 01, 2017 at 05:47:45PM +0300, Jani Nikula wrote: > On Thu, 01 Jun 2017, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Pass down the correct acquire context to the pipe A quirk load detect > > hack during display resume. Avoids

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: i915: Preserve old FBC status for update without new planes (rev2)

== Series Details == Series: drm: i915: Preserve old FBC status for update without new planes (rev2) URL : https://patchwork.freedesktop.org/series/24635/ State : success == Summary == Series 24635v2 drm: i915: Preserve old FBC status for update without new planes

Re: [Intel-gfx] [PATCH 30/37] drm/sti: Drop drm_vblank_cleanup

On 05/24/2017 04:52 PM, Daniel Vetter wrote: > Seems entirely cargo-culted. > > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/sti/sti_drv.c | 1 - > 1 file

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Pipe A quirk rework

== Series Details == Series: drm/i915: Pipe A quirk rework URL : https://patchwork.freedesktop.org/series/25169/ State : success == Summary == Series 25169v1 drm/i915: Pipe A quirk rework https://patchwork.freedesktop.org/api/1.0/series/25169/revisions/1/mbox/ fi-bdw-5557u total:278

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Use a loop for the "three times for luck" DPLL procedure

On Thu, Jun 01, 2017 at 05:36:15PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The magic "enable the DPLL three times" sequence feels like it > deserves a loop. Hmm, I thought once upon a time we figured out what the magic was about. Or

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Add i830 "pipes power well"

On Thu, Jun 01, 2017 at 05:36:16PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > 830 more or less requires both pipes and DPLLs to remain on as long > as either pipe is needed. However, when neither pipe is actually needed, > we can save a

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Use a loop for the "three times for luck" DPLL procedure

On Thu, 01 Jun 2017, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The magic "enable the DPLL three times" sequence feels like it > deserves a loop. I think the copy-paste unrolled loop is more fun. ;) Reviewed-by: Jani Nikula

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Fix deadlock witha the pipe A quirk during resume

On Thu, 01 Jun 2017, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Pass down the correct acquire context to the pipe A quirk load detect > hack during display resume. Avoids deadlocking the entire thing. Have we seen this in the wild? References?

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Plumb the correct acquire ctx into intel_crtc_disable_noatomic()

On Thu, 01 Jun 2017, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > If intel_crtc_disable_noatomic() were to ever get called during resume > e'd end up deadlocking since resume has its own acqcuire_ctx but > intel_crtc_disable_noatomic() still tries

Re: [Intel-gfx] [PATCH 0/7] drm/i915: Pipe A quirk rework

On Thu, Jun 01, 2017 at 05:36:12PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Note that I'm entirely removing the few remaining pipe A quirks > for non-830 platforms as they predate KMS and the hardware > really shouldn't need them. >

[Intel-gfx] [PATCH 6/7] drm/i915: Drop pipe A quirk for Thinkapd T60

From: Ville Syrjälä The pipe A force quirk shouldn't needed except on 830. So let's nuke it for the IBM Thinkpad T60 945 machines. This quirk pre-dates KMS so it's usefulness is doubtful at best now. The original bug report [1] describes the symptoms as "system

Re: [Intel-gfx] [PATCH] drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

On Thu, 01 Jun 2017, Imre Deak wrote: > On Thu, Jun 01, 2017 at 04:58:50PM +0300, Ville Syrjälä wrote: >> On Thu, Jun 01, 2017 at 03:55:13PM +0300, Jani Nikula wrote: >> > On Wed, 31 May 2017, Ville Syrjälä wrote: >> > > On Wed, May 31, 2017 at

[Intel-gfx] [PATCH 1/7] drm/i915: Fix deadlock witha the pipe A quirk during resume

From: Ville Syrjälä Pass down the correct acquire context to the pipe A quirk load detect hack during display resume. Avoids deadlocking the entire thing. Cc: sta...@vger.kernel.org Cc: Maarten Lankhorst Fixes: e2c8b8701e2d

[Intel-gfx] [PATCH 5/7] drm/i915: Drop pipe A quirk for Toshiba Protege R205-S209

From: Ville Syrjälä The pipe A force quirk shouldn't needed except on 830. So let's nuke it for the Toshiba Protege R-205/S-209 945 machines. This quirk pre-dates KMS so it's usefulness is doubtful at best now. Unfortunately the original bug report [1] isn't very

[Intel-gfx] [PATCH 7/7] drm/i915: Remove pipe A quirk remnants

From: Ville Syrjälä With 830 the only thing needing pipe quirks, we can just drop the quirk defines and replace the checks with IS_I830() checks. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.h | 2 -

[Intel-gfx] [PATCH 4/7] drm/i915: Add i830 "pipes power well"

From: Ville Syrjälä 830 more or less requires both pipes and DPLLs to remain on as long as either pipe is needed. However, when neither pipe is actually needed, we can save a bit of power by turning everything off. To do that we add a new "power well" that turns

[Intel-gfx] [PATCH 2/7] drm/i915: Plumb the correct acquire ctx into intel_crtc_disable_noatomic()

From: Ville Syrjälä If intel_crtc_disable_noatomic() were to ever get called during resume e'd end up deadlocking since resume has its own acqcuire_ctx but intel_crtc_disable_noatomic() still tries to use the mode_config.acquire_ctx. Pass down the correct acquire

[Intel-gfx] [PATCH 3/7] drm/i915: Use a loop for the "three times for luck" DPLL procedure

From: Ville Syrjälä The magic "enable the DPLL three times" sequence feels like it deserves a loop. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_display.c | 15 ++- 1 file changed, 6 insertions(+), 9

[Intel-gfx] [PATCH 0/7] drm/i915: Pipe A quirk rework

From: Ville Syrjälä This series eliminates the problematic load detect abuse for the pipe A quirk. My main motivations were to isolate these quirks more from atomic to avoid regressions, and to save a bit of extra power. I believe I cooked this up a few years ago

Re: [Intel-gfx] [PATCH v2 1/5] acpi, nfit: Switch to use new generic UUID API

On Wed, May 31, 2017 at 12:41 PM, Andy Shevchenko wrote: > There are new types and helpers that are supposed to be used in new code. > > As a preparation to get rid of legacy types and API functions do > the conversion here. > > Cc: Dan Williams

Re: [Intel-gfx] [PATCH v2 5/5] ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()

On Wed, May 31, 2017 at 12:41 PM, Andy Shevchenko wrote: > acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16 > bytes. Instead we convert them to use guid_t type. At the same time we > convert current users. > > acpi_str_to_uuid() becomes

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Allow kswapd to pause the device whilst reaping

== Series Details == Series: series starting with [1/3] drm/i915: Allow kswapd to pause the device whilst reaping URL : https://patchwork.freedesktop.org/series/25164/ State : success == Summary == Series 25164v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

On Thu, Jun 01, 2017 at 04:58:50PM +0300, Ville Syrjälä wrote: > On Thu, Jun 01, 2017 at 03:55:13PM +0300, Jani Nikula wrote: > > On Wed, 31 May 2017, Ville Syrjälä wrote: > > > On Wed, May 31, 2017 at 08:05:35PM +0300, Imre Deak wrote: > > >> Atm disabling either

Re: [Intel-gfx] [PATCH] drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

On Thu, 01 Jun 2017, Ville Syrjälä wrote: > On Thu, Jun 01, 2017 at 03:55:13PM +0300, Jani Nikula wrote: >> On Wed, 31 May 2017, Ville Syrjälä wrote: >> > On Wed, May 31, 2017 at 08:05:35PM +0300, Imre Deak wrote: >> >> Atm disabling

Re: [Intel-gfx] [PATCH v2 5/5] ACPI: Switch to use generic guid_t in acpi_evaluate_dsm()

On Wed, May 31, 2017 at 10:41:52PM +0300, Andy Shevchenko wrote: > acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16 > bytes. Instead we convert them to use guid_t type. At the same time we > convert current users. > > acpi_str_to_uuid() becomes useless after the conversion and

Re: [Intel-gfx] [PATCH] drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

On Thu, Jun 01, 2017 at 03:55:13PM +0300, Jani Nikula wrote: > On Wed, 31 May 2017, Ville Syrjälä wrote: > > On Wed, May 31, 2017 at 08:05:35PM +0300, Imre Deak wrote: > >> Atm disabling either DP or eDP outputs can generate a spurious short > >> pulse interrupt.

Re: [Intel-gfx] [PATCH 4/6] drm/i915/cnp: Backlight support for CNP.

On Wed, 31 May 2017, Rodrigo Vivi wrote: > Split out BXT and CNP's setup_backlight(),enable_backlight(), > disable_backlight() and hz_to_pwm() into > two separate functions instead of reusing BXT function. > > Reuse set_backlight() and get_backlight() since they have > no

Re: [Intel-gfx] [PATCH] drm/i915/glk: Fix dotclock calculation in skl_check_pipe_max_pixel_rate

On Thu, Jun 01, 2017 at 12:34:13PM +0200, Maarten Lankhorst wrote: > Seems that GLK has a dotclock that's twice the display clock. > skl_max_scale checks for IS_GEMINILAKE, so perform the same check here. > > While at it, change the DRM_ERROR to DEBUG_KMS. > > Fixes: 73b0ca8ec76d

[Intel-gfx] [PATCH 1/3] drm/i915: Allow kswapd to pause the device whilst reaping

In commit 5763ff04dc4e ("drm/i915: Avoid GPU stalls from kswapd") we stopped direct reclaim and kswapd from triggering GPU/client stalls whilst running (by restricting the objects they could reap to be idle). However with abusive GPU usage, it becomes quite easy to starve kswapd of memory and

[Intel-gfx] [PATCH 2/3] drm/i915: Encourage our shrinker more when our shmemfs allocations fails

Commit 24f8e00a8a2e ("drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations") made the bold decision to try and avoid the oomkiller by reporting -ENOMEM to userspace if our allocation failed after attempting to free enough buffer objects. In short, it appears we were

[Intel-gfx] [PATCH 3/3] drm/i915: Remove __GFP_NORETRY from our buffer allocator

I tried __GFP_NORETRY in the belief that __GFP_RECLAIM was effective. It struggles with handling reclaim via kswapd (through inconsistency within throttle_direct_reclaim() and even then the race between multiple allocators makes the two step of reclaim then allocate fragile), and as our buffers

Re: [Intel-gfx] [PATCH] drm/i915: Fix logical inversion for gen4 quirking

On Mon, May 22, 2017 at 08:55:09AM +0300, Joonas Lahtinen wrote: > On su, 2017-05-21 at 13:40 +0100, Chris Wilson wrote: > > The assertion that we want to make before disabling the pin of the pages > > for the unknown swizzling quirk is that the quirk is indeed active. > > > > Fixes: 2c3a3f44dc13

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Check the ring is empty when declaring the engines are idle

On Wed, May 31, 2017 at 05:01:53PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > On Tue, May 30, 2017 at 03:33:41PM +0300, Mika Kuoppala wrote: > >> Chris Wilson writes: > >> > >> > As another precaution when testing whether the CS

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Assert that we switch between known ggtt->invalidate functions

On Thu, Jun 01, 2017 at 09:36:58AM -, Patchwork wrote: > == Series Details == > > Series: drm/i915/guc: Assert that we switch between known ggtt->invalidate > functions > URL : https://patchwork.freedesktop.org/series/25150/ > State : success > > == Summary == > > Series 25150v1

Re: [Intel-gfx] [PATCH] drm/i915/dvo: fix debug logging on unknown DID

On Wed, 31 May 2017, Clint Taylor wrote: > On 05/31/2017 03:16 AM, Jani Nikula wrote: >> Print DID not VID on the DID error path. Looks like a copy-paste error >> from the VID error path. Clarify and clean up error logging, making them >> distinguishable from each

Re: [Intel-gfx] [PATCH] drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

On Wed, 31 May 2017, Ville Syrjälä wrote: > On Wed, May 31, 2017 at 08:05:35PM +0300, Imre Deak wrote: >> Atm disabling either DP or eDP outputs can generate a spurious short >> pulse interrupt. The reason is that after disabling the port the source >> will stop

Re: [Intel-gfx] [PATCH 01/15] drm/i915: really simple gemfs

On 1 June 2017 at 11:49, Joonas Lahtinen wrote: > On ke, 2017-05-31 at 19:51 +0100, Matthew Auld wrote: >> Not a fully blown gemfs, just our very own tmpfs kernel mount. Doing so >> moves us away from the shmemfs shm_mnt, and gives us the much needed >>

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ddi: Avoid long delays during system suspend / eDP disabling

On Wed, May 31, 2017 at 05:34:42PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/ddi: Avoid long delays during system suspend / eDP disabling > URL : https://patchwork.freedesktop.org/series/25116/ > State : success > > == Summary == > > Series 25116v1 drm/i915/ddi:

Re: [Intel-gfx] Implementing Miracast

On 01/06/17 09:02, Daniel Kasak wrote: Any news? Seems every TV I bump into these days has Miracast support ... Sorry, it must be frustrating. Some code needs to be re-implemented because it was GPL-based and we need it as MIT. Until I have some time to do this, this will probably not move

Re: [Intel-gfx] [PATCH] i915: fix build on gcc7

This is probably already fixed in drm-next by commit 0ad4dc887d4168448e8c801aa4edd8fe1e0bd534 Author: Hans de Goede Date: Thu May 18 13:06:44 2017 +0200 drm/i915: Fix new -Wint-in-bool-context gcc compiler warning > which I also think is a more sensible fix than

Re: [Intel-gfx] [PATCH 03/15] drm/i915: introduce page_size_mask to dev_info

On Thu, 01 Jun 2017, Joonas Lahtinen wrote: > On ke, 2017-05-31 at 19:51 +0100, Matthew Auld wrote: >> In preparation for huge gtt pages expose a page_size_mask as part of the >> device info, to indicate the page sizes supported by the HW.  Currently >> only 4K is

[Intel-gfx] ✓ Fi.CI.BAT: success for i915: fix build on gcc7

== Series Details == Series: i915: fix build on gcc7 URL : https://patchwork.freedesktop.org/series/25158/ State : success == Summary == Series 25158v1 i915: fix build on gcc7 https://patchwork.freedesktop.org/api/1.0/series/25158/revisions/1/mbox/ Test gem_exec_flush: Subgroup

Re: [Intel-gfx] [PATCH v15 14/14] drm/i915/perf: notify sseu configuration changes

On Wed, May 31, 2017 at 01:33:55PM +0100, Lionel Landwerlin wrote: > static void > -free_oa_buffer(struct drm_i915_private *i915) > +free_sseu_buffer(struct drm_i915_private *i915) > { > - mutex_lock(>drm.struct_mutex); > + i915_gem_object_unpin_map(i915->perf.sseu_buffer.vma->obj); > +

Re: [Intel-gfx] [PATCH] i915: fix build on gcc7

On Thu, 01 Jun 2017, Aleksa Sarai wrote: > With gcc7, the conditional usage of (port == PORT_A ? PORT_C : PORT_A) > triggers -Werror=int-in-bool-context which breaks the build. Instead, > use a temporary port_other variable that avoids hitting this error. > > % gcc --version >

Re: [Intel-gfx] [PATCH v15 14/14] drm/i915/perf: notify sseu configuration changes

On Wed, May 31, 2017 at 01:33:55PM +0100, Lionel Landwerlin wrote: > @@ -2493,6 +2499,44 @@ struct drm_i915_private { > const struct i915_oa_format *oa_formats; > int n_builtin_sets; > } oa; > + > + struct { > +

Re: [Intel-gfx] [PATCH v15 06/14] drm/i915/perf: Add OA unit support for Gen 8+

On Wed, May 31, 2017 at 01:33:47PM +0100, Lionel Landwerlin wrote: > u32 gen7_latched_oastatus1; > + u32 ctx_oactxctrl_offset; > + u32 ctx_flexeu0_offset; > + > + /* The RPT_ID/reason field for Gen8+ includes a bit >

Re: [Intel-gfx] [PATCH] drm/i915/guc: Assert that we switch between known ggtt->invalidate functions

On to, 2017-06-01 at 12:01 +0100, Chris Wilson wrote: > On Thu, Jun 01, 2017 at 01:44:07PM +0300, Joonas Lahtinen wrote: > > > > On to, 2017-06-01 at 10:04 +0100, Chris Wilson wrote: > > > > > > When we enable the GuC, we enable an alternative mechanism for doing > > > post-GGTT update

[Intel-gfx] [PATCH] i915: fix build on gcc7

With gcc7, the conditional usage of (port == PORT_A ? PORT_C : PORT_A) triggers -Werror=int-in-bool-context which breaks the build. Instead, use a temporary port_other variable that avoids hitting this error. % gcc --version gcc (SUSE Linux) 7.1.1 20170517 [gcc-7-branch revision 248152]

Re: [Intel-gfx] [PATCH] drm/i915/guc: Assert that we switch between known ggtt->invalidate functions

On Thu, Jun 01, 2017 at 01:24:55PM +0300, Joonas Lahtinen wrote: > On to, 2017-06-01 at 12:03 +0200, Michal Wajdeczko wrote: > > On Thu, Jun 01, 2017 at 10:04:46AM +0100, Chris Wilson wrote: > > >   > > >  void i915_ggtt_disable_guc(struct drm_i915_private *i915) > > >  { > > > - if

Re: [Intel-gfx] [PATCH 2/3] pwm: lpss: Add intel-gfx as consumer device in lookup table

On Wednesday 31 May 2017 10:16 PM, kbuild test robot wrote: Hi Shobhit, [auto build test ERROR on drm-intel/for-linux-next] [also build test ERROR on v4.12-rc3 next-20170531] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] Guess this needs

Re: [Intel-gfx] [PATCH] drm/i915/guc: Assert that we switch between known ggtt->invalidate functions

On Thu, Jun 01, 2017 at 01:44:07PM +0300, Joonas Lahtinen wrote: > On to, 2017-06-01 at 10:04 +0100, Chris Wilson wrote: > > When we enable the GuC, we enable an alternative mechanism for doing > > post-GGTT update invalidation. Likewise, when we disable the GuC, we > > restore the previous

Re: [Intel-gfx] [PATCH 03/15] drm/i915: introduce page_size_mask to dev_info

On ke, 2017-05-31 at 19:51 +0100, Matthew Auld wrote: > In preparation for huge gtt pages expose a page_size_mask as part of the > device info, to indicate the page sizes supported by the HW.  Currently > only 4K is supported. > > Signed-off-by: Matthew Auld > Cc: Joonas

  1   2   >