c: Daniel Vetter
cc: David Airlie
cc: intel-gfx@lists.freedesktop.org
cc: dri-de...@lists.freedesktop.org
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu
Daniel Vetter writes:
> Hm, I think we should just clean up wiat_req in ->atomic_destroy_state
> instead of littering cleanup code all over. But this gets the job done, so
> applied.
Thanks. It's required for the DRM patch I posted that makes moving the
cursor not block on rendering. I'm hoping
Daniel Vetter writes:
> Cc: Keith Packard
Reviewed-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
he Intel X11 back-end. The SNA back-end
> for X11 has always used execbuffer2.
All execbuffer users in the past that I'm aware of used libdrm, which
now uses the execbuffer2 ioctl for this API. That means these
applications will remain ABI compatible through this change.
Acked-by: Keith
pdate_edid_property about
potentially merging that with drm_add_edid_modes to avoid
the need for two driver calls.
Signed-off-by: Keith Packard
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/drm_connector.c | 13 ++
drivers/gpu
kernel API
* Disable CAP_UNIVERSAL_PLANES before leasing so that we don't need to
also include a plane.
* Zero out all of the ioctl structures so that any padding fields are
set correctly.
* When listing a lease, expect 3 resources -- crtc, connector and plane.
Signed-off-by: Keith Pa
g in the kernel.
v2: from Dave Airlie
* Add local definitions of new ioctls to avoid requiring latest
libdrm.
* Remove FIRST_PIXEL_OUT as that has been removed from the proposed
kernel patches.
Signed-off-by: Keith Packard
---
lib/igt_kms.c | 2 +-
lib/igt_kms.h
Both of these APIs are now in the kernel; it would be nice to have the
tests integrated into the test suite.
This includes an updated version of the kms_lease patch (v3) which
adapts to the final kernel API changes.
___
Intel-gfx mailing list
Intel-gfx@
Daniel Vetter writes:
> We still need to clean up the reference in case of failure, which
> means latest in intel_plane_destroy_state(). Also hanging onto a
> request isn't that evil really, why can't we just only clean up in the
> destroy function?
Sticking a cleanup there as well is good insur
Daniel Vetter writes:
> I spent a bit of time scratching heads and figuring out why the igts
> don't work. Probably useful to keep this work.
Acked-by: Keith Packard
> /* Do not allow sub-leases */
> - if (lessor->lessor)
> + if (lessor->lessor) {
>
Daniel Vetter writes:
> @@ -359,7 +359,8 @@ void drm_lease_revoke(struct drm_master *top)
> static int validate_lease(struct drm_device *dev,
> struct drm_file *lessor_priv,
> int object_count,
> - struct drm_mode_object **obj
Daniel Vetter writes:
> freedesktop.org has adopted a formal&enforced code of conduct:
Acked-by: Keith Packard
--
-keith
signature.asc
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.or
Manasi Navare writes:
> This patch fixes this problem by checking if the mode being pruned
> is the last mode on that connector and if so doesnt prune it.
I think you want to stop pruning when you've gotten to a single mode on
the list, not at the last mode in the list (which may well need to be
g in the kernel.
v2: from Dave Airlie
* Add local definitions of new ioctls to avoid requiring latest
libdrm.
* Remove FIRST_PIXEL_OUT as that has been removed from the proposed
kernel patches.
Signed-off-by: Keith Packard
---
lib/igt_kms.c | 2 +-
lib/igt_kms.h
Changes since last version:
* Add local definitions of new ioctls to avoid dependency on proposed
libdrm bits.
* Remove FIRST_PIXEL_OUT as that has been removed from the proposed
kernel interface
* Add tests for get_lease and list_lessees
* Fix commit message on the lease test patch
\
kms_mmio_vs_cs_flip \
diff --git a/tests/kms_lease.c b/tests/kms_lease.c
new file mode 100644
index ..49226163
--- /dev/null
+++ b/tests/kms_lease.c
@@ -0,0 +1,597 @@
+/*
+ * Copyright © 2017 Keith Packard
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy
Dhinakaran Pandiyan writes:
> drm_vblank_count() has a u32 type returning what is a 64-bit vblank
> count.
It looks like a general review of the 64-bit widening patch is needed.
* drm_crtc_accurate_vblank_count has a 32-bit return, and uses a 32-bit
temporary
* drm_wait_one_vblank uses a 32-
Dhinakaran Pandiyan writes:
> Now that drm_vblank_count() returns all bits of the vblank count, update
> drm_crtc_arm_vblank_event() so that it queues the correct sequence.
> Otherwise, this leads to prolonged waits for a vblank sequence when the
> current count is >=2^32.
The summary for this p
ped 32-bit count(when the
> value is >= 2^32) as reference, the requested sequence remains a 32-bit
> value and gets queued like that. However, the code that checks if the
> requested sequence has passed compares this against the 64-bit vblank
> count.
For patches 1-7:
Reviewed-by: Ke
Rodrigo Vivi writes:
> I didn't checked the drm one close enough yet to decide for that.
> DK or Keith? do you guys see anyone suitable for fixes?
Yeah, we should probably get 1, 3 and 7 into fixes. 2, 4, 5 and 6 add
explicit casts where the compiler would already introduce equivalent
implicit c
The server no longer supports the allocator wrapping functions.
Signed-off-by: Keith Packard
---
src/drmmode_display.c | 20 +-
src/i810_dga.c |4 +-
src/i810_dri.c | 50
src/i810_driver.c | 12
On Sun, 6 Jun 2010 23:52:59 -0700, Eric Anholt wrote:
> Theory being that we don't keep *that* many buffers around, and the
> pain of trying to find the right size in the list is less than the
> pain of using gratuitous amounts of system memory for our BOs.
And, if you sorted the list in size or
On Wed, 23 Jun 2010 00:14:39 -0700, Gregory Diamos
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 repository; that contains a l
On Fri, 25 Jun 2010 16:21:40 +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> We've just gotten an eDP laptop, and kms was booting to a black screen.
>
> as much as I hate Keith's magic * 3, it seems to work a lot better
> than the non-magic.
My *3 was based on the belief that we transmit 3 b
> Generally I think checking our current sw state instead of reading hw
> registers would be safer, e.g. in case we start to queue up more than
> one pageflip. For async pageflips in benchmark mode "flip as fast as
> you can queue" would be a sensible mode.
Ok, I've moved the tiling checks to the
This adds the necesary register defines for async page flipping
through the command ring, and then hooks those up for Ivybridge (gen7)
page flipping.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/intel_display.c | 37
Just copies the IVB code
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 166aa2c..4a118c3 100644
--- a
By mis-declaring this function, we ended up using software cursors
because the value seen by the caller was 0.
Signed-off-by: Keith Packard
---
src/sna/sna_display.c | 8 ++--
src/sna/sna_display_fake.c | 3 ++-
src/uxa/intel_display.c| 7 +--
3 files changed, 13 insertions
Steven Noonan writes:
> Was using my machine normally, then my mouse cursor vanished. After switching
> to a VT and back to X11, my cursor came back. But I did notice a nasty trace
> in
> dmesg (below).
I don't think the trace below is related to the cursor disappearing.
I found a pair of bugs
Julien Cristau writes:
> Only since
> http://cgit.freedesktop.org/xorg/xserver/commit/?id=901fbfbbbd71c0d82080957f8ba09eebbc786f2b
>
> Which could probably have used a different name to avoid silent
> breakage.
Yeah, that probably would have been a better change.
--
keith.pack...@intel.com
p
Steven Noonan writes:
> OK, good to know. Thanks for pointing those out!
As Julien points out, this bug only affects people running master from
the X server though...
--
keith.pack...@intel.com
pgpHmhnPO7B4K.pgp
Description: PGP signature
___
Intel
Ville Syrjälä writes:
> Todd already implemented 5.4Gbps support a while back. So it seems your
> tree is a bit out of date.
I didn't find it on drm-intel-fixes-2014-02-14; can you explain which
tree it is present in?
--
keith.pack...@intel.com
pgpDBs_8j9uhj.pgp
Description: PGP signature
__
Knut Petersen writes:
> /home/knut/fast/xorg/X11-h/usr/include/xorg/shmint.h:59:31: fatal
> error: protocol-versions.h: No such file or directory
Julien noticed this as well; I've posted a patch to the server to fix
it (by not including protocol-versions.h from shmint.h)
--
keith.pack...@intel
Here's a series of patches which provide DRI3 and Present support in
the Intel 2D driver. The first two patches pave the way by
synthesizing 64-bit vblank counters and extending the DRM event
handling to allow for both DRI2 and DRI3 events. Then there's a patch
to add DRI2 and miSyncShm support fol
Signed-off-by: Keith Packard
---
configure.ac| 15 ++
src/uxa/Makefile.am | 6 +
src/uxa/intel.h | 15 ++
src/uxa/intel_driver.c | 4 +
src/uxa/intel_present.c | 406
5 files changed, 446 insertions(+)
create mode
, the X server would end up using stale pointers
stored in those structures. Using simple integers makes it possible to
empty the queue of pending interrupt data and then ignore the stale
kernel data.
Signed-off-by: Keith Packard
---
src/uxa/intel.h | 31 -
src/uxa/intel_display.c | 316
Signed-off-by: Keith Packard
---
configure.ac | 14
src/uxa/Makefile.am| 7 ++
src/uxa/intel.h| 17 +
src/uxa/intel_dri3.c | 184 +
src/uxa/intel_driver.c | 13
src/uxa/intel_sync.c | 109
and
tracking the high 32-bits of MSC separately.
Signed-off-by: Keith Packard
---
src/uxa/intel.h | 9
src/uxa/intel_display.c | 118 -
src/uxa/intel_dri.c | 125
3 files changed, 156
Kristian Høgsberg writes:
> I already explained to Keith why we use different sets of format codes
> in the DRI interface, but it's always fun to slam other peoples code.
As we discussed, my complaint isn't so much about __DRI_IMAGE_FOURCC,
but the fact that the __DRIimage interfaces use *both*
Ville Syrjälä writes:
> What is this format anyway? -ENODOCS
Same as MESA_FORMAT_SARGB8 and __DRI_IMAGE_FORMAT_SARGB8 :-)
> If its just an srgb version of ARGB, then I wouldn't really want it
> in drm_fourcc.h. I expect colorspacy stuff will be handled by various
> crtc/plane properties in
Chris Wilson writes:
>> [PATCH 1/4] Support 64-bit MSC values. Handle kernel vageries about
>
> Some spurious assignments that appear to intentially drop the error code
> could be clarified,
I can't find any dropped error codes in this patch to add comments to,
please provide patch excerpts for
h and lockups".
When running efifb on an nVidia card, executing this store to SR01
ends up causing the screen to go black.
I'm not sure if this store is still required; this patch limits it to
when the intel card is primary.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel
Chris Wilson 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 *some other video
car
Chris Wilson 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 that
> vgaarb is ineff
I'm getting some weird results when using vblank_count on my Ivybridge
machine across suspend/resume.
With glxgears running, I suspend the machine. At resume, I see
vblank_count temporarily jump back by a fairly large amount (usually
between 1 and 2 frames). After a short while, it recove
<#part sign=pgpmime>
On Thu, 29 Mar 2012 13:44:28 +0100, Chris Wilson
wrote:
> In conjunction with bits Power Sequence Progress field and Power Cycle
> Delay Active, this bit set to a one indicates that the panel is
> currently powered up or is currently in the power down sequence and it
> is un
<#part sign=pgpmime>
On Thu, 29 Mar 2012 18:12:56 +0200, Takashi Iwai wrote:
> The strange thing is that, although you can recover the display by
> turning off LVDS and on again once when the problem happens, but then
> the display starts flickering. And, the flickering continues even
> after re
<#part sign=pgpmime>
On Thu, 29 Mar 2012 20:02:01 +0200, Takashi Iwai wrote:
> Sure, that'd be a preferred option.
> If you have any easy test in mind, let me know.
The way I'd love to see it tested would be to capture signal traces on
the LVDS link across mode set and see what glitches appear.
<#part sign=pgpmime>
On Fri, 30 Mar 2012 14:45:16 -0700, Jesse Barnes
wrote:
> So it looks like we can't use this on the BLT ring in SNB or IVB. So
> we'll need a render ring BLT routine to use here instead (hello SNA).
Or a semaphore to block the render ring?
--
keith.pack...@intel.com
<#part sign=pgpmime>
On Tue, 10 Apr 2012 09:46:53 -0400, Adam Jackson wrote:
> Certainly an improvement.
>
> Reviewed-by: Adam Jackson
I'd like to know if this actually helps someone before I stick it in
drm-intel-fixes...
--
keith.pack...@intel.com
__
<#part sign=pgpmime>
On Tue, 10 Apr 2012 09:20:38 -0400, Adam Jackson wrote:
> On 4/10/12 4:35 AM, Chris Wilson wrote:
> > As part of the PCH split, the ability to control CRT standby/suspend
> > states was defeatured; the bits are now marked reserved and apparently
> > have no effect.
>
> Are th
<#part sign=pgpmime>
On Thu, 12 Apr 2012 19:34:12 + (UTC), Eric Appleman
wrote:
> It's a known issue, but I've yet to find a comprehensive explanation for
> what's
> going on.
Appears to be caused by the Hi-Z code. No known solution at this
point, aside from disabling Hi-Z. Here's a script
On Tue, 1 May 2012 08:01:08 -0700, Jesse Barnes
wrote:
> I had wanted to avoid every HSW system looking like it had a bunch of
> HDMI and DP ports, when it really only has one of each or something.
Every DP port is also an HDMI port when a DP to HDMI converter is
plugged in.
--
keith.pack...@
Daniel Vetter writes:
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -1154,11 +1154,10 @@ static void ironlake_edp_panel_off(struct intel_dp
>> *intel_dp)
>>
>> DRM_DEBUG_KMS("Turn eDP power off\n");
>>
>> -WARN(intel_dp->want_panel_vdd, "Can
Jesse Barnes writes:
> High frequency link configurations have the potential to cause trouble
> with long and/or cheap cables, so prefer slow and wide configurations
> instead. This patch has the potential to cause trouble for eDP
> configurations that lie about available lanes, so if we run int
Chris Wilson writes:
> On Thu, 21 Jun 2012 18:13:19 -0700, Keith Packard wrote:
> It was structured to minimise lane count because certain chipsets did
> not wire up all the lanes, right? Is that still relevant as we are using
> the advertised max_lane_count from the DPCD now?
Jesse Barnes writes:
> In embedded applications, some of the lanes may not exist, but the DPCD
> should indicate that (though as Keith says, some lie about it). But if
> we set aside eDP it may be safe...
Yeah, that's my thinking. We should probably include eDP hooked up to
the PCH DP lanes (fo
On Thu, 19 Jul 2012 00:16:59 +0200, Clemens Eisserer
wrote:
> I really hope I won't need to use VGA forever - the blurry fonts make
> my eyes bleed ;)
Yeah, just be aware that DP to HDMI/DVI isn't really a 'dongle' in the
usual sense, the whole internal hardware is running in HDMI mode, just
s
Greg KH writes:
> I see his PCI patches on linux-pci for something that might look helpful
> here, although it's in relation to the radeon driver, so maybe not.
> I'll give it a try though, and I've asked him what he tested the patches
> on.
I sent mjg59 a new macbook pro with the higher resolut
display_bpc might not have been set before comparing with the
requested mode, so wait until afterwards before comparing with the
supported fdi bandwidth. Not a significant change as any case that
mattered would have worked; this just makes the debug messages look nicer.
Signed-off-by: Keith
This is the complete set of patches that yield a working 3-pipe mode
setting configuration on my test machines. It does not make DPMS work,
so I still need to figure that out. As the DPMS paths are almost
entirely different from mode setting (whose crazy idea was that,
anyway?), that may take a bit
These should probably all look like
enabled |= (1 << pipe)
so that the intent is clear...
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_pm.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/dr
IVB shares 4 lanes between FDI B and FDI C. When sharing, compute the
maximum BPC based on the available bandwidth.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 101 +++---
1 file changed, 94 insertions(+), 7 deletions(-)
diff --git a
This is left over from the old PLL sharing code and isn't useful now
that PLLs are shared when possible.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_crt.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gp
Just a bit of cleanup; it appears to have no effect.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7106807
Doesn't make sense to disable in the other order.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b0
Need to turn on the error correction when enabling training or it
might not get enabled in time.
This seems to fix the FDI-B/FDI-C link training problem.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions
Daniel Vetter writes:
> Cc: Keith Packard
I tried this on top of v3.5, appears to work just fine. Thanks!
Tested-by: Keith Packard
--
keith.pack...@intel.com
pgpqnQvHYzFB4.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-
Paulo Zanoni writes:
> +#define HSW_PTE_UNCACHED 0x
Are you sure this value should be zero? It seems pretty unlikely to me.
--
keith.pack...@intel.com
pgptzbyqd415W.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lis
"Lespiau, Damien" writes:
> On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard wrote:
>
> @@ -3728,7 +3728,8 @@ static inline bool intel_panel_use_ssc(struct
> drm_i915_private *dev_priv)
> */
> static bool intel_choose_pipe_bpp_
"Lespiau, Damien" writes:
> I can't see anything in the docs about an order requirement for those.
Right, the docs don't say anything, which is a bit disconcerting.
> Not sure why the other way does not make sense. Somehow disabling TX
> before RX makes some sense to me (TX enabled without a re
Ben Widawsky writes:
> Also, as a bikeshed you could probably get a much better detection with
> a CRC or something similar.
Wonder if you could use the existing MD5 code in the kernel; would avoid
all sorts of unfortunate false-positives.
--
keith.pack...@intel.com
pgpOfytF7Loyb.pgp
Descrip
Jesse Barnes writes:
> v2: use console_trylock() to try to resume the console immediately
> (Chris)
This will cause other printks to stall if i915 grabs the lock
first. Seems like a way to get random resume delays to me.
--
keith.pack...@intel.com
pgpas36b6iooM.pgp
Description: PGP signature
On Mon, 18 Jul 2011 17:57:52 +0100, Chris Wilson
wrote:
> Keith, apologies your missive arrived as I sent the previous patch. This
> uses the inferface you proposed..
Thanks! I've reduced the diff a bit more to make it easier to review and
have pushed this patch onto drm-intel-fixes. I'd like t
On Tue, 19 Jul 2011 00:48:23 +0200, Paul Menzel
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 definitely be sent to
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.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_gem.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions
On Wed, 20 Jul 2011 01:03:17 +0100, Chris Wilson
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.
> i915_gem_object_pin_to_disp
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
---
drivers
sh://master.kernel.org/pub/scm/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 ++-
d
ed the setting of
status_page.page_addr from 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
Date: Fri, 22
On Fri, 22 Jul 2011 12:54:22 -0700, Jesse Barnes
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.
I've stuck this on drm-in
On Sat, 23 Jul 2011 00:23:36 +0400, Kirill Smelkov 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 right, of cour
On Sat, 23 Jul 2011 18:55:48 +0300 (EEST), Pekka Enberg
wrote:
> I know I sound like a broken record but I really wish you i915 devs were
> little more eager to revert broken patches early rather than late. I mean,
> this particular breakage was already bisected but nobody said or
> did anyth
On Sat, 23 Jul 2011 14:40:36 -0400, Andrew Lutomirski 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 get an im
On Mon, 25 Jul 2011 11:23:17 -0400, Andrew Lutomirski 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
> the link.
mode setting is underway, the link will get
scrambled, leaving it in an inconsistent state.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/i915_irq.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
rlapping modesetting fun. And, it seems like the trace you provided
shows precisely that happening.
Care to try this patch? It's fixed my persistent hot-unplug problems.
From bba6ccca57f0536fb5aae278527939d7247a1f53 Mon Sep 17 00:00:00 2001
From: Keith Packard
Date: Mon, 25 Jul 2011 10:04:56
On Mon, 25 Jul 2011 13:40:58 -0400, Andrew Lutomirski wrote:
> Will test tonight.
Thanks.
> It looks like there is a lot of hotplug activity when 'xset dpms force
> off' gets run. (That's not a typo. I do mean "off," not "on."
Yup, that's what I've seen as well -- do a mode set to turn stuf
on hotplug after the driver
had been initialized because nothing in the mode setting path would set
the dpms_mode 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 59b920597999381fab70c485c161dd5
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
---
drivers/gpu/drm/i915/intel_dp.c |8 +++-
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b
-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 39 +++
1 files changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index dcc7ae6..45db810 100644
--- a/drivers/gpu/drm/i915
This describes the function better, allowing it to be used where the
DPCD value is relevant.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_dp.c | 24 +++-
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b
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
---
drivers/gpu/drm/i915/i915_reg.h |3
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
---
drivers/gpu/drm/i915/i915_irq.c |
[PATCH 1/5] drm/i915: Use dp_detect_common in hotplug helper
[PATCH 2/5] drm/i915: Rename i915_dp_detect_common to
[PATCH 3/5] drm/i915: In intel_dp_init, replace read of DPCD with
These three are simple cleanups to centralize all places where the
DPCD block was read from the device. Now everyo
On Tue, 26 Jul 2011 09:24:39 +0200, Daniel Vetter wrote:
> Two things I've noticed:
> - Why not dev->mode_config.mutex?
You're right, of course. I noticed that just after posting that version
and updated it; the updated version is on my drm-intel-fixes branch
already (having been reviewed by Jes
On Tue, 26 Jul 2011 09:44:32 +0200, Daniel Vetter wrote:
> queue_delayed_work? Plays nicer with other workqueue-items.
Yeah, I'll change this.
--
keith.pack...@intel.com
pgpmBnOF4ET1G.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-
This corrects the DPMS mode tracking so that the DPMS code will
actually turn the CRTC off the next time the screen saves.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915
On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes
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
> before that... Previou
Ok, that took all evening. And, I don't have a fix, but I do know a lot
more about the problem.
To recap:
On Sandybridge, sometimes, when you simultaneously change two
outputs, one of them turns into stripes, or as solid color.
Here's how I reproduce it:
First, connect
1 - 100 of 748 matches
Mail list logo
