Re: [Intel-gfx] [PATCH] i915: Drop legacy execbuffer support

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 Packa

Re: [Intel-gfx] [PATCH] drm/lease: Send a distinct uevent

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

Re: [Intel-gfx] [PATCH 3/3] drm/lease: look at ->universal_planes only once

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

Re: [Intel-gfx] [PATCH 1/3] drm/lease: debug output for lease creation

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) { > +

Re: [Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

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

Re: [Intel-gfx] [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

against the 64-bit vblank > count. For patches 1-7: Reviewed-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/5] drm/vblank: Fix data type width for drm_crtc_arm_vblank_event()

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

Re: [Intel-gfx] [PATCH 1/5] drm/vblank: Fix return type for drm_vblank_count()

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

[Intel-gfx] [PATCH i-g-t 1/2] tests/kms_sequence: Add tests for new CRTC get/queue sequence ioctls [v2]

. v2: from Dave Airlie <airl...@redhat.com> * 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 <kei...@keithp.com> --- lib/igt_kms.c |

[Intel-gfx] [PATCH i-g-t 0/2] tests: Add tests for new sequence API and leases

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] [PATCH i-g-t 2/2] tests/kms_lease: add tests for lease ioctls [v3]

ed-off-by: Keith Packard <kei...@keithp.com> --- tests/Makefile.sources | 1 + tests/kms_lease.c | 606 + tests/meson.build | 1 + 3 files changed, 608 insertions(+) create mode 100644 tests/kms_lease.c diff --git a/tests/Makefi

[Intel-gfx] [PATCH] drm: Update edid-derived drm_display_info fields at edid property set [v2]

FIXME in drm_mode_connector_update_edid_property about potentially merging that with drm_add_edid_modes to avoid the need for two driver calls. Signed-off-by: Keith Packard <kei...@keithp.com> Reviewed-by: Daniel Vetter <daniel.vet...@ffwll.ch> --- drivers/gpu/drm/drm_connector.c | 13 +

[Intel-gfx] [PATCH i-g-t 2/2] tests/kms_lease: add tests for lease ioctls [v2]

essees Signed-off-by: Keith Packard <kei...@keithp.com> --- tests/Makefile.sources | 1 + tests/kms_lease.c | 597 + tests/meson.build | 1 + 3 files changed, 599 insertions(+) create mode 100644 tests/kms_lease.c diff -

[Intel-gfx] [PATCH i-g-t 0/2] Add new vblank and lease tests [v2]

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

[Intel-gfx] [PATCH i-g-t 1/2] tests/kms_sequence: Add tests for new CRTC get/queue sequence ioctls [v2]

. v2: from Dave Airlie <airl...@redhat.com> * 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 <kei...@keithp.com> --- lib/igt_kms.c |

Re: [Intel-gfx] [PATCH] drm/dp: Do not prune the last mode on the connector

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

Re: [Intel-gfx] [PATCH] drm: Document code of conduct

Daniel Vetter <daniel.vet...@ffwll.ch> writes: > freedesktop.org has adopted a formal code of conduct: Acked-by: Keith Packard <kei...@keithp.com> -- -keith signature.asc Description: PGP signature ___ Intel-gfx mailing

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Drop reference to current state wait req as soon as it goes unused

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

Re: [Intel-gfx] [PATCH] drm/i915: cleanup_plane_fb: also drop reference to current state wait_req

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

[Intel-gfx] [PATCH] drm/i915: cleanup_plane_fb: also drop reference to current state wait_req

c: Daniel Vetter <daniel.vet...@intel.com> cc: David Airlie <airl...@linux.ie> cc: intel-gfx@lists.freedesktop.org cc: dri-de...@lists.freedesktop.org Signed-off-by: Keith Packard <kei...@keithp.com> --- drivers/gpu/drm/i915/intel_display.c | 2 ++ 1 file changed, 2 insertions(+

Re: [Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA

Chris Wilson ch...@chris-wilson.co.uk writes: commit d21d781466785c317131a8a57606925867265dc8 Author: Daniel Vetter daniel.vet...@ffwll.ch Date: Tue Feb 22 18:31:44 2011 +0100 Fix relaxed tiling on gen2 This one matches libdrm in using 16 for the tile height alignment on gen2. Try

Re: [Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA

Chris Wilson ch...@chris-wilson.co.uk writes: That extra alignment is due to gen2 and early gen3 (if (!intel-has_relaxed_fencing) covers them). Here's the patch which changed the alignment requirment: commit 736b89504a32239a0c7dfb5961c1b8292dd744bd Author: Chris Wilson

[Intel-gfx] [PATCH 0/2 xf86-video-intel] Two DRI3/Present bug fixes for UXA

Here are a couple of small bug fixes which make DRI3/Present work better with UXA. [PATCH 1/2] Do not clear pending kernel events on mode switch This patch prevents GL-based compositing managers from wedging when performing video mode setting. The problem was that DIX was never receiving

[Intel-gfx] [PATCH 2/2] Correct BO allocation alignment

-off-by: Keith Packard kei...@keithp.com --- src/uxa/intel_uxa.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/uxa/intel_uxa.c b/src/uxa/intel_uxa.c index d33eca5..4ce6eae 100644 --- a/src/uxa/intel_uxa.c +++ b/src/uxa/intel_uxa.c @@ -206,7 +206,7

[Intel-gfx] [PATCH 1/2] Do not clear pending kernel events on mode switch

at mode switch time will discard the connection between the kernel event and the present callback so that DIX will never know that the flip pixmap is idle. Signed-off-by: Keith Packard kei...@keithp.com --- src/uxa/intel_display.c | 4 1 file changed, 4 deletions(-) diff --git a/src/uxa

Re: [Intel-gfx] [PATCH 01/12] Stop trying to out-guess mesa for BO allocation

Eric Anholt e...@anholt.net writes: OK, but isn't the problem with the code you're #if 0ing (which, really? #if 0 in a patch being submitted for review?) that it's aligning to 2*height instead of height? I went and did a bit of archaeology to figure out why it's using 2*height instead of just

Re: [Intel-gfx] [PATCH 09/12] Do more checks for proposed flip pixmaps

Eric Anholt e...@anholt.net writes: Keith Packard kei...@keithp.com writes: Make sure the pitch and tiling are correct. Make sure there's a BO we can get at. I thought we couldn't change these parameters, but now I can't find what prevents them from changing. Can you cite sources? Looks

Re: [Intel-gfx] [PATCH 10/12] Add glamor back into the driver

Eric Anholt e...@anholt.net writes: Keith Packard kei...@keithp.com writes: This adds glamor support back into the driver, but instad of going through UXA, this uses it directly instead. This is hard to read with the conditionalizing all of the UXA code in the same commit as adding

Re: [Intel-gfx] [PATCH 00/12] Rework intel 2D driver glamor support

Eric Anholt e...@anholt.net writes: Keith Packard kei...@keithp.com writes: I spent the day just cleaning up this patch series and testing. I think it's ready for others to use and review. I've been running it on two machines for a couple of days now and it's been solid. Patches 2, 4

Re: [Intel-gfx] [PATCH 00/12] Rework intel 2D driver glamor support

Eric Anholt e...@anholt.net writes: Keith Packard kei...@keithp.com writes: I spent the day just cleaning up this patch series and testing. I think it's ready for others to use and review. I've been running it on two machines for a couple of days now and it's been solid. Patches 2, 4

Re: [Intel-gfx] [PATCH 09/12] Do more checks for proposed flip pixmaps

Ville Syrjälä ville.syrj...@linux.intel.com writes: Now that we have mmio flips in the kernel we can start to relax that restriction. That still needs a bit more work in the mmio flip code but I believe some people working on just that. I couldn't find any tiling restrictions in the current

Re: [Intel-gfx] [PATCH 01/12] Stop trying to out-guess mesa for BO allocation

Eric Anholt e...@anholt.net writes: Keith Packard kei...@keithp.com writes: I don't see anything indicating that this code path is only used by glamor. True. It's a fix for DRI3 for either UXA or none. Mesa allocates a single page for a 1x1 texture, but this code thinks that should take two

Re: [Intel-gfx] [PATCH 03/12] Don't use GetScratchPixmapHeader for shadow pixmaps

Eric Anholt e...@anholt.net writes: This change appears to be unrelated, and possibly harmful (if X has dropped the last ref to the BO, but it's still the scanout buffer, a new allocation would now reuse the BO and scribble on scanout until the next modeset happens). Yeah, it's unrelated.

Re: [Intel-gfx] [PATCH 06/12] Remove glamor support from UXA acceleration

Eric Anholt e...@anholt.net writes: Something weird happened in this commit. uxa-glamor.h is removed from the repo, but the makefile only drops intel_glamor.h, which keeps getting used. I suspect make distcheck is broken. Yeah, almost certainly. In fact, after this patch, the driver does

Re: [Intel-gfx] [PATCH 08/12] Get rid of glamor stubs in intel_glamor.h

Eric Anholt e...@anholt.net writes: Keith Packard kei...@keithp.com writes: This eliminates the stubs in intel_glamor.h and replaces them with ifdefs instead. I don't feel strongly about this either way -- ifdefs are more traditional userland style, while stubs are more kernel style

[Intel-gfx] [PATCH 00/12] Rework intel 2D driver glamor support

I spent the day just cleaning up this patch series and testing. I think it's ready for others to use and review. I've been running it on two machines for a couple of days now and it's been solid. I ran three different desktop environments (current Debian unstable versions): XFCE 4.10

[Intel-gfx] [PATCH 04/12] Move intel_alloc_framebuffer to intel_memory.c

UXA and Glamor both share this function, so move it out of the UXA file. Signed-off-by: Keith Packard kei...@keithp.com --- src/uxa/intel.h| 5 ++ src/uxa/intel_memory.c | 138 ++ src/uxa/intel_uxa.c| 158

[Intel-gfx] [PATCH 02/12] Fix present debug output

Was using 'low_msc', which isn't defined anymore. Signed-off-by: Keith Packard kei...@keithp.com --- src/uxa/intel_present.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/uxa/intel_present.c b/src/uxa/intel_present.c index 18fcbf8..5f98da8 100644 --- a/src/uxa

[Intel-gfx] [PATCH 01/12] Stop trying to out-guess mesa for BO allocation

--- src/uxa/intel_uxa.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/src/uxa/intel_uxa.c b/src/uxa/intel_uxa.c index b396188..717754f 100644 --- a/src/uxa/intel_uxa.c +++ b/src/uxa/intel_uxa.c @@ -758,6 +758,7 @@ free_priv: goto free_priv; } +#if

[Intel-gfx] [PATCH 03/12] Don't use GetScratchPixmapHeader for shadow pixmaps

-by: Keith Packard kei...@keithp.com --- src/uxa/intel_display.c | 44 ++-- 1 file changed, 30 insertions(+), 14 deletions(-) diff --git a/src/uxa/intel_display.c b/src/uxa/intel_display.c index 0b83140..bcaafaa 100644 --- a/src/uxa/intel_display.c +++ b/src

[Intel-gfx] [PATCH 10/12] Add glamor back into the driver

This adds glamor support back into the driver, but instad of going through UXA, this uses it directly instead. Signed-off-by: Keith Packard kei...@keithp.com --- src/uxa/intel.h | 17 +++ src/uxa/intel_display.c | 30 - src/uxa/intel_dri.c | 20 +++ src/uxa/intel_driver.c

[Intel-gfx] [PATCH 06/12] Remove glamor support from UXA acceleration

Makes UXA no longer include calls to glamor acceleration functions. Signed-off-by: Keith Packard kei...@keithp.com --- src/uxa/Makefile.am| 9 -- src/uxa/intel_dri.c| 60 + src/uxa/intel_driver.c | 1 - src/uxa/intel_uxa.c| 49 --- src/uxa/intel_uxa.h

[Intel-gfx] [PATCH 07/12] Add intel_flush to abstract flushing pending acceleration operations

intel_flush flushes any pending acceleration operations to the hardware, just like intel_uxa_batch_submit does today except that it is not uxa-specific. Signed-off-by: Keith Packard kei...@keithp.com --- src/uxa/intel.h | 3 +++ src/uxa/intel_display.c | 11 +++ src/uxa

[Intel-gfx] [PATCH 08/12] Get rid of glamor stubs in intel_glamor.h

This eliminates the stubs in intel_glamor.h and replaces them with ifdefs instead. Signed-off-by: Keith Packard kei...@keithp.com --- src/uxa/intel_dri.c | 20 ++-- src/uxa/intel_driver.c | 6 ++ src/uxa/intel_glamor.h | 21 - src/uxa

[Intel-gfx] [PATCH 11/12] Add none acceleration option

This just uses fb directly Signed-off-by: Keith Packard kei...@keithp.com --- configure.ac| 24 - src/Makefile.am | 9 +- src/intel_module.c | 12 ++- src/uxa/Makefile.am | 46 ++--- src/uxa/intel.h | 5 + src/uxa/intel_display.c | 6 ++ src

[Intel-gfx] [PATCH 12/12] Delay initial modeset until root window contents are prepared

Wait until the root window has been painted for the first time before doing the modeset. This avoids flashing black while the root window gets set up. Signed-off-by: Keith Packard kei...@keithp.com --- src/uxa/intel.h | 2 ++ src/uxa/intel_display.c | 39

[Intel-gfx] [PATCH 09/12] Do more checks for proposed flip pixmaps

Make sure the pitch and tiling are correct. Make sure there's a BO we can get at. Signed-off-by: Keith Packard kei...@keithp.com --- src/uxa/intel_present.c | 18 ++ 1 file changed, 18 insertions(+) diff --git a/src/uxa/intel_present.c b/src/uxa/intel_present.c index c53d71d

[Intel-gfx] [PATCH] load_cursor_argb is supposed to return a Bool, not void

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 kei...@keithp.com --- src/sna/sna_display.c | 8 ++-- src/sna/sna_display_fake.c | 3 ++- src/uxa/intel_display.c| 7 +-- 3 files changed

Re: [Intel-gfx] REGRESSION 3.14 i915 warning mouse cursor vanishing

Steven Noonan ste...@uplinklabs.net 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

Re: [Intel-gfx] [PATCH] load_cursor_argb is supposed to return a Bool, not void

Julien Cristau jcris...@debian.org 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. --

Re: [Intel-gfx] REGRESSION 3.14 i915 warning mouse cursor vanishing

Steven Noonan ste...@uplinklabs.net 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

Re: [Intel-gfx] [PATCH] drm/i915/dp: Allow for 5.4Gbps for Haswell.

Ville Syrjälä ville.syrj...@linux.intel.com 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

[Intel-gfx] [PATCH] drm/intel: Only smash VGA SR01 register if intel is default VGA device

. 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 kei...@keithp.com --- drivers/gpu/drm/i915

Re: [Intel-gfx] [PATCH] drm/intel: Only smash VGA SR01 register if intel is default VGA device

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

Re: [Intel-gfx] [PATCH] drm/intel: Only smash VGA SR01 register if intel is default VGA device

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

Re: [Intel-gfx] [PATCH 0/4] xf86-video-intel DRI3 and Present patch series

Chris Wilson ch...@chris-wilson.co.uk 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

Re: [Intel-gfx] [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

Kristian Høgsberg hoegsb...@gmail.com 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

Re: [Intel-gfx] [Mesa-dev] [PATCH] dri3, i915, i965: Add __DRI_IMAGE_FOURCC_SARGB8888

Ville Syrjälä ville.syrj...@linux.intel.com 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

[Intel-gfx] [PATCH 0/4] xf86-video-intel DRI3 and Present patch series

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

[Intel-gfx] [PATCH 4/4] Add Present extension support

Signed-off-by: Keith Packard kei...@keithp.com --- 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

[Intel-gfx] [PATCH 2/4] Restructure DRM event handling.

, 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 kei...@keithp.com --- src/uxa/intel.h | 31 - src/uxa

[Intel-gfx] [PATCH 3/4] Add DRI3 and miSyncShm support

Signed-off-by: Keith Packard kei...@keithp.com --- 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

[Intel-gfx] [PATCH 1/4] Support 64-bit MSC values. Handle kernel vageries about MSC reporting

and tracking the high 32-bits of MSC separately. Signed-off-by: Keith Packard kei...@keithp.com --- src/uxa/intel.h | 9 src/uxa/intel_display.c | 118 - src/uxa/intel_dri.c | 125 3 files

[Intel-gfx] vblank_count count jumps backwards and then forwards across system suspend

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

Re: [Intel-gfx] compilation broken again

Knut Petersen knut_peter...@t-online.de 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)

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Add async page flip support for IVB

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

[Intel-gfx] [PATCH 1/2] drm/i915: Add async page flip support for IVB

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 kei...@keithp.com --- drivers/gpu/drm/i915/i915_reg.h | 6 ++ drivers/gpu/drm/i915/intel_display.c | 37

[Intel-gfx] [PATCH 2/2] drm/i915: Add async page flip support for SNB

Just copies the IVB code Signed-off-by: Keith Packard kei...@keithp.com --- 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

Re: [Intel-gfx] [PATCH 1/4] drm/i915: don't block resume on fb console resume v2

Jesse Barnes jbar...@virtuousgeek.org 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

Re: [Intel-gfx] [PATCH] drm/i915: optionally check GTT checksum across suspend/resume

Ben Widawsky b...@bwidawsk.net 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

Re: [Intel-gfx] [PATCH 2/7] drm/i915: FDI B/C share 4 lanes on Ivybridge

Lespiau, Damien damien.lesp...@intel.com writes: On Tue, Aug 14, 2012 at 5:34 AM, Keith Packard kei...@keithp.com wrote: @@ -3728,7 +3728,8 @@ static inline bool intel_panel_use_ssc(struct drm_i915_private *dev_priv) */ static bool intel_choose_pipe_bpp_dither(struct drm_crtc *crtc

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Disable FDI RX before FDI TX

Lespiau, Damien damien.lesp...@intel.com 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

Re: [Intel-gfx] [PATCH] drm/i915: fix hsw uncached pte

Paulo Zanoni przan...@gmail.com 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

[Intel-gfx] [PATCH 4/7] drm/i915: Check display_bpc against max_fdi_bpp after display_bpc is set

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

[Intel-gfx] [PATCH 0/7] drm/i915: IVB FDI B/C fixes and misc cleanups

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

[Intel-gfx] [PATCH 5/7] drm/i915: Pipe-C only configurations would not get SR

These should probably all look like enabled |= (1 pipe) so that the intent is clear... Signed-off-by: Keith Packard kei...@keithp.com --- 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

[Intel-gfx] [PATCH 3/7] drm/i915: Delay between FDI link training tries. Clear FDI_RX_IIR before training

Just a bit of cleanup; it appears to have no effect. Signed-off-by: Keith Packard kei...@keithp.com --- 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

[Intel-gfx] [PATCH 6/7] drm/i915: Disable FDI RX before FDI TX

Doesn't make sense to disable in the other order. Signed-off-by: Keith Packard kei...@keithp.com --- 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

[Intel-gfx] [PATCH 7/7] drm/i915: Merge FDI RX reg writes during training

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 kei...@keithp.com --- drivers/gpu/drm/i915/intel_display.c | 11 ++- 1 file changed, 6 insertions

Re: [Intel-gfx] Output problems with displayport-hdmi kable on arrandale based hp elitebook 2540p

On Thu, 19 Jul 2012 00:16:59 +0200, Clemens Eisserer linuxhi...@gmail.com 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

Re: [Intel-gfx] [PATCH] drm/i915: prefer wide slow to fast narrow in DP configs

Chris Wilson ch...@chris-wilson.co.uk writes: On Thu, 21 Jun 2012 18:13:19 -0700, Keith Packard kei...@keithp.com 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

Re: [Intel-gfx] [PATCH] drm/i915: prefer wide slow to fast narrow in DP configs

Jesse Barnes jbar...@virtuousgeek.org 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

Re: [Intel-gfx] [PATCH] drm/i915: enable vdd when switching off the eDP panel

Daniel Vetter dan...@ffwll.ch 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, Cannot

Re: [Intel-gfx] [PATCH 19/24] drm/i915: detect digital outputs on Haswell

On Tue, 1 May 2012 08:01:08 -0700, Jesse Barnes jbar...@virtuousgeek.org 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

Re: [Intel-gfx] Google MapsGL causing X crashes on machines with Sandybridge graphics

#part sign=pgpmime On Thu, 12 Apr 2012 19:34:12 + (UTC), Eric Appleman erapple...@gmail.com 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.

Re: [Intel-gfx] [PATCH] drm/i915: properly compute dp dithering for user-created modes

#part sign=pgpmime On Tue, 10 Apr 2012 09:46:53 -0400, Adam Jackson a...@redhat.com wrote: Certainly an improvement. Reviewed-by: Adam Jackson a...@redhat.com I'd like to know if this actually helps someone before I stick it in drm-intel-fixes... -- keith.pack...@intel.com

Re: [Intel-gfx] [PATCH] drm/i915/crt: Only support DPMS On/Off with the PCH registers

#part sign=pgpmime On Tue, 10 Apr 2012 09:20:38 -0400, Adam Jackson a...@redhat.com 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.

Re: [Intel-gfx] Scanline wait hack for IVB

#part sign=pgpmime On Fri, 30 Mar 2012 14:45:16 -0700, Jesse Barnes jbar...@virtuousgeek.org 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? --

Re: [Intel-gfx] Broken LVDS output at mode changes

#part sign=pgpmime On Thu, 29 Mar 2012 13:44:28 +0100, Chris Wilson ch...@chris-wilson.co.uk 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

Re: [Intel-gfx] Broken LVDS output at mode changes

#part sign=pgpmime On Thu, 29 Mar 2012 18:12:56 +0200, Takashi Iwai ti...@suse.de 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

Re: [Intel-gfx] Broken LVDS output at mode changes

#part sign=pgpmime On Thu, 29 Mar 2012 20:02:01 +0200, Takashi Iwai ti...@suse.de 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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Check VBIOS value for determining LVDS dual channel mode, too

#part sign=pgpmime On Tue, 20 Mar 2012 13:04:41 +0100, Takashi Iwai ti...@suse.de wrote: Since checking the lid state is tricky and unreliable, the practical check would be simply reading the first LVDS reg and seeing whether it was initialized or not. It seems that it reads to 0x02 when

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Check VBIOS value for determining LVDS dual channel mode, too

#part sign=pgpmime On Sat, 17 Mar 2012 08:59:56 +0100, Takashi Iwai ti...@suse.de wrote: Well, the LVDS reg data isn't in lvds_dvo_timing but in lvds_fp_timing, thus you need to look at a different entry in anyway. Right, a parallel function which returns the lvds_fp_timing structure instead

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Check VBIOS value for determining LVDS dual channel mode, too

#part sign=pgpmime On Fri, 16 Mar 2012 22:41:12 +0100, Takashi Iwai ti...@suse.de wrote: +/* read the initial LVDS register value for the given panel mode */ +static unsigned int get_lvds_reg_val(const struct bdb_header *bdb, + const struct

[Intel-gfx] [PULL] drm-intel-fixes

Jesse sent me a couple of trivial sprite plane fixes. The following changes since commit 91982b58d35720b75b894c60e1e3133daa455b53: drm/gma500: Fix Cedarview boot failures in 3.3-rc (2012-03-05 14:08:31 +) are available in the git repository at:

Re: [Intel-gfx] [PATCH 1/2] drm/i915: fix color order for BGR formats on SNB

#part sign=pgpmime On Wed, 7 Mar 2012 07:02:02 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: Dave, not sure if Keith has setup his -fixes tree again, but this one needs to go to Linus in your next pull assuming you're doing one. Yeah, I got home just in time to travel for a whole week.

Re: [Intel-gfx] [PATCH 1/2] drm/i915: fix color order for BGR formats on SNB

#part sign=pgpmime On Mon, 27 Feb 2012 12:40:10 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: Had the wrong bits and field definitions. Merged. 617cf88..ab2f9df drm-intel-fixes - drm-intel-fixes -- keith.pack...@intel.com ___ Intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: support 32 bit BGR formats in sprite planes

#part sign=pgpmime On Wed, 7 Mar 2012 08:49:29 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: intel_framebuffer_init does some basic sanity checking of the pixel format, but is used by the plane code in addition to the primary crtc. So it needs to contain any formats used in either

Re: [Intel-gfx] [PATCH 1/2] drm/i915: fix color order for BGR formats on SNB

#part sign=pgpmime On Wed, 07 Mar 2012 14:04:28 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: Yeah, only 1/2 belongs in fixes. The other one needs another patch on top to avoid unpinning an active buffer. Hence 'sketchy' :-) -- keith.pack...@intel.com

Re: [Intel-gfx] [RFC] drm/i915: read current config at init time to avoid flicker

#part sign=pgpmime On Thu, 1 Mar 2012 12:37:47 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: The intent here is to build enough of the configuration to allow set_config to avoid mode setting if possible. When I played with this, not setting the fb across this process tended to do 'bad'

  1   2   3   4   5   6   7   >