On Tue, Oct 15, 2013 at 01:42:53PM -0700, Jesse Barnes wrote:
> On Tue, 15 Oct 2013 17:09:19 -0300
> Paulo Zanoni wrote:
>
> > 2013/10/14 Jesse Barnes :
> > > If we disable the power well at runtime, we need to save enough display
> > > state so we can restore it when the power well comes back ag
There is no functional change on this patch. Only rename several
hdmi encoder function name which suppose to use only by valleyview from
intel_hdmi_pre_pll_enable to vlv_hdmi_pre_pll_enable, and etc.
Signed-off-by: Chon Ming Lee
---
drivers/gpu/drm/i915/intel_hdmi.c | 12 ++--
1 files
On Tue, Oct 15, 2013 at 10:02:57AM -0700, Ben Widawsky wrote:
> From: Ben Widawsky
>
> I've sent this patch several times for various reasons. It essentially
> cleans up a lot of code where we need to do something per ring, and want
> to query whether or not the ring exists on that hardware.
>
>
On Tue, Oct 15, 2013 at 05:50:49PM -0300, Rodrigo Vivi wrote:
> If Userspace isn't using MI_PREDICATE all slices must be enabled for
> backward compatibility.
>
> If I915_EXEC_USE_PREDICATE isn't set and defaul is set to half, kernel will
> force
> all slices on.
>
> v2: fix the inverted logic f
This will be needed for setting the HDMI pixel clock for audio
config. No functional changes.
v2: Now with a commit message.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h |3 ++-
drivers/gpu/drm/i915/intel_display.c | 11 +++
2 files changed, 9 insertions(+),
The HDMI audio expects HDMI pixel clock to be set in the audio
configuration. We've currently just set 0, using 25.2 / 1.001 kHz
frequency, which fails with some modes.
v2: Now with a commit message.
Reference:
http://mid.gmane.org/cagpeb3ep1lrzetpxhgrfbdqr5ts2tac8gcukwwuguf1u5ny...@mail.gmail.c
Mengdong, I meant to CC you on these two patches. Please have a look.
I also screwed up in-reply-to, was meant to be
http://mid.gmane.org/cover.1381765995.git.jani.nik...@intel.com
BR,
Jani.
On Wed, 16 Oct 2013, Jani Nikula wrote:
> This will be needed for setting the HDMI pixel clock for au
On Wed, Oct 16, 2013 at 05:07:41PM +0800, Chon Ming Lee wrote:
> There is no functional change on this patch. Only rename several
> hdmi encoder function name which suppose to use only by valleyview from
> intel_hdmi_pre_pll_enable to vlv_hdmi_pre_pll_enable, and etc.
>
> Signed-off-by: Chon Ming
Also use #ifdef to keep consistent with all other such cases.
Cc: Damien Lespiau
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_irq.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/dr
We not only want const strings, but a const array of them. Reported by
checkpatch.pl
Cc: Damien Lespiau
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu
On Tue, Oct 15, 2013 at 06:55:26PM +0100, Damien Lespiau wrote:
> This series exposes the pipe CRCs on ivybridge through debugfs. It's based on
> the initial work from Shuang He, with some improvements to have a nice user
> space API.
>
> There are several points in the display pipeline where CRCs
On Wed, Oct 16, 2013 at 05:07:41PM +0800, Chon Ming Lee wrote:
> There is no functional change on this patch. Only rename several
> hdmi encoder function name which suppose to use only by valleyview from
> intel_hdmi_pre_pll_enable to vlv_hdmi_pre_pll_enable, and etc.
>
> Signed-off-by: Chon Ming
On Tue, Oct 15, 2013 at 06:55:27PM +0100, Damien Lespiau wrote:
> From: Shuang He
>
> There are several points in the display pipeline where CRCs can be
> computed on the bits flowing there. For instance, it's usually possible
> to compute the CRCs of the primary plane, the sprite plane or the CR
We have two once very similar functions, i915_gpu_idle() and
i915_gem_idle(). The former is used as the lower level operation to
flush work on the GPU, whereas the latter is the high level interface to
flush the GEM bookkeeping in addition to flushing the GPU. As such
i915_gem_idle() also clears ou
On Tue, 2013-10-15 at 13:40 -0700, Jesse Barnes wrote:
> On Tue, 15 Oct 2013 16:54:00 -0300
> Paulo Zanoni wrote:
> [...]
> No that's taken into account here. In __intel_set_mode we take a
> private ref on the appropriate power well so that we'll preserve state
> until we do the first crtc_enable
Yet other direct usages of the pipe number instead of pipe_name().
We've been tracking them lately but managed to miss these last ones.
v2: Catch them all! (Ville)
Reviewed-by: Ville Syrjälä (v1)
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
drivers/gpu/drm/i
On Wed, Oct 16, 2013 at 11:50:01AM +0100, Chris Wilson wrote:
> We have two once very similar functions, i915_gpu_idle() and
> i915_gem_idle(). The former is used as the lower level operation to
> flush work on the GPU, whereas the latter is the high level interface to
> flush the GEM bookkeeping i
Hi Chris,
Thank you very much for all suggestions. Will do the changes. But for
that question below I don't have the clear answer:
On Wed, Oct 16, 2013 at 6:15 AM, Chris Wilson wrote:
> On Tue, Oct 15, 2013 at 05:50:49PM -0300, Rodrigo Vivi wrote:
>> If Userspace isn't using MI_PREDICATE all sli
On Wed, Oct 16, 2013 at 09:12:46AM -0300, Rodrigo Vivi wrote:
> >> + dev_priv->gt_slices.forcing_full = true;
> >> + i915_gt_full_immediate(dev, ring);
> >
> > What happens when this fails? If it only partially emits the commands,
> > etc.
>
> This is a very good question.
On Tue, Oct 15, 2013 at 06:55:30PM +0100, Damien Lespiau wrote:
> Signed-off-by: Damien Lespiau
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/i915_irq.c | 8 ++--
> 3 files changed, 5 insertions(+), 9 deletions(-
On Wed, Oct 16, 2013 at 04:29:32PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 15, 2013 at 06:55:30PM +0100, Damien Lespiau wrote:
> > Signed-off-by: Damien Lespiau
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
> > drivers/gpu/drm/i915/i915_drv.h | 2 +-
> > drivers/gpu/drm/i915/i91
On Wed, Oct 16, 2013 at 03:51:40PM +0200, Daniel Vetter wrote:
> On Wed, Oct 16, 2013 at 04:29:32PM +0300, Ville Syrjälä wrote:
> > On Tue, Oct 15, 2013 at 06:55:30PM +0100, Damien Lespiau wrote:
> > > Signed-off-by: Damien Lespiau
> > > ---
> > > drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
> >
Signed-off-by: Jani Nikula
---
This is useful with the follow-up patch that frobs
dev_priv->vbt.edp_bpp, and the value no longer comes directly from VBT.
---
drivers/gpu/drm/i915/intel_dp.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp
On Wed, Oct 16, 2013 at 03:51:40PM +0200, Daniel Vetter wrote:
> On Wed, Oct 16, 2013 at 04:29:32PM +0300, Ville Syrjälä wrote:
> > On Tue, Oct 15, 2013 at 06:55:30PM +0100, Damien Lespiau wrote:
> > > Signed-off-by: Damien Lespiau
> > > ---
> > > drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
> >
This isn't a real fix to the problem, but rather a stopgap measure while
trying to find a proper solution.
There are several laptops out there that fail to light up the eDP panel
in UEFI boot mode. They seem to be mostly IVB machines, including but
apparently not limited to Dell XPS 13, Asus TX300
On Wed, Oct 16, 2013 at 12:29:54PM +0100, Damien Lespiau wrote:
> Yet other direct usages of the pipe number instead of pipe_name().
> We've been tracking them lately but managed to miss these last ones.
>
> v2: Catch them all! (Ville)
>
> Reviewed-by: Ville Syrjälä (v1)
> Signed-off-by: Damien
This is a prepration for adding support for multiple power-wells needed
by future HW platforms. I pushed the rest of the enabling patches to [1].
I'd like to post the generic parts of those once we agreed how to do the
power-well abstraction.
Except a spinlock->mutex change these patches shouldn't
Upcoming patches will add tracking for a set of power domains via a
bitmask; to make things simple there remove the current gap in the
enum values.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/d
There is no hard need for this to be a spin lock, as we don't take these
locks in irq context from anywhere. An upcoming patch will add calls to
punit read/write functions from within regions protected by this lock
and those functions need a mutex in turn. As a solution for that convert
the spin lo
We'll need the same functionality for other HW generations. The support
for these will be added by upcoming patches.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_display.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/
So far the modeset code enabled all power domains if it needed any. It
wasn't a problem since HW generations so far only had one always-on
power well and one dynamic power well that can be enabled/disabled. For
domains powered by always-on power wells (panel fitter on pipe A and the
eDP transcoder)
It is just cleaner this way and makes it easier to add support for
other HW generations with always-on power wells powering a different
set of domains.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/i915_drv.h | 8
drivers/gpu/drm/i915/intel_pm.c | 84 +++
Currently we make sure that all power domains are enabled during driver
init and turn off unneded ones only after the first modeset. Similarly
during suspend we enable all power domains, which will remain on through
the following resume until the first modeset.
This logic is supported by intel_set
On Tue, Oct 15, 2013 at 09:25:41AM +0100, Chris Wilson wrote:
> > This does indeed stop the server from crashing, but actually makes the
> > problem worse: it used to play video for a few minutes and then crash
> > when trying. With my patch it would play video for a few minutes and
> > then prese
On Wed, 2013-10-16 at 00:09 +0200, Daniel Vetter wrote:
> On Tue, Oct 15, 2013 at 8:15 PM, Imre Deak wrote:
> > Related to this: I made intel_encoder_get_hw_state() only check if the
> > power well is on and return false if it's not to indicate that the
> > encoder is off. I also thought of doing
Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
Specific Data Block to expose more stereo 3D modes.
v2: Use (1 << 0) for consistency. (Ville Syrjälä)
Skip adding any modes if 3D_MASK is indicated as being present but
the length only includes 3D_Structure_ALL. (Ville Syrjäl
On Wed, Oct 16, 2013 at 03:58:50PM +0100, Thomas Wood wrote:
> Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
> Specific Data Block to expose more stereo 3D modes.
>
> v2: Use (1 << 0) for consistency. (Ville Syrjälä)
> Skip adding any modes if 3D_MASK is indicated as being p
On Wed, 16 Oct 2013 14:10:13 +0300
Imre Deak wrote:
> On Tue, 2013-10-15 at 13:40 -0700, Jesse Barnes wrote:
> > On Tue, 15 Oct 2013 16:54:00 -0300
> > Paulo Zanoni wrote:
> > [...]
> > No that's taken into account here. In __intel_set_mode we take a
> > private ref on the appropriate power wel
On Wed, Oct 16, 2013 at 04:30:57PM +0200, Bas Wijnen wrote:
> On Tue, Oct 15, 2013 at 09:25:41AM +0100, Chris Wilson wrote:
> > > This does indeed stop the server from crashing, but actually makes the
> > > problem worse: it used to play video for a few minutes and then crash
> > > when trying. Wi
On Tue, Oct 15, 2013 at 07:44:27PM +0100, Damien Lespiau wrote:
> Signed-off-by: Damien Lespiau
> ---
> lib/Makefile.am | 2 ++
> lib/igt_debugfs.c | 75
> +++
> lib/igt_debugfs.h | 36 ++
> 3 files changed, 113 inser
Once the machine gets to a certain point in the suspend process, we
expect the GPU to be idle. If it is not, we might corrupt memory.
Empirically (with an early version of this patch) we have seen this is
not the case. We cannot currently explain why the latent GPU writes
occur.
In the technical s
Signed-off-by: Ben Widawsky
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/i915_gem_gtt.c | 35 ---
2 files changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6106
2013/10/16 Imre Deak :
> There is no hard need for this to be a spin lock, as we don't take these
> locks in irq context from anywhere. An upcoming patch will add calls to
> punit read/write functions from within regions protected by this lock
> and those functions need a mutex in turn. As a soluti
Once the machine gets to a certain point in the suspend process, we
expect the GPU to be idle. If it is not, we might corrupt memory.
Empirically (with an early version of this patch) we have seen this is
not the case. We cannot currently explain why the latent GPU writes
occur.
In the technical s
On Wed, 2013-10-16 at 13:19 -0300, Paulo Zanoni wrote:
> 2013/10/16 Imre Deak :
> > There is no hard need for this to be a spin lock, as we don't take these
> > locks in irq context from anywhere. An upcoming patch will add calls to
> > punit read/write functions from within regions protected by th
On Wed, Oct 16, 2013 at 01:50:29PM +0200, Daniel Vetter wrote:
> On Wed, Oct 16, 2013 at 11:50:01AM +0100, Chris Wilson wrote:
> > We have two once very similar functions, i915_gpu_idle() and
> > i915_gem_idle(). The former is used as the lower level operation to
> > flush work on the GPU, whereas
On Wed, Oct 16, 2013 at 09:21:30AM -0700, Ben Widawsky wrote:
> Once the machine gets to a certain point in the suspend process, we
> expect the GPU to be idle. If it is not, we might corrupt memory.
> Empirically (with an early version of this patch) we have seen this is
> not the case. We cannot
On Wed, Oct 16, 2013 at 05:58:31PM +0100, Chris Wilson wrote:
> On Wed, Oct 16, 2013 at 09:21:30AM -0700, Ben Widawsky wrote:
> > Once the machine gets to a certain point in the suspend process, we
> > expect the GPU to be idle. If it is not, we might corrupt memory.
> > Empirically (with an early
On Wed, Oct 16, 2013 at 10:06:27AM -0700, Ben Widawsky wrote:
> On Wed, Oct 16, 2013 at 05:58:31PM +0100, Chris Wilson wrote:
> > So clearing the valid bit should result in the GPU reporting errors for
> > delayed accesses, but none were reported?
>
> So I can't actually reproduce the problem for
Since
commit 912d812e84cea8689a2bf3dd13b11dfe191f0f1e
Author: Daniel Vetter
Date: Thu Oct 11 20:08:23 2012 +0200
drm/i915/crt: don't set HOTPLUG bits on !PCH
on VLV we don't detect any VGA unplug event after a modeset, since there we
reset the ADPA hotplug bits. Fix it by preserving the h
On Wed, Oct 16, 2013 at 05:47:26PM +0100, Chris Wilson wrote:
> On Wed, Oct 16, 2013 at 01:50:29PM +0200, Daniel Vetter wrote:
> > On Wed, Oct 16, 2013 at 11:50:01AM +0100, Chris Wilson wrote:
> > > We have two once very similar functions, i915_gpu_idle() and
> > > i915_gem_idle(). The former is us
On Wed, Oct 16, 2013 at 06:10:41PM +0300, Artem Bityutskiy wrote:
> From: Artem Bityutskiy
>
> This patch changes HDMI port registration order for the BayTrail platform.
>
> The story is that in kernel version 3.11 i915 supported only one HDMI port -
> the HDMIB port. So this port ended up being
On Wed, Oct 16, 2013 at 06:07:30PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 16, 2013 at 03:58:50PM +0100, Thomas Wood wrote:
> > Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
> > Specific Data Block to expose more stereo 3D modes.
> >
> > v2: Use (1 << 0) for consistency. (Vill
On Wed, Oct 16, 2013 at 08:39:24PM +0300, Imre Deak wrote:
> Since
>
> commit 912d812e84cea8689a2bf3dd13b11dfe191f0f1e
> Author: Daniel Vetter
> Date: Thu Oct 11 20:08:23 2012 +0200
>
> drm/i915/crt: don't set HOTPLUG bits on !PCH
>
> on VLV we don't detect any VGA unplug event after a mo
On Thu, Oct 10, 2013 at 02:42:40PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 09, 2013 at 09:23:50PM +0200, Daniel Vetter wrote:
> > Hi all,
> >
> > That little patch turned into a bit more, and on top of it there's now also
> > a
> > new testcase in igt: kms_addfb. It checks for most of the evil
BugLink: http://bugs.launchpad.net/bugs/1195483
This reverts commit 657445fe8660100ad174600ebfa61536392b7624.
Signed-off-by: Joseph Salisbury
Cc: Daniel Vetter
Cc: Paulo Zanoni
Cc: David Airlie
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/intel_dp.c | 18 ++
1 file
Hi Daniel,
A bug was opened against the Ubuntu kernel[0]. It was found that reverting the
following commit resolved this bug:
commit 657445fe8660100ad174600ebfa61536392b7624
Author: Daniel Vetter
Date: Sat May 4 10:09:18 2013 +0200
Revert "drm/i915: revert eDP bpp clamping code changes"
On Wed, Oct 16, 2013 at 07:46:27PM +0200, Daniel Vetter wrote:
> On Wed, Oct 16, 2013 at 06:10:41PM +0300, Artem Bityutskiy wrote:
> > Well, certainly this is user-space problem which was exposed with Jesse's
> > patch. However, there is a reason why we have to do this assumption - we use
> > touch
The ringbuffer update logic should always be the same, but different
platforms have different amounts of CRC registers. Hence extract it.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff -
Hi all,
I've stitched together basic CRC support for non-ivb platforms. Still need to do
a bit more testing on this, but ignoring bugs this should be it. We also need to
pimp the igt testcase a bit so that it falls back to the new PIPE source if the
PLANE1 source isn't available.
Review and comme
We enable the interrupt unconditionally and only control it
through the enable bit in the CRC control register.
v2: Extract per-platform helpers to compute the register values.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 74 -
drive
Also add a new _PIPE_INC macro which takes an base plus increment.
Much less likely to botch the job by missing an s/A/B/ somewhere.
v2: They've moved the bitfield. Argh!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_reg.h | 46 +++--
1 file chan
This avoids a spurious spurious interrupt warning.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 323f58e..349f149 100644
--- a/drivers/gpu
Suggested by Ville.
Cc: Ville Syrjälä
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 36465ef..eaf1268 100644
--- a/drivers/gpu
We've set up all files, but removed only those for which we have a
pipe. Which leaves the one for pipe C on machines with less than 2
pipes, breaking module reload.
v2: We can't get at the drm device this early (wtf), so just register
all the files and also remove them all again.
Signed-off-by: D
hw designers decided to change the CRC registers and coalesce them all
into one. Otherwise nothing changed. I've opted for a new hsw_ version
to grab the crc sample since hsw+1 will have the same crc registers,
but different interrupt source registers. So this little helper
function will come handy
Should work down to gen2. The #defines for the interrupt sources are
already there in PIPESTAT and are the same on all gmch platforms for
gen2 up to vlv.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 28 +++-
drivers/gpu/drm/i915/i915_reg.h | 30 +
A bit a mess, since with DP/TV outputs we can't use the pipe CRC.
Also, no plane CRCs, so we need to update the basic testcases.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_reg.h | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_
And throw in a tiny for_each_pipe refactoring for gen2.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 22 --
1 file changed, 16 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 98f5ac3..b3
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_irq.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index b31e7ca..5c3baa0 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/dr
The PIPE_B #define was missing the display mmio offset. Use the
_PIPE_INC macro instead, it's simpler.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_reg.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i91
On pre-gen5 and vlv we can't use the pipe source when TV-out or a DP
port is connected to the pipe. Hence we need to expose new CRC
sources.
Also simplify the existing pipe source platform code a bit by
rejecting all unhandled sources by default.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 44 +++--
1 file changed, 42 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index c504c27..6de9e7e 100644
--- a/drivers/gp
With PLANE1 and PIPE CRC sources the test will work on all currently
shipping (and planed fwiw) platforms.
Also add all the other new sources for non-ivb/hsw chips.
Signed-off-by: Daniel Vetter
---
lib/igt_debugfs.c| 12 +++-
lib/igt_debugfs.h| 7 ++-
tests/debugfs_
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index ff6970b..5841b6f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
++
Really simple, and we don't even have working frame numbers.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_debugfs.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
inde
On Wed, Oct 16, 2013 at 04:34:57PM -0400, Joseph Salisbury wrote:
> BugLink: http://bugs.launchpad.net/bugs/1195483
>
> This reverts commit 657445fe8660100ad174600ebfa61536392b7624.
>
> Signed-off-by: Joseph Salisbury
> Cc: Daniel Vetter
> Cc: Paulo Zanoni
> Cc: David Airlie
> Cc: sta...@vger
On Tuesday, October 08, 2013 10:56:11 AM Daniel Vetter wrote:
> The drm/i915 driver wants to adjust it's own power policies using the
> cpu policies as a guideline (we can implicitly boost the cpus through
> the gpus on some platforms). To avoid a dreaded select (since a
> depends will leave users
On Tue, Oct 08, 2013 at 09:19:06PM +0300, Jani Nikula wrote:
> Signed-off-by: Jani Nikula
> ---
> README | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/README b/README
> index 653bfcd..a04c987 100644
> --- a/README
> +++ b/README
> @@ -96,3 +96,15 @@ debugger/
> i
79 matches
Mail list logo
