Re: drm: Branch 'master' - 2 commits

[Eric Anholt]

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 
> 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 

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

[Eric Anholt]

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™ now supports Android™ Apps 
for the BlackBerry® PlayBook™. 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.

[Eric Anholt]

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'

[Eric Anholt]

On Tue, 31 Aug 2010 12:17:43 +0200, Zdenek Kabelac  wrote:
> Dne 28.8.2010 05:55, Eric Anholt napsal(a):
> > On Fri, 27 Aug 2010 13:16:04 +0200, Zdenek Kabelac  
> > 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
> drm&intel 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'

[Eric Anholt]

On Fri, 27 Aug 2010 13:16:04 +0200, Zdenek Kabelac  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()

[Eric Anholt]

On Thu, 27 May 2010 13:37:56 -0400, Prarit Bhargava  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 
> 
> 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

[Eric Anholt]

On Fri, 18 Jun 2010 16:51:02 +0800, april  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] i915: missing unlock on error path

[Eric Anholt]

On Fri, 7 May 2010 10:37:01 +0200, Dan Carpenter  wrote:
> There was a missing mutex_unlock(&dev->struct_mutex) on this error path.
> 
> Signed-off-by: Dan Carpenter 
> ---
> 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 -next] i915: remove unneeded null checks

[Eric Anholt]

On Fri, 7 May 2010 10:39:00 +0200, Dan Carpenter  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 

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 -next] i915/intel_sdvo: remove unneeded null check

[Eric Anholt]

On Fri, 7 May 2010 10:40:09 +0200, Dan Carpenter  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: [2.6.34, patch] i915: fix lock imbalance on error path...

[Eric Anholt]

On Mon, 17 May 2010 14:23:52 +0100, Daniel J Blueman  
wrote:
> While investigating Intel i5 Arrandale GPU lockups with -rc4, I
> noticed a lock imbalance.
> 
> Signed-off-by: Daniel J Blueman 

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] drm/i915: Convert more trace events to DEFINE_EVENT

[Eric Anholt]

On Mon, 24 May 2010 16:25:44 +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.

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: [PATCH] drm/i915: Convert more trace events to DEFINE_EVENT

[Eric Anholt]

On Tue, 25 May 2010 16:08:46 -0400, Steven Rostedt  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 
> 
> 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] i915: Skip wrong TV outputs on HP laptop

[Eric Anholt]

On Tue, 20 Apr 2010 14:50:54 +0200, Takashi Iwai  wrote:
> A new HP laptop with GM45 seems detecting wrongly TV outputs
> occasionally.  Most of time it detects the TV output as disconnected,
> but spontaneously it detects NTSC 480i although the laptop has no TV
> output at all.
> 
> A simple (but ad hoc) fix is to add a DMI check as below.
> 
> Signed-off-by: Takashi Iwai 

Does this laptop have no TV connector on the laptop or the dock for it?


pgp66Tbup43qL.pgp
Description: PGP signature
--
Download Intel® 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

[Eric Anholt]

On Tue, 13 Apr 2010 15:33:05 +1000, Dave Airlie  wrote:
> On Tue, Apr 13, 2010 at 5:19 AM, Daniel Vetter  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  
> >> 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® 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

[Eric Anholt]

On Thu, 8 Apr 2010 21:41:59 +0200, Luca Tettamanti  wrote:
> ->dev_private at that point is NULL and is initialied only a few lines
> later.
> 
> Signed-off-by: Luca Tettamanti 
> ---
> I'm beginnig to dive into DRM&KMS, that assignment really confused me :P

Applied.  Thanks!


pgppXukviO6Hj.pgp
Description: PGP signature
--
Download Intel® 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

[Eric Anholt]

On Fri,  9 Apr 2010 21:05:03 +0200, Daniel Vetter  
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® 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

[Eric Anholt]

On Mon, 29 Mar 2010 17:53:12 +0200, Stefan Bader  
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® 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

[Eric Anholt]

On Fri, 19 Mar 2010 16:30:48 +0100, Hubert Hesse  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® 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: ACPI _LID failures

[Eric Anholt]

On Fri, 19 Mar 2010 12:53:20 -0700, Jesse Barnes  
wrote:
> On Mon, 15 Mar 2010 21:32:41 +0200
> Surbhi Palande  wrote:
> 
> > The following two patches are quirks that blacklist bios which report
> > incorrect lid status. These are bioses for machines with a 900 GM.
> > The first one is tested by Ubuntu users and the second one isn't.
> > Further testing will be appreciated.
> > 
> > 
> > Surbhi Palande (2):
> >   drm/i915: blacklist lid status: Sony VGN-BX196VP
> >   drm/i915: blacklist lid status: Elite Co. G335
> > 
> >  drivers/gpu/drm/i915/intel_lvds.c |   14 ++
> >  1 files changed, 14 insertions(+), 0 deletions(-)
> 
> Patches look ok to me.  Len was curious about whether some recent ACPI
> EC fixes will fix some of our lid detection bugs though.
> 
> Len, is there any particular patch or version people should try?

Unless ACPI is going to magically become more reliable at the lid
method, I think we should abandon using it on generations where it
fails.  See other patch I submitted -- anyone care to ack it?


pgpLWvFeKlbuJ.pgp
Description: PGP signature
--
Download Intel® 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

[Eric Anholt]

On Thu, 11 Mar 2010 16:41:45 +0800, Li Zefan  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® 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

[Eric Anholt]

On Sat, 6 Mar 2010 12:50:54 +0100, Daniel Vetter  wrote:
> Oh, dang. Thanks for catching this. Eric, please merge.
> 
> Cc: sta...@kernel.org (for .33)
> Reviewed-by: Daniel Vetter 
> 
> On Sat, Mar 06, 2010 at 02:05:39PM +0300, Dan Carpenter wrote:
> > We should free "params" before returning.
> > 
> > Signed-off-by: Dan Carpenter 

Applied.  Thanks!


pgpeRvdLq2cWd.pgp
Description: PGP signature
--
Download Intel® 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

[Eric Anholt]

On Fri, 26 Feb 2010 19:07:24 +0100, Julien Cristau  wrote:
> Avoids conflicts with kernel headers.
> 
> Signed-off-by: Julien Cristau 

Applied this series, plus moving the intel file.  Thanks!


pgp9aozTfnYtg.pgp
Description: PGP signature
--
Download Intel® 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.

[Eric Anholt]

On Wed, 10 Mar 2010 18:20:42 +0200, Pauli Nieminen  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® 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

[Eric Anholt]

On Fri, 5 Mar 2010 12:21:29 +, Alan Cox  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® 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?

[Eric Anholt]

On Thu, 4 Mar 2010 12:37:23 -0800, Jesse Barnes  
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® 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

[Eric Anholt]

On Tue,  2 Mar 2010 22:59:52 +0200, Surbhi Palande 
 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 

As far as I know, this should already be covered by:

commit 7b9c5abee98c54f85bcc04bd4d7ec8d5094c73f4
Author: Jesse Barnes 
Date:   Fri Feb 12 09:30:00 2010 -0800

drm/i915: give up on 8xx lid status


pgpNe85gsm2Yr.pgp
Description: PGP signature
--
Download Intel® 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

[Eric Anholt]

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® 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

[Eric Anholt]

On Mon, 1 Mar 2010 18:33:14 +1000, Dave Airlie  wrote:
> On Sun, Feb 28, 2010 at 1:30 PM, Ben Hutchings  wrote:
> > This addresses .
> >
> > 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 
> > ---
> > 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® 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 / PM: Fix crash while aborting hibernation (Re: [linux-pm] [regression] "drm/i915: implement new pm ops" disables irq on aborted s2disk)

[Eric Anholt]

On Sun, 7 Feb 2010 21:48:24 +0100, "Rafael J. Wysocki"  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: introduce drm_gem_object_[handle_]unreference_unlocked

[Eric Anholt]

On Tue,  9 Feb 2010 06:49:11 +0100, Luca Barbieri  
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: drm: Branch 'master'

[Eric Anholt]

On Tue,  9 Feb 2010 00:38:05 -0800 (PST), ic...@kemper.freedesktop.org (Chris 
Wilson) wrote:
>  intel/intel_bufmgr_gem.c |   13 +
>  1 file changed, 13 insertions(+)
> 
> New commits:
> commit fdcde592c2c48e143251672cf2e82debb07606bd
> Author: Chris Wilson 
> Date:   Tue Feb 9 08:32:54 2010 +
> 
> intel: Account for potential pinned buffers hogging fences
> 
> As the kernel reports the total number of fences, we must guess how many
> fences are likely to be pinned. In the typical system these will be only
> used by the scanout buffers, of which there may be one per pipe, and any
> number of manually pinned fenced buffers. So take a conservative guess
> and reserve two fences for use by the system.
> 
> Note this reduces the number of fences to 3 for i915 and prior.

(on a non-2.6.33 KMS kernel)


pgphRCRvGshO0.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.

[Eric Anholt]

On Thu,  4 Feb 2010 06:29:05 +1000, Dave Airlie  wrote:
> From: Dave Airlie 
> 
> 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

[Eric Anholt]

On Sun, 24 Jan 2010 00:55:59 +0100, "Rafael J. Wysocki"  wrote:
> From: Rafael J. Wysocki 
> 
> 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 
> ---
> 
> 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 


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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: enable 36bit physical address for hardware status page

[Eric Anholt]

On Tue,  5 Jan 2010 11:25:06 +0800, Zhenyu Wang  wrote:
> This enables possible 36bit address mask on 965G that use physical
> address for hw status page.
> 
> Signed-off-by: Zhenyu Wang 

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

[PATCH] drm: Don't spam dmesg whenver a video mode is changed.

[Eric Anholt]

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 
---
 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: [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS

[Eric Anholt]

On Sat, 9 Jan 2010 00:45:33 +0100, "Rafael J. Wysocki"  wrote:
> From: Rafael J. Wysocki 
> 
> 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 

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

[Eric Anholt]

On Tue, 17 Nov 2009 14:08:52 -0800, a...@linux-foundation.org wrote:
> From: Andrew Morton 
> 
> 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 
> Cc: Eric Anholt 
> Cc: Dave Airlie 
> Signed-off-by: Andrew Morton 

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

[Eric Anholt]

On Mon, 4 Jan 2010 17:27:45 +0800, Zhenyu Wang  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

[Eric Anholt]

On Wed, 23 Dec 2009 14:14:34 +0100, Tobias Klauser  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 
> ---
>  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

[Eric Anholt]

On Tue, 8 Dec 2009 17:24:21 +0100, Helge Bahmann  
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

[Eric Anholt]

On Fri,  4 Dec 2009 11:08:00 +1000, Dave Airlie  wrote:
> From: Dave Airlie 
> 
> 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 


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

[Eric Anholt]

On Fri, 4 Dec 2009 23:22:51 +0100, Rafał Miłecki  wrote:
> 2009/12/4 Dave Airlie :
> > On Fri, 2009-12-04 at 20:05 +0800, yakui.z...@intel.com wrote:
> >> From: Zhao Yakui 
> >>
> >> 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] drm/i915: Fix sync to vblank when VGA output is turned off

[Eric Anholt]

On Mon, 09 Nov 2009 12:51:22 +0800, Li Peng  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 

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: [Intel-gfx] [PATCH 1/2] drm/i915: add GETPARAM request for page flipping

[Eric Anholt]

On Thu, 19 Nov 2009 10:49:07 -0800, Jesse Barnes  
wrote:
> From 3dea813806ecc117fadd2751580018040afefd0b Mon Sep 17 00:00:00 2001
> From: Jesse Barnes 
> 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 

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 
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 
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 
Signed-off-by: Eric Anholt 

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: [BUG][BISECTED][RESENT] Ogre3d produces black screen on Intel 965GM

[Eric Anholt]

On Wed, 25 Nov 2009 22:38:30 +0100, Dariush Forouher  
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 
> 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 
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

[Eric Anholt]

On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote:
> 2009/11/6 Kristian Høgsberg :
> > 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

[Eric Anholt]

On Sun, 2009-11-08 at 23:40 +0100, Stephane Marchesin wrote:
> On Sun, Nov 8, 2009 at 23:33, Eric Anholt  wrote:
> > On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote:
> >> On Sun, Nov 8, 2009 at 20:02, Eric Anholt  wrote:
> >> > On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote:
> >> >> On Sun, Nov 8, 2009 at 19:18, Eric Anholt  wrote:
> >> >> > On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote:
> >> >> >> 2009/11/6 Kristian Høgsberg :
> >> >> >> > 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

Re: RFC: libdrm repo

[Eric Anholt]

On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote:
> On Sun, Nov 8, 2009 at 20:02, Eric Anholt  wrote:
> > On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote:
> >> On Sun, Nov 8, 2009 at 19:18, Eric Anholt  wrote:
> >> > On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote:
> >> >> 2009/11/6 Kristian Høgsberg :
> >> >> > 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: libdrm repo

[Eric Anholt]

On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote:
> On Sun, Nov 8, 2009 at 19:18, Eric Anholt  wrote:
> > On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote:
> >> 2009/11/6 Kristian Høgsberg :
> >> > 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

[Eric Anholt]

On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote:
> 2009/11/6 Kristian Høgsberg :
> > 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] DRI2 synchronization and swap bits

[Eric Anholt]

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

[Eric Anholt]

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  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

[Eric Anholt]

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 
> ---
>  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: [Intel-gfx] [PATCH 0/8] drmmode overlay support v3

[Eric Anholt]

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 BlackBerry® 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/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: [PATCH] i915: Fix i2c init message

[Eric Anholt]

On Wed, 2009-09-30 at 14:26 -0600, Tim Gardner wrote:
> >From 8ef5591fa4392b4228b0be97013a8218f267ef90 Mon Sep 17 00:00:00 2001
> From: Tim Gardner 
> 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 
> 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 BlackBerry® 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/devconf--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Re: Linux 2.6.31-rc7

[Eric Anholt]

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

[Eric Anholt]

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 
> ---
>  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: [git pull] drm: previous pull req + 1.

[Eric Anholt]

On Mon, 2009-06-29 at 08:57 +0100, Chris Wilson wrote:
> On Mon, 2009-06-22 at 21:09 +0300, Maxim Levitsky wrote:
> > Nope, same thing.
> > 
> > I use commit 87ef92092fd092936535ba057ee19b97bb6a709a + this patch
> > Note that GE doesn't hang the system when maximizing it.
> > 
> > It is for sure tiled textures accessed incorrectly, same behavior
> > observed in many games (they still run though)
> 
> Sorry for the delay, I was travelling last week and was sure I had
> nailed the problem. Aside from the missing flush on i965 when a batch
> buffer might be using fenced commands, the only other issue I found was
> that we did not zap the mapping range on clear - which could also cause
> tiling errors if textures were being written via a GTT mmap.
> 
> So please can you try this patch:
> 
> >From 20b7c9322914213bb589035afbbc03faf1ae3bf0 Mon Sep 17 00:00:00 2001
> From: Chris Wilson 
> Date: Mon, 29 Jun 2009 08:45:31 +0100
> Subject: [PATCH] drm/i915: Remove mappings on clearing fence register
> 
> As the fence register is not locked whilst the user has mmaped the buffer
> through the GTT, in order for the buffer to reacquire a fence register we
> need to cause a fresh page-fault on the next user access. In order to
> cause the page fault, we zap the current mapping on clearing the register.
> We also ensure that all potential outstanding access via the fence
> register is flushed before release as well.
> 
> Signed-off-by: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem.c |   41 ++
>  1 files changed, 19 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 685a876..6dc74c8 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -1946,12 +1946,6 @@ i915_gem_object_unbind(struct drm_gem_object *obj)
>   obj_priv->agp_mem = NULL;
>   }
>  
> -
> - /* blow away mappings if mapped through GTT */
> - if (obj_priv->mmap_offset && dev->dev_mapping)
> - unmap_mapping_range(dev->dev_mapping,
> - obj_priv->mmap_offset, obj->size, 1);
> -

Err, so now untiled things wouldn't fault to rebind?  Seems wrong.


> @@ -2456,6 +2451,11 @@ i915_gem_clear_fence_reg(struct drm_gem_object *obj)
>  
>   dev_priv->fence_regs[obj_priv->fence_reg].obj = NULL;
>   obj_priv->fence_reg = I915_FENCE_REG_NONE;
> +
> + /* blow away mappings if mapped through GTT */
> + if (obj_priv->mmap_offset && dev->dev_mapping)
> + unmap_mapping_range(dev->dev_mapping,
> + obj_priv->mmap_offset, obj->size, 1);
>  }

This part seems good.

>  
>  /**
> @@ -2469,27 +2469,24 @@ i915_gem_clear_fence_reg(struct drm_gem_object *obj)
>  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;
> + int ret;
>  
>   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 there is outstanding activity on the buffer whilst it holds
> +  * a fence register we must assume that it requires that fence for
> +  * correct operation. 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_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);
> + i915_gem_clear_fence_reg(obj);
>  
>   return 0;
>  }

This part doesn't make sense to me.  There should be nothing in the 965
rendering path that's using fences.  Did you identify something that
was?

-- 
Eric Anholt
e...@anholt.net eric.anh...@intel.com




signature.asc
Description: This is a digitally signed message part
--
Enter the Bla

Re: [Intel-gfx] [PATCH] drm/i915: allow frame buffers up to 4096x4096 on pre-965 chipsets

[Eric Anholt]

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 
> ---
>  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: [Intel-gfx] [PATCH] drm/i915: allow frame buffers up to 4096x4096 on pre-965 chipsets

[Eric Anholt]

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 3/6] i830_bind_memory: Use dri_bo_pin under GEM. Pin when ACCEL_NONE.

[Eric Anholt]

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 
> ---
>  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: X server hung, kernel said "task blocked for >120 secs" (2.6.30)

[Eric Anholt]

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: [i855GME] [Kernel 2.6.30] intel_crt_load_detect() not working?

[Eric Anholt]

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: [PATCH] drm: remove root requirement from DRM_IOCTL_SET_VERSION

[Eric Anholt]

On Wed, 2009-07-01 at 09:55 -0700, Jesse Barnes wrote:
> On Tue, 30 Jun 2009 23:43:19 -0700
> Eric Anholt  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 
> > Acked-by: Eric Anholt 
> 
> 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: [PATCH] drm: remove root requirement from DRM_IOCTL_SET_VERSION

[Eric Anholt]

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 
Acked-by: Eric Anholt 

-- 
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

[Eric Anholt]

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 
> > > 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

[Eric Anholt]

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 
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

[Eric Anholt]

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

[Eric Anholt]

On Tue, 2009-06-09 at 18:46 -0700, Jesse Barnes wrote:
> On Wed, 10 Jun 2009 09:06:47 +0800
> yakui_zhao  wrote:
> 
> > On Wed, 2009-06-10 at 06:35 +0800, Jesse Barnes wrote:
> > > On Tue, 09 Jun 2009 15:16:53 -0700
> > > Eric Anholt  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: [Patch 0/2] [DRM] :add the CVT/GTF algorithm in kernel space

[Eric Anholt]

On Mon, 2009-05-11 at 10:52 +0800, yakui_zhao wrote:
> Hi, All
> 
>   This is the patch set to add the CVT/GTF algorithm in kernel space. 
> They are based on
> the CVT/GTF function in xserver. But the CVT/GTF algorithm in xserver is 
> realized by using float-point
> calculation. And the float-point calculation had better be avoided in kernel 
> space. I translate them
> by using 32-bit integer calculation.
>   Patch 1/2. Add the CVT algorithm . 
>   The CVT function can be called to generate the required modeline based 
> on the input parameters
> Patch 2/2. Add the GTF algorithm
>   The GTF function can be called to generate the required modeline based 
> on the input parameters.
> 
>   
> Welcome the comments.
> 
> Best regards.
> Yakui

Is this getting hooked up to actual EDID decode so it does something?

-- 
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

[Eric Anholt]

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: [Intel-gfx] [PATCH 13/17] drm/i915: Hook up display port

[Eric Anholt]

imits[INTEL_LIMIT_G4X_DISPLAY_PORT];
>   } else /* The option is for other outputs */
>   limit = &intel_limits[INTEL_LIMIT_I9XX_SDVO_DAC];
>  
> @@ -635,6 +683,35 @@ intel_g4x_find_best_PLL(const intel_limit_t *limit, 
> struct drm_crtc *crtc,
>   return found;
>  }
>  
> +/* DisplayPort has only two frequencies, 162MHz and 270MHz */
> +static bool
> +intel_find_pll_g4x_dp(const intel_limit_t *limit, 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: [Intel-gfx] [PATCH 12/17] drm/i915: Import DisplayPort code

[Eric Anholt]

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 17/17] drm/i915: Track DisplayPort DPMS state to retrain on hotplug as needed

[Eric Anholt]

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 
> ---
>  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 16/17] drm/i915: Attempt to make DP suspend/resume work a bit more

[Eric Anholt]

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 
> ---
>  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 15/17] drm/i915: Use drm_helper_connector_dpms for DisplayPort

[Eric Anholt]

On Sat, 2009-05-30 at 20:42 -0700, Keith Packard wrote:
> Signed-off-by: Keith Packard 

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 08/17] drm/i915: add per-output hotplug callback

[Eric Anholt]

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: [RFC] [Patch] [DRM/I915] :Add a debufs I/F to dump the I915 register

[Eric Anholt]

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: [PATCH] drm: i915: ensure objects are allocated below 4GB on PAE

[Eric Anholt]

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: [PATCH] drm: i915: ensure objects are allocated below 4GB on PAE

[Eric Anholt]

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 
> > 
> > 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

[Eric Anholt]

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: [Intel-gfx] [PATCH V1] drm: export get and put connector type id

[Eric Anholt]

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 
> ---
>  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 /*

Re: [PATCH] drm: Copy back ioctl data to userspace regardless of return code.

[Eric Anholt]

On Wed, 2009-05-20 at 13:32 +0200, Michel Dänzer wrote:
> From: Michel Dänzer 
> 
> 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 

Reviewed-by: Eric Anholt 

(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

[Eric Anholt]

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 
> Tested-by: Bill Nottingham 

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 2/2] Bump to version 2.4.10 to mark addition of drm_intel_bo_disable_reuse

[Eric Anholt]

On Tue, 2009-05-12 at 15:36 -0700, Keith Packard wrote:
> New API, new version.
> 
> Signed-off-by: Keith Packard 

For both:

Reviewed-by: Eric Anholt 

-- 
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] libdrm/intel: add drm_intel_bo_disable_reuse api

[Eric Anholt]

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 

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: [RFC] [Patch 1/2] [intel-gfx] : Add the CVT algorithm in kernel space

[Eric Anholt]

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 
> > 
> > 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

[Eric Anholt]

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 

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

[Eric Anholt]

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 
> > ---
> >  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

[Eric Anholt]

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  wrote:
> 
> > >From a121507f31e37a809dfa21c9756aa83f36d7acbf Mon Sep 17 00:00:00
> > >2001
> > From: Arjan van de Ven 
> > 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 
> 
> 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 

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: [Intel-gfx] [PATCH] i915: add page flipping support

[Eric Anholt]

_handler);
>   dev_priv->mm.next_gem_seqno = 1;
> + spin_lock_init(&dev_priv->vblank_lock);
>  
>   /* Old X drivers will take 0-2 for front, back, depth buffers
> */ dev_priv->fence_reg_start = 3;
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c index ee7ce7b..94aee6b 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -196,6 +196,35 @@ static void i915_hotplug_work_func(struct
> work_struct *work) drm_sysfs_hotplug_event(dev);
>  }
>  
> +static void i915_vblank_work_func(struct work_struct *work)
> +{
> + drm_i915_private_t *dev_priv = container_of(work,
> drm_i915_private_t,
> + vblank_work);
> + struct drm_device *dev = dev_priv->dev;
> + struct drm_i915_gem_object *obj_priv, *tmp;
> + unsigned long irqflags;
> + int pipe, cur_seqno;
> +
> + mutex_lock(&dev->struct_mutex);
> +
> + spin_lock_irqsave(&dev_priv->vblank_lock, irqflags);
> + for (pipe = 0; pipe < 2; pipe++) {
> + list_for_each_entry_safe(obj_priv, tmp,
> +
> &dev_priv->mm.vblank_list[pipe],
> +  vblank_head) {
> + cur_seqno = i915_get_gem_seqno(dev);
> + if (i915_seqno_passed(cur_seqno,
> +   obj_priv->flip_seqno)) {
> + list_del_init(&obj_priv->vblank_head);
> + drm_vblank_put(dev, pipe);
> + complete(&obj_priv->vblank);
> + }
> + }
> + }
> + spin_unlock_irqrestore(&dev_priv->vblank_lock, irqflags);
> + mutex_unlock(&dev->struct_mutex);
> +}
> +
>  irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
>  {
>   struct drm_device *dev = (struct drm_device *) arg;
> @@ -292,6 +321,9 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)
>   drm_handle_vblank(dev, 1);
>   }
>  
> + if (vblank)
> + schedule_work(&dev_priv->vblank_work);
> +
>   if ((pipeb_stats & 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 (1<<0) /* 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

Re: A17 tiling series V2

[Eric Anholt]

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 
> 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 
> ---
>  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/drive

Re: [PATCH] fix unpaired i915 device mutex

[Eric Anholt]

On Sat, 2009-04-18 at 10:43 +0800, Wu Fengguang wrote:
> Signed-off-by: Wu Fengguang 
> ---
>  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: [PATCH] drm/i915: Remove duplicated code

[Eric Anholt]

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 
> ---
>  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

[git pull] Fixes for 2.6.30-rc1

[Eric Anholt]

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

[PATCH 2/2] drm/i915: Allow tiling of objects with bit 17 swizzling by the CPU.

[Eric Anholt]

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 
---
 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;
+ 

A17 tiling series V2

[Eric Anholt]

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 1/2] drm/i915: Correctly set the write flag for get_user_pages in pread.

[Eric Anholt]

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 
---
 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

Re: [PATCH] Remove code for tracking per-drawable cliprects.

[Eric Anholt]

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  wrote:
> > 2009/4/2 Eric Anholt :
> >> 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