Re: [PATCH] ati_pcigart: fix format type warning
On Sun, 17 Jan 2010 19:41:20 +0100 Borislav Petkov petko...@googlemail.com wrote: drivers/gpu/drm/radeon/radeon_state.c:2145: /home/boris/kernel/linux-2.6/arch/x86/include/asm/uaccess_32.h:212: warning: call to ‘copy_from_user_overflow’ declared with attribute warning: copy_from_user() buffer size is not provably correct LD drivers/gpu/drm/radeon/radeon.o which is caused by the compile-time check in copy_from_user introduced in 4a312769: if (DRM_COPY_FROM_USER(depth_boxes, clear-depth_boxes, sarea_priv-nbox * sizeof(depth_boxes[0]))) due to the sarea_priv-nbox being unknown at compile time, even though the code clamps its value earlier in case it might cause an overflow: if (sarea_priv-nbox RADEON_NR_SAREA_CLIPRECTS) sarea_priv-nbox = RADEON_NR_SAREA_CLIPRECTS; gcc is not smart enough to prove that the clamp survives the multiplication without wrapping it seems. -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
kerneloops.org report for the week of October 11th 2009
for new kew This warning was last seen in version 2.6.30, and first seen in 2.6.27.35. More info: http://www.kerneloops.org/searchweek.php?search=iwl_set_dynamic_key -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: kerneloops.org report for the week of June 14 2009
On Thu, 18 Jun 2009 13:08:39 -0400 Bob Copeland m...@bobcopeland.com wrote: On Sun, Jun 14, 2009 at 8:33 PM, Arjan van de Venar...@infradead.org wrote: Rank 9: minstrel_get_rate (warning) Reported 64 times (384 total reports) Issue with the ath5k driver This warning was last seen in version 2.6.30-rc3, and first seen in 2.6.27.12. More info: http://www.kerneloops.org/searchweek.php?search=minstrel_get_rate I believe this is fixed by http://lkml.org/lkml/2009/6/5/269, now in pre-2.6.31. Hmm, odd though, we should be seeing reports from other wireless drivers since it's a general memory corruption unrelated to ath5k (but not all use the mac80211 rate controllers). well.. out of the 534 reports or so that I have by now... 525 have ath5k loaded. it's not 100% but it'd pretty close. -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
kerneloops.org report for the week of June 14 2009
Hi, First, a word of thanks to the kernel.org team for helping to host the kerneloops.org database on a real machine rather than a small virtualized host. Performance and continuity will be a lot better in the new setup! (as a result of the transition and hosting issues on the original server, there was a downtime of two days, meaning that the total number of reports is lower than typical) New sightings this report include the XFI driver, the i915 gem code and the DMAR code. This week, a total of 4026 oopses and warnings have been reported for kernels 2.6.29 and later. Reports for kernels earlier than 2.6.29 have been omitted from this report. Per file statistics 830 drivers/gpu/drm/i915/i915_gem_tiling.c 470 drivers/net/wireless/iwlwifi/iwl-sta.c 303 kernel/time.c 276 drivers/parport/procfs.c 269 include/linux/slob_def.h 187 include/linux/hrtimer.h 138 arch/x86/kernel/cpu/mtrr/generic.c 120 drivers/pci/dmar.c 65 net/mac80211/rc80211_minstrel.c 62 drivers/net/r8169.c 37 net/ipv4/tcp.c 34 fs/cifs/cifssmb.c Rank 1: i915_gem_set_tiling (warning) Reported 830 times (3700 total reports) [gem] Failure in the tiling code This warning was last seen in version 2.6.30, and first seen in 2.6.29-rc2. More info: http://www.kerneloops.org/searchweek.php?search=i915_gem_set_tiling Rank 2: iwl_set_dynamic_key (warning) Reported 470 times (13682 total reports) no space for new kew message. This warning was last seen in version 2.6.30, and first seen in 2.6.27. More info: http://www.kerneloops.org/searchweek.php?search=iwl_set_dynamic_key Rank 3: getnstimeofday (warning) Reported 309 times (2446 total reports) [suspend resume] getnstimeofday() is called before timekeeping is resumed This warning was last seen in version 2.6.29.4, and first seen in 2.6.24. More info: http://www.kerneloops.org/searchweek.php?search=getnstimeofday Rank 4: ct_vm_map (warning) - sleeping in atomic context Reported 285 times (960 total reports) Bug in the creative XFI driver (backported to Fedora) This warning was last seen in version 2.6.29.4, and first seen in 2.6.29-rc4-git1. More info: http://www.kerneloops.org/searchweek.php?search=ct_vm_map Rank 5: parport_device_proc_unregister (warning) Reported 278 times (1810 total reports) Alan has a fix for this on LKML This warning was last seen in version 2.6.29.4, and first seen in 2.6.27. More info: http://www.kerneloops.org/searchweek.php?search=parport_device_proc_unregister Rank 6: hres_timers_resume (warning) Reported 188 times (1024 total reports) [suspend resume] hres_timers_resume() is incorrectly called with interrupts on This warning was last seen in version 2.6.30-rc6, and first seen in 2.6.24.7. More info: http://www.kerneloops.org/searchweek.php?search=hres_timers_resume Rank 7: generic_get_mtrr (warning) Reported 139 times (1009 total reports) BIOS bug where the MTRRs are not set up correctly This warning was last seen in version 2.6.30, and first seen in 2.6.25.3. More info: http://www.kerneloops.org/searchweek.php?search=generic_get_mtrr Rank 8: dmar_table_init (warning) Reported 121 times (507 total reports) BIOS bug exposed via a WARN_ON This warning was last seen in version 2.6.30-rc8, and first seen in 2.6.29. More info: http://www.kerneloops.org/searchweek.php?search=dmar_table_init Rank 9: minstrel_get_rate (warning) Reported 64 times (384 total reports) Issue with the ath5k driver This warning was last seen in version 2.6.30-rc3, and first seen in 2.6.27.12. More info: http://www.kerneloops.org/searchweek.php?search=minstrel_get_rate Rank 10: dev_watchdog(r8169) (warning) Reported 62 times (9116 total reports) This warning was last seen in version 2.6.30-rc7, and first seen in 2.6.26.6. More info: http://www.kerneloops.org/searchweek.php?search=dev_watchdog(r8169) Rank 11: nv_tx_done_optimized (warning) Reported 61 times (2974 total reports) the NV ethernet driver is getting caught with the new DMA API checks This warning was last seen in version 2.6.30, and first seen in 2.6.29-rc3-git7. More info: http://www.kerneloops.org/searchweek.php?search=nv_tx_done_optimized Rank 12: tcp_recvmsg (warning) Reported 37 times (3797 total reports) fixed in 2.6.30 (commit 775273131810caa41dfc7f9e552ea5d8508caf40) This warning was last seen in version 2.6.30, and first seen in 2.6.25. More info: http://www.kerneloops.org/searchweek.php?search=tcp_recvmsg -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org
Re: [PATCH] drm: Cache the EDID value for a short time in i915
On Wed, 01 Apr 2009 12:38:17 -0700 Eric Anholt e...@anholt.net wrote: On Mon, 2009-03-16 at 19:36 -0700, Arjan van de Ven wrote: From 8ad1bd63c097f9f6948439c1ce7c0b17b8caa64a Mon Sep 17 00:00:00 2001 From: Arjan van de Ven ar...@linux.intel.com Date: Mon, 16 Mar 2009 19:31:39 -0700 Subject: [PATCH] drm: Cache the EDID value for a short time in i915 during the boot process we have several places that want to make sure we have EDID information in a short time. An EDID probe for me takes 0.23 seconds, so doing multiple of them is not very nice. This patch caches the EDID result for upto 1 second to avoid repeated delays. Signed-off-by: Arjan van de Ven ar...@linux.intel.com I'm holding off on this one. I'm applying the LVDS caching (makes complete sense) but I think someone needs to take a serious look at the requests for modes on outputs by the kernel and be sure that we've separated I want you go to reprobe and then tell me the current data from tell me what the current set of modes is. Once that's done, I expect this patch goes away. for me the caching patch obsoletes this one, so absolutely fine by me. -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] KMS: Do the actual mode setting from asynchronous context
On Fri, 27 Mar 2009 15:57:54 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: On Mon, 23 Mar 2009 13:46:23 -0700 Arjan van de Ven ar...@infradead.org wrote: From dfe256fc9d28f240f1a84fb4c3dfed4a4e18d5d4 Mon Sep 17 00:00:00 2001 From: Arjan van de Ven ar...@linux.intel.com Date: Mon, 23 Mar 2009 13:32:47 -0700 Subject: [PATCH] KMS: Do the actual mode setting from asynchronous context The mode setting (and the expensive part of mode detection) can take quite a bit of time, and will delay the kernel boot quite a bit. This patch puts these two parts into async context, so that the normal execution of the system continues while the slow hardware probing and poking happens. I'm curious if the patch I recently posted to add the idea of a primary head to the driver have a similar effect? It avoids probing secondary connectors if the primary one is found, so it should provide the same speedup as this one. part of (actually the majority of) the improvement is from doing the actual modeset async that is where on my systems most of the time goes. The probing only applies if you actually connect a vga screen... -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] KMS: cache the EDID information of the LVDS
On Fri, 27 Mar 2009 16:08:18 -0700 Jesse Barnes jbar...@virtuousgeek.org wrote: return ret; I definitely like the idea of caching the LVDS EDID, but rather than adding it to the intel_output struct I'd rather see it stored with the rest of the LVDS stuff in i915_private (though that stuff should be pulled out into an output private at some point). We could also just open code the intel_ddc_get_modes stuff in intel_lvds_init, getting the EDID just once, storing the property once, and adding the mode list once. intel_lvds_get_modes would need to be fixed too... that gets a bit messy though, esp if other output types decide to also want to cache. Remember that some of this code gets called from DRM or even userland, so the edid will end up being stored in a generic structure -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] KMS: register the LVDS before the CRT
On Thu, 26 Mar 2009 11:59:13 +0100 Jakob Bornecrantz wallbra...@gmail.com wrote: On Mon, Mar 23, 2009 at 9:46 PM, Arjan van de Ven ar...@infradead.org wrote: From 785bb9f968ead288395ead4f921d7c1fb794ee71 Mon Sep 17 00:00:00 2001 From: Arjan van de Ven ar...@linux.intel.com Date: Mon, 23 Mar 2009 13:34:46 -0700 Subject: [PATCH] KMS: register the LVDS before the CRT for the cases where the user only really cares about lighting up one output, or only one output at first, lighting up the LVDS (which only gets detected with lid-up) rather than the CRT is the right answer. This patch flips their order of registration so that this becomes possible. Signed-off-by: Arjan van de Ven ar...@linux.intel.com Not-acked-by: Jakob Bornecrantz wallbra...@gmail.com I'm going to nack this patch out of principle, getting the correct behavior from userspace depending on the order of connectors is bad. this has nothing to do with userspace though, but all about user choice. The interface gives you enough information to find the LVDS and turn that on only that on. Is there some other reason that the getting of output name is slow? If so I would be happy to see patches that fixes that. This patch has nothing to do with speed; it is only about registration order. LVDS-before-CRT makes total sense (as long as the lid of the laptop is not closed, which is why I added the comment); while CRT-before-LVDS does not. -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] KMS: register the LVDS before the CRT
On Thu, 26 Mar 2009 15:59:12 +0100 Jakob Bornecrantz wallbra...@gmail.com wrote: On Thu, Mar 26, 2009 at 3:25 PM, Arjan van de Ven ar...@infradead.org wrote: On Thu, 26 Mar 2009 11:59:13 +0100 Jakob Bornecrantz wallbra...@gmail.com wrote: On Mon, Mar 23, 2009 at 9:46 PM, Arjan van de Ven ar...@infradead.org wrote: From 785bb9f968ead288395ead4f921d7c1fb794ee71 Mon Sep 17 00:00:00 2001 From: Arjan van de Ven ar...@linux.intel.com Date: Mon, 23 Mar 2009 13:34:46 -0700 Subject: [PATCH] KMS: register the LVDS before the CRT for the cases where the user only really cares about lighting up one output, or only one output at first, lighting up the LVDS (which only gets detected with lid-up) rather than the CRT is the right answer. This patch flips their order of registration so that this becomes possible. Signed-off-by: Arjan van de Ven ar...@linux.intel.com Not-acked-by: Jakob Bornecrantz wallbra...@gmail.com I'm going to nack this patch out of principle, getting the correct behavior from userspace depending on the order of connectors is bad. this has nothing to do with userspace though, but all about user choice. Hard coding a specific order is not giving the user choice. Please tell me how doing crt-before-lvds fails with something that isn't userspace, currently I don't see how the order is important? Last time I checked there where only one kernel side consumer of the kms, the legacy fbdev stuff. Which if I remember correctly tried to clone one fb to all connectors. If you want to do some sort of no clone setup with fbdev you should let the user define the binding on the command line. Something like i915 fb0=lvds0 fb1=crt0. There might be some issues with this naming and hotplugable connectors. so the other patches in this patch series added a consumer that basically lights up the first one and then continues booting the kernel, while the all but first get detected asynchronously. The concern from various people was that if there was an oops, around that time, it should be on the primary display, where the driver decided what was primary. This patch has nothing to do with speed; it is only about registration order. LVDS-before-CRT makes total sense (as long as the lid of the laptop is not closed, which is why I added the comment); while CRT-before-LVDS does not. It makes totally sense for you, for somebody else not, which is why policy in the kernel is a bad idea. complaining about a change in policy by saying there should be no policy is not very useful; the policy is there today. What happens if the lid is closed? Is no lvds connector created? The comment you added make it sounds so, at least that was my first impression. that is what the rest of the code says yes. I just wanted to add the comment to show that. -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] KMS: do a faster EDID
From a121507f31e37a809dfa21c9756aa83f36d7acbf Mon Sep 17 00:00:00 2001
From: Arjan van de Ven ar...@linux.intel.com
Date: Mon, 23 Mar 2009 13:37:20 -0700
Subject: [PATCH] KMS: do a faster EDID
for some outputs (like LVDS), the current delays in the EDID reader are way
overkill.
This patch makes the EDID reader try twice; first with a 5x faster probe, and
if that fails, it probes at the current speed. This reduces probe time on my
LVDS
panel significantly.
Signed-off-by: Arjan van de Ven ar...@linux.intel.com
---
drivers/gpu/drm/drm_edid.c | 22 +-
1 files changed, 13 insertions(+), 9 deletions(-)
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;
algo_data-setscl(algo_data-data, 1);
- for (i = 0; i 1; i++) {
+ for (i = 0; i 2; i++) {
/* For some old monitors we need the
* following process to initialize/stop DDC
*/
+
algo_data-setsda(algo_data-data, 1);
- msleep(13);
+ msleep(13 / divider);
algo_data-setscl(algo_data-data, 1);
for (j = 0; j 5; j++) {
- msleep(10);
+ msleep(10 / divider);
if (algo_data-getscl(algo_data-data))
break;
}
@@ -609,31 +611,33 @@ static unsigned char *drm_ddc_read(struct i2c_adapter
*adapter)
continue;
algo_data-setsda(algo_data-data, 0);
- msleep(15);
+ msleep(15 / divider);
algo_data-setscl(algo_data-data, 0);
- msleep(15);
+ msleep(15 / divider);
algo_data-setsda(algo_data-data, 1);
- msleep(15);
+ msleep(15 / divider);
/* Do the real work */
edid = drm_do_probe_ddc_edid(adapter);
algo_data-setsda(algo_data-data, 0);
algo_data-setscl(algo_data-data, 0);
- msleep(15);
+ msleep(15 / divider);
algo_data-setscl(algo_data-data, 1);
for (j = 0; j 10; j++) {
- msleep(10);
+ msleep(10 / divider);
if (algo_data-getscl(algo_data-data))
break;
}
algo_data-setsda(algo_data-data, 1);
- msleep(15);
+ msleep(15 / divider);
algo_data-setscl(algo_data-data, 0);
algo_data-setsda(algo_data-data, 0);
+
if (edid)
break;
+ divider = 1;
}
/* Release the DDC lines when done or the Apple Cinema HD display
* will switch off
--
1.6.0.6
--
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
[PATCH] KMS: cache the EDID information of the LVDS
From eb512d6d953c8acc8abe1048862a92cec58d9791 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven ar...@linux.intel.com
Date: Mon, 23 Mar 2009 13:38:49 -0700
Subject: [PATCH] KMS: cache the EDID information of the LVDS
you're not going to replace your LVDS at runtime. so this patch
caches the EDID information of the LVDS. An LVDS probe can easily take
200 milliseconds, and we do this multiple times during a system startup.
Signed-off-by: Arjan van de Ven ar...@linux.intel.com
---
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_lvds.c |2 ++
drivers/gpu/drm/i915/intel_modes.c |8 +++-
3 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 957daef..22a74bd 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -81,6 +81,7 @@ struct intel_output {
int type;
struct intel_i2c_chan *i2c_bus; /* for control functions */
struct intel_i2c_chan *ddc_bus; /* for DDC only stuff */
+ struct edid *edid;
bool load_detect_temp;
bool needs_tv_clock;
void *dev_priv;
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index 0d211af..dc4fecc 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -336,6 +336,7 @@ static void intel_lvds_destroy(struct drm_connector
*connector)
intel_i2c_destroy(intel_output-ddc_bus);
drm_sysfs_connector_remove(connector);
drm_connector_cleanup(connector);
+ kfree(intel_output-edid);
kfree(connector);
}
@@ -516,5 +517,6 @@ failed:
if (intel_output-ddc_bus)
intel_i2c_destroy(intel_output-ddc_bus);
drm_connector_cleanup(connector);
+ kfree(intel_output-edid);
kfree(connector);
}
diff --git a/drivers/gpu/drm/i915/intel_modes.c
b/drivers/gpu/drm/i915/intel_modes.c
index e42019e..83816a4 100644
--- a/drivers/gpu/drm/i915/intel_modes.c
+++ b/drivers/gpu/drm/i915/intel_modes.c
@@ -70,13 +70,19 @@ int intel_ddc_get_modes(struct intel_output *intel_output)
struct edid *edid;
int ret = 0;
+ if (intel_output-edid)
+ return ret;
+
edid = drm_get_edid(intel_output-base,
intel_output-ddc_bus-adapter);
if (edid) {
drm_mode_connector_update_edid_property(intel_output-base,
edid);
ret = drm_add_edid_modes(intel_output-base, edid);
- kfree(edid);
+ if (intel_output-type == INTEL_OUTPUT_LVDS)
+ intel_output-edid = edid;
+ else
+ kfree(edid);
}
return ret;
--
1.6.0.6
--
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
[PATCH] KMS: Do the actual mode setting from asynchronous context
From dfe256fc9d28f240f1a84fb4c3dfed4a4e18d5d4 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven ar...@linux.intel.com
Date: Mon, 23 Mar 2009 13:32:47 -0700
Subject: [PATCH] KMS: Do the actual mode setting from asynchronous context
The mode setting (and the expensive part of mode detection) can take
quite a bit of time, and will delay the kernel boot quite a bit.
This patch puts these two parts into async context, so that the
normal execution of the system continues while the slow hardware
probing and poking happens.
Signed-off-by: Arjan van de Ven ar...@linux.intel.com
---
drivers/gpu/drm/drm_crtc_helper.c | 50 ++--
drivers/gpu/drm/drm_drv.c |4 +++
include/drm/drmP.h|1 +
3 files changed, 52 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index 1c3a8c5..7aa3107 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -29,6 +29,8 @@
* Jesse Barnes jesse.bar...@intel.com
*/
+#include linux/async.h
+
#include drmP.h
#include drm_crtc.h
#include drm_crtc_helper.h
@@ -42,6 +44,8 @@ static struct drm_display_mode std_modes[] = {
DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
};
+LIST_HEAD(drm_async_list);
+
/**
* drm_helper_probe_connector_modes - get complete set of display modes
* @dev: DRM device
@@ -137,6 +141,26 @@ int drm_helper_probe_connector_modes(struct drm_device
*dev, uint32_t maxX,
}
EXPORT_SYMBOL(drm_helper_probe_connector_modes);
+int drm_helper_probe_connector_modes_fast(struct drm_device *dev, uint32_t
maxX,
+ uint32_t maxY)
+{
+ struct drm_connector *connector;
+ int count = 0;
+
+ list_for_each_entry(connector, dev-mode_config.connector_list, head) {
+ count += drm_helper_probe_single_connector_modes(connector,
+maxX, maxY);
+ /*
+* If we found a 'good' connector, we stop probing futher.
+*/
+ if (count 0)
+ break;
+ }
+
+ return count;
+}
+EXPORT_SYMBOL(drm_helper_probe_connector_modes_fast);
+
static void drm_helper_add_std_modes(struct drm_device *dev,
struct drm_connector *connector)
{
@@ -882,6 +906,24 @@ bool drm_helper_plugged_event(struct drm_device *dev)
/* FIXME: send hotplug event */
return true;
}
+
+static void async_notify_fb_changed(void *data, async_cookie_t cookie)
+{
+ struct drm_device *dev = data;
+ /* Need to wait for async_probe_hard be done */
+ async_synchronize_cookie_domain(cookie, drm_async_list);
+ dev-mode_config.funcs-fb_changed(dev);
+}
+
+static void async_probe_hard(void *data, async_cookie_t cookie)
+{
+ struct drm_device *dev = data;
+ drm_helper_probe_connector_modes(dev,
+ dev-mode_config.max_width,
+ dev-mode_config.max_height);
+}
+
+
/**
* drm_initial_config - setup a sane initial connector configuration
* @dev: DRM device
@@ -902,7 +944,7 @@ bool drm_helper_initial_config(struct drm_device *dev, bool
can_grow)
struct drm_connector *connector;
int count = 0;
- count = drm_helper_probe_connector_modes(dev,
+ count = drm_helper_probe_connector_modes_fast(dev,
dev-mode_config.max_width,
dev-mode_config.max_height);
@@ -920,8 +962,10 @@ bool drm_helper_initial_config(struct drm_device *dev,
bool can_grow)
drm_setup_crtcs(dev);
- /* alert the driver fb layer */
- dev-mode_config.funcs-fb_changed(dev);
+ /* probe further outputs asynchronously */
+ async_schedule_domain(async_probe_hard, dev, drm_async_list);
+ /* alert the driver fb layer to actually change the mode */
+ async_schedule_domain(async_notify_fb_changed, dev, drm_async_list);
return 0;
}
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 14c7a23..ef52021 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -48,6 +48,7 @@
#include drmP.h
#include drm_core.h
+#include linux/async.h
static int drm_version(struct drm_device *dev, void *data,
struct drm_file *file_priv);
@@ -345,6 +346,9 @@ void drm_exit(struct drm_driver *driver)
struct drm_device *dev, *tmp;
DRM_DEBUG(\n);
+ /* make sure all async DRM operations are finished */
+ async_synchronize_full_domain(drm_async_list);
+
list_for_each_entry_safe(dev, tmp, driver-device_list, driver_item)
drm_cleanup(dev);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index e5f4ae9..69ce4f4 100644
--- a/include/drm/drmP.h
+++ b
[PATCH] KMS: register the LVDS before the CRT
From 785bb9f968ead288395ead4f921d7c1fb794ee71 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven ar...@linux.intel.com
Date: Mon, 23 Mar 2009 13:34:46 -0700
Subject: [PATCH] KMS: register the LVDS before the CRT
for the cases where the user only really cares about lighting up one output,
or only one output at first, lighting up the LVDS (which only gets detected
with lid-up) rather than the CRT is the right answer.
This patch flips their order of registration so that this becomes possible.
Signed-off-by: Arjan van de Ven ar...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index a283427..c0ab079 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1466,12 +1466,12 @@ static void intel_setup_outputs(struct drm_device *dev)
struct drm_i915_private *dev_priv = dev-dev_private;
struct drm_connector *connector;
- intel_crt_init(dev);
-
- /* Set up integrated LVDS */
+ /* Set up integrated LVDS -- will skip if the lid is closed */
if (IS_MOBILE(dev) !IS_I830(dev))
intel_lvds_init(dev);
+ intel_crt_init(dev);
+
if (IS_I9XX(dev)) {
int found;
--
1.6.0.6
--
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
[PATCH] KMS: clean up udelay usage
From 04795556b9ef5cd036a182535d04c4c853b61c96 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven ar...@linux.intel.com
Date: Mon, 23 Mar 2009 13:36:25 -0700
Subject: [PATCH] KMS: clean up udelay usage
udelay() of 20 milliseconds really ought to just use mdelay(), that avoids
the various wrap scenarios and also is more readable
Signed-off-by: Arjan van de Ven ar...@linux.intel.com
---
drivers/gpu/drm/i915/intel_display.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c0ab079..6f2eced 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);
}
static int
--
1.6.0.6
--
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
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
[PATCH] drm: Cache the EDID value for a short time in i915
From 8ad1bd63c097f9f6948439c1ce7c0b17b8caa64a Mon Sep 17 00:00:00 2001
From: Arjan van de Ven ar...@linux.intel.com
Date: Mon, 16 Mar 2009 19:31:39 -0700
Subject: [PATCH] drm: Cache the EDID value for a short time in i915
during the boot process we have several places that want to make sure we have
EDID information in a short time. An EDID probe for me takes 0.23 seconds, so
doing multiple of them is not very nice.
This patch caches the EDID result for upto 1 second to avoid repeated
delays.
Signed-off-by: Arjan van de Ven ar...@linux.intel.com
---
drivers/gpu/drm/i915/intel_drv.h |1 +
drivers/gpu/drm/i915/intel_modes.c |4
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 957daef..72e6b9a 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -81,6 +81,7 @@ struct intel_output {
int type;
struct intel_i2c_chan *i2c_bus; /* for control functions */
struct intel_i2c_chan *ddc_bus; /* for DDC only stuff */
+ unsigned long last_edid;
bool load_detect_temp;
bool needs_tv_clock;
void *dev_priv;
diff --git a/drivers/gpu/drm/i915/intel_modes.c
b/drivers/gpu/drm/i915/intel_modes.c
index e42019e..7c21b53 100644
--- a/drivers/gpu/drm/i915/intel_modes.c
+++ b/drivers/gpu/drm/i915/intel_modes.c
@@ -70,6 +70,9 @@ int intel_ddc_get_modes(struct intel_output *intel_output)
struct edid *edid;
int ret = 0;
+ if (intel_output-last_edid time_after(intel_output-last_edid+HZ,
jiffies))
+ return 0;
+
edid = drm_get_edid(intel_output-base,
intel_output-ddc_bus-adapter);
if (edid) {
@@ -77,6 +80,7 @@ int intel_ddc_get_modes(struct intel_output *intel_output)
edid);
ret = drm_add_edid_modes(intel_output-base, edid);
kfree(edid);
+ intel_output-last_edid = jiffies;
}
return ret;
--
1.6.0.6
--
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
Re: [git pull] drm patches for 2.6.27-rc1
On Sat, 18 Oct 2008 17:38:11 -0700 Keith Packard [EMAIL PROTECTED] wrote: I've got Venki lined up to do this work for me; once we're happy enough with the API. In particular, the non-highmem 32-bit case seems a bit tricky. Also, does anyone have a better set of names for this stuff? io_reserve_pci_mapping seems fairly ugly to me. how about pci_resource_force_caching(pci_dev, barnr, cachetype)? -- Arjan van de VenIntel Open Source Technology Centre For development, discussion and tips for power savings, visit http://www.lesswatts.org - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: io resources and cached mappings (was: [git pull] drm patches for 2.6.27-rc1)
On Sun, 19 Oct 2008 19:53:20 +0200
Ingo Molnar [EMAIL PROTECTED] wrote:
struct resource {
resource_size_t start;
resource_size_t end;
const char *name;
unsigned long flags;
struct resource *parent, *sibling, *child;
+ void *mapping;
};
The APIs would be:
int io_resource_init_mapping(struct resource *res);
void io_resource_free_mapping(struct resource *res);
void * io_resource_map(struct resource *res, pfn_t pfn, unsigned
long offset); void io_resource_unmap(struct resource *res, void
*kaddr);
Note how simple and consistent it all gets: IO resources already know
their physical location and their size limits. Being able to cache an
ioremap in a mapping [and being able to use atomic kmaps on 32-bit]
is a relatively simple and natural extension to the concept.
and making a simple wrapper around this that turns struct pci_dev,
barnr into a resource would make sense too, but yes.
We need one more
io_resource_force_cachability(struct resource, cachetype)
or maybe only
io_resource_force_writecombine(struct resource)
--
Arjan van de VenIntel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100url=/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.14-rt4: via DRM errors
On Fri, 2005-11-25 at 14:05 -0500, Lee Revell wrote: On Thu, 2005-11-24 at 07:31 -0800, Jesse Barnes wrote: Sounds interesting, but that would be card specific, right? I mean, on some cards the 2d and 3d locks would have to be the same because of shared state or whatever, for example. Not especially, that's how most Linux drivers work. The locking in the DRM seems unusually coarse grained. of course sometimes having less but more coarse locks is actually faster. Taking/dropping a lock is not free. far from it. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Remove DRM_ARRAY_SIZE
On Sun, 2005-09-25 at 00:56 +0100, Dave Airlie wrote: drivers/char/drm/drmP.h defines a macro DRM_ARRAY_SIZE(x) for determining the size of an array. kernel.h already provides one. Signed-off-by: Alexey Dobriyan [EMAIL PROTECTED] Nak. We have DRM_ for cross platform reasons in DRM, I could in theory get rid of all of them in the kernel, but it would make the merging of code from DRM CVS even more of a nightmare, ok so this brings the question: how does naming it DRM_ARRAY_SIZE make it more portable than naming it ARRAY_SIZE? If *BSD doesn't have ARRAY_SIZE, then surely naming it ARRAY_SIZE is easy for them to provide (after all they need to provide it already just called DRM_ARRAY_SIZE); if they have ARRAY_SIZE... then I assume it has the exact same semantics --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon-pre-2
On Mon, 2004-09-13 at 00:42, Dave Airlie wrote: works well, and the X team decide to do a decent X on mesa-solo on Jons super-DRM, now the super-DRM gets pushed via the X tree and distributions start relasing kernels with it merged into it and it never goes into the main tree... it won't matter, RH/SuSE/whomever will want to pick up the new features for the *enhanced user experience* and people will give out fwiw RH will ship the DRM that is in Linus' kernel not some weird oddball external one, so at least that portion of your argument is moot ;) signature.asc Description: This is a digitally signed message part
Re: New proposed DRM interface design
On Sat, 2004-09-04 at 11:43, Dave Airlie wrote: Umm, the Linux kernel isn't about minimizing interfaces. We don't link a copy of scsi helpers into each scsi driver either, or libata into each sata driver. true but the DRM isn't only about the Linux kernel, the DRM is a lowlevel component of a much larger system, of which the DRM just has to reside in the kernel, you seem to be confusing 2 things. The kernel-userspace interface is supposed to be stable, and it should be so that you can basically decouple X and kernel versions. Within the kernel you should go for the best interface (where best is a notion that is flexible over time) because 1) you can and 2) you are suboptimal in both performance and maintenance if you don't signature.asc Description: This is a digitally signed message part
Re: New proposed DRM interface design
If we make a library split that sits inside the kernel, their DRM can stop working if someone busts the interface, hence the idea of having the core reg/dereg in the kernel, and locking it down, then they can ship a complete DRM source tree, and do as they wish as long as they interface properly with the core... or they just ship their own matching core .c file as well Lets face it, for the core there are 2 things that are entirely at conflicts: small interface and core being useful. I rather go for the useful side myself. signature.asc Description: This is a digitally signed message part
Re: DRM and 2.4 ...
On Mon, 2004-08-16 at 07:56, Dave Airlie wrote: At the moment we are adding a lot of 2.6 stuff to the DRM under development in the DRM CVS tree and what will be merged into the -mm and Linus trees eventually, this has meant ifdefing stuff out so 2.4 will still work, which is uglyfying the code significantly if done wrong So the question is do we want to a final stable DRM for 2.4 in the next 2.4 release? and after that point I can tag the 2.4 release in the DRM CVS tree (and maybe branch it ...), I would strongly urge you to no longer update DRM in 2.4 in significant ways. 2.4 is the release for doing strict maintenance; people who want to run newer X will generally run 2.6 kernels as well anyway. signature.asc Description: This is a digitally signed message part
Re: DRM and 2.4 ...
On Mon, Aug 16, 2004 at 10:43:34AM +0100, Keith Whitwell wrote: If we can manage to support FreeBSD and Linux from one codebase, surely supporting 2.4 and 2.6 isn't too difficult? It for sure is possible. However the DRM codebase proves that it's incapable of even doing BSD support properly (eg without the right abstractions but instead fouling up the entire codebase to the point of unreadability). That gives me no confidence the keep 2.4 support will not turn out to be at least as ugly/broken/wrong. pgplIxRSAz9Xp.pgp Description: PGP signature
Re: DRM and 2.4 ...
On Mon, Aug 16, 2004 at 11:12:53AM +0100, Keith Whitwell wrote: Most of the abstractions that you're complaining about existed prior to the addition of freebsd support DRM_IOCTL_ARGS, DRM_ERR, DRM_CURRENTPID, DRM_UDELAY, DRM_READMEMORYBARRIER, DRM_COPY_FROM_USER_IOCTL etc etc existed prior to freebsd support? Oh my god... pgpW27UTY1SYA.pgp Description: PGP signature
Re: DRM and 2.4 ...
On Mon, Aug 16, 2004 at 11:42:00AM +0100, Dave Airlie wrote: DRM_IOCTL_ARGS, DRM_ERR, DRM_CURRENTPID, DRM_UDELAY, DRM_READMEMORYBARRIER, DRM_COPY_FROM_USER_IOCTL etc etc existed prior to freebsd support? Oh my god... I'm currently open for constructive critics with ideas on how to fix these things, the DRM is open for business if we can fix things up now it will be a lot easier while I'm knee deep with time than after I'm finished and back travelling .. should we have try to implement Linux fns in BSD, what do we do if more parameters/info are needed from a BSD side, or do we try and sideline all these into a separate library of functions and wrap them on both bsd and linux? it's a bit of all of this. If BSD doesn't have a conflicting udelay(), why not just implement one there instead of a superfluous rename. DRM_ERR() otoh should have been dealt with by making a core function for the ioctl with only the really needed/used arguments (probably even such that the arguments are already copied from userspace) and then a linux and a bsd specific API wrapper. The BSD one can then easily flip the sign (that's basically free), it also takes case of DRM_IOCTL_ARGS mess as well and DRM_COPY_FROM_USER_IOCTL if you do it right. DRM_CURRENTPID probably shouldn't exist at all, drivers shouldn't use pid's in general. pgp85oF0sWx6A.pgp Description: PGP signature
Re: drm - first steps towards 64-bit correctness..
On Sat, 2004-07-31 at 11:32, Eric Anholt wrote: As long as you don't use the linux-y u32-type types, BSD should be happy with the changes. can you explain why u32 would be outlawed? Surely it's trivial to do a typedef for u32 on BSD for drm ?? signature.asc Description: This is a digitally signed message part
Re: [Dri-devel] 2.6 kernel change in nopage
On Thu, 2004-01-01 at 13:03, Michel Dnzer wrote: How does this patch look? ugly. I find using #defines for function arguments ugly beyond belief and makes it really hard to look through code. I 10x rather have an ifdef in the function prototype (which then for the mainstream kernel drm can be removed for non-matching versions) than such obfuscation. signature.asc Description: This is a digitally signed message part
Re: [Dri-devel] 2.6 kernel change in nopage
On Thu, Jan 01, 2004 at 01:23:40PM +0100, Michel Dänzer wrote: How does this patch look? ugly. I find using #defines for function arguments ugly beyond belief and makes it really hard to look through code. I 10x rather have an ifdef in the function prototype (which then for the mainstream kernel drm can be removed for non-matching versions) than such obfuscation. That doesn't strike me as particularly beautiful either... well the advantage is that the ifdefs can just go away in kernel trees of specific versions... (eg unifdef it) is it really easier for merges, considering that the ugly way is kinda needed for functions which take different arguments on BSD anyway? I disagree there. The BSD takes different arguments thing *should* be fixed imo by making the common core of the function an inline function, and have one or two (depends if the common core happens to have its arguments in common with one of the oses) OS specific wrappers with the right prototype. This way the difference in error return sign can also be solved in the wrapper instead of with a nasty macro... The compiler generates the same code, but it's a lot easier to read/review. Greetings, Arjan van de Ven pgp0.pgp Description: PGP signature
[Dri-devel] Re: any DRM update scheduled for 2.4.23-pre?
It's a complete DRM-4.3 tree. He has to decide between an update of existing 4.2 code or an addition of a new subdirectory drm-4.3 + proper config.in entry. did you clean the tree up like in -ac's tree or did you take it as is from some cvs repo ? signature.asc Description: This is a digitally signed message part
