Re: [Intel-gfx] [PATCH 4/4] fbdev: Debug knob to register without holding console_lock

On 01/09/15 17:34, Rob Clark wrote: > I hadn't had a chance to look at it further yet.. I think Daniel > claimed it worked for him, but he was probably on intel-next, where I > was on drm-next at the time which seemed to be having some unrelated > i915 issues (when I was trying to debug atomic

Re: [Intel-gfx] [PATCH 6/7] drm/i915: use compute_page_offset() on SKL too

On Thu, Sep 24, 2015 at 10:55:17AM +0100, Tvrtko Ursulin wrote: > > On 09/23/2015 06:03 PM, Chris Wilson wrote: > >On Wed, Sep 23, 2015 at 12:52:26PM -0300, Paulo Zanoni wrote: > >>The trick is not strictly necessary on SKL because the offset > >>registers allow more bits. But for FBC, doing this

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/gtt: Do not initialize drm_mm twice.

On Wed, 2015-09-23 at 15:55 -0300, Paulo Zanoni wrote: > 2015-09-23 13:48 GMT-03:00 Imre Deak : > > On ke, 2015-09-16 at 11:49 +0200, Michał Winiarski wrote: > > > It would be initialized just moments later by i915_init_vm. > > > > > > v2: Commit msg update, > > >

Re: [Intel-gfx] [PATCH 6/7] drm/i915: use compute_page_offset() on SKL too

On 09/23/2015 06:03 PM, Chris Wilson wrote: On Wed, Sep 23, 2015 at 12:52:26PM -0300, Paulo Zanoni wrote: The trick is not strictly necessary on SKL because the offset registers allow more bits. But for FBC, doing this changes how the hardware tracking works - it starts at the surface address

Re: [Intel-gfx] [PATCH] drm/i915: Convert WARNs during userptr revoke to SIGBUS

On 09/23/2015 09:07 PM, Chris Wilson wrote: If the client revokes the virtual address it asked to be mapped into GPU space via userptr (by using anything along the lines of mmap, mprotect, madvise, munmap, ftruncate etc) the mmu notifier sends a range invalidate command to userptr. Upon

[Intel-gfx] [PATCH i-g-t] gem_storedw_loop: fix segfault when listing subtests

Commit fb66cd5 (tests/gem_storedw_loop: Fix use after free for bufmgr) introduced a segmentation fault when listing subtests because drm_intel_bufmgr_destroy is called with NULL. Move this and the call to the close function inside an igt_fixture block to prevent them being called when listing

Re: [Intel-gfx] [PATCH] drm/i915: Convert WARNs during userptr revoke to SIGBUS

On Thu, Sep 24, 2015 at 11:23:48AM +0100, Tvrtko Ursulin wrote: > > On 09/23/2015 09:07 PM, Chris Wilson wrote: > >If the client revokes the virtual address it asked to be mapped into GPU > >space via userptr (by using anything along the lines of mmap, mprotect, > >madvise, munmap, ftruncate etc)

Re: [Intel-gfx] [PATCH] drm/i915: Defer adding preallocated stolen objects to the VM list

On Thu, 24 Sep 2015, "Winiarski, Michal" wrote: > On Thu, 2015-09-24 at 11:57 +0100, Chris Wilson wrote: >> When preallocating a stolen object during early initialisation, we >> may >> be running before we have setup the the global GTT VM state, in >> particular before

Re: [Intel-gfx] [PATCH] drm/i915: Defer adding preallocated stolen objects to the VM list

On Thu, 24 Sep 2015, Chris Wilson wrote: > When preallocating a stolen object during early initialisation, we may > be running before we have setup the the global GTT VM state, in > particular before we have initialised the range manager and associated > lists. As this

[Intel-gfx] [PATCH i-g-t] lib/tests: explicitly raise SIGSEGV

Dereferencing a NULL pointer is undefined behaviour and may not always result in a segmentation fault. Explicitly raise the SIGSEGV signal to test handling of this signal. Signed-off-by: Thomas Wood --- lib/tests/igt_segfault.c | 6 +- 1 file changed, 5 insertions(+),

Re: [Intel-gfx] [PATCH] drm/i915: Convert WARNs during userptr revoke to SIGBUS

On 09/24/2015 11:31 AM, Chris Wilson wrote: On Thu, Sep 24, 2015 at 11:23:48AM +0100, Tvrtko Ursulin wrote: On 09/23/2015 09:07 PM, Chris Wilson wrote: If the client revokes the virtual address it asked to be mapped into GPU space via userptr (by using anything along the lines of mmap,

Re: [Intel-gfx] [PATCH] drm/i915: Defer adding preallocated stolen objects to the VM list

On Thu, 2015-09-24 at 11:57 +0100, Chris Wilson wrote: > When preallocating a stolen object during early initialisation, we > may > be running before we have setup the the global GTT VM state, in > particular before we have initialised the range manager and > associated > lists. As this is the

[Intel-gfx] [PATCH 1/3] drm/i915: Add current CD clock frequency to debugfs

Add information on current CD clock frequency to debugfs 'i915_frequency_info' Signed-off-by: Mika Kahola --- drivers/gpu/drm/i915/i915_debugfs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c

[Intel-gfx] [PATCH i-g-t v3] gem_ppgtt: Test VMA leak on context destruction

From: Tvrtko Ursulin Test that VMAs associated with a context are cleaned up when contexts are destroyed. In practice this emulates the leak seen between fbcon and X server. Every time the X server exits we gain one VMA on the fbcon frame buffer object as externally

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Set oscaledcompmethod to enable scale value

On to, 2015-09-24 at 10:22 +0530, Sonika Jindal wrote: > Bspec update tells that we have to enable oscaledcompmethod instead of > ouniqetrangenmethod for enabling scale value during swing programming. > > v2: Adding back 'don't care' values to bxt_ddi_translations_dp and add > error message if

[Intel-gfx] [PATCH 3/3] drm/i915: Add max DOT clock frequency to debugfs

Information on maximum supported pixel clock frequency to i915_frequency_info. Signed-off-by: Mika Kahola --- drivers/gpu/drm/i915/i915_debugfs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c

[Intel-gfx] [PATCH 2/3] drm/i915: Add max CD clock to debugfs

This adds information on maximum supported CD clock frequency to debugfs 'i915_frequency_info' Signed-off-by: Mika Kahola --- drivers/gpu/drm/i915/i915_debugfs.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c

[Intel-gfx] [PATCH 0/3] drm/i915: Add CD and pixel clock information

These patches add information of current and maximum CD clock frequency and pixel clock frequency information on 'i915_debugfs.c'. Mika Kahola (3): drm/i915: Add current CD clock frequency to debugfs drm/i915: Add max CD clock to debugfs drm/i915: Add max DOT clock frequency to debugfs

Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

Hi Jani, On Thu, 24 Sep 2015 11:57:05 +0300 Jani Nikula wrote: > > That was the right thing to do. > > The former commit is headed for v4.3, and there will have to be another > version of it for -next. This will cause you another conflict, and you > should resolve

Re: [Intel-gfx] [PATCH] drm/i915: Defer adding preallocated stolen objects to the VM list

On Thu, Sep 24, 2015 at 10:02:00AM +0100, Chris Wilson wrote: > When preallocating a stolen object during early initialisation, we may > be running before we have setup the the global GTT VM state, in > particular before we have initialised the range manager and associated > lists. As this is the

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Always call the adjusted mode 'adjusted_mode'

coccinelle does a fine job on renaming the variables. Although, it does break the rule of 80 character line width. Reviewed-by: Mika Kahola On Tue, 2015-09-08 at 13:40 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > >

[Intel-gfx] [PULL] drm-intel-fixes

Hi Dave, a few drm/i915 fixes, including a fix to the recent regression reported by Sedat Dilek [1]. BR, Jani. [1] http://mid.gmane.org/ca+iczuuwi96rv5pfdg3femg95vfpfjbmubiwrdzgduyjvt1...@mail.gmail.com The following changes since commit 1f93e4a96c9109378204c147b3eec0d0e8100fde: Linux

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Use intel_panel for DVO fixed mode handling

Reviewed-by: Mika Kahola On Tue, 2015-09-08 at 13:40 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Replace intel_dvo->panel_fixed_mode with the appropriate intel_panel > stuff. Now all connectors that have a fixed

Re: [Intel-gfx] [PATCH 3/7] drm/i915: s/mode/adjusted_mode/ in functions that really get passed the adjusted_mode

On Tue, 2015-09-08 at 13:40 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Rename the function argument to 'adjusted_mode' whenever the function > only ever gets passed the adjusted_mode. > > Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Move HDMI aspect ratio setup to .compute_config()

Reviewed-by: Mika Kahola On Tue, 2015-09-08 at 13:40 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We shouldn't frob adjusted_mode after .compute_config(), so move the > infoframe aspect ratio setup to

Re: [Intel-gfx] [PATCH v2 3/6] drm/i915/guc: Add host2guc notification for suspend and resume

On 9/23/2015 2:18 AM, yu@intel.com wrote: From: Alex Dai Add host2guc interfaces to nofigy GuC power state changes when *notify enter or resume from power saving state. v1: Change to a more flexible way when fill host to GuC scratch data in order to remove hard

Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

On Thu, 24 Sep 2015, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the drm-intel tree got a conflict in: > > drivers/gpu/drm/i915/intel_display.c > > between commit: > > 721a09f7393d ("drm/i915: Add primary plane to mask if it's visible") > > from

Re: [Intel-gfx] [regression] Re: [Linux-v4.2-10463-g9a9952bbd76a] i915: WARNING: intel_display.c:1377 assert_planes_disabled

On Thu, 24 Sep 2015, Sedat Dilek wrote: > On Wed, Sep 23, 2015 at 9:18 AM, Daniel Vetter wrote: >> Adding Jairo to track this regression. > > Hi, > > commit 721a09f7393de6c28a07516dccd654c6e995944a > "drm/i915: Add primary plane to mask if it's visible" >

[Intel-gfx] [PATCH] drm/i915: Defer adding preallocated stolen objects to the VM list

When preallocating a stolen object during early initialisation, we may be running before we have setup the the global GTT VM state, in particular before we have initialised the range manager and associated lists. As this is the case, we defer binding the stolen object until we call

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Constify adjusted_mode

Reviewed-by: Mika Kahola On Tue, 2015-09-08 at 13:40 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Make adjusted_mode const whereever we don't have to modify it. This only > covers cases when we have a local

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Always use crtc_ timings when dealing with adjustead_mode

Reviewed-by: Mika Kahola On Tue, 2015-09-08 at 13:40 +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > The adjustead_mode crtc_ timings are what we will program into the hardware, > so it's those timings we should be

Re: [Intel-gfx] [regression] [git pull] drm for 4.3

On Thu, 24 Sep 2015, "da...@codemonkey.org.uk" wrote: > On Wed, Sep 23, 2015 at 11:07:56AM +, Lankhorst, Maarten wrote: > > Hey, > > > > Dave Jones schreef op di 22-09-2015 om 21:49 [-0400]: > > > On Tue, Sep 22, 2015 at 09:15:58AM -0700, Matt Roper wrote: > > >

Re: [Intel-gfx] [RFC PATCH] drm/i915/skl: Add DC6 disabling as a power well

On Wed, Sep 23, 2015 at 01:18:00PM +0200, Patrik Jakobsson wrote: > On Wed, Sep 23, 2015 at 10:43:00AM +0200, Daniel Vetter wrote: > > On Mon, Sep 21, 2015 at 10:00:45AM +0200, Patrik Jakobsson wrote: > > > On Wed, Sep 16, 2015 at 11:10:07PM +0300, Ville Syrjälä wrote: > > > > On Fri, Sep 11, 2015

Re: [Intel-gfx] [PATCH i-g-t] lib/tests: explicitly raise SIGSEGV

This relies on signal.h being included by wait.h. Would it be better to include it explicitly? -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Thomas Wood Sent: Thursday, September 24, 2015 11:30 AM To: intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 1/2] drm: Add a non-locking version of drm_kms_helper_poll_enable(), v2

On Wed, 23 Sep 2015, Daniel Vetter wrote: > On Wed, Sep 23, 2015 at 04:13:00PM +0200, Egbert Eich wrote: >> drm_kms_helper_poll_enable() was converted to lock the mode_config >> mutex in commit 8c4ccc4ab6f64e859d4ff8d7c02c2ed2e956e07f >> ("drm/probe-helper: Grab mode_config.mutex

Re: [Intel-gfx] [PATCH] drm/i915: set proper N/CTS in modeset

Hi Takashi, Currently, our testing environment seems not to work. I will setup the test environment and send the patch after doing the test. Regards, Libin > -Original Message- > From: Yang, Libin > Sent: Wednesday, September 23, 2015 10:20 PM > To: Takashi Iwai; Jani Nikula > Cc:

Re: [Intel-gfx] [PATCH] drm/i915: Don't call intel_prepare_ddi when encoder list isn't yet initialized.

On ke, 2015-09-23 at 11:32 -0700, Rodrigo Vivi wrote: > In case something goes wrong with power well initialization we were calling > intel_prepare_ddi during boot while encoder list isnt't initilized. > > [9.618747] i915 :00:02.0: Invalid ROM contents > [9.631446] [drm] failed to

Re: [Intel-gfx] [PATCH] drm/i915: Defer adding preallocated stolen objects to the VM list

On Thu, Sep 24, 2015 at 02:24:36PM +0300, Jani Nikula wrote: > On Thu, 24 Sep 2015, "Winiarski, Michal" wrote: > > On Thu, 2015-09-24 at 11:57 +0100, Chris Wilson wrote: > >> When preallocating a stolen object during early initialisation, we > >> may > >> be running

[Intel-gfx] [PATCH i-g-t] kms_crash: Check that KMS client crashes are properly handled

From: Tvrtko Ursulin Check that frame buffers are torn down when a client dies. Later could be extended with a CRC based test to check whether a later client can inherit a plane left from an earlier one. There could be some interesting data or images on that plane.

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/guc: Add GuC css header parser

On 22/09/15 21:48, yu@intel.com wrote: From: Alex Dai By using information from GuC css header, we can eliminate some hard code w.r.t size of some components of firmware. v2: Add indent into DOC to make fixed-width format rather than change the tmpl. v1: 1)

Re: [Intel-gfx] [RFC PATCH] drm/i915/skl: Add DC6 disabling as a power well

On Thu, Sep 24, 2015 at 02:50:16PM +0200, Patrik Jakobsson wrote: > On Wed, Sep 23, 2015 at 01:18:00PM +0200, Patrik Jakobsson wrote: > > On Wed, Sep 23, 2015 at 10:43:00AM +0200, Daniel Vetter wrote: > > > On Mon, Sep 21, 2015 at 10:00:45AM +0200, Patrik Jakobsson wrote: > > > > On Wed, Sep 16,

Re: [Intel-gfx] [RFC][PATCH 43/43] WIP: drm/i915: Type safe register read/write

On Wed, Sep 23, 2015 at 05:23:27PM +0200, Daniel Vetter wrote: > On Fri, Sep 18, 2015 at 08:03:56PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Make I915_READ and I915_WRITE more type safe by wrapping the register > > offset in a

Re: [Intel-gfx] [PATCH] drm/i915: fixup runtime PM handling v2

Forgot to cc Rafael. On 09/23/2015 02:37 PM, Jesse Barnes wrote: > According to the PCI docs and Rafael, we don't need to be doing explicit > enables and disables in our init and teardown routines, as they're taken > care of by the PCI core. So drop the pm_runtime_disable() at teardown > and

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Support NV12 in rotated GGTT mapping

On Mon, Sep 21, 2015 at 10:45:34AM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Just adding the rotated UV plane at the end of the rotated Y plane. > > v2: Rebase. > > Signed-off-by: Tvrtko Ursulin > --- >

Re: [Intel-gfx] [PATCH] drm/i915: Detect virtual south bridge

On 08/28/2015 05:10 AM, robert.beck...@intel.com wrote: > From: Robert Beckett > > Virtualized systems often use a virtual P2X4 south bridge. > Detect this in intel_detect_pch and make a best guess as to which PCH > we should be using. > > This was seen on vmware esxi

Re: [Intel-gfx] [PATCH] drm/i915: fixup runtime PM handling v2

On Thursday, September 24, 2015 08:40:28 AM Jesse Barnes wrote: > Forgot to cc Rafael. > > On 09/23/2015 02:37 PM, Jesse Barnes wrote: > > According to the PCI docs and Rafael, we don't need to be doing explicit > > enables and disables in our init and teardown routines, as they're taken > > care

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/guc: Add GuC css header parser

On 24/09/15 19:34, Yu Dai wrote: On 09/24/2015 07:23 AM, Dave Gordon wrote: On 22/09/15 21:48, yu@intel.com wrote: > From: Alex Dai > > By using information from GuC css header, we can eliminate some > hard code w.r.t size of some components of firmware. > > v2: Add

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/guc: Add GuC css header parser

On 09/24/2015 07:23 AM, Dave Gordon wrote: On 22/09/15 21:48, yu@intel.com wrote: > From: Alex Dai > > By using information from GuC css header, we can eliminate some > hard code w.r.t size of some components of firmware. > > v2: Add indent into DOC to make fixed-width

Re: [Intel-gfx] [PATCH] drm/i915: Only disable visible planes in intel_crtc_disable_planes

On 21 September 2015 at 09:05, Maarten Lankhorst wrote: > This is fix for a regression introduced by 27321ae88c70104df > "drm/i915: Use the disable callback for disabling planes." > > Disabling invisible planes may cause recalculation of > watermarks, which is a

[Intel-gfx] [PATCH 3/4] drm/i915: Simplify vlv/chv rc6 residency calculation

From: Ville Syrjälä We have the czclk freqeuency in dev_priv now, so let's just use it when converting the rc6 counters to milliseconds. This elimiantes a bunch of hairy code that essentially tries to extract the czclk frequency using yet another method.

[Intel-gfx] [PATCH 2/4] drm/i915: Read czclk from CCK on vlv/chv

From: Ville Syrjälä As with the cdclk, read out czclk from CCK as well. This gives us the real current value and avoids having to decode fuses and whatnot. Also store it in kHz under dev_priv like we do for cdlck since it's not just an rps related clock, and

[Intel-gfx] [PATCH 4/4] drm/i915: Use czclk_freq in vlv c0 residency calculations

From: Ville Syrjälä Replace the use of mem_freq/4 with czclk_freq in the vlv c0 residency calculations. Also deal with VLV_COUNT_RANGE_HIGH which affects all RCx residency counters. We have just enough bits to do this without intermediate divisions.

Re: [Intel-gfx] [PATCH v2 2/6] drm/i915/guc: Add GuC css header parser

On 09/24/2015 12:04 PM, Dave Gordon wrote: On 24/09/15 19:34, Yu Dai wrote: > > > On 09/24/2015 07:23 AM, Dave Gordon wrote: >> On 22/09/15 21:48, yu@intel.com wrote: >> > From: Alex Dai >> > >> > By using information from GuC css header, we can eliminate some >> > hard

[Intel-gfx] [PATCH 13/15] drm/i915: Calculate watermark configuration during atomic check (v2)

v2: Don't forget to actually check the cstate->active value when tallying up the number of active CRTC's. (Ander) Signed-off-by: Matt Roper Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_drv.h | 10 ++

[Intel-gfx] [PATCH 11/15] drm/i915: Calculate ILK-style watermarks during atomic check (v3)

Calculate pipe watermarks during atomic calculation phase, based on the contents of the atomic transaction's state structure. We still program the watermarks at the same time we did before, but the computation now happens much earlier. While this patch isn't too exciting by itself, it paves the

[Intel-gfx] [PATCH 10/15] drm/i915: Calculate pipe watermarks into CRTC state (v3)

A future patch will calculate these during the atomic 'check' phase rather than at WM programming time, so let's store the watermark values we're planning to use in the CRTC state; the values actually active on the hardware remains in intel_crtc. While we're at it, do some minor restructuring to

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Update Promotion timer for RC6 TO Mode

This change looks good and is necessary, but the commit message should have more detail. I would add: "When using RC6 timeout mode, the timeout value should be written to GEN6_RC6_THRESHOLD." With that, Reviewed-by: Tom O'Rourke On Wed, Sep 23, 2015 at 03:06:42PM +0530,

[Intel-gfx] [PATCH 0/4] drm/i915: Read czclk from cck on vlv/chv

From: Ville Syrjälä This series replaces the czclk readout using a fuse on chv with reading it directly from the horse's mouth ie. cck. It also adds czclk readout for vlv, which means it also fixes the PFI credit programming on that platform. As a bonus we can

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Add max DOT clock frequency to debugfs

On Thu, Sep 24, 2015 at 02:28:41PM +0300, Mika Kahola wrote: > Information on maximum supported pixel clock frequency to > i915_frequency_info. > > Signed-off-by: Mika Kahola > --- > drivers/gpu/drm/i915/i915_debugfs.c | 1 + > 1 file changed, 1 insertion(+) > > diff

[Intel-gfx] [PATCH 15/15] drm/i915: Add two-stage ILK-style watermark programming (v5)

In addition to calculating final watermarks, let's also pre-calculate a set of intermediate watermark values at atomic check time. These intermediate watermarks are a combination of the watermarks for the old state and the new state; they should satisfy the requirements of both states which means

[Intel-gfx] [PATCH 05/15] drm/i915/skl: Simplify wm structures slightly (v2)

A bunch of SKL watermark-related structures have the cursor plane as a separate entry from the rest of the planes. Since a previous patch updated I915_MAX_PLANES such that those plane arrays now have a slot for the cursor, update the code to use the new slot in the existing plane arrays and kill

[Intel-gfx] [PATCH 14/15] drm/i915: Sanitize watermarks after hardware state readout

Although we can do a good job of reading out hardware state, the graphics firmware may have programmed the watermarks in a creative way that doesn't match how i915 would have chosen to program them. We shouldn't trust the firmware's watermark programming, but should rather re-calculate how we

[Intel-gfx] [PATCH 07/15] drm/i915/ivb: Move WaCxSRDisabledForSpriteScaling w/a to atomic check

Determine whether we need to apply this workaround at atomic check time and just set a flag that will be used by the main watermark update routine. Moving this workaround into the atomic framework reduces ilk_update_sprite_wm() to just a standard watermark update, so drop it completely and just

[Intel-gfx] [PATCH 12/15] drm/i915: Don't set plane visible during HW readout if CRTC is off

We already ensure that pstate->visible = false when crtc->active = false during runtime programming; make sure we follow the same logic when reading out initial hardware state. Signed-off-by: Matt Roper Reviewed-by: Maarten Lankhorst

[Intel-gfx] [PATCH 08/15] drm/i915: Drop intel_update_sprite_watermarks

The only platform that still has an update_sprite_wm entrypoint is SKL; on SKL, intel_update_sprite_watermarks just updates intel_plane->wm and then performs a regular watermark update. However intel_plane->wm is only used to update a couple fields in intel_wm_config, and those fields are never

[Intel-gfx] [PATCH 01/15] drm/i915: Drop redundant watermark programming

In commit commit e4ca061275ec6a48b66c6edebe08644e666994c0 Author: Patrik Jakobsson Date: Wed Jul 8 15:31:52 2015 +0200 drm/i915: Don't forget to mark crtc as inactive after disable we added extra watermark updates to all

[Intel-gfx] [PATCH 09/15] drm/i915: Refactor ilk_update_wm (v3)

From: Ville Syrjälä Split ilk_update_wm() into two parts; one doing the programming and the other the calculations. v2: Fix typo in commit message v3 (by Matt): Heavily rebased for current codebase. Signed-off-by: Ville Syrjälä

Re: [Intel-gfx] [BXT MIPI PATCH v4 14/14] drm/i915: Added BXT DSI backlight support

On Wed, Sep 23, 2015 at 11:30:43PM +0530, Uma Shankar wrote: > DSI backlight support for bxt is added. > > TODO: There is no support for backlight control in drm panel > framework. This will be added as part of VBT version patches > fixing the backlight sequence. > > v2: Fixed Jani's

Re: [Intel-gfx] [PATCH 1/7] drm/i915: fix CFB size calculation

On Wed, Sep 23, 2015 at 12:52:21PM -0300, Paulo Zanoni wrote: > We were considering the whole framebuffer height, but the spec clearly > says that we should only consider the active display height size. > > On my current testing machine, this moves us from 124 successes and > 502 skips to 209

Re: [Intel-gfx] [PATCH 6/7] drm/i915: use compute_page_offset() on SKL too

On Wed, Sep 23, 2015 at 12:52:26PM -0300, Paulo Zanoni wrote: > The trick is not strictly necessary on SKL because the offset > registers allow more bits. But for FBC, doing this changes how the > hardware tracking works - it starts at the surface address we provide > - so there's a higher chance

Re: [Intel-gfx] [PATCH] drm/i915: Detect virtual south bridge

> From: Jesse Barnes [mailto:jbar...@virtuousgeek.org] > Sent: Friday, September 25, 2015 12:41 AM > > On 08/28/2015 05:10 AM, robert.beck...@intel.com wrote: > > From: Robert Beckett > > > > Virtualized systems often use a virtual P2X4 south bridge. > > Detect this in

[Intel-gfx] [PATCH 02/15] drm/i915: Eliminate usage of plane_wm_parameters from ILK-style WM code (v2)

Just pull the info out of the plane state structure rather than staging it in an additional structure. v2: Add 'visible' condition to sprites_scaled so that we don't limit the WM level when the sprite isn't enabled. (Ville) Signed-off-by: Matt Roper

[Intel-gfx] [PATCH 06/15] drm/i915/skl: Eliminate usage of pipe_wm_parameters from SKL-style WM (v3)

Just pull the info out of the state structures rather than staging it in an additional set of structures. To make this more straightforward, we change the signature of several internal WM functions to take the crtc state as a parameter. v2: - Don't forget to skip cursor planes on a loop in the

[Intel-gfx] [PATCH 04/15] drm/i915: Determine I915_MAX_PLANES from plane enum

Let the compiler figure out what I915_MAX_PLANES is from 'enum plane' so that we don't need a separate #define. While we're at it, add the cursor plane to the enum. This will cause I915_MAX_PLANES to now include the cursor plane in its count (it didn't previously). This change is safe since we

[Intel-gfx] [PATCH 00/15] Atomic watermark updates (v5)

Previous version of the series was here: http://lists.freedesktop.org/archives/intel-gfx/2015-September/075883.html Pretty minimal changes since the last series: * General rebasing on di-nightly * Some minor SKL-specific bugfixes on patch #6 based on Maarten's review of v4 of this series.

[Intel-gfx] [PATCH 03/15] drm/i915: Eliminate usage of pipe_wm_parameters from ILK-style WM (v2)

Just pull the info out of the CRTC state structure rather than staging it in an additional structure. Note that we use cstate->active rather than intel_crtc->active which may appear to be a change in behavior. However since we're no longer trying to recalculate watermarks during the "pipe off"

[Intel-gfx] [PATCH v2] drm/i915: set proper N/CTS in modeset

From: Libin Yang When modeset occurs and the TMDS frequency is set to some speical values, the N/CTS need to be set manually if audio is playing. Signed-off-by: Libin Yang --- drivers/gpu/drm/i915/intel_audio.c | 57

Re: [Intel-gfx] [regression] Re: Linux 4.3-rc1

On Wed, Sep 23, 2015 at 11:37 PM, Sedat Dilek wrote: > On Wed, Sep 23, 2015 at 10:48 PM, Sedat Dilek wrote: >> On Wed, Sep 23, 2015 at 3:31 PM, Shuah Khan wrote: >>> On 09/23/2015 02:56 AM, Daniel Vetter wrote: Another