Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes

2009-03-20 Thread Daniel Stone
Greg,

On Thu, Mar 19, 2009 at 09:27:19AM -0700, Greg KH wrote:
 On Thu, Mar 19, 2009 at 12:03:09PM -0400, Sindhudweep Sarkar wrote:
  TI-OMAP 3xxx and a couple of other arm processors use similar SGX-5xx
  graphics cores. IIRC arm is often little endian so perhaps a unified
  driver would be easier in the long term.
 
 Long term lots of things are good.
 
 But how do I get my laptop that I currently have right now up and
 running properly with linux in a better-than-800x600-framebuffer mode?
 
 That's why I need/want this driver now, there are hundreds of thousands
 of these types of laptops in the pipeline to users and I want them to
 run Linux, not be forced to run some other operating system...

By the same logic, would you support including the proprietary NVIDIA
driver while we wait for Nouveau to catch up?

Cheers,
Daniel


signature.asc
Description: Digital signature
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[PATCH] drm: read EDID extensions from monitor (v2)

2009-03-20 Thread Ma Ling
Usually drm read basic EDID, that is enough for us, but because digital display 
in introduced
i.e. HDMI monitor, sometime we need to interact with monitor by EDID extension 
information,
including audio/video data block, speaker allocation and vendor specific data 
block...
This patch intends to read EDID extensions(max 4) from digital monitor for user.

Signed-off-by: Ma Ling ling...@intel.com
---
In this version drm will read max number if the number of edid extensions is 
over max number.

 drivers/gpu/drm/drm_edid.c |  121 +--
 include/drm/drm_crtc.h |3 +-
 2 files changed, 95 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a839a28..fab2bdf 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -550,11 +550,20 @@ static int add_detailed_info(struct drm_connector 
*connector,
 }
 
 #define DDC_ADDR 0x50
-
-unsigned char *drm_do_probe_ddc_edid(struct i2c_adapter *adapter)
+/**
+ * Get EDID information via I2C.
+ *
+ * \param adapter : i2c device adaptor
+ * \param buf : EDID data buffer to be filled
+ * \param len : EDID data buffer length
+ * \return 0 on success or -1 on failure.
+ *
+ * Try to fetch EDID information by calling i2c driver function.
+ */
+int drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
+ unsigned char *buf, int len)
 {
unsigned char start = 0x0;
-   unsigned char *buf = kmalloc(EDID_LENGTH, GFP_KERNEL);
struct i2c_msg msgs[] = {
{
.addr   = DDC_ADDR,
@@ -564,31 +573,36 @@ unsigned char *drm_do_probe_ddc_edid(struct i2c_adapter 
*adapter)
}, {
.addr   = DDC_ADDR,
.flags  = I2C_M_RD,
-   .len= EDID_LENGTH,
+   .len= len,
.buf= buf,
}
};
 
-   if (!buf) {
-   dev_warn(adapter-dev, unable to allocate memory for EDID 
-block.\n);
-   return NULL;
-   }
-
if (i2c_transfer(adapter, msgs, 2) == 2)
-   return buf;
+   return 0;
 
dev_info(adapter-dev, unable to read EDID block.\n);
-   kfree(buf);
-   return NULL;
+   return -1;
 }
 EXPORT_SYMBOL(drm_do_probe_ddc_edid);
 
-static unsigned char *drm_ddc_read(struct i2c_adapter *adapter)
+/**
+ * Get EDID information.
+ *
+ * \param adapter : i2c device adaptor.
+ * \param buf : EDID data buffer to be filled
+ * \param len : EDID data buffer length
+ * \return 0 on success or -1 on failure.
+ *
+ * Initialize DDC, then fetch EDID information
+ * by calling drm_do_probe_ddc_edid function.
+ */
+static int drm_ddc_read(struct i2c_adapter *adapter,
+   unsigned char *buf, int len)
 {
struct i2c_algo_bit_data *algo_data = adapter-algo_data;
-   unsigned char *edid = NULL;
int i, j;
+   int ret = -1;
 
algo_data-setscl(algo_data-data, 1);
 
@@ -616,7 +630,7 @@ static unsigned char *drm_ddc_read(struct i2c_adapter 
*adapter)
msleep(15);
 
/* Do the real work */
-   edid = drm_do_probe_ddc_edid(adapter);
+   ret = drm_do_probe_ddc_edid(adapter, buf, len);
algo_data-setsda(algo_data-data, 0);
algo_data-setscl(algo_data-data, 0);
msleep(15);
@@ -632,7 +646,7 @@ static unsigned char *drm_ddc_read(struct i2c_adapter 
*adapter)
msleep(15);
algo_data-setscl(algo_data-data, 0);
algo_data-setsda(algo_data-data, 0);
-   if (edid)
+   if (ret == 0)
break;
}
/* Release the DDC lines when done or the Apple Cinema HD display
@@ -641,9 +655,31 @@ static unsigned char *drm_ddc_read(struct i2c_adapter 
*adapter)
algo_data-setsda(algo_data-data, 1);
algo_data-setscl(algo_data-data, 1);
 
-   return edid;
+   return ret;
+}
+
+static int drm_ddc_read_edid(struct drm_connector *connector,
+struct i2c_adapter *adapter,
+char *buf, int len)
+{
+   int ret;
+
+   ret = drm_ddc_read(adapter, buf, len);
+   if (ret != 0) {
+   dev_info(connector-dev-pdev-dev, %s: no EDID data\n,
+drm_get_connector_name(connector));
+   goto end;
+   }
+   if (!edid_is_valid((struct edid *)buf)) {
+   dev_warn(connector-dev-pdev-dev, %s: EDID invalid.\n,
+drm_get_connector_name(connector));
+   ret = -1;
+   }
+end:
+   return ret;
 }
 
+#define MAX_EDID_EXT_NUM 4
 /**
  * drm_get_edid - get EDID data, if available
  * @connector: connector we're probing
@@ -656,24 +692,53 @@ static unsigned char *drm_ddc_read(struct i2c_adapter 

Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes

2009-03-20 Thread Greg KH
On Thu, Mar 19, 2009 at 09:40:08PM +0100, Thomas Hellström wrote:
 Greg KH wrote:
 On Thu, Mar 19, 2009 at 11:14:35AM +0100, Thomas Hellström wrote:
   
 First off, the non-staging patches need more complete changelog entries,
 a bit of meaning goes a long way. I'll ack them if they are documented 
 and
 make sense. The unlocked ioctl hook makes sense to me at least!
 
 For the non-staging patches, (which also sit in the modesetting-newttm 
 tree), I can add some more elaborate comments. However I think all of
 them are targeted to support functionality for TTM, so unless the TTM
 code goes into staging or mainstream, there is little point in merging
 them to core drm before other drivers find them useful.

 Although I see the patch adding TTM is including some backwards
 compatibility defines (In particular the PAT compat stuff) that needs
 to be stripped.
 

 Great, care to respin it and send it to me?

 Greg,
 A clean TTM patch was sent to Intel with the other patches.
 I'm not sure why it got lost along the way?

As there seems to be an unknown number of people in the intel chain
that resulted in me finally getting these patches, I don't hold out much
hope that I'm going to be able to get more than what I already got from
them :(

So, any chance you could just resend it?  I'll be glad to trade it for a
beer at the next conference :)

thanks,

greg k-h

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Patch 0/3]: the patch set for kms about LVDS

2009-03-20 Thread yakui_zhao
Hi
the following is the patch set for KMS about LVDS. 
patch 01: Sync the mode validation for INTERLACE/DBLSCAN
  Check whether the INTERLACE/DBLSCAN is supported by the output 
device. If
it is unsupported, the mode containing the flag of INTERLACE/DBLSCAN will be 
marked as 
invalidate.
patch 02: Sync the panel fitting property of LVDS with 2D driver
  Add the panel fitting property for LVDS. If the panel fitting 
property is expected to be
reported by xrandr, it will depends on the following patch from Zhengyu Wang:
  
http://lists.freedesktop.org/archives/intel-gfx/2009-March/001610.html
   KMS: hook up the output property
  Otherwise the panel fitting property can't be reported in the 
tool of xrandr.
patch 03: Sync the default modes for LVDS output device
  Add the default modes for LVDS output device. If not, the 
different mode lines are obtained
for LVDS output device in KMS/UMS.
 

Thanks for the comments.
   Yakui






--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Patch 1/3]: [DRM/I915] : Sync the mode validation for INTERLACE/DBLSCAN

2009-03-20 Thread yakui_zhao
Subject: [DRM/I915]: Sync the mode validation for INTERLACE/DBLSCAN
From: Zhao Yakui yakui.z...@intel.com

 Sync the mode validation for INTERLACE/DBLSCAN
 This covers:
 Check whether the INTERLACE/DBLSCAN is supported by output device. If
not, the mode containing the flag of INTERLACE/DBLSCAN will be marked
as unsupported.

Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
 drivers/gpu/drm/drm_crtc_helper.c |   25 +
 1 file changed, 25 insertions(+)

Index: linux-2.6/drivers/gpu/drm/drm_crtc_helper.c
===
--- linux-2.6.orig/drivers/gpu/drm/drm_crtc_helper.c2009-03-20 
11:47:32.0 +0800
+++ linux-2.6/drivers/gpu/drm/drm_crtc_helper.c 2009-03-20 13:36:22.0 
+0800
@@ -41,6 +41,23 @@
   968, 1056, 0, 600, 601, 605, 628, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
 };
+static void drm_mode_validate_flag(struct drm_connector *connector,
+   int flags)
+{
+   struct drm_display_mode *mode, *t;
+   if (flags == (DRM_MODE_FLAG_DBLSCAN |
+   DRM_MODE_FLAG_INTERLACE))
+   return ;
+
+   list_for_each_entry_safe(mode, t, connector-modes, head) {
+   if (mode-flags  DRM_MODE_FLAG_INTERLACE 
+   !(flags  DRM_MODE_FLAG_INTERLACE))
+   mode-status = MODE_NO_INTERLACE;
+   if (mode-flags  DRM_MODE_FLAG_DBLSCAN 
+   !(flags  DRM_MODE_FLAG_DBLSCAN))
+   mode-status = MODE_NO_DBLESCAN;
+   }
+}
 
 /**
  * drm_helper_probe_connector_modes - get complete set of display modes
@@ -96,6 +113,14 @@
if (maxX  maxY)
drm_mode_validate_size(dev, connector-modes, maxX,
   maxY, 0);
+   {
+   int flags = (connector-interlace_allowed ?
+   DRM_MODE_FLAG_INTERLACE : 0) |
+   (connector-doublescan_allowed ?
+   DRM_MODE_FLAG_DBLSCAN : 0);
+   drm_mode_validate_flag(connector, flags);
+
+   }
list_for_each_entry_safe(mode, t, connector-modes, head) {
if (mode-status == MODE_OK)
mode-status = connector_funcs-mode_valid(connector,



--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes

2009-03-20 Thread Greg KH
On Thu, Mar 19, 2009 at 02:11:18PM -0400, Sindhudweep Sarkar wrote:
 Of course real support for poulsbo is really important and desirable
 since netbooks make such a huge percentage of computer sales these
 days. I'm guessing, however, that the number of
 embedded/mobile/appliance devices that use or will use the SGX5xx is
 much larger than even the plethora of netbooks being pumped out. If
 more hardware support can be gained for a little extra burden why not
 go for it? I would argue that a unified driver stack would actually
 have less maintenance cost since common bugs could be killed. Even
 ignoring all the arm devices that will use that graphics core, what
 about intel's own use of the SGX 535 elsewhere? Does this poulsbo
 driver support the intel CE3100 processors?
 
 
 I think i'm really apprehensive about device specific one-offs. Of
 course a mainline driver upstream is an important step to prevent that
 but without a roadmap it only seems marginally better.

Staging is all aobut device specific one-offs.  the code is then in a
common area where everyone can work to fix it up properly.

I don't want to burry this work again in random git trees that no one
has any clue how to put together, like has already been done in the
past.

thanks,

greg k-h

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes

2009-03-20 Thread Matthew Garrett
On Thu, Mar 19, 2009 at 09:27:19AM -0700, Greg KH wrote:

 But how do I get my laptop that I currently have right now up and
 running properly with linux in a better-than-800x600-framebuffer mode?

You don't, because there's no working X driver.

-- 
Matthew Garrett | mj...@srcf.ucam.org

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Patch 3/3]: [DRM/I915] : Sync the default modes for LVDS output device

2009-03-20 Thread yakui_zhao
Subject: [DRM/I915]: Sync the default modes for LVDS output device
From: Zhao Yakui yakui.z...@intel.com

Sync the default modes for the LVDS output device
This covers:
Add the default modes for the LVDS output device.
The bit of edid-feature.msc indicates whether the display device is not
continous-frequency. And it is used to determine whether the default modes will
be added to the output device.
But for the LVDS output device the edid-feature.msc will always be set.Even
when there is no edid, the corresponding bit in the fake edid will be set.
In such case the default modes will be added to LVDS output device.
If not, the modes obtained by using KMS/UMS will be different.

Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
 drivers/gpu/drm/i915/intel_lvds.c |  422 +-
 1 file changed, 412 insertions(+), 10 deletions(-)

Index: linux-2.6/drivers/gpu/drm/i915/intel_lvds.c
===
--- linux-2.6.orig/drivers/gpu/drm/i915/intel_lvds.c2009-03-20 
11:51:53.0 +0800
+++ linux-2.6/drivers/gpu/drm/i915/intel_lvds.c 2009-03-20 13:36:03.0 
+0800
@@ -36,6 +36,381 @@
 #include intel_drv.h
 #include i915_drm.h
 #include i915_drv.h
+/*
+ * the default modes, which is based on the file of
+ * xserver/xfree86/common/xf86DefModeSet.c.
+ */
+static struct drm_display_mode default_modes[] = {
+   /* 640x...@85hz */
+   { DRM_MODE(640x350, DRM_MODE_TYPE_DRIVER, 31500, 640, 672,
+  736, 832, 0, 350, 382, 385, 445, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 320x...@85hz */
+   { DRM_MODE(320x175, DRM_MODE_TYPE_DRIVER, 15750, 320, 336,
+  368, 416, 0, 175, 191, 192, 222, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+   DRM_MODE_FLAG_DBLSCAN) },
+   /* 640x...@85hz */
+   { DRM_MODE(640x400, DRM_MODE_TYPE_DRIVER, 31500, 640, 672,
+  736, 832, 0, 400, 401, 405, 445, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 320x...@85hz */
+   { DRM_MODE(320x200, DRM_MODE_TYPE_DRIVER, 15750, 320, 336,
+  368, 416, 0, 200, 200, 202, 222, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+   DRM_MODE_FLAG_DBLSCAN) },
+   /* 720x...@85hz */
+   { DRM_MODE(720x400, DRM_MODE_TYPE_DRIVER, 35500, 720, 756,
+  828, 936, 0, 400, 401, 405, 446, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 360x...@85hz */
+   { DRM_MODE(360x200, DRM_MODE_TYPE_DRIVER, 17750, 360, 378,
+  414, 468, 0, 200, 200, 202, 223, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+   DRM_MODE_FLAG_DBLSCAN) },
+   /* 640x...@60hz */
+   { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 25175, 600, 656,
+  752, 800, 0, 480, 490, 492, 525, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 320x...@60hz */
+   { DRM_MODE(320x240, DRM_MODE_TYPE_DRIVER, 12587, 320, 328,
+  376, 400, 0, 240, 245, 246, 262, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+   DRM_MODE_FLAG_DBLSCAN) },
+   /* 640x...@72hz */
+   { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 31500, 640, 664,
+  704, 832, 0, 480, 489, 492, 520, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 320x...@72hz */
+   { DRM_MODE(320x240, DRM_MODE_TYPE_DRIVER, 15750, 320, 332,
+  352, 416, 0, 240, 244, 246, 260, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+   DRM_MODE_FLAG_DBLSCAN) },
+   /* 640x...@75hz */
+   { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 31500, 640, 656,
+  720, 840, 0, 480, 481, 484, 500, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 320x...@75hz */
+   { DRM_MODE(320x240, DRM_MODE_TYPE_DRIVER, 15750, 320, 328,
+  360, 420, 0, 240, 240, 242, 250, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+   DRM_MODE_FLAG_DBLSCAN) },
+   /* 640x...@85hz */
+   { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 36000, 640, 696,
+  752, 832, 0, 480, 481, 484, 509, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 320x...@85hz */
+   { DRM_MODE(320x240, DRM_MODE_TYPE_DRIVER, 18000, 320, 348,
+  376, 416, 0, 240, 240, 242, 254, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
+   DRM_MODE_FLAG_DBLSCAN) },
+   /* 800x...@56hz */
+   { DRM_MODE(800x600, DRM_MODE_TYPE_DRIVER, 36000, 800, 

[Patch 2/3]: [DRM/I915] : Sync the panel fitting property with 2D driver

2009-03-20 Thread yakui_zhao
Subject: DRM/I915: Sync the panel fitting property with 2D driver
From: Zhao Yakui yakui.z...@intel.com

 Sync the panel fitting property with 2D driver
 This covers:
 a. create the scaling mode property and attach it to LVDS
 b. add the support of panel fitting property for LVDS
 c. update the display mode according to the panel fitting mode

Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
 drivers/gpu/drm/i915/i915_reg.h   |   17 ++
 drivers/gpu/drm/i915/intel_lvds.c |  273 +++---
 2 files changed, 269 insertions(+), 21 deletions(-)

Index: linux-2.6/drivers/gpu/drm/i915/intel_lvds.c
===
--- linux-2.6.orig/drivers/gpu/drm/i915/intel_lvds.c2009-03-20 
11:39:38.0 +0800
+++ linux-2.6/drivers/gpu/drm/i915/intel_lvds.c 2009-03-20 11:51:53.0 
+0800
@@ -37,6 +37,21 @@
 #include i915_drm.h
 #include i915_drv.h
 
+/*
+ * the following four scaling options are defined.
+ * #define DRM_MODE_SCALE_NON_GPU  0
+ * #define DRM_MODE_SCALE_FULLSCREEN   1
+ * #define DRM_MODE_SCALE_NO_SCALE 2
+ * #define DRM_MODE_SCALE_ASPECT   3
+ */
+
+/* Private structure for the integrated LVDS support */
+struct intel_lvds_priv {
+   int fitting_mode;
+   u32 pfit_control;
+   u32 pfit_pgm_ratios;
+};
+
 /**
  * Sets the backlight level.
  *
@@ -160,10 +175,24 @@
  struct drm_display_mode *mode,
  struct drm_display_mode *adjusted_mode)
 {
+   /*
+* float point operation is not supported . So the PANEL_RATIO_FACTOR
+* is defined, which can avoid the float point computation when
+* calculating the panel ratio.
+*/
+#define PANEL_RATIO_FACTOR 8192
struct drm_device *dev = encoder-dev;
struct drm_i915_private *dev_priv = dev-dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(encoder-crtc);
struct drm_encoder *tmp_encoder;
+   struct intel_output *intel_output = enc_to_intel_output(encoder);
+   struct intel_lvds_priv *lvds_priv = intel_output-dev_priv;
+   u32 pfit_control = 0, pfit_pgm_ratios = 0;
+   int left_border = 0, right_border = 0, top_border = 0;
+   int bottom_border = 0;
+   bool border = 0;
+   int panel_ratio, desired_ratio, vert_scale, horiz_scale;
+   int horiz_ratio, vert_ratio;
 
/* Should never happen!! */
if (!IS_I965G(dev)  intel_crtc-pipe == 0) {
@@ -179,7 +208,9 @@
return false;
}
}
-
+   /* If we don't have a panel mode, there is nothing we can do */
+   if (dev_priv-panel_fixed_mode == NULL)
+   return true;
/*
 * If we have timings from the BIOS for the panel, put them in
 * to the adjusted mode.  The CRTC will be set up for this mode,
@@ -203,6 +234,184 @@
drm_mode_set_crtcinfo(adjusted_mode, CRTC_INTERLACE_HALVE_V);
}
 
+   /* Make sure pre-965s set dither correctly */
+   if (!IS_I965G(dev)  dev_priv-panel_wants_dither)
+   pfit_control |= PANEL_8TO6_DITHER_ENABLE;
+
+   /* Native modes don't need fitting */
+   if (adjusted_mode-hdisplay == mode-hdisplay 
+   adjusted_mode-vdisplay == mode-vdisplay) {
+   pfit_pgm_ratios = 0;
+   border = 0;
+   goto out;
+   }
+
+   /* 965+ wants fuzzy fitting */
+   if (IS_I965G(dev))
+   pfit_control |= (intel_crtc-pipe  PFIT_PIPE_SHIFT) |
+   PFIT_FILTER_FUZZY;
+
+   /*
+* Deal with panel fitting options. Figure out how to stretch the
+* image based on its aspect ratio  the current panel fitting mode.
+*/
+   panel_ratio = adjusted_mode-hdisplay * PANEL_RATIO_FACTOR /
+   adjusted_mode-vdisplay;
+   desired_ratio = mode-hdisplay * PANEL_RATIO_FACTOR /
+   mode-vdisplay;
+   /*
+* Enable automatic panel scaling for non-native modes so that they fill
+* the screen.  Should be enabled before the pipe is enabled, according
+* to register description and PRM.
+* Change the value here to see the borders for debugging
+*/
+   I915_WRITE(BCLRPAT_A, 0);
+   I915_WRITE(BCLRPAT_B, 0);
+
+   switch (lvds_priv-fitting_mode) {
+   case DRM_MODE_SCALE_NO_SCALE:
+   /*
+* For centered modes, we have to calculate border widths 
+* heights and modify the values programmed into the CRTC.
+*/
+   left_border = (adjusted_mode-hdisplay - mode-hdisplay) / 2;
+   right_border = left_border;
+   if (mode-hdisplay  1)
+   right_border++;
+   top_border = (adjusted_mode-vdisplay - mode-vdisplay) / 2;
+   

[Patch 0/5]: the patch set for kms about LVDS

2009-03-20 Thread yakui_zhao
Hi
the following is the patch set for KMS about LVDS. 
patch 01: Sync the mode validation for INTERLACE/DBLSCAN
  Check whether the INTERLACE/DBLSCAN is supported by the output 
device. If
it is unsupported, the mode containing the flag of INTERLACE/DBLSCAN will be 
marked as 
invalidate.
patch 02: Sync the panel fitting property of LVDS with 2D driver
  Add the panel fitting property for LVDS. If the panel fitting 
property is expected to be
reported by xrandr, it will depends on the following patch from Zhengyu Wang:
  
http://lists.freedesktop.org/archives/intel-gfx/2009-March/001610.html
   KMS: hook up the output property
  Otherwise the panel fitting property can't be reported in the 
tool of xrandr.
patch 03: Sync the default modes for LVDS output device
  Add the default modes for LVDS output device. If not, the 
different mode lines are obtained
for LVDS output device in KMS/UMS.
 

Thanks for the comments.
   Yakui






--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes

2009-03-20 Thread Sindhudweep Sarkar
 Nokia's written and open-sourced some related code for DRM.

 My university is paying me to work on an ARM-based SoC handheld with an
 SGX core, and I might be more into this later. (Y'know, once the device
 is actually out the door.)

 ~ C.


Could you point me to the aforementioned open-sourced drm code?

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes

2009-03-20 Thread Greg KH
On Thu, Mar 19, 2009 at 04:48:54PM +1000, Dave Airlie wrote:
 On Thu, Mar 19, 2009 at 2:08 PM, Greg KH g...@kroah.com wrote:
  Hi,
 
  Here's 5 patches that add the Intel Poulsbo/Morrestown DRM driver to the
  kernel tree.
 
  There are 4 patches that make changes to the DRM core, and one patch
  that adds the DRM driver itself.  The driver is added to the
  drivers/staging/ directory because it is not the final driver that
  Intel wishes to support over time.  The userspace api is going to
  change, and work is currently underway to hook up properly with the
  memory management system.
 
 
  However this work is going to take a while, and in the meantime, users
  want to run Linux on this kind of hardware.  I'd really like to add the
  driver to the staging tree, but it needs these core DRM changes in order
  to get it to work properly.
 
  Originally I had a patch that basically duplicated the existing DRM
  core, and embedded it with these changes and the PSB driver together
  into one big mess of a kernel module.  But Richard convinced me that
  this wasn't the nicest thing to do, and he did work on the PSB code
  and dug out these older DRM patches.
 
  The only thing that looks a bit odd to me is the unlocked ioctl patch,
  Thomas, is that thing really correct?
 
  David, I'd be glad to take the DRM changes through the staging tree, but
  only if you ack them.
 
 First off, the non-staging patches need more complete changelog entries,
 a bit of meaning goes a long way. I'll ack them if they are documented and
 make sense. The unlocked ioctl hook makes sense to me at least!

Heh, that one doesn't make sense to me as it doesn't seem to change any
locking issues :)

I'll write up better changelog comments based on other responses in this
thread.

 Now the non-core DRM driver comes with some caveats no one mentioned,
 only the userspace 2D is open, no userspace 3D is available and I've no idea 
 if
 one is forthcoming. Now I don't know enough about the Poulsbo to say this
 drm implementation is secure and can't DMA over my password file.
 
 There is no upstream X.org driver available for this yet, Ubuntu
 shipped something but really we should be at least seeing X.org and
 Mesa commitments from Intel to supporting this code in the future
 before we go shipping it all in the kernel.

The xorg driver is public, as has been pointed out.

As for the legality of the 3d binary blob, I really have no idea, and
for now, I really don't care, I just want basic 2d to work properly on
my hardware.

 Staging something with a very broken userspace API is going to be an 
 nightmare,

That's exactly what staging is for :)

Seriously, stuff in drivers/staging has horrible userspace api issues,
and has no guarantee to work properly at all in future kernel versions.
That's why we are using the staging tree, it lets users have a common
place to get the latest code to get their hardware working, and lets
developers work together in one place.

See my lkml post yesterday about staging if you have other questions
about it.

 So really I'm NAKing this from ever entering the mainline in its
 current form, without a supporting roadmap and plans for the userspace
 bits.

staging isn't really mainline so much as it is a place to get things
working.

If you want, I'll respin the drm changes and resubmit them.

If you aren't going to want to accept those drm changes, that's fine,
and I have no problem with that.

In that case, I'll just embed a private copy of the drm core in the
psb kernel driver in staging, much like we have done many times already
with wireless drivers.  Yes, it's not the nicest or prettiest thing at
all, but it lets people use their hardware and is a hell of a lot better
than burrying this stuff in random git trees around the world in ways
that no one else can figure out how to get working (like Ubuntu has
already done...)

thanks,

greg k-h

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes

2009-03-20 Thread Matthew Garrett
On Thu, Mar 19, 2009 at 12:02:54PM -0700, Greg KH wrote:
 On Thu, Mar 19, 2009 at 06:53:38PM +, Matthew Garrett wrote:
  On Thu, Mar 19, 2009 at 09:27:19AM -0700, Greg KH wrote:
  
   But how do I get my laptop that I currently have right now up and
   running properly with linux in a better-than-800x600-framebuffer mode?
  
  You don't, because there's no working X driver.
 
 Um, no, I have one right here, seems to work ok.  Richard pointed out
 the public git tree for it.

With current X? If that's been fixed up recently then it's a definite 
improvement, but last I checked it only built against old X servers.

-- 
Matthew Garrett | mj...@srcf.ucam.org

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Patch 0/3]: [DRM/I915] : Sync the mode validation for INTERLACE/DBLSCAN

2009-03-20 Thread yakui_zhao
Subject: [DRM/I915]: Sync the mode validation for INTERLACE/DBLSCAN
From: Zhao Yakui yakui.z...@intel.com

 Sync the mode validation for INTERLACE/DBLSCAN
 This covers:
 Check whether the INTERLACE/DBLSCAN is supported by output device. If
not, the mode containing the flag of INTERLACE/DBLSCAN will be marked
as unsupported.

Signed-off-by: Zhao Yakui yakui.z...@intel.com
---
 drivers/gpu/drm/drm_crtc_helper.c |   25 +
 1 file changed, 25 insertions(+)

Index: linux-2.6/drivers/gpu/drm/drm_crtc_helper.c
===
--- linux-2.6.orig/drivers/gpu/drm/drm_crtc_helper.c2009-03-20 
11:47:32.0 +0800
+++ linux-2.6/drivers/gpu/drm/drm_crtc_helper.c 2009-03-20 13:36:22.0 
+0800
@@ -41,6 +41,23 @@
   968, 1056, 0, 600, 601, 605, 628, 0,
   DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
 };
+static void drm_mode_validate_flag(struct drm_connector *connector,
+   int flags)
+{
+   struct drm_display_mode *mode, *t;
+   if (flags == (DRM_MODE_FLAG_DBLSCAN |
+   DRM_MODE_FLAG_INTERLACE))
+   return ;
+
+   list_for_each_entry_safe(mode, t, connector-modes, head) {
+   if (mode-flags  DRM_MODE_FLAG_INTERLACE 
+   !(flags  DRM_MODE_FLAG_INTERLACE))
+   mode-status = MODE_NO_INTERLACE;
+   if (mode-flags  DRM_MODE_FLAG_DBLSCAN 
+   !(flags  DRM_MODE_FLAG_DBLSCAN))
+   mode-status = MODE_NO_DBLESCAN;
+   }
+}
 
 /**
  * drm_helper_probe_connector_modes - get complete set of display modes
@@ -96,6 +113,14 @@
if (maxX  maxY)
drm_mode_validate_size(dev, connector-modes, maxX,
   maxY, 0);
+   {
+   int flags = (connector-interlace_allowed ?
+   DRM_MODE_FLAG_INTERLACE : 0) |
+   (connector-doublescan_allowed ?
+   DRM_MODE_FLAG_DBLSCAN : 0);
+   drm_mode_validate_flag(connector, flags);
+
+   }
list_for_each_entry_safe(mode, t, connector-modes, head) {
if (mode-status == MODE_OK)
mode-status = connector_funcs-mode_valid(connector,



--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes

2009-03-20 Thread Greg KH
On Thu, Mar 19, 2009 at 11:14:35AM +0100, Thomas Hellström wrote:
 First off, the non-staging patches need more complete changelog entries,
 a bit of meaning goes a long way. I'll ack them if they are documented and
 make sense. The unlocked ioctl hook makes sense to me at least!
   

 For the non-staging patches, (which also sit in the modesetting-newttm 
 tree), I can add some more elaborate comments. However I think all of
 them are targeted to support functionality for TTM, so unless the TTM
 code goes into staging or mainstream, there is little point in merging
 them to core drm before other drivers find them useful.

 Although I see the patch adding TTM is including some backwards
 compatibility defines (In particular the PAT compat stuff) that needs
 to be stripped.

Great, care to respin it and send it to me?

thanks,

greg k-h

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes

2009-03-20 Thread Greg KH
On Thu, Mar 19, 2009 at 10:39:03AM +, Alan Cox wrote:
  The non-existence of an open-source 3D implementation doesn't really 
  alter that situation.
 
 I think it does to an extent

With an opensource 2d solution it does?

  However, if there's a policy issue about adding Linux kernel support for 
  closed-source user-space drivers, I think it helps to be explicit about 
  that.
 
 Actually its a lawyer question not just policy. If the two parts being put
 together are tightly dependant on each other and in fact form a single
 work which it seems could reasonably be the case in this situation then
 if one half is GPL the other must also be so.

I'm not going to disagree with that, which would force the 3d portions
open.  At the moment I'm more worried about just getting 2d to work at
all.

I was going to wait for the rewrite to worry about 3d stuff, as it
will be done properly that way.

thanks,

greg k-h

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[RFC][PATCH] drm: detect hdmi monitor by hdmi identifier (v1)

2009-03-20 Thread Ma Ling
sometime we need to communicate with HDMI monitor by sending audio or video 
info frame,
so we have to know the monitor type. However if user utilize HDMI-DVI adapter 
to connect DVI monitor,
hardware detection will incorrectly shows the monitor is HDMI.
HDMI spec tell us that any device containing IEEE Registration Identifier will 
be
treated HDMI device. The patch intends to detect HDMI monitor by this rule.   

Any comments are welcome.
Thanks
Ma Ling

Signed-off-by: Ma Ling ling...@intel.com
---
 drivers/gpu/drm/drm_edid.c |   68 
 include/drm/drm_crtc.h |2 +
 2 files changed, 70 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a839a28..f92babe 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -677,6 +677,74 @@ struct edid *drm_get_edid(struct drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_get_edid);
 
+#define HDMI_IDENTIFIER 0x000C03
+#define VENDOR_BLOCK0x03
+/**
+ * drm_detect_hdmi_monitor - detect whether monitor is hdmi.
+ * @connector: connector we're probing
+ * @adapter: i2c adapter to use for DDC
+ *
+ * Parse the CEA extension according to CEA-861-B.
+ * Return true if HDMI, false if not or unknown.
+ */
+bool drm_detect_hdmi_monitor(struct drm_connector *connector,
+struct i2c_adapter *adapter)
+{
+   struct edid *edid;
+   char *edid_ext = NULL;
+   int start_offset, end_offset;
+   int i, hdmi_id;
+   bool ret = false;
+
+   edid = drm_get_edid(connector, adapter);
+
+   /* No EDID or EDID extensions */
+   if (edid == NULL || edid-extensions == 0)
+   goto end;
+
+   /* Find CEA extension */
+   for (i = 0; i  edid-extensions; i++) {
+   edid_ext = (char *)edid + EDID_LENGTH * (i + 1);
+   /* This block is CEA extension */
+   if (edid_ext[0] == 0x02)
+   break;
+   }
+
+   if (i == edid-extensions)
+   goto end;
+
+   /* Data block offset in CEA extension block */
+   start_offset = 4;
+   end_offset = edid_ext[2];
+
+   /*
+* Because HDMI identifier is in Vendor Specific Block,
+* search it from all data blocks of CEA extension.
+*/
+   for (i = start_offset; i  end_offset;
+   /* Increased by data block len */
+   i += ((edid_ext[i]  0x1f) + 1)) {
+   /* Find vendor specific block */
+   if ((edid_ext[i]  5) == VENDOR_BLOCK) {
+   hdmi_id = edid_ext[i + 1] | (edid_ext[i + 2]  8) |
+ edid_ext[i + 3]  16;
+   /* Find HDMI identifier */
+   if (hdmi_id == HDMI_IDENTIFIER)
+   ret = true;
+   break;
+   }
+   }
+
+end:
+   if (edid != NULL) {
+   connector-display_info.raw_edid = NULL;
+   kfree(edid);
+   }
+
+   return ret;
+}
+EXPORT_SYMBOL(drm_detect_hdmi_monitor);
+
 /**
  * drm_add_edid_modes - add modes from EDID data, if available
  * @connector: connector we're probing
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5ded1ac..e578f55 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -731,4 +731,6 @@ extern int drm_mode_gamma_get_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
 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 drm_connector *connector,
+   struct i2c_adapter *adapter);
 #endif /* __DRM_CRTC_H__ */
-- 
1.5.4.4




--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: udpated KMS speed improvement patch

2009-03-20 Thread Arjan van de Ven
On Thu, 19 Mar 2009 17:52:39 -0700
Jesse Barnes jbar...@virtuousgeek.org wrote:

  diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
  index a839a28..069b189 100644
  --- a/drivers/gpu/drm/drm_edid.c
  +++ b/drivers/gpu/drm/drm_edid.c
  @@ -588,20 +588,22 @@ static unsigned char *drm_ddc_read(struct
  i2c_adapter *adapter) {
  struct i2c_algo_bit_data *algo_data = adapter-algo_data;
  unsigned char *edid = NULL;
  +   int divider = 5;
  int i, j;
 
 Not sure about the DDC changes; we already have problems with not
 getting data back on several displays, but I think that problem is
 buried in the actual i2c code, not the delays in this routine.

with this change we try twice. First with divider = 5; if we get
nothing back we try again with divider = 1 (eg old behavior)...
should be ok I hope.

 
  diff --git a/drivers/gpu/drm/i915/intel_display.c
  b/drivers/gpu/drm/i915/intel_display.c index a283427..4b88341 100644
  --- a/drivers/gpu/drm/i915/intel_display.c
  +++ b/drivers/gpu/drm/i915/intel_display.c
  @@ -319,7 +319,7 @@ void
   intel_wait_for_vblank(struct drm_device *dev)
   {
  /* Wait for 20ms, i.e. one cycle at 50hz. */
  -   udelay(2);
  +   mdelay(20);
   }
 
 We could probably do this independently.  We'll generally be holding
 the struct mutex here, but that should be ok.

well udelay(2) == mdelay(20) for all intents and purposes; just
minor cleanup


-- 
Arjan van de VenIntel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 12899] New: Crash in i915.ko: i915_driver_irq_handler

2009-03-20 Thread bugme-daemon
http://bugzilla.kernel.org/show_bug.cgi?id=12899

   Summary: Crash in i915.ko: i915_driver_irq_handler
   Product: Drivers
   Version: 2.5
 KernelVersion: 2.6.29-rc8
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: high
  Priority: P1
 Component: Video(DRI)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: helge.bahm...@secunet.com


linux-2.6.29-rc8, no kernel modesetting, X server running with legacy DRI

I observe frequent kernel NULL pointer dereferences in i915_driver_irq_handler
while switching from a running X server back into the VGA text console. Machine
locks hard very shortly afterwards, so all backtraces via serial console are
truncated, the last messages are at best:

[drm:gm45_get_vblank_counter] *ERROR* trying to get vblank count for disabled
pipe 0
BUG: unable to handle kernel NULL pointer dereference at 0084
IP: [f90b736b] i915_driver_irq_handler+0x135/0x1b7 [i915]

From the disassembly I guess that the culprit is:

if (dev-primary-master) {
master_priv = dev-primary-master-driver_priv;
if (master_priv-sarea_priv)
master_priv-sarea_priv-last_dispatch =
READ_BREADCRUMB(dev_priv); CRASH
}

and after applying the following small patch:

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 87b6b60..d7fe821 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -249,7 +249,7 @@ irqreturn_t i915_driver_irq_handler(DRM_IRQ_ARGS)

if (dev-primary-master) {
master_priv = dev-primary-master-driver_priv;
-   if (master_priv-sarea_priv)
+   if (master_priv-sarea_priv 
dev_priv-hw_status_page)
master_priv-sarea_priv-last_dispatch =
READ_BREADCRUMB(dev_priv);
}


the problem goes away. The patch is most certainly *wrong*, but that it hides
the problem hints that there must somewhere be a race between clearing out
-hw_status_page and the interrupt handler. Someone with better understanding
of the driver should have a look.


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 12900] New: [intel 855GM] problems with tiled output in various circumstances

2009-03-20 Thread bugme-daemon
http://bugzilla.kernel.org/show_bug.cgi?id=12900

   Summary: [intel 855GM] problems with tiled output in various
circumstances
   Product: Drivers
   Version: 2.5
 KernelVersion: 2.6.29-rc8
  Platform: All
OS/Version: Linux
  Tree: Mainline
Status: NEW
  Severity: normal
  Priority: P1
 Component: Video(DRI)
AssignedTo: drivers_video-...@kernel-bugs.osdl.org
ReportedBy: dan...@ffwll.ch
CC: jbar...@virtuousgeek.org


Latest working kernel version: 2.6.29-rc3
Distribution: debian unstable
Hardware Environment: IBM X40 Latop

Problem Description:

In short: When using kms, glxgears is strangely tiled. When _not_ using kms,
all the output (save the X cursor) of the 2d ddx is strangely tiled (if the ddx
is new enough to support tiling). For the details, see my original bug report
on the 2d intel ddx at

https://bugs.freedesktop.org/show_bug.cgi?id=20289

After some testing it looks like the kernel is the culprit. For tracking down
the exact commit with bisecting my userspace env was:

xf86-video-intel: xf86-video-intel-2.4.97.0-369-gd9dbdb3 (using git describe)
xorg: 1.6 rc from debian experimental
libdrm: libdrm-2.4.5-41-g82eac80

According to my bisect-run, the breakage was introduced in the following
commit:

commit 0f973f27888e4664b253ab2cf69c67c2eb80ab1b
Author: Jesse Barnes jbar...@virtuousgeek.org
Date:   Mon Jan 26 17:10:45 2009 -0800

drm/i915: add fence register management to execbuf

I've tried to revert this on top of 2.6.29-rc8, but this failed due to merge
conflicts.


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes

2009-03-20 Thread Alan Cox
  By the same logic, would you support including the proprietary NVIDIA
  driver while we wait for Nouveau to catch up?
 
 The license of the NVIDIA driver does not allow that to even be a
 possibility.

I'm not convinced this is any different. If you accept the 3D changes you
step into a dangerous world of estoppel and since it has many
rightsholders also the wonderful world of contributory infringement. It
really really needs lawyers to look into it.

Now the other way to do it that might be more productive and simpler
would be to rip all the 3D crap out of that driver and just include the
minimum needed 2D bits for the open source X driver. Makes the code
smaller and cleaner, avoids an legal questions and lets people get on
with real work.


--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 12900] [intel 855GM] problems with tiled output in various circumstances

2009-03-20 Thread bugme-daemon
http://bugzilla.kernel.org/show_bug.cgi?id=12900


dan...@ffwll.ch changed:

   What|Removed |Added

 Regression|0   |1




-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes

2009-03-20 Thread Greg KH
On Fri, Mar 20, 2009 at 05:08:23PM +1100, Daniel Stone wrote:
 Greg,
 
 On Thu, Mar 19, 2009 at 09:27:19AM -0700, Greg KH wrote:
  On Thu, Mar 19, 2009 at 12:03:09PM -0400, Sindhudweep Sarkar wrote:
   TI-OMAP 3xxx and a couple of other arm processors use similar SGX-5xx
   graphics cores. IIRC arm is often little endian so perhaps a unified
   driver would be easier in the long term.
  
  Long term lots of things are good.
  
  But how do I get my laptop that I currently have right now up and
  running properly with linux in a better-than-800x600-framebuffer mode?
  
  That's why I need/want this driver now, there are hundreds of thousands
  of these types of laptops in the pipeline to users and I want them to
  run Linux, not be forced to run some other operating system...
 
 By the same logic, would you support including the proprietary NVIDIA
 driver while we wait for Nouveau to catch up?

The license of the NVIDIA driver does not allow that to even be a
possibility.

thanks,

greg k-h

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes

2009-03-20 Thread Greg KH
On Fri, Mar 20, 2009 at 03:00:32PM +, Alan Cox wrote:
   By the same logic, would you support including the proprietary NVIDIA
   driver while we wait for Nouveau to catch up?
  
  The license of the NVIDIA driver does not allow that to even be a
  possibility.
 
 I'm not convinced this is any different. If you accept the 3D changes you
 step into a dangerous world of estoppel and since it has many
 rightsholders also the wonderful world of contributory infringement. It
 really really needs lawyers to look into it.

I would hope that Intel's lawyers would have done such a thing before
releasing the kernel and xorg code under the licenses that they did :)

 Now the other way to do it that might be more productive and simpler
 would be to rip all the 3D crap out of that driver and just include the
 minimum needed 2D bits for the open source X driver. Makes the code
 smaller and cleaner, avoids an legal questions and lets people get on
 with real work.

Hm, that sounds fine to me.

Does that mean that all of these drm patches that I posted are _only_
needed for the 3d portions of the driver?  If I rip out the portions of
the psb kernel driver that need these changes, do I end up with an
working 2d driver as well?  Richard and Thomas, any thoughts here?

thanks,

greg k-h

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


[Bug 14076] GL_OUT_OF_MEMORY crash with R300 driver and Lineage II under Wine

2009-03-20 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=14076





--- Comment #3 from Roman Mamedov ro...@rm.pp.ru  2009-03-20 08:58:46 PST ---
I had 2 GB at the time.

Also, I have since upgraded the X800GT to a 3870, which has no 3D support with
Mesa drivers atm, so I wouldn't be able to further track if this issue
continues to occur or not.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes

2009-03-20 Thread Thomas Hellström
Greg KH wrote:
 On Fri, Mar 20, 2009 at 03:00:32PM +, Alan Cox wrote:
   
 By the same logic, would you support including the proprietary NVIDIA
 driver while we wait for Nouveau to catch up?
 
 The license of the NVIDIA driver does not allow that to even be a
 possibility.
   
 I'm not convinced this is any different. If you accept the 3D changes you
 step into a dangerous world of estoppel and since it has many
 rightsholders also the wonderful world of contributory infringement. It
 really really needs lawyers to look into it.
 

 I would hope that Intel's lawyers would have done such a thing before
 releasing the kernel and xorg code under the licenses that they did :)

   
 Now the other way to do it that might be more productive and simpler
 would be to rip all the 3D crap out of that driver and just include the
 minimum needed 2D bits for the open source X driver. Makes the code
 smaller and cleaner, avoids an legal questions and lets people get on
 with real work.
 

 Hm, that sounds fine to me.

 Does that mean that all of these drm patches that I posted are _only_
 needed for the 3d portions of the driver?  If I rip out the portions of
 the psb kernel driver that need these changes, do I end up with an
 working 2d driver as well?  Richard and Thomas, any thoughts here?

 thanks,

 greg k-h

   
Greg,
Let's not forget the video stuff. I'm not sure about the status of that.

But all the other patches are needed for 2D functionality and kernel 
modesetting.
If you want to strip 3D you can strip.

psb_schedule.[ch] - The 3D scheduler.
psb_xhw.c - The interface to the binary X server module.
psb_scene.c - The 3D scene tracker.

and anything that appears unused after that.
This means you lose Render acceleration and textured video and 
downscaling in the X server as well,
although accelerated rotation should still work, since it uses the 2D 
engine.

I think the video acceleration sits in

psb_msvdx.c
psb_msvdxinit.c
lnc_topaz.c
lnc_topazinit.c

/Thomas




--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Intel-gfx] [PATCH] drm/i915: Fix TV get_modes to return modes count

2009-03-20 Thread Eric Anholt
On Wed, 2009-03-04 at 19:36 +0800, Zhenyu Wang wrote:
 TV modes count must be returned in get_modes.
 This also fixed TV mode's clock calculation int
 overflow issue, and use 0.01 precision for mode
 refresh validation.
 
 Signed-off-by: Zhenyu Wang zhenyu.z.w...@intel.com

I've gone ahead and applied this series, but in the future please use
separate commits for separate issues (for example with this commit, one
would be returning the count, one would be int overflow, and one would
be the clock accuracy check).

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




signature.asc
Description: This is a digitally signed message part
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Intel-gfx] [PATCH] drm/i915: Check for dev-primary-master before dereference.

2009-03-20 Thread Eric Anholt
On Fri, 2009-03-06 at 23:27 +, Chris Wilson wrote:
 I've hit the occasional oops inside i915_wait_ring() with an indication of
 a NULL derefence of dev-primary-master.  Adding a NULL check is
 consistent with the other potential users of dev-primary-master.
 
 Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk

Applied.

Given how many bugs we've had with these perf_boxes settings, we may
want to just nuke them at some point.  It looks like the userland debug
code that used the flags went away in 2007.

Does anyone care for them continuing to exist?  Do we have any
obligation to keep them?  I think for any future performance debug like
these did, we'd just expose values in debugfs (it keeps the debug code
from interfering with app behavior, anyway).

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




signature.asc
Description: This is a digitally signed message part
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Patch 0/3]: [DRM/I915] : Sync the mode validation for INTERLACE/DBLSCAN

2009-03-20 Thread Eric Anholt
On Fri, 2009-03-20 at 14:10 +0800, yakui_zhao wrote:
 Subject: [DRM/I915]: Sync the mode validation for INTERLACE/DBLSCAN
 From: Zhao Yakui yakui.z...@intel.com
 
  Sync the mode validation for INTERLACE/DBLSCAN
  This covers:
  Check whether the INTERLACE/DBLSCAN is supported by output device. If
 not, the mode containing the flag of INTERLACE/DBLSCAN will be marked
 as unsupported.

Please fix the style here.

 Signed-off-by: Zhao Yakui yakui.z...@intel.com
 ---
  drivers/gpu/drm/drm_crtc_helper.c |   25 +
  1 file changed, 25 insertions(+)
 
 Index: linux-2.6/drivers/gpu/drm/drm_crtc_helper.c
 ===
 --- linux-2.6.orig/drivers/gpu/drm/drm_crtc_helper.c  2009-03-20 
 11:47:32.0 +0800
 +++ linux-2.6/drivers/gpu/drm/drm_crtc_helper.c   2009-03-20 
 13:36:22.0 +0800
 @@ -41,6 +41,23 @@
  968, 1056, 0, 600, 601, 605, 628, 0,
  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
  };

missing return here

 +static void drm_mode_validate_flag(struct drm_connector *connector,
 + int flags)

align the indentation of this line to the open paren

 +{
 + struct drm_display_mode *mode, *t;
 + if (flags == (DRM_MODE_FLAG_DBLSCAN |
 + DRM_MODE_FLAG_INTERLACE))

gratuitous newline to unaligned indentation

 + return ;

no space between return and ;

 + list_for_each_entry_safe(mode, t, connector-modes, head) {
 + if (mode-flags  DRM_MODE_FLAG_INTERLACE 
 + !(flags  DRM_MODE_FLAG_INTERLACE))
 + mode-status = MODE_NO_INTERLACE;
 + if (mode-flags  DRM_MODE_FLAG_DBLSCAN 
 + !(flags  DRM_MODE_FLAG_DBLSCAN))
 + mode-status = MODE_NO_DBLESCAN;
 + }
 +}
  
  /**
   * drm_helper_probe_connector_modes - get complete set of display modes
 @@ -96,6 +113,14 @@
   if (maxX  maxY)
   drm_mode_validate_size(dev, connector-modes, maxX,
  maxY, 0);
 + {
 + int flags = (connector-interlace_allowed ?
 + DRM_MODE_FLAG_INTERLACE : 0) |
 + (connector-doublescan_allowed ?
 + DRM_MODE_FLAG_DBLSCAN : 0);

declare your variable at the top of the function, don't start a new
block to declare it.  Also, use some if ()s instead of a long wrapped
line with two ternary operators.

 + drm_mode_validate_flag(connector, flags);
 +
 + }
   list_for_each_entry_safe(mode, t, connector-modes, head) {
   if (mode-status == MODE_OK)
   mode-status = connector_funcs-mode_valid(connector,
 
 
-- 
Eric Anholt
e...@anholt.net eric.anh...@intel.com




signature.asc
Description: This is a digitally signed message part
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Patch 3/3]: [DRM/I915] : Sync the default modes for LVDS output device

2009-03-20 Thread Eric Anholt
On Fri, 2009-03-20 at 14:13 +0800, yakui_zhao wrote:
 Subject: [DRM/I915]: Sync the default modes for LVDS output device
 From: Zhao Yakui yakui.z...@intel.com
 
 Sync the default modes for the LVDS output device
 This covers:
 Add the default modes for the LVDS output device.
 The bit of edid-feature.msc indicates whether the display device is not
 continous-frequency. And it is used to determine whether the default modes 
 will
 be added to the output device.
 But for the LVDS output device the edid-feature.msc will always be 
 set.Even
 when there is no edid, the corresponding bit in the fake edid will be set.
 In such case the default modes will be added to LVDS output device.
 If not, the modes obtained by using KMS/UMS will be different.

Similar whitespace concerns in this and the previous patch as the first,
plus a couple of review comments below.

 Signed-off-by: Zhao Yakui yakui.z...@intel.com
 ---
  drivers/gpu/drm/i915/intel_lvds.c |  422 
 +-
  1 file changed, 412 insertions(+), 10 deletions(-)
 
 Index: linux-2.6/drivers/gpu/drm/i915/intel_lvds.c
 ===
 --- linux-2.6.orig/drivers/gpu/drm/i915/intel_lvds.c  2009-03-20 
 11:51:53.0 +0800
 +++ linux-2.6/drivers/gpu/drm/i915/intel_lvds.c   2009-03-20 
 13:36:03.0 +0800
 @@ -36,6 +36,381 @@
  #include intel_drv.h
  #include i915_drm.h
  #include i915_drv.h
 +/*
 + * the default modes, which is based on the file of
 + * xserver/xfree86/common/xf86DefModeSet.c.
 + */
 +static struct drm_display_mode default_modes[] = {
 + /* 640x...@85hz */
 + { DRM_MODE(640x350, DRM_MODE_TYPE_DRIVER, 31500, 640, 672,
 +736, 832, 0, 350, 382, 385, 445, 0,
 +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
 + /* 320x...@85hz */
 + { DRM_MODE(320x175, DRM_MODE_TYPE_DRIVER, 15750, 320, 336,
 +368, 416, 0, 175, 191, 192, 222, 0,
 +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
 + DRM_MODE_FLAG_DBLSCAN) },
 + /* 640x...@85hz */
 + { DRM_MODE(640x400, DRM_MODE_TYPE_DRIVER, 31500, 640, 672,
 +736, 832, 0, 400, 401, 405, 445, 0,
 +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
 + /* 320x...@85hz */
 + { DRM_MODE(320x200, DRM_MODE_TYPE_DRIVER, 15750, 320, 336,
 +368, 416, 0, 200, 200, 202, 222, 0,
 +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
 + DRM_MODE_FLAG_DBLSCAN) },
 + /* 720x...@85hz */
 + { DRM_MODE(720x400, DRM_MODE_TYPE_DRIVER, 35500, 720, 756,
 +828, 936, 0, 400, 401, 405, 446, 0,
 +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
 + /* 360x...@85hz */
 + { DRM_MODE(360x200, DRM_MODE_TYPE_DRIVER, 17750, 360, 378,
 +414, 468, 0, 200, 200, 202, 223, 0,
 +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
 + DRM_MODE_FLAG_DBLSCAN) },
 + /* 640x...@60hz */
 + { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 25175, 600, 656,
 +752, 800, 0, 480, 490, 492, 525, 0,
 +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
 + /* 320x...@60hz */
 + { DRM_MODE(320x240, DRM_MODE_TYPE_DRIVER, 12587, 320, 328,
 +376, 400, 0, 240, 245, 246, 262, 0,
 +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
 + DRM_MODE_FLAG_DBLSCAN) },
 + /* 640x...@72hz */
 + { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 31500, 640, 664,
 +704, 832, 0, 480, 489, 492, 520, 0,
 +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
 + /* 320x...@72hz */
 + { DRM_MODE(320x240, DRM_MODE_TYPE_DRIVER, 15750, 320, 332,
 +352, 416, 0, 240, 244, 246, 260, 0,
 +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
 + DRM_MODE_FLAG_DBLSCAN) },
 + /* 640x...@75hz */
 + { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 31500, 640, 656,
 +720, 840, 0, 480, 481, 484, 500, 0,
 +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
 + /* 320x...@75hz */
 + { DRM_MODE(320x240, DRM_MODE_TYPE_DRIVER, 15750, 320, 328,
 +360, 420, 0, 240, 240, 242, 250, 0,
 +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
 + DRM_MODE_FLAG_DBLSCAN) },
 + /* 640x...@85hz */
 + { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 36000, 640, 696,
 +752, 832, 0, 480, 481, 484, 509, 0,
 +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
 + /* 320x...@85hz */
 + { DRM_MODE(320x240, DRM_MODE_TYPE_DRIVER, 18000, 320, 348,
 +376, 416, 0, 240, 240, 242, 254, 0,
 +DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC |
 + 

[Bug 12899] Crash in i915.ko: i915_driver_irq_handler

2009-03-20 Thread bugme-daemon
http://bugzilla.kernel.org/show_bug.cgi?id=12899





--- Comment #1 from e...@anholt.net  2009-03-20 13:06 ---
Looks sane to me.  Could you send the patch to lkml or dri-de...@lists.sf.net
with a commit message and Signed-off-by:?


-- 
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel


Re: [Intel-gfx] [PATCH] drm: read EDID extensions from monitor (v2)

2009-03-20 Thread Eric Anholt
On Fri, 2009-03-20 at 14:09 +0800, Ma Ling wrote:
 Usually drm read basic EDID, that is enough for us, but because digital 
 display in introduced
 i.e. HDMI monitor, sometime we need to interact with monitor by EDID 
 extension information,
 including audio/video data block, speaker allocation and vendor specific data 
 block...
 This patch intends to read EDID extensions(max 4) from digital monitor for 
 user.
 
 Signed-off-by: Ma Ling ling...@intel.com

This looks fine to me.  airlied, you want to pick this up for next, or
should I?

 ---
 In this version drm will read max number if the number of edid extensions is 
 over max number.
 
  drivers/gpu/drm/drm_edid.c |  121 +--
  include/drm/drm_crtc.h |3 +-
  2 files changed, 95 insertions(+), 29 deletions(-)
 
 diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
 index a839a28..fab2bdf 100644
 --- a/drivers/gpu/drm/drm_edid.c
 +++ b/drivers/gpu/drm/drm_edid.c
 @@ -550,11 +550,20 @@ static int add_detailed_info(struct drm_connector 
 *connector,
  }
  
  #define DDC_ADDR 0x50
 -
 -unsigned char *drm_do_probe_ddc_edid(struct i2c_adapter *adapter)
 +/**
 + * Get EDID information via I2C.
 + *
 + * \param adapter : i2c device adaptor
 + * \param buf : EDID data buffer to be filled
 + * \param len : EDID data buffer length
 + * \return 0 on success or -1 on failure.
 + *
 + * Try to fetch EDID information by calling i2c driver function.
 + */
 +int drm_do_probe_ddc_edid(struct i2c_adapter *adapter,
 +   unsigned char *buf, int len)
  {
   unsigned char start = 0x0;
 - unsigned char *buf = kmalloc(EDID_LENGTH, GFP_KERNEL);
   struct i2c_msg msgs[] = {
   {
   .addr   = DDC_ADDR,
 @@ -564,31 +573,36 @@ unsigned char *drm_do_probe_ddc_edid(struct i2c_adapter 
 *adapter)
   }, {
   .addr   = DDC_ADDR,
   .flags  = I2C_M_RD,
 - .len= EDID_LENGTH,
 + .len= len,
   .buf= buf,
   }
   };
  
 - if (!buf) {
 - dev_warn(adapter-dev, unable to allocate memory for EDID 
 -  block.\n);
 - return NULL;
 - }
 -
   if (i2c_transfer(adapter, msgs, 2) == 2)
 - return buf;
 + return 0;
  
   dev_info(adapter-dev, unable to read EDID block.\n);
 - kfree(buf);
 - return NULL;
 + return -1;
  }
  EXPORT_SYMBOL(drm_do_probe_ddc_edid);
  
 -static unsigned char *drm_ddc_read(struct i2c_adapter *adapter)
 +/**
 + * Get EDID information.
 + *
 + * \param adapter : i2c device adaptor.
 + * \param buf : EDID data buffer to be filled
 + * \param len : EDID data buffer length
 + * \return 0 on success or -1 on failure.
 + *
 + * Initialize DDC, then fetch EDID information
 + * by calling drm_do_probe_ddc_edid function.
 + */
 +static int drm_ddc_read(struct i2c_adapter *adapter,
 + unsigned char *buf, int len)
  {
   struct i2c_algo_bit_data *algo_data = adapter-algo_data;
 - unsigned char *edid = NULL;
   int i, j;
 + int ret = -1;
  
   algo_data-setscl(algo_data-data, 1);
  
 @@ -616,7 +630,7 @@ static unsigned char *drm_ddc_read(struct i2c_adapter 
 *adapter)
   msleep(15);
  
   /* Do the real work */
 - edid = drm_do_probe_ddc_edid(adapter);
 + ret = drm_do_probe_ddc_edid(adapter, buf, len);
   algo_data-setsda(algo_data-data, 0);
   algo_data-setscl(algo_data-data, 0);
   msleep(15);
 @@ -632,7 +646,7 @@ static unsigned char *drm_ddc_read(struct i2c_adapter 
 *adapter)
   msleep(15);
   algo_data-setscl(algo_data-data, 0);
   algo_data-setsda(algo_data-data, 0);
 - if (edid)
 + if (ret == 0)
   break;
   }
   /* Release the DDC lines when done or the Apple Cinema HD display
 @@ -641,9 +655,31 @@ static unsigned char *drm_ddc_read(struct i2c_adapter 
 *adapter)
   algo_data-setsda(algo_data-data, 1);
   algo_data-setscl(algo_data-data, 1);
  
 - return edid;
 + return ret;
 +}
 +
 +static int drm_ddc_read_edid(struct drm_connector *connector,
 +  struct i2c_adapter *adapter,
 +  char *buf, int len)
 +{
 + int ret;
 +
 + ret = drm_ddc_read(adapter, buf, len);
 + if (ret != 0) {
 + dev_info(connector-dev-pdev-dev, %s: no EDID data\n,
 +  drm_get_connector_name(connector));
 + goto end;
 + }
 + if (!edid_is_valid((struct edid *)buf)) {
 + dev_warn(connector-dev-pdev-dev, %s: EDID invalid.\n,
 +  drm_get_connector_name(connector));
 + ret = -1;
 + }
 +end:
 + return ret;
  }
  
 +#define MAX_EDID_EXT_NUM 4
  /**
   * 

Building rawhide+darktama on 2.6.24 (Re: [Nouveau] DRM changes)

2009-03-20 Thread Pekka Paalanen
On Mon, 9 Mar 2009 22:49:32 +0100
Stephane Marchesin marche...@icps.u-strasbg.fr wrote:

 As we discussed on irc, there would be multiple changes related to this:
 - we move to a linux kernel-like tree, that should make it easier when
 upstreaming the code.
 - this new tree is hosted in freedekstop.org in the nouveau/ git so we
 don't need additional accounts for everyone all around and people can
 keep pushing things (even better, all nouveau people can push to the
 drm, which used to require mesa rights before)
 - we keep a(some) branch(es) in the tree for backwards compat with
 older kernels. Either in the form of separate kernel versions
 including nouveau, or in the form of an out-of-tree-compilable
 drm/nouveau module.

Hi,

I took airlied's drm-rawhide kernel tree, applied darktama's patch
that adds Nouveau, wrote/copied my own compat-patches on top of that,
and compiled the DRM modules (drm.ko and nouveau.ko) against my
currently running kernel 2.6.24.

It works, with the caveat that I needed a tiny patch to 2.6.24 in
addition to reconfiguring it. The details will follow. I've been
running Nouveau for two hours now without any hickups.

I'm CC'ing also dri-devel@ just in case people working on other
drivers might be interested in offering a drm.git-like version
of their drivers for people with older, custom or otherwise
not-this-driver's-development-tree kernels. And because my
compat patches probably suck.

Feel free to drop the dri-devel@ CC when you discuss Nouveau-only
matters.


This raises some questions for Nouveau:
- like marcheu proposed, shall Nouveau DRM move into a kernel tree?
- do we abandon drm.git kernel directories completely?
- is the out-of-tree DRM build sketched below feasible for users?
- how do we maintain and distribute the compat patches and DRM code?

I'd expect the compat patches would be maintained by whoever happens
to run older kernels. Developers do not consider compat patching.


Building DRM out-of-tree for 2.6.24:

Prepare the upstream DRM and Nouveau code:

- Get airlied's linux kernel tree, the drm-rawhide branch:
http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-rawhide
(the version I used is probably a week old now)

- Get darktama's nouveau patch and apply it on drm-rawhide:
http://cvs.fedoraproject.org/viewvc/rpms/kernel/devel/drm-nouveau.patch?revision=1.25view=markup
(this is probably outdated by now)

- apply the included nouveau-drm-compat-24.patch
This patch is combined from the individual patches listed in its
description, diffstat is included.

- run 'make clean' unless your tree is already clean.


Prepare your 2.6.24 kernel:

- apply the included kernel-compat-24.patch to export shmem_file_setup()

- configure the following as modules:
CONFIG_DRM
CONFIG_FB
CONFIG_BACKLIGHT_CLASS_DEVICE
CONFIG_FB_SAVAGE
The savage driver is abused to get FB_CFB_FILLRECT, FB_CFB_COPYAREA and
FB_CFB_IMAGEBLIT enabled, since they do not have menuconfig entries.
If you actually have a Savage card in your computer, maybe you should
pick another fb driver.

- build and install as usual, remove the drm.ko generated.


Building the DRM and Nouveau modules as external modules
using the 2.6.24 kernel tree:

- save the included mkbuild-nouveau.bash script

- edit the script, and fix the paths to the 2.6.24 and the
drm-rawhide kernel trees

- create a new empty directory and cd into it

- run '../mkbuild-nouveau.bash init', it should not whine
about anything, just print good stuff.

- run '../mkbuild-nouveau.bash build', it should build drm.ko and
nouveau.ko. These are probably created in the drm-rawhide kernel
tree.

- find the kernel modules, and load these:
fb.ko
drm.ko
backlight.ko
cfbcopyarea.ko
cfbfillrect.ko
cfbimgblt.ko
nouveau.ko
Now the Nouveau DDX should run just fine using the new DRM modules.


Ben, I still don't see any comment from you on this thread :-)

-- 
Pekka Paalanen
http://www.iki.fi/pq/
#!/bin/bash

# 395e0ddc44005ced5e4fed9bfc2e4bdf63d37627 shmem_file_setup export

# Use e.g. CONFIG_FB_SAVAGE to get FB_CFB_FILLRECT, FB_CFB_COPYAREA
# and FB_CFB_IMAGEBLIT.

# cd into an empty directory, and call this script from there.

# Path to the kernel tree, from which DRM is built.
NKDIR=/home/pq/linux/linux-2.6-torvalds

# Path to the configured kernel tree you normally use
KDIR=$(readlink -f /lib/modules/`uname -r`/source)

# All resulting files *should* be written to OUTDIR, but it seems
# the external module directory does not honour that. I.e. the
# the external modules are built into DRMDIR.

DRMDIR=$NKDIR/drivers/gpu/drm
OUTDIR=$(pwd)
NEWCONFIG=$OUTDIR/.config

# --- nothing configurable below this line ---

CMD=$1

function config_check_ym {
OPTION=$1
grep -q -e CONFIG_$OPTION=[ym] $NEWCONFIG  return 0
echo Option CONFIG_$OPTION is not set in your kernel config.
return 1
}

function config_require {

[Bug 20537] piglit failures on ATI Mobility M6

2009-03-20 Thread bugzilla-daemon
http://bugs.freedesktop.org/show_bug.cgi?id=20537


jsado_...@comcast.net changed:

   What|Removed |Added

 CC||jsado_...@comcast.net




--- Comment #2 from jsado_...@comcast.net  2009-03-20 17:44:45 PST ---
The mesa/radeon-rewrite branch has failed miserably on my hardware. Any OpenGL
application (well I tried two) only displays its first frame, and then freezes.
Piglit only got through two tests and hung on the third, which I believe is
glean/orthoPosHLines. Attempting to kill piglit with ^C causes it to start the
next test, and repeated ^C finally stopped it, but some other test was still
around and crashed my machine hard, totally froze, could not even ssh in.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel