Re: drm: Branch 'master' - 2 commits
On Mon, 5 Dec 2011 02:31:58 -0800 (PST), ic...@kemper.freedesktop.org (Chris Wilson) wrote: configure.ac |2 +- intel/intel_bufmgr_gem.c | 27 +-- 2 files changed, 22 insertions(+), 7 deletions(-) New commits: commit e73161a02b604742e3da3bca8f13cff81276de43 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Mon Dec 5 10:30:52 2011 + configure: Bump version to 2.4.28 So that we can pull a couple of Intel bug fixes into xf86-video-intel. Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk Performance before: [ 0] glfirefox-talos-gfx 17.866 17.915 0.14%4/4 after: [ 0] glfirefox-talos-gfx 22.173 22.251 0.20%4/4 There's a pretty obvious opportunity to keep the performance win of the userspace caching that you've broken here, but you gave none of us a chance to review it before you pushed the patch *and shipped a release with it*. This is not acceptable. Please revert and bump the release, and fix it correctly. pgpAEuNpy2UG9.pgp Description: PGP signature -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[ANNOUNCE] libdrm 2.4.27
Ben Widawsky (1): intel: shared header for shader debugging Chih-Wei Huang (1): Specify the return type explicitly. Daniel Vetter (2): drm/intel: don't clobber bufmgr-pci_device drm/i915: y tiling on i915G/i915GM is different Dave Airlie (3): drm/test: handle usub being empty drmtest: make check should fail so hard on unable to open device nouveau: free in error path if drmAvailable fails. Eric Anholt (6): intel: Use stdbool.h for dealing with boolean values. intel: Add an interface for removing relocs after they're added. intel: Remove stale comment. intel: Don't call the SW_FINISH ioctl unless a CPU-mapped write was done. intel: Share the implementation of BO unmap between CPU and GTT mappings. configure: version bump for 2.4.27 release. Jakob Bornecrantz (5): tests: Add vmwgfx driver to probed drivers in tests vbltest: Check error codes returned from libdrm modetest: Check error message from pageflip ioctl modetest: Print extra info if we fail to create a framebuffer modetest: Call dirty fb on modeset Jesse Barnes (1): modetest: use 24 bit depth on the framebuffer Marcin Slusarz (2): drm mode: fix drmIoctl wrapper nouveau: assert argument cannot have side effects Matt Turner (1): modeprint.c: use PRIu64 for printing uint64_t Tapani Pälli (1): xf86drm.h : wrap C code for C++ compilation/linking Yuanhan Liu (1): intel: fix the wrong method check for bo_get_subdata git tag: 2.4.27 http://dri.freedesktop.org/libdrm/libdrm-2.4.27.tar.bz2 MD5: 0fba4f42735cd3d24dd7a8cde0023fbd libdrm-2.4.27.tar.bz2 SHA1: f5b40d30a7f2bfa369ab9b3bd9a0aa844a7f1e16 libdrm-2.4.27.tar.bz2 SHA256: ea6b04dd3298e36c7a43aadd5f80f48baeafe4caaabcf78b01dc919c5c757973 libdrm-2.4.27.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.27.tar.gz MD5: 235dd2e75d0286a91019cd3aec1b4b47 libdrm-2.4.27.tar.gz SHA1: 2dd6005e2a7e2f186d7b5780fc5e0143d18f90e7 libdrm-2.4.27.tar.gz SHA256: 9f11d369925222c013773ad7ec0812feb4f5388e70a8ef0f729251f956acd7bf libdrm-2.4.27.tar.gz pgpHLOO3Cxuvj.pgp Description: PGP signature -- Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World#153; now supports Android#153; Apps for the BlackBerryreg; PlayBook#153;. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] libkms: Allocate dumb framebuffers as 32bpp if we claim they're x8r8g8b8.
modetest got all segfaulty after walking off the end of the 16bpp framebuffer that it was told was 32bpp. --- libkms/dumb.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/libkms/dumb.c b/libkms/dumb.c index 3be5f7a..fafef64 100644 --- a/libkms/dumb.c +++ b/libkms/dumb.c @@ -95,7 +95,7 @@ dumb_bo_create(struct kms_driver *kms, memset(arg, 0, sizeof(arg)); - arg.bpp = 16; + arg.bpp = 32; arg.width = width; arg.height = height; -- 1.7.4.1 -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Tue, 31 Aug 2010 12:17:43 +0200, Zdenek Kabelac zkabe...@redhat.com wrote: Dne 28.8.2010 05:55, Eric Anholt napsal(a): On Fri, 27 Aug 2010 13:16:04 +0200, Zdenek Kabelac zkabe...@redhat.com wrote: On 27.8.2010 12:02, Julien Cristau wrote: On Fri, Aug 27, 2010 at 11:26:59 +0200, Zdenek Kabelac wrote: Why keeping different name for C++ and C ? Because changing the name for C means breaking API for existing users, which is not a nice thing to do. Well if DRM would have very stable API - it would make sence - but from a view of occasional user who needs to compile drm for intel driver - it seems the API is changed so frequently and in such an incompatible way that this change doesn't look all that bad. How many libdrm project users are there - and how often is this variable used outside of libdrm ? Now C++ will use different names for same variables - that IMHO bigger issue... Also - if headers are supposed to be C++ friendly - maybe usage of extern C might be handy for such case ? Uh, you claim the API has changed, but I'm not aware of any circumstance since TTM removal where upgrading libdrm on Intel should have broken either API or ABI for its users. Can you back that up? Ok - I'm remembering this issue: Essentially I've had idea to try to bisect for this problem: https://bugs.freedesktop.org/show_bug.cgi?id=26937 As I'm quite sure, that there were times were I could use fullscreen for flash without fear of having to restart my desktop. So I've tried just some random older git versions of libdrm intel driver - there were some minor compilations issue (I guess some list defines conflicts and few other minor things for compilation). However compiled driver library actually never worked and all I got was usually black screen. It's probably hard to judge if the problem is kernel driver (using usually quite fresh vanilla git tree) or Xorg from Fedora Rawhide can't work with some slightly older libdrm/intel. It probably not reasonable to spend time to detect where exactly is problem - all I want to point out is, that some internal API must changed significantly so while I could usually boot with 2 year old kernel, I cannot use few months old drmintel driver. And back to this issue - if this variable is used a lot by other projects, than this commit is probably ok - though looks ugly. But if there is just one project which uses it, than it's probably better to break API and keep it clean and use same variable for C C++ programs. For bisecting, just hold libdrm at the new version and bisect in 2d, unless your initial test of old+old vs old+new of each component points at libdrm (in which case, hold the 2d driver old and bisect across libdrm). New drivers do require new symbols, but libdrm is API and ABI stable, exactly so that people can bisect successfully. pgpcqoVUWDGRH.pgp Description: PGP signature -- This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: Branch 'master'
On Fri, 27 Aug 2010 13:16:04 +0200, Zdenek Kabelac zkabe...@redhat.com wrote: On 27.8.2010 12:02, Julien Cristau wrote: On Fri, Aug 27, 2010 at 11:26:59 +0200, Zdenek Kabelac wrote: Why keeping different name for C++ and C ? Because changing the name for C means breaking API for existing users, which is not a nice thing to do. Well if DRM would have very stable API - it would make sence - but from a view of occasional user who needs to compile drm for intel driver - it seems the API is changed so frequently and in such an incompatible way that this change doesn't look all that bad. How many libdrm project users are there - and how often is this variable used outside of libdrm ? Now C++ will use different names for same variables - that IMHO bigger issue... Also - if headers are supposed to be C++ friendly - maybe usage of extern C might be handy for such case ? Uh, you claim the API has changed, but I'm not aware of any circumstance since TTM removal where upgrading libdrm on Intel should have broken either API or ABI for its users. Can you back that up? pgpKm9ejTeVnU.pgp Description: PGP signature -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH]: i915: fix uninitialized variable warning in i915_setup_compression()
On Thu, 27 May 2010 13:37:56 -0400, Prarit Bhargava pra...@redhat.com wrote:
Fixes:
drivers/gpu/drm/i915/i915_dma.c: In function ‘i915_setup_compression’:
drivers/gpu/drm/i915/i915_dma.c:1311: error: ‘compressed_llb’ may be used
uninitialized in this function
Signed-off-by: Prarit Bhargava pra...@redhat.com
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 4c03ee5..e6a63d1 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1308,7 +1308,7 @@ static void i915_warn_stolen(struct drm_device *dev)
static void i915_setup_compression(struct drm_device *dev, int size)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- struct drm_mm_node *compressed_fb, *compressed_llb;
+ struct drm_mm_node *compressed_fb, *uninitialized_var(compressed_llb);
unsigned long cfb_base;
unsigned long ll_base = 0;
Applied to for-linus. Thanks!
pgpHFsSRc1QcL.pgp
Description: PGP signature
--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: How to clear WC buffer, or is it needs to clear WC buffer
On Fri, 18 Jun 2010 16:51:02 +0800, april aapri...@gmail.com wrote: Hi all: I have a problem. I want to make a command buffer in PCIE memory, and make Engine execute those commands. First set PCIE memory to be WC, copy command to command buffer in PCIE memory, and make HW to execute those commands. sometimes, the Graphic engine will hang. I try to use mb() to clear WC buffer, it seems a little butter? But the problem is still. When I set the PCIE memory to Uncached, everthing is OK. So, Is it due to the write buffer that is not evicted ? and how to clear the WC buffer? You need to do PCI write posting, meaning read some data out of the target to ensure that your buffered writes actually land. You'll often see this in the drivers as: WRITE_REG(reg, val) (void)READ_REG(reg) pgpjSoMHgI23A.pgp Description: PGP signature -- ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: Convert more trace events to DEFINE_EVENT
On Tue, 25 May 2010 16:08:46 -0400, Steven Rostedt rost...@goodmis.org wrote: On Mon, 2010-05-24 at 16:25 +0800, Li Zefan wrote: Convert i915_gem_object_clflush to DEFINE_EVENT, and save ~0.5K: textdata bss dec hex filename 132042732 12 159483e4c i915_trace_points.o.orig 126682732 12 154123c34 i915_trace_points.o No change in functionality. Acked-by: Steven Rostedt rost...@goodmis.org I'm expecting that this will be going through the DRM/i915 path. Yeah. pgpr9dkakX7pu.pgp Description: PGP signature -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: Convert more trace events to DEFINE_EVENT
On Mon, 24 May 2010 16:25:44 +0800, Li Zefan l...@cn.fujitsu.com wrote: Convert i915_gem_object_clflush to DEFINE_EVENT, and save ~0.5K: textdata bss dec hex filename 132042732 12 159483e4c i915_trace_points.o.orig 126682732 12 154123c34 i915_trace_points.o No change in functionality. Applied. Thanks! pgpdPz43INJQn.pgp Description: PGP signature -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [2.6.34, patch] i915: fix lock imbalance on error path...
On Mon, 17 May 2010 14:23:52 +0100, Daniel J Blueman daniel.blue...@gmail.com wrote: While investigating Intel i5 Arrandale GPU lockups with -rc4, I noticed a lock imbalance. Signed-off-by: Daniel J Blueman daniel.blue...@gmail.com Applied. Thanks! pgpNMR7N8gNTc.pgp Description: PGP signature -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch -next] i915/intel_sdvo: remove unneeded null check
On Fri, 7 May 2010 10:40:09 +0200, Dan Carpenter erro...@gmail.com wrote: The connector variable is used as the cursor in a list_for_each_entry() and it's always non-null so we don't need to check it. Applied. Thanks! pgp5LjYtrnRQc.pgp Description: PGP signature -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch -next] i915: remove unneeded null checks
On Fri, 7 May 2010 10:39:00 +0200, Dan Carpenter erro...@gmail.com wrote: The encoder variable can never be null because it is used as loop cursor in a list_for_each_entry() loop. Signed-off-by: Dan Carpenter erro...@gmail.com Applied. Thanks! pgp2b3chFIrqj.pgp Description: PGP signature -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch] i915: missing unlock on error path
On Fri, 7 May 2010 10:37:01 +0200, Dan Carpenter erro...@gmail.com wrote:
There was a missing mutex_unlock(dev-struct_mutex) on this error path.
Signed-off-by: Dan Carpenter erro...@gmail.com
---
I thought Jiri sent this patch earlier but a google search for stanse
struct_mutex i965_reset didn't find any patches, so I'm resending.
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 01e91ea..a605c87 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -369,6 +369,7 @@ int i965_reset(struct drm_device *dev, u8 flags)
}
} else {
DRM_ERROR(Error occurred. Don't know how to reset this
chip.\n);
+ mutex_unlock(dev-struct_mutex);
return -ENODEV;
}
Heh, got another version of this patch from Daniel J Blueman and ended
up applying his first as I went through my tag:todo list. Thanks,
though!
pgp1pGw2tcBi3.pgp
Description: PGP signature
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/6] make gem_object embedable and convert i915 driver
On Tue, 13 Apr 2010 15:33:05 +1000, Dave Airlie airl...@gmail.com wrote: On Tue, Apr 13, 2010 at 5:19 AM, Daniel Vetter dan...@ffwll.ch wrote: On Mon, Apr 12, 2010 at 10:51:20AM -0700, Eric Anholt wrote: On Fri, 9 Apr 2010 21:05:03 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: Daniel Vetter (6): drm: extract drm_gem_object_init drm: free core gem object from driver callbacks drm/i915: introduce i915_gem_alloc_object drm/i915: embed the gem object into drm_i915_gem_object drm/i915: don't use -driver_private anymore drm/i915: drop pointer to drm_gem_object I like this series. Dave, should I pull this one? Cool. wrt merging I'd prefer if Dave could take the first two via drm-core. That way round I could start working on the radeon/nouveau stuff independently of the i915 stuff. That'd stall i915 slightly but i915 is the easiest conversion (that's why I did it first) so I can quickly rebase in case of conflicts I'll take these via my tree, Eric just let me know if I can assume your ack on the i915 ones and even the main one. I'll try and review them over the next couple of days. OK. And if you felt like pulling my -next at the same time, that would be awesome as then I can continue merging there based off of this series. pgp1oPEWW5lt0.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/6] make gem_object embedable and convert i915 driver
On Fri, 9 Apr 2010 21:05:03 +0200, Daniel Vetter daniel.vet...@ffwll.ch wrote: Hi all, As promised here's my patch series to make struct drm_gem_object embedable. Also converts drm/i915 as a proof of concept. I've already looked at the radeon and nouveau modules and a straightforward replament of the gem_object pointer looks simple. But I think embedding it into the ttm_bo is better long-term. Stuff like duplicated ref-counting between the ttm object and the gem one just doesn't make too much sense. Tested on my i945GM. The changes to radeon and nouveau in patch 2 are only compile-tested, but the identical change to the i915 survived testing. Comments on the patches and my future plans highly welcome. Yours, Daniel Daniel Vetter (6): drm: extract drm_gem_object_init drm: free core gem object from driver callbacks drm/i915: introduce i915_gem_alloc_object drm/i915: embed the gem object into drm_i915_gem_object drm/i915: don't use -driver_private anymore drm/i915: drop pointer to drm_gem_object I like this series. Dave, should I pull this one? pgpw0NlC2uib8.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] i915: do not read uninitialized -dev_private
On Thu, 8 Apr 2010 21:41:59 +0200, Luca Tettamanti kronos...@gmail.com wrote: -dev_private at that point is NULL and is initialied only a few lines later. Signed-off-by: Luca Tettamanti kronos...@gmail.com --- I'm beginnig to dive into DRMKMS, that assignment really confused me :P Applied. Thanks! pgppXukviO6Hj.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: Add no_lvds entry for the Clientron U800
On Mon, 29 Mar 2010 17:53:12 +0200, Stefan Bader stefan.ba...@canonical.com wrote: Hi Eric, I am not sure, this could be a duplicate. But I had the feeling that somehow the patch might have gotten lost to some miscommunication. So I re-send it now. If you already have it on your queue, please feel free to ignore. Thanks, I'd lost track of this one. Applied. pgpz8fdzhyUOx.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: Add Sony VGN-BZ12VN to ACPI LID quirk list
On Fri, 19 Mar 2010 16:30:48 +0100, Hubert Hesse li...@hubertscorner.de wrote: Hi there, I'm referring to my Bugreport 15473. I wanted to use KMS with the latest kernel on my Sony VGN-BZ12VN. Similiar to Bug 14649 and 14554 `cat /proc/acpi/button/lid/LID0/state` always reports state: closed to me. A blank screen is the result for me, when booting with KMS enabled. I figured out to add my Laptop to the ACPI LID quirk list. Sorry for the double post. Its the first time I hand in a patch. In place of more quirk patches, I've pushed the patch removing the use of ACPI LID status for LVDS detection. pgpZauflOtVe6.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 3/3] Install headers to $(includedir)/libdrm
On Fri, 26 Feb 2010 19:07:24 +0100, Julien Cristau jcris...@debian.org wrote: Avoids conflicts with kernel headers. Signed-off-by: Julien Cristau jcris...@debian.org Applied this series, plus moving the intel file. Thanks! pgp9aozTfnYtg.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch] i915: fix small leak on error path
On Sat, 6 Mar 2010 12:50:54 +0100, Daniel Vetter dan...@ffwll.ch wrote: Oh, dang. Thanks for catching this. Eric, please merge. Cc: sta...@kernel.org (for .33) Reviewed-by: Daniel Vetter dan...@ffwll.ch On Sat, Mar 06, 2010 at 02:05:39PM +0300, Dan Carpenter wrote: We should free params before returning. Signed-off-by: Dan Carpenter erro...@gmail.com Applied. Thanks! pgpeRvdLq2cWd.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: Convert some trace events to DEFINE_TRACE
On Thu, 11 Mar 2010 16:41:45 +0800, Li Zefan l...@cn.fujitsu.com wrote:
Use DECLARE_EVENT_CLASS to remove duplicate code:
textdata bss dec hex filename
146552732 15 1740243fa i915_trace_points.o.orig
116252732 10 14367381f i915_trace_points.o
8 events are converted:
i915_gem_object: i915_gem_object_{unbind, destroy}
i915_gem_request: i915_gem_request_{complete, retire, wait_begin, wait_end}
i915_ring:i915_ring_{wait_begin, wait_end}
No functional change.
Applied to -next. Thanks!
pgp7RE1XbJgQv.pgp
Description: PGP signature
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] libdrm: Move intel_atomic.h to libdrm core for sharing.
On Wed, 10 Mar 2010 18:20:42 +0200, Pauli Nieminen suok...@gmail.com wrote: intel_atomic.h includes very usefull atomic operations for lock free parrallel access of variables. Moving these to core libdrm for code sharing with radeon. s/xf86/libdrm/ but other than that, cool. pgp9PLwqTrOT9.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Fri, 5 Mar 2010 12:21:29 +, Alan Cox a...@lxorguk.ukuu.org.uk wrote: Serious discussion point perhaps should be: is the libdrm so close to the kernel it ought to be in the same git tree ? Alternatively does it need to be easier to have multiple Nouveau libdrms autoselected according to the kernel side versioning. ELF library versioning is not rocket science and both the old and new libraries exist and can be installed so all the bits are present except for the wrapper to load the right sublibrary yes ? That *would* make versioning impossible. To make the difficulty of improving ABI at the moment concrete, I just got done merging the patches for execbuf2 in userland and enabling i915 texture tiling. This was a 3% performance win in one test I was looking at, and 1% in another -- less than hoped, but important nonetheless (there are other cases that should see 30% or so wins hopefully). The patches got written back in July, and revved several times as they broke various combinations of compatibility. At the point that I merged eb2 to the kernel for 2.6.33, it wasn't *really* tested -- the userland side was broken all to hell it looked like, but at least it wasn't regressing execbuf1 any more, right? I spent this week getting userland working, including a new libdrm release (already obsolete because a bug in the libdrm violated what the ABI between libdrm - msea was supposed to be). So overall, I'd say that we spent about a month of developer time at least between jbarnes, ickle, and myself, on extending the execbuf interface to add a flag saying dear kernel, please don't do this bit of work on this buffer, because I don't need it and it makes things slow. This is not that bad for Intel folks. We're paid to hack on it, and can justify spending ridiculous amounts of time for small wins. I actually enjoy this. Right now all the userland -- whether it's Mesa, xf86-video-intel, libva, cairo-drm, stand-alone DRM testcases, etc., gets to move to the new libdrm API, declare its dependency in PKG_CHECK_MODULES, and hand that new flag to libdrm as if the kernel supported the new interface. Inside libdrm, it looks at the kernel version and uses the new interface or old as appropriate. The ugly versioning stuff stays in one easy-to-review 5kloc component, and the complicated 50kloc driver components get to pretend they have a fancy new kernel. But if libdrm's in the kernel, all those userland components no longer get to rely on the version of libdrm, because distros will ship whatever's with the kernel they're using and our userland does have to work on (relatively recent) distros. Each of those userland components would have to grow a compatibility layer to work with whatever kernel libdrm is available, passing the flag in the new API or using the old API. Userland would even buggier for having to replicate all that logic everywhere, and we probably wouldn't have execbuf2 landed yet. Well, OK. What I'd really do instead is make the kernel libdrm be a thin ioctl wrapper, and build a librealdrm that does what libdrm does today. But I don't think that's what you were suggesting. pgp21kB5PwxVU.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] Move lists to freedesktop.org?
On Thu, 4 Mar 2010 12:37:23 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: Would anyone have objections if these lists moved to freedesktop.org? The recent thread with Linus about the drm pull request highlights the post lag and non-subscriber aspect of the current lists, and that leaves aside sf.net's horrible mail archive interface and poor performance. If spam is an issue, another option would be vger.kernel.org. That team runs lkml and several other very high traffic, high profile lists and manages quite well; performance is always high and spam is nearly non-existent given the amount of traffic. sf.net's mail interface is made of fail. Here's to changing to something credible. pgpV6TjtQUMox.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[ANNOUNCE] libdrm 2.4.19
New version for new Intel API that we're about to start using in Mesa. Eric Anholt (8): intel: Add initial support for Sandybridge, and clean up the #defines. intel: Use an integer for chipset generation instead of many conditionals. intel: add a comment about tiled buffer alloc height alignment from Mesa. intel: Fix typo in conversion from IS_GEN to bufmgr_gem-gen. intel: Don't tile-align pitch for untiled buffers. intel: Don't enable execbuf2 fenced relocs unless we have execbuf2. intel: Update the needs_fence flag of buffers on the validate list. Increment version to 2.4.19 for release. Francisco Jerez (1): nouveau: Update nouveau_class.h. Jakob Bornecrantz (4): vmwgfx: Update kernel header libkms: Add missing include file to libkms source libkms: Enable by default libkms: Use a standard version number Jesse Barnes (1): libdrm/intel: execbuf2 support Maarten Maathuis (1): nouveau: make sure initial kalloc for user bo ends up in the right place Marcin Kościelnicki (6): Add config.h macro HAVE_NOUVEAU libkms/intel: Throw out unused intel_bo fields. libkms/nouveau: Add support tests: Add nouveau to list of supported modules. tests: vrefresh is actually not * 1000. tests/modetest: Don't get_props on a connector after freeing it. Marek Olšák (1): radeon: add square-tiling flag Patrice Mandin (2): nv30: update for front/back stencil inversion nv30: update for 8 texture units git tag: 2.4.19 http://dri.freedesktop.org/libdrm/libdrm-2.4.19.tar.bz2 MD5: c2699b5d8ebc9e47fb56da15f460107f libdrm-2.4.19.tar.bz2 SHA1: fc6a7ae552d8f2000962bf833d72e286781081c9 libdrm-2.4.19.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.19.tar.gz MD5: 58829058201ce526d137d36f8bf7bcde libdrm-2.4.19.tar.gz SHA1: 0283c976054c0d954e2bf69c5edaf614ae2cdf00 libdrm-2.4.19.tar.gz pgpFXIcLupJqk.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: blacklist lid status: Sony VGN-BX196VP, Dell Inspiron 700m
On Tue, 2 Mar 2010 22:59:52 +0200, Surbhi Palande surbhi.pala...@canonical.com wrote: BugLink: https://bugs.launchpad.net/bugs/515246 Sony VGN-BX196VP and Dell Inspiron 700m report lid status as closed when it is open. This leads to a no connectors reported error at startup. Blacklisting them, to always return a connected status for the default lvds connector. Signed-off-by: Surbhi Palande surbhi.pala...@canonical.com As far as I know, this should already be covered by: commit 7b9c5abee98c54f85bcc04bd4d7ec8d5094c73f4 Author: Jesse Barnes jbar...@virtuousgeek.org Date: Fri Feb 12 09:30:00 2010 -0800 drm/i915: give up on 8xx lid status pgpNe85gsm2Yr.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] agpgart: Reprobe VGA devices when a new GART device is added
On Mon, 1 Mar 2010 18:33:14 +1000, Dave Airlie airl...@gmail.com wrote: On Sun, Feb 28, 2010 at 1:30 PM, Ben Hutchings b...@decadent.org.uk wrote: This addresses http://bugzilla.kernel.org/show_bug.cgi?id=15021. DRM drivers may fail to probe their devices when the associated AGP GART does not yet have a driver, so we reprobe unbound VGA devices when a GART device is added. Signed-off-by: Ben Hutchings b...@decadent.org.uk --- This is intended to address the dependency problem highlighted in the above bug report. That specific bug can be fixed by adding a module dependency from i915 to intel_agp, but in general there is no fixed relationship betweem DRM and GART drivers. There is a narrow race between the check for a current driver binding and the call to device_reprobe(). This could be closed by adding a variant on device_attach() and device_reprobe() that is a no-op for bound devices. This isn't useful, generally there is no AGP binding, and most drivers if they can't find an AGP backend will still run fine without it. i.e. radeon, mga etc. Intel is a special case and I think we've already merged an explicit depend. Just build agp drivers into the kernel, I'm tempted to make them all non-modular. That seems easier. pgptHyNIRQvRo.pgp Description: PGP signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] drm: introduce drm_gem_object_[handle_]unreference_unlocked
On Tue, 9 Feb 2010 06:49:11 +0100, Luca Barbieri l...@luca-barbieri.com wrote: This patch introduces the drm_gem_object_unreference_unlocked and drm_gem_object_handle_unreference_unlocked functions that do not require holding struct_mutex. drm_gem_object_unreference_unlocked calls the new -gem_free_object_unlocked entry point if available, and otherwise just takes struct_mutex and just calls -gem_free_object With the exception of adding a new unused API in the form of gem_free_object_unlocked driver hook, I like this. pgpWTX0zXEDW7.pgp Description: PGP signature -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] i915 / PM: Fix crash while aborting hibernation (Re: [linux-pm] [regression] drm/i915: implement new pm ops disables irq on aborted s2disk)
On Sun, 7 Feb 2010 21:48:24 +0100, Rafael J. Wysocki r...@sisk.pl wrote: On Thursday 04 February 2010, Zhenyu Wang wrote: On 2010.02.03 23:44:41 +0100, Rafael J. Wysocki wrote: On Wednesday 03 February 2010, Alan Jenkins wrote: Hi I found this regression on my EeePC 701 with modesetting enabled. When I hibernate using s2disk, I can abort the hibernation by pressing the backspace key. Doing so breaks X on 2.6.32-rc6 (but not 2.6.32). Yeah. To be honest, I knew that's going to happen, but didn't have the time to take care of it. The problem is that i915 does literally _nothing_ in its .thaw() callback, although it should at least reverse whatever .freeze() did to the hardware (and memory allocations and so on), so that the adapter is functional after creating the image. Fixing this requires some thought, though, because at the moment .freeze() thinks it's .suspend(), which is not the case as this report clearly shows. So, in fact i915_pci_suspend() has to be split into the .freeze() part and the poweroff part cleanly and that's not so simple (at least to me). Right, I think that'll be more clean, stuff in i915_save/restore_state() need to be splited too, especially isolate stuff for mode setting and other device state, as what my original purpose for this is to remove extra mode setting cycle in old behavior so not waste time for hibernate. We can't really do that, because we'll need to restore the saved state at the resume-from-hibernation stage. The appended patch fixes the issue for me, although it's been only tested a little. It sort of defeats the purpose of commit cbda12d77ea590082edb6d30bd342a67ebc459e0, but I don't see any less invasive way to fix this except maybe for reverting that commit entirely. Note that the drm_irq_[un]install() thing may be unnecessary, but I wasn't sure about that and surely wouldn't suggest doing that for 2.6.33. Also it looks like some things from the freeze and thaw parts may be moved to the low-level suspend and resume parts, respectively, but that would require some i915_gem_* surgery I was too scared to do. Alan, please test, i915 guys, please review. Rafael Applied to for-linus. Thanks! pgpya6h1omM6W.pgp Description: PGP signature -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] drm: switch all GEM/KMS ioctls to unlocked ioctl status.
On Thu, 4 Feb 2010 06:29:05 +1000, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com These ioctls are all protected by their own locking mechanisms so should be fine to not bother locking around. Seems good to me. At some point we should just push it down and not have the flag. pgpLytlFSpEfP.pgp Description: PGP signature -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] PM / i915: Skip kernel VT switch during suspend/resume if KMS is used
On Sun, 24 Jan 2010 00:55:59 +0100, Rafael J. Wysocki r...@sisk.pl wrote: From: Rafael J. Wysocki r...@sisk.pl If a non-KMS graphics driver is used, the kernel carries out a VT switch during suspend/resume to avoid possible problems with freezing X at a wrong time and to cause X to repaint everything after resume. This is not necessary any more if the KMS is used, so skip the kernel VT switch during suspend/resume for i915 in the KMS mode. Signed-off-by: Rafael J. Wysocki r...@sisk.pl --- Hi, I've been testing this patch for over a week and haven't seen a single problem related to it during this time. Are there any objections to it? Rafael Love it! Acked-by: Eric Anholt e...@anholt.net pgpY82WmwZfgh.pgp Description: PGP signature -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: Don't spam dmesg whenver a video mode is changed.
Not only are video mode changes normal events that probably don't deserve note in dmesg in general, drivers may also set video modes for output detection, leading to users being confused as to why their TV output is being turned on when they don't have one on their system. Signed-off-by: Eric Anholt e...@anholt.net --- drivers/gpu/drm/drm_crtc_helper.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index 4231d6d..35e8523 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -702,8 +702,9 @@ bool drm_crtc_helper_set_mode(struct drm_crtc *crtc, if (encoder-crtc != crtc) continue; - DRM_INFO(%s: set mode %s %x\n, drm_get_encoder_name(encoder), -mode-name, mode-base.id); + DRM_DEBUG_KMS(%s: set mode %s %x\n, + drm_get_encoder_name(encoder), + mode-name, mode-base.id); encoder_funcs = encoder-helper_private; encoder_funcs-mode_set(encoder, mode, adjusted_mode); } -- 1.6.5.7 -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/2] drm/i915: enable 36bit physical address for hardware status page
On Tue, 5 Jan 2010 11:25:06 +0800, Zhenyu Wang zhen...@linux.intel.com wrote: This enables possible 36bit address mask on 965G that use physical address for hw status page. Signed-off-by: Zhenyu Wang zhen...@linux.intel.com Applied to for-linus. Thanks! My understanding is that with the current 2 patches applied, the other swiotlb stuff in intel-agp is not required. Is that right? pgpZ3RjzqNgUb.pgp Description: PGP signature -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS
On Sat, 9 Jan 2010 00:45:33 +0100, Rafael J. Wysocki r...@sisk.pl wrote: From: Rafael J. Wysocki r...@sisk.pl Commit cbda12d77ea590082edb6d30bd342a67ebc459e0 (drm/i915: implement new pm ops for i915), among other things, removed the .suspend and .resume pointers from the struct drm_driver object in i915_drv.c, which broke resume without KMS on my MSI Wind U100. Fix this by reverting that part of commit cbda12d77ea59. Signed-off-by: Rafael J. Wysocki r...@sisk.pl Applied, with a little comment for the next poor person having to figure out the difference between these two suspend/resume paths. (And yes, I'd love to see the stealth mode die sometime soonish. It's not like attaching intelfb didn't make the user-mode 2D driver fail frequently, so it's not a great feature for us to be maintaining support for. From what I understand most distros blacklisted the intelfb driver anyway.) pgpthYkEjQPOe.pgp Description: PGP signature -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [patch for 2.6.32? 1/3] drivers/gpu/drm/i915/i915_dma.c: fix unused var
On Tue, 17 Nov 2009 14:08:52 -0800, a...@linux-foundation.org wrote: From: Andrew Morton a...@linux-foundation.org drivers/gpu/drm/i915/i915_dma.c: In function 'i915_driver_load': drivers/gpu/drm/i915/i915_dma.c:1114: warning: 'll_base' may be used uninitialized in this function Partly this is because gcc isn't smart enough. But `ll_base' does get used uninitialised in the DRM_DEBUG() call. Cc: Jesse Barnes jbar...@virtuousgeek.org Cc: Eric Anholt e...@anholt.net Cc: Dave Airlie airl...@linux.ie Signed-off-by: Andrew Morton a...@linux-foundation.org Applied. thanks! pgpNDghQt7z80.pgp Description: PGP signature -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] Failure with swiotlb
On Mon, 4 Jan 2010 17:27:45 +0800, Zhenyu Wang zhen...@linux.intel.com wrote: On 2009.12.31 12:33:06 +0800, Zhenyu Wang wrote: On 2009.12.30 10:26:27 +, David Woodhouse wrote: On Wed, 2009-12-30 at 11:02 +0800, Zhenyu Wang wrote: We have .31-.32 regression as reported in http://bugs.freedesktop.org/show_bug.cgi?id=25690 http://bugzilla.kernel.org/show_bug.cgi?id=14627 It's triggered on non VT-d machine (or machine that should have VT-d, but no way to turn it on in BIOS.) and with large memory, and swiotlb is used for PCI dma ops. swiotlb uses a bounce buffer to copy between CPU pages and real pages made for DMA, but we can't make it real coherent as we don't call pci_dma_sync_single_for_cpu() alike APIs. And in GEM domain change, we also can't flush pages for bounce buffer. It looks like our usual non-cache-coherent graphics device can't love swiotlb. This patch trys to only handle pci dma mapping in case of real iommu hardware detected, the only case for that is VT-d. And fallback to origin method to insert physical page directly in other case. This fixes the GPU hang on our Q965 with 8G memory in 64-bit OS. Comments? I don't understand. Why is swiotlb doing anything here anyway, when the device has a dma_mask of 36 bits? Shouldn't dma_capable() return 1, causing swiotlb_map_page() to return the original address unmangled? Good point, I didn't look into swiotlb code, coz my debug showed it returned mangled dma address. So looks the real problem is 36 bit dma mask got corrupted somehow, which matches first report in fd.o bug 25690. Looks we should setup dma mask in drm/i915 driver too, as they both operate on graphics device. But I can't test that on our 8G mem machine until after new year. Finally caught it! It's within drm_pci_alloc() which will try to setup dma mask for pci_dev again! That is used for physical address based hardware status page for 965G (i915_init_phys_hws()), as alloc with pci coherent interface. But trying to set mask again in an alloc function looks wrong to me, and driver should setup their own consistent dma mask according to hw. So following patch trys to remove mask setting in drm_pci_alloc(), which fixed the origin problem as dma mask now has the right 36bit setting on intel hw. I can't test if ati bits looks correct, Dave? As intel hws page does support 36bit physical address, that will be another patch for setup pci consistent 36bit mask for it. Any comment? Looks like this patch doesn't set the dma mask that used to get set for the drivers that were relying on it. Once all the drivers are fixed to set it up at load time, this seems like a good interface fix. pgppxP7AwQftl.pgp Description: PGP signature -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: Storage class should be before const qualifier
On Wed, 23 Dec 2009 14:14:34 +0100, Tobias Klauser tklau...@distanz.ch wrote:
The C99 specification states in section 6.11.5:
The placement of a storage-class specifier other than at the beginning
of the declaration specifiers in a declaration is an obsolescent
feature.
Signed-off-by: Tobias Klauser tklau...@distanz.ch
---
drivers/gpu/drm/i915/intel_display.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 52cd9b0..2256ac7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2448,7 +2448,7 @@ static void pineview_enable_cxsr(struct drm_device
*dev, unsigned long clock,
* A value of 5us seems to be a good balance; safe for very low end
* platforms but not overly aggressive on lower latency configs.
*/
-const static int latency_ns = 5000;
+static const int latency_ns = 5000;
static int i9xx_get_fifo_size(struct drm_device *dev, int plane)
{
@@ -2559,7 +2559,7 @@ static void g4x_update_wm(struct drm_device *dev, int
planea_clock,
/* Calc sr entries for one plane configs */
if (sr_hdisplay (!planea_clock || !planeb_clock)) {
/* self-refresh has much higher latency */
- const static int sr_latency_ns = 12000;
+ static const int sr_latency_ns = 12000;
sr_clock = planea_clock ? planea_clock : planeb_clock;
line_time_us = ((sr_hdisplay * 1000) / sr_clock);
@@ -2598,7 +2598,7 @@ static void i965_update_wm(struct drm_device *dev, int
planea_clock,
/* Calc sr entries for one plane configs */
if (sr_hdisplay (!planea_clock || !planeb_clock)) {
/* self-refresh has much higher latency */
- const static int sr_latency_ns = 12000;
+ static const int sr_latency_ns = 12000;
sr_clock = planea_clock ? planea_clock : planeb_clock;
line_time_us = ((sr_hdisplay * 1000) / sr_clock);
@@ -2667,7 +2667,7 @@ static void i9xx_update_wm(struct drm_device *dev, int
planea_clock,
if (HAS_FW_BLC(dev) sr_hdisplay
(!planea_clock || !planeb_clock)) {
/* self-refresh has much higher latency */
- const static int sr_latency_ns = 6000;
+ static const int sr_latency_ns = 6000;
sr_clock = planea_clock ? planea_clock : planeb_clock;
line_time_us = ((sr_hdisplay * 1000) / sr_clock);
Applied. Thanks!
pgpm7zOGwV7EE.pgp
Description: PGP signature
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev --
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] i915/crt: Always attempt ddc on both GPIOA and GPIOD
On Tue, 8 Dec 2009 17:24:21 +0100, Helge Bahmann helge.bahm...@secunet.com wrote: The small attached patch fixes a failure to fetch EDID for a newly connected display, when the previously connected display did not provide EDID. Overall I have found that hot-plugging displays with different resolutions at run-time does not work too well with KMS, once a mode gets added to a connector, it apparently never goes away, which means that replacing a display with a smaller one at run-time is problematic. Is there any work in progress to improve that? This patch looks good. However, patches to the Linux kernel require a Signed-off-by indicating your acceptance of the Developer's Certificate of Origin, described in linux-2.6/Documentation/SubmittingPatches. Could you resend with that? pgpdKXUuo7wQM.pgp Description: PGP signature -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/intel: refactor DP i2c support and DP common header to drm helper
On Fri, 4 Dec 2009 11:08:00 +1000, Dave Airlie airl...@gmail.com wrote: From: Dave Airlie airl...@redhat.com Both radeon and nouveau can re-use this code so move it up a level so they can. However the hw interfaces for aux ch are different enough that the code to translate from mode, address, bytes to actual hw interfaces isn't generic, so move that code into the Intel driver. Sounds like a good plan to me. The patch is all conflicty, though. Care to pull my tree and apply an updated version just after you do so? Acked-by: Eric Anholt e...@anholt.net pgpESYIeTGych.pgp Description: PGP signature -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Disable all the possibles output/crtcs before entering KMS mode
On Fri, 4 Dec 2009 23:22:51 +0100, Rafał Miłecki zaj...@gmail.com wrote: 2009/12/4 Dave Airlie airl...@redhat.com: On Fri, 2009-12-04 at 20:05 +0800, yakui.z...@intel.com wrote: From: Zhao Yakui yakui.z...@intel.com Disable all the possible outputs/crtcs before entering KMS mode. We need a bit more info than this for such a large change? At one point we wanted to do smooth startup for LVDS panels, so that we read back the mode and avoided reconfiguring them this sort of change would totally go against it. Also I thought Arjan wanted to avoid slowdowns on startup, which I would expect this to add to. We have something like drm_disable_unused_functions. Isn't that supposed to make what you introduce there? At least at KMS booting when we don't have encoders/crtcs/outputs configured it should work for that. Am I wrong? Yeah, drm_helper_disable_unused_functions with everything set to disconnected should do this. And if we want to get flicker-free transitions, then we could read out current state for some outputs and set our current state accordingly before calling that. It's something I've wanted to do since the original UMS work. But it is true that if we aren't reading current state out, we do need to turn everything off before modesetting. The clocks can get very angry at you otherwise, and you get things worse than a flicker at boot. (So, my review of this patch is: close, but just use drm_helper_disable_unused_functions instead of making a new function) pgpyjh6Th0l7V.pgp Description: PGP signature -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] drm/i915: add GETPARAM request for page flipping
On Thu, 19 Nov 2009 10:49:07 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: From 3dea813806ecc117fadd2751580018040afefd0b Mon Sep 17 00:00:00 2001 From: Jesse Barnes jbar...@virtuousgeek.org Date: Wed, 18 Nov 2009 04:31:47 + Subject: [PATCH 1/2] drm/i915: add GETPARAM request for page flipping Add a GETPARAM request for checking if page flipping is supported. Useful for the 2D driver to enable the flipping path. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org OK, I've applied this series in what I'm guessing was the desired order: 1) pageflipping support 2) core fixup 3) getparam to say it's ready Also, something seems wonky with your patches. The git am gives me: anh...@gaiman:anholt/src/linux-2.6% git log commit b0f57d0ff95c957b278d7a82d9ebdea395652cfa Author: Jesse Barnes jbar...@virtuousgeek.org Date: Thu Nov 19 10:49:07 2009 -0800 drm/i915: add GETPARAM request for page flipping From 3dea813806ecc117fadd2751580018040afefd0b Mon Sep 17 00:00:00 2001 From: Jesse Barnes jbar...@virtuousgeek.org Date: Wed, 18 Nov 2009 04:31:47 + Subject: [PATCH 1/2] drm/i915: add GETPARAM request for page flipping Add a GETPARAM request for checking if page flipping is supported. Useful for the 2D driver to enable the flipping path. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Signed-off-by: Eric Anholt e...@anholt.net Are you not using git send-email? -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Fix sync to vblank when VGA output is turned off
On Mon, 09 Nov 2009 12:51:22 +0800, Li Peng peng...@linux.intel.com wrote: In current vblank-wait implementation, if we turn off VGA output, drm_wait_vblank will still wait on the disabled pipe until timeout, because vblank on the pipe is assumed be enabled. This would cause slow system response on some system such as moblin. This patch resolve the issue by adding a drm helper function drm_vblank_off which explicitly clear vblank_enabled[crtc], wake up any waiting queue and save last vblank counter before turning off crtc. It also slightly change drm_vblank_get to ensure that we will will return immediately if trying to wait on a disabled pipe. Signed-off-by: Li Peng peng...@intel.com Applied. Thanks! -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BUG][BISECTED][RESENT] Ogre3d produces black screen on Intel 965GM
On Wed, 25 Nov 2009 22:38:30 +0100, Dariush Forouher dari...@forouher.de wrote: Hi everyone, applications using the ogre3d library (www.ogre3d.org) only show black screens instead of fancy 3D graphics on current 2.6.32-rc8. On 2.6.31 they worked fine. In the error case the kernel reports errors like this: [drm:i915_gem_object_pin_and_relocate] *ERROR* Relocation beyond target object bounds: obj 8800d74c3b40 target 91 delta 4096 size 4096. [...] I bisected it down to the following commit: commit cd0b9fb400ba775737bdc3874c4cbee4047e66d8 Author: Chris Wilson ch...@chris-wilson.co.uk Date: Tue Sep 15 23:23:18 2009 +0100 drm/i915: Check that the relocation points to within the target [...] Reverting the commit manually makes the problem disappear. cheers Dariush Platform: AMD64 Distro: Debian testing GPU: Intel 965GM xserver: 1.6.5 xorg-intel: 2.9.0 libdrm: 2.4.14 OGRE: 1.6.4 You didn't mention the most important software version for 3D issues: that of Mesa. There were bugs there that this safety check caught. commit a82da7fa263c7fb6b902285994136890e6dc3278 Author: Eric Anholt e...@anholt.net Date: Sun Oct 11 11:04:09 2009 -0700 i965: Fix the bounds emitted in the vertex buffer packets. It's the address of the last valid byte, not the address of the first invalid byte. This should also fix problems with rendering with the new sanity checks in the kernel. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 23:40 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 23:33, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. Okay, well in any case nothing in what you mentioned prevents the libdrm from living with the kernel. We could keep the compat stuff here, and we still have the advantages I mentioned. So is there any other reason for not putting it with the kernel? So you're saying that people building their distribution on 2.6.29 would have to pull down linux-2.6 from master to build and install libdrm? People with old kernels can pick an old libdrm from some place else in the meantime.People with 2.6.32 don't have to grab anything more as libdrm came with their kernel already. I don't care about the transition. I care about the long term. Replace 2.6.32 and 2.6.29 with 2.6.43 and 2.6.40. Where does the 2.6.40 user get his libdrm at that time? And how do I get releases of libdrm out outside of kernel releases? We're doing libdrms at least twice a kernel cycle, because we've got stable fixes to push out/new interfaces to start relying on faster than every 3 months. This is all seeming like a huge pain to avoid cp. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. This is why I've also argued against having libdrm not install the ioctl headers. It seems like the argument is mostly that having libdrm keep a copy of the kernel headers in the repo is bad because people might cp the file wrong. If the cost of not keeping them in the repo is having the libdrm and its consumers be ifdef hell, I will keep a cp in the repo. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. Okay, well in any case nothing in what you mentioned prevents the libdrm from living with the kernel. We could keep the compat stuff here, and we still have the advantages I mentioned. So is there any other reason for not putting it with the kernel? So you're saying that people building their distribution on 2.6.29 would have to pull down linux-2.6 from master to build and install libdrm? -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] DRI2 synchronization and swap bits
On Fri, 2009-10-30 at 10:59 -0700, Jesse Barnes wrote: I've put up some trees (after learning my lesson about working in the main tree) with the latest DRI2 sync/swap bits: git://git.freedesktop.org/home/jbarnes/xserver master branch git://git.freedesktop.org/home/jbarnes/mesa master branch They includes support for some new DRI2 requests (proto for which is in the dri2-swapbuffers branch of dri2proto), including: DRI2SwapBuffers DRI2GetMSC DRI2WaitMSC and DRI2WaitSBC These allow us to support GLX extensions like SGI_video_sync, OML_swap_control and SGI_swap_interval. There have been a few comments about the protocol so far: 1) DRI2SwapBuffers a) Concern about doing another round trip to fetch new buffers following the swap. I think this is a valid concern, we could potentially respond from the swap with the new buffers, but this would make some memory saving optimizations more difficult (e.g. freeing buffers if no drawing comes in for a short time after the swap). You're doing one round-trip anyway, and if users are concerned about the second one, go use XCB already. (We need to go fix Mesa to do that). -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC Patch] use MTRR for write combining if PAT is not available
On Thu, 2009-10-22 at 17:11 -0700, Suresh Siddha wrote: On Thu, 2009-10-22 at 16:10 -0700, Jesse Barnes wrote: On Thu, 22 Oct 2009 14:47:30 -0700 Suresh Siddha suresh.b.sid...@intel.com wrote: On Thu, 2009-10-22 at 08:34 -0700, Eric Anholt wrote: Can we just not create the _wc sysfs entry if we don't have PAT? I don't think there's userland relying on its presence as opposed to the non-_wc entry. Yes indeed. Jesse do you see an issue with this? This is simple and clean. Thanks Eric. Yeah, I think that will be fine. In fact, older versions of libpciaccess will behave better if we do it that way (iirc it only allocates an MTRR if the resource_wc file doesn't exist or fails to get mapped). Eric, care to send the patch? I don't have a patch, I was just suggesting a way to handle the submitter's problem that won't involve complicated changes that nobody else will be testing since everyone *should* have a graphics driver for their graphics hardware. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: overlay: kill one more unnecessary uninterruptible sleep
On Sun, 2009-10-04 at 15:00 +0200, Daniel Vetter wrote:
I've simply overlooked one case in the conversion to interruptible
sleeps. Rectify this.
Also delete a leftover debug printk.
OK, I'm confused about what this patch is about. I thought you were
going to check if the patch series I applied was the right one or not,
given that it was older than your comment please pull my tree instead
of the patch series I sent out on IRC.
Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch
---
drivers/gpu/drm/i915/intel_overlay.c | 17 +++--
1 files changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index 972d715..f1bf0b0 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -286,16 +286,15 @@ static int intel_overlay_wait_flip(struct intel_overlay
*overlay)
RING_LOCALS;
if (overlay-last_flip_req != 0) {
- ret = i915_do_wait_request(dev, overlay-last_flip_req, 0);
- if (ret != 0)
- return ret;
-
- overlay-last_flip_req = 0;
+ ret = i915_do_wait_request(dev, overlay-last_flip_req, 1);
+ if (ret == 0) {
+ overlay-last_flip_req = 0;
- tmp = I915_READ(ISR);
+ tmp = I915_READ(ISR);
- if (!(tmp I915_OVERLAY_PLANE_FLIP_PENDING_INTERRUPT))
- return 0;
+ if (!(tmp I915_OVERLAY_PLANE_FLIP_PENDING_INTERRUPT))
+ return 0;
+ }
}
/* synchronous slowpath */
@@ -439,8 +438,6 @@ int intel_overlay_recover_from_interrupt(struct
intel_overlay *overlay,
return ret;
case SWITCH_OFF_STAGE_2:
- printk(switch off 2\n);
-
BUG_ON(!overlay-vid_bo);
obj = overlay-vid_bo-obj;
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] i915: Fix i2c init message
On Wed, 2009-09-30 at 14:26 -0600, Tim Gardner wrote:
From 8ef5591fa4392b4228b0be97013a8218f267ef90 Mon Sep 17 00:00:00 2001
From: Tim Gardner tim.gard...@canonical.com
Date: Wed, 30 Sep 2009 14:08:15 -0600
Subject: [PATCH] i915: Fix i2c init message
BugLink: http://bugs.launchpad.net/bugs/409361
This message appears to be informational only.
Less than that, it appears to be debug only. Shall I just whack it to
DRM_DEBUG?
Signed-off-by: Tim Gardner tim.gard...@canonical.com
Cc: sta...@kernel.org
---
drivers/gpu/drm/i915/intel_dp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 2b914d7..d0f950c 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -400,7 +400,7 @@ intel_dp_i2c_init(struct intel_output *intel_output,
const char *name)
{
struct intel_dp_priv *dp_priv = intel_output-dev_priv;
- DRM_ERROR(i2c_init %s\n, name);
+ DRM_INFO(i2c_init %s\n, name);
dp_priv-algo.running = false;
dp_priv-algo.address = 0;
dp_priv-algo.aux_ch = intel_dp_i2c_aux_ch;
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Come build with us! The BlackBerryreg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9#45;12, 2009. Register now#33;
http://p.sf.net/sfu/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 0/8] drmmode overlay support v3
On Tue, 2009-09-15 at 22:57 +0200, Daniel Vetter wrote: Hi all, Latest version of my overlay kms work. I've added the new stuff as separated patches for easier testing in case something blows up. Please review. Thanks, Daniel Daniel Vetter (8): [drm]: make drm_mode_object_find typesafe [drm/i915]: add i915_lp_ring_sync helper [drm/i915]: kill superflous IS_I855 macro [drm/i915] implement drmmode overlay support v4 [drm/i915] fully switch off overlay when not in use [drm/i915] implement fastpath for overlay flip waiting [drm/i915] implement interruptible sleeps in the overlay code [drm/i915] kill i915_lp_ring_sync OK, I've finally pulled this for -next, with a bit of hand resolving of conflicts. I debated, because of the somewhat unusual series of adding the ring sync, implementing, fixing the ring sync use, then removing ring sync. Often, that sort of stuff gets flattened out in the commit history. However, in this case I think it's OK as overlays are touchy and bisectability for is the interruptible stuff working correctly may prove useful. Then I noticed that you'd told me that there was newer stuff in your gitorious tree. Only, that stuff claims to be older (v3), and doesn't have some of the patches above. So I've pushed my merge to drm-overlay of my tree for review -- is it what you think should land? drivers/gpu/drm/drm_crtc.c |3 +- drivers/gpu/drm/i915/Makefile|1 + drivers/gpu/drm/i915/i915_dma.c |7 + drivers/gpu/drm/i915/i915_drv.h |8 +- drivers/gpu/drm/i915/i915_gem.c | 37 +- drivers/gpu/drm/i915/i915_reg.h |5 + drivers/gpu/drm/i915/intel_display.c | 45 +- drivers/gpu/drm/i915/intel_drv.h | 39 + drivers/gpu/drm/i915/intel_overlay.c | 1420 ++ include/drm/drm_crtc.h |3 +- include/drm/drm_os_linux.h |2 +- include/drm/i915_drm.h | 71 ++ 12 files changed, 1620 insertions(+), 21 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_overlay.c ___ Intel-gfx mailing list intel-...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Linux 2.6.31-rc7
On Tue, 2009-08-25 at 15:07 -0700, Linus Torvalds wrote: On Tue, 25 Aug 2009, mailing54 wrote: Linus Torvalds schrieb: Are you using the same config? It sounds very much like your -rc7 problems are due to the Intel KMS (kernel mode setting) driver, which I know has had problems on at least Mac Mini's. And I wonder if the -rc6 kernel deb used different config options and didn't enable KMS, for example. Because I don't think anything actually changed in the KMS code itself between rc6 and rc7. Not sure what settings to look for, but this looks like you are completely correct: tob...@tbox:~$ cat /boot/config-2.6.31-020631rc6-generic | grep KMS # CONFIG_DRM_I915_KMS is not set # CONFIG_DRM_RADEON_KMS is not set tob...@tbox:~$ cat /boot/config-2.6.31-020631rc7-generic | grep KMS CONFIG_DRM_I915_KMS=y CONFIG_DRM_RADEON_KMS=y Yeah, so it's i915 kms. You can disable it dynamically at boot time with the i915.modeset=0 kernel command line (or I guess with nomodeset too, for that matter, which should disable both i915 and radeom kms). However, the problem remains that KMS gets the output wrong, in ways that clearly X does not. Eric - it's clearly not just Mac Mini and my experimental machine that have problems, but also a Macbook 2.1. I wonder why the Intel KMS logic doesn't look at which output was driven before it got invoked. Instead, it seems to want to try to detect everything from scratch, even though we should be able to assume that if you boot from BIOS (or EFI, for that matter), the current state of the graphics pipeline is likely meaningful. In my experience, the BIOS setup doesn't reflect what outputs should be used at runtime, and certainly not the correct configuration of the enabled outputs. For example, if we went to this, the giant monitor attached to my laptop that I actually look at would go unused. And clearly distros are trying to enable this. Which means that this is getting way more important to solve. Yes, please open a bug on bugs.freedesktop.org and set severity=critical -- the people working on modesetting should pick it up and take a look at it. For some of the DDC bugs, David Müller has an interesting-looking patch to parse the BIOS's tables describing what DDC pin is used for VGA on 852, though it looks like it should be usable on much more. I was hoping the modesetting guys would review it and ack, but no response so far. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 6/7] KMS: Keep screen pixmap devPrivate.ptr NULL during init and resize
On Fri, 2009-07-10 at 17:14 -0700, Keith Packard wrote:
The frame buffer only has a valid address between prepare_access and
finish_access calls, so remove all other attempts to compute an address from
the driver.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/drmmode_display.c |3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/src/drmmode_display.c b/src/drmmode_display.c
index 7cfdc5b..df10fb5 100644
--- a/src/drmmode_display.c
+++ b/src/drmmode_display.c
@@ -1056,12 +1056,9 @@ drmmode_xf86crtc_resize (ScrnInfoPtr scrn, int width,
int height)
goto fail;
i830_set_pixmap_bo(screen-GetScreenPixmap(screen),
pI830-front_buffer-bo);
- scrn-fbOffset = pI830-front_buffer-offset;
screen-ModifyPixmapHeader(screen-GetScreenPixmap(screen),
width, height, -1, -1, pitch * pI830-cpp,
NULL);
- xf86DrvMsg(scrn-scrnIndex, X_INFO, New front buffer at 0x%lx\n,
-pI830-front_buffer-offset);
for (i = 0; i xf86_config-num_crtc; i++) {
xf86CrtcPtr crtc = xf86_config-crtc[i];
This one and #3 seem to be in disagreement. Perhaps some squashing?
Other than that, it looks fine to me.
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 3/6] i830_bind_memory: Use dri_bo_pin under GEM. Pin when ACCEL_NONE.
On Wed, 2009-07-08 at 13:28 -0700, Keith Packard wrote:
When running GEM, any buffer objects can only be pinned using dri_bo_pin,
they shouldn't be pinned through the GART directly.
Also, when running with KMS but without UXA, make sure frame buffers get
pinned when allocated so that the screen pixmap can be set at that time.
Signed-off-by: Keith Packard kei...@keithp.com
---
src/i830_memory.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/i830_memory.c b/src/i830_memory.c
index 7326744..2393689 100644
--- a/src/i830_memory.c
+++ b/src/i830_memory.c
@@ -202,7 +202,10 @@ i830_bind_memory(ScrnInfoPtr pScrn, i830_memory *mem)
if (mem == NULL || mem-bound)
return TRUE;
-if (mem-bo != NULL !pI830-use_drm_mode) {
+if (pI830-have_gem mem-bo != NULL) {
+ if (pI830-use_drm_mode pI830-accel != ACCEL_NONE)
+ return TRUE;
+
Binding pixmaps on behalf of KMS is broken, and the init sequence should
be fixed if that's required :P
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: allow frame buffers up to 4096x4096 on pre-965 chipsets
On Wed, 2009-07-08 at 18:14 -0700, Keith Packard wrote: On Wed, 2009-07-08 at 18:08 -0700, Eric Anholt wrote: The only thing I'm concerned about is proper handling of 3D drawing to that big. What happens? It shouldn't work. We could require (in the X server) that DRI be disabled to allocate a larger frame buffer if you like, but there's no reason kernel space should restrict the size of the scanout area in case someone wants to use the 3D engine. I somehow managed to read this as a 2D patch. 100% agreement for the kernel. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: allow frame buffers up to 4096x4096 on pre-965 chipsets
On Wed, 2009-07-08 at 13:32 -0700, Keith Packard wrote:
The scanout hardware can handle up to this size, so there's no reason to
restrict it to 2048x2048.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 508838e..dcac28d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3149,8 +3149,8 @@ void intel_modeset_init(struct drm_device *dev)
dev-mode_config.max_width = 8192;
dev-mode_config.max_height = 8192;
} else {
- dev-mode_config.max_width = 2048;
- dev-mode_config.max_height = 2048;
+ dev-mode_config.max_width = 4096;
+ dev-mode_config.max_height = 4096;
}
/* set memory base */
The only thing I'm concerned about is proper handling of 3D drawing to
that big. What happens?
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: remove root requirement from DRM_IOCTL_SET_VERSION
On Mon, 2009-06-29 at 16:52 -0700, Jesse Barnes wrote: Just a DRM_MASTER flag is sufficient here, though maybe this call is totally deprecated anyway (xf86-video-intel still calls it though). Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Acked-by: Eric Anholt e...@anholt.net -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: remove root requirement from DRM_IOCTL_SET_VERSION
On Wed, 2009-07-01 at 09:55 -0700, Jesse Barnes wrote: On Tue, 30 Jun 2009 23:43:19 -0700 Eric Anholt e...@anholt.net wrote: On Mon, 2009-06-29 at 16:52 -0700, Jesse Barnes wrote: Just a DRM_MASTER flag is sufficient here, though maybe this call is totally deprecated anyway (xf86-video-intel still calls it though). Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Acked-by: Eric Anholt e...@anholt.net We'll also need to do something about DRM_IOCTL_AUTH_MAGIC... is it safe to make that master only? Agreed with airlied here -- auth_magic just lets other clients it chooses in on the access to the DRM that the master already has access to, so it should be safe. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [i855GME] [Kernel 2.6.30] intel_crt_load_detect() not working?
On Tue, 2009-06-30 at 10:25 +0200, David Müller (ELSOFT AG) wrote: Hello While testing Linux kernel 2.6.30 on a Intel 855GME platform i noticed a 3 minute delay during the Linux boot process in the case DDC support is not available. I've tracked the problem down to the following lines in driver/gpu/drm/i915/intel_crt.c: 289 /* 290 * Wait for the border to be displayed 291 */ 292 while (I915_READ(pipe_dsl_reg) = vactive) 293 ; 294 while ((dsl = I915_READ(pipe_dsl_reg)) = vsample) 295 ; The HW register pointed to by pipe_dsl_reg returns a constant value, resulting in an endless loop at line 294. For me this looks like some parts of the graphic engine is not correctly set up yet, especially as the corresponding code in the Xorg Intel graphics driver mentions that the current pipe's DPLL has to be active for this code to work. Or is this code designed to work in a graphic mode only, but not VGA text mode? My guess is that that pipe was currently off and so waiting for the scanline to move didn't work. There have been bugfixes in load detect since .30, could you try master and see if it's fixed? -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: X server hung, kernel said task blocked for 120 secs (2.6.30)
On Wed, 2009-07-01 at 12:48 -0400, Sanjoy Mahajan wrote: [Have been away for 10 days and just saw the message] I assume this is a regression? Since 2.6.29? I never saw it before using 2.6.30 and haven't been able to reproduce it even running 2.6.30. So it could be a regression. Or it could be a recurring problem (I had a few X lockups with earlier kernels) now exposed by a blocked-task timer (the INFO: task events/0:9 blocked for more than 120 seconds message) -- if that notification code is new in 2.6.30? This message appears when the GPU is hung but somebody is still trying to use it. The problem is that the GPU is hung, not the presence of the message (so you can't use the message to indicate any particular bug, and the bug is almost always in userland). -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: i915: readpix demo regression
On Mon, 2009-06-22 at 14:40 +0200, Michel Dänzer wrote: On Mon, 2009-06-22 at 13:48 +0200, Michel Dänzer wrote: On Sun, 2009-06-21 at 10:30 -0700, Eric Anholt wrote: I was checking on some driver regressions this weekend, and thought that readpixels failure on i915 might have been my fault, but bisect claims it's: dd26899ca39111e0866afed9df94bfb1618dd363 is first bad commit commit dd26899ca39111e0866afed9df94bfb1618dd363 Author: Michel Dänzer daen...@vmware.com Date: Fri Jun 19 23:55:55 2009 +0200 intel: Fixups for 'mesa: create/destroy buffer objects via driver functions'. Initialize all driver function hooks before calling _mesa---_initialize_context(), and handle all buffer objects in intel_buffer_object(). Fixes assertion failure when running glxinfo. :04 04 d2d5b6bc870422b08b9fb5a6d196fb390815cbdf 144a2d92751f48321a44430bfe8c4768eec59a97 Msrc The effect is that the Read/DrawPixels area of the readpix demo is white, and conformance tests all fail. Does the patch below help? Or better this (the test in the last hunk was inverted). BTW, the third image in the readpix demo turns white after pressing 's', regardless of these changes. Worked fine, pushed. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
i915: readpix demo regression
I was checking on some driver regressions this weekend, and thought that readpixels failure on i915 might have been my fault, but bisect claims it's: dd26899ca39111e0866afed9df94bfb1618dd363 is first bad commit commit dd26899ca39111e0866afed9df94bfb1618dd363 Author: Michel Dänzer daen...@vmware.com Date: Fri Jun 19 23:55:55 2009 +0200 intel: Fixups for 'mesa: create/destroy buffer objects via driver functions'. Initialize all driver function hooks before calling _mesa_initialize_context(), and handle all buffer objects in intel_buffer_object(). Fixes assertion failure when running glxinfo. :04 04 d2d5b6bc870422b08b9fb5a6d196fb390815cbdf 144a2d92751f48321a44430bfe8c4768eec59a97 M src The effect is that the Read/DrawPixels area of the readpix demo is white, and conformance tests all fail. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[GIT PULL] drm-malloc branch for merge
The following changes since commit 1d89b30cc9be41af87881682ec82e2c107849dbe: Matthew Wilcox (1): ia64: Fix resource assignment for root busses are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel ..BRANCH.NOT.VERIFIED.. I'm doing this slightly more formally as I've got a big change of my own that affects the DRM in general: Removing the unused malloc debugging. I've threatened it before, and shown the previous iterations of the patch around, but here it finally is for this merge window. Ben Gamari (2): drm/i915: Warn when inteldrmfb fails to restore its framebuffer config drm/i915: A few debugfs formatting fixes Chris Wilson (3): drm/i915: detach/attach get/put pages symmetry drm/i915: Install fence register for tiled scanout on i915 drm/i915: Clear fence register on tiling stride change. Eric Anholt (1): drm: Remove memory debugging infrastructure. drivers/gpu/drm/drm_agpsupport.c| 12 +- drivers/gpu/drm/drm_auth.c |4 +- drivers/gpu/drm/drm_bufs.c | 140 ++- drivers/gpu/drm/drm_context.c |4 +- drivers/gpu/drm/drm_debugfs.c |9 +- drivers/gpu/drm/drm_dma.c | 31 +--- drivers/gpu/drm/drm_drawable.c | 25 +-- drivers/gpu/drm/drm_drv.c | 18 +-- drivers/gpu/drm/drm_fops.c |8 +- drivers/gpu/drm/drm_gem.c |8 +- drivers/gpu/drm/drm_hashtab.c |6 +- drivers/gpu/drm/drm_ioctl.c | 14 +- drivers/gpu/drm/drm_irq.c | 44 ++--- drivers/gpu/drm/drm_memory.c| 25 --- drivers/gpu/drm/drm_pci.c | 53 +- drivers/gpu/drm/drm_proc.c |8 +- drivers/gpu/drm/drm_scatter.c | 33 ++-- drivers/gpu/drm/drm_sman.c | 29 ++-- drivers/gpu/drm/drm_stub.c | 19 +- drivers/gpu/drm/drm_vm.c|8 +- drivers/gpu/drm/i810/i810_dma.c |6 +- drivers/gpu/drm/i830/i830_dma.c |6 +- drivers/gpu/drm/i915/i915_dma.c | 40 ++--- drivers/gpu/drm/i915/i915_drv.h |2 + drivers/gpu/drm/i915/i915_gem.c | 86 ++--- drivers/gpu/drm/i915/i915_gem_debugfs.c |4 +- drivers/gpu/drm/i915/i915_gem_tiling.c | 67 +-- drivers/gpu/drm/i915/i915_mem.c | 24 ++-- drivers/gpu/drm/i915/intel_bios.c |6 +- drivers/gpu/drm/i915/intel_display.c| 20 ++- drivers/gpu/drm/i915/intel_fb.c |6 +- drivers/gpu/drm/i915/intel_tv.c | 11 +- drivers/gpu/drm/mga/mga_dma.c | 14 +- drivers/gpu/drm/r128/r128_cce.c | 12 +- drivers/gpu/drm/r128/r128_state.c | 84 drivers/gpu/drm/radeon/radeon_cp.c |9 +- drivers/gpu/drm/radeon/radeon_i2c.c |6 +- drivers/gpu/drm/radeon/radeon_kms.c |4 +- drivers/gpu/drm/radeon/radeon_mem.c | 24 ++-- drivers/gpu/drm/radeon/radeon_state.c | 16 +- drivers/gpu/drm/savage/savage_bci.c | 21 +-- drivers/gpu/drm/savage/savage_state.c | 17 +- drivers/gpu/drm/sis/sis_drv.c |6 +- drivers/gpu/drm/via/via_map.c |8 +- include/drm/drmP.h | 52 - include/drm/drm_memory_debug.h | 309 --- 46 files changed, 444 insertions(+), 914 deletions(-) delete mode 100644 include/drm/drm_memory_debug.h -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] [Patch] [DRM/I915] :Add a debufs I/F to dump the I915 register
On Tue, 2009-06-09 at 18:46 -0700, Jesse Barnes wrote: On Wed, 10 Jun 2009 09:06:47 +0800 yakui_zhao yakui.z...@intel.com wrote: On Wed, 2009-06-10 at 06:35 +0800, Jesse Barnes wrote: On Tue, 09 Jun 2009 15:16:53 -0700 Eric Anholt e...@anholt.net wrote: On Mon, 2009-06-08 at 08:52 +0800, yakui_zhao wrote: On Fri, 2009-06-05 at 19:11 +0800, Eric Anholt wrote: On Fri, 2009-06-05 at 15:45 +0800, yakui_zhao wrote: It is useful to get the register snapshot. Add a debugfs I/F named i915_reg to dump the I915 register snapshot. And this is created under the dri/0/ of debugfs. The output format is similar to what we have done in UMS mode. I don't think that all the decode and formatting of these registers should be in the kernel. Every time I've had to mess with register decode stuff for investigation, I've needed to extend the decode. Instead, we should expose the raw register values and make intel_reg_dumper in intel-gpu-tools that does the decode of actual meaning. Sometimes we can see the register snapshot without using the intel-gpu-tools. For example: in UMS mode we often get the register snapshot several times in starting X. It will be good that we expose the raw register values and then they are parsed by intel-gpu-tools if we need to extend the decode. How about adding two debugfs I/F? One is to dump the raw register snapshot(without decode and format). Another is what I have done in the patch. No, I won't pull something that puts the decode in the kernel without a really good argument. Expose the register names and values. Yakui, have you experimented with just dumping the whole mmio range? If that works ok we could just make intel-gpu-tools programs to interpret the data in a chipset specific way... It seems that this is a good point. In this patch only the registers related with modesetting are dumped. Is it ok that the whole mmio range is divided into several parts? a. memory interface, instruction and interrupt control registers b. 3d debug registers c. modeset registers(display,pipe, etc). Yeah that would be ok too... At this point, bgamari's patch for debugfs register dumping looks good to me. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] [Patch] [DRM/I915] :Add a debufs I/F to dump the I915 register
On Mon, 2009-06-08 at 08:52 +0800, yakui_zhao wrote: On Fri, 2009-06-05 at 19:11 +0800, Eric Anholt wrote: On Fri, 2009-06-05 at 15:45 +0800, yakui_zhao wrote: It is useful to get the register snapshot. Add a debugfs I/F named i915_reg to dump the I915 register snapshot. And this is created under the dri/0/ of debugfs. The output format is similar to what we have done in UMS mode. I don't think that all the decode and formatting of these registers should be in the kernel. Every time I've had to mess with register decode stuff for investigation, I've needed to extend the decode. Instead, we should expose the raw register values and make intel_reg_dumper in intel-gpu-tools that does the decode of actual meaning. Sometimes we can see the register snapshot without using the intel-gpu-tools. For example: in UMS mode we often get the register snapshot several times in starting X. It will be good that we expose the raw register values and then they are parsed by intel-gpu-tools if we need to extend the decode. How about adding two debugfs I/F? One is to dump the raw register snapshot(without decode and format). Another is what I have done in the patch. No, I won't pull something that puts the decode in the kernel without a really good argument. Expose the register names and values. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] [Patch] [DRM/I915] :Add a debufs I/F to dump the I915 register
On Fri, 2009-06-05 at 15:45 +0800, yakui_zhao wrote: It is useful to get the register snapshot. Add a debugfs I/F named i915_reg to dump the I915 register snapshot. And this is created under the dri/0/ of debugfs. The output format is similar to what we have done in UMS mode. I don't think that all the decode and formatting of these registers should be in the kernel. Every time I've had to mess with register decode stuff for investigation, I've needed to extend the decode. Instead, we should expose the raw register values and make intel_reg_dumper in intel-gpu-tools that does the decode of actual meaning. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 15/17] drm/i915: Use drm_helper_connector_dpms for DisplayPort
On Sat, 2009-05-30 at 20:42 -0700, Keith Packard wrote:
Signed-off-by: Keith Packard kei...@keithp.com
gratuitous move of code in this commit?
---
drivers/gpu/drm/i915/intel_dp.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 56b0119..c9dd28b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -1041,7 +1041,14 @@ static const struct drm_encoder_helper_funcs
intel_dp_helper_funcs = {
.commit = intel_encoder_commit,
};
+static const struct drm_connector_helper_funcs
intel_dp_connector_helper_funcs = {
+ .get_modes = intel_dp_get_modes,
+ .mode_valid = intel_dp_mode_valid,
+ .best_encoder = intel_best_encoder,
+};
+
static const struct drm_connector_funcs intel_dp_connector_funcs = {
+ .dpms = drm_helper_connector_dpms,
.save = intel_dp_save,
.restore = intel_dp_restore,
.detect = intel_dp_detect,
@@ -1049,12 +1056,6 @@ static const struct drm_connector_funcs
intel_dp_connector_funcs = {
.destroy = intel_dp_destroy,
};
-static const struct drm_connector_helper_funcs
intel_dp_connector_helper_funcs = {
- .get_modes = intel_dp_get_modes,
- .mode_valid = intel_dp_mode_valid,
- .best_encoder = intel_best_encoder,
-};
-
static void intel_dp_enc_destroy(struct drm_encoder *encoder)
{
drm_encoder_cleanup(encoder);
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 16/17] drm/i915: Attempt to make DP suspend/resume work a bit more
On Sat, 2009-05-30 at 20:42 -0700, Keith Packard wrote:
Suspend/resume of display port links really wants to just run through the
mode set code so that link training happens.
The commmit doesn't seem to match the commit message here.
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/i915_suspend.c | 56 +-
1 files changed, 41 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/drivers/gpu/drm/i915/i915_suspend.c
index c502913..54516b4 100644
--- a/drivers/gpu/drm/i915/i915_suspend.c
+++ b/drivers/gpu/drm/i915/i915_suspend.c
@@ -409,6 +409,42 @@ int i915_restore_state(struct drm_device *dev)
I915_WRITE(FENCE_REG_945_8 + (i * 4),
dev_priv-saveFENCE[i+8]);
}
+ /* Turn off all outputs */
+ if (IS_MOBILE(dev) !IS_I830(dev))
+ I915_WRITE(LVDS, dev_priv-saveLVDS ~LVDS_ON);
+ I915_WRITE(ADPA, (dev_priv-saveADPA ~ADPA_DAC_ENABLE) |
ADPA_HSYNC_CNTL_DISABLE | ADPA_VSYNC_CNTL_DISABLE);
+
+ if (IS_G4X(dev)) {
+ I915_WRITE(DP_B, dev_priv-saveDP_B ~DP_PORT_EN);
+ I915_WRITE(DP_C, dev_priv-saveDP_C ~DP_PORT_EN);
+ I915_WRITE(DP_D, dev_priv-saveDP_D ~DP_PORT_EN);
+ }
+
+ if (IS_I9XX(dev)) {
+// I915_WRITE(SDVOB, dev_priv-saveSDVOB ~SDVO_ENABLE);
+// I915_WRITE(SDVOC, dev_priv-saveSDVOB ~SDVO_ENABLE);
+ } else {
+ I915_WRITE(DVOA, dev_priv-saveDVOA ~DVO_ENABLE);
+ I915_WRITE(DVOB, dev_priv-saveDVOB ~DVO_ENABLE);
+ I915_WRITE(DVOC, dev_priv-saveDVOC ~DVO_ENABLE);
+ }
+
+//if (IS_I9XX(dev) IS_MOBILE(dev))
+// I915_WRITE(TV_CTL, dev_priv-saveTV_CTL ~TV_ENC_ENABLE);
+
+ I915_WRITE(VGACNTRL, VGA_DISP_DISABLE);
+
+ /* Turn off all planes, pipes and plls */
+ I915_WRITE(DSPACNTR, dev_priv-saveDSPACNTR ~DISPLAY_PLANE_ENABLE);
+ I915_WRITE(DSPBCNTR, dev_priv-saveDSPBCNTR ~DISPLAY_PLANE_ENABLE);
+ msleep(30);
+ I915_WRITE(PIPEACONF, dev_priv-savePIPEACONF ~PIPEACONF_ENABLE);
+ I915_WRITE(PIPEBCONF, dev_priv-savePIPEACONF ~PIPEACONF_ENABLE);
+ msleep(30);
+ I915_WRITE(DPLL_A, dev_priv-saveDPLL_A ~DPLL_VCO_ENABLE);
+ I915_WRITE(DPLL_B, dev_priv-saveDPLL_B ~DPLL_VCO_ENABLE);
+ msleep(30);
+
/* Display port ratios (must be done before clock is set) */
if (IS_G4X(dev)) {
I915_WRITE(PIPEA_GMCH_DATA_M, dev_priv-savePIPEA_GMCH_DATA_M);
@@ -423,11 +459,6 @@ int i915_restore_state(struct drm_device *dev)
/* Pipe plane A info */
/* Prime the clock */
- if (dev_priv-saveDPLL_A DPLL_VCO_ENABLE) {
- I915_WRITE(DPLL_A, dev_priv-saveDPLL_A
-~DPLL_VCO_ENABLE);
- DRM_UDELAY(150);
- }
I915_WRITE(FPA0, dev_priv-saveFPA0);
I915_WRITE(FPA1, dev_priv-saveFPA1);
/* Actually enable it */
@@ -465,11 +496,6 @@ int i915_restore_state(struct drm_device *dev)
I915_WRITE(DSPAADDR, I915_READ(DSPAADDR));
/* Pipe plane B info */
- if (dev_priv-saveDPLL_B DPLL_VCO_ENABLE) {
- I915_WRITE(DPLL_B, dev_priv-saveDPLL_B
-~DPLL_VCO_ENABLE);
- DRM_UDELAY(150);
- }
I915_WRITE(FPB0, dev_priv-saveFPB0);
I915_WRITE(FPB1, dev_priv-saveFPB1);
/* Actually enable it */
@@ -525,11 +551,11 @@ int i915_restore_state(struct drm_device *dev)
I915_WRITE(PP_CONTROL, dev_priv-savePP_CONTROL);
/* Display Port state */
- if (IS_G4X(dev)) {
- I915_WRITE(DP_B, dev_priv-saveDP_B);
- I915_WRITE(DP_C, dev_priv-saveDP_C);
- I915_WRITE(DP_D, dev_priv-saveDP_D);
- }
+// if (IS_G4X(dev)) {
+// I915_WRITE(DP_B, dev_priv-saveDP_B);
+// I915_WRITE(DP_C, dev_priv-saveDP_C);
+// I915_WRITE(DP_D, dev_priv-saveDP_D);
+// }
/* FIXME: restore TV SDVO state */
/* FBC info */
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 17/17] drm/i915: Track DisplayPort DPMS state to retrain on hotplug as needed
On Sat, 2009-05-30 at 20:42 -0700, Keith Packard wrote:
When a DP monitor is plugged back in, it needs to be retrained if it was
active before.
Looks like this should be squashed into #14 that uses it?
Signed-off-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_dp.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index c9dd28b..88a3906 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -47,6 +47,7 @@ struct intel_dp_priv {
uint32_t save_DP;
uint8_t save_link_configuration[DP_LINK_CONFIGURATION_SIZE];
bool has_audio;
+ int dpms_mode;
uint8_t link_bw;
uint8_t lane_count;
uint8_t dpcd[4];
@@ -546,6 +547,7 @@ intel_dp_dpms(struct drm_encoder *encoder, int mode)
if (!(dp_reg DP_PORT_EN))
intel_dp_link_train(intel_output, dp_priv-DP,
dp_priv-link_configuration);
}
+ dp_priv-dpms_mode = mode;
}
/*
@@ -1103,6 +1105,7 @@ intel_dp_init(struct drm_device *dev, int output_reg)
dp_priv-intel_output = intel_output;
dp_priv-output_reg = output_reg;
dp_priv-has_audio = false;
+ dp_priv-dpms_mode = DRM_MODE_DPMS_ON;
intel_output-dev_priv = dp_priv;
drm_encoder_init(dev, intel_output-enc, intel_dp_enc_funcs,
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 08/17] drm/i915: add per-output hotplug callback
On Sat, 2009-05-30 at 20:42 -0700, Keith Packard wrote:
This allows each output to deal with plug/unplug events as needed
(cherry picked from commit 08d57f21d1042153ebc26465be85d7e166008a14)
s-o-b? also, a weird cherry-pick message here.
---
drivers/gpu/drm/i915/i915_irq.c |8
drivers/gpu/drm/i915/intel_drv.h |1 +
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 98bb4c8..43745ff 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -191,7 +191,15 @@ static void i915_hotplug_work_func(struct work_struct
*work)
drm_i915_private_t *dev_priv = container_of(work, drm_i915_private_t,
hotplug_work);
struct drm_device *dev = dev_priv-dev;
+ struct drm_mode_config *mode_config = dev-mode_config;
+ struct drm_connector *connector;
+ list_for_each_entry(connector, mode_config-connector_list, head) {
+ struct intel_output *intel_output = to_intel_output(connector);
+
+ if (intel_output-hot_plug)
+ (*intel_output-hot_plug) (intel_output);
+ }
/* Just fire off a uevent and let userspace tell us what to do */
drm_sysfs_hotplug_event(dev);
}
diff --git a/drivers/gpu/drm/i915/intel_drv.h
b/drivers/gpu/drm/i915/intel_drv.h
index d89a2fe..c585879 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -83,6 +83,7 @@ struct intel_output {
bool load_detect_temp;
bool needs_tv_clock;
void *dev_priv;
+ void (*hot_plug)(struct intel_output *);
};
struct intel_crtc {
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 12/17] drm/i915: Import DisplayPort code
On Sat, 2009-05-30 at 20:42 -0700, Keith Packard wrote: --- drivers/gpu/drm/i915/Makefile|1 + drivers/gpu/drm/i915/i915_drv.h |1 + drivers/gpu/drm/i915/intel_display.c | 11 +- drivers/gpu/drm/i915/intel_dp.c | 967 +- drivers/gpu/drm/i915/intel_dp.h | 11 + drivers/gpu/drm/i915/intel_dp_i2c.c | 244 + drivers/gpu/drm/i915/intel_drv.h |1 + 7 files changed, 874 insertions(+), 362 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_dp_i2c.c Seems like #10 was Import DisplayPort code and this is something else? -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 13/17] drm/i915: Hook up display port
, struct drm_crtc *crtc,
+ int target, int refclk, intel_clock_t *best_clock)
+{
+intel_clock_t clock;
+if (target 20) {
+ clock.dot = 161670;
+ clock.p = 20;
+ clock.p1 = 2;
+ clock.p2 = 10;
+ clock.n = 0x01;
+ clock.m = 97;
+ clock.m1 = 0x10;
+ clock.m2 = 0x05;
+} else {
+ clock.dot = 27;
+ clock.p = 10;
+ clock.p1 = 1;
+ clock.p2 = 10;
+ clock.n = 0x02;
+ clock.m = 108;
+ clock.m1 = 0x12;
+ clock.m2 = 0x06;
+}
+memcpy(best_clock, clock, sizeof(intel_clock_t));
+return true;
+}
+
void
intel_wait_for_vblank(struct drm_device *dev)
{
@@ -1108,6 +1185,7 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
} else {
refclk = 48000;
}
+
/*
* Returns a set of divisors for the desired target clock with the given
@@ -1275,6 +1353,8 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
I915_WRITE(LVDS, lvds);
I915_READ(LVDS);
}
+ if (is_dp)
+ intel_dp_set_m_n(crtc, mode, adjusted_mode);
I915_WRITE(fp_reg, fp);
I915_WRITE(dpll_reg, dpll);
@@ -1920,7 +2000,7 @@ static void intel_setup_outputs(struct drm_device *dev)
intel_dp_init(dev, DP_C);
}
if (SUPPORTS_INTEGRATED_DP(dev) (I915_READ(DP_D)
DP_DETECTED))
- intel_dp_init(dev, DP_C);
+ intel_dp_init(dev, DP_D);
} else
intel_dvo_init(dev);
@@ -1963,6 +2043,11 @@ static void intel_setup_outputs(struct drm_device *dev)
(1 1));
clone_mask = (1 INTEL_OUTPUT_TVOUT);
break;
+ case INTEL_OUTPUT_DISPLAYPORT:
+ crtc_mask = ((1 0) |
+ (1 1));
+ clone_mask = (1 INTEL_OUTPUT_DISPLAYPORT);
+ break;
}
encoder-possible_crtcs = crtc_mask;
encoder-possible_clones = intel_connector_clones(dev,
clone_mask);
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 50a75a1..ed3c7de 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -169,6 +169,12 @@ intel_dp_aux_ch(struct intel_output *intel_output,
uint32_t ctl;
uint32_t status;
+// printk(KERN_ERR dp_aux_ch 0x%08x send %d:,
+// output_reg, send_bytes);
+// for (i = 0; i send_bytes; i++)
+// printk( %02x, send[i]);
+// printk(\n);
No // comments in kernel code.
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: i915: ensure objects are allocated below 4GB on PAE
On Wed, 2009-05-27 at 08:42 +0800, Shaohua Li wrote: On Wed, May 27, 2009 at 08:18:40AM +0800, Kyle McMartin wrote: On Tue, May 26, 2009 at 11:55:50PM +0100, Hugh Dickins wrote: I'm confused: I thought GFP_DMA32 only applies on x86_64: my 32-bit PAE machine with (slightly!) 4GB shows no ZONE_DMA32. Does this patch perhaps depend on another, to enable DMA32 on 32-bit PAE, or am I just in a muddle? No, you're exactly right, I'm just a muppet and missed the obvious. Looks like the correct fix is the fact that the allocation is thus filled out with GFP_USER, therefore, from ZONE_NORMAL, and below max_low_pfn. Looks like we'll need some additional thinking to get true ZONE_DMA32 on i386... ugh, I'll look into it tonight. For i386, GFP_USER is enough. But 945G GART can only map to physical page 4G, so for x64, we need GFP_DMA32. This is the reason I add extra GFP_DMA32. Those 945Gs don't have memory located above 4G, from my reading of the chipset specs. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Intel-gfx] [PATCH V1] drm: export get and put connector type id
On Tue, 2009-05-26 at 11:12 +0800, Ma, Ling wrote: -Original Message- From: Eric Anholt [mailto:e...@anholt.net] Sent: Saturday, May 23, 2009 3:12 AM To: Ma, Ling Cc: dri-devel@lists.sourceforge.net; intel-...@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH V1] drm: export get and put connector type id On Fri, 2009-05-22 at 20:15 +0800, Ma Ling wrote: We use connector type id as sequence to avoid duplicate connector name. However for some connectors that advertise multiple functions we have to meet the same issue, i.e. connector advertise two functions- DVI and VGA, actually only VGA is real one, in init function card0-VGA-1 is allocated for CRT, and card0-DVI-D-1 is allocated for DVI, but until detection process complete we could be aware of VGA, not DVI for this connector, then we change constructed connector type as VGA, which cause that the name card0-VGA-1 would be allocated to both a CRT and that connector. The patch intends to avoid above case by exporting get and put connector type id. This whole renaming connectors thing seems broken to me. Whatever detection is required should be done once at init, and appropriate connectors created. Is there something preventing that? We determin real output by response from sdvocommand. At init if we don't plug any output, the response from sdvo device is 0, so we have to chose real output untile detection complete. In this case, I think we should expose the maximum reliable information at init time (even if it means unknown), and not change it. Changing the connector names at runtime seems bad to me. It'll only confuse people and their xrandr scripts. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: i915: ensure objects are allocated below 4GB on PAE
On Tue, 2009-05-26 at 21:17 +0200, Peter Zijlstra wrote: On Tue, 2009-05-26 at 12:27 -0400, Kyle McMartin wrote: From: Kyle McMartin k...@redhat.com Ensure we allocate GEM objects below 4GB on PAE machines, otherwise misery ensues. This patch is based on a patch found on dri-devel by Shaohua Li, but Keith P. expressed reticence that the changes unfairly penalized other hardware. (The mm/shmem.c hunk is necessary to ensure the DMA32 flag isn't used by the slab allocator via radix_tree_preload, which will hit a WARN_ON.) Why is this, is the gart not PAE friendly? Seems to me its a grand way of promoting 64bit hard/soft-ware. No, the GART's fine. But the APIs required to make the AGP code PAE-friendly got deprecated, so the patches to fix the AGP code got NAKed, and Venkatesh never sent out his patches to undeprecate the APIs and use them. It's been like 6 months now, and it's absurd. I'd like to see this patch go in so people's graphics can start working again and stop corrupting system memory. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, Big Spaceship. http://p.sf.net/sfu/creativitycat-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH V1] drm: export get and put connector type id
On Fri, 2009-05-22 at 20:15 +0800, Ma Ling wrote:
We use connector type id as sequence to avoid duplicate connector name.
However for some connectors that advertise multiple functions
we have to meet the same issue, i.e. connector advertise two functions-
DVI and VGA, actually only VGA is real one, in init function card0-VGA-1
is allocated for CRT, and card0-DVI-D-1 is allocated for DVI, but until
detection process complete we could be aware of VGA, not DVI for this
connector,
then we change constructed connector type as VGA, which cause that
the name card0-VGA-1 would be allocated to both a CRT and that connector.
The patch intends to avoid above case by exporting get and put connector type
id.
This whole renaming connectors thing seems broken to me. Whatever
detection is required should be done once at init, and appropriate
connectors created. Is there something preventing that?
Signed-off-by: Ma Ling ling...@intel.com
---
drivers/gpu/drm/drm_crtc.c | 14 --
drivers/gpu/drm/drm_sysfs.c |3 +++
include/drm/drm_crtc.h |3 +++
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 94a7688..a876f71 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -148,6 +148,16 @@ static struct drm_conn_prop_enum_list
drm_connector_enum_list[] =
{ DRM_MODE_CONNECTOR_HDMIB, HDMI Type B, 0 },
};
+int drm_get_connector_type_id(struct drm_connector *connector)
+{
+ return ++drm_connector_enum_list[connector-connector_type].count;
+}
+
+void drm_put_connector_type_id(struct drm_connector *connector)
+{
+ --drm_connector_enum_list[connector-connector_type].count;
+}
+
static struct drm_prop_enum_list drm_encoder_enum_list[] =
{{ DRM_MODE_ENCODER_NONE, None },
{ DRM_MODE_ENCODER_DAC, DAC },
@@ -451,8 +461,7 @@ void drm_connector_init(struct drm_device *dev,
connector-funcs = funcs;
drm_mode_object_get(dev, connector-base, DRM_MODE_OBJECT_CONNECTOR);
connector-connector_type = connector_type;
- connector-connector_type_id =
- ++drm_connector_enum_list[connector_type].count; /* TODO */
+ connector-connector_type_id = drm_get_connector_type_id(connector);
INIT_LIST_HEAD(connector-user_modes);
INIT_LIST_HEAD(connector-probed_modes);
INIT_LIST_HEAD(connector-modes);
@@ -485,6 +494,7 @@ void drm_connector_cleanup(struct drm_connector
*connector)
struct drm_device *dev = connector-dev;
struct drm_display_mode *mode, *t;
+ drm_put_connector_type_id(connector);
list_for_each_entry_safe(mode, t, connector-probed_modes, head)
drm_mode_remove(connector, mode);
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 8f93729..b56c0b9 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -343,6 +343,8 @@ int drm_sysfs_connector_add(struct drm_connector
*connector)
/* We shouldn't get called more than once for the same connector */
BUG_ON(device_is_registered(connector-kdev));
+ drm_put_connector_type_id(connector);
+ drm_get_connector_type_id(connector);
connector-kdev.parent = dev-primary-kdev;
connector-kdev.class = drm_class;
connector-kdev.release = drm_sysfs_device_release;
@@ -428,6 +430,7 @@ void drm_sysfs_connector_remove(struct drm_connector
*connector)
DRM_DEBUG(removing \%s\ from sysfs\n,
drm_get_connector_name(connector));
+ drm_put_connector_type_id(connector);
for (i = 0; i ARRAY_SIZE(connector_attrs); i++)
device_remove_file(connector-kdev, connector_attrs[i]);
sysfs_remove_bin_file(connector-kdev.kobj, edid_attr);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 3c1924c..64ce824 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -733,4 +733,7 @@ extern int drm_mode_gamma_get_ioctl(struct drm_device
*dev,
extern int drm_mode_gamma_set_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
extern bool drm_detect_hdmi_monitor(struct edid *edid);
+
+extern int drm_get_connector_type_id(struct drm_connector *connector);
+extern void drm_put_connector_type_id(struct drm_connector *connector);
#endif /* __DRM_CRTC_H__ */
--
1.5.4.4
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers brand creativity professionals
Re: [PATCH] drm: Copy back ioctl data to userspace regardless of return code.
On Wed, 2009-05-20 at 13:32 +0200, Michel Dänzer wrote:
From: Michel Dänzer daen...@vmware.com
Fixes a regression from commit 9d5b3ffc42f7820e8ee07705496955e4c2c38dd9
('drm: fixup some of the ioctl function exit paths'): The vblank ioctl needs
to
update the userspace parameters when interrupted by a signal, which was
prevented by the return code check. This could cause the X server to hang in
drmWaitVBlank().
Signed-off-by: Michel Dänzer daen...@vmware.com
Reviewed-by: Eric Anholt e...@anholt.net
(The DRM ioctls are, to my memory, all built so that on error copying
the data out still is either harmless or good).
---
drivers/gpu/drm/drm_drv.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 14c7a23..825866d 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -512,7 +512,7 @@ int drm_ioctl(struct inode *inode, struct file *filp,
}
retcode = func(dev, kdata, file_priv);
- if ((retcode == 0) (cmd IOC_OUT)) {
+ if (cmd IOC_OUT) {
if (copy_to_user((void __user *)arg, kdata,
_IOC_SIZE(cmd)) != 0)
retcode = -EFAULT;
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tech-side developers brand creativity professionals. Meet
the minds behind Google Creative Lab, Visual Complexity, Processing,
iPhoneDevCamp asthey present alongside digital heavyweights like Barbarian
Group, R/GA, Big Spaceship. http://www.creativitycat.com --
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH resend] drm: ignore LVDS on intel graphics systems that lie about having it
On Tue, 2009-05-05 at 10:00 -0400, Jarod Wilson wrote: There are a number of small form factor desktop systems with Intel mobile graphics chips that lie and say they have an LVDS. With kernel mode-setting, this becomes a problem, and makes native resolution boot go haywire -- for example, my Dell Studio Hybrid, hooked to a 1920x1080 display claims to have a 1024x768 LVDS, and the resulting graphical boot on the 1920x1080 display uses only the top left 1024x768, and auto-configured X will end up only 1024x768 as well. With this change, graphical boot and X both do 1920x1080 as expected. Note that we're simply embracing and extending the early bail-out code in place for the Mac Mini here. The xorg intel driver uses pci subsystem device and vendor id for matching, while we're using dmi lookups here. The MSI addition is courtesy of and tested by Bill Nottingham. Signed-off-by: Jarod Wilson ja...@redhat.com Tested-by: Bill Nottingham nott...@redhat.com Looks good, I'm pulling it for 2.6.30. Thanks! -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] libdrm/intel: add drm_intel_bo_disable_reuse api
On Mon, 2009-05-11 at 13:51 -0700, Keith Packard wrote: Scanout buffers need to be freed through the kernel as it holds a reference to them; exposing this API allows applications allocating scanout buffers to flag them as not reusable. Signed-off-by: Keith Packard kei...@keithp.com I like it. Just a couple of things: Bump the configure.ac patch version so the 2D driver can depend on the version. Maybe have flink (setting global_name) call disable_reuse so we don't have to check both name and !reuse for whether to not reuse Slide the new char field down next to the other char boolean so it packs into what is pad space today. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/2] Bump to version 2.4.10 to mark addition of drm_intel_bo_disable_reuse
On Tue, 2009-05-12 at 15:36 -0700, Keith Packard wrote: New API, new version. Signed-off-by: Keith Packard kei...@keithp.com For both: Reviewed-by: Eric Anholt e...@anholt.net -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] [Patch 1/2] [intel-gfx] : Add the CVT algorithm in kernel space
On Thu, 2009-05-07 at 14:51 +0800, yakui_zhao wrote: On Thu, 2009-05-07 at 06:01 +0800, Eric Anholt wrote: On Tue, 2009-05-05 at 15:19 +0800, yakui_zhao wrote: Add the CVT algorithm in kernel space. And this function can be called to generate the required modeline. Signed-off-by: Zhao Yakui yakui.z...@intel.com This code appears to be a copy-and-paste with small modifications of xf86cvt.c, but the license of that code isn't respected. Yes. Most is copied from xserver/hw/xfree86/mode/xf86CVT(xf86GTF). What I done is that the float-point calculation is replaced by using integer. How to pay attention to the license of xf86CVT code? Is it OK that the following is added in the function description? /* * Copyright 2005-2006 Luc Verhaegen. * * Permission is hereby granted, free of charge, to any person obtaining a * copy of this software and associated documentation files (the Software), * to deal in the Software without restriction, including without limitation * the rights to use, copy, modify, merge, publish, distribute, sublicense, * and/or sell copies of the Software, and to permit persons to whom the * Software is furnished to do so, subject to the following conditions: */ Is the function comment OK ? If the style is incorrect, I will change it based on the description in kernel-doc-nano-Howto.txt. License information goes at the top of the file. If the license text is exactly the same as the existing license, just add the new copyright holder on a new line next to the others. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] [Patch 1/2] [intel-gfx] : Add the CVT algorithm in kernel space
On Tue, 2009-05-05 at 15:19 +0800, yakui_zhao wrote: Add the CVT algorithm in kernel space. And this function can be called to generate the required modeline. Signed-off-by: Zhao Yakui yakui.z...@intel.com This code appears to be a copy-and-paste with small modifications of xf86cvt.c, but the license of that code isn't respected. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [RFC] [Patch 1/2] [intel-gfx] : Add the CVT algorithm in kernel space
On Tue, 2009-05-05 at 11:17 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 yakui_zhao wrote: Add the CVT algorithm in kernel space. And this function can be called to generate the required modeline. Signed-off-by: Zhao Yakui yakui.z...@intel.com --- drivers/gpu/drm/drm_modes.c | 210 include/drm/drm_crtc.h |3 2 files changed, 213 insertions(+) Index: linux-2.6/drivers/gpu/drm/drm_modes.c === --- linux-2.6.orig/drivers/gpu/drm/drm_modes.c 2009-04-21 15:48:52.0 +0800 +++ linux-2.6/drivers/gpu/drm/drm_modes.c 2009-05-05 11:22:09.0 +0800 @@ -59,6 +59,216 @@ } EXPORT_SYMBOL(drm_mode_debug_printmodeline); +#define HV_FACTOR 1000 +/ + * Function: drm_cvt_mode + * + * Parameters : dev -drm device + * hdisplay - hdisplay size + * vdisplay - vdisplay size + * vfresh - vfresh rate. + * reduced - whether GTF calculation is simplified + * interlaced -- whether the interlace is supported + * Returns : return the display mode + * + * Function description + * : create the display mode according to the CVT algorthim. + * It is based on the file of xserver/hw/xfree86/modes/xf86cvt + */ Use kerneldoc function header comment style. I'd bet that Linus would NAK this. The existing style in the code is doxygen, and we've been continuing to use that so far. But coming up with your own new style is clearly wrong. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] KMS: do a faster EDID
On Fri, 2009-03-27 at 16:08 -0700, Jesse Barnes wrote: On Mon, 23 Mar 2009 13:48:01 -0700 Arjan van de Ven ar...@infradead.org wrote: From a121507f31e37a809dfa21c9756aa83f36d7acbf Mon Sep 17 00:00:00 2001 From: Arjan van de Ven ar...@linux.intel.com Date: Mon, 23 Mar 2009 13:37:20 -0700 Subject: [PATCH] KMS: do a faster EDID for some outputs (like LVDS), the current delays in the EDID reader are way overkill. This patch makes the EDID reader try twice; first with a 5x faster probe, and if that fails, it probes at the current speed. This reduces probe time on my LVDS panel significantly. Signed-off-by: Arjan van de Ven ar...@linux.intel.com Theoretically this should work fine, but there may be more savings to be had in the underlying EDID fetching code timing. I know our timings aren't as good as X yet, but we may be able to do something similar in the actual DDC probing as well (use fast timings first, then fall back to robust ones if that fails) and get a double benefit. Have you looked at that at all? Either way, this one looks ok, so I'm ok with it as long as Dave is. Acked-by: Jesse Barnes jbar...@virtuousgeek.org We need to just figure out how to use the GMBUS stuff successfully. It's what everyone else uses as far as I know. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Register Now Save for Velocity, the Web Performance Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: Remove duplicated code
On Tue, 2009-04-21 at 09:29 +0200, Jonas Bonn wrote:
It looks like some code got left behind while generalizing. This patch
removes the old, non-general version and fixes up the generalized version
so that it does what its supposed to.
NAK.
There is SDVOB, and SDVOC.
To detect SDVOB, you look in SDVOB.
To detect SDVOC, you look in SDVOB on old hardware, and SDVOC on new
hardware.
Signed-off-by: Jonas Bonn jo...@southpole.se
---
drivers/gpu/drm/i915/intel_display.c | 10 ++
1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c2c8e95..3811992 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1838,12 +1838,6 @@ static void intel_setup_outputs(struct drm_device *dev)
int found;
u32 reg;
- if (I915_READ(SDVOB) SDVO_DETECTED) {
- found = intel_sdvo_init(dev, SDVOB);
- if (!found SUPPORTS_INTEGRATED_HDMI(dev))
- intel_hdmi_init(dev, SDVOB);
- }
-
/* Before G4X SDVOC doesn't have its own detect register */
if (IS_G4X(dev))
reg = SDVOC;
@@ -1851,9 +1845,9 @@ static void intel_setup_outputs(struct drm_device *dev)
reg = SDVOB;
if (I915_READ(reg) SDVO_DETECTED) {
- found = intel_sdvo_init(dev, SDVOC);
+ found = intel_sdvo_init(dev, reg);
if (!found SUPPORTS_INTEGRATED_HDMI(dev))
- intel_hdmi_init(dev, SDVOC);
+ intel_hdmi_init(dev, reg);
}
} else
intel_dvo_init(dev);
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] fix unpaired i915 device mutex
On Sat, 2009-04-18 at 10:43 +0800, Wu Fengguang wrote:
Signed-off-by: Wu Fengguang fengguang...@intel.com
---
drivers/gpu/drm/i915/i915_gem.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Fixed up commit message and applied.
--- mm.orig/drivers/gpu/drm/i915/i915_gem.c
+++ mm/drivers/gpu/drm/i915/i915_gem.c
@@ -4087,8 +4087,10 @@ i915_gem_entervt_ioctl(struct drm_device
dev_priv-mm.suspended = 0;
ret = i915_gem_init_ringbuffer(dev);
- if (ret != 0)
+ if (ret != 0) {
+ mutex_unlock(dev-struct_mutex);
return ret;
+ }
spin_lock(dev_priv-mm.active_list_lock);
BUG_ON(!list_empty(dev_priv-mm.active_list));
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: A17 tiling series V2
On Wed, 2009-04-08 at 19:41 +0100, Chris Wilson wrote:
On Wed, 2009-04-08 at 11:05 -0700, Eric Anholt wrote:
Here's the pair of patches I've got to make A17-afflicted machines do
tiling.
I've created regression tests for swapping tiled objects and for pread on
tiled objects, and I'm at 1/10 failures in intel-gpu-tools, or 0/10 if I
disable BO reuse (appears to be a bug in fencing on objects getting reused
as tiled after being linear). 3D performance is back to normal on my
affected 945GM, and no_rast=true glxgears looks good.
Sounds like this patch should do the trick...
I don't think that's what's going on with the issue I was seeing, since
strides are all the same, and it's an untiled - tiled transition
failing (I think). But I can't say for sure.
On first glance, this patch tricked me because I was assuming that
i915_gem_tiling_ok was did the tiling mode we choose end up being OK
for this bo, not is the current GTT location OK for the new tiling
mode that we know for sure is OK?. I'm tempted to rename it.
Given that the current driver stack doesn't do any tiled - tiled
transitions, I'm thinking of holding off on this one until the next
merge window. Any strong objections?
From 1c5d1156f0f467568b1eab18a33dd9edc3579ce5 Mon Sep 17 00:00:00 2001
From: Chris Wilson ch...@chris-wilson.co.uk
Date: Wed, 11 Feb 2009 10:45:16 +
Subject: [PATCH] drm/i915: Clear fence register on tiling stride change.
The fence register value also depends upon the stride of the object, so
we
need to clear the fence if that is changed as well.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/i915_drv.h|1 +
drivers/gpu/drm/i915/i915_gem.c| 37 +-
drivers/gpu/drm/i915/i915_gem_tiling.c | 54
++-
3 files changed, 75 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h
b/drivers/gpu/drm/i915/i915_drv.h
index 3784cfc..833ad26 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -628,6 +628,7 @@ void i915_gem_object_unpin(struct drm_gem_object
*obj);
int i915_gem_object_unbind(struct drm_gem_object *obj);
void i915_gem_lastclose(struct drm_device *dev);
uint32_t i915_get_gem_seqno(struct drm_device *dev);
+int i915_gem_object_put_fence_reg(struct drm_gem_object *obj);
void i915_gem_retire_requests(struct drm_device *dev);
void i915_gem_retire_work_handler(struct work_struct *work);
void i915_gem_clflush_object(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/i915/i915_gem.c
b/drivers/gpu/drm/i915/i915_gem.c
index 5848c1d..43c71de 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2019,7 +2019,6 @@ static void i830_write_fence_reg(struct
drm_i915_fence_reg *reg)
val |= I830_FENCE_REG_VALID;
I915_WRITE(FENCE_REG_830_0 + (regnum * 4), val);
-
}
/**
@@ -2211,6 +2210,42 @@ i915_gem_clear_fence_reg(struct drm_gem_object
*obj)
}
/**
+ * i915_gem_object_put_fence_reg - waits on outstanding fenced access
+ * to the buffer to finish, and then resets the fence register.
+ * @obj: tiled object holding a fence register.
+ *
+ * Zeroes out the fence register itself and clears out the associated
+ * data structures in dev_priv and obj_priv.
+ */
+int
+i915_gem_object_put_fence_reg(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj-dev;
+ struct drm_i915_gem_object *obj_priv = obj-driver_private;
+
+ if (obj_priv-fence_reg == I915_FENCE_REG_NONE)
+ return 0;
+
+ /* On the i915, GPU access to tiled buffers is via a fence,
+ * therefore we must wait for any outstanding access to complete
+ * before clearing the fence.
+ */
+ if (!IS_I965G(dev)) {
+ int ret;
+
+ i915_gem_object_flush_gpu_write_domain(obj);
+ i915_gem_object_flush_gtt_write_domain(obj);
+ ret = i915_gem_object_wait_rendering(obj);
+ if (ret != 0)
+ return ret;
+ }
+
+ i915_gem_clear_fence_reg (obj);
+
+ return 0;
+}
+
+/**
* Finds free space in the GTT aperture and binds the object there.
*/
static int
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index 6be3f92..373e457 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -255,6 +255,21 @@ i915_tiling_ok(struct drm_device *dev, int stride,
int size, int tiling_mode)
return true;
}
+static bool
+i915_gem_object_tiling_ok (struct drm_gem_object *obj, int tiling_mode)
+{
+ struct drm_i915_gem_object *obj_priv = obj-driver_private;
+
+ if (obj_priv-gtt_space == NULL)
+ return true;
+
+ if (tiling_mode == I915_TILING_NONE)
+ return true;
+
+ return (obj_priv-gtt_offset
Re: [Intel-gfx] [PATCH] i915: add page flipping support
I915_LEGACY_BLC_EVENT_STATUS) ||
(iir I915_ASLE_INTERRUPT))
opregion_asle_intr(dev);
@@ -563,6 +595,7 @@ void i915_driver_irq_preinstall(struct drm_device *
dev) I915_WRITE(IER, 0x0);
(void) I915_READ(IER);
INIT_WORK(dev_priv-hotplug_work, i915_hotplug_work_func);
+ INIT_WORK(dev_priv-vblank_work, i915_vblank_work_func);
}
int i915_driver_irq_postinstall(struct drm_device *dev)
diff --git a/include/drm/i915_drm.h b/include/drm/i915_drm.h
index 67e3353..b022ba5 100644
--- a/include/drm/i915_drm.h
+++ b/include/drm/i915_drm.h
@@ -184,6 +184,7 @@ typedef struct _drm_i915_sarea {
#define DRM_I915_GEM_GET_TILING 0x22
#define DRM_I915_GEM_GET_APERTURE 0x23
#define DRM_I915_GEM_MMAP_GTT0x24
+#define DRM_I915_GEM_PAGE_FLIP 0x25
#define DRM_IOCTL_I915_INIT DRM_IOW( DRM_COMMAND_BASE +
DRM_I915_INIT, drm_i915_init_t) #define
DRM_IOCTL_I915_FLUSH DRM_IO ( DRM_COMMAND_BASE +
DRM_I915_FLUSH) @@ -219,6 +220,7 @@ typedef struct _drm_i915_sarea
{ #define DRM_IOCTL_I915_GEM_SET_TILING DRM_IOWR
(DRM_COMMAND_BASE + DRM_I915_GEM_SET_TILING, struct
drm_i915_gem_set_tiling) #define DRM_IOCTL_I915_GEM_GET_TILING
DRM_IOWR (DRM_COMMAND_BASE + DRM_I915_GEM_GET_TILING, struct
drm_i915_gem_get_tiling) #define DRM_IOCTL_I915_GEM_GET_APERTURE
DRM_IOR (DRM_COMMAND_BASE + DRM_I915_GEM_GET_APERTURE, struct
drm_i915_gem_get_aperture) +#define DRM_IOCTL_I915_GEM_PAGE_FLIP
DRM_IOW (DRM_COMMAND_BASE + DRM_I915_GEM_PAGE_FLIP, struct
drm_i915_gem_page_flip) /* Allow drivers to submit batchbuffers
directly to hardware, relying
* on the security mechanisms provided by hardware.
@@ -654,4 +656,20 @@ struct drm_i915_gem_get_aperture {
__u64 aper_available_size;
};
+#define I915_PAGE_FLIP_WAIT (10) /* block on page flip completion */
+
+struct drm_i915_gem_page_flip {
+ /** Handle of new front buffer */
+ uint32_t fb_id;
+ /**
+ * crtc to flip
+ */
+ uint32_t crtc_id;
+
+ /**
+ * page flip flags (wait on flip only for now)
+ */
+ uint32_t flags;
+};
+
#endif /* _I915_DRM_H_ */
___
Intel-gfx mailing list
intel-...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Eric Anholt
e...@anholt.net eric.anh...@intel.com
signature.asc
Description: This is a digitally signed message part
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm/i915: Correctly set the write flag for get_user_pages in pread.
Otherwise, the results of our read didn't show up when we were faulting in
the page being read into (as happened with a testcase reading into a big
stack area). Likely accounts for some conformance test failures.
Signed-off-by: Eric Anholt e...@anholt.net
---
drivers/gpu/drm/i915/i915_gem.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6f7d0e2..3a1189d 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -287,7 +287,7 @@ i915_gem_shmem_pread_slow(struct drm_device *dev, struct
drm_gem_object *obj,
down_read(mm-mmap_sem);
pinned_pages = get_user_pages(current, mm, (uintptr_t)args-data_ptr,
- num_pages, 0, 0, user_pages, NULL);
+ num_pages, 1, 0, user_pages, NULL);
up_read(mm-mmap_sem);
if (pinned_pages num_pages) {
ret = -EFAULT;
--
1.6.2.1
--
This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
http://p.sf.net/sfu/www-ibm-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
A17 tiling series V2
Here's the pair of patches I've got to make A17-afflicted machines do tiling. I've created regression tests for swapping tiled objects and for pread on tiled objects, and I'm at 1/10 failures in intel-gpu-tools, or 0/10 if I disable BO reuse (appears to be a bug in fencing on objects getting reused as tiled after being linear). 3D performance is back to normal on my affected 945GM, and no_rast=true glxgears looks good. I haven't written a regression test for tiled pwrite yet, is my only concern. -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] drm/i915: Allow tiling of objects with bit 17 swizzling by the CPU.
Save the bit 17 state of the pages when freeing the page list, and
reswizzle them if necessary when rebinding the pages (in case they were
swapped out). Since we have userland with expectations that the swizzle
enums let it pread and pwrite contents accurately, we can't expose a new
swizzle enum for bit 17 (which it would have to GTT map to handle), so we
handle it down in pread and pwrite by swizzling the copy when bit 17 of the
page address is set.
Signed-off-by: Eric Anholt e...@anholt.net
---
drivers/gpu/drm/i915/i915_drv.h|5 +
drivers/gpu/drm/i915/i915_gem.c| 130 +---
drivers/gpu/drm/i915/i915_gem_tiling.c | 111 ++-
include/drm/i915_drm.h |3 +
4 files changed, 235 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index efcd610..bccd414 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -446,6 +446,9 @@ struct drm_i915_gem_object {
uint32_t tiling_mode;
uint32_t stride;
+ /** Record of address bit 17 of each page at last unbind. */
+ long *bit_17;
+
/** AGP mapping type (AGP_USER_MEMORY or AGP_USER_CACHED_MEMORY */
uint32_t agp_type;
@@ -640,6 +643,8 @@ void i915_gem_object_put_pages(struct drm_gem_object *obj);
/* i915_gem_tiling.c */
void i915_gem_detect_bit_6_swizzle(struct drm_device *dev);
+void i915_gem_object_do_bit_17_swizzle(struct drm_gem_object *obj);
+void i915_gem_object_save_bit_17_swizzle(struct drm_gem_object *obj);
/* i915_gem_debug.c */
void i915_gem_dump_object(struct drm_gem_object *obj, int len,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3a1189d..6dca9fc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -155,6 +155,15 @@ fast_shmem_read(struct page **pages,
return 0;
}
+static int i915_gem_object_needs_bit17_swizzle(struct drm_gem_object *obj)
+{
+ drm_i915_private_t *dev_priv = obj-dev-dev_private;
+ struct drm_i915_gem_object *obj_priv = obj-driver_private;
+
+ return dev_priv-mm.bit_6_swizzle_x == I915_BIT_6_SWIZZLE_9_10_17
+ obj_priv-tiling_mode != I915_TILING_NONE;
+}
+
static inline int
slow_shmem_copy(struct page *dst_page,
int dst_offset,
@@ -182,6 +191,64 @@ slow_shmem_copy(struct page *dst_page,
return 0;
}
+static inline int
+slow_shmem_bit17_copy(struct page *gpu_page,
+ int gpu_offset,
+ struct page *cpu_page,
+ int cpu_offset,
+ int length,
+ int is_read)
+{
+ char *gpu_vaddr, *cpu_vaddr;
+
+ /* Use the unswizzled path if this page isn't affected. */
+ if ((page_to_phys(gpu_page) (1 17)) == 0) {
+ if (is_read)
+ return slow_shmem_copy(cpu_page, cpu_offset,
+ gpu_page, gpu_offset, length);
+ else
+ return slow_shmem_copy(gpu_page, gpu_offset,
+ cpu_page, cpu_offset, length);
+ }
+
+ gpu_vaddr = kmap_atomic(gpu_page, KM_USER0);
+ if (gpu_vaddr == NULL)
+ return -ENOMEM;
+
+ cpu_vaddr = kmap_atomic(cpu_page, KM_USER1);
+ if (cpu_vaddr == NULL) {
+ kunmap_atomic(gpu_vaddr, KM_USER0);
+ return -ENOMEM;
+ }
+
+ /* Copy the data, XORing A6 with A17 (1). The user already knows he's
+* XORing with the other bits (A9 for Y, A9 and A10 for X)
+*/
+ while (length 0) {
+ int cacheline_end = ALIGN(gpu_offset + 1, 64);
+ int this_length = min(cacheline_end - gpu_offset, length);
+ int swizzled_gpu_offset = gpu_offset ^ 64;
+
+ if (is_read) {
+ memcpy(cpu_vaddr + cpu_offset,
+ gpu_vaddr + swizzled_gpu_offset,
+ this_length);
+ } else {
+ memcpy(gpu_vaddr + swizzled_gpu_offset,
+ cpu_vaddr + cpu_offset,
+ this_length);
+ }
+ cpu_offset += this_length;
+ gpu_offset += this_length;
+ length -= this_length;
+ }
+
+ kunmap_atomic(cpu_vaddr, KM_USER1);
+ kunmap_atomic(gpu_vaddr, KM_USER0);
+
+ return 0;
+}
+
/**
* This is the fast shmem pread path, which attempts to copy_from_user directly
* from the backing pages of the object to the user's address space. On a
@@ -270,6 +337,7 @@ i915_gem_shmem_pread_slow(struct drm_device *dev, struct
drm_gem_object *obj,
int page_length;
int ret;
uint64_t data_ptr = args-data_ptr;
+ int do_bit17_swizzling;
remain = args-size
[git pull] Fixes for 2.6.30-rc1
The following changes since commit 8fe74cf053de7ad2124a894996f84fa890a81093: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../viro/vfs-2.6 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel drm-intel-next I haven't tested the merge with 2.6.30rc1, but I'm not expecting troubles. I've been testing with this set of patches for a couple days, and I don't think any of the problems I'm seeing are related. The most exciting change here is one that doesn't quite fit into an RC, but it'll help us catch bugs from here until release: batch and ring buffer dumping. We're cooking up a script that should sit on top of this to give us a useful pile of information for attaching to bug reports when your GPU's locked up. Coming up soon: A17 fixes to bring 945GM performance back up to par. drm_alloc/free removal (if you're up for it) Ben Gamari (1): drm/i915: Implement batch and ring buffer dumping Ferenc Wagner (1): drm/i915: indicate framebuffer restore key in SysRq help message Florian Mickler (1): drm/i915: Fix use of uninitialized var in 40a5f0de Ma Ling (1): drm/i915: sync hdmi detection by hdmi identifier with 2D Shaohua Li (1): drm/i915: Fix a mismerge of the IGD patch (new .find_pll hooks missed) drivers/gpu/drm/i915/i915_drv.h |2 + drivers/gpu/drm/i915/i915_gem.c | 42 -- drivers/gpu/drm/i915/i915_gem_debugfs.c | 93 +++ drivers/gpu/drm/i915/intel_display.c|2 + drivers/gpu/drm/i915/intel_fb.c |4 +- drivers/gpu/drm/i915/intel_hdmi.c | 23 +++- drivers/gpu/drm/i915/intel_sdvo.c | 22 +++- 7 files changed, 164 insertions(+), 24 deletions(-) -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Remove code for tracking per-drawable cliprects.
On Tue, 2009-04-07 at 13:08 -0400, Kristian Høgsberg wrote: On Fri, Apr 3, 2009 at 11:56 AM, Kristian Høgsberg k...@bitplanet.net wrote: 2009/4/2 Eric Anholt e...@anholt.net: On Thu, 2009-04-02 at 14:41 -0400, Kristian Høgsberg wrote: This was only used by the i915 driver for the swapbuffer vsync tasklet. That functionality is now gone and nothing uses the kernel side cliprects anymore. Just stub out the ioctls, but make sure we return a non-zero handle in the DRM_IOCTL_ADD_DRAW case. Have you tested old userland to make sure it doesn't freak out? Other than that, I love the idea. I did, ran gears, resized it, and it worked. glxgears is even less of a test suite than it is a benchmark, of course, bu int this case I do believe it tests the code paths in question. The only gotchas would be if some userspace code relies on updating or removing an invalid drawable handle to return -EINVAL or relies on adddraw returning unique drawable handles. In my reading of the xf86dri, aiglx and libgl, I've not come across any such requirement. Do you want to pick it up then or do you want Dave to take it? Since it wasn't in my driver, I was assuming airlied would pick it up. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/i915: Allow tiling of objects with bit 17 swizzling by the CPU.
On Fri, 2009-04-03 at 18:08 -0700, Keith Packard wrote: On Fri, 2009-04-03 at 17:03 -0700, Eric Anholt wrote: + obj_priv-bit_17 = kmalloc(page_count, GFP_KERNEL); seems like you could save a bit of memory here by using 1 bit per page instead of a byte. Before, I was figuring it was better to have easy code than memory optimal code in my infrequently-tested workaround. Since recent notes about kmalloc limits, I'll switch to using bitmap.h. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/i915: Allow tiling of objects with bit 17 swizzling by the CPU.
Save the bit 17 state of the pages when freeing the page list, and
reswizzle them if necessary when rebinding the pages. This exposes two new
swizzle enums to userland, which would have to be respected for correct
operation of software fallbacks on these objects. Given that users
complain that 3D acceleration is slower than software rendering without
tiling, it seems that reenabling things even if some operations aren't correct
with old userland is worth the cost.
Userland won't be able to respect the two new tiling enums with
drm_intel_bo_map or pread/pwrite. However, GTT maps are available and should
prove sufficient.
Signed-off-by: Eric Anholt e...@anholt.net
---
I've tested this, and it does take swapping of tiled objects on an
A17-affected machine from failing to working. I haven't written the
Mesa patch to move to GTT mapping yet, so this would regress Mesa and I
won't submit it for inclusion until I do that.
Or, if there's objection to breaking backwards compat in this way, I
could write pread/pwrite compatibility paths that do the swizzling as
well and just tell the user that it's got the swizzling without A17,
which would cover Mesa SW fallbacks. But either way we'll want to
change Mesa's behavior on at least A17 machines.
drivers/gpu/drm/i915/i915_drv.h|5 ++
drivers/gpu/drm/i915/i915_gem.c|8 +++
drivers/gpu/drm/i915/i915_gem_tiling.c | 85 +++-
include/drm/i915_drm.h |3 +
4 files changed, 99 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index efcd610..f968fe8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -446,6 +446,9 @@ struct drm_i915_gem_object {
uint32_t tiling_mode;
uint32_t stride;
+ /** Record of address bit 17 of each page at last unbind. */
+ char *bit_17;
+
/** AGP mapping type (AGP_USER_MEMORY or AGP_USER_CACHED_MEMORY */
uint32_t agp_type;
@@ -640,6 +643,8 @@ void i915_gem_object_put_pages(struct drm_gem_object *obj);
/* i915_gem_tiling.c */
void i915_gem_detect_bit_6_swizzle(struct drm_device *dev);
+void i915_gem_object_do_bit_17_swizzle(struct drm_gem_object *obj);
+void i915_gem_object_save_bit_17_swizzle(struct drm_gem_object *obj);
/* i915_gem_debug.c */
void i915_gem_dump_object(struct drm_gem_object *obj, int len,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 33ab07b..14db0e4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1295,6 +1295,9 @@ i915_gem_object_put_pages(struct drm_gem_object *obj)
if (--obj_priv-pages_refcount != 0)
return;
+ if (obj_priv-tiling_mode != I915_TILING_NONE)
+ i915_gem_object_save_bit_17_swizzle(obj);
+
for (i = 0; i page_count; i++)
if (obj_priv-pages[i] != NULL) {
if (obj_priv-dirty)
@@ -1920,6 +1923,10 @@ i915_gem_object_get_pages(struct drm_gem_object *obj)
}
obj_priv-pages[i] = page;
}
+
+ if (obj_priv-tiling_mode != I915_TILING_NONE)
+ i915_gem_object_do_bit_17_swizzle(obj);
+
return 0;
}
@@ -3591,6 +3598,7 @@ void i915_gem_free_object(struct drm_gem_object *obj)
i915_gem_free_mmap_offset(obj);
drm_free(obj_priv-page_cpu_valid, 1, DRM_MEM_DRIVER);
+ kfree(obj_priv-bit_17);
drm_free(obj-driver_private, 1, DRM_MEM_DRIVER);
}
diff --git a/drivers/gpu/drm/i915/i915_gem_tiling.c
b/drivers/gpu/drm/i915/i915_gem_tiling.c
index 6be3f92..5544102 100644
--- a/drivers/gpu/drm/i915/i915_gem_tiling.c
+++ b/drivers/gpu/drm/i915/i915_gem_tiling.c
@@ -25,6 +25,7 @@
*
*/
+#include linux/string.h
#include drmP.h
#include drm.h
#include i915_drm.h
@@ -127,8 +128,8 @@ i915_gem_detect_bit_6_swizzle(struct drm_device *dev)
swizzle_y = I915_BIT_6_SWIZZLE_9_11;
} else {
/* Bit 17 swizzling by the CPU in addition. */
- swizzle_x = I915_BIT_6_SWIZZLE_UNKNOWN;
- swizzle_y = I915_BIT_6_SWIZZLE_UNKNOWN;
+ swizzle_x = I915_BIT_6_SWIZZLE_9_10_17;
+ swizzle_y = I915_BIT_6_SWIZZLE_9_17;
}
break;
}
@@ -359,3 +360,83 @@ i915_gem_get_tiling(struct drm_device *dev, void *data,
return 0;
}
+
+/**
+ * Swap every 64 bytes of this page around, to account for it having a new
+ * bit 17 of its physical address and therefore being interpreted differently
+ * by the GPU.
+ */
+static int
+i915_gem_swizzle_page(struct page *page)
+{
+ char *vaddr;
+ int i;
+ char temp[64];
+
+ vaddr = kmap(page);
+ if (vaddr == NULL)
+ return -ENOMEM
[git pull] drm-intel fixes for 2.6.30
OK, here's another set for within the merge window. One commit outside of the driver, which is to fix GTT mapping non-PAT thanks to pgprot_writecombine. Probably the most important thing here, though, is the TV modesetting in property change, which fixes an oops with the new 2D driver now that it's actually poking these properties. The following changes since commit c09bca786ff941ed17c5f381c4eca5b106808c51: Linus Torvalds (1): Merge git://git.kernel.org/.../bart/ide-2.6 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel drm-intel-next Arjan van de Ven (1): drm/i915: clean up udelay usage Carl Worth (1): drm/i915: Add a spinlock to protect the active_list Daniel Vetter (1): drm/i915: fix up tiling/fence reg setup on i8xx class hw Jesse Barnes (3): drm/i915: check for -EINVAL from vm_insert_pfn drm/i915: add VGA hotplug support for 945+ drm: Use pgprot_writecombine in GEM GTT mapping to get the right bits for !PAT. Ma Ling (1): drm/i915: avoid hanging on to a stale pointer to raw_edid. Shaohua Li (1): drm/i915: correctly set IGD device's gtt size for KMS. Zhenyu Wang (6): drm/i915: only set TV mode when any property changed drm/i915: fix TV mode setting in property change drm/i915: Fix SDVO command debug function drm/i915: Fix error in SDVO DTD and modeline convert drm/i915: Fix SDVO CREATE_PREFERRED_INPUT_TIMING command drm/i915: Fix SDVO TV support drivers/gpu/drm/drm_gem.c |7 +- drivers/gpu/drm/drm_sysfs.c |1 + drivers/gpu/drm/i915/i915_dma.c |9 +-- drivers/gpu/drm/i915/i915_drv.h |5 + drivers/gpu/drm/i915/i915_gem.c | 38 +-- drivers/gpu/drm/i915/i915_gem_debug.c |2 + drivers/gpu/drm/i915/i915_gem_debugfs.c |6 + drivers/gpu/drm/i915/i915_gem_tiling.c | 16 +++ drivers/gpu/drm/i915/i915_irq.c | 67 ++- drivers/gpu/drm/i915/i915_reg.h | 11 ++ drivers/gpu/drm/i915/intel_crt.c|4 +- drivers/gpu/drm/i915/intel_display.c| 22 - drivers/gpu/drm/i915/intel_modes.c |1 + drivers/gpu/drm/i915/intel_sdvo.c | 193 +-- drivers/gpu/drm/i915/intel_sdvo_regs.h |3 + drivers/gpu/drm/i915/intel_tv.c | 30 - 16 files changed, 292 insertions(+), 123 deletions(-) -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Remove code for tracking per-drawable cliprects.
On Thu, 2009-04-02 at 14:41 -0400, Kristian Høgsberg wrote: This was only used by the i915 driver for the swapbuffer vsync tasklet. That functionality is now gone and nothing uses the kernel side cliprects anymore. Just stub out the ioctls, but make sure we return a non-zero handle in the DRM_IOCTL_ADD_DRAW case. Have you tested old userland to make sure it doesn't freak out? Other than that, I love the idea. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] KMS: cache the EDID information of the LVDS
On Fri, 2009-03-27 at 22:01 -0700, Arjan van de Ven wrote: On Fri, 27 Mar 2009 16:08:18 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: return ret; I definitely like the idea of caching the LVDS EDID, but rather than adding it to the intel_output struct I'd rather see it stored with the rest of the LVDS stuff in i915_private (though that stuff should be pulled out into an output private at some point). We could also just open code the intel_ddc_get_modes stuff in intel_lvds_init, getting the EDID just once, storing the property once, and adding the mode list once. intel_lvds_get_modes would need to be fixed too... that gets a bit messy though, esp if other output types decide to also want to cache. Remember that some of this code gets called from DRM or even userland, so the edid will end up being stored in a generic structure Ack. SDVO LVDS and eDP would also want to do this, and i915_private then seems like the wrong place. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
