On Fri, Nov 14, 2014 at 08:45:05PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 14, 2014 at 03:49:25PM -0200, Paulo Zanoni wrote:
> > 2014-10-30 15:43 GMT-02:00 :
> > > From: Ville Syrjälä
> > >
> > > On chv the pipe-a power well is the new disp2d well, and it kills pretty
> > > much everything in t
On Saturday 08 November 2014 01:03 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Even with the rps debug messages signficantly recuced by
commit 67956867aa07c59d6d83628bbc9ee4bd9799a1e1
Author: Ville Syrjälä
Date: Tue Sep 2 15:12:17 2014 +0300
drm/i915: Don't spa
On Friday 14 November 2014 01:42 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
GEN6_GT_THREAD_STATUS_REG doesn't seem to exist on VLV. Reads just give
0x0 no matter what the state of the render and media wells.
There was also some hint in the Gunit HAS that thread status not be
On Friday 14 November 2014 01:42 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Bits [18:16] of GEN6_GT_THREAD_STATUS_REG have always had the same
meaning since SNB. So treating them as something special for HSW doesn't
make sense to me.
Also the bits *seem* to work exactly the
On Tuesday 11 November 2014 02:25 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
The divider used in the GPU frequency calculations is compatible between
vlv and chv. vlv just wants doubled values compared to chv.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm
On 11/11/2014 10:30 PM, Jesse Barnes wrote:
> This should allow us to avoid mode sets for some panel fitter config
> changes.
>
> v2:
>- fixup pfit comment (Ander)
> v3:
>- fixup pfit disable shortcut, only apply to gen4 for now (Jesse)
I see that the patch does what it claims it does, so
On Tuesday 11 November 2014 02:25 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Currently we miscalculate the GPU frequency on chv. This causes us to
report the GPU frequency as half of what it really is. Drop the extra
factor of 2 from the calculations to get the correct answer
On Tuesday 11 November 2014 02:25 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/int
On Tuesday 11 November 2014 02:25 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
According to "Cherryview_GFXclocks_y14w36d1.xlsx" the GPU frequency
divider should be 10 in when the CZ clock is 400 MHz. Change the code
to agree so that we report the correct frequencies.
Signed-o
On Saturday 08 November 2014 01:03 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Always print the final PCBR register value on both vlv and chv, and
also tell us whether the BIOS was a good citizen or not.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 8
On Saturday 08 November 2014 01:03 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Our freq<->opcode conversions assume that GPLL is always used.
Apparently that should be the case always, but let's scream if we
ever encounter something different.
Signed-off-by: Ville Syrjälä
--
On Saturday 08 November 2014 01:03 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Remove the magic number for the GPLLENABLE bit by adding a name for it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
2 file
On Tue, Nov 18, 2014 at 02:38:25PM +0530, Deepak S wrote:
>
> On Tuesday 11 November 2014 02:25 AM, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Currently we miscalculate the GPU frequency on chv. This causes us to
> > report the GPU frequency as half of what it really is.
Signed-off-by: Chris Wilson
---
tests/gem_concurrent_blit.c | 233 +---
1 file changed, 198 insertions(+), 35 deletions(-)
diff --git a/tests/gem_concurrent_blit.c b/tests/gem_concurrent_blit.c
index 7d8d628..4c4cd9f 100644
--- a/tests/gem_concurrent_blit.
Signed-off-by: Chris Wilson
---
tests/gem_fence_upload.c | 73
1 file changed, 73 insertions(+)
diff --git a/tests/gem_fence_upload.c b/tests/gem_fence_upload.c
index 88da5dc..81f797b 100644
--- a/tests/gem_fence_upload.c
+++ b/tests/gem_fence_upl
Signed-off-by: Chris Wilson
---
tests/gem_gtt_speed.c | 63 ++-
1 file changed, 62 insertions(+), 1 deletion(-)
diff --git a/tests/gem_gtt_speed.c b/tests/gem_gtt_speed.c
index c68b8e4..d5e745e 100644
--- a/tests/gem_gtt_speed.c
+++ b/tests/gem_gtt
This exercises both the wc mmappings and the extended get_tiling ioctl.
Userspace cannot handle bit17 swizzling through wc mmaps (because bit17
requires swizzling based on the actual physical address of the page -
which is unknown to userspace) and so we need an extended get_tiling
ioctl to report
Signed-off-by: Chris Wilson
---
lib/ioctl_wrappers.c | 81 +++
lib/ioctl_wrappers.h | 5 +
tests/.gitignore | 1 +
tests/Makefile.am | 2 +
tests/Makefile.sources | 1 +
tests/gem_mmap_wc.c| 370 +
6 files changed
On Mon, Nov 17, 2014 at 11:37:19AM +, Chris Wilson wrote:
> Signed-off-by: Chris Wilson
> ---
> lib/ioctl_wrappers.c | 81 +++
> lib/ioctl_wrappers.h | 5 +
> tests/.gitignore | 1 +
> tests/Makefile.am | 2 +
> tests/Makefile.sources | 1 +
> tests/gem_mmap_wc
On Monday 17 November 2014 05:05 PM, Ville Syrjälä wrote:
On Tue, Nov 18, 2014 at 02:38:25PM +0530, Deepak S wrote:
On Tuesday 11 November 2014 02:25 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Currently we miscalculate the GPU frequency on chv. This causes us to
report the
2014-11-14 15:24 GMT-02:00 Damien Lespiau :
> When reading out a DDI config that uses a PLL that is not part of the
> shared_dpll scheme (DPLL0), it's totally normal to end up in the
> default: case of that switch.
Reviewed-by: Paulo Zanoni
>
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu
On Tue, Nov 18, 2014 at 05:59:07PM +0530, Deepak S wrote:
>
> On Monday 17 November 2014 05:05 PM, Ville Syrjälä wrote:
> > On Tue, Nov 18, 2014 at 02:38:25PM +0530, Deepak S wrote:
> >> On Tuesday 11 November 2014 02:25 AM, ville.syrj...@linux.intel.com wrote:
> >>> From: Ville Syrjälä
> >>>
> >
More in line with the usual igt pattern and simplifies the code -
every called just wrapped it in igt_require.
Signed-off-by: Daniel Vetter
---
lib/igt_aux.h| 2 +-
lib/intel_os.c | 25 +
tests/eviction_common.c | 12 ++--
tests
This has the upside that we'll never forget to add it to thrashing
tests. But we'll also never miss to move it when adding basic
functionality tests to existing binaries. Chris already started this
refining work in e.g.
commit d77eda6614a1955717f224be023dedf74eb7735d
Author: Chris Wilson
Date:
On Tue, Nov 18, 2014 at 12:10:51PM +0530, Deepak S wrote:
> On Thursday 13 November 2014 03:58 PM, Thomas Daniel wrote:
> >diff --git a/drivers/gpu/drm/i915/intel_lrc.c
> >b/drivers/gpu/drm/i915/intel_lrc.c
> >index 906b985..f7fa0f7 100644
> >--- a/drivers/gpu/drm/i915/intel_lrc.c
> >+++ b/drivers
On Tue, Nov 18, 2014 at 12:09:54PM +0530, Deepak S wrote:
> On Tuesday 18 November 2014 12:07 PM, Deepak S wrote:
> >With pin specific mutex from previous patch set removed
>
> Oops This comment was for previous patch in the series :( Since i
> reviewed the patch offline, comments got mixed :)
Pl
On Monday 17 November 2014 07:53 PM, Daniel Vetter wrote:
On Tue, Nov 18, 2014 at 12:10:51PM +0530, Deepak S wrote:
On Thursday 13 November 2014 03:58 PM, Thomas Daniel wrote:
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 906b985..f7fa0f7 100644
--- a/d
On Tue, Nov 18, 2014 at 02:48:27PM +0530, Deepak S wrote:
>
> On Saturday 08 November 2014 01:03 AM, ville.syrj...@linux.intel.com wrote:
> >From: Ville Syrjälä
> >
> >Always print the final PCBR register value on both vlv and chv, and
> >also tell us whether the BIOS was a good citizen or not.
>
On Monday 17 November 2014 07:59 PM, Daniel Vetter wrote:
On Tue, Nov 18, 2014 at 12:09:54PM +0530, Deepak S wrote:
On Tuesday 18 November 2014 12:07 PM, Deepak S wrote:
With pin specific mutex from previous patch set removed
Oops This comment was for previous patch in the series :( Since i
r
On Tue, Nov 18, 2014 at 02:44:57PM +0530, Deepak S wrote:
>
> On Tuesday 11 November 2014 02:25 AM, ville.syrj...@linux.intel.com wrote:
> >From: Ville Syrjälä
> >
> >According to "Cherryview_GFXclocks_y14w36d1.xlsx" the GPU frequency
> >divider should be 10 in when the CZ clock is 400 MHz. Chang
On Monday 17 November 2014 06:11 PM, Ville Syrjälä wrote:
On Tue, Nov 18, 2014 at 05:59:07PM +0530, Deepak S wrote:
On Monday 17 November 2014 05:05 PM, Ville Syrjälä wrote:
On Tue, Nov 18, 2014 at 02:38:25PM +0530, Deepak S wrote:
On Tuesday 11 November 2014 02:25 AM, ville.syrj...@linux.int
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On Thu, Nov 13, 2014 at 3:58 PM, Thomas Daniel
wrote:
> From: Oscar Mateo
>
> Up until now, we have pinned every logical ring context backing object
> during creation, and left it pinned until destruction. This made my life
> easier
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On Tue, Nov 18, 2014 at 11:59 AM, Deepak S wrote:
>
> On Thursday 13 November 2014 03:57 PM, Thomas Daniel wrote:
>
>> No longer create a work item to clean each execlist queue item.
>> Instead, move retired execlist requests to a qu
From: Ville Syrjälä
Fill out the lower three digits for gen2 and gen3 cdclk frqeuncy. It's
not clear if these are accurate frquencies or just in the ballpark, but
without docs this is the best we can do.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 22 +++
From: Ville Syrjälä
ilk_get_aux_clock_divider() is now a subset of
hsw_get_aux_clock_divider() so unify them.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 22 +++---
1 file changed, 3 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_
From: Ville Syrjälä
Print a warning if we fall through the .get_display_clock_speed() function
pointer setup. We end up assuming a 133MHz cdclk which should mean that
at least we avoid any 0 deivisions and whatnot. But this could at least
help remind people that they have to provide this function
From: Ville Syrjälä
Now that we are "extracting" the cdclk frequency on ILK-IVB we
can also simplify ilk_get_aux_clock_divider() to calculate the
divider based on cdclk instead of hardcoding the values.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 6 ++
1 file changed
From: Ville Syrjälä
We don't currently have cdclk extraction code for 965g,snb,ivb.
Let's assumee 400 MHz until we know better. That seems to match hints
in various vague documents. Whether that's good enough is not
entirely clear.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_di
From: Ville Syrjälä
Actually read the HPLLCC register insted of assuming it's 0. Fix the
HPLLCC bit definitions and all the missing ones from the 852GME spec.
852GME, 854 and 855 all seem to match the same HPLLC encoding even
though only some of the values are valid is some of the platforms.
Si
From: Ville Syrjälä
Rather that extracting the current cdclk freuqncy every time someone
wants to know it, cache the current value and use that. VLV/CHV already
stored a cached value there so just expand that to cover all platforms.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_dr
From: Ville Syrjälä
Based on the BIOS DP A AUX 2x clock divider the cdclk frequency
on ILK is 450Mhz. At least that holds on my ILK and it matches
how we program the divider.
Supposedly cdclk is 400MHz on SNB and IVB, again based on the AUX 2x
clock divider. Note that I don't have a SNB or IVB m
From: Ville Syrjälä
Unify the HSW/BDW/SKL cdclk extraction code to conform to the same
.get_display_clock_speed() mold that all the other platforms
use.
v2: Update due to SKL code getting added
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_ddi.c| 101 +---
From: Ville Syrjälä
Keep the cdclk maximum supported frequency around in dev_priv so that we
can verify certain things against it before actually changing the cdclk
frequency.
For now only VLV/CHV have support changing cdclk frequency, so other
plarforms get to assume cdclk is fixed.
Signed-off
From: Ville Syrjälä
My main motivation here was to get dev_priv->max_cdclk into place on
all platforms so that we can start to use it to validate modes and
whatnot. This series doesn't actually add any new checks like that
apart from the BDW IPS case, and converting over whatever checks we
alread
From: Ville Syrjälä
We need to tell BDW ULT and ULX apart.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 4aecabb..bf3f33d 100644
--- a/drivers/gpu/d
From: Ville Syrjälä
The specs seem to be full of misinformation wrt. the Punit register
0x36. Some versions still show the old VLV bit layout, some the new
layout, and all of them seem to tell us nonsense about the cdclk
value encoding.
Testing on actual hardware has shown that we simply need to
From: Ville Syrjälä
Bspec says we shouldn't enable IPS on BDW when the pipe pixel rate
exceeds 95% of the core display clock. Apparently this can cause
underruns.
There's no similar restriction listed for HSW, so leave that one alone
for now.
v2: Add pipe_config_supports_ips() (Chris)
v3: Compa
From: Ville Syrjälä
Implement cdclk extraction for g33, 965gm and g4x platforms. The details
came from configdb. Sadly there isn't anything there for other gen3/gen4
chipsets.
So far I've tested this on one ELK where it gave me a HPLL VCO of 5333
MHz and cdclk of 444 MHz which seems perfectly sa
From: Ville Syrjälä
Add support for changing cdclk frequency during runtime on BDW. The
procedure is quite a bit different on BDW from the one on HSW, so
add a separate function for it.
Also with IPS enabled the actual pixel rate mustn't exceed 95% of cdclk,
so take that into account when comput
From: Ville Syrjälä
Rather than reading out the current cdclk value use the cached value we
have tucked away in dev_priv.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c| 3 +--
drivers/gpu/drm/i915/intel_dp.c | 4 ++--
drivers/gpu/drm/i915/intel_pm.c
From: Ville Syrjälä
Implement support for changing the cdclk frequency during runtime on
HSW. VLV/CHV already have support for this, so we can follow their
example for the most part. Only the actual hardware programming differs,
the rest is pretty much the same.
The pipe pixel rate stuff is hand
From: Ville Syrjälä
It seems 852GM/GMV uses a different HPLLCC encoding than the other
85x platforms. For 852GM/GMV cdclk is always 133MHz. Try to detect that
using the PCI revision (sinc the device ID seems useless for that). I'm
not at all sure this is a good idea, but according to the specs it
Here is the actual review...
_
From: Daniel, Thomas
Sent: Wednesday, November 12, 2014 8:52 PM
To: Goel, Akash
Subject: RE: Execlists patches code review
Hi Akash,
I will put the WARN messages back in and remove the need_unpin.
The elsp_submitted cou
On Sat, Nov 15, 2014 at 10:54:47AM +, Damien Lespiau wrote:
> Hi Shuang,
>
> You wanted suggestions, so how about:
>
> For both examples, to determine the size of the column, I'd take the
> length of the longest value of that column (including the title) and add
> 4 to account for spacing. Le
On Sat, Nov 15, 2014 at 01:22:46AM -0800, shuang...@intel.com wrote:
> Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
> shuang...@intel.com)
> -Summary-
> Platform: baseline_drm_intel_nightly_pass_rate->patch_ap
On Monday 03 November 2014 06:59 PM, Dave Gordon wrote:
Fixes to both the LRC and the legacy ringbuffer code to correctly
calculate and update the available space in a ring.
The logical ring code was updating the software ring 'head' value
by reading the hardware 'HEAD' register. In LRC mode, t
On Tue, Nov 18, 2014 at 08:03:15PM +0530, Deepak S wrote:
>
> On Monday 17 November 2014 06:11 PM, Ville Syrjälä wrote:
> > On Tue, Nov 18, 2014 at 05:59:07PM +0530, Deepak S wrote:
> >> On Monday 17 November 2014 05:05 PM, Ville Syrjälä wrote:
> >>> On Tue, Nov 18, 2014 at 02:38:25PM +0530, Deepa
We are not freeing memory allocated for ringbuf and ctx if we fail
to map status page so release all resources correctly.
Signed-off-by: Arun Siluvery
---
drivers/gpu/drm/i915/intel_lrc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b
> -Original Message-
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Arun Siluvery
> Sent: Monday, November 17, 2014 3:48 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915: Free resources correctly if we cannot
> map sta
On 17/11/2014 15:54, Daniel, Thomas wrote:
-Original Message-
From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf
Of Arun Siluvery
Sent: Monday, November 17, 2014 3:48 PM
To: intel-gfx@lists.freedesktop.org
Subject: [Intel-gfx] [PATCH] drm/i915: Free
On Tue, Nov 04, 2014 at 02:17:07PM +, Dave Gordon wrote:
> BTW, I have some local patches which enforce strict checking of
> ring_begin/add_request pairing and generates warnings if there's a
> mismatch or an overrun or any other misuse. We've been using these to
> help identify and eliminate c
2014-11-14 15:24 GMT-02:00 Damien Lespiau :
> The previous clock series didn't include the eDP side of it. This should
> address most of it, for now.
>
> Note that I have some issues with HBR2 and link training here and I'm trying
> to
> find more information about this. So depending on the config
On Mon, Nov 17, 2014 at 03:04:19PM -0200, Paulo Zanoni wrote:
> 2014-11-14 15:24 GMT-02:00 Damien Lespiau :
> > The previous clock series didn't include the eDP side of it. This should
> > address most of it, for now.
> >
> > Note that I have some issues with HBR2 and link training here and I'm
>
From: Zhipeng Gong
On Broadwell GT3 we have 2 Video Command Streamers (VCS), but userspace
has no control when using VCS1 or VCS2. This patch introduces a mechanism
to avoid the default ping-pong mode and use one specific ring through
execution flag.
v2: fix whitespace (Rodrigo)
v3: remove incor
On Thu, Nov 13, 2014 at 10:28:10AM +, Thomas Daniel wrote:
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 059330c..3c7299d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -655,6 +655,7 @@ struct intel_context
When invalid cloning configurations were detected during modeset, we
never copied the error code into the return value variable, leading us
to return 0 (success) to userspace.
Testcase: igt/kms_setmode
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 1 +
1 file changed, 1 in
On Tue, Nov 18, 2014 at 02:10:35PM +0530, Deepak S wrote:
>
> On Friday 14 November 2014 01:42 AM, ville.syrj...@linux.intel.com wrote:
> >From: Ville Syrjälä
> >
> >GEN6_GT_THREAD_STATUS_REG doesn't seem to exist on VLV. Reads just give
> >0x0 no matter what the state of the render and media wel
On Fri, Nov 14, 2014 at 08:52:27AM -0800, Rodrigo Vivi wrote:
> No functional change. Just making it public for use outside intel_dp.c
> Allowing split psr functions.
>
> Signed-off-by: Rodrigo Vivi
Hm, some docbook for the library functions in intel_dp.c used by
intel_ddi.c and other parts of t
On Fri, Nov 14, 2014 at 08:52:41AM -0800, Rodrigo Vivi wrote:
> This patch is the last in series of VLV/CHV PSR,
> that finnaly enable psr by adding it to HAS_PSR
> and calling the proper enable and disable
> functions on the right places.
>
> Although it is still disabled by default.
>
> v2: Reb
On Fri, Nov 14, 2014 at 05:24:33PM +, Damien Lespiau wrote:
> On SKL DPLL0 is used to derive CDCLK but can also be used to drive an
> eDP port (as long as we don't want SSC). DPLL0 is special enough to not
> be handled by the shared DPLL framework (drives CDCLK, not supposed to
> enable the HDM
On Fri, Nov 14, 2014 at 05:24:35PM +, Damien Lespiau wrote:
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index b5a279a..924f1e
On Mon, Nov 17, 2014 at 10:18 AM, Daniel Vetter wrote:
> On Fri, Nov 14, 2014 at 08:52:41AM -0800, Rodrigo Vivi wrote:
>> This patch is the last in series of VLV/CHV PSR,
>> that finnaly enable psr by adding it to HAS_PSR
>> and calling the proper enable and disable
>> functions on the right place
On Mon, Nov 17, 2014 at 11:37:19AM +, Chris Wilson wrote:
> +/**
> + * gem_mmap__wc:
> + * @fd: open i915 drm file descriptor
> + * @handle: gem buffer object handle
> + * @offset: offset in the gem buffer of te mmap arena
> + * @size: size of the mmap arena
> + * @prot: memory protection bits
On Mon, Nov 17, 2014 at 04:43:45PM +0200, ville.syrj...@linux.intel.com wrote:
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index d8841c7..d23aa05 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runti
On Mon, Nov 17, 2014 at 04:43:47PM +0200, ville.syrj...@linux.intel.com wrote:
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 9c6bc82..5eeb456 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@
On Mon, Nov 17, 2014 at 04:43:35PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Fill out the lower three digits for gen2 and gen3 cdclk frqeuncy. It's
> not clear if these are accurate frquencies or just in the ballpark, but
> without docs this is the best we can do.
>
>
On Mon, Nov 17, 2014 at 04:43:40PM +0200, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> We don't currently have cdclk extraction code for 965g,snb,ivb.
> Let's assumee 400 MHz until we know better. That seems to match hints
> in various vague documents. Whether that's good enough
On Mon, Nov 17, 2014 at 09:59:28AM -0800, Matt Roper wrote:
> When invalid cloning configurations were detected during modeset, we
> never copied the error code into the return value variable, leading us
> to return 0 (success) to userspace.
>
> Testcase: igt/kms_setmode
> Signed-off-by: Matt Rope
2014-11-10 11:41 GMT-02:00 Imre Deak :
> Atm we first enable the RPS interrupts then we clear any pending ones.
> By this we could lose an interrupt arriving after we unmasked it. This
> may not be a problem as the caller should handle such a race, but logic
> still calls for the opposite order. Al
Please ignore this patch for now.
On SDP platforms VBT isn't set so we get a false positive on this
value causing frozen screens.
On Fri, Nov 14, 2014 at 8:52 AM, Rodrigo Vivi wrote:
> Let's always skip aux on exit unless specified at VBT we need it.
>
> Signed-off-by: Rodrigo Vivi
> ---
> dri
On Mon, Nov 17, 2014 at 10:30:58AM -0800, Rodrigo Vivi wrote:
> On Mon, Nov 17, 2014 at 10:18 AM, Daniel Vetter wrote:
> > On Fri, Nov 14, 2014 at 08:52:41AM -0800, Rodrigo Vivi wrote:
> >> This patch is the last in series of VLV/CHV PSR,
> >> that finnaly enable psr by adding it to HAS_PSR
> >> a
2014-11-10 11:44 GMT-02:00 Imre Deak :
> When disabling the RPS interrupts there is a tricky dependency between
> the thread disabling the interrupts, the RPS interrupt handler and the
> corresponding RPS work. The RPS work can reenable the interrupts, so
> there is no straightforward order in the
On Mon, Nov 17, 2014 at 03:06:01AM -0800, Rodrigo Vivi wrote:
> From: Zhipeng Gong
>
> On Broadwell GT3 we have 2 Video Command Streamers (VCS), but userspace
> has no control when using VCS1 or VCS2. This patch introduces a mechanism
> to avoid the default ping-pong mode and use one specific rin
On Mon, Nov 17, 2014 at 3:43 PM, wrote:
> From: Ville Syrjälä
>
> Bspec says we shouldn't enable IPS on BDW when the pipe pixel rate
> exceeds 95% of the core display clock. Apparently this can cause
> underruns.
>
> There's no similar restriction listed for HSW, so leave that one alone
> for no
On Mon, Nov 17, 2014 at 07:44:30PM +0100, Daniel Vetter wrote:
> On Mon, Nov 17, 2014 at 04:43:35PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Fill out the lower three digits for gen2 and gen3 cdclk frqeuncy. It's
> > not clear if these are accurate frquencies or
On Mon, Nov 17, 2014 at 03:48:27PM +, Arun Siluvery wrote:
> We are not freeing memory allocated for ringbuf and ctx if we fail
> to map status page so release all resources correctly.
>
> Signed-off-by: Arun Siluvery
> ---
> drivers/gpu/drm/i915/intel_lrc.c | 6 --
> 1 file changed, 4 i
On Mon, 2014-11-17 at 16:49 -0200, Paulo Zanoni wrote:
> 2014-11-10 11:41 GMT-02:00 Imre Deak :
> > Atm we first enable the RPS interrupts then we clear any pending ones.
> > By this we could lose an interrupt arriving after we unmasked it. This
> > may not be a problem as the caller should handle
On Mon, Nov 17, 2014 at 09:59:28AM -0800, Matt Roper wrote:
> When invalid cloning configurations were detected during modeset, we
> never copied the error code into the return value variable, leading us
> to return 0 (success) to userspace.
>
> Testcase: igt/kms_setmode
> Signed-off-by: Matt Rope
On Mon, Nov 17, 2014 at 07:41:44PM +0100, Daniel Vetter wrote:
> On Mon, Nov 17, 2014 at 04:43:45PM +0200, ville.syrj...@linux.intel.com wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index d8841c7..d23aa05 100644
> > --- a/drivers
On Mon, Nov 17, 2014 at 09:06:53PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 17, 2014 at 07:41:44PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 17, 2014 at 04:43:45PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > b/drivers/gpu/drm
On Mon, Nov 17, 2014 at 10:51 AM, Daniel Vetter wrote:
> On Mon, Nov 17, 2014 at 10:30:58AM -0800, Rodrigo Vivi wrote:
>> On Mon, Nov 17, 2014 at 10:18 AM, Daniel Vetter wrote:
>> > On Fri, Nov 14, 2014 at 08:52:41AM -0800, Rodrigo Vivi wrote:
>> >> This patch is the last in series of VLV/CHV PSR
On Mon, Nov 17, 2014 at 09:02:11PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 17, 2014 at 07:44:30PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 17, 2014 at 04:43:35PM +0200, ville.syrj...@linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > Fill out the lower three digits for gen2 an
On Mon, 2014-11-17 at 16:54 -0200, Paulo Zanoni wrote:
> 2014-11-10 11:44 GMT-02:00 Imre Deak :
> > When disabling the RPS interrupts there is a tricky dependency between
> > the thread disabling the interrupts, the RPS interrupt handler and the
> > corresponding RPS work. The RPS work can reenable
On Mon, Nov 17, 2014 at 08:06:47PM +0100, Daniel Vetter wrote:
> On Mon, Nov 17, 2014 at 09:59:28AM -0800, Matt Roper wrote:
> > When invalid cloning configurations were detected during modeset, we
> > never copied the error code into the return value variable, leading us
> > to return 0 (success)
On Mon, Nov 17, 2014 at 07:46:08PM +0100, Daniel Vetter wrote:
> On Mon, Nov 17, 2014 at 04:43:40PM +0200, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > We don't currently have cdclk extraction code for 965g,snb,ivb.
> > Let's assumee 400 MHz until we know better. That seem
On Mon, Nov 17, 2014 at 07:43:39PM +0100, Daniel Vetter wrote:
> On Mon, Nov 17, 2014 at 04:43:47PM +0200, ville.syrj...@linux.intel.com wrote:
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 9c6bc82..5eeb456 100644
> > --- a/drivers/gpu/d
On Mon, 17 Nov 2014 11:17:22 -0800
Matt Roper wrote:
> On Mon, Nov 17, 2014 at 08:06:47PM +0100, Daniel Vetter wrote:
> > On Mon, Nov 17, 2014 at 09:59:28AM -0800, Matt Roper wrote:
> > > When invalid cloning configurations were detected during modeset, we
> > > never copied the error code into t
On Mon, Nov 17, 2014 at 11:12:30AM -0800, Rodrigo Vivi wrote:
> But with your point in mind I got worried about FBC. One of my tasks
> that should be easily here was to put FBC on SKL on the same stage
> that we have currently on previous platforms. Should I just skip that
> while we don't really h
On Mon, Nov 17, 2014 at 12:10:25PM -0800, Jesse Barnes wrote:
> On Mon, 17 Nov 2014 11:17:22 -0800
> Matt Roper wrote:
>
> > On Mon, Nov 17, 2014 at 08:06:47PM +0100, Daniel Vetter wrote:
> > > On Mon, Nov 17, 2014 at 09:59:28AM -0800, Matt Roper wrote:
> > > > When invalid cloning configurations
Just like we do in the HDMI code, set the infoframe flag if we detect an
HDMI sink.
Reported-by: Paulo Zanoni
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_ddi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
1 - 100 of 117 matches
Mail list logo
