The server no longer supports the allocator wrapping functions.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/drmmode_display.c | 20 +-
src/i810_dga.c |4 +-
src/i810_dri.c | 50
src/i810_driver.c
On Wed, 23 Jun 2010 00:14:39 -0700, Gregory Diamos gregory.dia...@gatech.edu
wrote:
1. Is there an interface for writing directly to the GPU ring buffer
that is exposed by the driver? If not, would it be straightforward to
add such an interface?
Take a look at 'drm' in the mesa git
On Fri, 02 Jul 2010 09:24:07 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
This looks like the responsibility of miCloseScreen(). Are we failing to
chain up properly?
I don't think miCloseScreen (or fbCloseScreen) can do this -- before
we're called, rendering may not have been finished,
On Wed, 14 Jul 2010 15:40:56 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=28739. We need to
enable power to the panel with the AUX VDD bit in order to properly
detect the eDP attached panel, and we also need to turn the panel on in
Jack marty...@comcast.net
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: Keith Packard kei...@keithp.com
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpD06RpFALGL.pgp
Description: PGP signature
___
Intel-gfx
On Thu, 23 Sep 2010 09:04:11 -0400, Kristian Høgsberg k...@bitplanet.net
wrote:
Signed-off-by: Kristian Høgsberg k...@bitplanet.net
---
Chris Wilson points out that we were still accessing c-next after free.
Here's an updated version that fixes that.
I've merged this patch (and attempted
.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c | 19 +--
1 files changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 1a51ee0..9ab8708 100644
--- a/drivers/gpu/drm/i915
only do this when we're not about to wait for
the pipe to turn off.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 62 +-
drivers/gpu/drm/i915/intel_drv.h |1 -
2 files changed, 38 insertions(+), 25 deletions
On Sun, 3 Oct 2010 08:10:48 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Do these fixes help with the DP issues you've been seeing, Keith?
Seems like the first one shouldn't change behavior since we ought to
time out on waiting on vblank in that case, and the timeout is the same
as
The display port DPMS state is tracked internally in the display port
driver so that when a hotplug event comes along, the driver can know
whether to try retraining the link. This doesn't work well if the
driver never sets the DPMS state to ON when the output is enabled.
Signed-off-by: Keith
.
Signed-off-by: Keith Packard kei...@keithp.com
---
configure.ac |5 ++
src/Makefile.am|4 +-
src/intel.h| 11 +
src/intel_driver.c | 114
4 files changed, 132 insertions(+), 2 deletions(-)
diff --git
On Sun, 03 Oct 2010 22:05:13 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
It appears that all users (crtc and encoders) are tracking dpms_mode, in
one form or another. Should we move this to core?
Sounds like a good idea. Would you prefer to do that yourself?
Is there any hardware
.
V2: missed a #ifdef HAVE_UDEV around some udev-specific declarations
Signed-off-by: Keith Packard kei...@keithp.com
---
configure.ac |5 ++
src/Makefile.am|4 +-
src/intel.h| 12 +
src/intel_driver.c | 114
4
On Mon, 4 Oct 2010 06:33:01 +1000, Dave Airlie airl...@gmail.com wrote:
don't you do this already? both radeon/nouveau handle DP replug fine,
I thought Intel would have been where I stole the code from.
There was a one-line bug. Patch already posted.
--
keith.pack...@intel.com
Cancel the output polling work proc before acquiring the struct mutex
to avoid acquiring the work proc mutex with the struct mutex
held. This avoids inverting the lock order seen when the work proc
runs.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c
A physically mapped hardware status page is allocated at driver load
time but was never freed. Call the existing code to free this page at
driver unload time on hardware which uses this kind.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_dma.c |3 +++
1 files
when we only
needed a single copy, but as 64-bit access requires its own version,
it makes sense to just split them out for each size.
Signed-off-by: Eric Anholt e...@anholt.net
Signed-off-by: Keith Packard kei...@keithp.com
---
On Thu, 18 Nov 2010 10:05:00 +0800, Eric Anholt e...@anholt.net wrote
On Sat, 20 Nov 2010 16:17:40 +0100, Matthias Hopf mh...@suse.de wrote:
I know, I know. The patch is (one of) the results of the Novell-HP-Intel
workshop in Taipei this week. It turned out that rev07 is too unstable.
Keith and Eric can probably comment on this. Better than I can.
There's a
On Fri, 26 Nov 2010 11:45:38 +0300, Dan Carpenter erro...@gmail.com wrote:
Where are the patches? I pulled drm-next but I don't see them.
Looks like he hasn't merged them. I'm building drm-intel-next with this
and another patch.
I've pushed my bits to
When setting a new crtc configuration, force the DPMS state of all
connectors to ON. Otherwise, they'll be left at OFF and a future mode set
that disables the specified connector will not turn the connector off.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/drm_crtc_helper.c
In order to correctly report monitor connected status changes, the
previous monitor status must be recorded in the connector-status
value instead of being discarded.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/drm_crtc_helper.c |7 ---
1 files changed, 4 insertions
On Sun, 5 Dec 2010 13:27:43 +0100, Florian Mickler flor...@mickler.org wrote:
On Fri, 26 Nov 2010 10:45:59 -0800
Keith Packard kei...@keithp.com wrote:
In order to correctly report monitor connected status changes, the
previous monitor status must be recorded in the connector-status
On Wed, 08 Dec 2010 17:08:04 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Wed, 8 Dec 2010 17:34:24 +0100, Florian Mickler flor...@mickler.org
wrote:
Does that mean that the kernel regression will not be
fixed/worked-around for old userspace?
I think there is some confusion in
On Mon, 20 Dec 2010 14:00:54 -0500, Andy Lutomirski l...@mit.edu wrote:
Enabling and disabling the vblank interrupt (on devices that
support it) is cheap. So disable it quickly after each
interrupt.
So, the concern (and reason for the original design) was that you might
lose count of vblank
On Mon, 20 Dec 2010 22:34:12 -0500, Andrew Lutomirski l...@mit.edu wrote:
But five seconds is a *long* time, and anything short enough that the
interrupt actually gets turned off in normal use risks the same race.
Right, so eliminating any race seems like the basic requirement. Can
that be
On Tue, 21 Dec 2010 11:36:44 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
I think once upon a time I found a reliable method in the docs:
intel_lvds_ddc_probe(). However that only seemed to work over GMBUS...
That probably depends on the panel having DDC, which many don't, right?
Maybe
On Tue, 21 Dec 2010 19:55:15 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
The test we do is simply whether the LVDS i2c pins are addressable. That
requires differentiating between an IO error and a NAK, which at present
is only possible using GMBUS. The reference to this method I found
On Thu, 20 Jan 2011 15:07:07 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
+ if (dev_priv-is_vga) {
+ /* If we have 1 VGA cards with a single output,
+ * then disable the radeon VGA resources.
+ */
Why does this say 'radeon'?
--
On Mon, 28 Feb 2011 03:54:24 -0800 (PST), SD sd.dom...@yahoo.com wrote:
(II) intel(0): using SSC reference clock of 96 MHz
That's the spread-spectrum clock reference value; it forms the basis
From which the actual dot clock is computed using a PLL. It is *not* the
actual dot clock.
[
On Fri, 18 Mar 2011 08:02:03 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
... as wait_for_vblank (and friends) will do a flush of the MMIO writes
anyway.
This one seems reasonable.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgppxraae0dbT.pgp
On Fri, 18 Mar 2011 08:02:04 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
If the pipe or plane is already enabled, then we do not need to enable
it again and can skip the delay.
This should mention that you're also skipping the operation on disable.
Otherwise,
Reviewed-by: Keith
This comment is misleading -- the patch replaces a call to
intel_wait_for_vblank with a call to intel_flush_display_plane.
From my reading of the docs, enable requires two actions:
1) DSPACNTR with enable going from 0-1
2) wait for vblank
At disable, three actions are required:
1) DSPACNTR
On Fri, 18 Mar 2011 08:02:08 +, Chris Wilson ch...@chris-wilson.co.uk
wrote:
As we may release the last reference, we need to store the device in a
local variable in order to unlock afterwards.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpHcqpgV3keH.pgp
(mask (mask - 1)) == 0
is easier to reason about.
But, your fix is also correct as it finds the lowest bit set in 'mask'
and checks to see if that is the same as mask.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpK3403Fm1hC.pgp
Description: PGP signature
Might be nice to have the patch message mention that the bulk of this
patch is simply renaming and moving i915_gem_execbuffer_sync_rings. In
fact, doing this in two patches would make the actual change a whole lot
easier to find.
--
keith.pack...@intel.com
pgpogFDNCbIgt.pgp
Description: PGP
On Wed, 23 Mar 2011 10:21:07 +0800, Zhenyu Wang zhen...@linux.intel.com wrote:
DSPARB is reserved on G33 and not available on Gen6.
Does this fix a reported problem? Or just spec compliance?
--
keith.pack...@intel.com
pgpSsTjeknBqr.pgp
Description: PGP signature
On Thu, 24 Mar 2011 02:02:56 +0100, Julien Cristau jcris...@debian.org wrote:
Hi Keith,
a couple suggestions below from a quick look over these patches.
Thanks for your review!
static void
intel_vblank_handler(int fd, unsigned int frame, unsigned int tv_sec,
-
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpS0hlmwj2Q7.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, 24 Mar 2011 19:31:03 +0100, Julien Cristau jcris...@debian.org wrote:
This will cause a double free as the blit_fallback path does it too.
Argh! So we need to check before we reference the buffers and set
swap_info to NULL. This code is too twisty...
@@ -955,11 +960,16 @@
On Fri, 25 Mar 2011 00:57:10 +0100, Julien Cristau jcris...@debian.org wrote:
With that change,
Reviewed-by: Julien Cristau jcris...@debian.org
Thanks for catching my bugs before they caused any damage...
Pushed.
ec133ab..7ccbec8 master - master
--
keith.pack...@intel.com
On Wed, 30 Mar 2011 17:59:51 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
I'm not even sure we need the first posting read. Maybe it should be a
wait_for(I915_READ(GMBUS1 + reg_offset) GMBUS_SW_CLR_INT, 100)
to be clearer that we are simply giving the hardware the chance to assert
On Mon, 4 Apr 2011 07:26:44 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Following the fix to reset the GMBUS controller after a NAK, we finally
utilize the 0xa0 probe for a CRT connection. And discover that it is
useless as it simply detects the presence of the controller and not the
On Mon, 4 Apr 2011 07:26:45 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Rather than proceed on to the next test, return the result from
detecting a connection but to a digital panel and include some debug
output as to why.
I'm worried that this will falsely reject some monitors with
On Tue, 5 Apr 2011 10:19:16 +1000, Dave Airlie airl...@gmail.com wrote:
On Tue, Apr 5, 2011 at 2:26 AM, Keith Packard kei...@keithp.com wrote:
On Mon, 04 Apr 2011 16:29:55 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Yes. I'm saying that that the controller accepts a write to port
On Mon, 4 Apr 2011 07:26:44 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Following the fix to reset the GMBUS controller after a NAK, we finally
utilize the 0xa0 probe for a CRT connection. And discover that it is
useless as it simply detects the presence of the controller and not the
On Tue, 5 Apr 2011 10:24:15 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Rather than proceed on and return false by default, return the result
from detecting a connection but to a digital panel and include some
debug output as to why.
This comment does not match the patch anymore;
On Tue, 5 Apr 2011 10:24:18 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Toggle the Software Clear Interrupt bit which resets the controller to
clear any prior BUS_ERROR condition before we begin to use the
controller in earnest.
We do this in two places now, do we want to share the
On Tue, 05 Apr 2011 22:12:19 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Indeed, I started by setting them to zero in the caller. Decided that
there was some precedent to use the guard_size as the minimum value for
unused planes (and so perhaps the unused planes on the unused pipes)
On Tue, 5 Apr 2011 23:00:46 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
This looks like it fixes two bugs:
1) What if there is an error recorded before we start and so we
immediately service an IIR/EIR upon intalling the IRQ. Did we generate
that error during initialisation or was
On Wed, 06 Apr 2011 09:02:22 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Looks like we can now indeed merge g4x_compute_wm0 and ironlake_compute_wm0
and ignore the off-values for gen5+.
They do seem surprisingly similar at this point...
So fix the use of uninitialised values for
paths) instead.
Note that intel_sanitize_modesetting does not do anything on PCH
hardware yet. Otherwise, this looks like a reasonable plan.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpiMvU9734pI.pgp
Description: PGP signature
On Tue, 12 Apr 2011 18:31:51 -0700, Ben Widawsky b...@bwidawsk.net wrote:
I think we have no other option since the first thing that
i915_driver_irq_handler() does is read IIR, which according to the limited
knowledge I have requires forcewake.
I think the eventual plan will be to figure out
On Thu, 14 Apr 2011 10:03:35 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
... to clarify just how we use it inside the driver. We still need to
translate through agp_type for interface into the fake AGP driver.
agp_type has some really confusing semantics...
- obj-agp_type =
On Tue, 19 Apr 2011 21:32:02 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
We need to ensure that we feed valid memory into the display plane
attached to the pipe when switching the pipe on. Otherwise, the display
engine may read through an invalid PTE and so throw an PGTBL_ER
On Wed, 20 Apr 2011 16:42:08 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Given that the hardware may be left in a random condition by the BIOS,
it is conceivable that we then attempt to clear the DP_PIPEB_SELECT bit
without us ever enabling/attaching the DP encoder to a pipe. Thus
On Wed, 20 Apr 2011 10:22:17 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
+
+ if (!drm_crtc_helper_set_mode(crtc, mode, 0, 0, crtc-fb)) {
+ DRM_DEBUG_KMS(failed to set mode on load-detect
pipe\n);
+ return false;
+ }
them inside the common encoder structure.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpIyuZ6gZHYI.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org
On Wed, 20 Apr 2011 10:22:20 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Keith Packard kei...@keithp.com
(this might be separately tested to see if it might fix some TV load
detection issues?)
--
keith.pack
On Wed, 20 Apr 2011 20:38:54 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Wed, 20 Apr 2011 11:23:01 -0700, Keith Packard kei...@keithp.com wrote:
On Wed, 20 Apr 2011 10:22:20 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Signed-off-by: Chris Wilson ch...@chris
On Wed, 20 Apr 2011 19:55:10 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
I'll spin up a patch for a temporary buffer and see what you think.
Ok. I'd love to be able to use that code path all of the time, but I
don't like the thought of the cost of a temporary allocation every time
you
On Thu, 21 Apr 2011 22:18:15 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Whilst this may appear to be a big batch, it is actually only a few bug
fixes from the last couple of weeks broken down into small steps.
Do you think any of these are needed in .39?
--
keith.pack...@intel.com
On Fri, 22 Apr 2011 22:22:28 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
fp = FP0(pipe);
else
fp = FP1(pipe);
+ fp = I915_READ(fp);
Please use different variables for the offset vs the value...
--
keith.pack...@intel.com
pgpaGbAUtaJf4.pgp
On Tue, 26 Apr 2011 18:12:52 +0800, Feng, Boqun boqun.f...@intel.com wrote:
Signed-off-by: Feng, Boqun boqun.f...@intel.com
Please add a description here of what the bug was and how this fixes it.
--
keith.pack...@intel.com
pgph19eyUhT0a.pgp
Description: PGP signature
On Tue, 26 Apr 2011 16:38:45 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
We can treat PantherPoint as CougarPoint as far as display goes.
I'll note in passing that pch_type is never set to PCH_IBX explicitly,
which only works because PCH_IBX is zero.
--
keith.pack...@intel.com
On Tue, 26 Apr 2011 16:38:49 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
A0 stepping chips need to use manual training, but the bits have all
moved. So fix things up so we can at least train FDI for VGA links.
This patch should be before the auto-train patch so that we don't have
a
On Wed, 27 Apr 2011 15:41:18 +0800, Feng, Boqun boqun.f...@intel.com wrote:
Remove ring_put_irq/ring_get_irq:drivers/gpu/drm/i915/intel_ringbuffer.c
, they are only used by bsd_ring_put_irq/bsd_ring_get_irq.
Expand the code in bsd_ring_put_irq/bsd_ring_get_irq.
Why is this change useful?
--
On Thu, 28 Apr 2011 10:06:51 +0800, Feng, Boqun boqun.f...@intel.com wrote:
I have discussed this with Chris in my earlier patch.
This change is a clean-up, since ring_put_irq and ring_get_irq are only used
by
bsd_ring_put_irq and bsd_ring_get_irq.
And once this change is made, it is
On Thu, 28 Apr 2011 15:12:47 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Rather than branching in ironlake_pch_enable, add a new train_fdi
function to the display function pointer struct and use it instead.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Reviewed-by: Keith
On Thu, 28 Apr 2011 15:12:48 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Set the IRQ handling functions in driver load so they'll just be used
directly, rather than branching over most of the code in the chipset
functions.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack
On Thu, 28 Apr 2011 15:12:49 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
This makes the Ironlake+ code trivial and generally simplifies things.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
On Thu, 28 Apr 2011 15:12:50 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Note: IS_GEN* are for render related checks. Display and other checks
should use IS_MOBILE, IS_$CHIPSET or test for specific features.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Reviewed-by: Keith
On Thu, 28 Apr 2011 15:12:51 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
I don't see a patch in this series that sets this value from the PCI
ids. Is that still pending?
--
keith.pack...@intel.com
pgpfAzxA46ANr.pgp
Description: PGP signature
...@virtuousgeek.org
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgp0rmuIHa20e.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, 28 Apr 2011 15:12:53 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Treat it like Ironlake and Sandy Bridge.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Should use gen = 5?
--
keith.pack...@intel.com
pgptprXAz4FhS.pgp
Description: PGP signature
On Thu, 28 Apr 2011 15:12:54 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
+ if (IS_GEN6(dev)) {
+ temp = ~FDI_LINK_TRAIN_NONE;
+ temp |= FDI_LINK_TRAIN_NONE | FDI_TX_ENHANCE_FRAME_ENABLE;
+ } else if (IS_IVYBRIDGE(dev)) {
+ temp =
On Thu, 28 Apr 2011 15:12:55 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Ivy Bridge supports auto-training on the CPU side, so add a separate
training function to handle it.
Let's leave this out of the kernel until we have hardware that actually
uses it.
--
keith.pack...@intel.com
On Thu, 28 Apr 2011 15:12:56 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
- if (IS_GEN6(dev)) {
+ if (IS_GEN6(dev) || IS_IVYBRIDGE(dev)) {
IS_GEN6 for SNB and IS_IVYBRIDGE for IVB? More consistency, please.
--
keith.pack...@intel.com
pgpPesA8nYOAV.pgp
On Thu, 28 Apr 2011 15:12:57 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
- if (IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev)) {
+ if (IS_G4X(dev) || IS_GEN5(dev) || IS_GEN6(dev) || IS_IVYBRIDGE(dev)) {
IS_G4X || gen = 5 ?
Otherwise, this looks good (seems like it's just bit
On Thu, 28 Apr 2011 15:12:59 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Treat it like Sandy Bridge in a few places.
gen = 6?
--
keith.pack...@intel.com
pgpqFHB2q8tev.pgp
Description: PGP signature
___
Intel-gfx mailing list
On Thu, 28 Apr 2011 15:13:00 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Use Sandy Bridge paths in a few places.
gen = 6 ?
--
keith.pack...@intel.com
pgp6Bmd9mjsyL.pgp
Description: PGP signature
___
Intel-gfx mailing list
On Thu, 28 Apr 2011 15:13:03 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
There are several variants, set feature bits appropriately for both
mobile and desktop parts.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack
On Thu, 28 Apr 2011 15:13:04 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
This is a little less confusing than relying on the implicit zeroing of
the dev_priv.
Thanks.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpFuOeuyyxOq.pgp
Description: PGP
On Sun, 01 May 2011 17:26:11 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Perhaps if you do the s/IS_GEN6/IS_SNADYBRIDGE/ fixes first it will become
much clearer? :)
The only question is one of regressions; getting the cleanups tested in
isolation from the IVB patches. That seems
On Thu, 14 Apr 2011 10:03:38 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
+ obj-base.write_domain = ~I915_GEM_DOMAIN_GTT;
+ obj-base.write_domain = ~I915_GEM_DOMAIN_GTT;
I'll bet you want to modify the read_domain as well.
--
keith.pack...@intel.com
pgp2NzoJuMYNT.pgp
On Thu, 14 Apr 2011 10:03:41 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5360,7 +5360,7 @@ static int intel_crtc_cursor_set(struct drm_crtc *crtc,
goto fail_locked;
On Thu, 14 Apr 2011 10:03:45 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
The docs have a dire warning not to attempt to access snooped (the old
style of cache sharing on pre-SandyBridge chipsets) pages through the GTT.
Prevent userspace from doing so by sending them a SIGBUS if they
On Thu, 14 Apr 2011 10:03:46 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Older chipsets do not support snooping (i.e. cache sharing between the
CPU and GPU) on tiled surfaces. So prevent userspace from being silly
should we one day expose the ability to change cache levels from
On Wed, 04 May 2011 19:28:35 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
to simply mark the device as uninterruptible for the duration.
The code now does the latter.
I'm good with that plan during modesetting, the question is whether the
new users of this function should allow for
On Thu, 21 Apr 2011 22:18:23 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
As we failed to update the dpms_mode after modeset, where it is presumed
to have been changed to DRM_MODE_DPMS_ON by the upper layers the dpms state
on the crtc became inconsistent with its actual active state.
On Tue, 5 Apr 2011 23:00:46 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Something to think about...
Missing SoB here...
--
keith.pack...@intel.com
pgpnCoAAssejC.pgp
Description: PGP signature
___
Intel-gfx mailing list
Angela Gill (Visual Computing Group) and I (Keith Packard, Open Source
Technology Center) are pleased to announce that HD Graphics Programmer's
Reference Manuals for 2011 Intel Core Processor Family (Sandy Bridge)
are now available at:
http://intellinuxgraphics.org/documentation.html
On Tue, 19 Apr 2011 12:12:35 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
ILK+ provides this feature in the transcoder and pipe configuration
instead.
This doesn't seem to add in a new implementation of this feature for
ILK, just stops using the pre-ILK version on ILK. Please explain
On Tue, 19 Apr 2011 12:12:38 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Figuring out which pipe bpp to use is a bit painful. It depends on both
the encoder and display configuration attached to a pipe. For instance,
to drive a 24bpp framebuffer out to an 18bpp panel, we need to use
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_tv.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
index 6b22c1d..876064c 100644
--- a/drivers/gpu/drm/i915/intel_tv.c
Do not use this bit to indicate that load detection has completed,
instead just wait for vblank, at which point the load registers will
have been updated.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_tv.c | 40 +++---
1 files
On Thu, 12 May 2011 22:17:10 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
+ pages = kmalloc(n*sizeof(struct page *),
+ GFP_KERNEL | __GFP_NORETRY | __GFP_NOWARN);
+ if (pages == NULL) {
+ pages = drm_malloc_ab(n, sizeof(struct page *));
+
On Thu, 12 May 2011 22:17:11 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Convert our open coded offset_in_page() to the common macro.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpjf0bivf3pS.pgp
On Thu, 12 May 2011 22:17:17 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Toggle the Software Clear Interrupt bit which resets the controller to
clear any prior BUS_ERROR condition before we begin to use the
controller in earnest.
Looks reasonable, except for the bad register offsets
.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgp0mLAXjByJB.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, 12 May 2011 22:17:19 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
- return -ENOSPC;
+ return -EDEADLK;
Would be nice to have the kernel print out a debugging message at this
point -- the only way to hit this is from a bug in user or kernel code.
--
1 - 100 of 603 matches
Mail list logo
