Re: [patch 0/5] Intel Poulsbo/Morrestown DRM driver and DRM core changes
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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)
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)
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
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