Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6208
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Thursday, April 16, 2015 8:03 PM
>To: Jani Nikula
>Cc: R, Durgadoss; intel-gfx@lists.freedesktop.org; Syrjala, Ville; Zanoni,
>Paulo R
>Subject: Re: [Intel-gfx] [PATCH v2] drm/i915: Add debugfs to read a
On 4/16/2015 3:18 PM, Imre Deak wrote:
On to, 2015-04-16 at 12:25 +0300, Imre Deak wrote:
On to, 2015-04-16 at 14:22 +0530, Animesh Manna wrote:
[...]
@@ -223,11 +244,13 @@ static void finish_csr_load(const struct firmware *fw,
void *context)
if (!fw) {
i915_firmware
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6213
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6212
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6211
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
2015-04-15 12:38 GMT-03:00 Todd Previte :
> This patch adds 3 debugfs files for handling Displayport compliance testing
> and supercedes the previous patches that implemented debugfs support for
> compliance testing. Those patches were:
>
> - [PATCH 04/17] drm/i915: Add debugfs functions for Displa
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6210
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
2015-04-15 12:38 GMT-03:00 Todd Previte :
> For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source
> device must attempt at least 7 times to read the EDID when it receives an
> I2C defer. The normal DRM code makes only 7 retries, regardless of whether
> or not the response is a
On Thu, Apr 16, 2015 at 08:40:37PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> All CHV devices will be branded as "Intel(r) HD Graphics".
>
> Signed-off-by: Ville Syrjälä
Tweaked patch 2 to start filling out a gt_info struct like gen7, for the
moment it allows us to s
On Thu, Apr 16, 2015 at 08:40:39PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> Use the correct register (Yn_01) with first half of the
> Y samples instead of using the register (Yn_23) with the
> second half twice when computing the green channel.
>
> Also use the Yn_01
Hi Michael,
I totally understand your concerns, but Installer project just support latest
Ubuntu and latest Fedora, regardless official distro's Long Term Support.
The reason is that in the long term our upgrade might conflict with official
updates causing issues to end users instead of helpi
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6209
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
From: Ville Syrjälä
According to BSpec the max number of VS URB entries for CHV is 640.
Signed-off-by: Ville Syrjälä
---
src/sna/gen8_render.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/sna/gen8_render.c b/src/sna/gen8_render.c
index ebabb2e..8ea40e2 100644
-
From: Ville Syrjälä
All CHV devices will be branded as "Intel(r) HD Graphics".
Signed-off-by: Ville Syrjälä
---
src/intel_module.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/intel_module.c b/src/intel_module.c
index bb74422..faf70ab 100644
--- a/src/intel_module.c
+++ b/src/
From: Ville Syrjälä
Use the correct register (Yn_01) with first half of the
Y samples instead of using the register (Yn_23) with the
second half twice when computing the green channel.
Also use the Yn_01 register name instead of Yn for the red
channel as well, just for a bit of extra consistency
On 4/16/2015 9:31 AM, Daniel Vetter wrote:
On Thu, Apr 16, 2015 at 08:41:33AM -0700, Todd Previte wrote:
On 4/15/2015 10:42 AM, Paulo Zanoni wrote:
2015-04-15 12:37 GMT-03:00 Todd Previte :
On 4/14/2015 9:53 AM, Paulo Zanoni wrote:
2015-04-13 11:53 GMT-03:00 Todd Previte :
Adds in an EDID
On Thu, Apr 16, 2015 at 08:41:33AM -0700, Todd Previte wrote:
> On 4/15/2015 10:42 AM, Paulo Zanoni wrote:
> >2015-04-15 12:37 GMT-03:00 Todd Previte :
> >>On 4/14/2015 9:53 AM, Paulo Zanoni wrote:
> >>>2015-04-13 11:53 GMT-03:00 Todd Previte :
> Adds in an EDID read after the DPCD read to acco
On 15 April 2015 at 11:15, Jani Nikula wrote:
> Produce the man page from rst using rst2man.
>
> FIXME: configure support for checking rst2man.
I think this can be done with a fairly straightforward AC_CHECK_PROG
and AM_CONDITIONAL in configure.ac:
AC_CHECK_PROG(RST2MAN, rst2man, yes, no)
AM_CON
On Thu, Apr 16, 2015 at 8:58 AM, Rodrigo Vivi wrote:
> I'm not sure that that property will be accepted...
> if so it can be changed to toggle, but for now it is informative only
> (DRM_MODE_PROP_IMMUTABLE).
>
Okay, that changes things somewhat. There'll have to be some discussion over
what the s
I'm not sure that that property will be accepted...
if so it can be changed to toggle, but for now it is informative only
(DRM_MODE_PROP_IMMUTABLE).
On Wed, Apr 15, 2015 at 2:51 PM, Eric Caruso wrote:
> On Wed, Apr 15, 2015 at 2:39 PM, Rodrigo Vivi wrote:
>> On Fri, Mar 13, 2015 at 1:46 PM, Eri
Displayport compliance test 4.2.2.6 requires that a source device be capable of
detecting a corrupt EDID. The test specification states that the sink device
sets up the EDID with an invalid checksum. To do this, the sink sets up an
invalid EDID header, expecting the source device to generate the ch
On 4/15/2015 10:42 AM, Paulo Zanoni wrote:
2015-04-15 12:37 GMT-03:00 Todd Previte :
On 4/14/2015 9:53 AM, Paulo Zanoni wrote:
2015-04-13 11:53 GMT-03:00 Todd Previte :
Adds in an EDID read after the DPCD read to accommodate test 4.2.2.1 in
the
Displayport Link CTS Core 1.2 rev1.1. This tes
On Sat, Mar 28, 2015 at 03:23:35PM +0530, deepa...@linux.intel.com wrote:
> From: Deepak S
>
> After feedback from the hardware team we are changing the RC6
> promotional timer to increase the power saving without
> changing performance.
>
> Signed-off-by: Deepak S
> Reviewed-by: Paulo Zanoni
On Thu, 2015-04-16 at 19:53 +0530, Animesh Manna wrote:
>
> On 4/16/2015 4:55 PM, Imre Deak wrote:
> > On to, 2015-04-16 at 17:29 +0530, Animesh Manna wrote:
> >> + Jesse, Rodrigo
> >>
> >> On 04/16/2015 02:51 PM, Imre Deak wrote:
> >>> On to, 2015-04-16 at 14:22 +0530, Animesh Manna wrote:
>
On Thu, Apr 16, 2015 at 05:07:00PM +0300, Jani Nikula wrote:
> On Wed, 08 Apr 2015, Durgadoss R wrote:
> > This patch creates a connector specific debugfs
> > interface to read any particular DPCD register.
> > The DPCD register address (hex format) is written
> > to 'i915_dpcd_addr' interface and
On Thu, Apr 16, 2015 at 09:11:08PM +0800, weiyj...@163.com wrote:
> From: Wei Yongjun
>
> Remove duplicated include.
>
> Signed-off-by: Wei Yongjun
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_audio.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --gi
On 4/16/2015 4:55 PM, Imre Deak wrote:
On to, 2015-04-16 at 17:29 +0530, Animesh Manna wrote:
+ Jesse, Rodrigo
On 04/16/2015 02:51 PM, Imre Deak wrote:
On to, 2015-04-16 at 14:22 +0530, Animesh Manna wrote:
[...]
+#include
+#include "i915_drv.h"
+#include "i915_reg.h"
+
+#define I915_CSR_S
On Thu, Apr 16, 2015 at 12:26:52PM +0200, Maarten Lankhorst wrote:
> This makes disabling planes more explicit.
>
> Signed-off-by: Maarten Lankhorst
> ---
> Changes since v1:
> - Create a intel_crtc_reset function for i915_debugfs.c instead of calling
> .crtc members directly.
> - Remove the che
On Wed, 08 Apr 2015, Durgadoss R wrote:
> This patch creates a connector specific debugfs
> interface to read any particular DPCD register.
> The DPCD register address (hex format) is written
> to 'i915_dpcd_addr' interface and the corresponding
> value can be read from 'i915_dpcd_val' interface.
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6207
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On Thu, Apr 16, 2015 at 11:50:04AM +0100, Chris Wilson wrote:
> On Thu, Apr 16, 2015 at 11:03:20AM +0200, Daniel Vetter wrote:
> > On Wed, Apr 15, 2015 at 04:39:59PM +0100, Chris Wilson wrote:
> > > Since the removal of the user pin_ioctl, the only means for pinning an
> > > object is either throug
On 4/16/2015 6:34 AM, Paulo Zanoni wrote:
2015-04-15 19:03 GMT-03:00 Todd Previte :
Displayport compliance test 4.2.2.6 requires that a source device be capable of
detecting a corrupt EDID. The test specification states that the sink device
sets up the EDID with an invalid checksum. To do this
2015-04-15 19:03 GMT-03:00 Todd Previte :
> Displayport compliance test 4.2.2.6 requires that a source device be capable
> of
> detecting a corrupt EDID. The test specification states that the sink device
> sets up the EDID with an invalid checksum. To do this, the sink sets up an
> invalid EDID h
From: Wei Yongjun
Remove duplicated include.
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/i915/intel_audio.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio.c
index 2396cc7..d00d488 100644
--- a/drivers/gpu/drm/i915/in
On Wed, 15 Apr 2015, Ville Syrjälä wrote:
> BTW it would be a good idaa to include some kind of version number note
> on the whole series as well. Otherwise it could get a bit hard to find
> out which was the latest one. So the usual form is
> "[PATCH vN 00/MM] ..." or something like that.
Both g
On Thu, Apr 16, 2015 at 08:30:55AM -0400, Peter Hurley wrote:
> On 04/15/2015 01:31 PM, Daniel Vetter wrote:
> > On Wed, Apr 15, 2015 at 09:00:04AM -0400, Peter Hurley wrote:
> >> Hi Daniel,
> >>
> >> On 04/15/2015 03:17 AM, Daniel Vetter wrote:
> >>> This was a bit too much cargo-culted, so lets m
On 04/16/2015 02:39 AM, Mario Kleiner wrote:
> On 04/16/2015 03:29 AM, Peter Hurley wrote:
>> On 04/15/2015 05:26 PM, Mario Kleiner wrote:
>> Because the time scales for these events don't require that level of
>> resolution; consider how much code has to get executed between a
>> hardware vblank
On Wed, Apr 15, 2015 at 08:38:47AM -0700, Todd Previte wrote:
> The debug message is missing a newline at the end and it makes the
> logs hard to read when a device defers a lot. Simple 2-character fix
> adds the newline at the end.
>
> Signed-off-by: Todd Previte
> Cc: dri-de...@lists.freedeskto
On Wed, Apr 15, 2015 at 08:38:47AM -0700, Todd Previte wrote:
> The debug message is missing a newline at the end and it makes the
> logs hard to read when a device defers a lot. Simple 2-character fix
> adds the newline at the end.
>
> Signed-off-by: Todd Previte
> Cc: dri-de...@lists.freedeskto
On Wed, Apr 15, 2015 at 08:38:41AM -0700, Todd Previte wrote:
> The Displayport Link Layer Compliance Testing Specification 1.2 rev 1.1
> specifies that repeated AUX transactions after a failure (no response /
> invalid response) must have a minimum delay of 400us before the resend can
> occur. Tes
On 04/15/2015 01:31 PM, Daniel Vetter wrote:
> On Wed, Apr 15, 2015 at 09:00:04AM -0400, Peter Hurley wrote:
>> Hi Daniel,
>>
>> On 04/15/2015 03:17 AM, Daniel Vetter wrote:
>>> This was a bit too much cargo-culted, so lets make it solid:
>>> - vblank->count doesn't need to be an atomic, writes are
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6206
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On Wed, Apr 15, 2015 at 08:38:38AM -0700, Todd Previte wrote:
> Add the skeleton framework for supporting automation for Displayport
> compliance
> testing. This patch adds the necessary framework for the source device to
> appropriately respond to test automation requests from a sink device.
>
>
On to, 2015-04-16 at 17:29 +0530, Animesh Manna wrote:
> + Jesse, Rodrigo
>
> On 04/16/2015 02:51 PM, Imre Deak wrote:
> > On to, 2015-04-16 at 14:22 +0530, Animesh Manna wrote:
> >> [...]
> >> +#include
> >> +#include "i915_drv.h"
> >> +#include "i915_reg.h"
> >> +
> >> +#define I915_CSR_SKL "i9
On Thu, Apr 16, 2015 at 12:05:12PM +0100, Chris Wilson wrote:
> On Thu, Apr 16, 2015 at 01:51:43PM +0300, Mika Kahola wrote:
> > On Thu, 2015-04-16 at 09:02 +0100, Chris Wilson wrote:
> > > On Thu, Apr 16, 2015 at 10:40:51AM +0300, Mika Kahola wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > Ra
On Thu, Apr 16, 2015 at 01:51:43PM +0300, Mika Kahola wrote:
> On Thu, 2015-04-16 at 09:02 +0100, Chris Wilson wrote:
> > On Thu, Apr 16, 2015 at 10:40:51AM +0300, Mika Kahola wrote:
> > > From: Ville Syrjälä
> > >
> > > Rather that extracting the current cdclk freuqncy every time someone
> > > w
+ Jesse, Rodrigo
On 04/16/2015 02:51 PM, Imre Deak wrote:
On to, 2015-04-16 at 14:22 +0530, Animesh Manna wrote:
[...]
+#include
+#include "i915_drv.h"
+#include "i915_reg.h"
+
+#define I915_CSR_SKL "i915/skl_dmc_ver1.bin"
The latest version on the FW download page is skl_dmc_ver4.bin as Dami
On Thu, Apr 16, 2015 at 06:34:06PM +0800, kbuild test robot wrote:
> drivers/gpu/drm/i915/i915_debugfs.c:4850:2-3: Unneeded semicolon
>
>
> Removes unneeded semicolon.
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> CC: Jani Nikula
> Signed-off-by: Fengguang Wu
Applied, thanks
On Thu, 2015-04-16 at 09:02 +0100, Chris Wilson wrote:
> On Thu, Apr 16, 2015 at 10:40:51AM +0300, Mika Kahola wrote:
> > 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
>
On Thu, Apr 16, 2015 at 11:03:20AM +0200, Daniel Vetter wrote:
> On Wed, Apr 15, 2015 at 04:39:59PM +0100, Chris Wilson wrote:
> > Since the removal of the user pin_ioctl, the only means for pinning an
> > object is either through binding to the scanout or during execbuf
> > reservation. As the lat
Signed-off-by: Maarten Lankhorst
---
Changes since v1:
- Clear intel_crtc->atomic at the start of the check function (paranoia).
drivers/gpu/drm/i915/intel_atomic_plane.c | 18 +--
drivers/gpu/drm/i915/intel_display.c | 196 --
drivers/gpu/drm/i915/intel_sprit
This makes disabling planes more explicit.
Signed-off-by: Maarten Lankhorst
---
Changes since v1:
- Create a intel_crtc_reset function for i915_debugfs.c instead of calling
.crtc members directly.
- Remove the checks for intel_crtc->active, they're wrong. (thanks anderco)
drivers/gpu/drm/i915/
On to, 2015-04-16 at 12:25 +0300, Imre Deak wrote:
> On to, 2015-04-16 at 14:22 +0530, Animesh Manna wrote:
> > [...]
> > @@ -223,11 +244,13 @@ static void finish_csr_load(const struct firmware
> > *fw, void *context)
> >
> > if (!fw) {
> > i915_firmware_load_error_print(csr->fw
On to, 2015-04-16 at 11:38 +0200, Daniel Vetter wrote:
> intel_ is for generic code bxt_ and friends for platform specific
> functions. Remove the intel_ prefix to be consistent with our naming.
>
> Random OCD bikeshed I've spotted while merging bxt patches.
>
> Cc: Imre Deak
> Signed-off-by: Da
intel_ is for generic code bxt_ and friends for platform specific
functions. Remove the intel_ prefix to be consistent with our naming.
Random OCD bikeshed I've spotted while merging bxt patches.
v2: Oops, git add fail.
Cc: Imre Deak
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel
intel_ is for generic code bxt_ and friends for platform specific
functions. Remove the intel_ prefix to be consistent with our naming.
Random OCD bikeshed I've spotted while merging bxt patches.
Cc: Imre Deak
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 22 +++---
On Tue, Mar 17, 2015 at 11:40:08AM +0200, Imre Deak wrote:
> From: Satheeshakrishna M
>
> Assign PLL for pipe (dependent on port attached to the pipe)
>
> v2:
> - fix incorrect encoder vs. new_encoder check for crtc (imre)
>
> v3:
> - warn and return error if no encoder is attached (imre)
>
>
Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6205
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
On to, 2015-04-16 at 14:22 +0530, Animesh Manna wrote:
> From: Suketu Shah
>
> Add triggers as per expectations mentioned in gen9_enable_dc5
> and gen9_disable_dc5 patch.
>
> Also call POSTING_READ for every write to a register to ensure that
> its written immediately.
>
> v1: Remove POSTING_RE
On to, 2015-04-16 at 14:22 +0530, Animesh Manna wrote:
> [...]
> +#include
> +#include "i915_drv.h"
> +#include "i915_reg.h"
> +
> +#define I915_CSR_SKL "i915/skl_dmc_ver1.bin"
The latest version on the FW download page is skl_dmc_ver4.bin as Damien
pointed out and skl_dmc_ver1.bin is not availab
On Thu, Apr 16, 2015 at 02:22:07PM +0530, Animesh Manna wrote:
> +#define I915_CSR_SKL "i915/skl_dmc_ver1.bin"
This needs to be skl_dmc_ver4.bin, because that's the version we made
public.
--
Damien
___
Intel-gfx mailing list
Intel-gfx@lists.freedeskto
From: Tvrtko Ursulin
One month passed between posting a patch and it getting merged, and
unfortunately even though it still applies, it needs fixing to account
for changes in function parameters since:
commit d385612e15b8b6eb3db328d83f1872ef8a381788
Author: Tvrtko Ursulin
Date: Tue M
On Wed, Apr 15, 2015 at 04:52:29PM -0700, Rodrigo Vivi wrote:
> From: Jesse Barnes
>
> Same as IBX and G4x, they all share the same genetic material.
>
> v2: we all need a bit more port in our lives
>
> Signed-off-by: Jesse Barnes
> Tested-By: PRC QA PRTS (Patch Regression Test System Contact:
On Thu, Apr 16, 2015 at 09:45:01AM +0300, Imre Deak wrote:
> On ke, 2015-04-15 at 16:52 -0700, Rodrigo Vivi wrote:
> > From: Imre Deak
> >
> > Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across
> > suspend/resume, so fix this.
> >
> > This was introduced in
> >
> > commit
On Wed, Apr 15, 2015 at 04:42:46PM +0100, Chris Wilson wrote:
> Since the pin_ioctl is defunct, we only care about whether an object is
> pinned into the display for debug purposes.
>
> Signed-off-by: Chris Wilson
Queued for -next, thanks for the patch.
-Daniel
> ---
> drivers/gpu/drm/i915/i915
On Thu, Apr 16, 2015 at 05:00:02AM -0400, Peter Hurley wrote:
> On 04/16/2015 02:39 AM, Mario Kleiner wrote:
> > I think i'm still not getting something about why the compiler would
> > be allowed to reorder in this way in absence of the additional
> > smp_rmb? Or is that barrier required for other
On Wed, Apr 15, 2015 at 04:39:59PM +0100, Chris Wilson wrote:
> Since the removal of the user pin_ioctl, the only means for pinning an
> object is either through binding to the scanout or during execbuf
> reservation. As the later prevents a call to set-tiling, we need only
> check if the obj is pi
On 04/16/2015 02:39 AM, Mario Kleiner wrote:
> On 04/16/2015 03:29 AM, Peter Hurley wrote:
>> On 04/15/2015 05:26 PM, Mario Kleiner wrote:
>>> A couple of questions to educate me and one review comment.
>>>
>>> On 04/15/2015 07:34 PM, Daniel Vetter wrote:
This was a bit too much cargo-culted,
This was a bit too much cargo-culted, so lets make it solid:
- vblank->count doesn't need to be an atomic, writes are always done
under the protection of dev->vblank_time_lock. Switch to an unsigned
long instead and update comments. Note that atomic_read is just a
normal read of a volatile va
On Thu, Apr 16, 2015 at 09:07:57AM +0100, Chris Wilson wrote:
> On Thu, Apr 16, 2015 at 10:01:31AM +0200, Daniel Vetter wrote:
> > On Wed, Apr 15, 2015 at 11:47:02AM +0100, Chris Wilson wrote:
> > > On Tue, Apr 14, 2015 at 05:35:21PM +0200, Daniel Vetter wrote:
> > > > Currently we have the problem
On Wed, Apr 15, 2015 at 11:26:37PM +0200, Mario Kleiner wrote:
> A couple of questions to educate me and one review comment.
>
> On 04/15/2015 07:34 PM, Daniel Vetter wrote:
> >This was a bit too much cargo-culted, so lets make it solid:
> >- vblank->count doesn't need to be an atomic, writes are
For v5:
Reviewed-by: Sonika Jindal (v5)
Regards,
Sonika
On 4/16/2015 3:45 AM, Chandra Konduru wrote:
This patch enables skylake sprite plane display scaling using shared
scalers atomic desgin.
v2:
-use single copy of scaler limits (Matt)
v3:
-detaching scalers moved to crtc commit path (Mat
For v5:
Reviewed-by: Sonika Jindal (v5)
Regards,
Sonika
On 4/16/2015 3:44 AM, Chandra Konduru wrote:
This patch enables skylake primary plane scaling using shared
scalers atomic desgin.
v2:
-use single copy of scaler limits (Matt)
v3:
-move detach_scalers to crtc commit path (Matt)
-use val
On Thu, Apr 16, 2015 at 10:01:31AM +0200, Daniel Vetter wrote:
> On Wed, Apr 15, 2015 at 11:47:02AM +0100, Chris Wilson wrote:
> > On Tue, Apr 14, 2015 at 05:35:21PM +0200, Daniel Vetter wrote:
> > > Currently we have the problem that the decision whether ptes need to
> > > be (re)written is splatt
Op 16-04-15 om 09:32 schreef Ander Conselvan De Oliveira:
> On Wed, 2015-04-15 at 16:34 +0200, Maarten Lankhorst wrote:
>> This makes disabling planes more explicit.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/i915_debugfs.c | 4
>> drivers/gpu/drm/i915/intel_disp
On Wed, Apr 15, 2015 at 07:46:56PM +0200, Thomas Richter wrote:
> Hi Daniel, hi Ville,
>
> please find the reworked NS2501 DVO patch with changes as suggested
> attached.
> Unfortunately, the relation between the DVO scaler settings and the actual
> mode
> values remain still somewhat mysterious,
On Thu, Apr 16, 2015 at 10:40:51AM +0300, Mika Kahola wrote:
> 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 plat
On Wed, Apr 15, 2015 at 11:47:02AM +0100, Chris Wilson wrote:
> On Tue, Apr 14, 2015 at 05:35:21PM +0200, Daniel Vetter wrote:
> > Currently we have the problem that the decision whether ptes need to
> > be (re)written is splattered all over the codebase. Move all that into
> > i915_vma_bind. This
From: Suketu Shah
Enable runtime PM for Skylake platform
v2: After adding dmc ver 1.0 support rebased on top of nightly. (Animesh)
Issue: VIZ-2819
Signed-off-by: A.Sunil Kamath
Signed-off-by: Suketu Shah
Signed-off-by: Damien Lespiau
Signed-off-by: Animesh Manna
---
drivers/gpu/drm/i915/i9
From: "A.Sunil Kamath"
This patch just implements the basic enable and disable
functions of DC6 state which is needed for SKL platform.
Its important to load SKL CSR program before calling enable.
DC6 is a deeper power saving state where hardware dynamically
disables power well 0 and saves the
From: Suketu Shah
Warn if the conditions to enter or exit DC6 are not satisfied such
as support for runtime PM, state of power well, CSR loading etc.
v2: Removed camelcase in functions and variables.
v3: Do some minimal check to assert if CSR program is not loaded.
v4:
1] Correct the check for
From: Suketu Shah
Warn if the conditions to enter or exit DC5 are not satisfied such
as support for runtime PM, state of power well, CSR loading etc.
v2: Removed camelcase in functions and variables.
v3: Do some minimal check to assert if CSR program is not loaded.
v4:
1] Used an appropriate f
From: Suketu Shah
Add triggers for DC6 as per details provided in skl_enable_dc6
and skl_disable_dc6 implementations.
Also Call POSTING_READ for every write to a register to ensure
it is written to immediately
v1: Remove POSTING_READ and intel_prepare_ddi calls as they've been added in
previou
From: "A.Sunil Kamath"
This patch just implements the basic enable and disable
functions of DC5 state which is needed for both SKL and BXT.
Its important to load respective CSR program before calling
enable, which anyways will happen as CSR program is executed
during boot.
DC5 is a power saving
v4:
- Removed all warning by reordering the patchsets.
- Changed the dmc firmware file name skl_dmc_ver1.bin, followed naming
conventipon as _dmc_.bin
v3:
MOdified the code of patch 1 and 3 based on review commets.
v2:
Based on review comments modified the code.
v1:
Initial version send as RFC
From: "A.Sunil Kamath"
Display Context Save and Restore support is needed for
various SKL Display C states like DC5, DC6.
This implementation is added based on first version of DMC CSR program
that we received from h/w team.
Here we are using request_firmware based design.
Finally this firmware
From: Suketu Shah
Add triggers as per expectations mentioned in gen9_enable_dc5
and gen9_disable_dc5 patch.
Also call POSTING_READ for every write to a register to ensure that
its written immediately.
v1: Remove POSTING_READ calls as they've already been added in previous patches.
v2: Rebase t
On Thu, Apr 16, 2015 at 12:46:53AM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> Thank you for the patch.
>
> On Friday 10 April 2015 16:22:39 Daniel Vetter wrote:
> > It's a silly thing to do and surprises driver writers. Most likely
> > this did already blow up for exynos.
> >
> > It's also
On Thu, Apr 16, 2015 at 09:28:02AM +0200, Ingo Molnar wrote:
>
> * Chris Wilson wrote:
>
> > For fixed sized copies, copy_to_user() will utilize __put_user_size
> > fastpaths. However, it is missing the translation for 64bit copies on
> > x86/32. Testing on a Pinetrail Atom, the 64 bit put_user
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ä
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ä
v2: Rebased to the latest
Signed-off-by: Mika Kahola
Author:Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 3 +--
drivers/gp
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ä
v2: Rebased to the latest
Signed-off-by: Mika Kahola
Author:Ville Syrjälä
---
drivers/gpu/drm/i915/intel_dp.c | 23 +++
1 file
This patch series rebases Ville's original cdclk patch series
excluding the ones that are already reviewed.
http://lists.freedesktop.org/archives/intel-gfx/2014-November/055633.html
The patches include modifications to
Ville Syrjälä (12):
drm/i915: Fix i855 get_display_clock_speed
drm/i915:
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ä
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ä
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ä
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ä
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
1 - 100 of 115 matches
Mail list logo
