On Thu, 12 May 2011 22:17:16 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
- I915_WRITE(GMBUS0 + reg_offset, 0);
+ intel_i2c_reset(dev_priv-dev);
This looks like an unrelated change. Please split this out.
--
keith.pack...@intel.com
pgp2uVPK5zOxO.pgp
Description: PGP
that with compares. Meh.
Nacked-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpL0VmoE27oP.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:23 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Can you justify this change with performance data?
--
keith.pack...@intel.com
pgpwnyNWMT1aq.pgp
Description: PGP signature
On Thu, 12 May 2011 22:17:18 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
As we cannot wait upon an object to be released by the GPU once we have
disabled pagefaults, process any pending retirements first in the hope
that we move any potential relocations off the active list.
This
On Thu, 12 May 2011 22:17:24 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Make the audio property creation routine common and share the single
property between the connectors.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Keith Packard kei...@keithp.com
On Thu, 12 May 2011 22:17:20 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
From: Daniel Vetter daniel.vet...@ffwll.ch
A tile on gen2 has a size of 2kb, stride of 128 bytes and 16 rows.
Userspace was broken and assumed 8 rows. Chris Wilson noted that the
kernel unfortunately can't
On Thu, 12 May 2011 22:17:21 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Superseded by the tracking the render generation in the chipset
capabiltiies struct.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Yes please.
Reviewed-by: Keith Packard kei...@keithp.com
On Thu, 12 May 2011 22:17:14 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
The computation of the first-level watermarks for g4x and gen5+ are
based on the same algorithm, so we can refactor those code paths to
use a single function.
g4x_compute_wm0 takes a plane. ironlake_compute_wm0
out the
actual fence register contents (perhaps in addition to what the fence
management code thinks they should be...)
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpzXaQS0H4Q4.pgp
Description: PGP signature
___
Intel-gfx
On Fri, 13 May 2011 10:19:52 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Thu, 12 May 2011 17:34:49 -0700, Keith Packard kei...@keithp.com wrote:
On Thu, 12 May 2011 22:17:14 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
The computation of the first-level watermarks
On Fri, 13 May 2011 10:32:25 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
It has been booting daily on several machines for a month. I agree it
wouldn't have worked, but the since we automatically fallback to GPIO
should it go south, the failures didn't stop the external monitors from
On Tue, 3 May 2011 12:42:24 +0800, Feng, Boqun boqun.f...@intel.com wrote:
On g4x, user interrupt in BSD ring is missed.
g4x and ironlake share the same bsd_ring, but their interrupt control
interfaces are different. On g4x i915_enable_irq and i915_disable_irq
are used to enable/disable
On Sun, 15 May 2011 09:00:51 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
We're not performing the same trick as drm_malloc_ab() here though, since
this is only used for a temporary allocation we try to consume any
high-order pages, rather than building an array of order-0 pages,
On Sun, 15 May 2011 22:49:02 +0200, Daniel Vetter dan...@ffwll.ch wrote:
I actually like this: I saves one needless indirection when reading
codepaths and trying to find out what code is run for a given pci id.
Also, these two bits seem to be the only ones that are used in only _one_
device
On Fri, 13 May 2011 12:14:54 -0400, Andy Lutomirski l...@mit.edu wrote:
-unsigned int i915_semaphores = 1;
+unsigned int i915_semaphores = 0;
module_param_named(semaphores, i915_semaphores, int, 0600);
Acked-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgphrzmB2DHbN.pgp
On Mon, 16 May 2011 13:27:27 +0300, Konstantin Belousov kostik...@gmail.com
wrote:
It seems that the patch removes that last use for ring_get_irq() and
ring_put_irq() ? Are the helpers still needed ?
You're right -- these helpers are no longer used and are removed in the
second patch in this
On Mon, 16 May 2011 16:02:39 +0800, Feng, Boqun boqun.f...@intel.com wrote:
On g4x, user interrupt in BSD ring is missed.
This is because though g4x and ironlake share the same bsd_ring,
their interrupt control interfaces have _two_ differences.
Merged.
--
keith.pack...@intel.com
On Thu, 28 Apr 2011 17:15:33 +0800, Feng, Boqun boqun.f...@intel.com wrote:
This patch depends on patch drm/i915: fix user irq miss in BSD ring on
g4x.
Once the previous patch apply, ring_get_irq/ring_put_irq become unused.
So simply remove them.
I've merged this along with the updated
On Tue, 17 May 2011 00:53:38 +0200, Knut Petersen knut_peter...@t-online.de
wrote:
Nice to know that .39 will have the feature to lock screen and all input
devices
on exotic hardware like i915GM.
The alternative is to try to include a patch which has seen limited
testing and insufficient
On Tue, 17 May 2011 12:34:41 +0300 (EEST), Gabriel Schulhof n...@go-nix.ca
wrote:
Is there any way to configure the intel driver to allow for multiple X
screens?
No, we removed that capability several years ago; it was an ugly hack.
--
keith.pack...@intel.com
pgpdLC44xVFpc.pgp
On Wed, 18 May 2011 10:22:27 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
The work queue is only used on gen6, but gen6 and ilk share an irq
handler. I could make the work queue init conditional on gen6 though,
if that's what you're thinking.
Probably a good idea, mostly as
On Fri, 13 May 2011 12:14:54 -0400, Andy Lutomirski l...@mit.edu wrote:
My Q67 / i7-2600 box has rev09 Sandy Bridge graphics. It hangs
instantly when GNOME loads and it hangs so hard the reset button
doesn't work. Setting i915.semaphore=0 fixes it.
Can you describe precisely what hardware
On Tue, 24 May 2011 13:10:27 -0400, Andrew Lutomirski l...@mit.edu wrote:
I'm getting hangs on my X220 Core i7 laptop as well with 2.6.39 and
i915.semaphores=1. They're not as reliable -- sometimes the system
hangs on log in, sometimes after a few seconds, and sometimes it
doesn't hang.
On Wed, 1 Jun 2011 00:02:53 -0700, Eric Anholt e...@anholt.net wrote:
1) Clip against each box of the clip
2) Reject per box
3) draw.
I didn't try to figure out the old code, but the new code looks correct
to me.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
On Fri, 13 May 2011 08:00:40 -0700, Keith Packard kei...@keithp.com wrote:
Non-text part: multipart/signed
On Fri, 13 May 2011 10:28:34 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
And how about something like:
#define I915_GMBUS_WRITE(reg, val) \
I915_WRITE(intel_gmbus_reg
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.
I don't have a new patch with corrected register
On Thu, 12 May 2011 22:17:22 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
... as they only had a single PCI-ID each, and so using the pci-id is
easier than using a capability bit.
This patch no longer applies; do you want to update it?
--
keith.pack...@intel.com
pgpo9QUs6APPl.pgp
On Sat, 04 Jun 2011 00:09:29 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
I need to address the broader concerns raised by Jean Delvare first.
Once I have our i2c adapter to his liking, I can then get the code to
yours.
Sounds good.
--
keith.pack...@intel.com
pgpKkPpmnhIG5.pgp
On Sat, 4 Jun 2011 09:55:43 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
In order to correctly account for reserving space in the GTT and fences
for a batch buffer, we need to independently track whether the fence is
pinned due to a fenced GPU access in the batch from from whether the
On Sat, 04 Jun 2011 19:31:27 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Yes, we can't apply the EDEADLK patch until we fix the accounting.
Ok, I'll rearrange drm-intel-next then so that the EDEADLK patch occurs
after this fix.
Speedups on q35 (or equally because I finally noticed
I'm trying to formalize the process for merging code into the drm/i915
driver. Here's a first draft, please send along your comments.
-keith
Right now, I'm merging patches destined for the 3.0 release
in a kernel.org tree:
git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git
On Sun, 05 Jun 2011 16:23:43 +1000, Dave Airlie airl...@redhat.com wrote:
So when Linus is releasing rc4/5 you should really be cutting down stuff
going into your -next, and getting the tree ready for me to take. We can
probably add your tree direct to the -next git list as well so that we
On Mon, 6 Jun 2011 15:18:44 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
case I915_PARAM_HAS_RELAXED_FENCING:
- value = 1;
+ value = 2;
This looks like a change in ABI to me. I think this means you want a new
ioctl so that applications using the existing
On Mon, 06 Jun 2011 18:50:16 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Hah. Anyway it is actually irrelevant as it turns out, the kernel is broken
with any per-surface tiling on gen2/gen3.
Right, seems like we need to signal user space that tiling works now,
which should involve a
On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Can you keep drm-intel-next fairly up to date with respect to the fixes
branch? I.e. keep it a superset of drm-intel-fixes for the most part?
Yes, I wanted to do that now, but -fixes is not a fast-forward from
On Tue, 7 Jun 2011 15:54:39 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
According to BSpec volume 1c.4 section 3.2.9, Display (Plane) Select is
now at bits 21:19 instead of 21:20.
Signed-off-by: Kenneth Graunke kenn...@whitecape.org
I will note that the docs have an obvious bug --
On Tue, 7 Jun 2011 15:54:40 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
Ivybridge has BLT and BSD rings, so there's no need to check.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpdirl6C8HQ7.pgp
Description: PGP signature
On Tue, 7 Jun 2011 15:54:41 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
According to the hardware documentation, GDRST is exactly the same as on
Sandybridge. So simply enable the existing code.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
I'll be away on vacation starting today until the 20th. Please work with
either Eric Anholt or Dave Airlie if there are critical issues in the
drm/i915 kernel driver.
--
keith.pack...@intel.com
pgp1Z334Rigm6.pgp
Description: PGP signature
___
On Sun, 19 Jun 2011 22:49:36 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
The patch closes a race condition. The essence of your complaint is that
the kernel is not as fast as we need it to be, and that the initial upload
to any object is slower than expected. I presume you also have a
On Wed, 22 Jun 2011 11:13:09 +0800, Zou, Nanhai nanhai@intel.com wrote:
If I upload input buffer with movnti or movntdq (bypass cache) +
sfence(clear write combine buffer) in the end, clflush should
not be needed.
Alas, neither of these will flush existing cached data,
On Wed, 22 Jun 2011 12:29:21 +0800, Zou, Nanhai nanhai@intel.com wrote:
As I understand,
with movnti + sfence, data should be surly reach memory. Cache should be
coherent at this case.
I wouldn't mind seeing additional experiments in this area, but when
Eric and I tried this a couple
On Wed, 22 Jun 2011 08:29:24 +0200, Daniel Vetter dan...@ffwll.ch wrote:
The important thing is that you may never use the cpu mappings with
these functions (for objects of similar size). Because libdrm reuses
bos without checking their domain, you'll get tons of unnecessary
clflush even on
On Wed, 22 Jun 2011 18:04:46 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk
I've added this to drm-intel-fixes
--
keith.pack...@intel.com
pgpIrsnHzhStD.pgp
Description: PGP signature
___
On Wed, 11 May 2011 10:48:04 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
These bits are reserved on ILK+ (ILK+ provides this feature in the
transcoder and pipe configuration instead, which we already set).
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Reviewed-by: Keith
On Wed, 11 May 2011 10:48:05 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
This prevents us from setting reserved or incorrect bits on
CougarPoint.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpjbEwTRahrQ.pgp
Description: PGP signature
On Tue, 28 Jun 2011 13:00:41 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
This lets us make the various IRQ functions static and helps avoid
problems like the one fixed in drm/i915: Use chipset-specific irq
installers where one of the exported functions was called rather than
the
On Tue, 28 Jun 2011 14:00:02 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Yeah, definitely looks that way, but I haven't tested it.
It would require UMS code for IRL or SNB for it to break...
--
keith.pack...@intel.com
pgpZX2bnVYrhv.pgp
Description: PGP signature
On Wed, 29 Jun 2011 10:26:42 -0700, Ben Widawsky b...@bwidawsk.net wrote:
Provide a parameter to disable hanghcheck. This is useful mostly for
developers trying to debug known problems, and probably should not be
touched by normal users.
I've merged this to drm-intel-next
--
On Fri, 01 Jul 2011 13:01:50 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
Keith, could this go into -fixes?
Yes. Would Chris and/or Jesse be willing to review the remaining
GEN6-specific code and make sure the appropriate bits are also turned on
for GEN7?
--
keith.pack...@intel.com
(1):
drm/i915: Don't call describe_obj on NULL pointers
Chris Wilson (1):
drm/i915/overlay: Fix unpinning along init error paths
Jesse Barnes (2):
drm/i915: move IRQ function table init to i915_irq.c
drm/i915: apply HWSTAM writes to Ivy Bridge as well
Keith Packard (1
handle configuration changes at runtime.
This series fixes a ton of random hot-plug weirdness on my X220.
Tested-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpce8aBej1kF.pgp
Description: PGP signature
___
Intel-gfx mailing list
On Fri, 1 Jul 2011 15:22:51 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Especially after a hotplug or power status change, the sink may not
reply immediately to a link status query. So retry 3 times per the spec
to really make sure nothing is there.
There's no 'false' return path
On Fri, 1 Jul 2011 15:22:52 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Makes it easier to search for DP related constants.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpjKA9bEBDue.pgp
Description
On Fri, 1 Jul 2011 15:22:53 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
When a hotplug event is received, we need to check the receiver cap bits
in case they've changed (as they might with a hub or chain config).
Please create a common function to read the dpcd values; this code
On Fri, 1 Jul 2011 15:22:54 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
If -detect is called too soon after a hot plug event, the sink may not
be ready yet. So try up to 3 times with 1ms sleeps in between tries to
get the data (spec dictates that receivers must be ready to respond
On Fri, 1 Jul 2011 15:22:55 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
A regular mode set can be considered a DPMS on state as far as
receiver detection goes.
There are three patches affecting the tracking of the DP receiver
connected status. Please merge them into a single patch.
On Fri, 1 Jul 2011 15:22:56 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
If the receiver goes away, drop any associated CRTC. This will force a
full mode set on any subsequent setcrtc call, which is what we need if
the receiver is gone and the link is down.
This doesn't look like a
On Fri, 1 Jul 2011 15:22:57 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Make its usage a little more clear.
See previous comment -- this patch should be merged with the other
two receiver configured patches.
--
keith.pack...@intel.com
pgpGlQY3cXtKF.pgp
Description: PGP signature
On Fri, 1 Jul 2011 16:59:48 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
That depends on what behavior we want. With the previous fixes, if you
unplug, we'll get a hotplug event, fail to detect a link, and tear down
the receiver. With the old code you'd get bad behavior unless you
On Mon, 4 Jul 2011 13:35:57 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
This fixes the missing rendering oft triggered in the past, but easily
reproduced by using mutter with sna, for which the current workaround is
to disable fbc entirely.
This looks good; I'd like to see a few
On Wed, 6 Jul 2011 15:14:52 -0700, Ben Widawsky b...@bwidawsk.net wrote:
-static int i915_modeset = -1;
+static int i915_modeset __read_mostly = -1;
What effect does this have? Performance? Code size? More warnings?
--
keith.pack...@intel.com
pgpVFVofyIu2e.pgp
Description: PGP signature
On Wed, 6 Jul 2011 16:16:01 -0700, Ben Widawsky b...@bwidawsk.net wrote:
Non-text part: multipart/signed
I've seen no regressions on Nexuiz.
'this doesn't seem to hurt any' is hardly a strong recommendation...
--
keith.pack...@intel.com
pgp3gwbqzSTIA.pgp
Description: PGP signature
On Thu, 7 Jul 2011 12:48:05 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
FBC is currently disabled upstream due a few conflicting requirements
and questionable benefit. It is also buggy...
https://bugs.freedesktop.org/show_bug.cgi?id=33487 is the current open
SNB bug where FBC
On Thu, 7 Jul 2011 11:11:00 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
+ for (i = 0; i 3; i++) {
+ ret = intel_dp_aux_native_read(intel_dp,
+0x000, intel_dp-dpcd,
+sizeof
On Thu, 7 Jul 2011 21:30:19 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Upon review, all path share the same dependencies for updating the
registers and so we can benefit from sharing the code and checking
early.
yeah, looks good.
+ if (intel_fbc_enabled(dev)) {
+
Looks good to me.
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgpC8jcs9a8u1.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Thu, 7 Jul 2011 15:33:26 -0700, Kenneth Graunke kenn...@whitecape.org
wrote:
(Somehow this got lost; resending. It still applies cleanly to
-next.)
Thanks for resending; I don't know how this got dropped; clearly too
small a patch :-)
--
keith.pack...@intel.com
pgpHp4D3aSd9W.pgp
On Fri, 8 Jul 2011 12:22:38 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
- if (dev_priv-cfb_pitch == dev_priv-cfb_pitch / 64 - 1
That one was gonna be hard to satisfy...
--
keith.pack...@intel.com
pgpEpHLb66MY3.pgp
Description: PGP signature
On Fri, 08 Jul 2011 20:43:47 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Bumping to 250ms sufficiently delays the task to miss the race, but we
can not foretell just how long any given crtc modeset will take. So what
we need is to take the mode_config.lock in order to prevent
On Sat, 9 Jul 2011 09:38:51 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
+ /* We have to disable faulting here in case the user address
+ * is really a GTT mapping and so we can not enter
+ * i915_gem_fault() whilst already holding struct_mutex.
On Sat, 09 Jul 2011 21:50:26 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
I think would do, find_vma() is not necessary cheap though, and there are a
couple of optimisations that we haven't done for pwrite/pread yet to speed
up the transition to the slow path.
Yeah, find_vma is a rb
On Sun, 10 Jul 2011 11:45:29 -0700, Eric Anholt e...@anholt.net wrote:
That means that I can't give users of GL pointers to GTT mappings for
the buffer mapping API, because then I'd have to check in userland
whether the pointer they give me for other API entrypoints is to a known
GTT mapping
On Mon, 11 Jul 2011 17:51:08 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
no-prefaulting:
pread: shmem fast: 1273764/3395, slow: 0/0
pwrite: sheme fast: 51163148/14554, slow: 23552/9
pwrite: gtt fast: 32744702068/12658489, slow: 29376/10
Looks like it won't matter that much, at
receiver capability bits on hotplug
drm/i915/dp: try to read receiver capabilities 3 times when detecting
drm/i915/dp: remove DPMS mode tracking from DP
drm/i915/dp: consolidate AUX retry code
drm/i915/dp: manage sink power state if possible
Keith Packard (2):
drm/i915
On Tue, 12 Jul 2011 17:51:36 -0400, Matthew Garrett m...@redhat.com wrote:
- keycode = KEY_SWITCHVIDEOMODE;
+ if (!acpi_notifier_call_chain(device, event, 0))
+ keycode = KEY_SWITCHVIDEOMODE;
Right, acpi_notify_call_chain returns -EINVAL when the
DP_RECEIVE_PORT_1_STATUS(1 1)
#define DP_ADJUST_REQUEST_LANE0_10x206
#define DP_ADJUST_REQUEST_LANE2_30x207
Please make a separate patch for whitespace cleanups...
Otherwise, these changes all match the DP 1.1a spec that I compared them
with.
Reviewed-by: Keith
Patches 2-7:
Reviewed-by: Keith Packard kei...@keithp.com
--
keith.pack...@intel.com
pgp8M0sdGYuWA.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Sat, 04 Jun 2011 00:09:29 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
I need to address the broader concerns raised by Jean Delvare first.
Once I have our i2c adapter to his liking, I can then get the code to
yours.
Are you still planning on cleaning up the i2c stuff at some
On Wed, 13 Jul 2011 19:22:14 +0200, Wolfram Sang w.s...@pengutronix.de wrote:
Is this one intentionally not in or did it slip through?
I thought I had replied to that -- it doesn't apply to either -fixes or
-next at this point. I can try to fix it, but I'd prefer it if you'd
figure out how
On Wed, 6 Jul 2011 15:14:52 -0700, Ben Widawsky b...@bwidawsk.net wrote:
Signed-off-by: Ben Widawsky b...@bwidawsk.net
This patch series doesn't apply to -next anymore; care to clean it up so
I can merge it in?
(too many -fixes applied for 3.0, I fear)
--
keith.pack...@intel.com
invasive change.
Signed-off-by: Keith Packard kei...@keithp.com
Tested-by: Robse rob...@live.de
---
drivers/gpu/drm/i915/i915_drv.h |1 +
drivers/gpu/drm/i915/intel_display.c | 15 ++-
2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915
drm/i915: use pipe bpp in DP link bandwidth calculations
drm/i915: use pipe bpp when setting HDMI bpc
drm: bpp and depth changes require full mode sets
drm/i915: check for supported depth at fb init time
drm/i915: use pipe bpp in DP link bandwidth calculation
Keith
On Wed, 13 Jul 2011 16:32:32 -0400, Adam Jackson a...@redhat.com wrote:
+ if (width 1)
+ width++;
+ if (height 1)
+ height++;
You'll want to stick a comment in here
On Sat, 9 Jul 2011 09:31:25 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
uint32_t
-i915_gem_get_unfenced_gtt_alignment(struct drm_i915_gem_object *obj)
+i915_gem_get_unfenced_gtt_alignment(struct drm_i915_gem_object *obj,
+ int tiling_mode)
...
+
On Mon, 18 Jul 2011 09:17:16 -0700, Keith Packard kei...@keithp.com wrote:
Non-text part: multipart/signed
On Sat, 9 Jul 2011 09:31:25 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
uint32_t
-i915_gem_get_unfenced_gtt_alignment(struct drm_i915_gem_object *obj
On Tue, 19 Jul 2011 00:48:23 +0200, Paul Menzel
paulepan...@users.sourceforge.net wrote:
Non-text part: multipart/mixed
Non-text part: multipart/signed
Am Montag, den 18.07.2011, 13:31 -0700 schrieb Keith Packard:
I have not been able to test this patch but if it fixes the issue it
should
On Wed, 20 Jul 2011 01:03:17 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
This doesn't prevent us returning an error should the wait-rendering abort
due to a GPU hang occurring in the middle of the wait.
Yeah, should probably check the return value and ignore the error instead.
Failing to pin a scanout buffer will most likely lead to a black
screen, so if the GPU is wedged, then just let the pin happen and hope
that things work out OK.
v2: Just ignore any error from i915_gem_object_wait_rendering, as
suggested by Chris Wilson
Signed-off-by: Keith Packard kei
/linux/kernel/git/keithp/linux-2.6.git
drm-intel-fixes
Chris Wilson (1):
drm/i915: Fix unfenced alignment on pre-G33 hardware
Keith Packard (1):
drm/i915: Add quirk to disable SSC on Lenovo U160 LVDS
drivers/gpu/drm/i915/i915_drv.h|5 ++-
drivers/gpu/drm/i915/i915_gem.c
i915_init_phys_hws.
I suspect we could remove the memset from intel_init_render_ring_buffer;
it seems entirely superfluous given the memset in i915_init_phys_hws.
From 159ba1dd207fc52590ce8a3afd83f40bd2cedf46 Mon Sep 17 00:00:00 2001
From: Keith Packard kei...@keithp.com
Date: Fri, 22 Jul 2011 10:44
On Fri, 22 Jul 2011 12:54:22 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
Keith, please pull this one in for 3.1. Hardware will wedge if we try
to access the palette after pipe enable but before FDI or eDP training
completes, so we may as well just do it right before pipe enable.
On Sat, 23 Jul 2011 00:23:36 +0400, Kirill Smelkov k...@mns.spb.ru wrote:
What kind of a workaround are you talking about?
Just reverting the commit -- that makes your machine work, even if it's
wrong for other machines.
Sorry, to me it all looked like UMS is being ignored forever.
You're
On Sat, 23 Jul 2011 14:40:36 -0400, Andrew Lutomirski l...@mit.edu wrote:
I have a Q67 (DQ67SW board) attached to a Dell U2711 via DP. In
previous kernels, the DP link has worked flawlessly. I just booted
3.0-final and simultaneously enabled SNA, and now when my screen goes
to sleep I don't
On Mon, 25 Jul 2011 11:23:17 -0400, Andrew Lutomirski l...@mit.edu wrote:
A debugging patch and its output are attached.
I didn't get any attachment.
If I had to guess, though, it's a race: a hotplug event happens during
the intel_dp_dpms callback, confusing the code that's trying to train
to DRM_MODE_DPMS_ON, so the hotplug code would bail every
time. With that fixed, this patch should work for you *and* for others.
Care to give it a try?
From 59b920597999381fab70c485c161dd50590e561a Mon Sep 17 00:00:00 2001
From: Keith Packard kei...@keithp.com
Date: Mon, 25 Jul 2011 22:37:51 -0700
Subject
Eliminates an open-coded read and also gains the retry behaviour of
intel_dp_get_dpcd, which seems like a good idea.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm
A was changed, any
display port outputs on pipe B would get disabled as
intel_disable_pch_ports would ensure that the mode setting operation
could occur on pipe A without interference from other outputs
connected to that pch port
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915
If the connector is inserted or removed slowly, the hotplug line may
well change state before the data lines do. So, assume the user isn't
trying to fool us and give them 250ms to get the connector plugged or
unplugged.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915
On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes jbar...@virtuousgeek.org
wrote:
I'd like to amend my reviewed by and say the lock shouldn't be held
around the call to the drm helper function. It queues some work that
also takes the mode config lock, which will break. So you can drop it
101 - 200 of 603 matches
Mail list logo
