Re: radeon kms on ppc status
On Tue, 2010-08-10 at 14:56 +0200, Michel Dänzer wrote: On Mon, 2010-08-09 at 16:16 +1000, Benjamin Herrenschmidt wrote: I'm currently testing on a rv350 based aluminium powerbooks. Same here. :) Heh. Well, I also have the G5 with rv350, and that has a serial port :-) - AGP: locks up before the console shows anything useful, that's going to be fun to debug without a serial port ... I'll see what I can with netconsole or some firewire hack. Works fine with PCI GART. AGP 1x works mostly fine for me. Not sure what the problem is with higher speeds (4x used to work fine with UMS) but I guess most likely some kind of coherency issue which only matters now that we're dynamically changing GTT bindings. Ok. Well, we -know- we have a problem with AGP anyways bcs of that dual cachable/non-cachable mapping issue. I'll see if I can find ways to work around that. If not, I don't really mind sticking to x1, it's old machines and it's better than nothing. The reason you don't get anything useful with higher AGP speeds is that the attempt to reset the locked-up GPU kills the machine. I tried tracking this down with netconsole but the only possibly relevant info I've got out of that yet is that there seem to be some machine checks occurring. Right, makes sense if the card doesn't answer to an MMIO access. I'll see what I can do. - transition from offb. If both kms and offb are built-in, the transition leads to panel blooming. I only tried this once but AFAIR it was the same for me. I found some stuff there and fixed some on the G5. It now works there, I haven't tried again on the powerbook yet. One is the patch I send to do an early transition like nouveau does. The other one is you need to make sure CONFIG_VT_HW_CONSOLE_BINDING is set. Without that, unregister_framebuffer() of offb fails bcs fbcon refuses to unbind the last console. So you end up with fb1 for the drm, while fb0 remains on offb and everything breaks. We might want to make this a hard dependency. - The other fancy stuff... well, we could make up profiles on powerbooks I suppose, at least dynclk can be enable always and I'm sure we can make up default profiles with something like half clock speed, what do you reckon ? Might be nice, though IME the CPU seems to suck more power anyway. :) Right. IMO the highest priority missing feature is backlight control, followed by suspend/resume. Agreed. Note that there's also still outstanding KMS related endianness issues in the Mesa tree, in particular concerning r300g but also the classic driver related to the OpenGL blit functionality. I've been meaning to clean up and push my hacks for those but had little time recently. Ok. I'll leave you to those because I really know near to nothing about GL and Mesa ... from my quick tests, things seem to work allright with compiz on the G5 and the powerbook tho with whatever Mesa's in lucid. Also, the few tests I did on the quad G5 with nvidia 6600 nouveau were interesting as well (gallium in that case). nouveau itself works well, but the mesa part doesn't (renders black). The interesting thing tho was that all the SW rendering path seemed to work well, which is a nice change from not that long ago where all the fallbacks were endian broken. I suspect you may have done some fixing there :-) Cheers, Ben. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon kms on ppc status
Just a quick status in case others are interested and want to help as I have -very- little time. I'm currently testing on a rv350 based aluminium powerbooks. The basic stuff works provided you stay away from AGP. Here's things in no special order I noticed: - AGP: locks up before the console shows anything useful, that's going to be fun to debug without a serial port ... I'll see what I can with netconsole or some firewire hack. Works fine with PCI GART. - transition from offb. If both kms and offb are built-in, the transition leads to panel blooming. Note that it seems broken with nouveau on the G5 as well, I suspect we are passing a crap mode when picking up from offb at boot. - Power Management. - Sleep/wakeup needs to be ported over from radeonfb (will also be useful for some x86 models). - The other fancy stuff... well, we could make up profiles on powerbooks I suppose, at least dynclk can be enable always and I'm sure we can make up default profiles with something like half clock speed, what do you reckon ? Cheers, Ben. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon: Add probing of clocks from device-tree
When we find no ROM we understand and a device-tree is present, see
if we can retreive clock info from there.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/gpu/drm/radeon/radeon_clocks.c | 81
1 files changed, 81 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_clocks.c
b/drivers/gpu/drm/radeon/radeon_clocks.c
index f64936c..14448a7 100644
--- a/drivers/gpu/drm/radeon/radeon_clocks.c
+++ b/drivers/gpu/drm/radeon/radeon_clocks.c
@@ -91,6 +91,85 @@ uint32_t radeon_legacy_get_memory_clock(struct radeon_device
*rdev)
return mclk;
}
+#ifdef CONFIG_OF
+/*
+ * Read XTAL (ref clock), SCLK and MCLK from Open Firmware device
+ * tree. Hopefully, ATI OF driver is kind enough to fill these
+ */
+static bool __devinit radeon_read_clocks_OF(struct drm_device *dev)
+{
+ struct radeon_device *rdev = dev-dev_private;
+ struct device_node *dp = rdev-pdev-dev.of_node;
+ const u32 *val;
+ struct radeon_pll *p1pll = rdev-clock.p1pll;
+ struct radeon_pll *p2pll = rdev-clock.p2pll;
+ struct radeon_pll *spll = rdev-clock.spll;
+ struct radeon_pll *mpll = rdev-clock.mpll;
+
+ if (dp == NULL)
+ return false;
+ val = of_get_property(dp, ATY,RefCLK, NULL);
+ if (!val || !*val) {
+ printk(KERN_WARNING radeonfb: No ATY,RefCLK property !\n);
+ return false;
+ }
+ p1pll-reference_freq = p2pll-reference_freq = (*val) / 10;
+ p1pll-reference_div = RREG32_PLL(RADEON_PPLL_REF_DIV) 0x3ff;
+ if (p1pll-reference_div 2)
+ p1pll-reference_div = 12;
+ p2pll-reference_div = p1pll-reference_div;
+
+ /* These aren't in the device-tree */
+ if (rdev-family = CHIP_R420) {
+ p1pll-pll_in_min = 100;
+ p1pll-pll_in_max = 1350;
+ p1pll-pll_out_min = 2;
+ p1pll-pll_out_max = 5;
+ p2pll-pll_in_min = 100;
+ p2pll-pll_in_max = 1350;
+ p2pll-pll_out_min = 2;
+ p2pll-pll_out_max = 5;
+ } else {
+ p1pll-pll_in_min = 40;
+ p1pll-pll_in_max = 500;
+ p1pll-pll_out_min = 12500;
+ p1pll-pll_out_max = 35000;
+ p2pll-pll_in_min = 40;
+ p2pll-pll_in_max = 500;
+ p2pll-pll_out_min = 12500;
+ p2pll-pll_out_max = 35000;
+ }
+
+ spll-reference_freq = mpll-reference_freq = p1pll-reference_freq;
+ spll-reference_div = mpll-reference_div =
+ RREG32_PLL(RADEON_M_SPLL_REF_FB_DIV)
+ RADEON_M_SPLL_REF_DIV_MASK;
+
+ val = of_get_property(dp, ATY,SCLK, NULL);
+ if (val *val)
+ rdev-clock.default_sclk = (*val) / 10;
+ else
+ rdev-clock.default_sclk =
+ radeon_legacy_get_engine_clock(rdev);
+
+ val = of_get_property(dp, ATY,MCLK, NULL);
+ if (val *val)
+ rdev-clock.default_mclk = (*val) / 10;
+ else
+ rdev-clock.default_mclk =
+ radeon_legacy_get_memory_clock(rdev);
+
+ DRM_INFO(Using device-tree clock info\n);
+
+ return true;
+}
+#else
+static bool __devinit radeon_read_clocks_OF(struct drm_device *dev)
+{
+ return false;
+}
+#endif /* CONFIG_OF */
+
void radeon_get_clock_info(struct drm_device *dev)
{
struct radeon_device *rdev = dev-dev_private;
@@ -105,6 +184,8 @@ void radeon_get_clock_info(struct drm_device *dev)
ret = radeon_atom_get_clock_info(dev);
else
ret = radeon_combios_get_clock_info(dev);
+ if (!ret)
+ ret = radeon_read_clocks_OF(dev);
if (ret) {
if (p1pll-reference_div 2) {
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon kms on ppc status
On Mon, 2010-08-09 at 03:18 -0400, Alex Deucher wrote: 2010/8/9 Benjamin Herrenschmidt b...@kernel.crashing.org: Just a quick status in case others are interested and want to help as I have -very- little time. Unfortunately, I don't have much spare time to dedicate to this either and I don't have any ppc machines. I guessed :-) We'll see what we manage. - AGP: locks up before the console shows anything useful, that's going to be fun to debug without a serial port ... I'll see what I can with netconsole or some firewire hack. Works fine with PCI GART. I think Michel had it working with 1x AGP. Interesting. Michel, any idea what the problems might be ? - transition from offb. If both kms and offb are built-in, the transition leads to panel blooming. Note that it seems broken with nouveau on the G5 as well, I suspect we are passing a crap mode when picking up from offb at boot. - Power Management. - Sleep/wakeup needs to be ported over from radeonfb (will also be useful for some x86 models). It would be nice to get this ported over. Most definitely. I'm still getting my head around the KMS driver structure. - The other fancy stuff... well, we could make up profiles on powerbooks I suppose, at least dynclk can be enable always and I'm sure we can make up default profiles with something like half clock speed, what do you reckon ? The dynclks in the drm should work on the ppc. As for the power profiles, something like a half clock should work. Ok. Here too, trying to sort out what the driver is doing for now, and we'll move from there. Probably also useful to come up with some way to add backlight control to the macs without conflicting with the acpi backlight stuff on x86. Yup, forgot about that one. Shouldn't be -too- hard. Cheers, Ben. Alex -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon kms on ppc status
- transition from offb. If both kms and offb are built-in, the transition leads to panel blooming. Note that it seems broken with nouveau on the G5 as well, I suspect we are passing a crap mode when picking up from offb at boot. wierd offb-nouveau worked on my G5, handoff doesn't do anything technically other than just remove offb from the system, and start the driver, so it should be like setting an initial mode. Unless the newer early handover messed it up. Yeah, not sure what's up, I suspect the driver get passed a bogus mode in the initial set_par() when doing the handover. I'll see what I can find out once I dig out my dual G5 which has a serial port :-) - Power Management. - Sleep/wakeup needs to be ported over from radeonfb (will also be useful for some x86 models). I've started to port this on the M7 in a thinkpad on my desk, in theory it should save battery life as it appears currently the GPU doesn't go into D3 properly, however I haven't figured out exactly which bits are required, or proven its saving battery (the battery is a little old so I can't be sure). Ok. So there's basically two different things in that code. Merely D2 sleep and re-POST (aka D3 cold). The former is supported on M6, M7 and M9 (at least some of these, the code might need tweaks to work on non-powerbooks). In this case, we are dealing with cases where the chip isn't powered down by the motherboard or firmware. I don't actually know for sure -what- happens to it on the relevant powerbooks actually, I suspect the clocks might go off, and/or the VRAM is off. IE. If I don't run that code, I don't come back. The code was essentially contributed by ATI btw. Then there's code for M10/M11 which re-POSTs the chip. It mostly relies on saving as much registers as can be and restoring things in the right order, along with the right magic to restart PLLs, MC, DLLs, ... This code was written after analyzing the MacOS driver IO traces. Some parts however cannot be saved/restored (memory init sequence), so in that case, I have a default sequence, and I have code to retreive a different one from the OF device-tree when available. For that code to work more generically/better on x86's, we might want to add code to extract that from the BIOS tables. Now, I need to figure out how to make all this fit in our driver architecture. Dave, can I see your patches ? That might give me some good hints to get started. Hopefully, most of that can be kept safely in the r100 files and we can avoid clobbering too much of the core drivers. Cheers, Ben. Dave. -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon: Fix pci_map_page() error checking
0 is a valid DMA address from pci_map_page(), use pci_dma_mapping_error()
instead to check for errors
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/gpu/drm/radeon/radeon_device.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 6c95dcf..83024e8 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -347,7 +347,8 @@ int radeon_dummy_page_init(struct radeon_device *rdev)
return -ENOMEM;
rdev-dummy_page.addr = pci_map_page(rdev-pdev, rdev-dummy_page.page,
0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
- if (!rdev-dummy_page.addr) {
+ if (pci_dma_mapping_error(rdev-pdev, rdev-dummy_page.addr)) {
+ dev_err(rdev-pdev, Failed to DMA MAP the dummy page\n);
__free_page(rdev-dummy_page.page);
rdev-dummy_page.page = NULL;
return -ENOMEM;
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] libdrm: Fix PCI domain domain support
This works in conjunction with newer kernels. If we succeed in requesting
interface 1.4, the we know the kernel provides proper domain numbers. If
not, ignore the domain number as it's bogus (except on Alpha).
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
xf86drm.c | 30 +-
1 files changed, 25 insertions(+), 5 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 220aaa1..cb0c3a3 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -229,7 +229,7 @@ drmHashEntry *drmGetEntry(int fd)
* PCI:b:d:f format and the newer pci::bb:dd.f format. In the format, o is
* domain, b is bus, d is device, f is function.
*/
-static int drmMatchBusID(const char *id1, const char *id2)
+static int drmMatchBusID(const char *id1, const char *id2, int pci_domain_ok)
{
/* First, check if the IDs are exactly the same */
if (strcasecmp(id1, id2) == 0)
@@ -257,6 +257,13 @@ static int drmMatchBusID(const char *id1, const char *id2)
return 0;
}
+ /* If domains aren't properly supported by the kernel interface,
+* just ignore them, which sucks less than picking a totally random
+* card with open by name
+*/
+ if (!pci_domain_ok)
+ o1 = o2 = 0;
+
if ((o1 != o2) || (b1 != b2) || (d1 != d2) || (f1 != f2))
return 0;
else
@@ -482,7 +489,7 @@ int drmAvailable(void)
*/
static int drmOpenByBusid(const char *busid)
{
-inti;
+inti, pci_domain_ok = 1;
intfd;
const char *buf;
drmSetVersion sv;
@@ -492,14 +499,27 @@ static int drmOpenByBusid(const char *busid)
fd = drmOpenMinor(i, 1, DRM_NODE_RENDER);
drmMsg(drmOpenByBusid: drmOpenMinor returns %d\n, fd);
if (fd = 0) {
+ /* We need to try for 1.4 first for proper PCI domain support
+* and if that fails, we know the kernel is busted
+*/
sv.drm_di_major = 1;
- sv.drm_di_minor = 1;
+ sv.drm_di_minor = 4;
sv.drm_dd_major = -1; /* Don't care */
sv.drm_dd_minor = -1; /* Don't care */
- drmSetInterfaceVersion(fd, sv);
+ if (drmSetInterfaceVersion(fd, sv)) {
+#ifndef __alpha__
+ pci_domain_ok = 0;
+#endif
+ sv.drm_di_major = 1;
+ sv.drm_di_minor = 1;
+ sv.drm_dd_major = -1; /* Don't care */
+ sv.drm_dd_minor = -1; /* Don't care */
+ drmMsg(drmOpenByBusid: Interface 1.4 failed,trying 1.1\n, fd);
+ drmSetInterfaceVersion(fd, sv);
+ }
buf = drmGetBusid(fd);
drmMsg(drmOpenByBusid: drmGetBusid reports %s\n, buf);
- if (buf drmMatchBusID(buf, busid)) {
+ if (buf drmMatchBusID(buf, busid, pci_domain_ok)) {
drmFreeBusid(buf);
return fd;
}
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: Fix support for PCI domains
(For some reason I thought that went in ages ago ...)
This fixes support for PCI domains in what should hopefully be a backward
compatible way along with a change to libdrm.
When the interface version is set to 1.4, we assume userspace understands
domains and the world is at peace. We thus pass proper domain numbers
instead of 0 to userspace.
The newer libdrm will then try 1.4 first, and fallback to 1.1, along with
ignoring domains in the later case (well, except on alpha of course)
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/gpu/drm/drm_ioctl.c |1 +
include/drm/drmP.h | 18 +-
include/drm/drm_core.h |2 +-
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 9b9ff46..d7b2bd6 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -322,6 +322,7 @@ int drm_setversion(struct drm_device *dev, void *data,
struct drm_file *file_pri
if (sv-drm_di_minor = 1) {
/*
* Version 1.1 includes tying of DRM to specific device
+* Version 1.4 has proper PCI domain support
*/
drm_set_busid(dev, file_priv);
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c1b9871..6d4bad5 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1071,11 +1071,19 @@ static __inline__ int drm_core_check_feature(struct
drm_device *dev,
return ((dev-driver-driver_features feature) ? 1 : 0);
}
-#ifdef __alpha__
-#define drm_get_pci_domain(dev) dev-hose-index
-#else
-#define drm_get_pci_domain(dev) 0
-#endif
+static inline int drm_get_pci_domain(struct drm_device *dev)
+{
+#ifndef __alpha__
+ /* For historical reasons, drm_get_pci_domain() is busticated
+* on most archs and has to remain so for userspace interface
+* 1.4, except on alpha which was right from the beginning
+*/
+ if (dev-if_version 0x10004)
+ return 0;
+#endif /* __alpha__ */
+
+ return pci_domain_nr(dev-pdev-bus);
+}
#if __OS_HAS_AGP
static inline int drm_core_has_AGP(struct drm_device *dev)
diff --git a/include/drm/drm_core.h b/include/drm/drm_core.h
index 3167390..4e75238 100644
--- a/include/drm/drm_core.h
+++ b/include/drm/drm_core.h
@@ -27,7 +27,7 @@
#define CORE_DATE 20060810
#define DRM_IF_MAJOR 1
-#define DRM_IF_MINOR 3
+#define DRM_IF_MINOR 4
#define CORE_MAJOR 1
#define CORE_MINOR 1
--
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm nouveau pony for Xmas.
On Mon, 2009-12-14 at 14:35 +1100, Benjamin Herrenschmidt wrote: And built-in works beautifully with kms fbdev on top of it etc... (real fast console switches ! yay !) if I do CONFIG_EXTRA_FIRMWARE_DIR=/lib/firmware CONFIG_EXTRA_FIRMWARE=/nouveau/xxx.ctxprog nouveau/yyy.ctxvals ^ Without that / of course :-) Cheers, Ben. -- 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: [git pull] drm nouveau pony for Xmas.
On Fri, 2009-12-11 at 15:19 -0800, Linus Torvalds wrote: On Fri, 11 Dec 2009, Dave Airlie wrote: Please pull the 'drm-nouveau-pony' branch from PONIES! Yay! I lurve ponies! And it works for me too. Needed to get the firmware from the fedora project, and make sure that it loads as a module rather than built in (so that it can find the firmware!), but other than those two gotchas (that are obvious, but I needed to fail a couple of boots to hammer the point home) it all seems to work. Thank you. The squeaky wheel _does_ get greased. And built-in works beautifully with kms fbdev on top of it etc... (real fast console switches ! yay !) if I do CONFIG_EXTRA_FIRMWARE_DIR=/lib/firmware CONFIG_EXTRA_FIRMWARE=/nouveau/xxx.ctxprog nouveau/yyy.ctxvals Where xxx and yyy need to be replaced by whatever is relevant to your hardware. (In my case nv43. BTW. For the lurkers, it works fine with the 6600 in the PowerMac G5 with an endian fix to the new loader that I just posted to the nouveau list and which should trickle upstream soon). Cheers, Ben. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] vga: implements VGA arbitration on Linux
On Tue, 2009-08-11 at 16:17 -0700, Jesse Barnes wrote: Ok, applied this to my linux-next branch, but I'd like to get Ben's s-o-b before pushing it to Linus. Well, S-O-B is if the code went through my hands... though in this case I wrote the original version so I suppose it did :-) An ack for sure. Let me have a look, I'll come back to you asap. Cheers, Ben. -- 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: [PATCH] vga: implements VGA arbitration on Linux
On Tue, 2009-08-11 at 15:52 +1000, Dave Airlie wrote:
From: Tiago Vignatti tiago.vigna...@nokia.com
Background:
Graphic devices are accessed through ranges in I/O or memory space. While most
modern devices allow relocation of such ranges, some Legacy VGA devices
implemented on PCI will typically have the same hard-decoded addresses as
they did on ISA. For more details see PCI Bus Binding to IEEE Std 1275-1994
Standard for Boot (Initialization Configuration) Firmware Revision 2.1
Section 7, Legacy Devices.
The Resource Access Control (RAC) module inside the X server currently does
the task of arbitration when more than one legacy device co-exists on the same
machine. But the problem happens when these devices are trying to be accessed
by different userspace clients (e.g. two server in parallel). Their address
assignments conflict. Therefore an arbitration scheme _outside_ of the X
server is needed to control the sharing of these resources. This document
introduces the operation of the VGA arbiter implemented for Linux kernel.
Signed-off-by: Tiago Vignatti tiago.vigna...@nokia.com
Signed-off-by: Dave Airlie airl...@redhat.com
Well, since I wrote a god deal of it:
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
Note that I do believe we still have some kind of race vs. the default
VGA device going away but it's rather minor, something to fix at some
stase though.
---
drivers/gpu/Makefile |2 +-
drivers/gpu/vga/Kconfig | 10 +
drivers/gpu/vga/Makefile |1 +
drivers/gpu/vga/vgaarb.c | 1206
++
drivers/pci/pci.c| 44 ++
drivers/video/Kconfig|2 +
include/linux/pci.h |2 +
include/linux/vgaarb.h | 195
8 files changed, 1461 insertions(+), 1 deletions(-)
create mode 100644 drivers/gpu/vga/Kconfig
create mode 100644 drivers/gpu/vga/Makefile
create mode 100644 drivers/gpu/vga/vgaarb.c
create mode 100644 include/linux/vgaarb.h
diff --git a/drivers/gpu/Makefile b/drivers/gpu/Makefile
index de566cf..30879df 100644
--- a/drivers/gpu/Makefile
+++ b/drivers/gpu/Makefile
@@ -1 +1 @@
-obj-y+= drm/
+obj-y+= drm/ vga/
diff --git a/drivers/gpu/vga/Kconfig b/drivers/gpu/vga/Kconfig
new file mode 100644
index 000..790e675
--- /dev/null
+++ b/drivers/gpu/vga/Kconfig
@@ -0,0 +1,10 @@
+config VGA_ARB
+ bool VGA Arbitration if EMBEDDED
+ default y
+ depends on PCI
+ help
+ Some legacy VGA devices implemented on PCI typically have the same
+ hard-decoded addresses as they did on ISA. When multiple PCI devices
+ are accessed at same time they need some kind of coordination. Please
+ see Documentation/vgaarbiter.txt for more details. Select this to
+ enable VGA arbiter.
diff --git a/drivers/gpu/vga/Makefile b/drivers/gpu/vga/Makefile
new file mode 100644
index 000..7cc8c1e
--- /dev/null
+++ b/drivers/gpu/vga/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_VGA_ARB) += vgaarb.o
diff --git a/drivers/gpu/vga/vgaarb.c b/drivers/gpu/vga/vgaarb.c
new file mode 100644
index 000..199138f
--- /dev/null
+++ b/drivers/gpu/vga/vgaarb.c
@@ -0,0 +1,1206 @@
+/*
+ * vgaarb.c
+ *
+ * (C) Copyright 2005 Benjamin Herrenschmidt b...@kernel.crashing.org
+ * (C) Copyright 2007 Paulo R. Zanoni przan...@gmail.com
+ * (C) Copyright 2007, 2009 Tiago Vignatti vigna...@freedesktop.org
+ *
+ * Implements the VGA arbitration. For details refer to
+ * Documentation/vgaarbiter.txt
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/pci.h
+#include linux/errno.h
+#include linux/init.h
+#include linux/list.h
+#include linux/sched.h
+#include linux/wait.h
+#include linux/spinlock.h
+#include linux/poll.h
+#include linux/miscdevice.h
+
+#include linux/uaccess.h
+
+#include linux/vgaarb.h
+
+static void vga_arbiter_notify_clients(void);
+/*
+ * We keep a list of all vga devices in the system to speed
+ * up the various operations of the arbiter
+ */
+struct vga_device {
+ struct list_head list;
+ struct pci_dev *pdev;
+ unsigned int decodes; /* what does it decodes */
+ unsigned int owns; /* what does it owns */
+ unsigned int locks; /* what does it locks */
+ unsigned int io_lock_cnt; /* legacy IO lock count */
+ unsigned int mem_lock_cnt; /* legacy MEM lock count */
+ unsigned int io_norm_cnt; /* normal IO count */
+ unsigned int mem_norm_cnt; /* normal MEM count */
+
+ /* allow IRQ enable/disable hook */
+ void *cookie;
+ void (*irq_set_state)(void *cookie, bool enable);
+ unsigned int (*set_vga_decode)(void *cookie, bool decode);
+};
+
+static LIST_HEAD(vga_list);
+static int vga_count, vga_decode_count;
+static bool vga_arbiter_used;
+static DEFINE_SPINLOCK(vga_lock);
+static DECLARE_WAIT_QUEUE_HEAD(vga_wait_queue
Re: [git pull] drm: previous pull req + 1.
On Mon, 2009-06-22 at 17:24 -0700, Linus Torvalds wrote: On Tue, 23 Jun 2009, Benjamin Herrenschmidt wrote: As far as I can remember, all fbdev operations are done under the console semaphore. Yeah, and some of them are horribly broken (ie copying data from user space while doing it - causing horrible things like VC switching latencies and invisible printk's if an oops happens during the op). Or maybe that got fixed. Well, it does rely on userspace behaving.. ie, no accel ops are done by the kernel in KD_GRAPHICS and userspace is -supposed- to switch to KD_GRAPHICS before touching the fb. In fact, nowdays, we do have the infrastructure to be smart and enforce that. IE. Instead of using a boring remap_page_ranges() in fb_mmap() we could use a fault handler. When in KD_TEXT, we fail them, when in KD_GRAPHICS, we service them, and we unmap_mapping_range() when switching. Something like that... Dunno how that interacts with the new DRM thingy though. Cheers, Ben. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm: previous pull req + 1.
On Mon, 2009-06-22 at 11:22 -0700, Linus Torvalds wrote: Not going to happen. Why? 'printk'. If you can't handle printk, then you're basically useless. And printk absolutely -has- to work in bad situations (the most important messages could happen in any context). Well... yes and no. If X is frontmost, printk is not going to be printed, ie, I'm talking about today, when the console is !KD_TEXT. There -is- a mechanism to deal with these things today, and the console semaphore does take care of accesses to the fb. (That doesn't exclude having the ability to force-switch back to kernel fb for printing things like oops btw, which KMS could do, but for basic access control, it makes sense). Cheers, Ben. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm: previous pull req + 1.
On Mon, 2009-06-22 at 18:18 -0700, Jesse Barnes wrote: I think it could work, but ideally we'd keep the kernel fbcon object pinned, and keep printing into it even while some other gfx app is running. That way we don't have to dump the whole queue into it when a panic occurs, we can just switch buffers (something like this would also be handy for dual head debugging; one head running your desktop and the other a debug console printing all the messages). That's slightly more invasive surgery though... I should have a chance to do something like that as part of the kdb/kms work I'll be doing with Jason. Do we really need that ? We can easily repaint (ie, regenerate the fb content from the pseudo vgacon image kept by the console layer). So if we want the kernel to take over, it's reasonably easy to make it also repaint the content of the fb. How, of course, kicking out usespace with unmap_mapping_ranges() isn't going to work well from an oops or something at interrupt time, we do need to have a reasonably safe path for these things, which is why I believe that sort of emergency printing should be done without any acceleration, just basic manual painting in the front buffer... Should we even bother changing the mode ? Not sure... Cheers, Ben. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm: previous pull req + 1.
On Mon, 2009-06-22 at 19:07 -0700, Jesse Barnes wrote: Yeah I don't think we should try to change the mode, unless we really have to for whatever reason. fbcon should generally be able to paint to whatever we have up as long as we set it up properly. Well... it may not. IE. The text consoles can be using a different mode than X, and so fbcon will be all setup for that ... (including how many lines/columns etc...). So it's not totally trivial... but on the other hands, it would be useful to avoid as much as possible complicated things like mode switches when hitting an oops. Cheers, Ben. -- Are you an open source citizen? Join us for the Open Source Bridge conference! Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250. Need another reason to go? 24-hour hacker lounge. Register today! http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: Round size of mappings in drmAddMap ioctl
Currently, userspace fails to obtain the SAREA mapping on some platforms because they pass SAREA_MAX to drmAddMap without aligning it to the page size. This breaks for example on PowerPC with 64K pages. The way SAREA_MAX is defined with a bunch of ifdef's and duplicated between libdrm and the X server is gross, ultimately it should be retrieved by userspace from the kernel, but in the meantime, we have plenty of existing userspace built with bad values that need to work. The actual SAREA in the kernel is created with an aligned size by the radeon driver (I haven't tested others) so it's purely a userspace problem. This works around it by rounding the requested size in drmAddMap to the page size. There should never be any need to manipulate maps smaller than a page (MMIO regions might but there isn't much we can do about it) and our mmap() calls has enough sanity checks here if the map is actually too small to be mapped. We also only do that fir the ioctl, not the in-kernel call. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- This fixes DRM with 16K and 64K pages on PowerPC embedded machines. Dunno if you want that in 2.6.30, I would personally like that but I'm not going to force your hand :-) Cheers, Ben. Index: linux-work/drivers/gpu/drm/drm_bufs.c === --- linux-work.orig/drivers/gpu/drm/drm_bufs.c 2009-05-18 10:50:04.0 +1000 +++ linux-work/drivers/gpu/drm/drm_bufs.c 2009-05-18 10:51:01.0 +1000 @@ -404,6 +404,8 @@ int drm_addmap_ioctl(struct drm_device * if (!(capable(CAP_SYS_ADMIN) || map-type == _DRM_AGP || map-type == _DRM_SHM)) return -EPERM; + /* Workaround for userspace passing smaller than page size quantities */ + map-size = PAGE_ALIGN(map-size); err = drm_addmap_core(dev, map-offset, map-size, map-type, map-flags, maplist); -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: Round size of SHM maps to PAGE_SIZE
Currently, userspace fail to obtain the SAREA mapping (among others) because
they pass SAREA_MAX to drmAddMap without aligning it to the page size. This
breaks for example on PowerPC with 64K pages and radeon despite the kernel
radeon actually doing the right rouding in the first place.
The way SAREA_MAX is defined with a bunch of ifdef's and duplicated between
libdrm and the X server is gross, ultimately it should be retrieved by
userspace from the kernel, but in the meantime, we have plenty of existing
userspace built with bad values that need to work.
This works around it by rounding the requested size in drm_addmap_core() of
any SHM map to the page size. Since those maps backing memory is allocated
within addmap_core, there is no security issue involved, the only side effect
is that drivers that previous tries to create or access SHM maps using
a size PAGE_SIZE and would have failed (-EINVAL) will no succeed at the
cost of a little bit more memory used if that happens to be when the map is
created.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
That replaces my previous attempt. This is safer and cleaner and still
fixes the radeon problem. Other drivers having other type of maps with
incorrect sizes will need proper fixes but they did anyway.
Index: linux-work/drivers/gpu/drm/drm_bufs.c
===
--- linux-work.orig/drivers/gpu/drm/drm_bufs.c 2009-05-18 10:50:04.0
+1000
+++ linux-work/drivers/gpu/drm/drm_bufs.c 2009-05-18 11:47:25.0
+1000
@@ -170,6 +170,14 @@ static int drm_addmap_core(struct drm_de
}
DRM_DEBUG(offset = 0x%08llx, size = 0x%08lx, type = %d\n,
(unsigned long long)map-offset, map-size, map-type);
+
+ /* page-align _DRM_SHM maps. They are allocated here so there is no
security
+* hole created by that and it works around various broken drivers that
use
+* a non-aligned quantity to map the SAREA. --BenH
+*/
+ if (map-type == _DRM_SHM)
+ map-size = PAGE_ALIGN(map-size);
+
if ((map-offset (~(resource_size_t)PAGE_MASK)) || (map-size
(~PAGE_MASK))) {
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
return -EINVAL;
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unlimited royalty-free distribution of the report engine
for externally facing server and web deployment.
http://p.sf.net/sfu/businessobjects
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Round size of mappings in drmAddMap ioctl
So, in order to fix a problem with the SAREA you align the map size for all added maps? Sounds bogus to me, especially since the range of possible page sizes is potentially unbounded. Only the requested size from userspace, most drivers create the map from the kernel anyway. IMO the proper thing to do is to fix the drivers when they create the SAREA... The SAREA, in my case (radeon) is -already- created with the proper size, it's userspace making use of the bogus SAREA_MAX constant that gets it wrong and fails to map it. However, after our IRC discussion, I'll post a different patch that we agreed provides a better and safer workaround. Jesse, ignore that patch for now, new one on the cookpot. Cheers, Ben. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI page size problem
On Fri, 2009-05-15 at 14:46 +1000, Benjamin Herrenschmidt wrote: Hi Jesse ! Haven't had much time to investigate the problem I've been talking to you and David about but from what I can see in the code, we're probably hitting this in drm_mmap_locked() in drm_vm.c : /* Check for valid size. */ if (map-size vma-vm_end - vma-vm_start) return -EINVAL; Now, this won't do any good for example if the SAREA is 8K (which I think is about that nowadays) and the machine PAGE_SIZE is 64K. Except that radeon_cp.c does: sareapage = max_t(unsigned long, SAREA_MAX, PAGE_SIZE); ret = drm_addmap(dev, 0, sareapage, _DRM_SHM, _DRM_CONTAINS_LOCK|_DRM_DRIVER, master_priv-sarea); So it should have worked ... hrm I'll dig more. Cheers, Ben. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI page size problem
Hi Jesse ! Haven't had much time to investigate the problem I've been talking to you and David about but from what I can see in the code, we're probably hitting this in drm_mmap_locked() in drm_vm.c : /* Check for valid size. */ if (map-size vma-vm_end - vma-vm_start) return -EINVAL; Now, this won't do any good for example if the SAREA is 8K (which I think is about that nowadays) and the machine PAGE_SIZE is 64K. There is indeed a possible problem of allowing clients to map more than the resource specifically specified in the map, so just removing that test may not be the best approach though. I would suggest maybe bumping the SAREA to be a multiple of the page size for now. I think that should get us going. I'll have a go at a patch on monday unless there's an objection. That won't help for things like MMIO register space that isn't a multiple of the page size but fortunately that won't be hitting my with radeon for now and we can deal with that when we need to. Any objection ? Cheers, Ben. -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm: Only use DRM_IOCTL_UPDATE_DRAW compat wrapper for compat X86.
On Wed, 2009-02-18 at 01:35 -0800, David Miller wrote:
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.
Heh, quite possibly
Could that be related to the kernel spewing a bunch of
[drm:drm_update_drawable_info] *ERROR* Failed to copy cliprects from userspace
?
I've seen that yesterday on the Bimini, was planning to dig today until
I got stuck home with a cold...
Nothing in userspace checks the return value for errors, etc. :-/
Surprise !
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.
That's a nice trick, I might do something similar on power..
Cheers,
Ben.
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,
};
--
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.
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. 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 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. 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. 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 Right. That's the one I was talking about earlier. 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. Yup. 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. Yes, it's likely that they added it after being bitten on Apple or such :-) .../... 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 Either that or have the kernel do it... (ioctl's ?) which would be more in the spirit of moving toward KMS and would avoid those blunders ... That's my preferred approach. But if we want to stick to the current mess, and we have a bolted surface covering the GART, it would work fine as long as the restore path ensures the DRM restores all surfaces before it loads it back into vram, ie, same setting on save/restore, userspace doesn't have to care what the swapper actually is. 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. Preferably. Shouldn't even be hard in fact. Again, I haven't hit it on my r500 tests because I let X POST the card and basically have nothing on the VTs. I don't have a PCI-E R300 to test with, though there is -one- model of iMac G5 with such a thing, and guess what ? It's been troublesome for ages, though I never managed to get my hand on one to actually debug it. It might just all be the same issues. 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. Same as above, it should just not do it when the DRI's around. Just fire an ioctl if necessary and let the DRM do it. But if it's going to do it, bracketing it in CP stop/resume might do the trick. 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. Heh, looks like we're on the same mind set :-) Ben. -- Open Source Business Conference (OSBC),
Re: [PATCH 1/5]: drm: ati_pcigart: Do not access I/O MEM space using pointer derefs.
The only think I can think to do is use a surface instead of the aperture swappers and make the surface cover all the VRAM except the GART table which is at the end. Why not use a surface to cover the GART ? At least this would ensure a known swapper setting for it. That's interesting, it could explain why things never work again after a reset or at least proceed to hang straight away. No shit :-) Cheers, Ben. -- 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 3/5]: drm: radeon: Fix ring_rptr accesses.
On Thu, 2009-02-12 at 02:15 -0800, David Miller wrote:
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.
Similar comment about potential swapper setting when accessing the RPTR
via the framebuffer. David (Airlied), what's the current status with
that stuff ? I know you work on cleaning that shit up in kms, right now,
we'll hit the non-surface region whose setting will pretty much depend
on the fb bit depth setting...
Cheers,
Ben.
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;
Re: [PATCH 3/5]: drm: radeon: Fix ring_rptr accesses.
On Thu, 2009-02-12 at 21:37 +1100, Benjamin Herrenschmidt wrote:
Similar comment about potential swapper setting when accessing the RPTR
via the framebuffer. David (Airlied), what's the current status with
that stuff ? I know you work on cleaning that shit up in kms, right now,
we'll hit the non-surface region whose setting will pretty much depend
on the fb bit depth setting...
Forget -that- one... this is never in fb mem, I'm just tired. But the
other one about actual GART access still stand.
Cheers,
Ben.
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
Re: [PATCH 1/5]: drm: ati_pcigart: Do not access I/O MEM space using pointer derefs.
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. They leave alone the swapper of the engine, not the fb one (SURFACE_CNTL) afaik. I dbl checked the other day and it seems that we setup the GART before we whack it tho but it might be an issue in conjunction with radeonfb (ie, I don't have radeonfb on my test embedded boards as I rely on X to POST the cards using ATOMBIOS). Cheers, Ben. -- 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.
On Fri, 2009-02-13 at 08:26 +1100, Benjamin Herrenschmidt wrote: 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. They leave alone the swapper of the engine, not the fb one (SURFACE_CNTL) afaik. Though actually if you stick to 8bpp, the default, the swapper will be off in radeonfb. I dbl checked the other day and it seems that we setup the GART before we whack it tho but it might be an issue in conjunction with radeonfb (ie, I don't have radeonfb on my test embedded boards as I rely on X to POST the cards using ATOMBIOS). Cheers, Ben. -- 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: Print PCI ID of cards when probing
This is usedul when you have multiple cards to figure out which one is which minor. Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org --- drivers/gpu/drm/drm_stub.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- linux-work.orig/drivers/gpu/drm/drm_stub.c 2009-02-04 17:18:21.0 +1100 +++ linux-work/drivers/gpu/drm/drm_stub.c 2009-02-04 17:18:29.0 +1100 @@ -403,9 +403,9 @@ int drm_get_dev(struct pci_dev *pdev, co list_add_tail(dev-driver_item, driver-device_list); - DRM_INFO(Initialized %s %d.%d.%d %s on minor %d\n, + DRM_INFO(Initialized %s %d.%d.%d %s for %s on minor %d\n, driver-name, driver-major, driver-minor, driver-patchlevel, -driver-date, dev-primary-index); +driver-date, pci_name(pdev), dev-primary-index); return 0; -- 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] drm: Remove typedef drm_local_map_t
Now that linus has real separate struct drm_map and struct drm_local_map,
the drm_local_map_t typedef is gratuituous and I don't like typedefs of
structs that much so remove it.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/gpu/drm/i810/i810_drv.h |4 ++--
drivers/gpu/drm/i830/i830_drv.h |4 ++--
drivers/gpu/drm/i915/i915_drv.h |6 +++---
drivers/gpu/drm/mga/mga_drv.h | 12 ++--
drivers/gpu/drm/r128/r128_drv.h | 10 +-
drivers/gpu/drm/radeon/radeon_cp.c |2 +-
drivers/gpu/drm/radeon/radeon_drv.h | 12 ++--
drivers/gpu/drm/savage/savage_drv.h | 16
drivers/gpu/drm/sis/sis_drv.h |2 +-
drivers/gpu/drm/sis/sis_mm.c|4 ++--
drivers/gpu/drm/via/via_drv.h |8
drivers/gpu/drm/via/via_verifier.c | 11 ++-
drivers/gpu/drm/via/via_verifier.h |2 +-
include/drm/drmP.h |2 --
14 files changed, 47 insertions(+), 48 deletions(-)
--- linux-work.orig/drivers/gpu/drm/mga/mga_drv.h 2009-02-04
13:36:05.0 +1100
+++ linux-work/drivers/gpu/drm/mga/mga_drv.h2009-02-04 13:36:05.0
+1100
@@ -138,12 +138,12 @@ typedef struct drm_mga_private {
unsigned int texture_offset;
unsigned int texture_size;
- drm_local_map_t *sarea;
- drm_local_map_t *mmio;
- drm_local_map_t *status;
- drm_local_map_t *warp;
- drm_local_map_t *primary;
- drm_local_map_t *agp_textures;
+ struct drm_local_map *sarea;
+ struct drm_local_map *mmio;
+ struct drm_local_map *status;
+ struct drm_local_map *warp;
+ struct drm_local_map *primary;
+ struct drm_local_map *agp_textures;
unsigned long agp_handle;
unsigned int agp_size;
Index: linux-work/drivers/gpu/drm/r128/r128_drv.h
===
--- linux-work.orig/drivers/gpu/drm/r128/r128_drv.h 2009-02-04
13:35:45.0 +1100
+++ linux-work/drivers/gpu/drm/r128/r128_drv.h 2009-02-04 13:36:05.0
+1100
@@ -115,11 +115,11 @@ typedef struct drm_r128_private {
u32 depth_pitch_offset_c;
u32 span_pitch_offset_c;
- drm_local_map_t *sarea;
- drm_local_map_t *mmio;
- drm_local_map_t *cce_ring;
- drm_local_map_t *ring_rptr;
- drm_local_map_t *agp_textures;
+ struct drm_local_map *sarea;
+ struct drm_local_map *mmio;
+ struct drm_local_map *cce_ring;
+ struct drm_local_map *ring_rptr;
+ struct drm_local_map *agp_textures;
struct drm_ati_pcigart_info gart_info;
} drm_r128_private_t;
Index: linux-work/drivers/gpu/drm/radeon/radeon_cp.c
===
--- linux-work.orig/drivers/gpu/drm/radeon/radeon_cp.c 2009-02-04
13:36:05.0 +1100
+++ linux-work/drivers/gpu/drm/radeon/radeon_cp.c 2009-02-04
13:36:05.0 +1100
@@ -1818,7 +1818,7 @@ void radeon_master_destroy(struct drm_de
int radeon_driver_firstopen(struct drm_device *dev)
{
int ret;
- drm_local_map_t *map;
+ struct drm_local_map *map;
drm_radeon_private_t *dev_priv = dev-dev_private;
dev_priv-gart_info.table_size = RADEON_PCIGART_TABLE_SIZE;
Index: linux-work/drivers/gpu/drm/radeon/radeon_drv.h
===
--- linux-work.orig/drivers/gpu/drm/radeon/radeon_drv.h 2009-02-04
13:36:05.0 +1100
+++ linux-work/drivers/gpu/drm/radeon/radeon_drv.h 2009-02-04
13:36:05.0 +1100
@@ -227,7 +227,7 @@ struct radeon_virt_surface {
#define RADEON_PURGE_EMITED(1 1)
struct drm_radeon_master_private {
- drm_local_map_t *sarea;
+ struct drm_local_map *sarea;
drm_radeon_sarea_t *sarea_priv;
};
@@ -290,10 +290,10 @@ typedef struct drm_radeon_private {
unsigned long buffers_offset;
unsigned long gart_textures_offset;
- drm_local_map_t *sarea;
- drm_local_map_t *cp_ring;
- drm_local_map_t *ring_rptr;
- drm_local_map_t *gart_textures;
+ struct drm_local_map *sarea;
+ struct drm_local_map *cp_ring;
+ struct drm_local_map *ring_rptr;
+ struct drm_local_map *gart_textures;
struct mem_block *gart_heap;
struct mem_block *fb_heap;
@@ -320,7 +320,7 @@ typedef struct drm_radeon_private {
int num_gb_pipes;
int track_flush;
- drm_local_map_t *mmio;
+ struct drm_local_map *mmio;
} drm_radeon_private_t;
typedef struct drm_radeon_buf_priv {
Index: linux-work/drivers/gpu/drm/savage/savage_drv.h
===
--- linux-work.orig/drivers/gpu/drm/savage/savage_drv.h 2009-02-04
13:35:45.0 +1100
+++ linux-work/drivers/gpu/drm/savage/savage_drv.h 2009-02-04
13:36:05.0 +1100
@@ -151,14 +151,14 @@ typedef struct
Re: [PATCH 3/3] drm: Make drm_local_map use a resource_size_t offset
Don't worry I've applied the patches with Erics comment replacing your one. All 3 are queued in drm-next. Thanks ! I'll let you know when I finally get a chance to tackle the other issues. BTW. Do you guys want me to remove the drm_local_map_t typedef completely in favor of struct drm_local_map ? I have a patch here going part way through that, it's fairly trivial, so if you want it, I can easily finish it. Cheers, Ben. -- 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 3/3] drm: Make drm_local_map use a resource_size_t offset
Could this comment instead be maybe: Because the kernel-userspace ABI is fixed at a 32-bit offset, while PCI resources may live above that, we ignore the map offset for maps of type _DRM_FRAMEBUFFER or _DRM_REGISTERS. It is assumed that each driver will have only one resource of each type. (I want to remember later what exact ABI problem was in question) Fair enough. I'll repost. Cheers, Ben. -- 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/3] drm: Use resource_size_t for drm_get_resource_{start, len}
2009-02-02 14:16:04.0 +1100
@@ -599,8 +599,8 @@ int savage_driver_firstopen(struct drm_d
drm_mtrr_add(dev_priv-mtrr[2].base,
dev_priv-mtrr[2].size,
DRM_MTRR_WC);
} else {
- DRM_ERROR(strange pci_resource_len %08lx\n,
- drm_get_resource_len(dev, 0));
+ DRM_ERROR(strange pci_resource_len %08llx\n,
+ (unsigned long
long)drm_get_resource_len(dev, 0));
Don't we have a printk specifier for this now?
If we do I've missed it. We have a specifier for a struct resource *,
but not for an individual resource_size_t afaik.
Cheers,
Ben.
--
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/3] drm: Use resource_size_t for drm_get_resource_{start, len}
On Mon, 2009-02-02 at 11:02 -0800, Eric Anholt wrote:
On Mon, 2009-02-02 at 16:55 +1100, Benjamin Herrenschmidt wrote:
The DRM uses its own wrappers to obtain resources from PCI devices,
which currently convert the resource_size_t into an unsigned long.
This is broken on 32-bit platforms with 32-bit physical address
space.
This fixes them, along with a few occurences of unsigned long used
to store such a resource in drivers.
Do we just want to dump the wrappers, instead?
That would be an option, I wasn't sure about the consequence vs. BSD
etc... so I just fixed them...
Cheers,
Ben.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/gpu/drm/drm_bufs.c |4 ++--
drivers/gpu/drm/i915/i915_dma.c |2 +-
drivers/gpu/drm/mga/mga_drv.h |4 ++--
drivers/gpu/drm/radeon/radeon_drv.h |2 +-
drivers/gpu/drm/savage/savage_bci.c |8
include/drm/drmP.h |6 +++---
include/drm/drm_crtc.h |2 +-
7 files changed, 14 insertions(+), 14 deletions(-)
--- linux-work.orig/drivers/gpu/drm/drm_bufs.c 2009-02-02
14:11:26.0 +1100
+++ linux-work/drivers/gpu/drm/drm_bufs.c 2009-02-02 14:11:35.0
+1100
@@ -36,13 +36,13 @@
#include linux/vmalloc.h
#include drmP.h
-unsigned long drm_get_resource_start(struct drm_device *dev, unsigned int
resource)
+resource_size_t drm_get_resource_start(struct drm_device *dev, unsigned
int resource)
{
return pci_resource_start(dev-pdev, resource);
}
EXPORT_SYMBOL(drm_get_resource_start);
-unsigned long drm_get_resource_len(struct drm_device *dev, unsigned int
resource)
+resource_size_t drm_get_resource_len(struct drm_device *dev, unsigned int
resource)
{
return pci_resource_len(dev-pdev, resource);
}
Index: linux-work/drivers/gpu/drm/i915/i915_dma.c
===
--- linux-work.orig/drivers/gpu/drm/i915/i915_dma.c 2009-02-02
14:25:44.0 +1100
+++ linux-work/drivers/gpu/drm/i915/i915_dma.c 2009-02-02
14:28:19.0 +1100
@@ -1051,7 +1051,7 @@ void i915_master_destroy(struct drm_devi
int i915_driver_load(struct drm_device *dev, unsigned long flags)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- unsigned long base, size;
+ resource_size_t base, size;
int ret = 0, mmio_bar = IS_I9XX(dev) ? 0 : 1;
/* i915 has 4 more counters */
Index: linux-work/drivers/gpu/drm/mga/mga_drv.h
===
--- linux-work.orig/drivers/gpu/drm/mga/mga_drv.h 2009-02-02
14:18:10.0 +1100
+++ linux-work/drivers/gpu/drm/mga/mga_drv.h2009-02-02
14:18:37.0 +1100
@@ -113,8 +113,8 @@ typedef struct drm_mga_private {
* \sa drm_mga_private_t::mmio
*/
/*...@{ */
- u32 mmio_base; /** Bus address of base of MMIO. */
- u32 mmio_size; /** Size of the MMIO region. */
+ resource_size_t mmio_base; /** Bus address of base of MMIO. */
+ resource_size_t mmio_size; /** Size of the MMIO region. */
/*...@} */
u32 clear_cmd;
Index: linux-work/drivers/gpu/drm/radeon/radeon_drv.h
===
--- linux-work.orig/drivers/gpu/drm/radeon/radeon_drv.h 2009-02-02
14:13:35.0 +1100
+++ linux-work/drivers/gpu/drm/radeon/radeon_drv.h 2009-02-02
14:13:44.0 +1100
@@ -316,7 +316,7 @@ typedef struct drm_radeon_private {
/* starting from here on, data is preserved accross an open */
uint32_t flags; /* see radeon_chip_flags */
- unsigned long fb_aper_offset;
+ resource_size_t fb_aper_offset;
int num_gb_pipes;
int track_flush;
Index: linux-work/drivers/gpu/drm/savage/savage_bci.c
===
--- linux-work.orig/drivers/gpu/drm/savage/savage_bci.c 2009-02-02
14:15:43.0 +1100
+++ linux-work/drivers/gpu/drm/savage/savage_bci.c 2009-02-02
14:16:04.0 +1100
@@ -599,8 +599,8 @@ int savage_driver_firstopen(struct drm_d
drm_mtrr_add(dev_priv-mtrr[2].base,
dev_priv-mtrr[2].size, DRM_MTRR_WC);
} else {
- DRM_ERROR(strange pci_resource_len %08lx\n,
- drm_get_resource_len(dev, 0));
+ DRM_ERROR(strange pci_resource_len %08llx\n,
+ (unsigned long long)drm_get_resource_len(dev,
0));
}
} else if (dev_priv-chipset != S3_SUPERSAVAGE
dev_priv-chipset != S3_SAVAGE2000) {
@@ -620,8 +620,8 @@ int savage_driver_firstopen(struct drm_d
drm_mtrr_add(dev_priv-mtrr
[PATCH 2/3] drm: Split drm_map and drm_local_map
Once upon a time, the DRM made the distinction between the drm_map
data structure exchanged with user space and the drm_local_map used
in the kernel.
For some reasons, while the BSD port still has that feature, the
linux part abused drm_map for kernel internal usage as the local
map only existed as a typedef of the struct drm_map.
This patch fixes it by declaring struct drm_local_map separately
(though its content is currently identical to the userspace variant),
and changing the kernel code to only use that, except when it's a
user-kernel interface (ie. ioctl).
This allows subsequent changes to the in-kernel format
I've also replaced the use of drm_local_map_t with struct drm_local_map
in a couple of places. Mostly by accident but they are the same (the
former is a typedef of the later) and I have some remote plans and
half finished patch to completely kill the drm_local_map_t typedef
so I left those bits in.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/gpu/drm/drm_bufs.c | 46 ++-
drivers/gpu/drm/drm_context.c |4 +--
drivers/gpu/drm/drm_drv.c |2 -
drivers/gpu/drm/drm_gem.c |2 -
drivers/gpu/drm/drm_memory.c|6 ++---
drivers/gpu/drm/drm_proc.c |2 -
drivers/gpu/drm/drm_vm.c| 12 +-
drivers/gpu/drm/i810/i810_drv.h |4 +--
drivers/gpu/drm/i830/i830_drv.h |4 +--
drivers/gpu/drm/i915/i915_gem.c |4 +--
include/drm/drmP.h | 47 +---
11 files changed, 76 insertions(+), 57 deletions(-)
--- linux-work.orig/drivers/gpu/drm/drm_bufs.c 2009-02-02 15:27:55.0
+1100
+++ linux-work/drivers/gpu/drm/drm_bufs.c 2009-02-02 16:00:35.0
+1100
@@ -50,7 +50,7 @@ resource_size_t drm_get_resource_len(str
EXPORT_SYMBOL(drm_get_resource_len);
static struct drm_map_list *drm_find_matching_map(struct drm_device *dev,
-drm_local_map_t *map)
+ struct drm_local_map *map)
{
struct drm_map_list *entry;
list_for_each_entry(entry, dev-maplist, head) {
@@ -89,13 +89,8 @@ static int drm_map_handle(struct drm_dev
}
/**
- * Ioctl to specify a range of memory that is available for mapping by a
non-root process.
- *
- * \param inode device inode.
- * \param file_priv DRM file private.
- * \param cmd command.
- * \param arg pointer to a drm_map structure.
- * \return zero on success or a negative value on error.
+ * Core function to create a range of memory available for mapping by a
+ * non-root process.
*
* Adjusts the memory offset to its absolute value according to the mapping
* type. Adds the map to the map list drm_device::maplist. Adds MTRR's where
@@ -106,7 +101,7 @@ static int drm_addmap_core(struct drm_de
enum drm_map_flags flags,
struct drm_map_list ** maplist)
{
- struct drm_map *map;
+ struct drm_local_map *map;
struct drm_map_list *list;
drm_dma_handle_t *dmah;
unsigned long user_token;
@@ -329,7 +324,7 @@ static int drm_addmap_core(struct drm_de
int drm_addmap(struct drm_device * dev, unsigned int offset,
unsigned int size, enum drm_map_type type,
- enum drm_map_flags flags, drm_local_map_t ** map_ptr)
+ enum drm_map_flags flags, struct drm_local_map ** map_ptr)
{
struct drm_map_list *list;
int rc;
@@ -342,6 +337,17 @@ int drm_addmap(struct drm_device * dev,
EXPORT_SYMBOL(drm_addmap);
+/**
+ * Ioctl to specify a range of memory that is available for mapping by a
+ * non-root process.
+ *
+ * \param inode device inode.
+ * \param file_priv DRM file private.
+ * \param cmd command.
+ * \param arg pointer to a drm_map structure.
+ * \return zero on success or a negative value on error.
+ *
+ */
int drm_addmap_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
@@ -367,19 +373,13 @@ int drm_addmap_ioctl(struct drm_device *
* Remove a map private from list and deallocate resources if the mapping
* isn't in use.
*
- * \param inode device inode.
- * \param file_priv DRM file private.
- * \param cmd command.
- * \param arg pointer to a struct drm_map structure.
- * \return zero on success or a negative value on error.
- *
* Searches the map on drm_device::maplist, removes it from the list, see if
* its being used, and free any associate resource (such as MTRR's) if it's not
* being on use.
*
* \sa drm_addmap
*/
-int drm_rmmap_locked(struct drm_device *dev, drm_local_map_t *map)
+int drm_rmmap_locked(struct drm_device *dev, struct drm_local_map *map)
{
struct drm_map_list *r_list = NULL, *list_t;
drm_dma_handle_t dmah;
@@ -442,7 +442,7 @@ int drm_rmmap_locked(struct drm_device *
}
EXPORT_SYMBOL(drm_rmmap_locked);
-int drm_rmmap(struct drm_device *dev
[PATCH 1/3] drm: Use resource_size_t for drm_get_resource_{start, len}
The DRM uses its own wrappers to obtain resources from PCI devices,
which currently convert the resource_size_t into an unsigned long.
This is broken on 32-bit platforms with 32-bit physical address
space.
This fixes them, along with a few occurences of unsigned long used
to store such a resource in drivers.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/gpu/drm/drm_bufs.c |4 ++--
drivers/gpu/drm/i915/i915_dma.c |2 +-
drivers/gpu/drm/mga/mga_drv.h |4 ++--
drivers/gpu/drm/radeon/radeon_drv.h |2 +-
drivers/gpu/drm/savage/savage_bci.c |8
include/drm/drmP.h |6 +++---
include/drm/drm_crtc.h |2 +-
7 files changed, 14 insertions(+), 14 deletions(-)
--- linux-work.orig/drivers/gpu/drm/drm_bufs.c 2009-02-02 14:11:26.0
+1100
+++ linux-work/drivers/gpu/drm/drm_bufs.c 2009-02-02 14:11:35.0
+1100
@@ -36,13 +36,13 @@
#include linux/vmalloc.h
#include drmP.h
-unsigned long drm_get_resource_start(struct drm_device *dev, unsigned int
resource)
+resource_size_t drm_get_resource_start(struct drm_device *dev, unsigned int
resource)
{
return pci_resource_start(dev-pdev, resource);
}
EXPORT_SYMBOL(drm_get_resource_start);
-unsigned long drm_get_resource_len(struct drm_device *dev, unsigned int
resource)
+resource_size_t drm_get_resource_len(struct drm_device *dev, unsigned int
resource)
{
return pci_resource_len(dev-pdev, resource);
}
Index: linux-work/drivers/gpu/drm/i915/i915_dma.c
===
--- linux-work.orig/drivers/gpu/drm/i915/i915_dma.c 2009-02-02
14:25:44.0 +1100
+++ linux-work/drivers/gpu/drm/i915/i915_dma.c 2009-02-02 14:28:19.0
+1100
@@ -1051,7 +1051,7 @@ void i915_master_destroy(struct drm_devi
int i915_driver_load(struct drm_device *dev, unsigned long flags)
{
struct drm_i915_private *dev_priv = dev-dev_private;
- unsigned long base, size;
+ resource_size_t base, size;
int ret = 0, mmio_bar = IS_I9XX(dev) ? 0 : 1;
/* i915 has 4 more counters */
Index: linux-work/drivers/gpu/drm/mga/mga_drv.h
===
--- linux-work.orig/drivers/gpu/drm/mga/mga_drv.h 2009-02-02
14:18:10.0 +1100
+++ linux-work/drivers/gpu/drm/mga/mga_drv.h2009-02-02 14:18:37.0
+1100
@@ -113,8 +113,8 @@ typedef struct drm_mga_private {
* \sa drm_mga_private_t::mmio
*/
/*...@{ */
- u32 mmio_base; /** Bus address of base of MMIO. */
- u32 mmio_size; /** Size of the MMIO region. */
+ resource_size_t mmio_base; /** Bus address of base of MMIO. */
+ resource_size_t mmio_size; /** Size of the MMIO region. */
/*...@} */
u32 clear_cmd;
Index: linux-work/drivers/gpu/drm/radeon/radeon_drv.h
===
--- linux-work.orig/drivers/gpu/drm/radeon/radeon_drv.h 2009-02-02
14:13:35.0 +1100
+++ linux-work/drivers/gpu/drm/radeon/radeon_drv.h 2009-02-02
14:13:44.0 +1100
@@ -316,7 +316,7 @@ typedef struct drm_radeon_private {
/* starting from here on, data is preserved accross an open */
uint32_t flags; /* see radeon_chip_flags */
- unsigned long fb_aper_offset;
+ resource_size_t fb_aper_offset;
int num_gb_pipes;
int track_flush;
Index: linux-work/drivers/gpu/drm/savage/savage_bci.c
===
--- linux-work.orig/drivers/gpu/drm/savage/savage_bci.c 2009-02-02
14:15:43.0 +1100
+++ linux-work/drivers/gpu/drm/savage/savage_bci.c 2009-02-02
14:16:04.0 +1100
@@ -599,8 +599,8 @@ int savage_driver_firstopen(struct drm_d
drm_mtrr_add(dev_priv-mtrr[2].base,
dev_priv-mtrr[2].size, DRM_MTRR_WC);
} else {
- DRM_ERROR(strange pci_resource_len %08lx\n,
- drm_get_resource_len(dev, 0));
+ DRM_ERROR(strange pci_resource_len %08llx\n,
+ (unsigned long long)drm_get_resource_len(dev,
0));
}
} else if (dev_priv-chipset != S3_SUPERSAVAGE
dev_priv-chipset != S3_SAVAGE2000) {
@@ -620,8 +620,8 @@ int savage_driver_firstopen(struct drm_d
drm_mtrr_add(dev_priv-mtrr[0].base,
dev_priv-mtrr[0].size, DRM_MTRR_WC);
} else {
- DRM_ERROR(strange pci_resource_len %08lx\n,
- drm_get_resource_len(dev, 1));
+ DRM_ERROR(strange pci_resource_len %08llx\n,
+ (unsigned long long
[PATCH 3/3] drm: Make drm_local_map use a resource_size_t offset
This changes drm_local_map to use a resource_size for its offset
member instead of an unsigned long, thus allowing 32-bit machines
with a 32-bit physical address space to be able to store there
their register or framebuffer addresses when those are above 4G,
such as when using a PCI video card on a recent AMCC 440 SoC.
This patch isn't as trivial as it sounds: A few functions needed
to have some unsigned long/int changed to resource_size_t and a few
printk's had to be adjusted.
But also, because userspace isn't capable of passing such offsets,
I had to modify drm_find_matching_map() to ignore the offset passed
in for maps of type _DRM_FRAMEBUFFER or _DRM_REGISTERS.
If we ever support multiple _DRM_FRAMEBUFFER or _DRM_REGISTERS maps
for a given device, we might have to change that trick, but I don't
think that happens on any current driver.
Signed-off-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
drivers/gpu/drm/drm_bufs.c | 33 -
drivers/gpu/drm/drm_proc.c |4 ++--
drivers/gpu/drm/drm_vm.c | 22 --
drivers/gpu/drm/mga/mga_dma.c | 17 +
drivers/gpu/drm/mga/mga_drv.h |4 ++--
drivers/gpu/drm/r128/r128_cce.c|7 ---
drivers/gpu/drm/radeon/radeon_cp.c |9 +
include/drm/drmP.h | 12 ++--
8 files changed, 64 insertions(+), 44 deletions(-)
--- linux-work.orig/drivers/gpu/drm/drm_bufs.c 2009-02-02 16:29:54.0
+1100
+++ linux-work/drivers/gpu/drm/drm_bufs.c 2009-02-02 16:29:54.0
+1100
@@ -54,11 +54,25 @@ static struct drm_map_list *drm_find_mat
{
struct drm_map_list *entry;
list_for_each_entry(entry, dev-maplist, head) {
- if (entry-map (entry-master == dev-primary-master)
(map-type == entry-map-type)
- ((entry-map-offset == map-offset) ||
-((map-type == _DRM_SHM)
(map-flags_DRM_CONTAINS_LOCK {
+ /* Due to userspace API breakage, we ignore the map offset
+* for maps of type _DRM_FRAMEBUFFER or _DRM_REGISTERS
+*/
+ if (!entry-map ||
+ map-type != entry-map-type ||
+ entry-master != dev-primary-master)
+ continue;
+ switch (map-type) {
+ case _DRM_SHM:
+ if (map-flags != _DRM_CONTAINS_LOCK)
+ break;
+ case _DRM_REGISTERS:
+ case _DRM_FRAME_BUFFER:
return entry;
+ default: /* Make gcc happy */
+ ;
}
+ if (entry-map-offset == map-offset)
+ return entry;
}
return NULL;
@@ -96,7 +110,7 @@ static int drm_map_handle(struct drm_dev
* type. Adds the map to the map list drm_device::maplist. Adds MTRR's where
* applicable and if supported by the kernel.
*/
-static int drm_addmap_core(struct drm_device * dev, unsigned int offset,
+static int drm_addmap_core(struct drm_device * dev, resource_size_t offset,
unsigned int size, enum drm_map_type type,
enum drm_map_flags flags,
struct drm_map_list ** maplist)
@@ -124,9 +138,9 @@ static int drm_addmap_core(struct drm_de
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
return -EINVAL;
}
- DRM_DEBUG(offset = 0x%08lx, size = 0x%08lx, type = %d\n,
- map-offset, map-size, map-type);
- if ((map-offset (~PAGE_MASK)) || (map-size (~PAGE_MASK))) {
+ DRM_DEBUG(offset = 0x%08llx, size = 0x%08lx, type = %d\n,
+ (unsigned long long)map-offset, map-size, map-type);
+ if ((map-offset (~(resource_size_t)PAGE_MASK)) || (map-size
(~PAGE_MASK))) {
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
return -EINVAL;
}
@@ -254,7 +268,8 @@ static int drm_addmap_core(struct drm_de
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
return -EPERM;
}
- DRM_DEBUG(AGP offset = 0x%08lx, size = 0x%08lx\n,
map-offset, map-size);
+ DRM_DEBUG(AGP offset = 0x%08llx, size = 0x%08lx\n,
+ (unsigned long long)map-offset, map-size);
break;
case _DRM_GEM:
@@ -322,7 +337,7 @@ static int drm_addmap_core(struct drm_de
return 0;
}
-int drm_addmap(struct drm_device * dev, unsigned int offset,
+int drm_addmap(struct drm_device * dev, resource_size_t offset,
unsigned int size, enum drm_map_type type,
enum drm_map_flags flags, struct drm_local_map ** map_ptr)
{
Index: linux-work/drivers/gpu/drm/drm_proc.c
===
--- linux-work.orig/drivers/gpu/drm
Re: Adding kmap_atomic_prot_pfn (was: [git pull] drm patches for 2.6.27-rc1)
On Thu, 2008-10-23 at 14:24 -0700, Linus Torvalds wrote: The whole point of that function has absolutely nothing to do with highmem, and it *must* be useful on non-highmem configurations to be appropriate. So I'd much rather create a new linux/kmap.h or something. Or just expose this from to asm/fixmap.h or something. Let's not confuse this with highmem, even if the implementation _historically_ was due to that. Well, on powerpc, we just went (or rather, Kumar just went) through the oops of implementing fixmap and then kmap on top of it... just because we wanted kmap_atomic functionality on non-highmem platforms :-) (and the fixmap approach has some other interesting features). So yes, I agree. Typically very useful for any 32-bit processor with a memory mapped PCI Express config space since it's something like 256M of virtual space to map it all iirc. Cheers, Ben. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Adding kmap_atomic_prot_pfn (was: [git pull] drm patches for 2.6.27-rc1)
On Thu, 2008-10-23 at 19:48 -0700, Linus Torvalds wrote: Then, there's the issue of 64-bit, and just mapping everything there, and the interface to that. I liked the trivial extension to struct resource to have a cached mapping pointer. So if we can just make it pass resources around and get a page that way (and not even need kmap() on 64-bit architections), that would be good. I'm not that fan of carrying a mapping with a struct resource because if we do that we should probably also refcount the mapping, and then there is the whole question of mappings with different attributes, etc etc... Cheers, Ben. - 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] drm: Fix for non-coherent DMA PowerPC
This patch fixes bits of the DRM so to make the radeon DRI work on
non-cache coherent PCI DMA variants of the PowerPC processors.
It moves the few places that needs change to wrappers to that
other architectures with similar issues can easily add their
own changes to those wrappers, at least until we have more useful
generic kernel API.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
This version of the patch removes the use of GFP_HIGHMEM on powerpc
as our implementation of some of the DMA mapping ops on non cache
coherent platforms don't work on highmem.
Index: linux-work/drivers/char/drm/ati_pcigart.c
===
--- linux-work.orig/drivers/char/drm/ati_pcigart.c 2008-02-18
10:09:27.0 +1100
+++ linux-work/drivers/char/drm/ati_pcigart.c 2008-03-05 15:42:02.0
+1100
@@ -214,6 +214,12 @@ int drm_ati_pcigart_init(struct drm_devi
}
}
+ if (gart_info-gart_table_location == DRM_ATI_GART_MAIN)
+ dma_sync_single_for_device(dev-pdev-dev,
+ bus_address,
+ max_pages * sizeof(u32),
+ PCI_DMA_TODEVICE);
+
ret = 1;
#if defined(__i386__) || defined(__x86_64__)
Index: linux-work/drivers/char/drm/drm_scatter.c
===
--- linux-work.orig/drivers/char/drm/drm_scatter.c 2008-02-18
10:09:27.0 +1100
+++ linux-work/drivers/char/drm/drm_scatter.c 2008-03-05 15:48:55.0
+1100
@@ -36,6 +36,15 @@
#define DEBUG_SCATTER 0
+static inline void *drm_vmalloc_dma(unsigned long size)
+{
+#if defined(__powerpc__) defined(CONFIG_NOT_COHERENT_CACHE)
+ return __vmalloc(size, GFP_KERNEL, PAGE_KERNEL | _PAGE_NO_CACHE);
+#else
+ return vmalloc_32(size);
+#endif
+}
+
void drm_sg_cleanup(struct drm_sg_mem * entry)
{
struct page *page;
@@ -104,7 +113,7 @@ int drm_sg_alloc(struct drm_device *dev,
}
memset((void *)entry-busaddr, 0, pages * sizeof(*entry-busaddr));
- entry-virtual = vmalloc_32(pages PAGE_SHIFT);
+ entry-virtual = drm_vmalloc_dma(pages PAGE_SHIFT);
if (!entry-virtual) {
drm_free(entry-busaddr,
entry-pages * sizeof(*entry-busaddr), DRM_MEM_PAGES);
Index: linux-work/drivers/char/drm/drm_vm.c
===
--- linux-work.orig/drivers/char/drm/drm_vm.c 2008-02-21 13:34:16.0
+1100
+++ linux-work/drivers/char/drm/drm_vm.c2008-03-05 15:42:02.0
+1100
@@ -54,13 +54,24 @@ static pgprot_t drm_io_prot(uint32_t map
pgprot_val(tmp) |= _PAGE_NO_CACHE;
if (map_type == _DRM_REGISTERS)
pgprot_val(tmp) |= _PAGE_GUARDED;
-#endif
-#if defined(__ia64__)
+#elif defined(__ia64__)
if (efi_range_is_wc(vma-vm_start, vma-vm_end -
vma-vm_start))
tmp = pgprot_writecombine(tmp);
else
tmp = pgprot_noncached(tmp);
+#elif defined(__sparc__)
+ tmp = pgprot_noncached(tmp);
+#endif
+ return tmp;
+}
+
+static pgprot_t drm_dma_prot(uint32_t map_type, struct vm_area_struct *vma)
+{
+ pgprot_t tmp = vm_get_page_prot(vma-vm_flags);
+
+#if defined(__powerpc__) defined(CONFIG_NOT_COHERENT_CACHE)
+ tmp |= _PAGE_NO_CACHE;
#endif
return tmp;
}
@@ -603,9 +614,6 @@ static int drm_mmap_locked(struct file *
offset = dev-driver-get_reg_ofs(dev);
vma-vm_flags |= VM_IO; /* not in core dump */
vma-vm_page_prot = drm_io_prot(map-type, vma);
-#ifdef __sparc__
- vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
-#endif
if (io_remap_pfn_range(vma, vma-vm_start,
(map-offset + offset) PAGE_SHIFT,
vma-vm_end - vma-vm_start,
@@ -624,6 +632,7 @@ static int drm_mmap_locked(struct file *
page_to_pfn(virt_to_page(map-handle)),
vma-vm_end - vma-vm_start, vma-vm_page_prot))
return -EAGAIN;
+ vma-vm_page_prot = drm_dma_prot(map-type, vma);
/* fall through to _DRM_SHM */
case _DRM_SHM:
vma-vm_ops = drm_vm_shm_ops;
@@ -636,6 +645,7 @@ static int drm_mmap_locked(struct file *
vma-vm_ops = drm_vm_sg_ops;
vma-vm_private_data = (void *)map;
vma-vm_flags |= VM_RESERVED;
+ vma-vm_page_prot = drm_dma_prot(map-type, vma);
break;
default:
return -EINVAL; /* This should never happen. */
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008
Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
On Mon, 2008-03-03 at 20:51 +0100, Gerhard Pircher wrote: Remove the GFP_HIGHMEM from the above. It looks like our cache flushing isn't going to work for highmem, it would need some kmap's for that. Yes, it looks like this was the problem. No kernel oops anymore. The machine locks up anyway (which is a well known hardware problem). It doesn't lock up with CPPIOMode=true, but probably only because the initialization of DRI fails with BAD cp_mode (f000)!. Damn, I wonder why you insist trying to make that machine work :-) The hardware is just totally busted. Ben. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
Xorg (v7.1.1, Debian Etch) crashes with this patch (applied to 2.6.25-rc3) on my AmigaOne with a Radeon 9200 (PCIGART mode enabled). See the attached log file for the stack trace. That doesn't look possible, which is weird... looks like we are passing 0 to clean_dcache_range(). Interestingly enough, I can -see- possible issues with the ppc32 DMA API when trying to use HIGHMEM but that isn't the case here... Can you add printk's to ati_pcigart.c to print the arguments passed to + dma_sync_single_for_device(dev-pdev-dev, + bus_address, + max_pages * sizeof(u32), + PCI_DMA_TODEVICE); + And also print the result of bus_to_virt(bus_address) ? Ben. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
Okay, I changed the code to this:
DRM_DEBUG(dev = 0x%x, bus_address = 0x%x, bus_to_virt = 0x%lx, max_pages =
0x%x\n,
(unsigned int)dev-pdev-dev, bus_address,
(unsigned long)virt_to_bus(bus_address), max_pages);
if (gart_info-gart_table_location == DRM_ATI_GART_MAIN) {
DRM_DEBUG(calling dma_sync_single_for_device()\n);
dma_sync_single_for_device(dev-pdev-dev,
bus_address,
max_pages * sizeof(u32),
PCI_DMA_TODEVICE);
}
It looks like dma_sync_single_for_device() is not called here (the debug
messages don't show up in kernel log). I also included the Xorg.0.log
file.
Ok, try adding more debug then, around the calls to pci_map_single() in
that same function and dump the arguments. I'm especially interested
in the result of the various page_address().
Ben.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BUG/RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
Bah, I think I found the problem:
+static inline void *drm_vmalloc_dma(unsigned long size)
+{
+#if defined(__powerpc__) defined(CONFIG_NOT_COHERENT_CACHE)
+ return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM,
+PAGE_KERNEL | _PAGE_NO_CACHE);
+#else
+ return vmalloc_32(size);
+#endif
+}
+
Remove the GFP_HIGHMEM from the above. It looks like our cache
flushing isn't going to work for highmem, it would need some
kmap's for that.
Ben.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC/PATCH] drm: Fix for non-coherent DMA PowerPC
This patch fixes bits of the DRM so to make the radeon DRI work on
non-cache coherent PCI DMA variants of the PowerPC processors.
It moves the few places that needs change to wrappers to that
other architectures with similar issues can easily add their
own changes to those wrappers, at least until we have more useful
generic kernel API.
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
drivers/char/drm/ati_pcigart.c |6 ++
drivers/char/drm/drm_scatter.c | 12 +++-
drivers/char/drm/drm_vm.c | 20 +++-
3 files changed, 32 insertions(+), 6 deletions(-)
Index: linux-work/drivers/char/drm/ati_pcigart.c
===
--- linux-work.orig/drivers/char/drm/ati_pcigart.c 2007-11-26
10:07:29.0 +1100
+++ linux-work/drivers/char/drm/ati_pcigart.c 2007-11-26 10:21:33.0
+1100
@@ -214,6 +214,12 @@ int drm_ati_pcigart_init(struct drm_devi
}
}
+ if (gart_info-gart_table_location == DRM_ATI_GART_MAIN)
+ dma_sync_single_for_device(dev-pdev-dev,
+ bus_address,
+ max_pages * sizeof(u32),
+ PCI_DMA_TODEVICE);
+
ret = 1;
#if defined(__i386__) || defined(__x86_64__)
Index: linux-work/drivers/char/drm/drm_scatter.c
===
--- linux-work.orig/drivers/char/drm/drm_scatter.c 2007-11-26
10:07:29.0 +1100
+++ linux-work/drivers/char/drm/drm_scatter.c 2007-11-26 10:20:08.0
+1100
@@ -36,6 +36,16 @@
#define DEBUG_SCATTER 0
+static inline void *drm_vmalloc_dma(unsigned long size)
+{
+#if defined(__powerpc__) defined(CONFIG_NOT_COHERENT_CACHE)
+ return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM,
+PAGE_KERNEL | _PAGE_NO_CACHE);
+#else
+ return vmalloc_32(size);
+#endif
+}
+
void drm_sg_cleanup(struct drm_sg_mem * entry)
{
struct page *page;
@@ -104,7 +114,7 @@ int drm_sg_alloc(struct drm_device *dev,
}
memset((void *)entry-busaddr, 0, pages * sizeof(*entry-busaddr));
- entry-virtual = vmalloc_32(pages PAGE_SHIFT);
+ entry-virtual = drm_vmalloc_dma(pages PAGE_SHIFT);
if (!entry-virtual) {
drm_free(entry-busaddr,
entry-pages * sizeof(*entry-busaddr), DRM_MEM_PAGES);
Index: linux-work/drivers/char/drm/drm_vm.c
===
--- linux-work.orig/drivers/char/drm/drm_vm.c 2007-11-26 10:07:29.0
+1100
+++ linux-work/drivers/char/drm/drm_vm.c2007-11-26 10:11:09.0
+1100
@@ -54,13 +54,24 @@ static pgprot_t drm_io_prot(uint32_t map
pgprot_val(tmp) |= _PAGE_NO_CACHE;
if (map_type == _DRM_REGISTERS)
pgprot_val(tmp) |= _PAGE_GUARDED;
-#endif
-#if defined(__ia64__)
+#elif defined(__ia64__)
if (efi_range_is_wc(vma-vm_start, vma-vm_end -
vma-vm_start))
tmp = pgprot_writecombine(tmp);
else
tmp = pgprot_noncached(tmp);
+#elif defined(__sparc__)
+ tmp = pgprot_noncached(tmp);
+#endif
+ return tmp;
+}
+
+static pgprot_t drm_dma_prot(uint32_t map_type, struct vm_area_struct *vma)
+{
+ pgprot_t tmp = vm_get_page_prot(vma-vm_flags);
+
+#if defined(__powerpc__) defined(CONFIG_NOT_COHERENT_CACHE)
+ tmp |= _PAGE_NO_CACHE;
#endif
return tmp;
}
@@ -617,9 +628,6 @@ static int drm_mmap_locked(struct file *
offset = dev-driver-get_reg_ofs(dev);
vma-vm_flags |= VM_IO; /* not in core dump */
vma-vm_page_prot = drm_io_prot(map-type, vma);
-#ifdef __sparc__
- vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot);
-#endif
if (io_remap_pfn_range(vma, vma-vm_start,
(map-offset + offset) PAGE_SHIFT,
vma-vm_end - vma-vm_start,
@@ -638,6 +646,7 @@ static int drm_mmap_locked(struct file *
page_to_pfn(virt_to_page(map-handle)),
vma-vm_end - vma-vm_start, vma-vm_page_prot))
return -EAGAIN;
+ vma-vm_page_prot = drm_dma_prot(map-type, vma);
/* fall through to _DRM_SHM */
case _DRM_SHM:
vma-vm_ops = drm_vm_shm_ops;
@@ -650,6 +659,7 @@ static int drm_mmap_locked(struct file *
vma-vm_ops = drm_vm_sg_ops;
vma-vm_private_data = (void *)map;
vma-vm_flags |= VM_RESERVED;
+ vma-vm_page_prot = drm_dma_prot(map-type, vma);
break;
default:
return -EINVAL; /* This should never happen. */
-
This SF.net email
Re: [RFC] enhancing the kernel's graphics subsystem
On Tue, 2007-05-22 at 08:39 -0700, Jesse Barnes wrote: The current code does its best to figure out what modes are available and tries to pick a good one for each display. It sounds like you're mainly concerned with the actual mode picking, not the mode and output detection and enumeration? If so, that's a pretty easy change to make. But if you're also worried about the kernel building mode lists, then we'll have bigger changes to make... I'm worried that the EDID we get from the monitor is bogus and needs to be overriden. Now, if the kernel builds a mode list, that's find if we have a call to feed it with a replacement one later on from userland. In addition, there are all those monitors that cannot be probed (no DDC/EDID) and for which only userland can reasonably provide a mode or a mode list. So it's a bit of both :-) Building an initial mode list from the EDID might be fair enough if we can replace it soon enough, but we still need to be very conservative about whatever boot mode we choose. I'm not really sure how much of a problem broken EDIDs will be. The X server only has a few quirks for broken EDIDs now, nothing major afaict, and apparently the FB layer already has some code for handling EDID quirks, so I don't think that'll be our biggest problem. So far, it looks like handling laptop panels is a bit trickier (at least for Intel chips)... Well, I've seen my share of broken EDID.. Last time I looked at Darwin, I think I saw Apple maintaining a fairly huge database of EDID replacements in userland... Ben. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] enhancing the kernel's graphics subsystem
In collaboration with the FB guys, we've been working on enhancing the kernel's graphics subsystem in an attempt to bring some sanity to the Linux graphics world and avoid the situation we have now where several kernel and userspace drivers compete for control of graphics devices. .../... A little note about initial mode setting at boot... I do stongly beleive that the decision of what mode to choose should not be made in the kernel. At boot the kernel should either leave the HW in whatever state the FW set it (and text mode is fine) or setup some sane default (ie 640x480 has the most chances of working) if that's not an option, maybe some very minimum EDID parsing in case you have a fixed frequency weirdo panel, but that's it (unless it's a mac an OF tells you what to use :-) The kernel would provide userland with connector infos (presence load detect, EDID, ...) and userland gets to decide what to do. Some reasons to keep that policy completely out of the kernel even at boot time are: - User may want to configure his default gfx setup and have it up early - EDID do lie, monitors routinely ship with windows .inf files containing updated infos apple has that too in OS X (EDID overrides afaik) etc and if we're going to do such a database of known monitors, it should definitely not be in the kernel. Besides, we want to add more infos that EDIDs don't provide most of the time to it like subpixel ordering etc... - It sounds better that way :-) (yeah, that's the best reason !) So while I agree that the register frobbing, memory management, etc... should be indeed moved to the kernel as you guys have been doing lately, the policy of deciding what mode to set should totally stick to userland. IMHO, the best would be a lib (or daemon or both) for monitor detection mode setting that is separate from X :-) That could handle storing the admin's default setup (including weird monitor info if any) and restoring it at boot time, etc... Cheers, Ben. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] enhancing the kernel's graphics subsystem
On Mon, 2007-05-21 at 17:51 -0700, Keith Packard wrote: That's the plan; the kernel just provides mechanism. The architecture used in the X server splits precisely at this point with the mechanism in the driver and the configuration and policy up in the X server proper. Quite a bit of that code could be broken out into a shared library for fbdev-based apps and the X server to share, but that's down the road a bit after the kernel APIs look a lot more solid. Ok, good plan then. With the goal of getting to a single-mode-set boot to avoid screen flashing before login, the key here is to make any early user-mode graphics apps share the same kernel graphics infrastructure as the X server to identify the common cases where the startup and X modes are the same and avoid resetting the configuration. Ok. Fair enough. Cheers, Ben. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
On Thu, 2006-10-05 at 17:52 +0200, Thomas Hellström wrote: Ben, I've implemented a version of the drm_mm code that unmaps ptes using unmap_mapping_range, and remaps IO space using io_remap_pfn_range() for a single page in nopage. This has the side effect that I need to double check in nopage() after taking the object mutex that the pte in question hasn't been populated by a racing nopage, which means I have to include some page table walking code. I can see no obvious performance drops from populating one pte at a time. I think the correct thing is to add the double check in remap_pte_range() instread of the current BUG_ON This makes the need for an io-page aware nopage() or an io_remap_pfn_range() that doesn't BUG on populated page tables quite obvious. What is the status of the NOPAGE_RETRY mechanism in 2.6.19? I don't think it got in, but I need it for various things so I'll check with Andrew if it can still be merged. Ben. - 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 memory manager on cards with hardware contexts
On Thu, 2006-10-05 at 17:52 +0200, Thomas Hellström wrote: Ben, I've implemented a version of the drm_mm code that unmaps ptes using unmap_mapping_range, and remaps IO space using io_remap_pfn_range() for a single page in nopage. This has the side effect that I need to double check in nopage() after taking the object mutex that the pte in question hasn't been populated by a racing nopage, which means I have to include some page table walking code. I can see no obvious performance drops from populating one pte at a time. This makes the need for an io-page aware nopage() or an io_remap_pfn_range() that doesn't BUG on populated page tables quite obvious. What is the status of the NOPAGE_RETRY mechanism in 2.6.19? Patch just got in -mm, the return code changed to NOPAGE_REFAULT. It might still make it into 2.6.19. Regarding the change to io_remap_pfn_range(), I'm tempted to just provide a single routine to put in a single PTE that also does the double check of pte-present. I'll cook up something today hopefully as I want to experiment doing the exact same thing for SPE mappings on cell. Cheers, Ben. - 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 memory manager on cards with hardware contexts
OK. i was reffering to another approach: Copying _to_ VRAM /AGP:
lock_mmap_sems()
unmap_mapping_range() (or similar)
copy() / flip()
foreach_affected_vma{
io_remap_pfn_range() /* Map vram / AGP space */
}
unlock_mmap_sem()
This works like a charm in the drm memory manager but it requires the
lock of the mmap sems from all affected processes, and the locking
order must be the same all the time otherwise deadlocks will occur.
Yes, and that's what I think we can fix using do_no_page() and
unmap_mapping_ranges(). That is, we don't io_remap_pfn_range(), we just
fault in pages either from VRAM or from memory depending on where an
object sits at a given point in time. and we use
unmap_mappingng_ranges() to invalidate current mappings of an object
when we move it. That can be done with the minimal approach I
described with the only limitation (though a pretty big one today) that
you need struct page for VRAM for no_page() to be useable in those
conditions.
do_no_page() is smart enough to recheck the pte when it retakes the
page table spinlock(), so if the pte has been populated by someone
while in the driver nopage(), the returned struct page will simply be
discarded.
Yup, indeed. It has to to avoid races since no_page() has to be called
without the PTE lock. The NOPAGE_RETRY approach would still be slightly
more efficient though.
io_remap_pfn_range() should do the job of setting up the new ptes, but
it needs the mmap_sem, so if that one is held while blocked in
nopage(), a deadlock will occur. Here, the NOPAGE_RETRY will obviously
do the job. When io_remap_pfn_range() has finished setting up the
ptes, one can simply return a bogus page to nopage() if it insists on
retrying. Until NOPAGE_RETRY is implemented, I'm afraid I'm stuck with
the approach outlined above.
It's not completely clear to me if we need the mmap_sem for writing to
call io_remap_pfn_range()... We can certainly populate PTEs with only
the read semaphore and we happen to have it in no_page so that would
just work being called just within no_page().
So this approach would work today imho:
* objects have rwsem to protect migration.
* no_page() does:
- takes that object read sem
- if object is in vram or other non-memory location then do
io_remap_pfn_range() and get a dummy page struct pointer
- else get the struct page of the object page in memory
- release the object read sem and return whatever struct page we got
* migration does:
- take that object write sem
- copy the data to the new location
- call unmap_mapping_ranges() for that object
- release the object write sem
With 2.6.19, hopefully, NOPAGE_RETRY will get in, which means that
no_page() can be optimized for the case where it calls
io_remap_pfn_range() to not return a bogus page and have a faster return
path to userland. It's also possible to provide a io_remap_one_page()
that would be faster than having to call the whole 4 level
io_remap_pfn_range() for every page faulted in (though we might just
remap the entire object on the first fault, might well work ...)
Or do you think I missed something ?
Cheers,
Ben
-
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 memory manager on cards with hardware contexts
* objects have rwsem to protect migration.
* no_page() does:
- takes that object read sem
- if object is in vram or other non-memory location then do
io_remap_pfn_range() and get a dummy page struct pointer
- else get the struct page of the object page in memory
- release the object read sem and return whatever struct page we got
* migration does:
- take that object write sem
- copy the data to the new location
- call unmap_mapping_ranges() for that object
- release the object write sem
Ok, there is one fault in my reasoning: io_remap_pfn_range() isn't
designed to be used in that context (it's really made to be called with
the mmap_sem held for writing) and thus doesn't check if the PTE is
still empty after locking it which is necessary if you are only holding
the read semaphore.
That means that it's still all possible, but not using
io_remap_pfn_range(). Best is to provide a specific new function, called
something like map_one_io_page() or something like that, which does
something along the lines of
pgd = pgd_offset(mm, address);
pud = pud_alloc(mm, pgd, address);
if (!pud)
return VM_FAULT_OOM;
pmd = pmd_alloc(mm, pud, address);
if (!pmd)
return VM_FAULT_OOM;
pte = pte_alloc_map(mm, pmd, address);
if (!pte)
return VM_FAULT_OOM;
pte = pte_offset_map_lock(mm, pmd, address, ptl);
if (pte_none(*page_table)) {
flush_icache_page(vma, new_page);
entry = mk_pte(new_page, vma-vm_page_prot);
if (write_access)
entry = maybe_mkwrite(pte_mkdirty(entry), vma);
set_pte_at(mm, address, page_table, entry);
} else {
page_cache_release(new_page);
goto unlock;
}
update_mmu_cache(vma, address, entry);
lazy_mmu_prot_update(entry);
unlock:
pte_unmap_unlock(pte, ptl);
Note that it's clear that this is to be used exclusively for mapping on
non real pages and it doesn't handle racing with truncate (concurrent
unmap_mapping_ranges(), which is fine in our case as we have the object
semaphore).
We're looking into doing something like that for Cell to not require
sparsemem anymore and thus not create struct page's for SPE local stores
and registers which is a real pain...
We should probably move that discussion to linux-mm and/or lkml tho :)
Cheers,
Ben.
-
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 memory manager on cards with hardware contexts
I'm finding this an interesting discussion. If it shifts to lkml, for instance, is there a way to follow *and post* on the thread without either subscribing to lkml or requiring myself to be on the CC list? I don't know if lkml allows non-subscriber posted, I think it does tho. So you can follow from an archive, though that sucks. Or we can keep both lists CCed. Ben. - 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 memory manager on cards with hardware contexts
No, that's probably the safest approach we can use until NOPAGE_RETRY arrives. Only I was not sure it'd be safe to call io_remap_pfn_range() from within nopage, in case it modifies some internal mm structs that the kernel nopage() code expects to be untouched. It does a couple of things that I don't like and lacks the re-test of the PTE as I explained in my other email. I really want to provide a function for doing that tho, one page at a time. Once NOPAGE_RETRY arrives, (hopefully with a schedule() call attached to it), What about schedule ? NOPAGE_RETRY returns all the way back to userland... So things like signals can be handled etc... and the faulting instruction is re-executed. If there is a need for rescheduling, that will be handled by the kernel on the return path to userland as with signals. I want that for other things on cell which might also be useful for you, for example, the no_page() handler for cell might wait a long time to be able to schedule in a free HW SPE to service the fault. With NOPAGE_RETRY, I can make that wait interruptible (test for signals) and return to userland _without_ filling the PTE if a signal is pending, thus causing signals to be serviced and the faulting instruction re-executed. it's possible, however, that repopulating the whole vma using io_remap_pfn_range() outside nopage, just after doing the copying is more efficient. Might well be when switching to vram but that means knowing about all VMAs and thus all clients... possible but I was trying to avoid it. Although this means keeping track of vmas, the mmap_sems can be taken and released one at a time, without any locking problems. Yup. I agree the single-page approach looks nicer, though. It's somewhat ugly to force one's way into another process' memory space. It is but it works :) It's typically done by things like ptrace, or some drivers DMA'ing to user memory, that's for example what get_user_pages() allows you to do. So it should work as long as you are only faulting pages, or invalidating mappings. We (ab)use that on cell too as SPEs run in the host process address space. They have an MMU that we point to the page tables of the process owning the context running on them. That means we might have take interrupts on the host to service faults for an SPE which is running another mm :) It might be more efficient performance wise however to do the full remap of the entire vram on the first no_page() to it when the object is in vram. That can be done safely with a simple change to io_remap_pfn_range() to make it safe against racing with itself, basically by having remap_pte_range() return 0 instead of BUG()'ing if the PTE has been populated after the lock. Should be pretty trivial and we shouldn't break anything since that was a BUG() case. That would work around what I'm explaining in another email that it currently needs the write mmap_sem because it doesn't handle races with another faulting path (that is with itself basically). Ben. - 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 memory manager on cards with hardware contexts
Hmm, the comments to handle_pte_fault(), which is calling do_nopage gives some insight.. * Note the page_table_lock. It is to protect against kswapd removing * pages from under us. Note that kswapd only ever _removes_ pages, never * adds them. As such, once we have noticed that the page is not present, * we can drop the lock early. * * The adding of pages is protected by the MM semaphore (which we hold), * so we don't need to worry about a page being suddenly been added into * our VM. * This comment is a bit stale I think :) For example, the PTL is no longer used for faulting in PTEs, in favor of a more fine grained lock. Also, fauling only takes the mmap_sem for reading, which can be taken multiple times. It's only taken for writing (which excludes other writers and all readers) when modifying the VMA list itself. So basically when driver nopage is called we should _never_ have a valid PTE. No, we can have two no_page racing. This makes the extra check in do_nopage() after the call to driver nopage() somewhat mysterious, (but fortunate). Perhaps the intention is for driver nopage() to be able to temporarily release the MM semaphore. (Which would be even more fortunate). It's a rwsem, it can be taken multiple times for reading. Only once the PTE lock has been taken (ex page table lock, now a PTE lock whose actual granularity is arch dependent) then you know for sure that nobody else will be mucking around with -this- specific PTE. Which is why you need to re-check after taking the lock. The mmap_sem only protects against the whole VMA being teared down or modified (though truncate doesn't take it neither, thus the truncate count trick which ends up in a retry if we raced with it). In any case, if the comments hold, we should never hit the BUG() statement in io_remap_pfn_range(), but it also seems clear that the code doesn't really expect ptes to be added. Unfortunately, the comment is misleading. I suppose I should submit a patch changing or removing it one of these days... Taking this to the lkml for some clarification might be a good idea. On a totally different subject, the previous discussion we had about having pages outside of the kernel virtual map (highmem pages) for example, might be somewhat tricky with the current definition of alloc_gatt_pages and free_gatt_pages, which both returns kernel virtual addresses. Would be nice to have them return struct page* instead. Yes. Currently, we can get to struct page with virt_to_page, which is what we do in drm_vm.h for platforms where the AGP aperture cannot be accessed as MMIO and thus requires a no_page() for faulting the individual pages in (which is what we do on ppc btw). But that will not work with pages that aren't coming from the virtual mapping. Thus it might indeed be a good idea to change the AGP allocation to return struct page. Ben. - 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 memory manager on cards with hardware contexts
I don't think so. We are not doing vram yet in the TTM code, but I think a general eviction would consist of 1) locking mmap_sems for all processes mapping the buffer. 2) zap the page table. Any attempt to access will be blocked by mmap_sem in nopage(). 3) Copy contents from vram to system using either PCI SG or video-blit-AGP-flip-system. 4) Wait for completion. 5) release the mmap sem. The page table will be refilled using nopage(). On Cell, for SPU mappings, we don't scan through all processes mapping it, we use umap_mapping_range() which does it. However, after double-checking, i have some doubts about the locking so I'm trying to clarify that and I'll come back to you wether it's actually a viable solution or not. Ben. - 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 memory manager on cards with hardware contexts
OK. It seems like mmap locks are needed even for unmap_mapping_range(). Well, I came to the opposite conclusion :) unmap_mapping_range() uses the truncate count mecanism to guard against a racing no_page(). The idea is that: no_page() itself internally takes the per-obkect lock/mutex mostly as a sycnhronisation point before looking for the struct page and releases it before returning the struct page to do_no_page(). unmap_mapping_range() is called with that muetx/lock held (and the copy is done with that held too). That should work without taking the mmap_sem. Now, of course, the real problem is that we don't have struct page for vram There are two ways out of this: - Enforce use of sparsemem and create struct page for vram. That will probably make a few people jump out of their seats in x86 land but that's what we do for cell and SPUs for now. - There's a prooposal that I'm pusing to add a way for no_page() to return a NOPAGE_RETRY error, which essentially causes it to go all the way back to userland and re-do the access. I want that to be able to handle signals while blocked inside no_page() but that could -also- be used to have no_page() setup the PTE mappings itself and return NOPAGE_RETRY, thus avoiding the need for a struct page. Now I do not -ever- want to see drivers mucking around with PTEs directly, however, we can provide something in mm/memory.c that a driver can call from within no_page() to perform the set_pte() along with all the necessary locking, flushes, etc... The base code for NOPAGE_RETRY should get in 2.6.19 soon (one of these days). Ben. - 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 memory manager on cards with hardware contexts
On Tue, 2006-09-19 at 11:27 +0200, Thomas Hellström wrote: But this should be the same problem encountered by the agpgart driver? x86 and x86-64 calls change_page_attr() to take care of this. On powerpc it is simply a noop. (asm/agp.h) Possibly. We sort-of ignore the issue for now on PowerPC and happen to be lucky most of the time because 32 bits PowerPC aren't that agressive at prefetching... I haven't looked at change_page_attr() implementation on x86 but I know they also map the linear mapping with large pages. I don't know what happens if you start trying to change a single page attribute. x86 can breakup that large page into 4k pages, so maybe that's what happens. Currently we take the following approach when the GPU needs access to a buffer: 0) Take the hardware lock. 1) The buffer is validated, and if not present in the GATT, it's flipped in. At this point, idle buffers may be flipped out. 2) The app submits a batch buffer (or in the general case a command sequence). All buffers that are referenced by this command sequence needs to have been validated, and the command sequence should be updated with their new GATT offset. 3) A fence is emitted, and associated with all unfenced buffers. 4) The hardware lock is released. 5) When the fence has expired (The GPU is finished with the command sequence), the buffers associated with it may optionally be thrown out. One problem is that buffers that need to be pinned (_always_ available to the GPU) cannot be thrown out and will thus fragment the aperture- or VRAM space. Buffers also carry usage- and mapping refcounts. They are not allowed to be validated when mapped, and (except under some circumstances) are not allowed to be mapped while validated. Buffer destruction occurs when the refcount goes to zero. Yup. My idea was to allow the locking from userspace to allow for chips that can allow userspace direct command submission. Basically, lock/pin the buffer if it's still in the card, and if that fails (because it's been evicted already), then fallback to a kernel call. Ben. - 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 memory manager on cards with hardware contexts
Yes, this is really a different hardware model than we're used to dealing with for DRI drivers, however it's not a problem for the most part - if you don't need to take the lock, don't. But then you need some other way of dealing with the other hacky stuff we get away with by lock abuses eg. VT switching. We could abuse a RW lock model here where normal command submission takes a read lock (can be shared) and big hammer like VT switch takes a write lock. For the memory manager, I guess there are two choices: 1) make the driver use a command-buffer approach even though the hardware supports per-context ring buffers, or 2) extend the memory manager. Extending the memory manager would involve adding an ability to lock and unlock surfaces to VRAM/AGP addresses - this would require kernel interaction I guess. The driver would have to lock the surfaces then be free to submit commands to the ring, then explicitly unlock the surfaces. This is actually a pretty nasty approach - it makes it very hard to deal with low-memory situations - it's impossible to kick out another processes allocations. I wonder how NV deals with this... I've heard some of the proprietary drivers play MMU tricks. We could do something similar... when kicking a pixmap out, we remap the virtual mapping for that pixmap to backup memory. But that means fundamentally changing our model where we have a big mapping for the fb which we then cut into objects and instead mmap objects separately. As for kicking out mappings behind somebody's back, it works fine :) We do that for SPEs local stores on the Cell processor. A no_page() function will refill as needed from either the HW or the backing store and use unmap_mapping_range() can kick that out behind any process back. The main problem I see with that approach is that you have to either map the backup memory non-cacheable which can be trouble on some platforms (*) or cacheable which means that the same bit of memory will either be cacheable or non-cacheable depending on wether you get the HW, which might be trouble to some apps unless you are careful. (*) The kernel always keeps a cacheable linear mapping of all memory and the nasty prefetchers or speculative execution units might thus bring something from your page otherwise mapped non-cacheable into userspace in the cache that way. Some CPUs will shoke badly if you access via a non-cacheable mapping something that is present in the cache. Ben. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM memory manager on cards with hardware contexts
Actually, the TTM memory manager already does this, but also changes the caching policy of the linear kernel map. The later is not portable unfortunately, and can have other serious performance impacts. Typically, the kernel linear map is mapped using larger page sizes, or in some cases, even large TLB entries, or separate translation registers (like BATs). Thus you cannot affect the caching policy of a single 4k page. Also, on some processors, you can't just break down a single large page into small pages neither. For example, on desktop PowerPC, entire segments of 256M can have only one page size. Even x86 might have some interesting issues here... Unfortunately this leads to rather costly cache and TLB flushes. Particularly on SMP. Yup. I think Keith was referring to the drawbacks with buffers pinned in AGP or VRAM space. /Thomas. - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel - 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 memory manager on cards with hardware contexts
On Mon, 2006-09-18 at 16:46 +0200, Thomas Hellström wrote: Unfortunately this leads to rather costly cache and TLB flushes. Particularly on SMP. I think Keith was referring to the drawbacks with buffers pinned in AGP or VRAM space. What about a futex-like approach: A shared are mapped by both kernel and user has locks for the buffers. When submitting a command involving a buffer, userland tries to lock it. This is a simple atomic operation in user space. If that fails (the lock for that buffer is held, possibly by the kernel, or the buffer is swapped out), them it does an ioctl to the DRM to get access (which involves sleeping until the buffer can be retreived). One the operation is complete, the apps can release the locks to buffers it holds. In fact, if there is a mapping to buffers - objects for cards like nVidia with objects and notifiers, the kernel could auto-unlock objects when the completion interrupt for them occurs. Ben. - 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: R3XX lockup possible solution
First, I think, you shouldn't touch register 0x140, you write value 0x22 there. For my card there is 0x2D (this is power on default and is not changed by fglrx). When value 0x22 is written there, I have got corrupted console and X desktop too. This is the MC_CNTL register. It contains some configuration of the card's memeory controller, and it's content is totally specific to a given card memory configuration (what type of SDRAM's are used, how many banks and channels, what timings etc...). I'm very surprised that fglrx touches this at all... Ben. Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Re : Re : R3XX lockup possible solution
On Sun, 2006-06-25 at 19:57 +0400, Elie Morisse wrote: Nope, doesn't help :'( It still get corrupted after i commented out the 0x0140 stuff. I localized the nasty lines, though : ptr[0x01F82] = 0x011A; ptr[0x01FC2] = 0x151557FF; ptr[0x01F82] = 0x011C; ptr[0x01FC2] = 0x151557FF; ptr[0x01F82] = 0x011E; ptr[0x01FC2] = 0x151557FF; ptr[0x01F82] = 0x0120; ptr[0x01FC2] = 0x151557FF; Any of those line couples is responsible of screen corruption here, so i commented them too.. so i stopped X, run r300init, restart X so i launched a game... my heart pulsing faster... lockup after roughly the same time :'( Those registers are the configuration of the memory controller. They should not have to be touched from what the BIOS does. I'm surprised that fglrx plays with that at all. Like 0x140 (MC_CNTL), their settings is specific to a given card's memory configuration. Ben. Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 9800 lockups, why fixing them seems to be that hard ?
Well, the only time I have immediate lockups are when I use nearly anything other than glxgears and I haven't started X with fglrx first. And, even then, the lockups are simply X, not the full machine. I can remotely log in and reboot (though I can't kill the GL application... That seems to cause even more problems). This is an improvement from months ago when the entire machine would essentially lockup (the cursor would move, but I couldn't kill X and couldn't ssh in). As long as I use fglrx first (and simply loading the 2D driver seems to work, loading the kernel module and 3D drivers are unnecessary) I don't get any real lockups. Googleearth hangs at times, but I can just ssh in and kill it. I don't know if it's related or not (is the M24 apparented to the 9800 in any way ?), but on Tridge laptop, with one of these chips, he gets total hard lockups of the laptop when using google earth with the current r300 DRI (after disabling the smooth fallbacks since google earth trigger them). It worked with an earlier r300 DRI though (whatever debian used to have, he'll try to figure out more precisely). Also, Wolfenstein locks up solid right away if you pop the quake console. If you don't do that, it works fine in window mode (it displays nothing in full screen). With both the old and the current driver. I have asked him to test with fglrx first to see if that helps. I expect he'll pop on this list or the bugzilla with more details soon. Ben. -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300][patch] retry when busy
It should probably be infinite if no hw lock is being held. Lock should be dropped in case of longer waits so that user is given a chance to stop the process. Well, the current behaviour (i.e. return EBUSY after 3 seconds) would make sense too, the user-space driver could simply redo the ioctl (it could also drop the lock before it retries). Which probably really is what was intended, just that it checks for EAGAIN instead of EBUSY (though the code does not drop and retake the lock) by mistake. Dropping the lock while the card is busy processing commands ? sounds pretty dangerous to me.. Ben. --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: __put_page change in 2.6.17-rc1
On Sat, 2006-04-22 at 17:40 -0700, Jesse Allen wrote: Hi, There has been a patch to 2.6.17-rc1 [PATCH] mm: make __put_page internal http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=0f8053a509ceba4a077a50ea7b77039b5559b428 I believe this is causing drm cvs compiling to fail for the radeon module. I guess it is because __put_page's definition is hidden, and the drm cvs falls back to an old definition in linux-core/drm_compat.h line 173. count vs _count. I made this patch to make it compile. Some please look at what should be really done. I tend to think that we should use __free_page() and do it _after_ clearing PG_Reserved but it's Dave's baby so ... :) Ben. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Insane build system (Was: glxinfo segfaults with r300)
On Fri, 2006-04-14 at 15:31 +1000, Benjamin Herrenschmidt wrote:
On Fri, 2006-04-14 at 15:15 +1000, Benjamin Herrenschmidt wrote:
Not sure at this point, but the problem ends up being ctx-DriverCtx at
a different offset
within GLcontext between mesa context.c and r300_tex.c.
Looks like to get the stuff built properly, one has to build first, make
install, make clean and rebuild, and finally re-make install
Oh, and I'm not even sure where the installed versions came from...
looks like it could have been from an X.org install (does it install
GL/internal/* stuff too ?)
Hrm... did make install which updated headers, rebuilt all and still
crash... so something else is causing r300_tex.c to be built with a
different idea of what GLcontext is than the rest of mesa, maybe some
#define related to an EXTension or something like that...
Ok, finally... stale {prefix}/include/GL/internal/glcore.h
No idea who installed this file, it wasn't updated by a make install of
Mesa/DRI, could have been put there by the server, not sure.
The build system seems to occasionally pick it up instead of the one in
the build tree for some files and not others.
I removed it (in fact, I removed {prefix}/include/GL/internal completely
but it was the only file in there). Works now.
Ben.
---
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
glxinfo segfaults with r300
With an r300 DRI checked out a couple of days ago I get a SEGV with the backtrace below, I will try updating from CVS and looking at it more closely later as I find some time... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 805425952 (LWP 6928)] r300NewTextureObject (ctx=value optimized out, name=value optimized out, target=value optimized out) at r300_tex.c:1106 1106obj-MaxAnisotropy = rmesa-initialMaxAnisotropy; (gdb) backtrace #0 r300NewTextureObject (ctx=value optimized out, name=value optimized out, target=value optimized out) at r300_tex.c:1106 #1 0x0f558938 in _mesa_initialize_context (ctx=0x1002fbc0, visual=0x1001ed30, share_list=0x0, driverFunctions=value optimized out, driverContext=0x100261f0) at main/context.c:704 #2 0x0f558c54 in _mesa_create_context (visual=0xf5c0898, share_list=0x1c, driverFunctions=0x10025388, driverContext=0x20) at main/context.c:1298 #3 0x0f53060c in radeonInitContext (radeon=0x10021008, functions=0x0, glVisual=0x100251d0, driContextPriv=0x10020ce0, sharedContextPrivate=0x20) at radeon_context.c:153 #4 0x0f535fe0 in r300CreateContext (glVisual=0x1001ed30, driContextPriv=0x10020ce0, sharedContextPrivate=0x0) at r300_context.c:215 #5 0x0f52f31c in radeonCreateContext (glVisual=0x100251d0, driContextPriv=0xf5c0898, sharedContextPriv=0x1c) at radeon_screen.c:893 #6 0x0f52b494 in driCreateNewContext (dpy=0x10016008, modes=0x1001ed30, render_type=value optimized out, sharedPrivate=value optimized out, pctx=0x10020ce0) at ../common/dri_util.c:798 #7 0x0ff6db9c in CreateContext (dpy=0x10016008, vis=0x10020b48, fbconfig=0x0, shareList=0x0, allowDirect=value optimized out, contextID=value optimized out, use_glx_1_3=0, renderType=0) at glxcmds.c:353 #8 0x10002260 in ?? () #9 0x10003d48 in ?? () #10 0x0fc7d8ec in generic_start_main () from /lib/libc.so.6 #11 0x0fc7da34 in __libc_start_main () from /lib/libc.so.6 #12 0x in ?? () --- 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: glxinfo segfaults with r300
On Fri, 2006-04-14 at 10:38 +1000, Benjamin Herrenschmidt wrote: With an r300 DRI checked out a couple of days ago I get a SEGV with the backtrace below, I will try updating from CVS and looking at it more closely later as I find some time... Same with current CVS, will investigate later unless you fix it in the meantime :) Ben. --- 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
Insane build system (Was: glxinfo segfaults with r300)
On Fri, 2006-04-14 at 11:00 +1000, Benjamin Herrenschmidt wrote: On Fri, 2006-04-14 at 10:38 +1000, Benjamin Herrenschmidt wrote: With an r300 DRI checked out a couple of days ago I get a SEGV with the backtrace below, I will try updating from CVS and looking at it more closely later as I find some time... Same with current CVS, will investigate later unless you fix it in the meantime :) Ok, I got bitten by the build system again... Checking out a fresh mesa source tree, doing a make linux-dri-ppc in it, what hapens is that - mesa bits are built using GL/internal/*.h includes from the source tree - DRI bits are built using GL/internal/*.h includes from the install prefix (the distro basically) Of course, they didn't match, thus I end up with non-matching GLcontext structure among others... I'm not sure at this point what's going on with the Makefiles Ben. --- 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: Insane build system (Was: glxinfo segfaults with r300)
On Thu, 2006-04-13 at 22:04 -0700, Ian Romanick wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Benjamin Herrenschmidt wrote: Ok, I got bitten by the build system again... Checking out a fresh mesa source tree, doing a make linux-dri-ppc in it, what hapens is that - mesa bits are built using GL/internal/*.h includes from the source tree - DRI bits are built using GL/internal/*.h includes from the install prefix (the distro basically) Of course, they didn't match, thus I end up with non-matching GLcontext structure among others... GLcontext should come from mtypes.h, and that file is *never* supposed to be installed anywhere on the system. Yes, but GLcontext itself is made of things like GLimports etc.. that come from other files, including GL/internal/glcore.h. It seems that it's where the mixup happens. Some bits of the build use the installed version and some bits use the one in the tree. They should obviously all be in the tree. Since we're supposed to be able to have some ABI version skew between libGL and DRI drivers, some changes in GL/internal/dri_interface.h and glcore.h should be okay. What are the actual diffs? Not sure at this point, but the problem ends up being ctx-DriverCtx at a different offset within GLcontext between mesa context.c and r300_tex.c. Looks like to get the stuff built properly, one has to build first, make install, make clean and rebuild, and finally re-make install I'm not sure at this point what's going on with the Makefiles -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (GNU/Linux) iD8DBQFEPy1gX1gOwKyEAw8RAqDnAKCQDRKckOTTzpVq9/yMwUGCUWz/VQCfazqB /tnfoibBSaPfSQpfwGlWJ0o= =HJmY -END PGP SIGNATURE- --- 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: Insane build system (Was: glxinfo segfaults with r300)
On Fri, 2006-04-14 at 15:15 +1000, Benjamin Herrenschmidt wrote: Not sure at this point, but the problem ends up being ctx-DriverCtx at a different offset within GLcontext between mesa context.c and r300_tex.c. Looks like to get the stuff built properly, one has to build first, make install, make clean and rebuild, and finally re-make install Oh, and I'm not even sure where the installed versions came from... looks like it could have been from an X.org install (does it install GL/internal/* stuff too ?) Hrm... did make install which updated headers, rebuilt all and still crash... so something else is causing r300_tex.c to be built with a different idea of what GLcontext is than the rest of mesa, maybe some #define related to an EXTension or something like that... Ben. --- 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: xorg HEAD + Mesa HEAD = boom
Ok, I rebuild it all from fresh CVS checkouts today and made sure the trees had no stale .o file or anything. Result is, it doesn't crash, but doesn't work very well neither. Machine is a ppc32 laptop, Mesa/DRI built with TLS enabled and X built with the new enable-glx-tls option from Kristian. So far, what I've been able to collect is: - DRI r300 doesn't work. I get that when running any GL app: libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering - AIGLX doesn't work, probably for the same reason as above. Message in log is: (EE) AIGLX error: Calling driver entry point failed(EE) GLX-DRI: reverting to software rendering - When using glxgears and EXA, the gears (software rendering by GLcore on server side) are garbage all over the framebuffer. Looks like the pitch is wrong, not sure exactly what's up there at this point. Seems to work ok with XAA. (I haven't tried indirect GL for ages since until recently, DRI worked fine, so this might be an old breakage). At this point, I didn't have any time to try to track down these issues, thus this email, in case I wake up with everything fixed in CVS tomorrow morning :) Cheers, Ben. --- 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: xorg HEAD + Mesa HEAD = boom
On Thu, 2006-03-30 at 10:36 +0300, Daniel Stone wrote: On Thu, Mar 30, 2006 at 04:50:52PM +1100, Benjamin Herrenschmidt wrote: On Thu, 2006-03-30 at 16:23 +1100, Benjamin Herrenschmidt wrote: The one used to build libGL and the DRI was a bit less up to date and had some stale junk I missed, so I think the problem is my fault. (I've been hacking on a native ppc dispatch but it's still incomplete). Rebuilt with up to date on both sides and gets that (though it's still anoncvs and thus might not have caught up with your latest fixes): anoncvs is only *two* *minutes* behind, in the worst case. Yah, I checked out the non-anon CVS and it had no diffs Ben. --- 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: xorg HEAD + Mesa HEAD = boom
Update your Mesa CVS and try again. I checked in some changes a few hours ago. Ok, in fact, I have 2 Mesa trees, one used to build the server and one used to build libGL, DRI, etc... :) (the later because I use it for experimenting with the DRI). The one used to build the server is up to date vs. anoncvs as of now, though I suppose it could also be anoncvs being slow as hell to replicate... I haven't tried the real CVS as I didn't have my ssh keys at hand back then. The one used to build libGL and the DRI was a bit less up to date and had some stale junk I missed, so I think the problem is my fault. (I've been hacking on a native ppc dispatch but it's still incomplete). I'm not sure 100% the client library caused the server to crash tho, it might have to do with AIGLX maybe going through the client dispatch from the server. So forget about it for now, I'll re-test with clean builds. Cheers, Ben. --- 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: xorg HEAD + Mesa HEAD = boom
On Thu, 2006-03-30 at 16:23 +1100, Benjamin Herrenschmidt wrote: The one used to build libGL and the DRI was a bit less up to date and had some stale junk I missed, so I think the problem is my fault. (I've been hacking on a native ppc dispatch but it's still incomplete). Rebuilt with up to date on both sides and gets that (though it's still anoncvs and thus might not have caught up with your latest fixes): 0: /usr/local/xorg/bin/X(xf86SigHandler+0xa4) [0x10082344] 1: [0x100374] 2: [0x10bb3e50] 3: /usr/local/xorg/lib/xorg/modules/extensions/libGLcore.so [0xf616ec4] 4: /usr/local/xorg/lib/xorg/modules/extensions/libglx.so(__glXUnrefDrawable+0x68) [0xf99510 c] 5: /usr/local/xorg/lib/xorg/modules/extensions/libglx.so [0xf993450] 6: /usr/local/xorg/bin/X(FreeClientResources+0xe4) [0x10027f28] 7: /usr/local/xorg/bin/X(CloseDownClient+0x210) [0x10042ce4] 8: /usr/local/xorg/bin/X(Dispatch+0x39c) [0x10043dc0] 9: /usr/local/xorg/bin/X(main+0x47c) [0x10025170] 10: /lib/libc.so.6 [0xfc558ec] 11: /lib/libc.so.6 [0xfc55a34] --- 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: radeon problems with current cvs code
Load DRM with option no_wb=1 what is it for and how do I do it? Well... it tells your DRM to not try to do writeback through AGP (that is to not let the video card write various status informations back to memory via the AGP bus). Doing AGP writeback is faster, but on some chipsets, it doesn't work properly. The driver tries to detect it, but we had some examples in the past where the detection would say ok while it's still unreliable. This option forces not to do it. To do that, you either: modprobe radeon no_wb=1 (Or edit the appropriate modultils config file to have that option by default) Or if the module is built-in the kernel, boot the kernel with radeon.no_wb=1 On the kernel comand line. Try latest DRM CVS I have kernel 2.6.16. I saw that source files such as radeon.c were identical to the ones in DRM CVS. Am I wrong? There is no such file as radeon.c that I can remember :) the drm CVS has a slightly more up to date version than 2.6.16. To build it in linux, go to linux-core and type make DRM_MODULES=radeon At the moment I have a kernel compiled without module support. And the radeon drm is built-in. Do I have to change that? If it works for you, stay with it. At the moment it works, but xgl is slow with movies. I saw this sentence in the suse site: Driver has neither pBuffer nor FBO support. When using a composite manager all windows are rendered in software and only compositing is hardware accelerated. Astonishingly, this works well enough for most use cases. What does it mean? That is, is the driver _never_ going to have that support? It will, just no yet. It's beeing developped on intel chipsets at the moment and will probably be ported over at one point. I can't tell more precisely. Ben. --- 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: radeon problems with current cvs code
On Sat, 2006-03-25 at 02:26 +0100, Luca Dionisi wrote: I'm having problems with Xorg built from cvs sources very recently. I've also built from cvs sources libdrm and the latest kernel (2.6.16) with the drm enabled for my card (radeon) I don't know for sure, but I think my problem is with the video driver (the ati open source driver) The syptom is that Xorg start, but sometimes it hangs hup very quickly, sometimes when I change VT, sometimes when I click the mouse, ... Most of the times my whole machine becomes unusable. Any help please! I attach the log and the xorg.conf Looks like the engine is going nuts. Can you try: - Disabling AGP fast write - Lowering AGP speed - Load DRM with option no_wb=1 - Try latest DRM CVS And tell me if any of these helps. Also, when you say very recently for your X.org build, when exactly did you get the ati driver from CVS ? If it was more than 4 days ago, it might be worth updating and trying again. Ben. --- 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: r300 freezes the X server after resume from suspend2 (suspend to disk)
nvidia-agp is loaded long time before drm.ko and radeon.ko here, so this can not be the reason. Can you try with the driver in ati-1-0-branch from CVS ? You may need a 7.0 server tho .. Ben. --- 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: cvs radeon driver build problem
I have not rebuilt xserver, however I looked into cvs today and I noticed : Stop using xf86PciInfo.h, instead use a local copy of the PCI IDs we need in atipciids.h so we can update the ATI driver independently of the server when new chips are added Well that did help... partly since I do not see previous error message, but the new one says: radeon_exa.c: In function `RADEONGetOffsetPitch': radeon_exa.c:160: error: structure has no member named `pixmapPitchAlign' radeon_exa.c:163: error: structure has no member named `pixmapOffsetAlign' In file included from radeon_exa.c:334: .../... The EXA APIs changed in xserver CVS HEAD. So either you update your xserver too, or you can use the newly created ati-1-0-0-branch of the radeon driver which should build with the old server (it's aimed at producing a bug fixed version that will build/install with existing 7.0 servers). The fix for the PCI IDs should be in the branch Ben. --- 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: [r300] Lockups
On Fri, 2006-03-10 at 10:12 +, Aapo Tahkola wrote: On Thu, 02 Mar 2006 09:27:37 +0100 Christoph Brill [EMAIL PROTECTED] wrote: Hi list, I'm still seeing lots of lockups with my r300 (Radeon 9700Pro) with current drm/mesa/xf86-video-ati cvs. I think I found a reproducable lockup. It happens when I use Wings3d[1] (a free modeller). Wings has a grid for orientation when I move around the camera it works fine. But as soon as the grid hits the borders of the window, my system locks up. I'm not 100% sure so if anyone else can reproduce this it would be great. As long as it gets solved by initializing the card with fglrx, I don't see any point in investigating. Does it lock only if you hit upper or lower bound of screen? You don't see any point ? You mean that you consider it a good solution to have to run fglrx first in the long run ? I hope you are kidding :) /me with his ppc without a fglrx to initialize the card ... Cheers, Ben. --- 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: R300 dri and sleep
I was unable to run a completely naked X, as if I try to run glxgears without a window manager I get a strange result... http://laera.web.cs.unibo.it/no-wm.png Does this still happen with latest DRI from CVS ? Using vtwm if I run glxgears I get ~ 2600 fps, then if I run 3ddesk (http://desk3d.sourceforge.net/) and restart glxgears it runs slower, ~1700 fps. On gnome I've also used BillardGL to test perfs: after 3ddesk or xscreensaver it can't reach the 80 fps previously obtained. I hope it can help. Ok, I'll see if I can reproduce Ben. --- 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: R300 dri and sleep
I was unable to run a completely naked X, as if I try to run glxgears without a window manager I get a strange result... http://laera.web.cs.unibo.it/no-wm.png Using vtwm if I run glxgears I get ~ 2600 fps, then if I run 3ddesk (http://desk3d.sourceforge.net/) and restart glxgears it runs slower, ~1700 fps. On gnome I've also used BillardGL to test perfs: after 3ddesk or xscreensaver it can't reach the 80 fps previously obtained. Remind me what machine this is ? My rv350 laptop gets about 1800fps all the time... I'll try again after I reboot the box later. Ben. --- 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: R300 dri and sleep
I was unable to run a completely naked X, as if I try to run glxgears without a window manager I get a strange result... http://laera.web.cs.unibo.it/no-wm.png Using vtwm if I run glxgears I get ~ 2600 fps, then if I run 3ddesk (http://desk3d.sourceforge.net/) and restart glxgears it runs slower, ~1700 fps. On gnome I've also used BillardGL to test perfs: after 3ddesk or xscreensaver it can't reach the 80 fps previously obtained. Do you have pageflipping enabled ? Ben. --- 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: Status of X600 (5B62) support inquiry; bug 5413
For Q1, the status is that it should work, but apparently it locks up for some unknown reason for some people. There was a significant fix for potential lockup problems in the radeon ddx driver in xorg modular cvs, which may or not help you. You should try the snapshots, you can try patching the drm that comes with them or use your own, there is not much you can do to build it wrong. Which gets us to Q2, that patch 4745 is needed for drm/dri (and dma ddx) support of new radeons (it is nothing more than new ids, all the cleanup was commited), but it's not in cvs because it sometimes causes lockups (even though the lockups aren't exactly caused by drm, but xorg ddx if it uses the drm module). (Note though that the ids of new radeons already present in drm are just as likely to cause lockups as those which aren't.) There are more fixes comming into the DDX everyday or so too :) So if it doesn't work, you may want to lurk at the CVS commit list and retry regulary. Ben. --- 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: radeon memory map DRM patch
Well I already looked at it and thought it's impossible this happens ;-). Just for completeness, I tested with the drm patches too which didn't change anything. Unless I missed something in my tests... RADEONDRIRefreshArea() is never called. I verified that ShadowFBInit() does succeed though (returns TRUE). I though about a possible ordering issue with ShadowFBInit() and thus moved the call to RADEONDRIFinishScreen to much later in RADEONScreenInit() but the problem is the same. I'll try to trace through the ShadowFB code but we are deep into realms of the server where I have very little understanding... Ben. --- 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
radeon page flipping fixed BUT ...
I found the problem I introduced with Page Flipping, I pushed a fix to CVS, however, I still see a (different) issue. I don't think it was introduced by my patch but I don't have an old X to test with at the moment... When using Page Flipping, I launch glxgears, it's all fine. Now I move the window around, the content heavily flickers, alternating between the gears and a black content. When I drop the window (stop moving it), it will either be the gears running happily ... or the black content. In that later case, it will stay black until I move the window again and drop it at the right time to get the gears back. I don't know much about what's going on with DRI when moving windows around so I would appreciate if somebody more familiar with that stuff could help me figure that one out. Ben. --- 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: dri on r300
On Wed, 2006-02-22 at 03:01 -0500, Patrick McFarland wrote: On Tuesday 21 February 2006 01:29, Benjamin Herrenschmidt wrote: On Sat, 2006-02-18 at 21:45 -0500, Patrick McFarland wrote: Well, I finally upgraded my Radeon 8500 to a Radeon 9600, however trying to use Xorg's DRI drivers with it causes X to completely lock up on startup. ATI's binary drivers work fine, however. Also, starting Xorg without Load dri works fine Xorg's radeon driver. Does it work any better with current cvs HEAD for both Xorg ATI driver and the kernel DRM cvs HEAD radeon driver ? Ben I'll tell you soon as I can figure out why Mesa thinks I don't have stdarg.h and stddef.h. I imagine this is going to require pounding Mesa with a hammer until it quits being stupid. You updated your compiler ? you may need to rebuild makedepends Ben. --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: dri on r300
On Sat, 2006-02-18 at 21:45 -0500, Patrick McFarland wrote: Well, I finally upgraded my Radeon 8500 to a Radeon 9600, however trying to use Xorg's DRI drivers with it causes X to completely lock up on startup. ATI's binary drivers work fine, however. Also, starting Xorg without Load dri works fine Xorg's radeon driver. Does it work any better with current cvs HEAD for both Xorg ATI driver and the kernel DRM cvs HEAD radeon driver ? Ben --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon memory map DRM patch
On Fri, 2006-02-17 at 19:37 +0100, Roland Scheidegger wrote: Benjamin Herrenschmidt wrote: I finally commited the X driver side of the radeon memory map patches to the xorg CVS. I just noticed this breaks page flipping here (rv250), obviously with xaa only (heavy flicker). This is without the drm patch, but I doubt it makes a difference. To be more exact, the 3d window itself is fine, just the window borders, background etc. flickers, so it looks like the refresharea stuff might no longer be working. Ok, will have a look this week-end. Ben. --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon memory map DRM patch
On Fri, 2006-02-17 at 19:37 +0100, Roland Scheidegger wrote: Benjamin Herrenschmidt wrote: I finally commited the X driver side of the radeon memory map patches to the xorg CVS. I just noticed this breaks page flipping here (rv250), obviously with xaa only (heavy flicker). This is without the drm patch, but I doubt it makes a difference. To be more exact, the 3d window itself is fine, just the window borders, background etc. flickers, so it looks like the refresharea stuff might no longer be working. I didn't see anything obvious, so this will need more digging. Not sure I'll have any time this week-end though so you are welcome to beat me at it if you have an idea ;) Ben. --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 dri and sleep
On Thu, 2006-02-16 at 10:05 +0100, Dario Laera wrote: Benjamin Herrenschmidt wrote: It could be some other thing ... The radeonfb kernel driver tries to save restore as much registers as it knows about on sleep / wakeup but it might be missing one or two ... it would be interesting to do register dumps and compare here. Well, I've never worked on a linux driver, but if someone can give me some instructions, I can try to look at the register dump, I should have time next days. I don't have time to work on that with your at the moment, but please ping me in a couple of weeks unless somebody else pops up to guide you through the process. Ben. --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: R300 dri and sleep
On Tue, 2006-02-14 at 14:16 +0100, Dario Laera wrote: Hi all, I'm running r300 driver on my powerbook with ati 9600, and I've noted this problem: if I run glxgears after boot I get ~2600 fps, while after a sleep/resume I get ~1600 fps. I don't know if it's due to the dri driver, to the xorg radeon driver(bad frequency scaling?) or to some other thing, please redirect me to the right ml if this is not a dri problem. It could be some other thing ... The radeonfb kernel driver tries to save restore as much registers as it knows about on sleep / wakeup but it might be missing one or two ... it would be interesting to do register dumps and compare here. Ben. --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (#3)
Current DRM CVS HEAD doesn't work for me. However it does work with a small patch applied: https://bugs.freedesktop.org/show_bug.cgi?id=5450#c3 Does it make sense to test that DRM code with the new X patch? You mean the DRM without my old patch doesn't work ? What was the symptom ? lockups ? So it worked in the short period of time when my old patch was in and broke when it was backed off right ? That's interesting... In that case I would have expected my new patch to work but you say you still have lockups. Can you try all combinations of my old patch, new patch, X patch !X patch and let me know what the results are ? Thanks, Ben. --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (#3)
On Mon, 2006-02-13 at 11:53 -0800, Donnie Berkholz wrote: Kevin Shanahan wrote: All seems good. No regressions on my Radeon Mobility M6 LY and Radeon 64MB DDR (7200). VT switch problems from #2 now fixed. Radeon 9800 Pro still locks up with 3D, but that's not a regression. I just had some trouble with VT switching -- when switching back to X, I lost my cursor and a small black minify box appeared near the lower right of my screen (perhaps where the cursor was when I switched VTs?). XAA or EXA ? Is this reproduceable ? Will the cursor go back to normal when changed again by a program ? Ben. --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (#3)
Can you try all combinations of my old patch, new patch, X patch !X patch and let me know what the results are ? If it's perfectly stable with your latest patch and without that one bad Mesa patch, would that convince you it's not a bug in DRM/DDX? :) Well, I'm navigating between lots of conflicting reports so yes, any solid data like that would be very useful. Also, is it stable if not using 3d ? Thanks, Ben. --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (#3)
On Sun, 2006-02-12 at 19:25 +0100, Tilman Sauerbeck wrote: Tilman Sauerbeck [2006-02-12 13:39]: Benjamin Herrenschmidt [2006-02-10 18:12]: Here's a 3rd set of patches. Please report regressions ASAP as I intend to merge those in the various CVS trees real soon now. [...] Also, I fixed a potential issue in the DRM with machines where AGP writeback doesn't work (we would still rely on AGP writeback for the ring read ptr instead of reading it from a register). I believe these 2 patches introduce a hardware lockup problem in 3D mode for me. It's not reliably reproduced though, so I'm not sure n/m, I just reproduced it with patch set #2, so it's not a regression. What if you only apply the X patch and not the DRM patch ? Ben. --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes (#3)
On Sat, 2006-02-11 at 09:04 +1030, Kevin Shanahan wrote: On Fri, Feb 10, 2006 at 06:12:24PM +1100, Benjamin Herrenschmidt wrote: Here's a 3rd set of patches. Please report regressions ASAP as I intend to merge those in the various CVS trees real soon now. Thanks Ben, compiling now - I just thought I'd mention while I remember that there's a small problem with this (and previous) patch: radeon_cursor.c:35: error: syntax error before '/' token radeon_cursor.c:35: error: stray '#' in program radeon_cursor.c: In function 'RADEONCursorAllocEXA': radeon_cursor.c:138: warning: too many arguments for format radeon_cursor.c: In function 'RADEONUseHWCursorARGB': radeon_cursor.c:361: warning: unused variable 'info' Looks to be cause by the C++ style // comment. Will have a look, thanks. Ben. --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] new radeon memory map fixes (#3)
Here's a 3rd set of patches. Please report regressions ASAP as I intend to merge those in the various CVS trees real soon now. I fixed a couple of possible segfaults I found due to initialisation issues (places relying on pScrn-pScreen from within ScreenInit() and incorrect ordering of colormap vs. cursor inits for example). Also, I fixed a potential issue in the DRM with machines where AGP writeback doesn't work (we would still rely on AGP writeback for the ring read ptr instead of reading it from a register). Patches are at: Xorg driver patch: http://gate.crashing.org/~benh/radeon-memmap-7.0-3.diff DRM patch: http://gate.crashing.org/~benh/radeon-memmap-drm-4.diff Cheers, Ben. --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
On Thu, 2006-02-02 at 07:08 +1030, Kevin Shanahan wrote: On Mon, Jan 30, 2006 at 09:41:30AM +1030, Kevin Shanahan wrote: On Sun, Jan 29, 2006 at 04:04:50PM +1100, Benjamin Herrenschmidt wrote: On Sun, 2006-01-29 at 10:06 +1030, Kevin Shanahan wrote: I also tested on my desktop with Radeon 9800 Pro (R350), but no miracle improvements there. It still locks up after about 1 minute of glquake, but no problems if not using 3d apps. I'm using xorg 6.9 packages there but with libgl1-mesa-dri (6.3.2-2) instead of xlibmesa-dri. With both the DRM and the server patch ? Ok, so it seems that my patch fix some lockups on some 9800's but not all of them... bummer. Yes, I patched both. Maybe there were some lockups solved in Mesa 6.4, but I'll wait until Debian packages are available to test that. Okay, I've now updated to Mesa 6.4.1 but unfortunately it still locks up. Possibly this is just a typical lockup, but I'll describe what I'm seeing: What happens if you try (serparately): - With the X patch but not the DRM patch - Modify RADEONInitMemoryMap() in radeon_driver.c (X driver) to change that line: mem_size = INREG(RADEON_CONFIG_MEMSIZE); to: mem_size = INREG(RADEON_CONFIG_MEMSIZE) / 2; And tell me if any of those makes a difference... Ben. --- 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://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
