On Mon, Dec 16, 2013 at 04:35:40PM -0800, Jesse Barnes wrote:
On Thu, 12 Dec 2013 14:44:33 -0800
Jesse Barnes jbar...@virtuousgeek.org wrote:
On Thu, 12 Dec 2013 23:39:39 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Thu, Dec 12, 2013 at 01:29:39PM -0800, Jesse Barnes wrote:
On
On Mon, Dec 16, 2013 at 04:01:41PM -0800, Jesse Barnes wrote:
On Sat, 14 Dec 2013 12:01:47 +0100
Daniel Vetter dan...@ffwll.ch wrote:
But I still think the fb lifetime management is a bit broken here and we
need a few small changes:
1. Right here in this loop we need to assign the fb
On Mon, Dec 16, 2013 at 04:34:25PM -0800, Jesse Barnes wrote:
We want to do this early on before we try to fetch the plane config,
which depends on some of the pipe config state.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
I've merged patches 23 from this series. This one here needs
On Mon, Dec 16, 2013 at 08:50:43PM -0800, Ben Widawsky wrote:
Gen8 has already had some differentiation with how it handles rings.
Semaphores bring yet more differences, and now is as good a time as any
to do the split.
Also, since gen8 doesn't actually use semaphores up until this point,
Noticed while reviewing a patch and couldn't resist the OCD.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index
Otherwise we don't kick out firmware framebuffers like vesafb and
efifb when CONFIG_DRM_I915_FBDEV=n but CONFIG_FB=y.
There's still the pesky issue with vgacon which we should somehow
replace with the dummy console at least. We have a similar issue at
module un/reload, since vgacon state is
On Mon, 16 Dec 2013, Chris Wilson ch...@chris-wilson.co.uk wrote:
This has very little effect other than log the errors in case of failure,
and we then hope for the best.
Reviewed-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
On Mon, Dec 16, 2013 at 08:50:36PM -0800, Ben Widawsky wrote:
Reposting this as a new series since two of the patches dropped off
since last time.
Functionally it's the same as before. Like before, the patch drm/i915:
unleash semaphores on gen8 should probably not be merged as it's not
100%
On Mon, 16 Dec 2013, Chris Wilson ch...@chris-wilson.co.uk wrote:
Touching the VGA registers risks a hard machine hang, at least on this
ivb machine after removing a conflicting efifb. This is more than likely
related to the discovery that VGA IO decode on the more recent PCH
platforms is
On Tue, 17 Dec 2013, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Otherwise we don't kick out firmware framebuffers like vesafb and
efifb when CONFIG_DRM_I915_FBDEV=n but CONFIG_FB=y.
There's still the pesky issue with vgacon which we should somehow
replace with the dummy console at least. We
Hi all,
Thanks to Carl Worth we now have a nice pachwork instance for intel-gfx:
http://patchwork.freedesktop.org/project/intel-gfx/list/
We also have a git hook for i-g-t, xf86-video-intel and my drm-intel
repo which will automatically set patches to Accepted when they're
merged.
I'll
On Thu, Dec 12, 2013 at 02:36:36PM +, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Merged this one here, not really sure what to do with the rest.
-Daniel
---
drivers/gpu/drm/i915/intel_pm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
On Mon, Dec 16, 2013 at 08:50:42PM -0800, Ben Widawsky wrote:
@@ -2054,7 +2052,8 @@ int intel_init_bsd_ring_buffer(struct drm_device *dev)
gen6_ring_dispatch_execbuffer;
}
ring-semaphore.sync_to = gen6_ring_sync;
-
On Mon, Dec 16, 2013 at 7:52 PM, Colin Ian King
colin.k...@canonical.com wrote:
Hi there,
There is a S3 resume issue that affects HP Mini Atom N270 with Intel
Mobile 945GSE on Linux 3.9.0 upwards.
Device:
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile
945GSE Express
On Mon, Dec 16, 2013 at 04:34:26PM -0800, Jesse Barnes wrote:
+ if (INTEL_INFO(dev)-gen = 4) {
+ if (plane_config-tiled)
+ offset = I915_READ(DSPTILEOFF(plane));
+ else
+ offset = I915_READ(DSPLINOFF(plane));
+
On Mon, Dec 16, 2013 at 11:38:38PM +0200, Imre Deak wrote:
On Thu, 2013-12-05 at 15:51 +0200, ville.syrj...@linux.intel.com wrote:
Back on the watermark horse. This series moves ILK/SNB/IVB over to the HSW
watermark code.
This series still has some underrun issues since the safe
On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
@@ -333,7 +535,8 @@ MODULE_LICENSE(GPL and additional rights);
void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = dev-dev_private;
-
On Tue, 17 Dec 2013, Daniel Vetter daniel.vet...@ffwll.ch wrote:
Noticed while reviewing a patch and couldn't resist the OCD.
Reviewed-by: Jani Nikula jani.nik...@intel.com
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/i915_drv.c | 6 +++---
1 file changed, 3
On Tue, Dec 17, 2013 at 10:38:48AM +0100, Daniel Vetter wrote:
On Thu, Dec 12, 2013 at 02:36:36PM +, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Merged this one here, not really sure what to do with the rest.
So, apparently, there's some unhappiness with
On Tue, Dec 17, 2013 at 11:21:27AM +0200, Jani Nikula wrote:
On Mon, 16 Dec 2013, Chris Wilson ch...@chris-wilson.co.uk wrote:
Touching the VGA registers risks a hard machine hang, at least on this
ivb machine after removing a conflicting efifb. This is more than likely
related to the
On Tue, Dec 17, 2013 at 11:45:45AM +, Chris Wilson wrote:
On Tue, Dec 17, 2013 at 11:21:27AM +0200, Jani Nikula wrote:
On Mon, 16 Dec 2013, Chris Wilson ch...@chris-wilson.co.uk wrote:
Touching the VGA registers risks a hard machine hang, at least on this
ivb machine after removing a
On Tue, Dec 17, 2013 at 09:33:08AM +0200, Jani Nikula wrote:
On Mon, 16 Dec 2013, Chris Wilson ch...@chris-wilson.co.uk wrote:
If we fail to remove a conflicting fb driver, we need to abort the
loading of the second driver to avoid likely kernel panics.
Signed-off-by: Chris Wilson
On Tue, Dec 17, 2013 at 12:17 PM, Damien Lespiau
damien.lesp...@intel.com wrote:
On Tue, Dec 17, 2013 at 10:38:48AM +0100, Daniel Vetter wrote:
On Thu, Dec 12, 2013 at 02:36:36PM +, Damien Lespiau wrote:
Signed-off-by: Damien Lespiau damien.lesp...@intel.com
Merged this one here, not
On Tue, Dec 17, 2013 at 10:58:23AM +0530, Vandana Kannan wrote:
From: Pradeep Bhat pradeep.b...@intel.com
This patch reads the DRRS support and Mode type from VBT fields.
The read information will be stored in VBT struct during BIOS
parsing. The above functionality is needed for decision
On Tue, Dec 17, 2013 at 10:58:24AM +0530, Vandana Kannan wrote:
From: Pradeep Bhat pradeep.b...@intel.com
This patch and finds out the lowest refresh rate supported for the resolution
same as the fixed_mode, based on the implementaion find_panel_downclock.
It also checks the VBT fields to
On Tue, Dec 17, 2013 at 10:58:26AM +0530, Vandana Kannan wrote:
Adding support to detect display idleness by tracking page flip from
user space. Switch to low refresh rate is triggered after 2 seconds of
idleness. The delay is configurable. If there is a page flip or call to
update the plane,
On Tue, Dec 17, 2013 at 10:58:27AM +0530, Vandana Kannan wrote:
For Broadwell, there is one instance of Transcoder MN values per transcoder.
For dynamic switching between multiple refreshr rates, M/N values may be
reprogrammed on the fly. Link N programming triggers update of all data and
link
No functional change.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index c12767c..f402c16 100644
---
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_reg.h | 36
1 file changed, 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e9548b1..a699efd 100644
---
We use this hook starting from ILK onwards, so change the prefix
accordingly. Also rename functions/struct names used from
haswell_update_wm that are relevant to ILK already.
No functional change.
Signed-off-by: Imre Deak imre.d...@intel.com
---
drivers/gpu/drm/i915/i915_drv.h | 4 +-
2013/12/17 Imre Deak imre.d...@intel.com:
We use this hook starting from ILK onwards, so change the prefix
accordingly. Also rename functions/struct names used from
haswell_update_wm that are relevant to ILK already.
No functional change.
As I mentioned on IRC, my only worry is how many
We attempt to reschedule an active work which can itself corrupt the
workqueue lists, and we may then free the work item whilst the task is
still pending. Both of these may lead to a system deadlock and an
unresponsive machine without any outputs for a panic to even be shown.
[7.372961]
The GMCH_CTRL register (or MGCC in the spec) is at a different address
on Sandybridge, and the address to which we currently write to is
undefined. These stray writes appear to upset (hard hang) my Ivybridge
machine whilst it is in UEFI mode.
Note that the register is still marked as locked RO on
From: Deepak S deepa...@intel.com
RC6 should be enabled only if the PCBR register is programmed properly by
either BIOS or Gfx. This patches address the case where PCBR allocation
fails due buggy BIOS or due to stolen memory allocation fails.
v2: Add #define for magic numbers (Daniel)
From: Deepak S deepa...@intel.com
we're doing forcewake before Disabling RC6, This what the BIOS expects
when going into suspend.
v2: updated commit message (Daniel)
Signed-off-by: Deepak S deepa...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 6 ++
1 file changed, 6 insertions(+)
diff
From: Deepak S deepa...@intel.com
We use RPe here since it should match the Vmin we were shooting for.
That should give us better perf than if we used the min freq available.
System thermal can take the system to lowest possible freq (RPn). We are
making sure, we calmp the freq to min_delay
From: Deepak S deepa...@intel.com
When we enter RC6 and GFX Clocks are off, the voltage remains higher
than Vmin. When we try to set the freq to RPe, it might fail since the
Gfx clocks are down.
So to fix this in Gfx idel,Bring the GFX clock up and set the freq to
RPe then move GFx down.
v2:
From: Deepak S deepa...@intel.com
This patch includes
1. set min delay to rpe delay (Efficient frequency) for better
performace.
2. Disable/Enable PM Intrrupts based on the current freq.
3. WA to fix Voltage is not getting dropped to Vmin when Gfx is power
gated
Deepak
From: Deepak S deepa...@intel.com
When current delay is already at max delay, Let's disable the PM UP
THRESHOLD INTRRUPTS, so that we will not get further interrupts until
current delay is less than max delay, Also request for the PM DOWN
THRESHOLD INTRRUPTS to indicate the decrease in clock
On Tue, Dec 17, 2013 at 08:35:39PM +0530, deepa...@intel.com wrote:
From: Deepak S deepa...@intel.com
We use RPe here since it should match the Vmin we were shooting for.
That should give us better perf than if we used the min freq available.
System thermal can take the system to lowest
On Tue, Dec 17, 2013 at 08:35:40PM +0530, deepa...@intel.com wrote:
From: Deepak S deepa...@intel.com
When current delay is already at max delay, Let's disable the PM UP
THRESHOLD INTRRUPTS, so that we will not get further interrupts until
current delay is less than max delay, Also request
On Tue, 17 Dec 2013, Chris Wilson ch...@chris-wilson.co.uk wrote:
The GMCH_CTRL register (or MGCC in the spec) is at a different address
on Sandybridge, and the address to which we currently write to is
undefined. These stray writes appear to upset (hard hang) my Ivybridge
machine whilst it is
On Tue, 17 Dec 2013 10:52:06 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Mon, Dec 16, 2013 at 7:52 PM, Colin Ian King
colin.k...@canonical.com wrote:
Hi there,
There is a S3 resume issue that affects HP Mini Atom N270 with Intel
Mobile 945GSE on Linux 3.9.0 upwards.
Device:
On Tue, Dec 17, 2013 at 10:17:38AM +0100, Daniel Vetter wrote:
On Mon, Dec 16, 2013 at 08:50:36PM -0800, Ben Widawsky wrote:
Reposting this as a new series since two of the patches dropped off
since last time.
Functionally it's the same as before. Like before, the patch drm/i915:
On 17/12/13 16:30, Jesse Barnes wrote:
On Tue, 17 Dec 2013 10:52:06 +0100
Daniel Vetter daniel.vet...@ffwll.ch wrote:
On Mon, Dec 16, 2013 at 7:52 PM, Colin Ian King
colin.k...@canonical.com wrote:
Hi there,
There is a S3 resume issue that affects HP Mini Atom N270 with Intel
Mobile
We want to disable the (unused) VGA plane on the intel hardware, which
should be a simple matter of writing the vga control register. However,
in 2009 (commit 24f119c769bacac5729297b682fec7811a983cc6), that simple
code was changed to also smash the SR01 VGA register to fix random
crash and
On Tue, Dec 17, 2013 at 09:12:10AM -0800, Keith Packard wrote:
We want to disable the (unused) VGA plane on the intel hardware, which
should be a simple matter of writing the vga control register. However,
in 2009 (commit 24f119c769bacac5729297b682fec7811a983cc6), that simple
code was changed
On Mon, Dec 16, 2013 at 06:07:14PM -0200, Paulo Zanoni wrote:
2013/12/16 Daniel Vetter dan...@ffwll.ch:
On Mon, Dec 16, 2013 at 05:19:25PM +, Chris Wilson wrote:
Touching the VGA resources on an IVB EFI machine causes hard hangs when
we then kick out the efifb. Ouch.
Please take a
Chris Wilson ch...@chris-wilson.co.uk writes:
The bspec still says we must assert SR01 bit5 prior to disabling the VGA
plane.
Perhaps the test should be whether (vga_reg VGA_DISP_DISABLE) == 0 and
do nothing if the plane is already off.
The problem is that for some reason we're smashing
On Tue, Dec 17, 2013 at 04:29:56PM +, Damien Lespiau wrote:
On Tue, Dec 17, 2013 at 10:17:38AM +0100, Daniel Vetter wrote:
On Mon, Dec 16, 2013 at 08:50:36PM -0800, Ben Widawsky wrote:
Reposting this as a new series since two of the patches dropped off
since last time.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 6 +++---
drivers/gpu/drm/i915/intel_drv.h | 1 -
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
On Mon, Dec 16, 2013 at 08:50:47PM -0800, Ben Widawsky wrote:
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Can you source this recommendation, even if just personal communication?
Is this likely to be temporary? Will a difference (power, latency)
ever be measurable?
-Chris
--
Chris Wilson,
2013/12/17 Rodrigo Vivi rodrigo.v...@gmail.com:
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 6 +++---
drivers/gpu/drm/i915/intel_drv.h | 1 -
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git
On Mon, 07 Oct 2013 11:05:57 +0300
Jani Nikula jani.nik...@linux.intel.com wrote:
On Fri, 04 Oct 2013, Todd Previte tprev...@gmail.com wrote:
- DP_TEST_LINK_PATTERN is ambiguous, rename to DP_TEST_LINK_VIDEO_PATTERN
to clarify
- Added DP_TEST_LINK_FAUX_PATTERN to support automated
This patch adds PSR Support to Baytrail.
Baytrail cannot easily detect screen updates and force PSR exit.
So we inactivate it on busy_ioctl and update to get it back
on next display mark_idle.
The current issue with this implementation is the cursor updates.
(Yet to be fixed).
Signed-off-by:
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 6 +++---
drivers/gpu/drm/i915/intel_drv.h | 1 -
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
This patch adds PSR Support to Baytrail.
Baytrail cannot easily detect screen updates and force PSR exit.
So we inactivate it on busy_ioctl and update to get it back
on next display mark_idle.
v2: Also inactivate PSR on cursor update.
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
On Mon, Dec 16, 2013 at 08:50:44PM -0800, Ben Widawsky wrote:
+static int gen8_rcs_signal(struct intel_ring_buffer *signaller,
+unsigned int num_dwords)
+{
+#define MBOX_UPDATE_DWORDS 8
+ struct drm_device *dev = signaller-dev;
+ struct drm_i915_private
On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
int intel_fbdev_init(struct drm_device *dev)
@@ -268,17 +461,25 @@ int intel_fbdev_init(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
int ret;
- ifbdev = kzalloc(sizeof(*ifbdev),
On Sat, 2013-12-14 at 20:38 -0200, Rodrigo Vivi wrote:
From: Imre Deak imre.d...@intel.com
At least on my VLV stepping VGA detection doesn't work in certain cases.
One such case is when all pipes are off and VGA is plugged in. Another
case reported by Joonas Lahtinen (also on the same
On Tue, Dec 17, 2013 at 10:17:24AM -0800, Keith Packard wrote:
Chris Wilson ch...@chris-wilson.co.uk writes:
The bspec still says we must assert SR01 bit5 prior to disabling the VGA
plane.
Perhaps the test should be whether (vga_reg VGA_DISP_DISABLE) == 0 and
do nothing if the plane
On Mon, Dec 16, 2013 at 08:50:45PM -0800, Ben Widawsky wrote:
Semaphore waits use a new instruction, MI_SEMAPHORE_WAIT. The seqno to
wait on is all well defined by the table in the previous patch. There is
nothing else different from previous GEN's semaphore synchronization
code.
v2: Update
On Tue, Dec 17, 2013 at 6:06 PM, Paulo Zanoni przan...@gmail.com wrote:
2013/12/17 Rodrigo Vivi rodrigo.v...@gmail.com:
Signed-off-by: Rodrigo Vivi rodrigo.v...@gmail.com
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_dp.c | 6 +++---
On Mon, Dec 16, 2013 at 08:50:48PM -0800, Ben Widawsky wrote:
Refactoring semaphore error state capture in preparation for future
hardware support.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
A trivial explanation for a trivial patch is better than none. :)
-Chris
--
Chris Wilson, Intel
VGA detection requires the reference clock to be on, so make sure this
is the case.
This fixes VGA hotplug/manual detection where all pipes are off and so
we would normally disable all clocks.
v2:
- Instead of disabling PSR clock gating, force the reference clock on
through the DPLL_A
On Tue, 17 Dec 2013 09:38:36 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Mon, Dec 16, 2013 at 04:01:41PM -0800, Jesse Barnes wrote:
On Sat, 14 Dec 2013 12:01:47 +0100
Daniel Vetter dan...@ffwll.ch wrote:
But I still think the fb lifetime management is a bit broken here and we
need a
On Tue, 17 Dec 2013 10:03:12 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Dec 16, 2013 at 04:34:26PM -0800, Jesse Barnes wrote:
+ if (INTEL_INFO(dev)-gen = 4) {
+ if (plane_config-tiled)
+ offset = I915_READ(DSPTILEOFF(plane));
+ else
On Tue, 17 Dec 2013 10:34:39 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
@@ -333,7 +535,8 @@ MODULE_LICENSE(GPL and additional rights);
void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
struct
On Tue, Dec 17, 2013 at 10:05 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
@@ -333,7 +535,8 @@ MODULE_LICENSE(GPL and additional rights);
void intel_fbdev_output_poll_changed(struct drm_device *dev)
{
struct
On Tue, 17 Dec 2013 22:17:22 +0100
Daniel Vetter dan...@ffwll.ch wrote:
On Tue, Dec 17, 2013 at 10:05 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
@@ -333,7 +535,8 @@ MODULE_LICENSE(GPL and additional rights);
void
On Tue, Dec 17, 2013 at 10:04 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
Hm yeah the ownership is less clear in the CONFIG_FB=n case. I think
the driver will own the buffer, and it'll get dropped on the first mode
set with a new buffer. But even then there will be no process to deref
On Mon, Dec 16, 2013 at 08:50:38PM -0800, Ben Widawsky wrote:
Aside from the fact that it leaves confusing dumps on error capture, it
is entirely unnecessary, and potentially harmful in cases like BDW,
where the instruction has changed.
In reality (seemingly), this will have no behavioral
On Tue, Dec 17, 2013 at 10:30 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
On Tue, Dec 17, 2013 at 10:05 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
@@ -333,7 +535,8 @@ MODULE_LICENSE(GPL and additional rights);
On Tue, 17 Dec 2013 19:29:00 +
Chris Wilson ch...@chris-wilson.co.uk wrote:
On Mon, Dec 16, 2013 at 04:34:27PM -0800, Jesse Barnes wrote:
int intel_fbdev_init(struct drm_device *dev)
@@ -268,17 +461,25 @@ int intel_fbdev_init(struct drm_device *dev)
struct drm_i915_private
On Tue, Dec 17, 2013 at 07:24:41PM +, Chris Wilson wrote:
On Mon, Dec 16, 2013 at 08:50:38PM -0800, Ben Widawsky wrote:
Aside from the fact that it leaves confusing dumps on error capture, it
is entirely unnecessary, and potentially harmful in cases like BDW,
where the instruction has
But only when we indeed set up a gtt mapping. We need this since the
vma also holds a pages_pin_count, on top of the unconditional
pages_pin_count we grab for all stolen objects (to avoid swap-out).
This should avoid a pages_pin_count underrun when cleaning up
framebuffers objects taken over from
Just add an early init since we may need to access DPIO regs early on.
The init call in modeset_init_hw is also needed for the resume case,
when we need to reset DPIO to keep things happy.
v2: split reset and reg init
v3: split patches (Daniel)
Signed-off-by: Jesse Barnes
Along with refcounting changes and breakage.
---
drivers/gpu/drm/i915/i915_gem_stolen.c | 2 ++
drivers/gpu/drm/i915/intel_display.c | 39 ++
drivers/gpu/drm/i915/intel_drv.h | 1 -
drivers/gpu/drm/i915/intel_fbdev.c | 19 -
4 files
---
drivers/gpu/drm/i915/i915_reg.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 2d20390..f91cb12 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2119,9
Read out the current plane configuration at init time into a new
plane_config structure. This allows us to track any existing
framebuffers attached to the plane and potentially re-use them in our
fbdev code for a smooth handoff.
v2: update for new pitch_for_width function (Jesse)
comment how
For use by get_plane_config.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index
We only need to init the reg offset for DPIO once, but we need to reset
DPIO at resume time and at init time.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git
We want to do this early on before we try to fetch the plane config,
which depends on some of the pipe config state.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
On Tue, Dec 17, 2013 at 02:02:23PM -0800, Ben Widawsky wrote:
On Tue, Dec 17, 2013 at 07:24:41PM +, Chris Wilson wrote:
On Mon, Dec 16, 2013 at 08:50:38PM -0800, Ben Widawsky wrote:
Aside from the fact that it leaves confusing dumps on error capture, it
is entirely unnecessary, and
Allocate this struct instead, so we can re-use another allocated
elsewhere if needed.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
drivers/gpu/drm/i915/intel_drv.h | 2 +-
drivers/gpu/drm/i915/intel_fbdev.c | 27
On Tue, Dec 17, 2013 at 10:58:51PM +0100, Daniel Vetter wrote:
On Tue, Dec 17, 2013 at 10:30 PM, Jesse Barnes jbar...@virtuousgeek.org
wrote:
So in the unlikely event that the fb helper code fails I don't want to
fall over.
But that shouldn't happen in practice. I only have the checks
Retrieve current framebuffer config info from the regs and create an fb
object for the buffer the BIOS or boot loader left us. This should
allow for smooth transitions to userspace apps once we finish the
initial configuration construction.
v2: check for non-native modes and adjust (Jesse)
The BIOS or boot loader will generally create an initial display
configuration for us that includes some set of active pipes and
displays. This routine tries to figure out which pipes and connectors
are active and stuffs them into the crtcs and modes array given to us by
the drm_fb_helper code.
Semaphore signalling works similarly to previous GENs with the exception
that the per ring mailboxes no longer exist. Instead you must define
your own space, somewhere in the GTT.
The comments in the code define the layout I've opted for, which should
be fairly future proof. Ie. I tried to define
A couple patches in the upcoming rework of semaphores will break if
semaphores are toggled by the user at various times. Since the code
cleanups there seem to be an overall win, and toggling semaphores at
runtime is not a terribly useful thing to do, simply make the module
parameter read-only.
Semaphore waits use a new instruction, MI_SEMAPHORE_WAIT. The seqno to
wait on is all well defined by the table in the previous patch. There is
nothing else different from previous GEN's semaphore synchronization
code.
v2: Update macros to not require the other ring's ring-id (Chris)
v3: Use a
On Tue, Dec 17, 2013 at 07:14:27PM +, Chris Wilson wrote:
On Mon, Dec 16, 2013 at 08:50:48PM -0800, Ben Widawsky wrote:
Refactoring semaphore error state capture in preparation for future
hardware support.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
A trivial explanation for a
On Tue, Dec 17, 2013 at 11:42:11PM +0100, Daniel Vetter wrote:
But only when we indeed set up a gtt mapping. We need this since the
vma also holds a pages_pin_count, on top of the unconditional
pages_pin_count we grab for all stolen objects (to avoid swap-out).
This should avoid a
Chris Wilson ch...@chris-wilson.co.uk writes:
Ok, so as no vgaarb_clients have yet been registered and so the call to
grab the IO resource does not actually disable VGA IO routing to the
nvidia card.
Yikes! This explains a lot.
If you care to update the changelog to explain the problem is
On Tue, Dec 17, 2013 at 10:14 PM, Chris Wilson ch...@chris-wilson.co.uk wrote:
On Tue, Dec 17, 2013 at 09:33:08AM +0200, Jani Nikula wrote:
On Mon, 16 Dec 2013, Chris Wilson ch...@chris-wilson.co.uk wrote:
If we fail to remove a conflicting fb driver, we need to abort the
loading of the
Hi all,
Today's linux-next merge of the drm-intel tree got a conflict in
drivers/gpu/drm/i915/intel_pm.c between commit fec8cba306f9 (drm/i915:
use crtc_htotal in watermark calculations to match fastboot v2) from
Linus' tree and commit 96f90c5421aa (drm/i915: Move ILK/SNB/IVB over to
the HSW WM
The ring will emit too many if semaphores are disabled since we do not
add the correct number to num_dwords anymore.
This was introduced:
commit 52ed23253b68e1cf154b03d91bed619504cf955b
Author: Ben Widawsky benjamin.widaw...@intel.com
Date: Mon Dec 16 20:50:38 2013 -0800
drm/i915: Don't
Use helper functions to simplify _DSM related code in i915 driver.
Function intel_dsm() is used to check functions supported by ACPI _DSM
method, but it has strange check for special value 0x8002. After
digging into nouveau driver, I think the check is copied from nouveau
driver and is
98 matches
Mail list logo
