Re: Regression in panic
On Mon, 20 Jun 2011, Mandeep Singh Baines wrote: Hi Dave, I think this change is causing a regression I'm seeing in panic. Before this change, I'd get a reboot on panic (we've configured as such). With this change, my machine gets wedged if the machine is running in X when the panic occurs. I traced the code flow to this: bust_spinlocks(0); -unblank_screen(); -do_unblank_screen(0); -vc-vc_sw-con_blank(vc, 0, 0); -fbcon_blank(vc, 0, 0); -update_screen(vc); -redraw_screen(vc, 0); -vc-vc_sw-con_switch(vc); -fbcon_switch(vc); -ops-update_start(info); -bit_update_start(info); -fb_pan_display(info, ops-var); -info-fbops-fb_pan_display(var, info); -drm_fb_helper_pan_display(var, info); -mutex_lock(dev-mode_config.mutex); *this blocks* With this change, there is now a lot going on in the panic path. Stuff that I'm not sure is safe when panicking. In addition to the mutex_lock, there is also a del_timer_sync() now happening in the context of panic(). I see this bug with a 2.6.38 kernel but did a quick scan of a newer kernels and did not see anything that changed in this path so I suspect its still there. Reverting this change fixes the regression. Chris Fowler reports something similar when running 2.6.38 by inducing a kernel panic via the oom killer -- see http://marc.info/?l=linux-kernelm=130805985022791. I've added him to the cc so he can participate in the thread and cherry-pick any fixes (last status update was that he was going to be trying 2.6.38.8). -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Regression] [PATCH] intel_crt_detect_ddc() seems to be broken for DVI-I
Hello
Since Linux 2.6.36 the digital output on my system (855GME + DVI-I) is
not working any longer. The analog output is always activated regardless
of the type of monitor attached.
The culprit seems to be intel_crt_detect_ddc(), which returns true as
soon as an ACK from the EDID device is received. Obviously this approach
does not work with DVI-I where the analog and digital outputs share a
common DDC bus.
The patch below adds an additional check to make sure that there is
really an analog device attached (similar to the Mac mini hack in
intel_sdvo.c)
Signed-off-by: David Müller d.muel...@elsoft.ch
diff -dpurN a/drivers/gpu/drm/i915/intel_crt.c
b/drivers/gpu/drm/i915/intel_crt.c
--- a/drivers/gpu/drm/i915/intel_crt.c 2011-01-05 10:35:18.44923 +0100
+++ b/drivers/gpu/drm/i915/intel_crt.c 2011-01-06 12:16:47.630998952 +0100
@@ -30,6 +30,7 @@
#include drm.h
#include drm_crtc.h
#include drm_crtc_helper.h
+#include drm_edid.h
#include intel_drv.h
#include i915_drm.h
#include i915_drv.h
@@ -287,8 +288,9 @@ static bool intel_crt_ddc_probe(struct d
return i2c_transfer(dev_priv-gmbus[ddc_bus].adapter, msgs, 1) == 1;
}
-static bool intel_crt_detect_ddc(struct intel_crt *crt)
+static bool intel_crt_detect_ddc(struct drm_connector *connector)
{
+ struct intel_crt *crt = intel_attached_crt(connector);
struct drm_i915_private *dev_priv = crt-base.base.dev-dev_private;
/* CRT should always be at 0, but check anyway */
@@ -301,8 +303,26 @@ static bool intel_crt_detect_ddc(struct
}
if (intel_ddc_probe(crt-base, dev_priv-crt_ddc_pin)) {
- DRM_DEBUG_KMS(CRT detected via DDC:0x50 [EDID]\n);
- return true;
+ struct edid *edid;
+ bool is_digital = false;
+
+ edid = drm_get_edid(connector,
+ dev_priv-gmbus[dev_priv-crt_ddc_pin].adapter);
+ /*
+* This may be a DVI-I connector with a shared DDC
+* link between analog and digital outputs, so we
+* have to check the EDID input spec of the attached device.
+*/
+ if (edid != NULL) {
+ is_digital = edid-input DRM_EDID_INPUT_DIGITAL;
+ connector-display_info.raw_edid = NULL;
+ kfree(edid);
+ }
+
+ if (!is_digital) {
+ DRM_DEBUG_KMS(CRT detected via DDC:0x50 [EDID]\n);
+ return true;
+ }
}
return false;
@@ -458,7 +478,7 @@ intel_crt_detect(struct drm_connector *c
}
}
- if (intel_crt_detect_ddc(crt))
+ if (intel_crt_detect_ddc(connector))
return connector_status_connected;
if (!force)
@@ -472,7 +492,7 @@ intel_crt_detect(struct drm_connector *c
crtc = intel_get_load_detect_pipe(crt-base, connector,
NULL, dpms_mode);
if (crtc) {
- if (intel_crt_detect_ddc(crt))
+ if (intel_crt_detect_ddc(connector))
status = connector_status_connected;
else
status = intel_crt_load_detect(crtc, crt);
--
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and,
should the need arise, upgrade to a full multi-node Oracle RAC database
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.33.2 kmalloc-8 slab leaks ~512 objects per second
On Thu, 13 May 2010, Tvrtko Ursulin wrote: You could just enable CONFIG_DEBUG_KMEMLEAK on 2.6.33, mount the debugfs and do a 'cat /sys/kernel/debug/kmemleak' after a half-hour or so. I could do it if radeon/drm guys would be interested in those results? (Given how 2.6.34-rc7 is not leaking.) Did you get a chance to find out if kmemleak was able to identify the source of this problem? -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Fri, 5 Mar 2010 12:38:34 + The conclusion is crystal clear, breaking an ABI via a flag day cleanup/feature/etc is: Ingo go read the staging Kconfig. It's crystal clear, and lots of vendor junk that is in there being cleaned up it would be *insane* to keep their old APIs See there's a bigger offence than breaking an ABI - its called not RTFM. All of this RTFM and what directory the noveau driver is sitting in is entirely irrelevant Alan. If it effects such a large number of people, which this noveau thing does, it's entirely relevant to everyone. And the way it's breaking and making kernel development difficult for so many people matters to us. It's about the tester base, and this breakage shrinks the tester base considerably. Or do you want the kernel tested by less people? -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Fri, 5 Mar 2010 15:09:34 + I think you miss a bigger picture ? If Fedora hadn't merged it then it wouldn't have gotten to the state of usability it had. If Fedora hadn't merged it then several hundred thousand users wouldn't have had useful working machines. I think Fedora were right to merge it, and I think it was proper to merge it into the upstream kernel. But I also think the large size of that userbase should have been respected by doing the right thing here, and that means not making it so hard for Fedora users to use upstream kernels out of the box. Making the sandbox claim cuts both ways Alan. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 17:17:54 +0200 On Fri, Mar 05, 2010 at 06:37:18AM -0800, David Miller wrote: If it effects such a large number of people, which this noveau thing does, it's entirely relevant to everyone. And the way it's breaking and making kernel development difficult for so many people matters to us. Maybe the lesson to be learned from all this is, 'if the developers don't want something merged because they're not ready and forsee huge problems in the future, actually listen to them instead of blindly ramming it in regardless'? But maybe that's just me. That's doesn't work, and it never will. First of all, if we didn't merge the driver Fedora users wouldn't be able to test the upstream kernel at all. And if you think things through, there is one and onle one set of actions that would have made things work properly. And that's merge the driver upstream and not break user visible APIs. In fact, I argue that the moment nouveau went into Fedora and was turned on by default, the interfaces needed to be frozen. Consider if it didn't go upstream and I want to do upstream kernel development, ok so I patch the noveau-of-the-moment into my upstream tree. Six months and 10 DRM library updates later I go back and try to boot that kernel. And it's not going to work. So if the user visible APIs are changed in any set of situations (upstream merged, not upstream merged, etc.) things can end up breaking. Ergo, you simply can't sanely do it at all. You have to have a compatability story when you change these things. Personally I wouldn't have ever committed to that user visible APIs can break cause it's in -stable. Because that's complete garbage. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 17:40:09 +0200 On Fri, Mar 05, 2010 at 07:26:12AM -0800, David Miller wrote: In fact, I argue that the moment nouveau went into Fedora and was turned on by default, the interfaces needed to be frozen. That's a matter for the Fedora kernel team; for better or worse, they made the choices they did, which included going through all the relevant pain to support this. They didn't consider it suitable for upstream because they didn't think everyone else should be forced to endure that pain. By not merging it upstream the pain is larger not smaller. It's enabled by default, so you therefore can't test upstream kernels by default. And as I showed already, even if you jump through the hoops to make it work (building noveau from out of tree in the upstream kernel) you'll end up getting screwed when the API changes anyways. Using VESA or whatever else you've suggested is just not a reasonable alternative. You can't unleash something like this on a userbase of this magnitude and then throw your hands up in the air and say I'm not willing to support this in a reasonable way. We're better than that. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test
From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 17:41:43 +0200 I understand that you guys are upset about this, so maybe you'd like to donate, say, 10% of your developer base to help out? That'd be pretty ace. You have to support less than %10 of the amount of hardware we have to support. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Fri, 5 Mar 2010 16:02:17 + You can't unleash something like this on a userbase of this magnitude and then throw your hands up in the air and say I'm not willing to support this in a reasonable way. Not to belabour the obvious - they didn't. Linus ordered them to merge it. And I'm arguing not merging it upstream would be like saying the same thing. We're better than that. If you consider the problem is with the Fedora kernel team decision to merge it into Fedora in the first place For the second time Alan, I don't. I think Fedora should have merged it. I think it should be upstream. And I think the API bustage needs to be avoided. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 18:04:34 +0200 So you're saying that there's no way to develop any reasonable body of code for the Linux kernel without committing to keeping your ABI absolutely rock-solid stable for eternity, no exceptions, ever? Cool, that worked really well for Xlib. read() still works the same way it did 30 years ago last time I checked. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test
From: Xavier Bestel xavier.bes...@free.fr Date: Fri, 05 Mar 2010 18:50:24 +0100 On Fri, 2010-03-05 at 07:49 -0800, David Miller wrote: From: Daniel Stone dan...@fooishbar.org Date: Fri, 5 Mar 2010 17:41:43 +0200 I understand that you guys are upset about this, so maybe you'd like to donate, say, 10% of your developer base to help out? That'd be pretty ace. You have to support less than %10 of the amount of hardware we have to support. You can't compare a network card and a GPU. The latter is way more complex to code for. I wasn't talking specifically about network cards. But if you want specific examples... How about the x86 or parisc cpu, and all their derivatives, are those complex enough for you? :-) I've worked on OpenGL capable grapics card drivers of various vintages, and I honestly don't think there is anything in there more complex than what we have to deal with in the kernel. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Making Xorg easier to test
From: Jesse Barnes jbar...@virtuousgeek.org Date: Fri, 5 Mar 2010 10:02:44 -0800 So from that perspective, the graphics stack is the most complex one in Linux by a long shot. It's even worse than if we had STREAMS networking with a ton of different modules up in userspace messing with protocol. :) Maybe :-) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: hung bootup with drm/radeon/kms: move radeon KMS on/off switch out of staging.
On Thu, 4 Feb 2010, Ingo Molnar wrote: * Jesse Barnes jbar...@virtuousgeek.org wrote: On Thu, 4 Feb 2010 20:32:32 +0100 Ingo Molnar mi...@elte.hu wrote: Nobody has reacted to my related boot hang bugreport yet - and it's detailed and fully reproducible (so i can test any proposed fixes as well in short order). I.e. my limited testing has triggered two separate bugs in the same driver - and this will show up in -rc7. It might be all OK and no-one else will see trouble. Or past patterns might repeat themselves and i might simply be an early bird for trouble to come. My (oft repeated) point is that adding new sub-features to existing drivers is not what we do in late -rc's: there's simply not enough time to shake out bugs/regressions in them. We introduce new functionality to existing drivers in the merge window - in the two weeks following a stable kernel's release. This is the .config issue right? It doesn't sound like the bug is new, you're just seeing now it because of the way you run tests. It shouldn't affect any more or fewer users than it did before, and reverting the move radeon KMS out of staging won't fix the bug at all or prevent anyone from seeing it. People using KMS will still use KMS and people without it won't, [...] I think you are missing my point. My point is very simple: existing non-KMS users of CONFIG_DRM_RADON=y (a pre-existing driver) might turn on the new sub-feature (CONFIG_DRM_RADEON_KMS=y), in the expectation that this is a safe addition to his currently well-working driver. ( I have to confess i do that all the time for drivers that work well for me, and if it pops up in a late -rc i sure expect it to be safe to enable. I dont even read the help text most of the time - if the single-line summary sounds useful i enable it. Especially if the Kconfig help entry says it's safe with a new distro, it's not CONFIG_EXPERIMENTAL, it's not marked CONFIG_BROKEN, it's not in CONFIG_STAGING, etc. ) forget the people testing the rc kernels, what about people who will see this in the released kernel? David Lang -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH v2] drm: Keep disabled outputs disabled after suspend / resume
On 12/31/2009 12:00 PM, David John wrote: With the current DRM code, an output that has been powered off from userspace will automatically power back on when resuming from suspend. This patch fixes this behaviour. Tested only with the Intel i915 driver on an Intel GM45 Express chipset. Signed-off-by: David John david...@xenontk.org Ping. Any update on this? Correct? Incorrect? Utter rubbish that I should be ashamed of myself? Regards, David. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/kms: fix fbdev blanking regression
On 01/07/2010 12:42 AM, Johan Hovold wrote: Yeap. The fix uncovered a bug in your driver. I haven't heard of problems with the other drm drivers. The backlight is handled via the DRI driver I assume. At least i9xx_crtc_dpms is called on powerdown. Can you post your dmesg and kernel config. [snip] Adding the Intel DRM people in CC as well. I have the same issue with my GM45. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm
From: Alan Cox a...@lxorguk.ukuu.org.uk Date: Fri, 11 Dec 2009 09:18:43 + However the fundamental point stands. The only people who can sign it off are the people who wrote it. Those are the rules. Red Hat didn't write the code, Red Hat cannot sign it off however much you rant at them. You also previously said you don't want to merge stuff when the authors don't want it merged. I agree with a lot of what you say. However, one point remains is that we were told, by Dave Airlie, that they didn't want this code merged because the one person being paid to work on it would be overwhelmed if the code went upstream. I distinctly remember this being mentioned at the kernel summit. And you know what? That kind of excuse pisses me off too :-) -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: is avoiding compat ioctls possible?
From: Heiko Carstens heiko.carst...@de.ibm.com Date: Thu, 29 Oct 2009 09:34:16 +0100 Subject: [PATCH] fs: add missing compat_ptr handling for FS_IOC_RESVSP ioctl From: Heiko Carstens heiko.carst...@de.ibm.com For FS_IOC_RESVSP and FS_IOC_RESVSP64 compat_sys_ioctl() uses its arg argument as a pointer to userspace. However it is missing a a call to compat_ptr() which will do a proper pointer conversion. This was introduced with 3e63cbb1 fs: Add new pre-allocation ioctls to vfs for compatibility with legacy xfs ioctls. Cc: Ankit Jain m...@ankitjain.org Cc: Christoph Hellwig h...@lst.de Cc: Al Viro v...@zeniv.linux.org.uk Cc: Arnd Bergmann arndbergm...@googlemail.com Reported-by: David Miller da...@davemloft.net Signed-off-by: Heiko Carstens heiko.carst...@de.ibm.com Acked-by: David S. Miller da...@davemloft.net -- 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: is avoiding compat ioctls possible?
From: Dave Airlie airl...@linux.ie Date: Wed, 28 Oct 2009 05:42:27 + (GMT) I'll add this to my TODO for before the next merge window as its definitely more than I can manage now. I'll do it. -- 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: is avoiding compat ioctls possible?
From: David Miller da...@davemloft.net
Date: Tue, 27 Oct 2009 23:04:50 -0700 (PDT)
From: Dave Airlie airl...@linux.ie
Date: Wed, 28 Oct 2009 05:42:27 + (GMT)
I'll add this to my TODO for before the next merge window as its
definitely more than I can manage now.
I'll do it.
Ok, everything was straightforward except for radeon_cs, which
has three levels of indirection for the tables of data and
relocation chunks userland can pass into the DRM :-/
There is no way to isolate the compat handling without parsing
and bringing the pointer array and the chunk headers into the
kernel twice.
So I guess I'm willing to capitulate with is_compat_task() checks in
radeon_cs_init(), but if you want to improve this interface I see two
ways:
1) Eliminate one level of indirection so there is just a straight
scatter-gather list at one level.
2) Use a base pointer and a set of offsets to communicate at least
one level of indirection.
Both schemes should satisfy the buffering flexibility these
interfaces seem to be geared towards giving to userland.
Anyways the following patch is tested and seems to work well.
Signed-off-by: David S. Miller da...@davemloft.net
diff --git a/drivers/gpu/drm/radeon/radeon_cs.c
b/drivers/gpu/drm/radeon/radeon_cs.c
index 5ab2cf9..ba44eba 100644
--- a/drivers/gpu/drm/radeon/radeon_cs.c
+++ b/drivers/gpu/drm/radeon/radeon_cs.c
@@ -24,6 +24,8 @@
* Authors:
*Jerome Glisse gli...@freedesktop.org
*/
+#include linux/compat.h
+
#include drmP.h
#include radeon_drm.h
#include radeon_reg.h
@@ -107,7 +109,12 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
if (p-chunks_array == NULL) {
return -ENOMEM;
}
- chunk_array_ptr = (uint64_t *)(unsigned long)(cs-chunks);
+#ifdef CONFIG_COMPAT
+ if (is_compat_task())
+ chunk_array_ptr = compat_ptr((compat_uptr_t) cs-chunks);
+ else
+#endif
+ chunk_array_ptr = (uint64_t *)(unsigned long)(cs-chunks);
if (DRM_COPY_FROM_USER(p-chunks_array, chunk_array_ptr,
sizeof(uint64_t)*cs-num_chunks)) {
return -EFAULT;
@@ -120,9 +127,15 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
for (i = 0; i p-nchunks; i++) {
struct drm_radeon_cs_chunk __user **chunk_ptr = NULL;
struct drm_radeon_cs_chunk user_chunk;
- uint32_t __user *cdata;
- chunk_ptr = (void __user*)(unsigned long)p-chunks_array[i];
+#ifdef CONFIG_COMPAT
+ if (is_compat_task())
+ chunk_ptr = compat_ptr((compat_uptr_t)
+ p-chunks_array[i]);
+ else
+#endif
+ chunk_ptr = (void __user*) (unsigned long)
+ p-chunks_array[i];
if (DRM_COPY_FROM_USER(user_chunk, chunk_ptr,
sizeof(struct drm_radeon_cs_chunk))) {
return -EFAULT;
@@ -142,9 +155,16 @@ int radeon_cs_parser_init(struct radeon_cs_parser *p, void
*data)
}
p-chunks[i].length_dw = user_chunk.length_dw;
- p-chunks[i].user_ptr = (void __user *)(unsigned
long)user_chunk.chunk_data;
+#ifdef CONFIG_COMPAT
+ if (is_compat_task())
+ p-chunks[i].user_ptr =
+ compat_ptr((compat_uptr_t)
+ user_chunk.chunk_data);
+ else
+#endif
+ p-chunks[i].user_ptr = (void __user *) (unsigned long)
+ user_chunk.chunk_data;
- cdata = (uint32_t *)(unsigned long)user_chunk.chunk_data;
if (p-chunks[i].chunk_id != RADEON_CHUNK_ID_IB) {
size = p-chunks[i].length_dw * sizeof(uint32_t);
p-chunks[i].kdata = kmalloc(size, GFP_KERNEL);
diff --git a/drivers/gpu/drm/radeon/radeon_ioc32.c
b/drivers/gpu/drm/radeon/radeon_ioc32.c
index a1bf11d..3c4dfa2 100644
--- a/drivers/gpu/drm/radeon/radeon_ioc32.c
+++ b/drivers/gpu/drm/radeon/radeon_ioc32.c
@@ -156,7 +156,7 @@ static int compat_radeon_cp_stipple(struct file *file,
unsigned int cmd,
typedef struct drm_radeon_tex_image32 {
unsigned int x, y; /* Blit coordinates */
unsigned int width, height;
- u32 data;
+ compat_uptr_t data;
} drm_radeon_tex_image32_t;
typedef struct drm_radeon_texture32 {
@@ -165,7 +165,7 @@ typedef struct drm_radeon_texture32 {
int format;
int width; /* Texture image coordinates */
int height;
- u32 image;
+ compat_uptr_t image;
} drm_radeon_texture32_t;
static int compat_radeon_cp_texture(struct file *file, unsigned int cmd,
@@ -180,8 +180,7 @@ static int compat_radeon_cp_texture(struct file *file,
unsigned int cmd,
return -EFAULT
Re: is avoiding compat ioctls possible?
From: Andi Kleen a...@firstfloor.org Date: Wed, 28 Oct 2009 08:59:08 +0100 } -chunk_array_ptr = (uint64_t *)(unsigned long)(cs-chunks); +#ifdef CONFIG_COMPAT +if (is_compat_task()) Are the COMPAT ifdefs really needed? The compiler should optimize that away anyways on non compat aware architectures, shouldn't it? There are no non-compat is_compat_task() definitions, nor are there non-compat build definitions of compat_uptr_t and the assosciated interfaces. -- 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: is avoiding compat ioctls possible?
From: Andi Kleen a...@firstfloor.org Date: Wed, 28 Oct 2009 09:19:09 +0100 On Wed, Oct 28, 2009 at 01:11:41AM -0700, David Miller wrote: From: Andi Kleen a...@firstfloor.org Date: Wed, 28 Oct 2009 08:59:08 +0100 } - chunk_array_ptr = (uint64_t *)(unsigned long)(cs-chunks); +#ifdef CONFIG_COMPAT + if (is_compat_task()) Are the COMPAT ifdefs really needed? The compiler should optimize that away anyways on non compat aware architectures, shouldn't it? There are no non-compat is_compat_task() definitions, nor are there non-compat build definitions of compat_uptr_t and the assosciated interfaces. That seems wrong then, better fix that too? It would be certainly better than adding a lot of ifdefs. That's usually done by seperating the compat code into a seperate file and obj-$(CONFIG_COMPAT) += foo.o in the Makefile. That's not really possible here. Sure, longer term we can provide those kinds of definitions to avoid the ifdefs, but that's not what my change is about. :-) -- 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: is avoiding compat ioctls possible?
From: Arnd Bergmann arndbergm...@googlemail.com Date: Wed, 28 Oct 2009 13:13:32 +0100 IMHO a better way to handle the radeon specific ioctls would be to avoid the compat_alloc_user_space and just define the common function taking a kernel pointer, with two implementations of the copy operation: Agreed, that would be a great follow-on patch to mine. -- 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: is avoiding compat ioctls possible?
From: Arnd Bergmann arndbergm...@googlemail.com Date: Wed, 28 Oct 2009 13:13:32 +0100 The ioctl argument actually needs a compat_ptr() conversion as well. For the s390 case, we can't do that in common code, because some ioctl methods put a 32 bit integer into the argument. Not sure if we want to fix that everywhere, the problem is very common and the impact is minimal. What does s390 do with the 'arg' argument to sys_ioctl()? That assumption that you can cast this to a pointer is everywhere. If someone wants to fix this up, feel free to do an audit and go over that seperately from my work :-) -- 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: is avoiding compat ioctls possible?
From: Arnd Bergmann arndbergm...@googlemail.com Date: Wed, 28 Oct 2009 16:40:18 +0100 I'm pretty sure it was ok when we started adding the compat_ioctl handlers years ago. I think most people just ignored these for the majority of drivers that can't possibly run on s390. Even on s390, gcc will always do the right thing if you call call ioctl with a pointer to a normal object in the .data section, heap or stack, but hand-written assembly or other compilers may not. Arnd, even compat_sys_ioctl() itself has constructs like: case FS_IOC_RESVSP: case FS_IOC_RESVSP64: error = ioctl_preallocate(filp, (void __user *)arg); goto out_fput; That's why I asked about the 'arg' argument to sys_ioctl on s390 :-) -- 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: is avoiding compat ioctls possible?
From: Dave Airlie airl...@gmail.com Date: Wed, 28 Oct 2009 11:22:18 +1000 Is there really no way to avoid compat ioctls? was I delusional in thinking there was? If you use pointers in your interfaces in any way, no. And for this drm_radeon_info thing the pointer is pointless, you're just returning 32-bit values to the user, just use a u32 inside of the drm_radeon_info structure for the kernel to place the result in. -- 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: is avoiding compat ioctls possible?
From: Andi Kleen a...@firstfloor.org Date: Wed, 28 Oct 2009 03:53:17 +0100 Dave Airlie airl...@gmail.com writes: Now I thought cool I don't need to worry about compat ioctl hackery I can run 32 on 64 bit apps fine and it'll all just work. Now Dave Miller points out that I'm obivously deluded and we really need to add compat ioctls so that the kernel can truncate correctly 32-bit address in case userspace shoves garbage into the top 32bits of the u64. When the user space sees a u64 field it should never shove garbage here. The problem is that it can if it wants to. On sparc64, in order to make debugging easier, we trap any time the kernel does a userspace access to a compat task and any of the upper 32-bits are non-zero. That's more than a reasonable assumption to make because user pointers are either: 1) Zero chopped when passed in via register arguments to a syscall. 2) Go through the compat_uptr() interface which chops the upper bits. So whether userland should or should not do something, we still have to guard against it. You just have to cast on 32bit for this, which is a bit ugly. Right, via the compat_*() interfaces. However some architectures need special operations on compat pointers (s390 iirc), but if you don't support those it might be reasonable to not support that. s390 has to sign extend all 32-bit compat process pointers when processing them in the 64-bit s390 kernel. I think one other architecture has this kind of situation too. -- 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: is avoiding compat ioctls possible?
From: Dave Airlie airl...@gmail.com Date: Wed, 28 Oct 2009 13:05:08 +1000 DrNick on irc suggested just doing: if (is_compat_task()) ptr = 0x; Is there a one liner I can just do in the actual ioctls instead of adding 20 compat ones? Just do the right thing and pass all userland compat pointers through the correct compat_*() macros. -- 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: is avoiding compat ioctls possible?
From: Dave Airlie airl...@gmail.com Date: Wed, 28 Oct 2009 13:28:10 +1000 On Wed, Oct 28, 2009 at 1:19 PM, Andi Kleen a...@firstfloor.org wrote: On Wed, Oct 28, 2009 at 01:05:08PM +1000, Dave Airlie wrote: We've designed that into a/c also, we pad all 64-bit values to 64-bit alignment on all the ioctls we've added to the drm in the past couple of years. Just because of this particular insanity. That's actually not needed, just use compat_*64. Assume no mistakes are made, new ioctls designed from scratch That seems like a bad assumption. It sounds like you already made some. You mean its impossible to design a 32/64-bit safe ioctl no matter what? If you use pointers at all, yes. We've said this several times. and we should live with having compat ioctls? This isn't something that was very clearly stated or documented, the advice we had previously was that compat ioctls were only required for old ioctls or ioctls with design problems. compat_*64 didn't exist when this code we designed, and we worked around that, but it was in no way mistaken, manually aligning 64-bit values is a perfectly good solution, not sure why you imply it isn't. Manually aligning the way you have solves only one side of the compat problem on x86 with 64-bit types. It may handle the layout properly bit it doesn't change the alignment requirements of the containing structure and that's a similarly important the issue. If you want to solve both aspects, use the aligned_u64 type. But once you introduce pointers, you must have compat layer code, and this is a hard requirement. And there is nothing baroque or wrong about it. -- 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: is avoiding compat ioctls possible?
From: Andi Kleen a...@firstfloor.org Date: Wed, 28 Oct 2009 04:34:55 +0100 On Wed, Oct 28, 2009 at 01:28:10PM +1000, Dave Airlie wrote: Well this was what I was trying to gather, so maybe I just need to write something up to state that compat_ioctl is always required for new ioctls that pass pointers or 64-bit values hiding pointers, so more people don't make this mistake going forward. I can say when we inquired about this 2 or so years ago when designing kms I didn't get this answer, which is a pity. Right now you could probably ignore it (if you document it), since there are no non s390 architectures with this problem, just prepare mentally that you might need to revisit this at some point. You can't ignore it on sparc64, it already OOPS's, and I refuse to live with that if (is_compat_task()) masking hack, no way. We designed portable interfaces for doing this stuff, please use it. -- 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: is avoiding compat ioctls possible?
From: Dave Airlie airl...@linux.ie Date: Wed, 28 Oct 2009 03:43:07 + (GMT) we already opencoded this (probably before it was macroisied or we just pasted it), so the radeon one is buggy, I should just go and compat_* all of these then and we should be all happy? It should be, it's only working because: 1) A malicious userland hasn't put garbage in the upper bits for you yet. 2) Nobody has tested s390 yet :-) Let's just not design non-portability into the code when we have no strong reason to, ok? :-) -- 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: is avoiding compat ioctls possible?
From: Dave Airlie airl...@linux.ie
Date: Wed, 28 Oct 2009 03:54:34 + (GMT)
we already opencoded this (probably before it was macroisied or we just
pasted it), so the radeon one is buggy, I should just go and compat_* all
of these then and we should be all happy?
It should be, it's only working because:
1) A malicious userland hasn't put garbage in the upper bits for
you yet.
2) Nobody has tested s390 yet :-)
So will an inline like this work?
static inline void *__user convert_user_ptr(uint64_t ioctl_ptr)
{
Please don't do this.
This is exactly what I feared people would do when is_compat_task()
was added. is_compat_task() is for situations where there is
otherwise no other way to handle the compat situation properly.
It's not that much work for you to hook up the compat ioctls properly,
and if you are clever you can do it in such a way that you'll get
warnings if someone accidently adds a new ioctl but forgets the
compat bits :-)
--
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: is avoiding compat ioctls possible?
From: Andi Kleen a...@firstfloor.org Date: Wed, 28 Oct 2009 05:36:11 +0100 On Tue, Oct 27, 2009 at 08:37:09PM -0700, David Miller wrote: On sparc64, in order to make debugging easier, we trap any time the kernel does a userspace access to a compat task and any of the upper 32-bits are non-zero. Interesting. That definitely means Dave needs a special path. I wouldn't call it special, the rule is that any userland pointer has to either go through a syscall argument register or one of the compat_*() accessor routines :-) -- 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
[PATCH] Improve CRTDDC mapping by using VBT info
Hello
Changelog:
Use VBT information to determine which DDC bus to use for CRTDCC.
Fall back to GPIOA if VBT info is not available.
Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org
Signed-off-by: David Müller d.muel...@elsoft.ch
diff -dpurN linux-2.6.31-rc8.orig/drivers/gpu/drm/i915/i915_drv.h
linux-2.6.31-rc8.patched/drivers/gpu/drm/i915/i915_drv.h
--- linux-2.6.31-rc8.orig/drivers/gpu/drm/i915/i915_drv.h 2009-08-28
02:59:04.0 +0200
+++ linux-2.6.31-rc8.patched/drivers/gpu/drm/i915/i915_drv.h2009-08-28
09:06:56.0 +0200
@@ -222,6 +222,7 @@ typedef struct drm_i915_private {
unsigned int edp_support:1;
int lvds_ssc_freq;
+ int crt_ddc_bus; /* -1 = unknown, else GPIO to use for CRT DDC */
struct drm_i915_fence_reg fence_regs[16]; /* assume 965 */
int fence_reg_start; /* 4 if userland hasn't ioctl'd us yet */
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
diff -dpurN linux-2.6.31-rc8.orig/drivers/gpu/drm/i915/intel_bios.c
linux-2.6.31-rc8.patched/drivers/gpu/drm/i915/intel_bios.c
--- linux-2.6.31-rc8.orig/drivers/gpu/drm/i915/intel_bios.c 2009-08-28
02:59:04.0 +0200
+++ linux-2.6.31-rc8.patched/drivers/gpu/drm/i915/intel_bios.c 2009-08-28
09:07:54.0 +0200
@@ -59,6 +59,16 @@ find_section(struct bdb_header *bdb, int
return NULL;
}
+static u16
+get_blocksize(void *p)
+{
+ u16 *block_ptr, block_size;
+
+ block_ptr = (u16 *)((char *)p - 2);
+ block_size = *block_ptr;
+ return block_size;
+}
+
static void
fill_detail_timing_data(struct drm_display_mode *panel_fixed_mode,
struct lvds_dvo_timing *dvo_timing)
@@ -215,6 +225,41 @@ parse_general_features(struct drm_i915_p
}
static void
+parse_general_definitions(struct drm_i915_private *dev_priv,
+ struct bdb_header *bdb)
+{
+ struct bdb_general_definitions *general;
+ const int crt_bus_map_table[] = {
+ GPIOB,
+ GPIOA,
+ GPIOC,
+ GPIOD,
+ GPIOE,
+ GPIOF,
+ };
+
+ /* Set sensible defaults in case we can't find the general block
+ or it is the wrong chipset */
+ dev_priv-crt_ddc_bus = -1;
+
+ general = find_section(bdb, BDB_GENERAL_DEFINITIONS);
+ if (general) {
+ u16 block_size = get_blocksize(general);
+ if (block_size = sizeof(*general)) {
+ int bus_pin = general-crt_ddc_gmbus_pin;
+ DRM_DEBUG(crt_ddc_bus_pin: %d\n, bus_pin);
+ if ((bus_pin = 1) (bus_pin = 6)) {
+ dev_priv-crt_ddc_bus =
+ crt_bus_map_table[bus_pin-1];
+ }
+ } else {
+ DRM_DEBUG(BDB_GD too small (%d). Invalid.\n,
+ block_size);
+ }
+ }
+}
+
+static void
parse_sdvo_device_mapping(struct drm_i915_private *dev_priv,
struct bdb_header *bdb)
{
@@ -222,7 +267,7 @@ parse_sdvo_device_mapping(struct drm_i91
struct bdb_general_definitions *p_defs;
struct child_device_config *p_child;
int i, child_device_num, count;
- u16 block_size, *block_ptr;
+ u16 block_size;
p_defs = find_section(bdb, BDB_GENERAL_DEFINITIONS);
if (!p_defs) {
@@ -240,8 +285,7 @@ parse_sdvo_device_mapping(struct drm_i91
return;
}
/* get the block size of general definitions */
- block_ptr = (u16 *)((char *)p_defs - 2);
- block_size = *block_ptr;
+ block_size = get_blocksize(p_defs);
/* get the number of child device */
child_device_num = (block_size - sizeof(*p_defs)) /
sizeof(*p_child);
@@ -362,6 +406,7 @@ intel_init_bios(struct drm_device *dev)
/* Grab useful general definitions */
parse_general_features(dev_priv, bdb);
+ parse_general_definitions(dev_priv, bdb);
parse_lfp_panel_data(dev_priv, bdb);
parse_sdvo_panel_data(dev_priv, bdb);
parse_sdvo_device_mapping(dev_priv, bdb);
diff -dpurN linux-2.6.31-rc8.orig/drivers/gpu/drm/i915/intel_crt.c
linux-2.6.31-rc8.patched/drivers/gpu/drm/i915/intel_crt.c
--- linux-2.6.31-rc8.orig/drivers/gpu/drm/i915/intel_crt.c 2009-08-28
02:59:04.0 +0200
+++ linux-2.6.31-rc8.patched/drivers/gpu/drm/i915/intel_crt.c 2009-08-28
09:06:56.0 +0200
@@ -508,6 +508,7 @@ void intel_crt_init(struct drm_device *d
{
struct drm_connector *connector;
struct intel_output *intel_output;
+ struct drm_i915_private *dev_priv = dev-dev_private;
u32 i2c_reg;
intel_output = kzalloc(sizeof(struct intel_output), GFP_KERNEL);
@@ -527,8 +528,12 @@ void intel_crt_init(struct drm_device *d
/* Set up the DDC bus. */
if (IS_IGDNG
Re: [Kernel 2.6.30] Only GPIOA is used as CRTDDC bus
Jesse Barnes wrote:
Wanna respin it with that change (just remove the IS_85X change and add
a return below the crtc_ddc_bus = -1 if the structure size doesn't match
the block size).
I'm not sure if i fully understood what you are trying to tell me but
have you imagined something like this?
Signed-off-by: David Müller d.muel...@elsoft.ch
diff -dpurN linux-2.6.31-rc8.orig/drivers/gpu/drm/i915/i915_drv.h
linux-2.6.31-rc8.patched/drivers/gpu/drm/i915/i915_drv.h
--- linux-2.6.31-rc8.orig/drivers/gpu/drm/i915/i915_drv.h 2009-08-28
02:59:04.0 +0200
+++ linux-2.6.31-rc8.patched/drivers/gpu/drm/i915/i915_drv.h2009-08-28
09:06:56.0 +0200
@@ -222,6 +222,7 @@ typedef struct drm_i915_private {
unsigned int edp_support:1;
int lvds_ssc_freq;
+ int crt_ddc_bus; /* -1 = unknown, else GPIO to use for CRT DDC */
struct drm_i915_fence_reg fence_regs[16]; /* assume 965 */
int fence_reg_start; /* 4 if userland hasn't ioctl'd us yet */
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
diff -dpurN linux-2.6.31-rc8.orig/drivers/gpu/drm/i915/intel_bios.c
linux-2.6.31-rc8.patched/drivers/gpu/drm/i915/intel_bios.c
--- linux-2.6.31-rc8.orig/drivers/gpu/drm/i915/intel_bios.c 2009-08-28
02:59:04.0 +0200
+++ linux-2.6.31-rc8.patched/drivers/gpu/drm/i915/intel_bios.c 2009-08-28
09:07:54.0 +0200
@@ -59,6 +59,16 @@ find_section(struct bdb_header *bdb, int
return NULL;
}
+static u16
+get_blocksize(void *p)
+{
+ u16 *block_ptr, block_size;
+
+ block_ptr = (u16 *)((char *)p - 2);
+ block_size = *block_ptr;
+ return block_size;
+}
+
static void
fill_detail_timing_data(struct drm_display_mode *panel_fixed_mode,
struct lvds_dvo_timing *dvo_timing)
@@ -215,6 +225,41 @@ parse_general_features(struct drm_i915_p
}
static void
+parse_general_definitions(struct drm_i915_private *dev_priv,
+ struct bdb_header *bdb)
+{
+ struct bdb_general_definitions *general;
+ const int crt_bus_map_table[] = {
+ GPIOB,
+ GPIOA,
+ GPIOC,
+ GPIOD,
+ GPIOE,
+ GPIOF,
+ };
+
+ /* Set sensible defaults in case we can't find the general block
+ or it is the wrong chipset */
+ dev_priv-crt_ddc_bus = -1;
+
+ general = find_section(bdb, BDB_GENERAL_DEFINITIONS);
+ if (general) {
+ u16 block_size = get_blocksize(general);
+ if (block_size = sizeof(*general)) {
+ int bus_pin = general-crt_ddc_gmbus_pin;
+ DRM_DEBUG(crt_ddc_bus_pin: %d\n, bus_pin);
+ if ((bus_pin = 1) (bus_pin = 6)) {
+ dev_priv-crt_ddc_bus =
+ crt_bus_map_table[bus_pin-1];
+ }
+ } else {
+ DRM_DEBUG(BDB_GD too small (%d). Invalid.\n,
+ block_size);
+ }
+ }
+}
+
+static void
parse_sdvo_device_mapping(struct drm_i915_private *dev_priv,
struct bdb_header *bdb)
{
@@ -222,7 +267,7 @@ parse_sdvo_device_mapping(struct drm_i91
struct bdb_general_definitions *p_defs;
struct child_device_config *p_child;
int i, child_device_num, count;
- u16 block_size, *block_ptr;
+ u16 block_size;
p_defs = find_section(bdb, BDB_GENERAL_DEFINITIONS);
if (!p_defs) {
@@ -240,8 +285,7 @@ parse_sdvo_device_mapping(struct drm_i91
return;
}
/* get the block size of general definitions */
- block_ptr = (u16 *)((char *)p_defs - 2);
- block_size = *block_ptr;
+ block_size = get_blocksize(p_defs);
/* get the number of child device */
child_device_num = (block_size - sizeof(*p_defs)) /
sizeof(*p_child);
@@ -362,6 +406,7 @@ intel_init_bios(struct drm_device *dev)
/* Grab useful general definitions */
parse_general_features(dev_priv, bdb);
+ parse_general_definitions(dev_priv, bdb);
parse_lfp_panel_data(dev_priv, bdb);
parse_sdvo_panel_data(dev_priv, bdb);
parse_sdvo_device_mapping(dev_priv, bdb);
diff -dpurN linux-2.6.31-rc8.orig/drivers/gpu/drm/i915/intel_crt.c
linux-2.6.31-rc8.patched/drivers/gpu/drm/i915/intel_crt.c
--- linux-2.6.31-rc8.orig/drivers/gpu/drm/i915/intel_crt.c 2009-08-28
02:59:04.0 +0200
+++ linux-2.6.31-rc8.patched/drivers/gpu/drm/i915/intel_crt.c 2009-08-28
09:06:56.0 +0200
@@ -508,6 +508,7 @@ void intel_crt_init(struct drm_device *d
{
struct drm_connector *connector;
struct intel_output *intel_output;
+ struct drm_i915_private *dev_priv = dev-dev_private;
u32 i2c_reg;
intel_output = kzalloc(sizeof(struct intel_output), GFP_KERNEL
Ping Re: [Kernel 2.6.30] Only GPIOA is used as CRTDDC bus
Hello Any news regarding this issue? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Kernel 2.6.30] Only GPIOA is used as CRTDDC bus
Hello
What about a patch like the attached one; would this be acceptable?
Signed-off-by: David Müller d.muel...@elsoft.ch
diff -dpruN linux-2.6.31-rc2.orig/drivers/gpu/drm/i915/i915_drv.h
linux-2.6.31-rc2.patched/drivers/gpu/drm/i915/i915_drv.h
--- linux-2.6.31-rc2.orig/drivers/gpu/drm/i915/i915_drv.h 2009-07-04
19:58:48.0 +0200
+++ linux-2.6.31-rc2.patched/drivers/gpu/drm/i915/i915_drv.h2009-07-13
12:47:52.0 +0200
@@ -205,6 +205,7 @@ typedef struct drm_i915_private {
unsigned int lvds_use_ssc:1;
int lvds_ssc_freq;
+ int crt_ddc_bus; /* -1 = unknown, else GPIO to use for CRT DDC */
struct drm_i915_fence_reg fence_regs[16]; /* assume 965 */
int fence_reg_start; /* 4 if userland hasn't ioctl'd us yet */
int num_fence_regs; /* 8 on pre-965, 16 otherwise */
diff -dpruN linux-2.6.31-rc2.orig/drivers/gpu/drm/i915/intel_bios.c
linux-2.6.31-rc2.patched/drivers/gpu/drm/i915/intel_bios.c
--- linux-2.6.31-rc2.orig/drivers/gpu/drm/i915/intel_bios.c 2009-07-04
19:58:48.0 +0200
+++ linux-2.6.31-rc2.patched/drivers/gpu/drm/i915/intel_bios.c 2009-07-13
12:49:22.0 +0200
@@ -204,6 +204,38 @@ parse_general_features(struct drm_i915_p
}
static void
+parse_general_definitions(struct drm_i915_private *dev_priv,
+ struct bdb_header *bdb)
+{
+ struct bdb_general_definitions *general;
+ const int crt_bus_map_table[] = {
+ GPIOB,
+ GPIOA,
+ GPIOC,
+ GPIOD,
+ GPIOE,
+ GPIOF,
+ };
+
+ /* Set sensible defaults in case we can't find the general block
+ or it is the wrong chipset */
+ dev_priv-crt_ddc_bus = -1;
+
+ /* FIXME maybe add additional chipsets */
+ if (IS_I85X(dev_priv-dev)) {
+ general = find_section(bdb, BDB_GENERAL_DEFINITIONS);
+ if (general) {
+ int bus_pin = general-crt_ddc_gmbus_pin;
+ DRM_DEBUG(crt_ddc_bus_pin: %d\n, bus_pin);
+ if ((bus_pin = 1) (bus_pin = 6)) {
+ dev_priv-crt_ddc_bus =
+ crt_bus_map_table[bus_pin-1];
+ }
+ }
+ }
+}
+
+static void
parse_sdvo_device_mapping(struct drm_i915_private *dev_priv,
struct bdb_header *bdb)
{
@@ -332,6 +364,7 @@ intel_init_bios(struct drm_device *dev)
/* Grab useful general definitions */
parse_general_features(dev_priv, bdb);
+ parse_general_definitions(dev_priv, bdb);
parse_lfp_panel_data(dev_priv, bdb);
parse_sdvo_panel_data(dev_priv, bdb);
parse_sdvo_device_mapping(dev_priv, bdb);
diff -dpruN linux-2.6.31-rc2.orig/drivers/gpu/drm/i915/intel_crt.c
linux-2.6.31-rc2.patched/drivers/gpu/drm/i915/intel_crt.c
--- linux-2.6.31-rc2.orig/drivers/gpu/drm/i915/intel_crt.c 2009-07-04
19:58:48.0 +0200
+++ linux-2.6.31-rc2.patched/drivers/gpu/drm/i915/intel_crt.c 2009-07-13
11:48:22.0 +0200
@@ -478,6 +478,7 @@ void intel_crt_init(struct drm_device *d
{
struct drm_connector *connector;
struct intel_output *intel_output;
+ struct drm_i915_private *dev_priv = dev-dev_private;
u32 i2c_reg;
intel_output = kzalloc(sizeof(struct intel_output), GFP_KERNEL);
@@ -497,8 +498,12 @@ void intel_crt_init(struct drm_device *d
/* Set up the DDC bus. */
if (IS_IGDNG(dev))
i2c_reg = PCH_GPIOA;
- else
+ else {
i2c_reg = GPIOA;
+ /* Use VBT information for CRT DDC if available */
+ if (dev_priv-crt_ddc_bus != -1)
+ i2c_reg = dev_priv-crt_ddc_bus;
+ }
intel_output-ddc_bus = intel_i2c_create(dev, i2c_reg, CRTDDC_A);
if (!intel_output-ddc_bus) {
dev_printk(KERN_ERR, dev-pdev-dev, DDC bus registration
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [i855GME] [Kernel 2.6.30] intel_crt_load_detect() not working?
Eric Anholt wrote: There have been bugfixes in load detect since .30, could you try master and see if it's fixed? Yes, you are right. Problem seems to me fixed in 2.6.31-rc1. Thanks for the hint -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Kernel 2.6.30] Only GPIOA is used as CRTDDC bus
Ma, Ling wrote: We have one DG45ID board connected VGA by DVI-I port, however bmp_CRT_DDC_Pins from vbt is always 0x02 which means GPIOA, so we can not depend on the value, and have to try GPIOD or GPIOE. It only impact G4X series platform. So if i understand you correctly, the crt_ddc_gmbus_pin field in the VBT is not reliable and can not be used. But this is only a problem on G4X platforms. What about 855GM or 945GME platforms? Can the crt_ddc_gmbus_pin field use on these platforms? -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Kernel 2.6.30] Only GPIOA is used as CRTDDC bus
Ma, Ling wrote: What about 855GM or 945GME platforms? Can the crt_ddc_gmbus_pin field use on these platforms? On those platforms they always use GPIOA, at least we don't find similar bugs. If you have some related bugs, could you please tell us? There are (at least) two boards on this planet which have connected GPIOD as DDC channel to their DVI-I connectors. Is there an (official) requirement that GPIOA has to be used as DDC channel in conjunction with DVI? -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[i855GME] [Kernel 2.6.30] intel_crt_load_detect() not working?
Hello While testing Linux kernel 2.6.30 on a Intel 855GME platform i noticed a 3 minute delay during the Linux boot process in the case DDC support is not available. I've tracked the problem down to the following lines in driver/gpu/drm/i915/intel_crt.c: 289 /* 290 * Wait for the border to be displayed 291 */ 292 while (I915_READ(pipe_dsl_reg) = vactive) 293 ; 294 while ((dsl = I915_READ(pipe_dsl_reg)) = vsample) 295 ; The HW register pointed to by pipe_dsl_reg returns a constant value, resulting in an endless loop at line 294. For me this looks like some parts of the graphic engine is not correctly set up yet, especially as the corresponding code in the Xorg Intel graphics driver mentions that the current pipe's DPLL has to be active for this code to work. Or is this code designed to work in a graphic mode only, but not VGA text mode? -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Segfault with glMapBuffer (intel)
Hello,
I'm using xorg-edgers' packages on Ubuntu Jaunty, so I have equivalent
of mesa 7.5 from git (intel 945GM), up to date.
Recently (but unfortunately I can't tell exactly when), some of my own
OpenGL programs using VBOs and glMapBuffer broke. I'm not sure if it's a
bug of the intel DRI driver or a misuse of glMapBuffer, so I first ask
on the list before possibly filling a bug report.
I'm attaching a little OpenGL program showing the problem. It displays a
rotating cube. When using glMapBuffer/memcpy/glUnmapBuffer, it works for
the first frame and crashes for the next one. If I use glBufferData it
works fine.
Is it expected, or is it a bug?
Note that it works with LIBGL_ALWAYS_SOFTWARE=1. It worked before too
(Mesa 7.4). It crashes with linux 2.6.30 as well as 2.6.28, both KMS and
UMS tested.
Yours,
David HENRY.
/*
* gcc -Wall -ansi -lGL -lGLU -lGLEW -lglut vbo.c -o vbo
*/
#include GL/glew.h
#include GL/glut.h
#include stdio.h
#include stdlib.h
#include string.h
struct VN_t
{
GLfloat v[3]; /* position */
GLfloat n[3]; /* normal */
};
static struct VN_t cube[24] = {
{ { 0.0, 0.0, 0.0 }, { 0.0, 0.0, -1.0 } },
{ { 0.0, 1.0, 0.0 }, { 0.0, 0.0, -1.0 } },
{ { 1.0, 1.0, 0.0 }, { 0.0, 0.0, -1.0 } },
{ { 1.0, 0.0, 0.0 }, { 0.0, 0.0, -1.0 } },
{ { 0.0, 0.0, 1.0 }, { 0.0, 0.0, 1.0 } },
{ { 1.0, 0.0, 1.0 }, { 0.0, 0.0, 1.0 } },
{ { 1.0, 1.0, 1.0 }, { 0.0, 0.0, 1.0 } },
{ { 0.0, 1.0, 1.0 }, { 0.0, 0.0, 1.0 } },
{ { 1.0, 0.0, 1.0 }, { 1.0, 0.0, 0.0 } },
{ { 1.0, 0.0, 0.0 }, { 1.0, 0.0, 0.0 } },
{ { 1.0, 1.0, 0.0 }, { 1.0, 0.0, 0.0 } },
{ { 1.0, 1.0, 1.0 }, { 1.0, 0.0, 0.0 } },
{ { 0.0, 0.0, 1.0 }, { -1.0, 0.0, 0.0 } },
{ { 0.0, 1.0, 1.0 }, { -1.0, 0.0, 0.0 } },
{ { 0.0, 1.0, 0.0 }, { -1.0, 0.0, 0.0 } },
{ { 0.0, 0.0, 0.0 }, { -1.0, 0.0, 0.0 } },
{ { 0.0, 1.0, 1.0 }, { 0.0, 1.0, 0.0 } },
{ { 1.0, 1.0, 1.0 }, { 0.0, 1.0, 0.0 } },
{ { 1.0, 1.0, 0.0 }, { 0.0, 1.0, 0.0 } },
{ { 0.0, 1.0, 0.0 }, { 0.0, 1.0, 0.0 } },
{ { 0.0, 0.0, 1.0 }, { 0.0, -1.0, 0.0 } },
{ { 0.0, 0.0, 0.0 }, { 0.0, -1.0, 0.0 } },
{ { 1.0, 0.0, 0.0 }, { 0.0, -1.0, 0.0 } },
{ { 1.0, 0.0, 1.0 }, { 0.0, -1.0, 0.0 } },
};
static GLushort indices[24] = {
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12,
13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23
};
GLuint vboId = 0;
GLuint iboId = 0;
static void
init ()
{
GLenum err = glewInit ();
if (GLEW_OK != err)
{
/* Problem: glewInit failed, something is seriously wrong. */
fprintf (stderr, Error: %s\n, glewGetErrorString (err));
exit (EXIT_FAILURE);
}
if (!GLEW_ARB_vertex_buffer_object)
{
fprintf (stderr, Error: missing ARB_vertex_buffer_object extension\n);
exit (EXIT_FAILURE);
}
/* OpenGL initialization */
glClearColor (0.1f, 0.1f, 0.1f, 0.0f);
glShadeModel (GL_SMOOTH);
glEnable (GL_CULL_FACE);
glEnable (GL_DEPTH_TEST);
glEnable (GL_LIGHTING);
glEnable (GL_LIGHT0);
/* VBO setup */
glGenBuffersARB (1, vboId);
glGenBuffersARB (1, iboId);
glBindBufferARB (GL_ELEMENT_ARRAY_BUFFER, iboId);
glBufferDataARB (GL_ELEMENT_ARRAY_BUFFER, 24 * sizeof (GLushort), indices, GL_STATIC_DRAW);
glBindBufferARB (GL_ARRAY_BUFFER, vboId);
glBufferDataARB (GL_ARRAY_BUFFER, 24 * sizeof (struct VN_t), NULL, GL_STREAM_DRAW_ARB);
glBindBufferARB (GL_ELEMENT_ARRAY_BUFFER, 0);
glBindBufferARB (GL_ARRAY_BUFFER, 0);
}
static void
reshape (int w, int h)
{
if (h == 0)
h = 1;
glViewport (0, 0, (GLsizei)w, (GLsizei)h);
glMatrixMode (GL_PROJECTION);
glLoadIdentity ();
gluPerspective (45.0, (GLfloat)w/(GLfloat)h, 0.1, 1000.0);
glMatrixMode (GL_MODELVIEW);
glLoadIdentity ();
glutPostRedisplay ();
}
static void
display ()
{
GLenum err;
struct VN_t *v;
static float angle = 25.0;
static int frame = 1;
glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
/* Camera setup */
glLoadIdentity ();
glTranslated (0.0f, 0.0f, -3.0f);
glRotated (35.0f, 1.0f, 0.0f, 0.0f);
glRotated (angle, 0.0f, 1.0f, 0.0f);
glTranslatef (-0.5f, -0.5f, -0.5f);
angle += 0.2;
glBindBufferARB (GL_ELEMENT_ARRAY_BUFFER, iboId);
glBindBufferARB (GL_ARRAY_BUFFER, vboId);
if (0)
{
/*glBufferSubDataARB (GL_ARRAY_BUFFER, 0, 24 * sizeof (struct vertex), cube);*/
glBufferDataARB (GL_ARRAY_BUFFER, 24 * sizeof (struct VN_t), cube, GL_STREAM_DRAW_ARB);
}
else
{
/*glBufferDataARB (GL_ARRAY_BUFFER, 24 * sizeof (struct vertex), NULL, GL_STREAM_DRAW_ARB);*/
v = (struct VN_t *)glMapBufferARB (GL_ARRAY_BUFFER_ARB, GL_WRITE_ONLY_ARB);
memcpy (v, cube, sizeof (cube));
glUnmapBufferARB (GL_ARRAY_BUFFER_ARB);
}
glEnableClientState (GL_VERTEX_ARRAY);
glEnableClientState (GL_NORMAL_ARRAY);
glNormalPointer (GL_FLOAT, sizeof (struct VN_t), (char *)(sizeof (GLfloat) * 3));
glVertexPointer (3, GL_FLOAT, sizeof (struct VN_t), 0);
glDrawElements (GL_QUADS, 24, GL_UNSIGNED_SHORT, 0);
glBindBufferARB (GL_ELEMENT_ARRAY_BUFFER, 0
Re: [PATCH] drm: Only use DRM_IOCTL_UPDATE_DRAW compat wrapper for compat X86.
From: Arnd Bergmann a...@arndb.de Date: Thu, 19 Feb 2009 15:19:01 +0100 On Wednesday 18 February 2009, David Miller wrote: drm: Only use DRM_IOCTL_UPDATE_DRAW compat wrapper for compat X86. Only X86 32-bit uses a different alignment for unsigned long long than it's 64-bit counterpart. Therefore this compat translation is only correct, and only needed, when either CONFIG_X86 or CONFIG_IA64. Signed-off-by: David S. Miller da...@davemloft.net The patch is correct AFAICT, but I'd like to point out that the problem could have been avoided (besides using a non-padded layout) by using a compat_u64 member in the struct definition instead of the packed attribute: Indeed, David A. showed me compat_u64 et al. and I'm fine with it being fixed that way too. Feel free to submit a patch :) -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Preserve SHMLBA bits in hash key for _DRM_SHM mappings.
From: Andrew Morton a...@linux-foundation.org Date: Thu, 19 Feb 2009 15:27:26 -0800 eg: arch/xtensa/include/asm/shmparam.h #define SHMLBA ((PAGE_SIZE DCACHE_WAY_SIZE)? PAGE_SIZE : DCACHE_WAY_SIZE) But including linux/shm.h here seems a bit silly. We'll see.. If DRM even builds on XTENSA, let alone is usable there, I'll buy you a lollipop. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
drm: radeon: Fix unaligned access in r300_scratch().
drm: radeon: Fix unaligned access in r300_scratch().
In compat mode, the cmdbuf-buf 64-bit address cookie can
potentially be only 32-bit aligned. Dereferencing this as
64-bit causes expensive unaligned traps on platforms like
sparc64.
Use get_unaligned() to fix.
Signed-off-by: David S. Miller da...@davemloft.net
---
drivers/gpu/drm/radeon/r300_cmdbuf.c |6 +-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300_cmdbuf.c
b/drivers/gpu/drm/radeon/r300_cmdbuf.c
index cace396..3efa633 100644
--- a/drivers/gpu/drm/radeon/r300_cmdbuf.c
+++ b/drivers/gpu/drm/radeon/r300_cmdbuf.c
@@ -37,6 +37,8 @@
#include radeon_drv.h
#include r300_reg.h
+#include asm/unaligned.h
+
#define R300_SIMULTANEOUS_CLIPRECTS4
/* Values for R300_RE_CLIPRECT_CNTL depending on the number of cliprects
@@ -917,6 +919,7 @@ static int r300_scratch(drm_radeon_private_t *dev_priv,
{
u32 *ref_age_base;
u32 i, buf_idx, h_pending;
+ u64 ptr_addr;
RING_LOCALS;
if (cmdbuf-bufsz
@@ -930,7 +933,8 @@ static int r300_scratch(drm_radeon_private_t *dev_priv,
dev_priv-scratch_ages[header.scratch.reg]++;
- ref_age_base = (u32 *)(unsigned long)*((uint64_t *)cmdbuf-buf);
+ ptr_addr = get_unaligned((u64 *)cmdbuf-buf);
+ ref_age_base = (u32 *)(unsigned long)ptr_addr;
cmdbuf-buf += sizeof(u64);
cmdbuf-bufsz -= sizeof(u64);
--
1.6.1.2.350.g88cc
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: Only use DRM_IOCTL_UPDATE_DRAW compat wrapper for compat X86.
Ben, I'm pretty sure you're hitting this too on powerpc. Every time a
32-bit process tries to upload cliprects it's going to fail with
-EFAULT or similar.
Nothing in userspace checks the return value for errors, etc. :-/
The only reason I caught this is because I have a debugging check on
sparc64 that makes sure that faults on kernel accesses to 32-bit
userspace never have any of the high 32-bits set.
drm: Only use DRM_IOCTL_UPDATE_DRAW compat wrapper for compat X86.
Only X86 32-bit uses a different alignment for unsigned long long
than it's 64-bit counterpart.
Therefore this compat translation is only correct, and only needed,
when either CONFIG_X86 or CONFIG_IA64.
Signed-off-by: David S. Miller da...@davemloft.net
---
drivers/gpu/drm/drm_ioc32.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index 920b72f..282d9fd 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -954,6 +954,7 @@ static int compat_drm_sg_free(struct file *file, unsigned
int cmd,
DRM_IOCTL_SG_FREE, (unsigned long)request);
}
+#if defined(CONFIG_X86) || defined(CONFIG_IA64)
typedef struct drm_update_draw32 {
drm_drawable_t handle;
unsigned int type;
@@ -984,6 +985,7 @@ static int compat_drm_update_draw(struct file *file,
unsigned int cmd,
DRM_IOCTL_UPDATE_DRAW, (unsigned long)request);
return err;
}
+#endif
struct drm_wait_vblank_request32 {
enum drm_vblank_seq_type type;
@@ -1066,7 +1068,9 @@ drm_ioctl_compat_t *drm_compat_ioctls[] = {
#endif
[DRM_IOCTL_NR(DRM_IOCTL_SG_ALLOC32)] = compat_drm_sg_alloc,
[DRM_IOCTL_NR(DRM_IOCTL_SG_FREE32)] = compat_drm_sg_free,
+#if defined(CONFIG_X86) || defined(CONFIG_IA64)
[DRM_IOCTL_NR(DRM_IOCTL_UPDATE_DRAW32)] = compat_drm_update_draw,
+#endif
[DRM_IOCTL_NR(DRM_IOCTL_WAIT_VBLANK32)] = compat_drm_wait_vblank,
};
--
1.6.1.2.350.g88cc
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Only use DRM_IOCTL_UPDATE_DRAW compat wrapper for compat X86.
From: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Thu, 19 Feb 2009 08:59:50 +1100 Could that be related to the kernel spewing a bunch of [drm:drm_update_drawable_info] *ERROR* Failed to copy cliprects from userspace Yep, that is exactly caused by this bug. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: Preserve SHMLBA bits in hash key for _DRM_SHM mappings.
Ok, this is the last DRM bug I am aware of with Radeon on sparc64.
What kills me is that I fixed this bug 6 or 7 years ago :)
drm: Preserve SHMLBA bits in hash key for _DRM_SHM mappings.
Platforms such as sparc64 have D-cache aliasing issues. We
cannot allow virtual mappings in different contexts to be such
that two cache lines can be loaded for the same backing data.
Updates to one cache line won't be seen by accesses to the other
cache line.
Code in sparc64 and other architectures solve this problem by
making sure that all userland mappings of MAP_SHARED objects have
the same virtual address base. They implement this by keying
off of the page offset, and using that to choose a suitably
consistent virtual address for mmap() requests.
Making things even worse, getting this wrong on sparc64 can result
in hangs during DRM lock acquisition. This is because, at least on
UltraSPARC-III, normal loads consult the D-cache but atomics such
as 'cas' (which is what cmpxchg() is implement using) only consult
the L2 cache. So if a D-cache alias is inserted, the load can
see different data than the atomic, and we'll loop forever because
the atomic compare-and-exchange will never complete successfully.
So to make this all work properly, we need to make sure that the
hash address computed by drm_map_handle() preserves the SHMLBA
relevant bits, and that's what this patch does for _DRM_SHM mappings.
As a historical note, many years ago this bug didn't exist because we
used to just use the low 32-bits of the address as the hash and just
hope for the best. This preserved the SHMLBA bits properly. But when
the hashtab code was added to DRM, this was no longer the case.
Signed-off-by: David S. Miller da...@davemloft.net
---
drivers/gpu/drm/drm_bufs.c | 35 +++
1 files changed, 31 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 069544c..445c762 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -34,6 +34,8 @@
*/
#include linux/vmalloc.h
+#include linux/log2.h
+#include asm/shmparam.h
#include drmP.h
resource_size_t drm_get_resource_start(struct drm_device *dev, unsigned int
resource)
@@ -83,9 +85,11 @@ static struct drm_map_list *drm_find_matching_map(struct
drm_device *dev,
}
static int drm_map_handle(struct drm_device *dev, struct drm_hash_item *hash,
- unsigned long user_token, int hashed_handle)
+ unsigned long user_token, int hashed_handle, int shm)
{
- int use_hashed_handle;
+ int use_hashed_handle, shift;
+ unsigned long add;
+
#if (BITS_PER_LONG == 64)
use_hashed_handle = ((user_token 0xUL) ||
hashed_handle);
#elif (BITS_PER_LONG == 32)
@@ -101,9 +105,31 @@ static int drm_map_handle(struct drm_device *dev, struct
drm_hash_item *hash,
if (ret != -EINVAL)
return ret;
}
+
+ shift = 0;
+ add = DRM_MAP_HASH_OFFSET PAGE_SHIFT;
+ if (shm (SHMLBA PAGE_SIZE)) {
+ int bits = ilog2(SHMLBA PAGE_SHIFT) + 1;
+
+ /* For shared memory, we have to preserve the SHMLBA
+* bits of the eventual vma-vm_pgoff value during
+* mmap(). Otherwise we run into cache aliasing problems
+* on some platforms. On these platforms, the pgoff of
+* a mmap() request is used to pick a suitable virtual
+* address for the mmap() region such that it will not
+* cause cache aliasing problems.
+*
+* Therefore, make sure the SHMLBA relevant bits of the
+* hash value we use are equal to those in the original
+* kernel virtual address.
+*/
+ shift = bits;
+ add |= ((user_token PAGE_SHIFT) ((1UL bits) - 1UL));
+ }
+
return drm_ht_just_insert_please(dev-map_hash, hash,
user_token, 32 - PAGE_SHIFT - 3,
-0, DRM_MAP_HASH_OFFSET PAGE_SHIFT);
+shift, add);
}
/**
@@ -323,7 +349,8 @@ static int drm_addmap_core(struct drm_device * dev,
resource_size_t offset,
/* We do it here so that dev-struct_mutex protects the increment */
user_token = (map-type == _DRM_SHM) ? (unsigned long)map-handle :
map-offset;
- ret = drm_map_handle(dev, list-hash, user_token, 0);
+ ret = drm_map_handle(dev, list-hash, user_token, 0,
+(map-type == _DRM_SHM));
if (ret) {
if (map-type == _DRM_REGISTERS)
iounmap(map-handle);
--
1.6.1.2.350.g88cc
--
Open Source Business Conference (OSBC), March 24-25, 2009
Re: [dri-devel] BROKEN drm: ati_pcigart: Fix limit check in drm_ati_pcigart_init().
From: Sedat Dilek sedat.di...@googlemail.com Date: Sun, 15 Feb 2009 10:28:29 +0100 unfortunately, your latest DRM patch [1] is broken while building against Linux-2.6.25-rc5. This is my patch-series: Did you read my patch postings? I said my work was relative to dri-next, as sparc64 also needs the changes David has commited there from Ben H. It therefore uses types only found in that branch. In David's dri-next branch, the proper type is struct drm_local_map, so if you're not patching against his dri-next branch you won't have Ben H's drm_addmap() changes which create and use that new type. You will notice that when David added my changes to his dri-fixes branch, he corrected up that single line which you could have very easily done as well. Just change struct drm_local_map to just plain struct drm_map. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/5]: drm: ati_pcigart: Do not access I/O MEM space using pointer derefs.
From: Dave Airlie airl...@gmail.com Date: Sat, 14 Feb 2009 17:42:02 +1000 On Sat, Feb 14, 2009 at 4:09 PM, David Miller da...@davemloft.net wrote: 1) Mis-sizes the GART table save buffer, it uses PAGE_SIZE instead of the constant 4096 to determine how many GART entries there are. The PCI GART entries map 4096 bytes, always. So using getpagesize() is wrong. (see RADEONDRIGetPciAperTableSize) I have this fixed in my local tree. Oops. 2) It doesn't check the surface byte swapping settings, so it could be saving in one byte order and restoing in another. I guess we could force RADEON_SURFACE_CNTL to zero around the two memcpy()'s done in radeon_driver.c Might be a good plan. I have patches for both of these things written, will submit to the xorg-driver-ati list. I also have a cunning plan to work around the surface swapping GART issue in the DRM, will try that out right now. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/5]: drm: ati_pcigart: Do not access I/O MEM space using pointer derefs.
From: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Sat, 14 Feb 2009 20:07:54 +1100 I did some research, and it does appear that the GART does read the PTEs from the VRAM using the Host Data Path. This means the surface control byte swapping settings are applied. So for depths of 16 and 24, the GART is reading garbage PTEs. And that's why the CP hangs. That makes me wonder how the heck did it work for me ! Or maybe... I've been using an R5xx which happens to have a bit that I haven't seen on R3xx that allows ... to set whether the GART reads come from HDP or directly from MC. That might be what saved my ass here. I wonder. But I really doubt it. The bit is off by default and the radeon DRM code explicitly sets it to off. We can do that by registering a surface from the kernel to cover the GART I suppose, and clean things a bit so that when using the DRI, X doesn't touch the surface registers -at all- and leaves it to the kernel. That actually sounds like a good idea. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH]: drm: radeon: Use surface for PCI GART table.
This allocates a physical surface for the PCI GART table, this way no
matter what other surface configurations exist the GART table will
always be seen by the hardware properly.
We encode the file pointer of the virtual surface allocate using a
special cookie value, called PCIGART_FILE_PRIV. On the last close, we
release that surface.
Just to be doubly safe, we run the pcigart table setup with the main
surface control register clear.
Based upon ideas from David Airlie and Ben Benjamin Herrenschmidt.
Signed-off-by: David S. Miller da...@davemloft.net
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/radeon/radeon_cp.c
index e235778..119e642 100644
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -909,6 +909,46 @@ static void radeon_set_pcigart(drm_radeon_private_t *
dev_priv, int on)
}
}
+static int radeon_setup_pcigart_surface(drm_radeon_private_t *dev_priv)
+{
+ struct drm_ati_pcigart_info *gart_info = dev_priv-gart_info;
+ struct radeon_virt_surface *vp;
+ int i;
+
+ for (i = 0; i RADEON_MAX_SURFACES * 2; i++) {
+ if (!dev_priv-virt_surfaces[i].file_priv ||
+ dev_priv-virt_surfaces[i].file_priv == PCIGART_FILE_PRIV)
+ break;
+ }
+ if (i = 2 * RADEON_MAX_SURFACES)
+ return -ENOMEM;
+ vp = dev_priv-virt_surfaces[i];
+
+ for (i = 0; i RADEON_MAX_SURFACES; i++) {
+ struct radeon_surface *sp = dev_priv-surfaces[i];
+ if (sp-refcount)
+ continue;
+
+ vp-surface_index = i;
+ vp-lower = gart_info-bus_addr;
+ vp-upper = vp-lower + gart_info-table_size;
+ vp-flags = 0;
+ vp-file_priv = PCIGART_FILE_PRIV;
+
+ sp-refcount = 1;
+ sp-lower = vp-lower;
+ sp-upper = vp-upper;
+ sp-flags = 0;
+
+ RADEON_WRITE(RADEON_SURFACE0_INFO + 16 * i, sp-flags);
+ RADEON_WRITE(RADEON_SURFACE0_LOWER_BOUND + 16 * i, sp-lower);
+ RADEON_WRITE(RADEON_SURFACE0_UPPER_BOUND + 16 * i, sp-upper);
+ return 0;
+ }
+
+ return -ENOMEM;
+}
+
static int radeon_do_init_cp(struct drm_device *dev, drm_radeon_init_t *init,
struct drm_file *file_priv)
{
@@ -1202,6 +1242,9 @@ static int radeon_do_init_cp(struct drm_device *dev,
drm_radeon_init_t *init,
} else
#endif
{
+ u32 sctrl;
+ int ret;
+
dev_priv-gart_info.table_mask = DMA_BIT_MASK(32);
/* if we have an offset set from userspace */
if (dev_priv-pcigart_offset_set) {
@@ -1243,12 +1286,25 @@ static int radeon_do_init_cp(struct drm_device *dev,
drm_radeon_init_t *init,
}
}
- if (!drm_ati_pcigart_init(dev, dev_priv-gart_info)) {
+ sctrl = RADEON_READ(RADEON_SURFACE_CNTL);
+ RADEON_WRITE(RADEON_SURFACE_CNTL, 0);
+ ret = drm_ati_pcigart_init(dev, dev_priv-gart_info);
+ RADEON_WRITE(RADEON_SURFACE_CNTL, sctrl);
+
+ if (!ret) {
DRM_ERROR(failed to init PCI GART!\n);
radeon_do_cleanup_cp(dev);
return -ENOMEM;
}
+ ret = radeon_setup_pcigart_surface(dev_priv);
+ if (ret) {
+ DRM_ERROR(failed to setup GART surface!\n);
+ drm_ati_pcigart_cleanup(dev, dev_priv-gart_info);
+ radeon_do_cleanup_cp(dev);
+ return ret;
+ }
+
/* Turn on PCI GART */
radeon_set_pcigart(dev_priv, 1);
}
diff --git a/drivers/gpu/drm/radeon/radeon_drv.h
b/drivers/gpu/drm/radeon/radeon_drv.h
index 9b60a26..ecfd414 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.h
+++ b/drivers/gpu/drm/radeon/radeon_drv.h
@@ -217,6 +217,7 @@ struct radeon_virt_surface {
u32 upper;
u32 flags;
struct drm_file *file_priv;
+#define PCIGART_FILE_PRIV ((void *) -1L)
};
#define RADEON_FLUSH_EMITED(1 0)
diff --git a/drivers/gpu/drm/radeon/radeon_state.c
b/drivers/gpu/drm/radeon/radeon_state.c
index 03fea43..043293a 100644
--- a/drivers/gpu/drm/radeon/radeon_state.c
+++ b/drivers/gpu/drm/radeon/radeon_state.c
@@ -3155,6 +3155,7 @@ void radeon_driver_preclose(struct drm_device *dev,
struct drm_file *file_priv)
void radeon_driver_lastclose(struct drm_device *dev)
{
+ radeon_surfaces_release(PCIGART_FILE_PRIV, dev-dev_private);
radeon_do_release(dev);
}
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing
Re: [PATCH 1/5]: drm: ati_pcigart: Do not access I/O MEM space using pointer derefs.
From: David Miller da...@davemloft.net Date: Sat, 14 Feb 2009 01:11:45 -0800 (PST) From: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Sat, 14 Feb 2009 20:07:54 +1100 We can do that by registering a surface from the kernel to cover the GART I suppose, and clean things a bit so that when using the DRI, X doesn't touch the surface registers -at all- and leaves it to the kernel. That actually sounds like a good idea. Ok I have it working, patch coming right up. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH]: drm: radeon: Use surface for PCI GART table.
From: Michel Dänzer mic...@daenzer.net Date: Sat, 14 Feb 2009 10:59:59 +0100 On Sat, 2009-02-14 at 01:51 -0800, David Miller wrote: This allocates a physical surface for the PCI GART table, this way no matter what other surface configurations exist the GART table will always be seen by the hardware properly. BTW, I don't think the swapping settings affect GPU access to the table, only CPU access, but this is a good solution anyway. They absolutely and positively do effect GPU access to the table. I've proven it with many conclusive tests over the past 3 days. This is only really necessary on big endian, but other than that: Acked-By: Michel Dänzer daen...@vmware.com Thanks. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/5]: drm: ati_pcigart: Do not access I/O MEM space using pointer derefs.
From: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Thu, 12 Feb 2009 21:35:59 +1100 Oh BTW something else to be careful with, though I suppose it's working some what by accident right now... when the GART is in the frame buffer it gets applied the current fb swapper setting... ouch ! So it might be a good idea, if we're going to use DRM_READ/WRITE32 which afaik are readl/writel (ie, swapping) to make sure we at least temporarily disable that swapper while whacking the GART. So I've narrowed down the final problems I'm having. It's the surface swapping settings indeed. Running Xorg at depth 8, the CP can execute indirect buffers just fine, no code changes necessary. However, the CP hangs on indirect execution for depth 16 and 24. But these depths work if I hard disable the surface byte swapping settings in the radeon Xorg driver. I did some research, and it does appear that the GART does read the PTEs from the VRAM using the Host Data Path. This means the surface control byte swapping settings are applied. So for depths of 16 and 24, the GART is reading garbage PTEs. And that's why the CP hangs. I have no idea how to handle this properly. Not only does the Xorg ATI driver set the swapping settings at an arbitray point, it also mucks with them dynamically f.e. in the render helper functions. The only way this can work properly is to choose one surface swapping setting, set the VRAM GART table so that the GART sees the PTEs in the correct format, and retain those settings throughout. It seems like, in at least R5xx, they tried to add a control bit in the PCI-E GART registers to handle this. Bit 6 in PCI-E indirect register 0x10 is named 'GART_RDREQPATH_SEL' and has description: Read request path 0=HDP 1=Direct Rd Req to MC This seems to be intended to be a way to have the GART PTE reads bypass the full Host Data Path (and thus potential surface byte swaps), by setting this bit to 1. I tried doing that, but it doesn't help my RV370 so perhaps older chips don't support this bit. It's hard to tell as this is the area where all of AMD's published GPU documents are severely lacking. I tested whether reading back the PCIE_TX_GART_CNTL register shows bit 6 after I try to write it, and it always reads back zero. There are even more complications, the VT enter/exit code in the Xorg ATI driver tries to save and restore the VRAM GART table for PCI-E cards. But this: 1) Mis-sizes the GART table save buffer, it uses PAGE_SIZE instead of the constant 4096 to determine how many GART entries there are. The PCI GART entries map 4096 bytes, always. So using getpagesize() is wrong. (see RADEONDRIGetPciAperTableSize) I have this fixed in my local tree. 2) It doesn't check the surface byte swapping settings, so it could be saving in one byte order and restoing in another. I guess we could force RADEON_SURFACE_CNTL to zero around the two memcpy()'s done in radeon_driver.c But really this whole area is a mess, and I know KMS is coming to fix this, but even in the traditional XORG/DRM layout XORG has no business keeping the GART table uptodate across VT switches. It should be calling into the DRM with an ioctl to write the GART table out to VRAM again. Finally there is a huge issue with how the Xorg ATI driver resets the chip using the RBBM. It soft resets the CP, but this resets the ring read pointer. However, nothing is done to make sure the DRM resync's the ring write pointer (which remains unchanged by a soft CP reset) as well as it's internal software ring state. The result is that on the very next CP command submission, the CP re-executes everything from ring entry zero until wherever the DRM things the write pointer was at the time of the CP soft reset. Any time the Xorg ATI driver does a CP soft reset, it should do CP stop and resume calls to the DRM to resync the ring pointers. And this does not appear to be happening where it needs to be happening. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH]: drm: ati_pcigart: Fix limit check in drm_ati_pcigart_init().
drm: ati_pcigart: Fix limit check in drm_ati_pcigart_init().
The variable 'max_pages' is ambiguous. There are two concepts
of pages being used in this function.
First, we have ATI GART pages which are always 4096 bytes.
Then, we have system pages which are of size PAGE_SIZE.
Eliminate the confusion by creating max_ati_pages and
max_real_pages. Calculate and use them as appropriate.
Signed-off-by: David S. Miller da...@davemloft.net
---
drivers/gpu/drm/ati_pcigart.c | 13 +++--
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ati_pcigart.c b/drivers/gpu/drm/ati_pcigart.c
index 7972ec8..4d86a62 100644
--- a/drivers/gpu/drm/ati_pcigart.c
+++ b/drivers/gpu/drm/ati_pcigart.c
@@ -102,7 +102,7 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct
drm_ati_pcigart_info *ga
u32 *pci_gart, page_base, gart_idx;
dma_addr_t bus_address = 0;
int i, j, ret = 0;
- int max_pages;
+ int max_ati_pages, max_real_pages;
if (!entry) {
DRM_ERROR(no scatter/gather memory!\n);
@@ -130,14 +130,15 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct
drm_ati_pcigart_info *ga
pci_gart = (u32 *) address;
- max_pages = (gart_info-table_size / sizeof(u32));
- pages = (entry-pages = max_pages)
- ? entry-pages : max_pages;
+ max_ati_pages = (gart_info-table_size / sizeof(u32));
+ max_real_pages = max_ati_pages / (PAGE_SIZE / ATI_PCIGART_PAGE_SIZE);
+ pages = (entry-pages = max_real_pages)
+ ? entry-pages : max_real_pages;
if (gart_info-gart_table_location == DRM_ATI_GART_MAIN) {
- memset(pci_gart, 0, max_pages * sizeof(u32));
+ memset(pci_gart, 0, max_ati_pages * sizeof(u32));
} else {
- for (gart_idx = 0; gart_idx max_pages; gart_idx++)
+ for (gart_idx = 0; gart_idx max_ati_pages; gart_idx++)
DRM_WRITE32(map, gart_idx * sizeof(u32), 0);
}
--
1.6.1.2.350.g88cc
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/5]: drm: ati_pcigart: Do not access I/O MEM space using pointer derefs.
The PCI GART table initialization code treats the GART table mapping
unconditionally as a kernel virtual address.
But it could be in the framebuffer, for example, and thus we're
dealing with a PCI MEM space ioremap() cookie. Treating that as a
virtual address is illegal and will crash some system types (such as
sparc64 where the ioremap() return value is actually a physical I/O
address).
So access the area correctly, using gart_info-gart_table_location as
our guide.
Signed-off-by: David S. Miller da...@davemloft.net
---
drivers/gpu/drm/ati_pcigart.c | 26 --
1 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/ati_pcigart.c b/drivers/gpu/drm/ati_pcigart.c
index c533d0c..2cd827a 100644
--- a/drivers/gpu/drm/ati_pcigart.c
+++ b/drivers/gpu/drm/ati_pcigart.c
@@ -95,10 +95,11 @@ EXPORT_SYMBOL(drm_ati_pcigart_cleanup);
int drm_ati_pcigart_init(struct drm_device *dev, struct drm_ati_pcigart_info
*gart_info)
{
+ struct drm_local_map *map = gart_info-mapping;
struct drm_sg_mem *entry = dev-sg;
void *address = NULL;
unsigned long pages;
- u32 *pci_gart, page_base;
+ u32 *pci_gart, page_base, gart_idx;
dma_addr_t bus_address = 0;
int i, j, ret = 0;
int max_pages;
@@ -133,8 +134,14 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct
drm_ati_pcigart_info *ga
pages = (entry-pages = max_pages)
? entry-pages : max_pages;
- memset(pci_gart, 0, max_pages * sizeof(u32));
+ if (gart_info-gart_table_location == DRM_ATI_GART_MAIN) {
+ memset(pci_gart, 0, max_pages * sizeof(u32));
+ } else {
+ for (gart_idx = 0; gart_idx max_pages; gart_idx++)
+ DRM_WRITE32(map, gart_idx * sizeof(u32), 0);
+ }
+ gart_idx = 0;
for (i = 0; i pages; i++) {
/* we need to support large memory configurations */
entry-busaddr[i] = pci_map_page(dev-pdev, entry-pagelist[i],
@@ -149,19 +156,26 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct
drm_ati_pcigart_info *ga
page_base = (u32) entry-busaddr[i];
for (j = 0; j (PAGE_SIZE / ATI_PCIGART_PAGE_SIZE); j++) {
+ u32 val;
+
switch(gart_info-gart_reg_if) {
case DRM_ATI_GART_IGP:
- *pci_gart = cpu_to_le32((page_base) | 0xc);
+ val = page_base | 0xc;
break;
case DRM_ATI_GART_PCIE:
- *pci_gart = cpu_to_le32((page_base 8) | 0xc);
+ val = (page_base 8) | 0xc;
break;
default:
case DRM_ATI_GART_PCI:
- *pci_gart = cpu_to_le32(page_base);
+ val = page_base;
break;
}
- pci_gart++;
+ if (gart_info-gart_table_location ==
+ DRM_ATI_GART_MAIN)
+ pci_gart[gart_idx] = cpu_to_le32(val);
+ else
+ DRM_WRITE32(map, gart_idx * sizeof(u32), val);
+ gart_idx++;
page_base += ATI_PCIGART_PAGE_SIZE;
}
}
--
1.6.1.2.350.g88cc
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/5]: drm: ati_pcigart: Need to use PCI_DMA_BIDIRECTIONAL.
The buffers mapped by the PCI GART can be written to by the device,
not just read.
For example, this happens via the RB_RPTR writeback on Radeon.
So we can't use PCI_DMA_TODEVICE else we'll get protection faults
on IOMMU platforms.
Signed-off-by: David S. Miller da...@davemloft.net
---
drivers/gpu/drm/ati_pcigart.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/ati_pcigart.c b/drivers/gpu/drm/ati_pcigart.c
index 2cd827a..7972ec8 100644
--- a/drivers/gpu/drm/ati_pcigart.c
+++ b/drivers/gpu/drm/ati_pcigart.c
@@ -77,7 +77,7 @@ int drm_ati_pcigart_cleanup(struct drm_device *dev, struct
drm_ati_pcigart_info
if (!entry-busaddr[i])
break;
pci_unmap_page(dev-pdev, entry-busaddr[i],
-PAGE_SIZE, PCI_DMA_TODEVICE);
+PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
}
if (gart_info-gart_table_location == DRM_ATI_GART_MAIN)
@@ -145,7 +145,7 @@ int drm_ati_pcigart_init(struct drm_device *dev, struct
drm_ati_pcigart_info *ga
for (i = 0; i pages; i++) {
/* we need to support large memory configurations */
entry-busaddr[i] = pci_map_page(dev-pdev, entry-pagelist[i],
-0, PAGE_SIZE,
PCI_DMA_TODEVICE);
+0, PAGE_SIZE,
PCI_DMA_BIDIRECTIONAL);
if (entry-busaddr[i] == 0) {
DRM_ERROR(unable to map PCIGART pages!\n);
drm_ati_pcigart_cleanup(dev, gart_info);
--
1.6.1.2.350.g88cc
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/5]: drm: radeon: Fix ring_rptr accesses.
The memory behind ring_rptr can either be in ioremapped memory
or a vmalloc() normal kernel memory buffer.
However, the code unconditionally uses DRM_{READ,WRITE}32() (and thus
readl() and writel()) to access it.
Basically, if RADEON_IS_AGP then it's ioremap()'d memory else it's
vmalloc'd memory.
Adjust all of the ring_rptr access code as needed.
While we're here, kill the 'scratch' pointer in drm_radeon_private.
It's only used in the one place where it is initialized.
Signed-off-by: David S. Miller da...@davemloft.net
---
drivers/gpu/drm/radeon/radeon_cp.c| 70 +++--
drivers/gpu/drm/radeon/radeon_drv.h | 17
drivers/gpu/drm/radeon/radeon_state.c |6 +-
3 files changed, 70 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/radeon/radeon_cp.c
index ae4ffa1..9053755 100644
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -43,6 +43,52 @@
static int radeon_do_cleanup_cp(struct drm_device * dev);
static void radeon_do_cp_start(drm_radeon_private_t * dev_priv);
+static u32 radeon_read_ring_rptr(drm_radeon_private_t *dev_priv, u32 off)
+{
+ u32 val;
+
+ if (dev_priv-flags RADEON_IS_AGP) {
+ val = DRM_READ32(dev_priv-ring_rptr, off);
+ } else {
+ val = *(((volatile u32 *)
+dev_priv-ring_rptr-handle) +
+ (off / sizeof(u32)));
+ val = le32_to_cpu(val);
+ }
+ return val;
+}
+
+u32 radeon_get_ring_head(drm_radeon_private_t *dev_priv)
+{
+ if (dev_priv-writeback_works)
+ return radeon_read_ring_rptr(dev_priv, 0);
+ else
+ return RADEON_READ(RADEON_CP_RB_RPTR);
+}
+
+static void radeon_write_ring_rptr(drm_radeon_private_t *dev_priv, u32 off,
u32 val)
+{
+ if (dev_priv-flags RADEON_IS_AGP)
+ DRM_WRITE32(dev_priv-ring_rptr, off, val);
+ else
+ *(((volatile u32 *) dev_priv-ring_rptr-handle) +
+ (off / sizeof(u32))) = cpu_to_le32(val);
+}
+
+void radeon_set_ring_head(drm_radeon_private_t *dev_priv, u32 val)
+{
+ radeon_write_ring_rptr(dev_priv, 0, val);
+}
+
+u32 radeon_get_scratch(drm_radeon_private_t *dev_priv, int index)
+{
+ if (dev_priv-writeback_works)
+ return radeon_read_ring_rptr(dev_priv,
+RADEON_SCRATCHOFF(index));
+ else
+ return RADEON_READ(RADEON_SCRATCH_REG0 + 4*index);
+}
+
static u32 R500_READ_MCIND(drm_radeon_private_t *dev_priv, int addr)
{
u32 ret;
@@ -647,10 +693,6 @@ static void radeon_cp_init_ring_buffer(struct drm_device *
dev,
RADEON_WRITE(RADEON_SCRATCH_ADDR, RADEON_READ(RADEON_CP_RB_RPTR_ADDR)
+ RADEON_SCRATCH_REG_OFFSET);
- dev_priv-scratch = ((__volatile__ u32 *)
-dev_priv-ring_rptr-handle +
-(RADEON_SCRATCH_REG_OFFSET / sizeof(u32)));
-
RADEON_WRITE(RADEON_SCRATCH_UMSK, 0x7);
/* Turn on bus mastering */
@@ -668,13 +710,13 @@ static void radeon_cp_init_ring_buffer(struct drm_device
* dev,
RADEON_WRITE(RADEON_BUS_CNTL, tmp);
} /* PCIE cards appears to not need this */
- dev_priv-scratch[0] = 0;
+ radeon_write_ring_rptr(dev_priv, RADEON_SCRATCHOFF(0), 0);
RADEON_WRITE(RADEON_LAST_FRAME_REG, 0);
- dev_priv-scratch[1] = 0;
+ radeon_write_ring_rptr(dev_priv, RADEON_SCRATCHOFF(1), 0);
RADEON_WRITE(RADEON_LAST_DISPATCH_REG, 0);
- dev_priv-scratch[2] = 0;
+ radeon_write_ring_rptr(dev_priv, RADEON_SCRATCHOFF(2), 0);
RADEON_WRITE(RADEON_LAST_CLEAR_REG, 0);
radeon_do_wait_for_idle(dev_priv);
@@ -698,12 +740,15 @@ static void radeon_test_writeback(drm_radeon_private_t *
dev_priv)
/* Writeback doesn't seem to work everywhere, test it here and possibly
* enable it if it appears to work
*/
- DRM_WRITE32(dev_priv-ring_rptr, RADEON_SCRATCHOFF(1), 0);
+ radeon_write_ring_rptr(dev_priv, RADEON_SCRATCHOFF(1), 0);
+
RADEON_WRITE(RADEON_SCRATCH_REG1, 0xdeadbeef);
for (tmp = 0; tmp dev_priv-usec_timeout; tmp++) {
- if (DRM_READ32(dev_priv-ring_rptr, RADEON_SCRATCHOFF(1)) ==
- 0xdeadbeef)
+ u32 val;
+
+ val = radeon_read_ring_rptr(dev_priv, RADEON_SCRATCHOFF(1));
+ if (val == 0xdeadbeef)
break;
DRM_UDELAY(1);
}
@@ -1540,7 +1585,7 @@ struct drm_buf *radeon_freelist_get(struct drm_device *
dev)
start = dev_priv-last_buf;
for (t = 0; t dev_priv-usec_timeout; t++) {
- u32 done_age = GET_SCRATCH(1);
+ u32 done_age = GET_SCRATCH(dev_priv, 1);
DRM_DEBUG(done_age = %d\n, done_age);
for (i = start; i dma
[PATCH 5/5]: drm: radeon: Fix calculation of RB_RPTR_ADDR in non-AGP case.
The address needs to be a GART relative address, rather than a PCI
DMA address.
Signed-off-by: David S. Miller da...@davemloft.net
---
drivers/gpu/drm/radeon/radeon_cp.c | 15 ---
1 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_cp.c
b/drivers/gpu/drm/radeon/radeon_cp.c
index 9053755..e235778 100644
--- a/drivers/gpu/drm/radeon/radeon_cp.c
+++ b/drivers/gpu/drm/radeon/radeon_cp.c
@@ -655,17 +655,10 @@ static void radeon_cp_init_ring_buffer(struct drm_device
* dev,
} else
#endif
{
- struct drm_sg_mem *entry = dev-sg;
- unsigned long tmp_ofs, page_ofs;
-
- tmp_ofs = dev_priv-ring_rptr-offset -
- (unsigned long)dev-sg-virtual;
- page_ofs = tmp_ofs PAGE_SHIFT;
-
- RADEON_WRITE(RADEON_CP_RB_RPTR_ADDR, entry-busaddr[page_ofs]);
- DRM_DEBUG(ring rptr: offset=0x%08lx handle=0x%08lx\n,
- (unsigned long)entry-busaddr[page_ofs],
- entry-handle + tmp_ofs);
+ RADEON_WRITE(RADEON_CP_RB_RPTR_ADDR,
+dev_priv-ring_rptr-offset
+- ((unsigned long) dev-sg-virtual)
++ dev_priv-gart_vm_start);
}
/* Set ring buffer size */
--
1.6.1.2.350.g88cc
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 4/5]: drm: radeon: Fix RADEON_*_EMITED defines.
These are not supposed to be booleans, they are
supposed to be bit masks.
Signed-off-by: David S. Miller da...@davemloft.net
---
drivers/gpu/drm/radeon/radeon_drv.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_drv.h
b/drivers/gpu/drm/radeon/radeon_drv.h
index a253cf0..9b60a26 100644
--- a/drivers/gpu/drm/radeon/radeon_drv.h
+++ b/drivers/gpu/drm/radeon/radeon_drv.h
@@ -219,8 +219,8 @@ struct radeon_virt_surface {
struct drm_file *file_priv;
};
-#define RADEON_FLUSH_EMITED(1 0)
-#define RADEON_PURGE_EMITED(1 1)
+#define RADEON_FLUSH_EMITED(1 0)
+#define RADEON_PURGE_EMITED(1 1)
struct drm_radeon_master_private {
drm_local_map_t *sarea;
--
1.6.1.2.350.g88cc
--
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/5]: drm: ati_pcigart: Do not access I/O MEM space using pointer derefs.
From: Benjamin Herrenschmidt b...@kernel.crashing.org Date: Thu, 12 Feb 2009 21:35:59 +1100 Oh BTW something else to be careful with, though I suppose it's working some what by accident right now... when the GART is in the frame buffer it gets applied the current fb swapper setting... ouch ! So it might be a good idea, if we're going to use DRM_READ/WRITE32 which afaik are readl/writel (ie, swapping) to make sure we at least temporarily disable that swapper while whacking the GART. Cute. I wonder if this is what is tripping me up. But, looking more closely, it appears that: 1) The kernel radeon framebuffer driver doesn't mess with the framebuffer endianness setting. 2) On = R300 (which my chip is), Xorg leaves it alone too. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/5]: drm: ati_pcigart: Do not access I/O MEM space using pointer derefs.
From: Dave Airlie airl...@gmail.com Date: Thu, 12 Feb 2009 21:23:13 +1000 are you on a PCI or PCIE card, I've no idea what buses you have on sparc64. On the PCI cards the GART table will always be in main memory. PCIE always in VRAM. PCI-E -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/5]: ATI/RADEON DRM bug fixes...
From: Dave Airlie airl...@gmail.com Date: Thu, 12 Feb 2009 21:26:51 +1000 On Thu, Feb 12, 2009 at 8:15 PM, David Miller da...@davemloft.net wrote: David, this work is against your drm-next branch. Here are a collection of bug fixes for the Radeon DRM support. Most of them have to do with trying to access kernel virtual addresses using DRM_READ32() and DRM_WRITE32(). With these patches at least the writeback test works on sparc64 and the CP is able to process commands in the ring. I'm now diagnosing some further problem that's preventing Xorg from functioning fully but I should be able to diagnose that soon. You'll probably love patch #4 in this series, and it probably explains all kinds of weird problems people run into with DRM on radeon cards. Thanks Dave, These all look great, the EMITED one has potential to regress something by fixing it, but I think it might actually make things better, I'll push all of these to Linus asap as they all fix real bugs. I've put them into my drm-fixes branch and I'll try and re-review and get some testing tomorrow when I'm more awake. Note that these depend upon Ben's drm_addmap and resource fixed in your drm-next branch, sparc64 was also broken by those problems. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 09/59] CRED: Wrap task credential accesses in the DRM driver
Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current-(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task-e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells [EMAIL PROTECTED] Reviewed-by: James Morris [EMAIL PROTECTED] Acked-by: Serge Hallyn [EMAIL PROTECTED] Cc: David Airlie [EMAIL PROTECTED] Cc: dri-devel@lists.sourceforge.net --- drivers/gpu/drm/drm_fops.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c index 851a53f..dcf8b4d 100644 --- a/drivers/gpu/drm/drm_fops.c +++ b/drivers/gpu/drm/drm_fops.c @@ -246,7 +246,7 @@ static int drm_open_helper(struct inode *inode, struct file *filp, memset(priv, 0, sizeof(*priv)); filp-private_data = priv; priv-filp = filp; - priv-uid = current-euid; + priv-uid = current_euid(); priv-pid = task_pid_nr(current); priv-minor = idr_find(drm_minors_idr, minor_id); priv-ioctl_count = 0; - 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
[PATCH 2/2] Fix a pointer cast warning in the SIS DRM code
Fix a pointer cast warning in the SIS DRM code. This was introduced in patch ce65a44de07f73ceda1749812b75086b7add408d. Signed-off-by: David Howells [EMAIL PROTECTED] --- drivers/char/drm/sis_mm.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/char/drm/sis_mm.c b/drivers/char/drm/sis_mm.c index c4debfd..af22111 100644 --- a/drivers/char/drm/sis_mm.c +++ b/drivers/char/drm/sis_mm.c @@ -57,7 +57,7 @@ static void *sis_sman_mm_allocate(void *private, unsigned long size, if (req.size == 0) return NULL; else - return (void *)~req.offset; + return (void *)(unsigned long)~req.offset; } static void sis_sman_mm_free(void *private, void *ref) - Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] Fix the SIS DRM memory allocator if the SIS FB is built as a module
Fix the SIS DRM memory allocator if the SIS FB built as a module. The SIS DRM
code initialises the mm allocation hooks, but _only_ if the SIS FB is not
built as a module because it depends on CONFIG_FB_SIS, and that's unset if the
SIS FB is not built in. It must check CONFIG_FB_SIS_MODULE as well.
Signed-off-by: David Howells [EMAIL PROTECTED]
---
drivers/char/drm/sis_mm.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/drm/sis_mm.c b/drivers/char/drm/sis_mm.c
index b387877..c4debfd 100644
--- a/drivers/char/drm/sis_mm.c
+++ b/drivers/char/drm/sis_mm.c
@@ -41,7 +41,7 @@
#define AGP_TYPE 1
-#if defined(CONFIG_FB_SIS)
+#if defined(CONFIG_FB_SIS) || defined(CONFIG_FB_SIS_MODULE)
/* fb management via fb device */
#define SIS_MM_ALIGN_SHIFT 0
@@ -75,12 +75,12 @@ static unsigned long sis_sman_mm_offset(void *private, void
*ref)
return ~((unsigned long)ref);
}
-#else /* CONFIG_FB_SIS */
+#else /* CONFIG_FB_SIS[_MODULE] */
#define SIS_MM_ALIGN_SHIFT 4
#define SIS_MM_ALIGN_MASK ( (1 SIS_MM_ALIGN_SHIFT) - 1)
-#endif /* CONFIG_FB_SIS */
+#endif /* CONFIG_FB_SIS[_MODULE] */
static int sis_fb_init(struct drm_device *dev, void *data, struct drm_file
*file_priv)
{
@@ -89,7 +89,7 @@ static int sis_fb_init(struct drm_device *dev, void *data,
struct drm_file *file
int ret;
mutex_lock(dev-struct_mutex);
-#if defined(CONFIG_FB_SIS)
+#if defined(CONFIG_FB_SIS) || defined(CONFIG_FB_SIS_MODULE)
{
struct drm_sman_mm sman_mm;
sman_mm.private = (void *)0x;
-
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Support for stereoscopic output in DRI?
Ah, thanks for your explanations. Too bad it's not as straightforward as I'd hoped... One would have hoped the creators of the OpenGL standard would have prepared it for steroscopic graphics right from the start, but perhaps they didn't think it'd catch on? For the time being I guess I'll just enjoy my bzflag in 3D... B) -David Oftedal - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm + 4GB RAM + swiotlb = drm craps out
From: Dave Airlie [EMAIL PROTECTED] Date: Mon, 2 Apr 2007 09:44:41 +1000 Okay I've got a bug reported before and now again about 4GB + radeon blows up the DRM... on Intel hw... What the drm currently does for the PCI GART table is it allocates a chunk of memory (8MB) with vmalloc_32(), then when it decides to use it it goes through every page of it calls pci_map_single() (with PCI_DMA_TODEVICE, which is probably wrong...) with every page from the vmalloc mapping and puts the bus addresses of the pages into the PCI GART table on the GPU. So when swiotlb happens, as you can guess it all falls apart as the drm never calls sync functions at any stage... You would have hit this on any platform that does caching in the PCI controller as well. The main problem is the ring buffer and scratch write back, these values are read/write from both the CPU and GPU quite a lot, so this leads me to think I should really just be using dma_alloc_coherent for the whole lot, however this is an 8MB mapping and possibly could be getting larger in the future and dynamic as we do dynamic PCIEGART support for the radeons... So I suppose I'm asking for ideas on the correct way to do this, and perhaps any quick way to patch up the problem I'm seeing now by making swiotlb not get involved Coherent memory was created for precisely the case where the cpu and the device frequently access the memory. 8MB is indeed a lot for the kind of allocation that the coherent DMA implementation uses. Does it really have to be all in one big 8MB chunk? I doubt it. Perhaps you can therefore create multiple DMA pools instead? See include/linux/dmapool.h - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm + 4GB RAM + swiotlb = drm craps out
From: Dave Airlie [EMAIL PROTECTED] Date: Mon, 2 Apr 2007 14:08:13 +1000 So when swiotlb happens, as you can guess it all falls apart as the drm never calls sync functions at any stage... You would have hit this on any platform that does caching in the PCI controller as well. We must not have a great intersect of radeon and such systems.. It might explain why my machine hung when I tried to use radeon with DRM on my sparc64 workstation :-) I have investigating that on my todo list. It currently is required to be in a big 8MB chunk as it gets chopped up by the X server not the kernel, so kernel needs to allocate pages to back it when X inits, yes this is ugly, no it can't be fixed without time-travelling and fixing deployed X servers... Really we probably only need the ring buffer to be in coherent memory, the rest of the stuff is used for DMA buffers which are mainly filled by the CPU and read by the GPU. However I cannot change this without breaking X, the solution is really to use TTM for this sort of stuff I'm a bit worried as the AGP driver now uses vmalloc_32 which really is a meaningless interface on 64-bit systems.. I don't know what to recommend to you, getting 8MB of linear memory really just isn't practical. Perhaps we'll have to create something ugly like vmalloc_nobounce(). Remind me again why you're ending up with swiotlb'd pages? vmalloc_32() uses GFP_KERNEL which should use entirely lowmem and thus RAM below 4GB and not anything which should need bounce buffering. You should only get swiotlb'd pages if __GFP_HIGHMEM were set in the gfp flags. Are you expecting to be able to virtually remap these pages in PCI space as one huge 8MB chunk too and that's how swiotlb gets involved? That won't work, sorry... - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm + 4GB RAM + swiotlb = drm craps out
From: Dave Airlie [EMAIL PROTECTED] Date: Mon, 2 Apr 2007 15:15:48 +1000 Perhaps we'll have to create something ugly like vmalloc_nobounce(). Remind me again why you're ending up with swiotlb'd pages? vmalloc_32() uses GFP_KERNEL which should use entirely lowmem and thus RAM below 4GB and not anything which should need bounce buffering. On a 64-bit machine GFP_KERNEL can give me any memory... it all works fine on 32-bit highmem kernel as I don't get highmem... I really need __GFP_DMA32 memory but we don't have a generic allocator that gives this out that I can see.. That clears things up thanks. Perhaps the other uses of vmalloc_32() want GFP_32 semantics too, although I didn't check. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Support for stereoscopic output in DRI?
Hello! According to one or more sources on Google, Linux now makes it possible to use LCD shutter to get stereoscopic graphics in certain games and with certain graphics cards. However, there are certainly other interesting methods of outputting stereoscopic graphics, such as outputting to two different outputs (such as two different projectors with different polarising filters), combining the red channel of the left frame and the green and blue channels of the right frame to create an anaglyphic image that can be viewed with 3D glasses and so on, and it would be really interesting to see if these methods could be used to output OpenGL graphics. Even more so with the arrival of 3D TVs and monitors, it would be interesting to be able to use their stereoscopic capabilities with existing games and applications. I've seen two pieces of software, one for Linux and one for Windows, and it seemed like what they did was intercept OpenGL commands and render two separate images at slightly shifted (user-specified?) angles or viewpoints, one for the left eye and one for the right eye. If the effect could be achieved more or less reliably in all applications, stereoscopic output could be achieved in a wide range of games even today. At any rate, I was wondering if something like this has ever been attempted, or implemented, in DRI? Best regards David J. Oftedal - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[nouveau] Formal offer from the nouveau driver pledge drive
Dear Nouveau developers It is my pride and honor on behalf of myself and 1247 other pledgers (as of current writing) to formally offer up the sum of ~10.000$ in the form of 1248 pledges of at least 10$ each. It is entirely up to you, the nouveau developers, if you want to accept this donation and if so what you elect to do with the money. We offer it up without strings attached though naturally with the hope that it goes towards easing your lives a bit and help the world reap the benefits of your hard labor as soon as possible. There are boring technical details to take care of in regards to the actual donations to take place and should you elect to take this offer I will do my best to be helpful in working them out. I know this pledge drive has caused both trouble and confusion for you all, for that I personally apologize as well. Thank you for your hard work. Kind regards, David Nielsen -- Ridicule is the only weapon that can be used against unintelligible propositions. Ideas must be distinct before reason can act upon them.” -Thomas Jefferson signature.asc Description: Dette er en digitalt underskrevet brevdel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: driver level sub-pixel rendering?
On Sat, 2006-04-01 at 20:08 +0200, Nicolai Haehnle wrote: On Friday 31 March 2006 19:49, Keith Packard wrote: On Fri, 2006-03-31 at 09:33 -0700, Brian Paul wrote: AFAIK, nobody's hardware does that. When that kind of antialiasing is done for text, I think it's the job of the font rendering code to do so. It's not the construction of the glyphs that's at issue here, I don't think. The glyphs are drawn to the screen using a separate alpha channel for each component in the pixel, an operation which isn't directly supported by the GL API at present. I don't know what we'd need in the hardware for this to be efficient though; I believe it is possible to do it today using three passes for each string, which seems horrendous until you realize how slow it will be to do the same thing with the CPU. Surely you could just use an RGB texture instead of an ALPHA texture? Then it's just a matter of setting the appropriate texture environments and blending modes. Not really, as you can only pass one alpha value to the blending stage. In the general case you need to do it in multiple passes. I've got code in glitz for doing this in three passes. For the case when we're using a solid source color and OVER operator (I think that's 99.9% of all text rendering in X today) we can actually pass all alpha channels to the blending stage and achieve per-component alpha blending with the solid source color in one pass by using GL blend color. I've got code in glitz for doing this as well. -David --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Lockup on x server startup with xorg 6.9 on Radeon (R100)
On Sat, Jan 14, 2006 at 04:07:47PM +1030, Kevin Shanahan wrote: On Fri, Jan 13, 2006 at 08:40:11AM -0500, Alex Deucher wrote: It probably needs Ben's mem patch. PCI cards were the most prone to problems without it IIRC. I think you can comment out the busmastering lines (reg RADEON_BUS_CNTL) in RADEONSetFBLocation() as a quick hack, it may help. It really need the full patch. I guessed you were talking about the patch from this email: http://lists.freedesktop.org/archives/xorg/2005-December/011679.html I rebuilt the xserver-xorg and xserver-common Debian packages with this patch applied and it does seem to have fixed the startup problems. Successful five times in a row so far. It also seems to have fixed the VT switch problems. I also tried out the patch on my desktop which has an R100 QD (7200) and it seems fine there as well. I'll keep an eye out for future versions of the patch for further testing. Awesome. Would you mind putting the info that this patch fixed your problem in the Debian bug? I'm looking to add the patch to the packages when Ben says it's ready. - David Nusinow --- 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: persistant problems with drm + mga
Hello again Just for the record I have downgraded to debian stable just to check a few things and the speed difference is definitely noticeable. glxgears cogs fly in debian stable and in blender a simple textured round shape moves with no delay/jitter. with latest X and 2.4.15 kernel the same shape shows noticeable delay/jitter. Seems like a performance regression to me (but I am no expert). Dave --- 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: persistant problems with drm + mga
On Tuesday 03 Jan 2006 18:02, Ian Romanick wrote: David Mulcahy wrote: I have been experiencing problems getting drm to work again with my matrox g4oo card. The problem started around this post. http://sourceforge.net/mailarchive/forum.php?thread_id=8163981forum_id=7 177 Now although That particular problem has stopped I still cannot get drm working again. I have a current kernel 2.6.14 and a new xorg X Protocol Version 11, Revision 0, Release 6.9 but still no drm. This appears in the xlog (**) Option dpms (**) MGA(0): DPMS enabled (II) MGA(0): Using overlay video (II) MGA(0): X context handle = 0x1 (II) MGA(0): [drm] installed DRM signal handler (II) MGA(0): [DRI] installation complete (EE) MGA(0): [drm] Failed to map DMA buffers list (II) MGA(0): [drm] removed 1 reserved context for kernel (II) MGA(0): [drm] unmapping 8192 bytes of SAREA 0xe0a27000 at 0xb6192000 (WW) MGA(0): Direct rendering disabled (==) RandR enabled There were some issues with the AGP interaction in the MGA DRM introduced last August. I believe that I fixed them around the beginning of November. I'm not sure if all of those changes found their way into 2.6.14. Is there anything interesting in /var/log/messages? See also: https://bugs.freedesktop.org/show_bug.cgi?id=4797 There are two things that you could try. First, try updating your DRM to current CVS. Second, try adding 'Option OldDmaInit true' to the card's device section in your xorg.conf. Right after upgrading to kernel 2.6.15-rc5 things are getting better. This is with 'Option OldDmaInit true' in my xconf file. (**) MGA(0): DPMS enabled (II) MGA(0): Using overlay video (II) MGA(0): X context handle = 0x1 (II) MGA(0): [drm] installed DRM signal handler (II) MGA(0): [DRI] installation complete (II) MGA(0): [drm] Mapped 128 DMA buffers (II) MGA(0): [drm] dma control initialized, using IRQ 7 (II) MGA(0): Direct rendering enabled and this is from glxgears 1210 frames in 5.0 seconds = 241.964 FPS 1206 frames in 5.0 seconds = 241.097 FPS 1206 frames in 5.0 seconds = 241.014 FPS 1207 frames in 5.0 seconds = 241.209 FPS 1207 frames in 5.0 seconds = 241.253 FPS 1206 frames in 5.0 seconds = 241.181 FPS However the cogs turning when glxgears are running are VERY slow a lot slower than I am used to and the 241FPS is slightly down on 311FPs that I used to get (but why are the cogs moving so slowly as if direct rendering is turned off). Remove 'Option OldDmaInit true' and drm is disabled again. Dave --- 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
persistant problems with drm + mga
Hello all I have been experiencing problems getting drm to work again with my matrox g4oo card. The problem started around this post. http://sourceforge.net/mailarchive/forum.php?thread_id=8163981forum_id=7177 Now although That particular problem has stopped I still cannot get drm working again. I have a current kernel 2.6.14 and a new xorg X Protocol Version 11, Revision 0, Release 6.9 but still no drm. This appears in the xlog (**) Option dpms (**) MGA(0): DPMS enabled (II) MGA(0): Using overlay video (II) MGA(0): X context handle = 0x1 (II) MGA(0): [drm] installed DRM signal handler (II) MGA(0): [DRI] installation complete (EE) MGA(0): [drm] Failed to map DMA buffers list (II) MGA(0): [drm] removed 1 reserved context for kernel (II) MGA(0): [drm] unmapping 8192 bytes of SAREA 0xe0a27000 at 0xb6192000 (WW) MGA(0): Direct rendering disabled (==) RandR enabled ANY HELP IS MOST WELCOME Thanks Dave. --- 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
libGL warning: 3D driver claims to not support visual 0x23
Hello Not sure if this is the right list to post to but i am just reporting a problem I am experiencing with current unstable version of xorg and xfree. The problem is with mga and dri (I think) The output from glxgears is libGL warning: 3D driver claims to not support visual 0x23 libGL warning: 3D driver claims to not support visual 0x24 libGL warning: 3D driver claims to not support visual 0x27 libGL warning: 3D driver claims to not support visual 0x28 libGL warning: 3D driver claims to not support visual 0x2b libGL warning: 3D driver claims to not support visual 0x2c libGL warning: 3D driver claims to not support visual 0x2f libGL warning: 3D driver claims to not support visual 0x30 but for some reason the problem is apparent when using blender. In fact blender is unusable with this problem because the colours dissapear. To use blender i have to remove the intel-agp and agpgart modules, and then all is fine. Just some info on a problem I am experiencing. Any advice would be appreciated Dave Please CC me as I am not subscribed to the list --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
strings.h vs string.h
I've found a few places where strings.h is included. When I use some versions of the gcc complier I get a 'file not found' error. I changed some to string.h and the compile is working ok. The files I changed were t_vp_build.c and main/texenvprogram.c. Should these be string.h or strings.h? David Kesselring Atmel MMC [EMAIL PROTECTED] 919-462-6587 --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
missing definition
I'm trying to build the software only mesa on cygwin but have a compile error for a missing definition. Would any of you know where to look for M_E from the following snip? t_vp_build.c, build_fog() case GL_EXP: emit_op1(p, VP_OPCODE_ABS, tmp, 0, input); emit_op2(p, VP_OPCODE_MUL, tmp, 0, tmp, swizzle1(params,X)); emit_op2(p, VP_OPCODE_POW, fog, WRITEMASK_X, register_const1f(p, M_E), negate(tmp)); ^^^ Thanks, David Kesselring Atmel MMC [EMAIL PROTECTED] 919-462-6587 --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393alloc_id=16281op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
linux-fbdev build
I've downloaded the latest code from cvs and built using 'make linux-fbdev'. It does not look like progs/fbdev dir was built. Is that expected or should it be built with the linux-fbdev option? Thanks, David David Kesselring Atmel MMC [EMAIL PROTECTED] 919-462-6587 --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
newbie question - ARM support
When looking at the Mesa source I see processor specific directories in Mesa-x.x.x/src/mesa. I see x86,sparc,ppc. What happens in a build for ARM? Thanks, David Kesselring Atmel MMC [EMAIL PROTECTED] 919-462-6587 --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
linux-solo fb-dri
Hello, My project is to get opengl/mesa on an embedded arm7. I am trying to begin with the linux-solo build and the simplest driver which seems to be the fb-dri. Unfortunately it does not compile. Do any of you have information about the current status of this driver? Ideally, I would like to modify things enough to get a software only build without any OS dependencies (i.e. just dump data to a psuedo-framebuffer). Thanks for your help. David Kesselring Atmel MMC [EMAIL PROTECTED] 919-462-6587 --- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: linux-solo fb-dri
Thanks Keith. David On Thu, 28 Apr 2005, Keith Whitwell wrote: Keith Whitwell wrote: David Kesselring wrote: Hello, My project is to get opengl/mesa on an embedded arm7. I am trying to begin with the linux-solo build and the simplest driver which seems to be the fb-dri. Unfortunately it does not compile. Do any of you have information about the current status of this driver? Ideally, I would like to modify things enough to get a software only build without any OS dependencies (i.e. just dump data to a psuedo-framebuffer). Thanks for your help. David, I'm not sure what the current status of linux-solo/fbdri is, but there are several drivers that are probably even simpler - for instance the driver in mesa/drivers/fbdev. If you scan through the source in that directory you should get an idea how small a driver can be. The fbdri is a demonstration of a software-only driver which happens to live within a framework designed for acclerated drivers. The focus of recent development has definitely been the DRI drivers, but it shouldn't be forgotten that the historical mesa drivers are exactly targetted towards the sort of dumb framebuffer device you are describing, and the easiest way to get one is still going to be by looking at one of those old-style drivers. Ugh. I've just had a quick check and the fbdev driver hasn't been brought up to speed with recent changes either (including build changes)... I'll see if I can't get it running again later tonight. Keith David Kesselring Atmel MMC [EMAIL PROTECTED] 919-462-6587 --- SF.Net email is sponsored by: Tell us your software development plans! Take this survey and enter to win a one-year sub to SourceForge.net Plus IDC's 2005 look-ahead and a copy of this survey Click here to start! http://www.idcswdc.com/cgi-bin/survey?id=105hix -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Announce] DRIconf 0.2.5
El Domingo, 27 de Marzo del 2005 4:02 PM, Felix Kühling escribió: The tarball includes a Makefile, which is supposed to make life easier for translators. If you're interested in translating DRIconf to your native language see the start of the Makefile for instructions. Well, I think that there should be more strings marked for translation. Anyway here's the .po for the Spanish translation. See ya. David Rubio. es.po.tgz Description: application/tgz
Re: [Announce] DRIconf 0.2.5
El Domingo, 27 de Marzo del 2005 9:16 PM, Felix Kühling escribió: Am Sonntag, den 27.03.2005, 19:45 +0200 schrieb David: El Domingo, 27 de Marzo del 2005 4:02 PM, Felix Kühling escribió: The tarball includes a Makefile, which is supposed to make life easier for translators. If you're interested in translating DRIconf to your native language see the start of the Makefile for instructions. Well, I think that there should be more strings marked for translation. I suppose you're referring to option descriptions? They are not part of the DRIconf user interface, they are defined in the drivers themselves. Of course you're welcome to translate them too. Take a look at mesa/src/mesa/drivers/dri/common/xmlpool.h in Mesa CVS. I'll take a look. Now that I know gettext, I'm considering to generate xmlpool.h automatically from .po-files. That would make life easier for maintainers of translations, especially for non-programmers. A brief note on this: I searched google for pygettext and I read somewhere that it has been deprecated for xgettext, now supporting python. I installed python-demo from a suse package, but make po failed saying that pygettext could not be found, so I copied pygettext.py to the driconf directory and edited the Makefile so that python pygettext.py were called instead of only pygettext. BTW, do you use any special tool for editing .po files? I tried the Emacs mode for po files, but I'm not too happy with it. (Maybe I'd change my mind if I was dealing with longer .po files.) I use a plain text editor: Kate. I could have used also KBabel or another specific tool, but IMHO they are very complicated for the normal user. Anyway here's the .po for the Spanish translation. Thanks for this very quick reply. I'll wait for a few more translations before making a new release. I went through your translation. I know very little Spanish myself (I know how it's pronounced ;-) and have a few comments/questions: The í in aplicacíón looks like a typo: msgstr Crear un nuevo dispositivo o aplicacíón Yes, It's a typo. It should be aplicación. You translated anyway in two different ways. Is that intentional? Would it be better to use the same formulation in both cases? ¿Salir de todos modos? ¿Salvar de todas formas? Both forms are correct. And you are right. Choose one. Is Creados a typo? AFAIK plural should not change the verb: msgstr Creados nuevos archivos de configuración DRI %s por usted. Yes, but here the phrase is a short form for: Han sido creados nuevos archivos de configuración por usted. It would be more natural with a passive form: Se han creado nuevos archivos de configuración de DRI por usted. or Se han creado por usted nuevos archivos de configuración de DRI. The last one is more out of curiosity: You used usted when addressing the user, which is used very much in South America among strangers. AFAIK in Spain tú is more widely used, though I don't know which is the usual form in user interfaces. What is your experience? Usted is the polite form. Kids use it to talk to adults, and people use it when talking to somebody who had never meet before, etc. In South America it is used way more often. However, it is the form that user interfaces use. KDE uses it all the time. Anyway it was a _fast_ translation. ;-) See ya. David Rubio. Hasta luego, Felix --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95alloc_id396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: New snapshots
Little bug, little fix. There is a bug in the install script in the DRM compile section. It is checking for a linux-2.6 directory. I changed it to linux-core and it works. El Lunes, 31 de Enero del 2005 2:04 PM, Felix Kühling escribió: Hi all, I just uploaded a new set of experimental snapshots built on our new snapshot build host kindly sponsored by Eric Anholt. They can be found on http://dri.freedesktop.org/~fxkuehl/snapshots for now. Once the daily build is up and running again they will be available from the usual place http://dri.freedesktop.org/snapshots. Please test these snapshots (*-20050130-linux.i386.tar.bz2) and report any problems you may find, especially with the install script. The new snapshots contain the new linux-core/shared-core DRM for 2.6 kernels. On 2.4 kernels the old linux/shared DRM will be built. The default module format changed in Xorg CVS. However, the snapshots are still built with the old module format because that's the format still in use in the latest Xorg releases. If you compiled Xorg from CVS with the new module format you'll have to restore the last release first before installing the new snapshots. AFAIK the new module format is already used at least in one distribution, namely Gentoo. It would be easy to set up builds for both module formats. Then users would have to choose which module format is the correct one for them. I suggest to make dlloader builds available in http://dri.freedesktop.org/snapshots/dlloader/... for those who know that they need them. So much for now, Felix --- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag--drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: A few Savage Xv issues
El Lunes, 1 de Noviembre del 2004 4:22 PM, Alex Deucher escribió: On Sun, 31 Oct 2004 13:42:32 +0100, David [EMAIL PROTECTED] wrote: Hi. While the current Xv implementation is far better than the old one there are still a few glitches I noticed so far: * 4 pixels always missing on the right side on the screen * The old shadowing effect is showed on certain conditions (depending on input sizes). I only tested a few sizes: 768 and smaller work, 924 (and probably greater) show that effect. I wanted to make this report because I noticed today that the shadowing effect still remains. I noticed it using the tv aplicattion tvtime and changing the horizontal resolution to 924. Unfortunately, I do not have any video file to test such big sizes. I'm using savage and common snapshots from 20041015. I hope these are not too old. Thank you for your time. I haven't had a chance to look into the missing pixel stuff yet. What Yeah, I know. I just wanted to enumerate the current issues. Take your time. Anyway is a minor stuff. do you mean by shadowing? You might try turning off option BCIforXv Alex I mean how it looked in the past: random horizontal lines placed on the right (or left) side of the image, taken from the other side giving the impresion that one side is superimposed on the other side with heavy flickering. Do you remember it? Here is a image I made time ago to show the effect: http://deif.wolfnews.net/tv-bad.jpg BTW, turning BCIforXv off has no effect. David --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_idU88alloc_id065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
A few Savage Xv issues
Hi. While the current Xv implementation is far better than the old one there are still a few glitches I noticed so far: * 4 pixels always missing on the right side on the screen * The old shadowing effect is showed on certain conditions (depending on input sizes). I only tested a few sizes: 768 and smaller work, 924 (and probably greater) show that effect. I wanted to make this report because I noticed today that the shadowing effect still remains. I noticed it using the tv aplicattion tvtime and changing the horizontal resolution to 924. Unfortunately, I do not have any video file to test such big sizes. I'm using savage and common snapshots from 20041015. I hope these are not too old. Thank you for your time. --- This SF.Net email is sponsored by: Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux. http://ads.osdn.com/?ad_id=5588alloc_id=12065op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage: 4 pixels missing
El Jueves, 14 de Octubre del 2004 5:38 AM, Alex Deucher escribió: On Thu, 14 Oct 2004 00:55:51 +0200, David [EMAIL PROTECTED] wrote: Hi. Sorry to be too picky, but I've found that after the Xv fix 4 pixels are missing on the right side of the screen. You can check a sample image to test this here (please do not abuse the server): http://webs.ono.com/deifo/fullscreen-test.png Put the image as a wallpaper at 1024x768x16 and see the right side. The 4 rightmost pixels (in red) cannot be seen. Before the Xv fix the problem was also appearing running any program using overlay surfaces (kdetv, xine, ...). Now is permanent. I'll look into it. thanks for reporitng it. BTW, which savage chip do you have? Alex lspci -v reports: :01:00.0 VGA compatible controller: S3 Inc. Savage 4 (rev 02) (prog-if 00 [VGA]) Subsystem: S3 Inc. 86C394-397 Savage4 Flags: bus master, 66Mhz, medium devsel, latency 248, IRQ 11 Memory at e100 (32-bit, non-prefetchable) Memory at d800 (32-bit, prefetchable) [size=128M] Capabilities: [dc] Power Management version 1 Capabilities: [80] AGP version 2.0 BTW, you can put this bug in your lowest-priority list ;) P.S. The new Xv implementation works great. You guys are doing an excellent job with the savage driver. A few other issues have magically disappeared (strange plain-color rectangles on the screen while clicking a header in a QTable widget on keramik-based themes at 24bpp plus a temporary system hang, etc...). I don't know if these strange bugs came with the driver or the X server, but now they are gone. Thanks for your time. David. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Undefined symbols in recent DRM
El Martes, 12 de Octubre del 2004 1:02 AM, Felix Kühling escribió: I've uploaded a Xorg-modules.tar.bz2 to the snapshots/extras dir. It contains all (strip -g) modules except the ones included in the binary snapshots (libGLcore.a, libglx.a, libdri.a, all 2D and 3D drivers). David, could you give it a try? Proceed as follows: uninstall common and card-specifc snapshots cd /usr/X11R6/lib mv modules modules.backup tar -tjf ~/Xorg-modules.tar.bz2 reinstall common and card-specific snapshots If this works I'll update the snapshot installation instructions and add a README.Xorg in the extras dir. Regards, Felix Yes, it works. Finally I can continue testing. However tar -tjf only lists the archive contents ;) but I got the idea. You can update the docs. Thanks (to all) for your work. David. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
libGL cannot open savage_dri.so
I tried the 20041012 common+savage snapshots with the Xorg snapshots today. The only problem I'm seeing is that direct rendering isn't enabled. Xorg.0.log says that DRI is enabled. Output of glxinfo with LIBGL_DEBUG=verbose: name of display: :0.0 libGL: XF86DRIGetClientDriverName: 1.1.16 savage (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/savage_dri.so libGL error: dlopen /usr/X11R6/lib/modules/dri/savage_dri.so failed (libexpat.so.1: cannot open shared object file: No such file or directory) libGL error: unable to find driver: savage_dri.so display: :0 screen: 0 direct rendering: No ... ls -l /usr/X11R6/lib/modules/dri/savage_dri.so -rwxr-xr-x 1 root root 5129761 2004-10-12 22:17 /usr/X11R6/lib/modules/dri/savage_dri.so* Output of xdriinfo options 0: libGL: XF86DRIGetClientDriverName: 1.1.16 savage (screen 0) libGL: OpenDriver: trying /usr/X11R6/lib/modules/dri/savage_dri.so libGL error: dlopen /usr/X11R6/lib/modules/dri/savage_dri.so failed (libexpat.so.1: cannot open shared object file: No such file or directory) libGL error: unable to find driver: savage_dri.so Driver savage is not installed or does not support configuration. A snip of dmesg: ... PCI: Unable to reserve mem region #2:[EMAIL PROTECTED] for device :01:00.0 mtrr: base(0xda00) is not aligned on a size(0x500) boundary [drm] Initialized savage 1.0.0 20011023 on minor 0: [drm] Used old pci detect: framebuffer loaded ... Regards, David --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 3D not working after software suspend/resume
Bill Gou wrote: after a software suspend/resume cycle, running glxgears emits the following error msgs and quits: libGL warning: 3D driver claims to not support visual 0x22 libGL warning: 3D driver claims to not support visual 0x23 libGL warning: 3D driver claims to not support visual 0x26 libGL warning: 3D driver claims to not support visual 0x27 intelWaitIrq: drmI830IrqWait: -16 The kernel also logged the following message: [drm:i915_wait_irq] *ERROR* i915_wait_irq: EBUSY -- rec: 972815 emitted: 972834 I'm running Xorg 6.8.1 with i915-20041008 snapshot. My video card is an Intel 855GM, below is the lspci -v output I'll add a Me too here. I830 CGC, Panasonic Toughbook R1. I don't get the libGL warnings; when I run glxgears, I see the first frame and then it stalls; after about 2-3s, the window closes and it says: intelWaitIrq: drmI830IrqWait: -16 Nonetheless, a definite improvement with i915 driver from before (suspend and resume with i830 DRI would suspend fine, but resume would lead to a hung machine after X restarted). David Bronaugh --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
i915 DRM
Hey, I was poking through the code for i915 DRM, trying to find the source of the resume failure. It looks like the i915_resume function can't be called by anything -- am I wrong about this? If I'm right, how should it be enabled? Regardless, I have some doubts about the allocation made using pci_alloc_consistent in the init function surviving over a suspend. The impression I got from asking people was that a DMA mapping such as that would -not- survive a suspend cycle. Info / feedback welcome :) David Bronaugh --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Undefined symbols in recent DRM
El Domingo, 10 de Octubre del 2004 12:08 AM, Adam Jackson escribi: On Saturday 09 October 2004 12:02, Felix Khling wrote: On Sat, 9 Oct 2004 09:09:52 -0400 Adam Jackson [EMAIL PROTECTED] wrote: On Friday 08 October 2004 17:22, David wrote: Hi. Common and savage snapshots from 20041008 are giving me this at the XFree86 startup: You cannot use modules compiled for Xorg 6.8 on XFree86 anything. I thought they were still binary compatible. If they are not then we would have to offer a download of a precompiled Xorg server for snapshot users. They are forwards compatible but not backwards compatible. 4.4 modules will work on 6.8, but 6.8 modules won't work on 4.4. So yes, we need to build an Xorg server snapshot. - ajax I don't want to reinstall my whole box every year, so I must find a way to test current snapshots on XFree86 or give up with testing. The new snapshots instructions (Xorg binary, etc...) are giving me this: Symbol FontCacheChangeSettings from module /usr/X11R6/lib/modules/extensions/libextmod.a is unresolved! Symbol FontCacheGetStatistics from module /usr/X11R6/lib/modules/extensions/libextmod.a is unresolved! Symbol FontCacheGetSettings from module /usr/X11R6/lib/modules/extensions/libextmod.a is unresolved! Symbol FontCacheCloseCache from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheSearchEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheGetEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheInsertEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheGetEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheOpenCache from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheSearchEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheGetBitmap from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol FontCacheSearchEntry from module /usr/X11R6/lib/modules/fonts/libxtt.a is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol fbOverlayGetScreenPrivateIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol XAAGetScreenIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP_PM from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol XAAGetScreenIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP_PM from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Symbol XAAGetScreenIndex from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Required symbol XAAGetCopyROP from module /usr/X11R6/lib/modules/drivers/savage_drv.o is unresolved! Fatal server error: Some required symbols were unresolved Maybe you can provide us some binary modules with the Xorg snapshot (libextmod and libxtt). Thanks --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Kernel Oopses in recent DRMs
Thomas Hellstrom wrote:
Hi, Jon!
Jon Smirl wrote:
This should fix it. I'm I'll check it in after I reboot and test it.
It didn't occur to me that DRM(global) could be freed while the loop
is in progress.
I need to remember to keep testing everything with framebuffer loaded
and again without it loaded.
[EMAIL PROTECTED] drm-bk]$ bk -r diffs -u
= linux/drm_drv.h 1.21 vs edited =
--- 1.21/linux/drm_drv.h2004-09-21 20:29:48 -04:00
+++ edited/linux/drm_drv.h 2004-10-06 19:56:06 -04:00
@@ -664,7 +664,7 @@
DRM_DEBUG( \n );
if (DRM(fb_loaded)) {
if (DRM(global)) {
- for (i = 0; i DRM(global)-cards_limit; i++) {
+ for (i = 0; DRM(global) (i
DRM(global)-cards_limit); i++) {
minor = DRM(global)-minors[i];
dev = minor-dev;
DRM_DEBUG(fb loaded release minor
%d\n, dev-minor);
Not that it usually happens in practice, but isn't it perfectly valid
for a C compiler evaluating
A B
to evaluate B first and then A, or am I not keeping up with the C
standard changes?
Had some crashes on Irix back in the early 90's related to this :)
Short circuit evaluation rules apply. A will be evaluated first; if it
is false, B will not be evaluated.
Hope this clears things up.
David Bronaugh
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage test notes/glDrawPixels problem
El Miércoles, 6 de Octubre del 2004 2:44 PM, Alex Deucher escribió: On Wed, 6 Oct 2004 13:16:38 +0200, David [EMAIL PROTECTED] wrote: The drawpix demo is working for me (I have a Savage4). Hope it helps. Is it working for you with or without the change I mentioned? Thanks, Alex It is working without that change (I haven't tested the new commits). Sorry to be so brief, but I hadn't much time those days. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: savage test notes/glDrawPixels problem
On Wed, 29 Sep 2004 13:16:44 -0500, Steve Holland [EMAIL PROTECTED] wrote: - My previously reported problem with glDrawPixels is still happens. Card is S3 Inc. SuperSavage IX/C SDR (rev 05) on ThinkPad T23. The problem seems to be that glDrawPixels doesn't work to the back buffer. For example, the 'drawpix' demo shows blackness until the 'f' key is pressed to switch drawing to the front buffer. Drawpix works normally when LIBGL_ALWAYS_INDIRECT is set. On Tue, 5 Oct 2004 15:07:22 -0400, Alex Deucher [EMAIL PROTECTED] wrote: I think I tracked this down. On supersavages (I don't know about other savage4 based chips, I'll test it out tonight if I get a chance) you need to shift the framebuffer offset passed to the tiled surface registers by 6 rather than 5 (in savage_dri.c): The drawpix demo is working for me (I have a Savage4). Hope it helps. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Compiling Snapshots for 2.6
Last snapshots for r200 don't compile on 2.6 I didnt check CVS, but from what i've read , it seems there are now two separate branches ( for 2.4 and 2.6) 2.6 branch does not appear in snapshots. Is it only temporary ? Will I have to compile from CVS ? I have limited resources ( proc-mem-space) and the whole cx tree is a pain to compile. --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: compiling mach64 kernel module for 2.6.9-rc-mm4 kernel
El Miércoles, 29 de Septiembre del 2004 3:20 AM, Jon Smirl escribió: Get the code from here: cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvs/dri co drm and build in the linux-2.6 directory. It looks like you are missing drm_sysfs.h which is is the CVS repository. I'm building mach64 from CVS on my machine without problems on current linus-bk. There files should be in the linux-2.6 directory: [EMAIL PROTECTED] linux-2.6]$ ls CVS drm_core.h drm_sysfs.h Makefile Makefile.kernel radeon_i2c.c radeon_i2c.h README [EMAIL PROTECTED] linux-2.6]$ Only the 2.4 DRM will build from linux directory, you have to use linux-2.6 Same problem. Your solution works. Seems that snapshots are taken from the linux directory. Somebody should make a workaround to let the users (like me) download a snapshot an install without more complications. On Wed, 29 Sep 2004 03:44:07 +0200, Micha Feigin [EMAIL PROTECTED] wrote: I am trying to compile the mach64 drm kernel module for kernel 2.6.9-rc2-mm4 from latest cvs as the code from the mach64 tree from January is regrettably no longer compiling for me, too many changes to the drm code in the kernel apparently (mostly problems with drmP.h). Anyway, I downloaded the latest cvs from freedesktop.org according to the instructions on the site (it said something about a move of some of the cvs code, but didn't seem related to drm). When I tried to compile it, it gave the following warnings about missing symbols and then the driver won't load for the same reason: *** Warning: mach64_sysfs_device_add [/home/micha/dev/dri/new/drm/linux/mach64.ko] undefined! *** Warning: remap_page_range [/home/micha/dev/dri/new/drm/linux/mach64.ko] undefined! *** Warning: mach64_sysfs_device_remove [/home/micha/dev/dri/new/drm/linux/mach64.ko] undefined! *** Warning: mach64_sysfs_create [/home/micha/dev/dri/new/drm/linux/mach64.ko] undefined! *** Warning: mach64_sysfs_destroy [/home/micha/dev/dri/new/drm/linux/mach64.ko] undefined! Is the tree supposed to compile now, which one if so and where am I going wrong. If not, is there a tag/date thats known to work that I can use (I could really use the little acceleration drm gives me for the matlab work I do. Not much 3D, but enough to be intolerable without drm support). Thanks --- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
