On Mon, Nov 17, 2014 at 06:10:36PM -0800, Matt Roper wrote:
> From: Gustavo Padovan
>
> We need to get hdisplay and vdisplay in a few places so create a
> helper to make our job easier.
>
> v2 (by Matt): Use new stereo doubling function (suggested by Ville)
>
> Cc: dri-de...@lists.freedesktop.o
On Mon, Nov 17, 2014 at 08:04:09PM +0100, Daniel Vetter wrote:
> 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
>
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
BYT: pass/total=290/291->290/291
PNV: pass/total=356/356->354
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
BYT: pass/total=290/291->290/291
PNV: pass/total=356/356->355
can you boot with drm.debug=6 and send me a copy?
Dave.
- Original Message -
> From: "Michal Nazarewicz"
> To: "David Airlie"
> Cc: intel-gfx@lists.freedesktop.org
> Sent: Tuesday, 11 November, 2014 2:54:11 AM
> Subject: Re: drm-i915-mst + Ubuntu 14.04 + HP 840
>
> On Fri, Nov 07 2014
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On Thu, Nov 13, 2014 at 3:58 PM, Thomas Daniel
wrote:
> Same as with the context, pinning to GGTT regardless is harmful (it
> badly fragments the GGTT and can even exhaust it).
>
> Unfortunately, this case is also more complex than
Reviewed the patch & it looks fine.
Reviewed-by: "Akash Goel "
On Mon, Nov 3, 2014 at 6: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 'he
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
BYT: pass/total=290/291->291/291
PNV: pass/total=356/356->356
When using the universal plane interface, the source rectangle
coordinates define the panning offset for the primary plane, which needs
to be stored in crtc->{x,y}. The original universal plane code
negelected to set these panning offset fields, which was partially
remedied in:
commit ccc
There are places where we want to perform vertical doubling for stereo
modes without the other adjustments (doublescan, vscan > 1, etc.) that
drm_mode_set_crtcinfo() performs. Refactor this logic into its own
function so that it can be called directly in such places.
Cc: dri-de...@lists.freedeskt
From: Gustavo Padovan
After some refactor intel_primary_plane_setplane() does the same
as intel_pipe_set_base() so we can get rid of it and replace the calls
with intel_primary_plane_setplane().
v2: take Ville's comments:
- get the right arguments for update_plane()
- use drm_crt
From: Gustavo Padovan
Merge it into the plane update_plane() callback and make other
users use the update_plane() functions instead.
The fb != crtc->cursor->fb was already inside intel_crtc_cursor_set_obj()
so we fold intel_crtc_cursor_set_obj() inside intel_commit_cursor_plane()
and merge both
From: Gustavo Padovan
We need to get hdisplay and vdisplay in a few places so create a
helper to make our job easier.
v2 (by Matt): Use new stereo doubling function (suggested by Ville)
Cc: dri-de...@lists.freedesktop.org
Suggested-by: Ville Syrjälä
Signed-off-by: Gustavo Padovan
Signed-off-b
This patch set continues the work that Gustavo Padovan (Collabora) started to
refactor the i915 display code in preparation for atomic modeset. Gustavo's
patches have been updated to work with the latest drm-intel-nightly code and
the review feedback that came in after he got pulled away to work o
Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
-Summary-
Platform: baseline_drm_intel_nightly_pass_rate->patch_applied_pass_rate
BYT: pass/total=290/291->291/291
PNV: pass/total=356/356->356
>> + /*
>> +* FIXME if we compare against max we should then
>> +* increase the cdclk frequency when the current
>> +* value is too low. The other option is to compare
>> +* against the cdclk frqeuncy we're going have post
>> +* modeset (ie. one we comp
The lack of a break here wasn't for falling through to some other
important code, so made me do a double take. Add a break just to make
things a little less confusing.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_ddi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gp
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
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
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, 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 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, 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 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, 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 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, 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: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 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: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, 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 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, 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 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 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
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 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
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
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
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 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 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: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: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 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 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 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 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 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 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 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
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 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
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 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
>
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 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
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
> -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
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
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
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 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 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
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
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
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ä
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ä
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ä
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ä
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ä
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ä
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ä
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ä
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ä
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ä
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ä
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
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
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
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
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 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: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: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 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 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
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:
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
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ä
> >>>
> >
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 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
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
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
1 - 100 of 117 matches
Mail list logo
