Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel
I'm adding dri-devel@ to CC, since this suggested patch touches TTM code, and none of the Nouveau code. TTM patches go via dri-de...@. Thanks. On Wed, 10 Mar 2010 18:51:21 +0530 Arvind R wrote: > Hi, > Following is a simple patch that is needed in nouveau to get > accelerated X on a Xen dom0 pv_ops kernel. The kernel is jeremy's > 2.6.31.6 as of 20100222. The whole gpu tree of nouveau (which is > almost the mainline merge), was substituted into the kernel-tree. > All components of X (mesa, Xorg-server-7.5, xf86-nouveau, libdrm) > used of the same day. > > Patch: > diff -Naur nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c > nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c > --- nouveau-kernel.orig/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-01-27 > 10:19:28.0 +0530 > +++ nouveau-kernel.new/drivers/gpu/drm/ttm/ttm_bo_vm.c 2010-03-10 > 17:28:59.0 +0530 > @@ -271,7 +271,10 @@ > */ > > vma->vm_private_data = bo; > - vma->vm_flags |= VM_RESERVED | VM_IO | VM_MIXEDMAP | > VM_DONTEXPAND; > + vma->vm_flags |= VM_RESERVED | VM_MIXEDMAP | > VM_DONTEXPAND; > + if (!((bo->mem.placement & TTM_PL_MASK_MEM) & > TTM_PL_FLAG_TT)) > + vma->vm_flags |= VM_IO; > + vma->vm_page_prot = vma_get_vm_prot(vma->vm_flags); > return 0; > out_unref: > ttm_bo_unref(&bo); > > This patch is necessary because, in Xen, PFN of a page is > virtualised. So physical addresses > for DMA programming needs to use the MFN. Xen transparently does > the correct translation > using the _PAGE_IOMEM prot-bit in the PTE. If the bit is set, > then Xen assumes that the backing > memory is in the IOMEM space, and PFN equals MFN. If not set, > page_to_pfn() returns MFN. > > The patch enables the ttm_bo_vm_fault() handler to behave > correctly under Xen, and has no > side-effects on normal (not under Xen) operations. The use of > TTM_PL_FLAG_TT in the > check assumes that all other placements are backed by device > memory or IO. If there are > any other placements that use system memory, that flag has to be > OR'ed into the check. > > The above patch has no implications on a normal kernel or a Xen > pv_ops kernel booted without > the Xen hypervisor. My testing is on a debian-lenny environment > on a Core2 processor with > nVidia GeForce 9400 GT. -- Pekka Paalanen http://www.iki.fi/pq/ -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Nouveau] [Discussion] User controls for PowerManagement
On Sun, 10 Jan 2010 12:43:02 +0200 Alexey Dobriyan wrote: > > On Thu, 7 Jan 2010 22:44:24 +0100 > > r.spl...@umail.leidenuniv.nl wrote: > > > > > 1. joi pointed out that procfs is deprecated, and I should use > > > sysfs instead. > > /proc is not deprecated per se, you simply shouldn't expose > everything you know to userspace, because it will be impossible > to remove later. I think adding "random crap" to procfs is frowned upon nowadays, that's probably what he meant. Attributes should be in sysfs. What to expose is another question, you are right. If the interface is just temporary, it should probably go into debugfs. That way one can have the code in the kernel proper, not fear about freezing it, and prevent people from finding it by accident. And it should be guarded by an "EXPERIMENTAL, DANGEROUS" Kconfig option in any case. -- Pekka Paalanen http://www.iki.fi/pq/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Nouveau] [Discussion] User controls for PowerManagement
Adding dri-devel@ to CC. On Thu, 7 Jan 2010 22:44:24 +0100 r.spl...@umail.leidenuniv.nl wrote: > With some progress in PowerManagement support (there's a patch > nearly done for reading the P-tables, written mostly by xexaxo, > derived from thunderbirds nvclock, with 0x40 adjustments from > myself) in my opinion it's time to think about the user aspect of > this. My personal idea for GPU scaling was similar to that of CPU > scaling in appearance eventually. When you look at the > cpufreq-applet for Gnome, you see the choice between every > supported CPU speed, and an option for Automatic scaling. To make > an application like this possible nouveau needs to communicate > with users. I was thinking a procfs or sysfs node for outputting > a readable table with possible modes like: > > 03: CPU=135MHz,Shdr=135MHz,Mem=135MHz,Vlt=0.8V,Fan=80%; > ... > > the node name would be something like pm_supported. Another node > named pm_current could output the current mode (for instance 03), > and be writable to set the desired mode. Mode numbers will be the > identifier given by pm_supported, found in the powermode table. A > third node would then be required to set auto scaling on or off > (called pm_auto ?). All those nodes could eventually be placed in > a separate subdirectory (pm?) > > 1. joi pointed out that procfs is deprecated, and I should use > sysfs instead. There are two reasons to use procfs: > - DRM has a pointer to the right DRM subfolder (/proc/drm/ number>) which can be obtained by drm_device.control->proc_root. > number>Ofcourse, if there's > something similar for sysfs available, then there's no problem. > Otherwise procfs simply saves a lot of hassle as long as DRM > still promotes procfs to the device drivers. > - sysfs was designed for "one value per node". The output of the > pm_supported node would be an entire table. Is this on par with > the design of sysfs? So: procfs or sysfs? > > 2. It sounds sensible to me to have one scaling algorithm > (whatever that may become... first things first). When you can > scale you can have the maximum performance as soon as you need > it... so the aim should be maximum powersaving at all time, > without sacrificing on performance. Agreed, or should there be > several "auto" modes for different situations? I recall someone (you?) saying this is only for testing for now, and the proper user interface can be done later. In any case, I'd like to suggest discussing it on dri-devel@, since there are other drivers wanting to expose similar features. Hopefully people working on power management interfaces on intel and radeon can comment on this, like is there an agreed user interface design yet. btw. I think max powersaving and no performance loss are mutually exclusive, since changing power modes is not free nor instantenous. Or is it? How much of the card you need to stop to change clocks and volts? Do you need to sync to vblank to prevent visual glitches? -- Pekka Paalanen http://www.iki.fi/pq/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Nouveau ctxprogs (Re: [git pull] drm)
On Thu, 10 Dec 2009 15:33:13 -0500 "C. Bergström" wrote: > Pekka Paalanen > > > The big question is what we call ctxprogs: binary blobs that are > > clearly executable, running somewhere in the GPU. No-one seems > > to know, if those are copyrightable, or if they can be > > redistributed. In their current form, they have been recorded > > from the nvidia proprietary driver using mmiotrace, and copied > > verbatim for each card type. > > --- > (apologies about the copy paste of thread, but I'm joining the > list late) > > Please see my other response. From my perspective there is only > technical issues remaining and no license issues. I am just > evaluating and receiving information from one of the nouveau > devs. However, ctxprogs was obtained in the same way that the > rest of the information was via dumping from the mmio-traces. > (As stated above) When Nouveau is able to generate ctxprogs itself, I completely agree. But the current situation is a little different. We are not collecting just the basic blocks individually like has been done for everything else. We are copying a complete program or something that is a non-trivial composition. The proprietary driver might be generating it on the fly from basic blocks, or it might contain the complete programs. We only see the stream of data going into the card. Apparently there is also freedom to do things right more than one way(?), so it is not trivial in the sense that the hardware would force it to be exactly what we see. How sure you are that there won't be a problem and that it is not "actually copying a copyrighted work"? Did you already see things the way I put it here? Thanks. -- Pekka Paalanen http://www.iki.fi/pq/ -- 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
On Thu, 10 Dec 2009 15:35:08 -0500 Will Dyson wrote: > This seems similar to the unfortunate situation with the b43 > wireless card firmware. Broadcom refuses to provide the firmware > under a redistributable license (or even as files separate from > their proprietary drivers). This did not stop b43 from being > included in Linux. Distributions have dealt with it by providing > a script that downloads the proprietary driver and extracts the > firmware from it to files in /lib/firmware. > > Do you think that a similar solution for nouveau would be legally > problematic? Or is the issue technical, since you mention that the > ctxprogs were obtained by mmiotrace, instead of a more > straightforward extraction from the binary driver blobs? It is definitely a lot harder than a script that just downloads something. It would have to: - download the proprietary driver - install it and load it into the kernel - activate mmiotrace (if it even is compiled in) - reconfigure and start X and quit - analyse the mmiotrace log to extract the ctxprog and ctxvals - undo all the proprietary setup I cannot comment on the legal side, but the practise sounds too cumbersome. Thanks. -- Pekka Paalanen http://www.iki.fi/pq/ -- 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
On Thu, 10 Dec 2009 10:42:46 -0800 (PST) Linus Torvalds wrote: > On Thu, 10 Dec 2009, Maarten Maathuis wrote: > > > > You assume that Red Hat has full control over the project, > > which i don't think is the case. The reason it isn't in staging > > yet (as far as i know) is because of some questions over the > > copyright of some (essential) microcode. Either the question > > needs to be answered, or it has to be reverse engineered to the > > point that it's possible to generate it. > > I think people are just making up excuses, as evidenced by the > fact that you're quoting a different excuse than I've heard > before. That is because priorities change. The ABI has not seen changes for some time now, so it's probably not an issue anymore. And it is not an issue for staging. The other issue has become more important. That said, there are features that likely require revising the ABI at some point, and we know about those already. > The fact is, if there are license questions, then Fedora had > better not be distributing the code either. And they clearly are. I've no idea how they pulled that, but I have not heard anyone say that there are *no* legal issues at all. > I've heard the "but it's hard to merge" excuse too - which I also > know is bullshit, because I can look at the git tree Fedora > apparently uses, and it merges without any conflicts what-so-ever. No-one has said that about Nouveau, have they? > The most common excuse is the "oh, but it might change" crap. But > that's not even a very good excuse to start with, and it's what > staging is for anyway. Yes, and to my understanding Nouveau is past that excuse. People just like to quote what they heard last. The big question is what we call ctxprogs: binary blobs that are clearly executable, running somewhere in the GPU. No-one seems to know, if those are copyrightable, or if they can be redistributed. In their current form, they have been recorded from the nvidia proprietary driver using mmiotrace, and copied verbatim for each card type. Would you be willing to pull that kind of stuff into Linux? I would not even dare sending them to the Linux firmware repository, since they have some license requirements, too. -- Pekka Paalanen http://www.iki.fi/pq/ -- 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: drm git branches revisited
On Wed, 2 Dec 2009 14:10:11 +1000 Dave Airlie wrote: > So I'm going to change the layout of my git branches again, > because my current plan isn't working for me. > > At the moment drm-next is considered the branch to base new work > off and to also for downstream trees to > pull from, this is changing. > > I will now maintain > > drm-core-next : a branch with all the core DRM/KMS changes in it, > please base all downstream sub-driver > trees from this branch in the future. This branch will not > rebase, it may pull in a downstream driver tree in > the pre-merge window time, and/or when some patch from that tree > is required for a patch to the mainline. > This will be the basis of any trees I send to Linus. Previously, I've been doing: git diff drm/drm-next...nouveau/master If I understand correctly, to gather all the Nouveau development I should now use: git diff --stat drm/drm-core-next...nouveau/master git log ^drm/drm-core-next nouveau/master where nouveau is the nouveau/linux-2.6 repo. Right? Why do I see changes to radeon, i915 and drm core, too? The last time drm-next was merged into nouveau/master was Nov 4th and I am quite sure there are no radeon patches committed to nouveau/master, it has all come from drm-next or linus' merges. My intent was to create a tentative Nouveau patch and run it through checkpatch.pl to see if there are new things to fix. I've been doing that occasionally and running it takes roughly an hour. > drm-radeon-next: a tree like Eric's drm-intel-next where radeon > specific changes will be queued up. > > drm-next: This tree will be rebased quite regularly (2-3 days) > with a git pull of the latest, drm-core-next, drm-radeon-next > and drm-intel-next, so that the code in drm-next is tested > better. You should use this tree for testing latest drm stuff > with an eye to the next Linus kernel. -- Pekka Paalanen http://www.iki.fi/pq/ -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
libdrm headers (Re: RFC: libdrm repo)
On Mon, 23 Nov 2009 17:12:07 +0100 Michel Dänzer wrote: > On Mon, 2009-11-23 at 10:55 -0500, Kristian Høgsberg wrote: > > The headers in include/drm will be installed and libdrm_radeon > > should be updated to use those headers instead of the ones in > > radeon/ since they're what's upstream. > > At least one of the headers in question - radeon_bo.h - isn't in > the kernel (and it probably makes no sense to put userland > specific headers like that in the kernel) and is outdated in > include/drm. Now that we are talking about headers, what is the proper layout of *installed* headers? I'm leaving out $prefix in the following. include/drm/ I'd assume that should contain only the kernel headers, and those are going a away soonish or ASAP. (krh already tried to remove them ;-) include/drm/ seems to be also containing libdrm_radeon user API headers? include/intel_bufmgr.h libdrm_intel has their header sitting in the root include dir. include/nouveau/ almost all libdrm_nouveau headers are here, except nouveau_drmif.h, which should probably be moved. include/xf86drm.h include/xf86drmMode.h and then these two... So, each of the three drivers have their headers installed differently, and Nouveau manages to fail even in that. :-) What should installed header tree look like? -- Pekka Paalanen http://www.iki.fi/pq/ -- 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] drm_sysfs.c: Fix compile error on kernels > 2.6.31
On Sat, 24 Oct 2009 16:19:48 +0200 Johannes Obermayr wrote: > Hi, > > I tried compiling nouveau/linux-2.6 and Dave Airlie's git tree on > kernel 2.6.32-rc5 and received on both the same error. > > This patch fixes the error and let the code also compatible to > kernels < 2.6.32. > > I "robbed" some code from http://lwn.net/Articles/353496/ and > added only IF-loops... > > I tried compiling on kernels 2.6.32-rc5 and 2.6.31.3 - both works > fine... > > But I do not know whether it is wished that code which will be > merged into mainline kernel (someday) contains code that is only > needed for older kernel versions. #include is seen as a red flag and will never make it into the mainline. The proper fix must be done at the time Airlied merges Linus' tree to drm-next. Well, probably it is already fixed in Linus' tree, so there is nothing to fix, really. I've been wondering when the merge happens... btw. Nouveau does not carry backwards support, so when it does happen, all Nouveau users need to upgrade too. Users wishing to mix and match versions may find your patch useful. -- Pekka Paalanen http://www.iki.fi/pq/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon kernel module fails to compile
On Wed, 7 Oct 2009 16:19:48 +0200 Johannes Obermayr wrote: > Am Mittwoch, 7. Oktober 2009 14:59:00 schrieben Sie: > > Don't use that branch, it is outdated, the drm kernel stuff for > > radeon went into mainline long time ago. Please take kernel > > source from vanilla instead. > > > > Cheers, Johannes > > > > 2009/10/7 Johannes Obermayr : > > > Hi, > > > > > > I tried compiling radeon kernel module from nouveau/linux-2.6 > > > on openSUSE Build Service and received the attached output. > > > Is it a general failure or must I change something? > > > outdated? > > nouveau/linux-2.6 Well, "wrong" would be a more appropriate word than "outdated". The nouveau/linux-2.6 tree is for Nouveau development only, and if any other DRM driver in that tree is broken, nobody cares. The merge from drm-next likely introduced some internal API changes, and nouveau/linux-2.6 being the Nouveau tree, radeon is not fixed, until 1) radeon fixes get into drm-next, and 2) drm-next gets merged into nouveau/linux-2.6. If you want to test early radeon code, you should use whatever tree the radeon developers recommend. I do not know which tree that is. -- Pekka Paalanen http://www.iki.fi/pq/ -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: NULL pointer dereference at cfq_exit_single_io_context
On Sun, 04 Oct 2009 11:12:55 +0300 Ozan Çağlayan wrote: > Hi, > > The attached dmesg is obtained on a 2.6.30.8 with: > > - DRM patches mainly gathered from Fedora F-11 branch, > - The following patch from mainline which addresses kernel > bugzilla #13401: > > From: Jeff Moyer > Date: Fri, 11 Sep 2009 15:08:59 + (+0200) > Subject: cfq: choose a new next_req when a request is dispatched > X-Git-Url: > http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Ftorvalds%2Flinux-2.6.git;a=commitdiff_plain;h=06d2188644c85c56d243efab914f368d1d23c4a3 > > > The user which sent me the dmesg below tells that consecutive > attempts to boot into X with the *nouveau* driver is generally > not possible because of random lockups. > > I'll have access to the machine in this week so I can try > anything you want me to do. This problem should be fixed now, we debugged it for a long time. E.g. https://bugs.freedesktop.org/show_bug.cgi?id=23847 The commit: http://cgit.freedesktop.org/nouveau/linux-2.6/commit/?id=7798546495c04a810db86be34ba1f39e370fd325 "drm/nouveau: fix missized allocation for ttm_bo_global struct" I hope that solves your issue. -- Pekka Paalanen http://www.iki.fi/pq/ -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: fix _DRM_GEM addmap error message
Fix the error message: this is add, not rm.
Move the closing brace to proper spot: _DRM_GEM branch should not be
included in the block.
Signed-off-by: Pekka Paalanen
---
drivers/gpu/drm/drm_bufs.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index 6246e3f..3d09e30 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -310,10 +310,10 @@ static int drm_addmap_core(struct drm_device * dev,
resource_size_t offset,
(unsigned long long)map->offset, map->size);
break;
+ }
case _DRM_GEM:
- DRM_ERROR("tried to rmmap GEM object\n");
+ DRM_ERROR("tried to addmap GEM object\n");
break;
- }
case _DRM_SCATTER_GATHER:
if (!dev->sg) {
kfree(map);
--
1.6.3.3
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: GEM handles are u32, not int
Several functions in the GEM kernel API used int as handle type, but
user API has it __u32 which is also the intended type.
Replace int with u32.
Signed-off-by: Pekka Paalanen
---
drivers/gpu/drm/drm_gem.c | 11 +--
drivers/gpu/drm/i915/i915_gem.c |3 ++-
include/drm/drmP.h |4 ++--
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index ffe8f43..230c9ff 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -164,7 +164,7 @@ EXPORT_SYMBOL(drm_gem_object_alloc);
* Removes the mapping from handle to filp for this object.
*/
static int
-drm_gem_handle_delete(struct drm_file *filp, int handle)
+drm_gem_handle_delete(struct drm_file *filp, u32 handle)
{
struct drm_device *dev;
struct drm_gem_object *obj;
@@ -207,7 +207,7 @@ drm_gem_handle_delete(struct drm_file *filp, int handle)
int
drm_gem_handle_create(struct drm_file *file_priv,
struct drm_gem_object *obj,
- int *handlep)
+ u32 *handlep)
{
int ret;
@@ -221,7 +221,7 @@ again:
/* do the allocation under our spinlock */
spin_lock(&file_priv->table_lock);
- ret = idr_get_new_above(&file_priv->object_idr, obj, 1, handlep);
+ ret = idr_get_new_above(&file_priv->object_idr, obj, 1, (int *)handlep);
spin_unlock(&file_priv->table_lock);
if (ret == -EAGAIN)
goto again;
@@ -237,7 +237,7 @@ EXPORT_SYMBOL(drm_gem_handle_create);
/** Returns a reference to the object named by the handle. */
struct drm_gem_object *
drm_gem_object_lookup(struct drm_device *dev, struct drm_file *filp,
- int handle)
+ u32 handle)
{
struct drm_gem_object *obj;
@@ -344,7 +344,7 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data,
struct drm_gem_open *args = data;
struct drm_gem_object *obj;
int ret;
- int handle;
+ u32 handle;
if (!(dev->driver->driver_features & DRIVER_GEM))
return -ENODEV;
@@ -539,7 +539,6 @@ int drm_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
vma->vm_flags |= VM_RESERVED | VM_IO | VM_PFNMAP | VM_DONTEXPAND;
vma->vm_ops = obj->dev->driver->gem_vm_ops;
vma->vm_private_data = map->handle;
- /* FIXME: use pgprot_writecombine when available */
vma->vm_page_prot = pgprot_writecombine(vma->vm_page_prot);
/* Take a ref for this mapping of the object, so that the fault
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 140bee1..0e6c9cc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -111,7 +111,8 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
{
struct drm_i915_gem_create *args = data;
struct drm_gem_object *obj;
- int handle, ret;
+ int ret;
+ u32 handle;
args->size = roundup(args->size, PAGE_SIZE);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index e0f1c1f..eeefb63 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1441,7 +1441,7 @@ drm_gem_object_unreference(struct drm_gem_object *obj)
int drm_gem_handle_create(struct drm_file *file_priv,
struct drm_gem_object *obj,
- int *handlep);
+ u32 *handlep);
static inline void
drm_gem_object_handle_reference(struct drm_gem_object *obj)
@@ -1467,7 +1467,7 @@ drm_gem_object_handle_unreference(struct drm_gem_object
*obj)
struct drm_gem_object *drm_gem_object_lookup(struct drm_device *dev,
struct drm_file *filp,
-int handle);
+u32 handle);
int drm_gem_close_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
int drm_gem_flink_ioctl(struct drm_device *dev, void *data,
--
1.6.3.3
--
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
[PATCH] drm/kms: no need to return void value (encoder)
Cc: Francisco Jerez
Signed-off-by: Pekka Paalanen
---
include/drm/drm_encoder_slave.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/drm/drm_encoder_slave.h b/include/drm/drm_encoder_slave.h
index 821ec40..a8d8053 100644
--- a/include/drm/drm_encoder_slave.h
+++ b/include/drm/drm_encoder_slave.h
@@ -154,7 +154,7 @@ static inline int drm_i2c_encoder_register(struct module
*owner,
*/
static inline void drm_i2c_encoder_unregister(struct drm_i2c_encoder_driver
*driver)
{
- return i2c_del_driver(&driver->i2c_driver);
+ i2c_del_driver(&driver->i2c_driver);
}
void drm_i2c_encoder_destroy(struct drm_encoder *encoder);
--
1.6.3.3
--
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
[PATCH] drm/ttm: optimize bo_kmap_type values
A micro-optimization on the function ttm_kmap_obj_virtual().
By defining the values of enum ttm_bo_kmap_obj::bo_kmap_type to have a
bit indicating iomem, size of the function ttm_kmap_obj_virtual() will be
reduced by 16 bytes on x86_64 (gcc 4.1.2).
ttm_kmap_obj_virtual() may be heavily used, when buffer objects are
accessed via wrappers, that work for both kinds of memory addresses:
iomem cookies and kernel virtual.
Signed-off-by: Pekka Paalanen
---
include/drm/ttm/ttm_bo_api.h | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index cd22ab4..99dc521 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -245,14 +245,15 @@ struct ttm_buffer_object {
* premapped region.
*/
+#define TTM_BO_MAP_IOMEM_MASK 0x80
struct ttm_bo_kmap_obj {
void *virtual;
struct page *page;
enum {
- ttm_bo_map_iomap,
- ttm_bo_map_vmap,
- ttm_bo_map_kmap,
- ttm_bo_map_premapped,
+ ttm_bo_map_iomap= 1 | TTM_BO_MAP_IOMEM_MASK,
+ ttm_bo_map_vmap = 2,
+ ttm_bo_map_kmap = 3,
+ ttm_bo_map_premapped= 4 | TTM_BO_MAP_IOMEM_MASK,
} bo_kmap_type;
};
@@ -522,8 +523,7 @@ extern int ttm_bo_evict_mm(struct ttm_bo_device *bdev,
unsigned mem_type);
static inline void *ttm_kmap_obj_virtual(struct ttm_bo_kmap_obj *map,
bool *is_iomem)
{
- *is_iomem = (map->bo_kmap_type == ttm_bo_map_iomap ||
-map->bo_kmap_type == ttm_bo_map_premapped);
+ *is_iomem = !!(map->bo_kmap_type & TTM_BO_MAP_IOMEM_MASK);
return map->virtual;
}
--
1.6.3.3
--
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
[PATCH] drm: fixup include files in drm_encoder_slave.h
Signed-off-by: Pekka Paalanen --- include/drm/drm_encoder_slave.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/drm/drm_encoder_slave.h b/include/drm/drm_encoder_slave.h index 821ec40..e5e5c94 100644 --- a/include/drm/drm_encoder_slave.h +++ b/include/drm/drm_encoder_slave.h @@ -27,8 +27,8 @@ #ifndef __DRM_ENCODER_SLAVE_H__ #define __DRM_ENCODER_SLAVE_H__ -#include -#include +#include "drmP.h" +#include "drm_crtc.h" /** * struct drm_encoder_slave_funcs - Entry points exposed by a slave encoder driver -- 1.6.3.3 -- 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: [Nouveau] [PATCH 10/12] drm: Import driver for the ch7006 I2C TV encoder chip.
On Wed, 12 Aug 2009 02:15:06 +0200 Francisco Jerez wrote: > > Signed-off-by: Francisco Jerez > --- > drivers/gpu/drm/Kconfig | 14 + > drivers/gpu/drm/Makefile |1 + > drivers/gpu/drm/i2c/Makefile |3 + > drivers/gpu/drm/i2c/ch7006_drv.c | 479 > + > drivers/gpu/drm/i2c/ch7006_mode.c | 470 > drivers/gpu/drm/i2c/ch7006_priv.h | 332 + > include/drm/i2c/ch7006.h | 86 +++ > 7 files changed, 1385 insertions(+), 0 deletions(-) > create mode 100644 drivers/gpu/drm/i2c/Makefile > create mode 100644 drivers/gpu/drm/i2c/ch7006_drv.c > create mode 100644 drivers/gpu/drm/i2c/ch7006_mode.c > create mode 100644 drivers/gpu/drm/i2c/ch7006_priv.h > create mode 100644 include/drm/i2c/ch7006.h This patch should probably go in via dri-devel@ and airlied, like the other two DRM patches. Would that work? It would be unused without Nouveau, so it probably won't get to Linus' before Nouveau does. Airlied? Does Nouveau build and work otherwise without this patch? If we take it to the nouveau/linux-2.6 master branch, we would have to remember to revert it when submitting Nouveau upstream. OTOH, we could apply it to master-compat branch for testing. How's that sound? Thanks. -- Pekka Paalanen http://www.iki.fi/pq/ -- 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
Hi,
some minor comments below.
On Tue, 11 Aug 2009 15:52:06 +1000
Dave Airlie wrote:
> From: Tiago Vignatti
>
> 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
> Signed-off-by: Dave Airlie
> ---
> 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.
The file Documentation/vgaarbiter.txt does not exist.
> 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
> + * (C) Copyright 2007 Paulo R. Zanoni
> + * (C) Copyright 2007, 2009 Tiago Vignatti
> + *
> + * Implements the VGA arbitration. For details refer to
> + * Documentation/vgaarbiter.txt
Another reference to vgaarbiter.txt.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +
> +#include
> +
> +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);
> +
> +
> +static const char *vga_iostate_to_str(unsigned int iostate)
> +{
> + /* Ignore VGA_RSRC_IO and VGA_RSRC_MEM */
> + iostate &= VGA_RSRC_LEGACY_IO | VGA_RSRC_LEGACY_MEM;
> + switch (iostate) {
> + case VGA_RSRC_LEGACY_IO | VGA_RSRC_LEGACY_MEM:
> + return "io+mem";
> +
[RFC] drm/nouveau: optimize code emission of inline functions
>From 8fb4fecbdf912abdde82bfff40443c9a57c32e26 Mon Sep 17 00:00:00 2001
From: Pekka Paalanen
Date: Mon, 10 Aug 2009 19:44:58 +0300
Subject: [PATCH] drm/nouveau: optimize code emission of inline functions
When a call into a static inline function cannot be inlined, the
function is emitted as a regular function into the object file. When
object files are linked in a kernel module file *.ko, it may end up
containing multiple copies of the same static inline function. For
instance, the non-inlined functions nv_rd32 and nv_wr32 have almost
30 copies in nouveau.ko.
This patch moves some inline functions from nouveau_drv.h into a
separate header nouveau_inlines.h, and changes the 'static inline' into
'extern inline'. Gcc uses the extern inline definitions for function
inlining, and otherwise generates a call to an external symbol. The
external symbols need to be defined once, this is done in nouveau_drv.c
by including nouveau_inlines.h the second time, omitting the 'extern
inline' specifiers.
The end result is reduction in code size, as the non-inlined function
definitions are emitted only once.
Signed-off-by: Pekka Paalanen
---
Before this patch:
$ objdump -t nouveau.ko --section=.text | cut -f2 | sort -k2 | uniq -d -c
4
9 0010 BEGIN_RING
5 0051 FIRE_RING
2 00b3 NVLockVgaCrtcs
4 008b NVReadVgaCrtc
2 008c NVReadVgaCrtc
2 0011 NVVgaSeqReset
2 006b NVWriteCRTC
2 0066 NVWriteRAMDAC
4 0081 NVWriteVgaCrtc
3 0082 NVWriteVgaCrtc
11 001a OUT_RING
9 0028 RING_SPACE
2 0019 crtc_wr_cio_state
3 0012 drm_gem_object_unreference
2 0005 kmalloc
3 000b kzalloc
4 0051 nouveau_bo_ref
2 0050 nvReadMC
2 0052 nvWriteMC
3 0029 nv_gf4_disp_arch
4 001b nv_rd08
3 001c nv_rd08
29 0012 nv_rd32
2 0012 nv_ri32
5 001c nv_ro32
4 008b nv_two_heads
11 0022 nv_wo32
8 0015 nv_wr08
29 0014 nv_wr32
2 0013 pci_read_config_dword
After this patch:
$ objdump -t nouveau.ko --section=.text | cut -f2 | sort -k2 | uniq -d -c
4
9 0010 BEGIN_RING
5 0051 FIRE_RING
2 00b3 NVLockVgaCrtcs
5 00a7 NVReadVgaCrtc
2 0011 NVVgaSeqReset
2 0073 NVWriteCRTC
3 0072 NVWriteRAMDAC
4 0091 NVWriteVgaCrtc
3 0092 NVWriteVgaCrtc
11 001a OUT_RING
9 0028 RING_SPACE
2 0019 crtc_wr_cio_state
3 0012 drm_gem_object_unreference
2 0005 kmalloc
3 000b kzalloc
3 0051 nouveau_bo_ref
2 0052 nouveau_bo_ref
3 005d nvReadMC
2 005c nvWriteMC
3 0029 nv_gf4_disp_arch
4 008b nv_two_heads
2 0013 pci_read_config_dword
As you can see, the static inline functions changed to extern
inline functions no longer appear many times in the final kernel
module. But, at the same time nouveau.ko file size
before: 583683 B (.text size 0x000312c8)
after: 681075 B (.text size 0x00039474)
That's .text size increase by 32 kB.
So something is definitely inlined a lot more. This was tested on
x86_64, gcc 4.1.2, CONFIG_OPTIMIZE_INLINING=y,
CONFIG_CC_OPTIMIZE_FOR_SIZE=y.
Now, I'm not sure if this patch would be a good thing or not.
Comments?
I can convert more static inline functions, if this is deemed a
good idea.
drivers/gpu/drm/nouveau/nouveau_drv.c |4 ++
drivers/gpu/drm/nouveau/nouveau_drv.h | 51 +--
drivers/gpu/drm/nouveau/nouveau_inlines.h | 64 +
3 files changed, 69 insertions(+), 50 deletions(-)
create mode 100644 drivers/gpu/drm/nouveau/nouveau_inlines.h
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index f766ca9..c903e9d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -364,3 +364,7 @@ module_exit(nouveau_exit);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_DESCRIPTION(DRIVER_DESC);
MODULE_LICENSE("GPL and additional rights");
+
+#define NOUVEAU_WANT_UNINLINED
+#include "nouveau_inlines.h"
+
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index 381cadd..d8eac47 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -1005,60 +1005,11 @@ extern int nouveau_gem_io
Re: [PATCH] ttm: Fix a potential comparison of structs.
On Sun, 02 Aug 2009 20:12:18 +0200 Thomas Hellström wrote: > Pekka Paalanen skrev: > > From 5e2851952729b287a82efa002b28a2095404d44d Mon Sep 17 00:00:00 2001 > > From: Thomas Hellstrom > > Date: Fri, 31 Jul 2009 10:47:51 +0200 > > Subject: [PATCH] ttm: Fix a potential comparison of structs. > > > > On some architectures the comparison may cause a compilation failure. > > > > Original partial fix Signed-off-by: Thomas Hellstrom > > > > Signed-off-by: Pekka Paalanen > > --- > > > > Thomas, you forgot two more of these :-) > > Here's a patch that actually compiles on x86_64. > > > > Pekka, > Thanks for fixing this! (Just for clarity, i assume you mean that the > non-x86 part now compiles on x86?) Ah yes, that's what I mean. I changed the #ifdefs for my compat fix in http://cgit.freedesktop.org/nouveau/linux-2.6/log/?h=master-compat and tried compiling it the both ways. > Dave, is there a chance to have this in 2.6.31? Compilation errors are > bad, although probably nobody has been hitting this yet.. Well, Nouveau master-compat users would have hit it, but I added your fix, too. Users with x86_32 highmem kernels already hit the kmap_atomic_prot not exported bug while building the latest DRM, TTM and Nouveau bits against distro kernels. So yeah, no-one anyone (else) would care about ;-) Thanks. > > /Thomas > > > drivers/gpu/drm/ttm/ttm_bo_util.c |8 > > 1 files changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c > > b/drivers/gpu/drm/ttm/ttm_bo_util.c > > index f4e2eba..999fbe7 100644 > > --- a/drivers/gpu/drm/ttm/ttm_bo_util.c > > +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c > > @@ -151,7 +151,7 @@ static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, > > void *src, > > #ifdef CONFIG_X86 > > dst = kmap_atomic_prot(d, KM_USER0, prot); > > #else > > - if (prot != PAGE_KERNEL) > > + if (pgprot_val(prot) != pgprot_val(PAGE_KERNEL)) > > dst = vmap(&d, 1, 0, prot); > > else > > dst = kmap(d); > > @@ -164,7 +164,7 @@ static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, > > void *src, > > #ifdef CONFIG_X86 > > kunmap_atomic(dst, KM_USER0); > > #else > > - if (prot != PAGE_KERNEL) > > + if (pgprot_val(prot) != pgprot_val(PAGE_KERNEL)) > > vunmap(dst); > > else > > kunmap(d); > > @@ -187,7 +187,7 @@ static int ttm_copy_ttm_io_page(struct ttm_tt *ttm, > > void *dst, > > #ifdef CONFIG_X86 > > src = kmap_atomic_prot(s, KM_USER0, prot); > > #else > > - if (prot != PAGE_KERNEL) > > + if (pgprot_val(prot) != pgprot_val(PAGE_KERNEL)) > > src = vmap(&s, 1, 0, prot); > > else > > src = kmap(s); > > @@ -200,7 +200,7 @@ static int ttm_copy_ttm_io_page(struct ttm_tt *ttm, > > void *dst, > > #ifdef CONFIG_X86 > > kunmap_atomic(src, KM_USER0); > > #else > > - if (prot != PAGE_KERNEL) > > + if (pgprot_val(prot) != pgprot_val(PAGE_KERNEL)) > > vunmap(src); > > else > > kunmap(s); -- Pekka Paalanen http://www.iki.fi/pq/ -- 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
[PATCH] ttm: Fix a potential comparison of structs.
>From 5e2851952729b287a82efa002b28a2095404d44d Mon Sep 17 00:00:00 2001 From: Thomas Hellstrom Date: Fri, 31 Jul 2009 10:47:51 +0200 Subject: [PATCH] ttm: Fix a potential comparison of structs. On some architectures the comparison may cause a compilation failure. Original partial fix Signed-off-by: Thomas Hellstrom Signed-off-by: Pekka Paalanen --- Thomas, you forgot two more of these :-) Here's a patch that actually compiles on x86_64. drivers/gpu/drm/ttm/ttm_bo_util.c |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c b/drivers/gpu/drm/ttm/ttm_bo_util.c index f4e2eba..999fbe7 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_util.c +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c @@ -151,7 +151,7 @@ static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, void *src, #ifdef CONFIG_X86 dst = kmap_atomic_prot(d, KM_USER0, prot); #else - if (prot != PAGE_KERNEL) + if (pgprot_val(prot) != pgprot_val(PAGE_KERNEL)) dst = vmap(&d, 1, 0, prot); else dst = kmap(d); @@ -164,7 +164,7 @@ static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, void *src, #ifdef CONFIG_X86 kunmap_atomic(dst, KM_USER0); #else - if (prot != PAGE_KERNEL) + if (pgprot_val(prot) != pgprot_val(PAGE_KERNEL)) vunmap(dst); else kunmap(d); @@ -187,7 +187,7 @@ static int ttm_copy_ttm_io_page(struct ttm_tt *ttm, void *dst, #ifdef CONFIG_X86 src = kmap_atomic_prot(s, KM_USER0, prot); #else - if (prot != PAGE_KERNEL) + if (pgprot_val(prot) != pgprot_val(PAGE_KERNEL)) src = vmap(&s, 1, 0, prot); else src = kmap(s); @@ -200,7 +200,7 @@ static int ttm_copy_ttm_io_page(struct ttm_tt *ttm, void *dst, #ifdef CONFIG_X86 kunmap_atomic(src, KM_USER0); #else - if (prot != PAGE_KERNEL) + if (pgprot_val(prot) != pgprot_val(PAGE_KERNEL)) vunmap(src); else kunmap(s); -- 1.6.3.3 -- 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 2/2] ttm: Fix ttm in-kernel copying of pages with non-standard caching attributes.
On Fri, 31 Jul 2009 10:59:57 +0200 Thomas Hellström wrote: > Pekka Paalanen wrote: > >> @@ -145,17 +146,35 @@ static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, > >> void *src, > >>return -ENOMEM; > >> > >>src = (void *)((unsigned long)src + (page << PAGE_SHIFT)); > >> - dst = kmap(d); > >> + > >> +#ifdef CONFIG_X86 > >> + dst = kmap_atomic_prot(d, KM_USER0, prot); > >> +#else > >> + if (prot != PAGE_KERNEL) > >> + dst = vmap(&d, 1, 0, prot); > >> + else > >> + dst = kmap(d); > >> +#endif > >> > > > > What are the implications of choosing the non-CONFIG_X86 path > > even on x86? > > > > The only implication is a slowdown if dealing with highmem pages or > pages with > a non standard caching policy. Also you need the patch I just posted to > dri-devel / lkml to make it compile. > I should've done more thorough testing of the non-x86 path. > > > Is kmap_atomic_prot() simply an optimization allowed by the x86 > > arch, and the alternate way also works, although it uses the > > precious vmalloc address space? > > > > Exactly, although it's only using one page out of vmalloc space and for > the time it > takes to copy a page to / from io. > > > Since kmap_atomic_prot() is not exported on earlier kernels, > > I'm tempted to just do the non-CONFIG_X86 path. > > > For compat I think that should be fine. If your driver is using > accelerated copy to / from > VRAM, you shouldn't even hit this path. Okay, thank you very much. -- Pekka Paalanen http://www.iki.fi/pq/ -- 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 2/2] ttm: Fix ttm in-kernel copying of pages with non-standard caching attributes.
Hi,
since I see this patch in Linus' tree, and I likely have to patch
TTM in Nouveau's compat-branch to compile with older kernels,
I have a question below.
(The Nouveau kernel tree's compat branch offers drm.ko, ttm.ko and
nouveau.ko to be built against kernels 2.6.28 and later.)
On Fri, 24 Jul 2009 09:57:34 +0200
Thomas Hellstrom wrote:
> For x86 this affected highmem pages only, since they were always kmapped
> cache-coherent, and this is fixed using kmap_atomic_prot().
>
> For other architectures that may not modify the linear kernel map we
> resort to vmap() for now, since kmap_atomic_prot() generally uses the
> linear kernel map for lowmem pages. This of course comes with a
> performance impact and should be optimized when possible.
>
> Signed-off-by: Thomas Hellstrom
> ---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 63 ++--
> 1 files changed, 52 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
> b/drivers/gpu/drm/ttm/ttm_bo_util.c
> index 3e5d0c4..ce2e6f3 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
> @@ -136,7 +136,8 @@ static int ttm_copy_io_page(void *dst, void *src,
> unsigned long page)
> }
>
> static int ttm_copy_io_ttm_page(struct ttm_tt *ttm, void *src,
> - unsigned long page)
> + unsigned long page,
> + pgprot_t prot)
> {
> struct page *d = ttm_tt_get_page(ttm, page);
> void *dst;
> @@ -145,17 +146,35 @@ static int ttm_copy_io_ttm_page(struct ttm_tt *ttm,
> void *src,
> return -ENOMEM;
>
> src = (void *)((unsigned long)src + (page << PAGE_SHIFT));
> - dst = kmap(d);
> +
> +#ifdef CONFIG_X86
> + dst = kmap_atomic_prot(d, KM_USER0, prot);
> +#else
> + if (prot != PAGE_KERNEL)
> + dst = vmap(&d, 1, 0, prot);
> + else
> + dst = kmap(d);
> +#endif
What are the implications of choosing the non-CONFIG_X86 path
even on x86?
Is kmap_atomic_prot() simply an optimization allowed by the x86
arch, and the alternate way also works, although it uses the
precious vmalloc address space?
Since kmap_atomic_prot() is not exported on earlier kernels,
I'm tempted to just do the non-CONFIG_X86 path.
> if (!dst)
> return -ENOMEM;
>
> memcpy_fromio(dst, src, PAGE_SIZE);
> - kunmap(d);
> +
> +#ifdef CONFIG_X86
> + kunmap_atomic(dst, KM_USER0);
> +#else
> + if (prot != PAGE_KERNEL)
> + vunmap(dst);
> + else
> + kunmap(d);
> +#endif
> +
> return 0;
> }
>
> static int ttm_copy_ttm_io_page(struct ttm_tt *ttm, void *dst,
> - unsigned long page)
> + unsigned long page,
> + pgprot_t prot)
> {
> struct page *s = ttm_tt_get_page(ttm, page);
> void *src;
> @@ -164,12 +183,28 @@ static int ttm_copy_ttm_io_page(struct ttm_tt *ttm,
> void *dst,
> return -ENOMEM;
>
> dst = (void *)((unsigned long)dst + (page << PAGE_SHIFT));
> - src = kmap(s);
> +#ifdef CONFIG_X86
> + src = kmap_atomic_prot(s, KM_USER0, prot);
> +#else
> + if (prot != PAGE_KERNEL)
> + src = vmap(&s, 1, 0, prot);
> + else
> + src = kmap(s);
> +#endif
> if (!src)
> return -ENOMEM;
>
> memcpy_toio(dst, src, PAGE_SIZE);
> - kunmap(s);
> +
> +#ifdef CONFIG_X86
> + kunmap_atomic(src, KM_USER0);
> +#else
> + if (prot != PAGE_KERNEL)
> + vunmap(src);
> + else
> + kunmap(s);
> +#endif
> +
> return 0;
> }
>
> @@ -214,11 +249,17 @@ int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
>
> for (i = 0; i < new_mem->num_pages; ++i) {
> page = i * dir + add;
> - if (old_iomap == NULL)
> - ret = ttm_copy_ttm_io_page(ttm, new_iomap, page);
> - else if (new_iomap == NULL)
> - ret = ttm_copy_io_ttm_page(ttm, old_iomap, page);
> - else
> + if (old_iomap == NULL) {
> + pgprot_t prot = ttm_io_prot(old_mem->placement,
> + PAGE_KERNEL);
> + ret = ttm_copy_ttm_io_page(ttm, new_iomap, page,
> +prot);
> + } else if (new_iomap == NULL) {
> + pgprot_t prot = ttm_io_prot(new_mem->placement,
> +
Re: [Nouveau] When will nouveau kernel tree be merged into master
Sorry for causing that much trouble. On Thu, 09 Jul 2009 19:20:54 +0200 Eric Valette wrote: > Well I would suggest you to look at GALLIUM3D because using gi to clone > mesa master is not even working and even if you get a git snapshot it > does not build. http://nouveau.freedesktop.org/wiki/GalliumHowto Is there something unclear here? The same applies to the following, since Gallium3D is the one providing OpenGL. > kde4 kwin not running using openGL as composing type is maybe my > favorite bug! > > Then comes messa git nouveau being out of sync with the rest of nouveau code This is an open project with too few developers. If you want faster progress, you should join. You already know the issues you want to tackle. Also, I'd recommend studying git, you only ever have to 'clone' once. Receiving updates is a lot faster. InstallDRM has the instructions, since the kernel tree is so big, but there are more than one way to pull updates. -- Pekka Paalanen http://www.iki.fi/pq/ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Nouveau] When will nouveau kernel tree be merged into master
On Thu, 09 Jul 2009 14:00:29 +0200 Eric Valette wrote: > I've been using nouveau driveau for 8 months or so, using automated > build from drm git, xf86-video-nouveau git and even sometimes mesa drm > git and discovered the linux-core build did not build the nouveau > driver the hard way: X was refusing to start as the nouveau.ko modules > was not loaded nor build. Build process did chnage without obvious way > to know womething was wrong. Nouveau was removed from make targets, therefore you get this: $ make nouveau.o make: *** No rule to make target `nouveau.o'. Stop. The removal was done in a commit, that removed the old ttm code, and at the same time broke the nouveau.ko build, hence nouveau is not a target anymore. The plain 'make' of course works, since there are other modules that (supposedly) still work. Btw. Nouveau should fall back to NoAccel mode, if the kernel modules are not available. > Then I tried to build it by hand as the nouveau directory is still there > but compilation fails! I wonder why the code is still in the tree as it > make me waste quite some time trying to find where the missing > definitions had gone. The nouveau directory? > After some hours of goggling I discovered there was an git kernel tree > for nouveau. Got the feeling from dri-devel posts it was supposed to be > merged for rc1, checked master tree and found it was not merged. I assume you refer to the discussion http://lists.freedesktop.org/archives/nouveau/2009-June/003103.html The only merge mentioned is newTTM, which went into -rc1 along with the radeon KMS driver. Nouveau depends on newTTM, and we wanted it upstream before setting up the master branch. > So my question are: > - Why not purely delete nouveau files from linux-core and issue > error messages? The code is still in the tree for historical reference, and for BSDs. I'm not sure if BSDs still need it. > - When will nouveau in kernel git tree be merged? I know the merge > windows is closed but that usually does not hold for new drivers This Nouveau kernel tree will never be merged from. A completely separate git repository will be created for upstreaming Nouveau. A proposition was made in http://lists.freedesktop.org/archives/nouveau/2009-March/002765.html and we are approximately following that. The precise development model is still under discussion and has to be decided before creating the upstreaming tree. There's a good chance the upstreaming tree is created this year, and Nouveau starts its journey into mainline, but first into staging. > Thanks. Using nouveau is quite painfull. Please be aware that as > distribution move too slowly into nominal nouveau driver support, I'm > not probably the only guy lost in the dust. Yes, and we are trying to alleviate the pain by keeping the guides in the wiki up-to-date. Granted, there were the few days, when drm.git nouveau.ko build was broken, and the InstallDRM page was not written yet, nor InstallNouveau updated. IIRC that was less than a week. Unfortunately, some people want to translate wiki pages to their mother tongue, and then do not bother updating them for a long time. The English pages contain the latest information. This is the original announcement: http://lists.freedesktop.org/archives/nouveau/2009-June/003000.html later we got master and master-compat branches up and deprecated everything else. For further info, see http://lists.freedesktop.org/archives/nouveau/2009-June/003134.html http://lists.freedesktop.org/archives/nouveau/2009-July/003148.html and the Nouveau wiki. The nouveau kernel tree was annouced on the wiki front page, and on the nouveau mailing list. What more should we have done? -- Pekka Paalanen http://www.iki.fi/pq/ -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 5/6] libdrm: Make chown check for return value and in case a signal call again chown.
On Sat, 4 Jul 2009 02:18:53 +0300
Pauli Nieminen wrote:
> ---
> libdrm/xf86drm.c | 49 ++---
> 1 files changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/libdrm/xf86drm.c b/libdrm/xf86drm.c
> index 7b05386..bf80fd4 100644
> --- a/libdrm/xf86drm.c
> +++ b/libdrm/xf86drm.c
> @@ -269,6 +269,49 @@ static int drmMatchBusID(const char *id1, const char
> *id2)
> return 0;
> }
>
> +static int chownCheckReturn(const char *path, uid_t owner, gid_t group)
> +{
> + int rv;
> + do {
> + rv = chown(path, owner, group);
> + } while( rv != 0 && errno == EINTR);
> + if (rv == 0)
> + return 0;
> + char *errMsg = "";
> + switch(errno)
> + {
> + case EACCES:
> + errMsg = "Read permission denied.";
> + break;
> + case ELOOP:
> + errMsg = "Recursive symbolic link.";
> + break;
> + case ENAMETOOLONG:
> + errMsg = "Too long path.";
> + break;
> + case ENOTDIR:
> + errMsg = "Path isn't in a directory.";
> + break;
> + case ENOENT:
> + errMsg = "No file found.";
> + break;
> + case EPERM:
> + errMsg = "No permission to change the permission.";
> + break;
> + case EROFS:
> + errMsg = "Read-only file system.";
> + break;
> + case EIO:
> + errMsg = "I/O error.";
> + break;
> + case EINVAL:
> + errMsg = "The owner or group id is invalid.";
> + break;
> + }
> + drmMsg("Failed to change ower or group for file %s! %d: %s\n",path,
> errno, errMsg);
> + return -1;
> +}
> +
Is there a reason for not using strerror() here?
> /**
> * Open the DRM device, creating it if necessary.
> *
> @@ -307,7 +350,7 @@ static int drmOpenDevice(long dev, int minor, int type)
> if (!isroot)
> return DRM_ERR_NOT_ROOT;
> mkdir(DRM_DIR_NAME, DRM_DEV_DIRMODE);
> - chown(DRM_DIR_NAME, 0, 0); /* root:root */
> + chownCheckReturn(DRM_DIR_NAME, 0, 0); /* root:root */
> chmod(DRM_DIR_NAME, DRM_DEV_DIRMODE);
> }
>
> @@ -320,7 +363,7 @@ static int drmOpenDevice(long dev, int minor, int type)
> }
>
> if (drm_server_info) {
> - chown(buf, user, group);
> + chownCheckReturn(buf, user, group);
> chmod(buf, devmode);
> }
> #else
> @@ -363,7 +406,7 @@ wait_for_udev:
> remove(buf);
> mknod(buf, S_IFCHR | devmode, dev);
> if (drm_server_info) {
> - chown(buf, user, group);
> + chownCheckReturn(buf, user, group);
> chmod(buf, devmode);
> }
> }
> --
> 1.6.3.1
--
Pekka Paalanen
http://www.iki.fi/pq/
--
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Why was old TTM removed from drm.git?
On Wed, 24 Jun 2009 19:26:41 +0200 Thomas Hellström wrote: > Hi, Pekka! > > I'm sorry for this breakage. I thought drm master was currently used > only for libdrm development, but > I see now that I didn't pay enough attention. Just prior to the commit I > sent out a message explaining what I was going to do and why, but > apparently it didn't make it to the list (which seems to be the case of > quite a few mails these days). Yeah, I read dri-devel@ daily, and I didn't notice anything. Of course I could have missed it. > Please feel free to revert that commit and pull it in again when you > think it's OK, or perhaps anchor a nouveau drm branch just ahead of this > commit. The old TTM is completely unmaintained and blocks any attempt to > bring the drm.git master repo reasonably up to sync with what's in the > kernel, so the sooner it goes away the better. > > Again, Sorry for the breakage. Don't worry, I believe we can live with this for the few days it takes to get our replacement source going. Bringing drm.git up to sync... are you saying someone is going to start porting stuff from Linus' tree back to drm.git? Isn't drm.git linux-core dying after all? Thanks. -- Pekka Paalanen http://www.iki.fi/pq/ -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Why was old TTM removed from drm.git?
Hi Thomas, I meant to ask you this 24h ago: why did you deliberately break Nouveau in drm.git? The commit 9a33f62be1c478334572ea9384af60 "drm: Strip old ttm." not only removes the old TTM, it explicitly removes Nouveau from Makefile. IMHO this means you knew it broke Nouveau and you did not care. And there is no explanation in the commit as to why. Did you ask any Nouveau developer if it was ok? It is true, that Nouveau is aiming for its own kernel tree for DRM development, but it is not for all end users yet. Majority of our users use the drm.git kernel modules for Nouveau, and now we get to explain how it is not there anymore, and we have no guide to point them to. 2.6.31-rc1 is coming, bearing newTTM. If you had waited a week, we would have had the kernel tree up and user documentation written on how to build that, and breaking Nouveau in drm.git would not have mattered. Well, rc1 is so near, that we probably won't bother fixing Nouveau in drm.git. I just wish the transition would have been Nouveau developers' decision. Regards, pq -- Pekka Paalanen http://www.iki.fi/pq/ -- -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Building rawhide+darktama on 2.6.24 (Re: [Nouveau] DRM changes)
On Mon, 9 Mar 2009 22:49:32 +0100 Stephane Marchesin wrote: > As we discussed on irc, there would be multiple changes related to this: > - we move to a linux kernel-like tree, that should make it easier when > upstreaming the code. > - this new tree is hosted in freedekstop.org in the nouveau/ git so we > don't need additional accounts for everyone all around and people can > keep pushing things (even better, all nouveau people can push to the > drm, which used to require mesa rights before) > - we keep a(some) branch(es) in the tree for backwards compat with > older kernels. Either in the form of separate kernel versions > including nouveau, or in the form of an out-of-tree-compilable > drm/nouveau module. Hi, I took airlied's drm-rawhide kernel tree, applied darktama's patch that adds Nouveau, wrote/copied my own compat-patches on top of that, and compiled the DRM modules (drm.ko and nouveau.ko) against my currently running kernel 2.6.24. It works, with the caveat that I needed a tiny patch to 2.6.24 in addition to reconfiguring it. The details will follow. I've been running Nouveau for two hours now without any hickups. I'm CC'ing also dri-devel@ just in case people working on other drivers might be interested in offering a "drm.git-like" version of their drivers for people with older, custom or otherwise not-this-driver's-development-tree kernels. And because my compat patches probably suck. Feel free to drop the dri-devel@ CC when you discuss Nouveau-only matters. This raises some questions for Nouveau: - like marcheu proposed, shall Nouveau DRM move into a kernel tree? - do we abandon drm.git kernel directories completely? - is the out-of-tree DRM build sketched below feasible for users? - how do we maintain and distribute the compat patches and DRM code? I'd expect the compat patches would be maintained by whoever happens to run older kernels. Developers do not consider compat patching. Building DRM out-of-tree for 2.6.24: Prepare the "upstream" DRM and Nouveau code: - Get airlied's linux kernel tree, the drm-rawhide branch: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=shortlog;h=drm-rawhide (the version I used is probably a week old now) - Get darktama's nouveau patch and apply it on drm-rawhide: http://cvs.fedoraproject.org/viewvc/rpms/kernel/devel/drm-nouveau.patch?revision=1.25&view=markup (this is probably outdated by now) - apply the included nouveau-drm-compat-24.patch This patch is combined from the individual patches listed in its description, diffstat is included. - run 'make clean' unless your tree is already clean. Prepare your 2.6.24 kernel: - apply the included kernel-compat-24.patch to export shmem_file_setup() - configure the following as modules: CONFIG_DRM CONFIG_FB CONFIG_BACKLIGHT_CLASS_DEVICE CONFIG_FB_SAVAGE The savage driver is abused to get FB_CFB_FILLRECT, FB_CFB_COPYAREA and FB_CFB_IMAGEBLIT enabled, since they do not have menuconfig entries. If you actually have a Savage card in your computer, maybe you should pick another fb driver. - build and install as usual, remove the drm.ko generated. Building the DRM and Nouveau modules as external modules using the 2.6.24 kernel tree: - save the included mkbuild-nouveau.bash script - edit the script, and fix the paths to the 2.6.24 and the drm-rawhide kernel trees - create a new empty directory and cd into it - run '../mkbuild-nouveau.bash init', it should not whine about anything, just print good stuff. - run '../mkbuild-nouveau.bash build', it should build drm.ko and nouveau.ko. These are probably created in the drm-rawhide kernel tree. - find the kernel modules, and load these: fb.ko drm.ko backlight.ko cfbcopyarea.ko cfbfillrect.ko cfbimgblt.ko nouveau.ko Now the Nouveau DDX should run just fine using the new DRM modules. Ben, I still don't see any comment from you on this thread :-) -- Pekka Paalanen http://www.iki.fi/pq/ #!/bin/bash # 395e0ddc44005ced5e4fed9bfc2e4bdf63d37627 shmem_file_setup export # Use e.g. CONFIG_FB_SAVAGE to get FB_CFB_FILLRECT, FB_CFB_COPYAREA # and FB_CFB_IMAGEBLIT. # cd into an empty directory, and call this script from there. # Path to the kernel tree, from which DRM is built. NKDIR="/home/pq/linux/linux-2.6-torvalds" # Path to the configured kernel tree you normally use KDIR="$(readlink -f /lib/modules/`uname -r`/source)" # All resulting files *should* be written to OUTDIR, but it seems # the external module directory does not honour that. I.e. the # the external modules are built into DRMDIR. DRMDIR="$NKDIR/drivers/gpu/drm" OUTDIR="$(pwd)" NEWCONFIG="$OUTDIR/.config" # --- nothing configurable below this line --- CMD="$1" function config_check_ym
[PATCH 04/10] drm: drop Linux < 2.6.12 support
Signed-off-by: Pekka Paalanen
---
linux-core/drmP.h |6 --
linux-core/drm_agpsupport.c | 37 +
linux-core/drm_memory.c |7 ---
linux-core/drm_memory_debug.c |4
4 files changed, 1 insertions(+), 53 deletions(-)
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
index 002ad3d..bc68bfe 100644
--- a/linux-core/drmP.h
+++ b/linux-core/drmP.h
@@ -517,9 +517,7 @@ struct drm_agp_head {
DRM_AGP_KERN agp_info; /**< AGP device information */
struct list_head memory;
unsigned long mode; /**< AGP mode */
-#if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,11)
struct agp_bridge_data *bridge;
-#endif
int enabled;/**< whether the AGP bus as been
enabled */
int acquired; /**< whether the AGP device has been
acquired */
unsigned long base;
@@ -1279,11 +1277,7 @@ extern int drm_agp_unbind_ioctl(struct drm_device *dev,
void *data,
extern int drm_agp_bind(struct drm_device *dev, struct drm_agp_binding
*request);
extern int drm_agp_bind_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11)
-extern DRM_AGP_MEM *drm_agp_allocate_memory(size_t pages, u32 type);
-#else
extern DRM_AGP_MEM *drm_agp_allocate_memory(struct agp_bridge_data *bridge,
size_t pages, u32 type);
-#endif
extern int drm_agp_free_memory(DRM_AGP_MEM * handle);
extern int drm_agp_bind_memory(DRM_AGP_MEM * handle, off_t start);
extern int drm_agp_unbind_memory(DRM_AGP_MEM * handle);
diff --git a/linux-core/drm_agpsupport.c b/linux-core/drm_agpsupport.c
index 3cc94ff..2abfac6 100644
--- a/linux-core/drm_agpsupport.c
+++ b/linux-core/drm_agpsupport.c
@@ -94,21 +94,12 @@ int drm_agp_info_ioctl(struct drm_device *dev, void *data,
*/
int drm_agp_acquire(struct drm_device * dev)
{
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11)
- int retcode;
-#endif
-
if (!dev->agp)
return -ENODEV;
if (dev->agp->acquired)
return -EBUSY;
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11)
- if ((retcode = agp_backend_acquire()))
- return retcode;
-#else
if (!(dev->agp->bridge = agp_backend_acquire(dev->pdev)))
return -ENODEV;
-#endif
dev->agp->acquired = 1;
return 0;
@@ -145,11 +136,7 @@ int drm_agp_release(struct drm_device *dev)
{
if (!dev->agp || !dev->agp->acquired)
return -EINVAL;
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11)
- agp_backend_release();
-#else
agp_backend_release(dev->agp->bridge);
-#endif
dev->agp->acquired = 0;
return 0;
@@ -178,11 +165,7 @@ int drm_agp_enable(struct drm_device *dev, struct
drm_agp_mode mode)
return -EINVAL;
dev->agp->mode = mode.mode;
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11)
- agp_enable(mode.mode);
-#else
agp_enable(dev->agp->bridge, mode.mode);
-#endif
dev->agp->enabled = 1;
return 0;
}
@@ -418,9 +401,6 @@ struct drm_agp_head *drm_agp_init(struct drm_device *dev)
return NULL;
memset((void *)head, 0, sizeof(*head));
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11)
- agp_copy_info(&head->agp_info);
-#else
head->bridge = agp_find_bridge(dev->pdev);
if (!head->bridge) {
if (!(head->bridge = agp_backend_acquire(dev->pdev))) {
@@ -432,7 +412,7 @@ struct drm_agp_head *drm_agp_init(struct drm_device *dev)
} else {
agp_copy_info(head->bridge, &head->agp_info);
}
-#endif
+
if (head->agp_info.chipset == NOT_SUPPORTED) {
drm_free(head, sizeof(*head), DRM_MEM_AGPLISTS);
return NULL;
@@ -445,18 +425,11 @@ struct drm_agp_head *drm_agp_init(struct drm_device *dev)
}
/** Calls agp_allocate_memory() */
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11)
-DRM_AGP_MEM *drm_agp_allocate_memory(size_t pages, u32 type)
-{
- return agp_allocate_memory(pages, type);
-}
-#else
DRM_AGP_MEM *drm_agp_allocate_memory(struct agp_bridge_data *bridge,
size_t pages, u32 type)
{
return agp_allocate_memory(bridge, pages, type);
}
-#endif
/** Calls agp_free_memory() */
int drm_agp_free_memory(DRM_AGP_MEM * handle)
@@ -501,12 +474,8 @@ drm_agp_bind_pages(struct drm_device *dev,
int ret, i;
DRM_DEBUG("drm_agp_populate_ttm\n");
-#if LINUX_VERSION_CODE <= KERNEL_VERSION(2,6,11)
- mem = drm_agp_allocate_memory(num_pages, AGP_USER_MEMORY);
-#else
mem = drm_agp_allocate_memory(dev->agp->bridge, num_pages,
AGP_USER_MEMORY);
-#endif
if
[PATCH 02/10] drm: drop Linux <= 2.6.8 support
Signed-off-by: Pekka Paalanen --- linux-core/drm_os_linux.h | 18 -- 1 files changed, 0 insertions(+), 18 deletions(-) diff --git a/linux-core/drm_os_linux.h b/linux-core/drm_os_linux.h index 8921944..4f1e83b 100644 --- a/linux-core/drm_os_linux.h +++ b/linux-core/drm_os_linux.h @@ -10,23 +10,6 @@ #define DRM_CURRENTPID current->pid #define DRM_SUSER(p) capable(CAP_SYS_ADMIN) #define DRM_UDELAY(d) udelay(d) -#if LINUX_VERSION_CODE <= 0x020608 /* KERNEL_VERSION(2,6,8) */ -#ifndef __iomem -#define __iomem -#endif -/** Read a byte from a MMIO region */ -#define DRM_READ8(map, offset) readb(((void __iomem *)(map)->handle) + (offset)) -/** Read a word from a MMIO region */ -#define DRM_READ16(map, offset)readw(((void __iomem *)(map)->handle) + (offset)) -/** Read a dword from a MMIO region */ -#define DRM_READ32(map, offset)readl(((void __iomem *)(map)->handle) + (offset)) -/** Write a byte into a MMIO region */ -#define DRM_WRITE8(map, offset, val) writeb(val, ((void __iomem *)(map)->handle) + (offset)) -/** Write a word into a MMIO region */ -#define DRM_WRITE16(map, offset, val) writew(val, ((void __iomem *)(map)->handle) + (offset)) -/** Write a dword into a MMIO region */ -#define DRM_WRITE32(map, offset, val) writel(val, ((void __iomem *)(map)->handle) + (offset)) -#else /** Read a byte from a MMIO region */ #define DRM_READ8(map, offset) readb((map)->handle + (offset)) /** Read a word from a MMIO region */ @@ -39,7 +22,6 @@ #define DRM_WRITE16(map, offset, val) writew(val, (map)->handle + (offset)) /** Write a dword into a MMIO region */ #define DRM_WRITE32(map, offset, val) writel(val, (map)->handle + (offset)) -#endif /** Read memory barrier */ #define DRM_READMEMORYBARRIER()rmb() /** Write memory barrier */ -- 1.6.0.6 -- 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 00/10] DRM cleanup
Even 2.6.21 is about two years old now. Drop support for all kernels before 2.6.21. This kernel version is a nice stopping point, since it guarantees #define DRM_FULL_MM_COMPAT. If no-one objects, I can push these into drm.git myself. Pekka Paalanen (10): drm: drm_bo_mmap_locked() is static. drm: drop Linux <= 2.6.8 support drm: drop Linux < 2.6.10 support drm: drop Linux < 2.6.12 support drm: drop Linux < 2.6.15 support drm: drop Linux < 2.6.16 support drm: drop Linux < 2.6.18 support drm: drop Linux < 2.6.19 support drm, via: drop Linux < 2.6.20 support drm: drop Linux < 2.6.21 support linux-core/drmP.h |8 - linux-core/drm_agpsupport.c | 37 +--- linux-core/drm_bo.c | 66 - linux-core/drm_bo_move.c | 16 -- linux-core/drm_compat.c | 579 - linux-core/drm_compat.h | 172 linux-core/drm_drv.c |3 - linux-core/drm_memory.c |7 - linux-core/drm_memory_debug.c |4 - linux-core/drm_objects.h | 11 - linux-core/drm_os_linux.h | 18 -- linux-core/drm_ttm.c |6 - linux-core/drm_vm.c | 24 +-- linux-core/mga_drv.c |2 +- linux-core/nouveau_drv.c |2 +- linux-core/r128_drv.c |2 +- linux-core/radeon_drv.c |2 +- linux-core/via_dmablit.c | 12 - linux-core/xgi_drv.c |2 +- shared-core/nouveau_mem.c |2 +- 20 files changed, 9 insertions(+), 966 deletions(-) -- 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 08/10] drm: drop Linux < 2.6.19 support
This also means dropping the DRM_ODD_MM_COMPAT case.
Signed-off-by: Pekka Paalanen
---
linux-core/drm_bo.c | 46
linux-core/drm_bo_move.c | 16 ---
linux-core/drm_compat.c | 272 +
linux-core/drm_compat.h | 82 --
linux-core/drm_objects.h |7 -
linux-core/drm_vm.c | 15 ---
shared-core/nouveau_mem.c |2 +-
7 files changed, 3 insertions(+), 437 deletions(-)
diff --git a/linux-core/drm_bo.c b/linux-core/drm_bo.c
index 3fb43fc..6f083f5 100644
--- a/linux-core/drm_bo.c
+++ b/linux-core/drm_bo.c
@@ -91,44 +91,13 @@ void drm_bo_add_to_lru(struct drm_buffer_object *bo)
static int drm_bo_vm_pre_move(struct drm_buffer_object *bo, int old_is_pci)
{
-#ifdef DRM_ODD_MM_COMPAT
- int ret;
-
if (!bo->map_list.map)
return 0;
- ret = drm_bo_lock_kmm(bo);
- if (ret)
- return ret;
drm_bo_unmap_virtual(bo);
- if (old_is_pci)
- drm_bo_finish_unmap(bo);
-#else
- if (!bo->map_list.map)
- return 0;
-
- drm_bo_unmap_virtual(bo);
-#endif
return 0;
}
-static void drm_bo_vm_post_move(struct drm_buffer_object *bo)
-{
-#ifdef DRM_ODD_MM_COMPAT
- int ret;
-
- if (!bo->map_list.map)
- return;
-
- ret = drm_bo_remap_bound(bo);
- if (ret) {
- DRM_ERROR("Failed to remap a bound buffer object.\n"
- "\tThis might cause a sigbus later.\n");
- }
- drm_bo_unlock_kmm(bo);
-#endif
-}
-
/*
* Call bo->mutex locked.
*/
@@ -237,9 +206,6 @@ static int drm_bo_handle_move_mem(struct drm_buffer_object
*bo,
goto out_err;
moved:
- if (old_is_pci || new_is_pci)
- drm_bo_vm_post_move(bo);
-
if (bo->priv_flags & _DRM_BO_FLAG_EVICTED) {
ret =
dev->driver->bo_driver->invalidate_caches(dev,
@@ -260,9 +226,6 @@ moved:
return 0;
out_err:
- if (old_is_pci || new_is_pci)
- drm_bo_vm_post_move(bo);
-
new_man = &bm->man[bo->mem.mem_type];
if ((new_man->flags & _DRM_FLAG_MEMTYPE_FIXED) && bo->ttm) {
drm_ttm_unbind(bo->ttm);
@@ -467,11 +430,6 @@ static void drm_bo_destroy_locked(struct drm_buffer_object
*bo)
return;
}
-#ifdef DRM_ODD_MM_COMPAT
- BUG_ON(!list_empty(&bo->vma_list));
- BUG_ON(!list_empty(&bo->p_mm_list));
-#endif
-
if (bo->ttm) {
drm_ttm_unbind(bo->ttm);
drm_ttm_destroy(bo->ttm);
@@ -1784,10 +1742,6 @@ int drm_buffer_object_create(struct drm_device *dev,
INIT_LIST_HEAD(&bo->lru);
INIT_LIST_HEAD(&bo->pinned_lru);
INIT_LIST_HEAD(&bo->ddestroy);
-#ifdef DRM_ODD_MM_COMPAT
- INIT_LIST_HEAD(&bo->p_mm_list);
- INIT_LIST_HEAD(&bo->vma_list);
-#endif
bo->dev = dev;
bo->type = type;
bo->num_pages = num_pages;
diff --git a/linux-core/drm_bo_move.c b/linux-core/drm_bo_move.c
index bf0e1b7..d794e98 100644
--- a/linux-core/drm_bo_move.c
+++ b/linux-core/drm_bo_move.c
@@ -297,10 +297,6 @@ int drm_buffer_object_transfer(struct drm_buffer_object
*bo,
INIT_LIST_HEAD(&fbo->ddestroy);
INIT_LIST_HEAD(&fbo->lru);
INIT_LIST_HEAD(&fbo->pinned_lru);
-#ifdef DRM_ODD_MM_COMPAT
- INIT_LIST_HEAD(&fbo->vma_list);
- INIT_LIST_HEAD(&fbo->p_mm_list);
-#endif
fbo->fence = drm_fence_reference_locked(bo->fence);
fbo->pinned_node = NULL;
@@ -341,20 +337,8 @@ int drm_bo_move_accel_cleanup(struct drm_buffer_object *bo,
if (ret)
return ret;
-#ifdef DRM_ODD_MM_COMPAT
- /*
-* In this mode, we don't allow pipelining a copy blit,
-* since the buffer will be accessible from user space
-* the moment we return and rebuild the page tables.
-*
-* With normal vm operation, page tables are rebuilt
-* on demand using fault(), which waits for buffer idle.
-*/
- if (1)
-#else
if (evict || ((bo->mem.mm_node == bo->pinned_node) &&
bo->mem.mm_node != NULL))
-#endif
{
if (bo->fence) {
(void) drm_fence_object_wait(bo->fence, 0, 1,
diff --git a/linux-core/drm_compat.c b/linux-core/drm_compat.c
index ff4085d..fb39649 100644
--- a/linux-core/drm_compat.c
+++ b/linux-core/drm_compat.c
@@ -27,31 +27,7 @@
#include "drmP.h"
-#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,19))
-
-/*
- * The protection map was exported in 2.6.19
- */
-
-pgprot_t vm_get_page_prot(unsigned long vm_flags)
-{
-#ifdef MODULE
-
[PATCH 05/10] drm: drop Linux < 2.6.15 support
Signed-off-by: Pekka Paalanen
---
linux-core/drm_bo.c |7 ---
linux-core/drm_compat.c | 104 +--
linux-core/drm_compat.h | 24 +--
linux-core/drm_drv.c|3 -
linux-core/drm_ttm.c|6 ---
5 files changed, 2 insertions(+), 142 deletions(-)
diff --git a/linux-core/drm_bo.c b/linux-core/drm_bo.c
index 88b2ee6..3fb43fc 100644
--- a/linux-core/drm_bo.c
+++ b/linux-core/drm_bo.c
@@ -2362,9 +2362,6 @@ int drm_bo_driver_finish(struct drm_device *dev)
if (list_empty(&bm->unfenced))
DRM_DEBUG("Unfenced list was clean\n");
-#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,15))
- ClearPageReserved(bm->dummy_read_page);
-#endif
__free_page(bm->dummy_read_page);
out:
@@ -2397,10 +2394,6 @@ int drm_bo_driver_init(struct drm_device *dev)
goto out_unlock;
}
-#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,15))
- SetPageReserved(bm->dummy_read_page);
-#endif
-
/*
* Initialize the system memory buffer type.
* Other types need to be driver / IOCTL initialized.
diff --git a/linux-core/drm_compat.c b/linux-core/drm_compat.c
index 67baac5..e90338f 100644
--- a/linux-core/drm_compat.c
+++ b/linux-core/drm_compat.c
@@ -27,32 +27,6 @@
#include "drmP.h"
-#if defined(CONFIG_X86) && (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,15))
-
-/*
- * These have bad performance in the AGP module for the indicated kernel
versions.
- */
-
-int drm_map_page_into_agp(struct page *page)
-{
-int i;
-i = change_page_attr(page, 1, PAGE_KERNEL_NOCACHE);
-/* Caller's responsibility to call global_flush_tlb() for
- * performance reasons */
-return i;
-}
-
-int drm_unmap_page_from_agp(struct page *page)
-{
-int i;
-i = change_page_attr(page, 1, PAGE_KERNEL);
-/* Caller's responsibility to call global_flush_tlb() for
- * performance reasons */
-return i;
-}
-#endif
-
-
#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,19))
/*
@@ -76,84 +50,8 @@ pgprot_t vm_get_page_prot(unsigned long vm_flags)
#endif
-#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,15))
-
-/*
- * vm code for kernels below 2.6.15 in which version a major vm write
- * occured. This implement a simple straightforward
- * version similar to what's going to be
- * in kernel 2.6.19+
- * Kernels below 2.6.15 use nopage whereas 2.6.19 and upwards use
- * nopfn.
- */
-
-static struct {
- spinlock_t lock;
- struct page *dummy_page;
- atomic_t present;
-} drm_np_retry =
-{SPIN_LOCK_UNLOCKED, NOPAGE_OOM, ATOMIC_INIT(0)};
-
-
-static struct page *drm_bo_vm_fault(struct vm_area_struct *vma,
- struct fault_data *data);
-
-
-struct page * get_nopage_retry(void)
-{
- if (atomic_read(&drm_np_retry.present) == 0) {
- struct page *page = alloc_page(GFP_KERNEL);
- if (!page)
- return NOPAGE_OOM;
- spin_lock(&drm_np_retry.lock);
- drm_np_retry.dummy_page = page;
- atomic_set(&drm_np_retry.present,1);
- spin_unlock(&drm_np_retry.lock);
- }
- get_page(drm_np_retry.dummy_page);
- return drm_np_retry.dummy_page;
-}
-
-void free_nopage_retry(void)
-{
- if (atomic_read(&drm_np_retry.present) == 1) {
- spin_lock(&drm_np_retry.lock);
- __free_page(drm_np_retry.dummy_page);
- drm_np_retry.dummy_page = NULL;
- atomic_set(&drm_np_retry.present, 0);
- spin_unlock(&drm_np_retry.lock);
- }
-}
-
-struct page *drm_bo_vm_nopage(struct vm_area_struct *vma,
- unsigned long address,
- int *type)
-{
- struct fault_data data;
-
- if (type)
- *type = VM_FAULT_MINOR;
-
- data.address = address;
- data.vma = vma;
- drm_bo_vm_fault(vma, &data);
- switch (data.type) {
- case VM_FAULT_OOM:
- return NOPAGE_OOM;
- case VM_FAULT_SIGBUS:
- return NOPAGE_SIGBUS;
- default:
- break;
- }
-
- return NOPAGE_REFAULT;
-}
-
-#endif
-
#if !defined(DRM_FULL_MM_COMPAT) && \
- ((LINUX_VERSION_CODE < KERNEL_VERSION(2,6,15)) || \
- (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,19)))
+ (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,19))
static int drm_pte_is_clear(struct vm_area_struct *vma,
unsigned long addr)
diff --git a/linux-core/drm_compat.h b/linux-core/drm_compat.h
index 937908a..d265ad1 100644
--- a/linux-core/drm_compat.h
+++ b/linux-core/drm_compat.h
@@ -152,8 +152,7 @@
#include
#include
-#if ((LINUX_VERSION_CODE < KERNEL_VERSION(2,6,19)) && \
- (LINUX_VERSION_CODE >= KERNEL_V
[PATCH 10/10] drm: drop Linux < 2.6.21 support
This also means, that DRM_FULL_MM_COMPAT is always defined,
so it is dropped, too.
Signed-off-by: Pekka Paalanen
---
linux-core/drm_compat.c | 164 ---
linux-core/drm_compat.h | 26
linux-core/drm_vm.c |6 +--
3 files changed, 1 insertions(+), 195 deletions(-)
diff --git a/linux-core/drm_compat.c b/linux-core/drm_compat.c
index fb39649..0ccd2ab 100644
--- a/linux-core/drm_compat.c
+++ b/linux-core/drm_compat.c
@@ -27,168 +27,6 @@
#include "drmP.h"
-#if !defined(DRM_FULL_MM_COMPAT)
-
-static int drm_pte_is_clear(struct vm_area_struct *vma,
- unsigned long addr)
-{
- struct mm_struct *mm = vma->vm_mm;
- int ret = 1;
- pte_t *pte;
- pmd_t *pmd;
- pud_t *pud;
- pgd_t *pgd;
-
- spin_lock(&mm->page_table_lock);
- pgd = pgd_offset(mm, addr);
- if (pgd_none(*pgd))
- goto unlock;
- pud = pud_offset(pgd, addr);
-if (pud_none(*pud))
- goto unlock;
- pmd = pmd_offset(pud, addr);
- if (pmd_none(*pmd))
- goto unlock;
- pte = pte_offset_map(pmd, addr);
- if (!pte)
- goto unlock;
- ret = pte_none(*pte);
- pte_unmap(pte);
- unlock:
- spin_unlock(&mm->page_table_lock);
- return ret;
-}
-
-static int vm_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
- unsigned long pfn)
-{
- int ret;
- if (!drm_pte_is_clear(vma, addr))
- return -EBUSY;
-
- ret = io_remap_pfn_range(vma, addr, pfn, PAGE_SIZE, vma->vm_page_prot);
- return ret;
-}
-
-
-static struct page *drm_bo_vm_fault(struct vm_area_struct *vma,
- struct fault_data *data)
-{
- unsigned long address = data->address;
- struct drm_buffer_object *bo = (struct drm_buffer_object *)
vma->vm_private_data;
- unsigned long page_offset;
- struct page *page = NULL;
- struct drm_ttm *ttm;
- struct drm_device *dev;
- unsigned long pfn;
- int err;
- unsigned long bus_base;
- unsigned long bus_offset;
- unsigned long bus_size;
-
- dev = bo->dev;
- drm_bo_read_lock(&dev->bm.bm_lock, 0);
-
- mutex_lock(&bo->mutex);
-
- err = drm_bo_wait(bo, 0, 1, 0);
- if (err) {
- data->type = (err == -EAGAIN) ?
- VM_FAULT_MINOR : VM_FAULT_SIGBUS;
- goto out_unlock;
- }
-
-
- /*
-* If buffer happens to be in a non-mappable location,
-* move it to a mappable.
-*/
-
- if (!(bo->mem.flags & DRM_BO_FLAG_MAPPABLE)) {
- unsigned long _end = jiffies + 3*DRM_HZ;
- uint32_t new_mask = bo->mem.proposed_flags |
- DRM_BO_FLAG_MAPPABLE |
- DRM_BO_FLAG_FORCE_MAPPABLE;
-
- do {
- err = drm_bo_move_buffer(bo, new_mask, 0, 0);
- } while((err == -EAGAIN) && !time_after_eq(jiffies, _end));
-
- if (err) {
- DRM_ERROR("Timeout moving buffer to mappable
location.\n");
- data->type = VM_FAULT_SIGBUS;
- goto out_unlock;
- }
- }
-
- if (address > vma->vm_end) {
- data->type = VM_FAULT_SIGBUS;
- goto out_unlock;
- }
-
- dev = bo->dev;
- err = drm_bo_pci_offset(dev, &bo->mem, &bus_base, &bus_offset,
- &bus_size);
-
- if (err) {
- data->type = VM_FAULT_SIGBUS;
- goto out_unlock;
- }
-
- page_offset = (address - vma->vm_start) >> PAGE_SHIFT;
-
- if (bus_size) {
- struct drm_mem_type_manager *man =
&dev->bm.man[bo->mem.mem_type];
-
- pfn = ((bus_base + bus_offset) >> PAGE_SHIFT) + page_offset;
- vma->vm_page_prot = drm_io_prot(man->drm_bus_maptype, vma);
- } else {
- ttm = bo->ttm;
-
- drm_ttm_fixup_caching(ttm);
- page = drm_ttm_get_page(ttm, page_offset);
- if (!page) {
- data->type = VM_FAULT_OOM;
- goto out_unlock;
- }
- pfn = page_to_pfn(page);
- vma->vm_page_prot = (bo->mem.flags & DRM_BO_FLAG_CACHED) ?
- vm_get_page_prot(vma->vm_flags) :
- drm_io_prot(_DRM_TTM, vma);
- }
-
- err = vm_insert_pfn(vma, address, pfn);
-
- if (!err || err == -EBUSY)
- data->type = VM_FAULT_MINOR;
- else
- data->type = VM_FAULT_OOM;
-out_unlock:
- mutex_unlock(&bo->mute
[PATCH 09/10] drm, via: drop Linux < 2.6.20 support
Signed-off-by: Pekka Paalanen
---
linux-core/drm_bo.c | 13 -
linux-core/drm_objects.h |4
linux-core/via_dmablit.c | 12
3 files changed, 0 insertions(+), 29 deletions(-)
diff --git a/linux-core/drm_bo.c b/linux-core/drm_bo.c
index 6f083f5..f43480c 100644
--- a/linux-core/drm_bo.c
+++ b/linux-core/drm_bo.c
@@ -481,20 +481,11 @@ static void drm_bo_delayed_delete(struct drm_device *dev,
int remove_all)
}
}
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
-static void drm_bo_delayed_workqueue(void *data)
-#else
static void drm_bo_delayed_workqueue(struct work_struct *work)
-#endif
{
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
- struct drm_device *dev = (struct drm_device *) data;
- struct drm_buffer_manager *bm = &dev->bm;
-#else
struct drm_buffer_manager *bm =
container_of(work, struct drm_buffer_manager, wq.work);
struct drm_device *dev = container_of(bm, struct drm_device, bm);
-#endif
DRM_DEBUG("Delayed delete Worker\n");
@@ -2356,11 +2347,7 @@ int drm_bo_driver_init(struct drm_device *dev)
if (ret)
goto out_unlock;
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
- INIT_WORK(&bm->wq, &drm_bo_delayed_workqueue, dev);
-#else
INIT_DELAYED_WORK(&bm->wq, drm_bo_delayed_workqueue);
-#endif
bm->initialized = 1;
bm->nice_mode = 1;
atomic_set(&bm->count, 0);
diff --git a/linux-core/drm_objects.h b/linux-core/drm_objects.h
index 2f49bcf..136fdc8 100644
--- a/linux-core/drm_objects.h
+++ b/linux-core/drm_objects.h
@@ -563,11 +563,7 @@ struct drm_buffer_manager {
struct drm_mem_type_manager man[DRM_BO_MEM_TYPES];
struct list_head unfenced;
struct list_head ddestroy;
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
- struct work_struct wq;
-#else
struct delayed_work wq;
-#endif
uint32_t fence_type;
unsigned long cur_pages;
atomic_t count;
diff --git a/linux-core/via_dmablit.c b/linux-core/via_dmablit.c
index b5f9f05..59e1e11 100644
--- a/linux-core/via_dmablit.c
+++ b/linux-core/via_dmablit.c
@@ -500,17 +500,9 @@ via_dmablit_timer(unsigned long data)
static void
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
-via_dmablit_workqueue(void *data)
-#else
via_dmablit_workqueue(struct work_struct *work)
-#endif
{
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
- drm_via_blitq_t *blitq = (drm_via_blitq_t *) data;
-#else
drm_via_blitq_t *blitq = container_of(work, drm_via_blitq_t, wq);
-#endif
struct drm_device *dev = blitq->dev;
unsigned long irqsave;
drm_via_sg_info_t *cur_sg;
@@ -579,11 +571,7 @@ via_init_dmablit(struct drm_device *dev)
DRM_INIT_WAITQUEUE(blitq->blit_queue + j);
}
DRM_INIT_WAITQUEUE(&blitq->busy_queue);
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,20)
- INIT_WORK(&blitq->wq, via_dmablit_workqueue, blitq);
-#else
INIT_WORK(&blitq->wq, via_dmablit_workqueue);
-#endif
init_timer(&blitq->poll_timer);
blitq->poll_timer.function = &via_dmablit_timer;
blitq->poll_timer.data = (unsigned long) blitq;
--
1.6.0.6
--
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 03/10] drm: drop Linux < 2.6.10 support
Signed-off-by: Pekka Paalanen
---
linux-core/drm_compat.h | 21 -
linux-core/mga_drv.c |2 +-
linux-core/nouveau_drv.c |2 +-
linux-core/r128_drv.c|2 +-
linux-core/radeon_drv.c |2 +-
linux-core/xgi_drv.c |2 +-
6 files changed, 5 insertions(+), 26 deletions(-)
diff --git a/linux-core/drm_compat.h b/linux-core/drm_compat.h
index a567356..937908a 100644
--- a/linux-core/drm_compat.h
+++ b/linux-core/drm_compat.h
@@ -107,27 +107,6 @@
#define IRQF_SHARED SA_SHIRQ
#endif
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10)
-static inline int remap_pfn_range(struct vm_area_struct *vma, unsigned long
from, unsigned long pfn, unsigned long size, pgprot_t pgprot)
-{
- return remap_page_range(vma, from,
- pfn << PAGE_SHIFT,
- size,
- pgprot);
-}
-
-static __inline__ void *kcalloc(size_t nmemb, size_t size, int flags)
-{
- void *addr;
-
- addr = kmalloc(size * nmemb, flags);
- if (addr != NULL)
- memset((void *)addr, 0, size * nmemb);
-
- return addr;
-}
-#endif
-
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,16)
#define mutex_lock down
#define mutex_unlock up
diff --git a/linux-core/mga_drv.c b/linux-core/mga_drv.c
index 14a0be4..ce49857 100644
--- a/linux-core/mga_drv.c
+++ b/linux-core/mga_drv.c
@@ -73,7 +73,7 @@ static struct drm_driver driver = {
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
-#if defined(CONFIG_COMPAT) && LINUX_VERSION_CODE > KERNEL_VERSION(2,6,9)
+#if defined(CONFIG_COMPAT)
.compat_ioctl = mga_compat_ioctl,
#endif
},
diff --git a/linux-core/nouveau_drv.c b/linux-core/nouveau_drv.c
index c8f57df..b31485a 100644
--- a/linux-core/nouveau_drv.c
+++ b/linux-core/nouveau_drv.c
@@ -70,7 +70,7 @@ static struct drm_driver driver = {
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
-#if defined(CONFIG_COMPAT) && LINUX_VERSION_CODE > KERNEL_VERSION(2,6,9)
+#if defined(CONFIG_COMPAT)
.compat_ioctl = nouveau_compat_ioctl,
#endif
},
diff --git a/linux-core/r128_drv.c b/linux-core/r128_drv.c
index 7b6159b..111fe71 100644
--- a/linux-core/r128_drv.c
+++ b/linux-core/r128_drv.c
@@ -68,7 +68,7 @@ static struct drm_driver driver = {
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
-#if defined(CONFIG_COMPAT) && LINUX_VERSION_CODE > KERNEL_VERSION(2,6,9)
+#if defined(CONFIG_COMPAT)
.compat_ioctl = r128_compat_ioctl,
#endif
},
diff --git a/linux-core/radeon_drv.c b/linux-core/radeon_drv.c
index 934fa0b..902bdc2 100644
--- a/linux-core/radeon_drv.c
+++ b/linux-core/radeon_drv.c
@@ -114,7 +114,7 @@ static struct drm_driver driver = {
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
-#if defined(CONFIG_COMPAT) && LINUX_VERSION_CODE > KERNEL_VERSION(2,6,9)
+#if defined(CONFIG_COMPAT)
.compat_ioctl = radeon_compat_ioctl,
#endif
},
diff --git a/linux-core/xgi_drv.c b/linux-core/xgi_drv.c
index bfe9acd..51ace0f 100644
--- a/linux-core/xgi_drv.c
+++ b/linux-core/xgi_drv.c
@@ -93,7 +93,7 @@ static struct drm_driver driver = {
.mmap = drm_mmap,
.poll = drm_poll,
.fasync = drm_fasync,
-#if defined(CONFIG_COMPAT) && LINUX_VERSION_CODE > KERNEL_VERSION(2,6,9)
+#if defined(CONFIG_COMPAT)
.compat_ioctl = xgi_compat_ioctl,
#endif
},
--
1.6.0.6
--
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 01/10] drm: drm_bo_mmap_locked() is static.
Signed-off-by: Pekka Paalanen
---
linux-core/drm_vm.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/linux-core/drm_vm.c b/linux-core/drm_vm.c
index d4d97a4..6de6031 100644
--- a/linux-core/drm_vm.c
+++ b/linux-core/drm_vm.c
@@ -870,8 +870,7 @@ static struct vm_operations_struct drm_bo_vm_ops = {
* \param map The buffer object drm map.
* \return zero on success or a negative number on failure.
*/
-
-int drm_bo_mmap_locked(struct vm_area_struct *vma,
+static int drm_bo_mmap_locked(struct vm_area_struct *vma,
struct file *filp,
drm_local_map_t *map)
{
--
1.6.0.6
--
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 07/10] drm: drop Linux < 2.6.18 support
Signed-off-by: Pekka Paalanen
---
linux-core/drm_compat.c | 45 -
linux-core/drm_compat.h | 11 ---
2 files changed, 0 insertions(+), 56 deletions(-)
diff --git a/linux-core/drm_compat.c b/linux-core/drm_compat.c
index e90338f..ff4085d 100644
--- a/linux-core/drm_compat.c
+++ b/linux-core/drm_compat.c
@@ -583,51 +583,6 @@ EXPORT_SYMBOL(idr_remove_all);
#endif /* DRM_IDR_COMPAT_FN */
-
-#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,18))
-/**
- * idr_replace - replace pointer for given id
- * @idp: idr handle
- * @ptr: pointer you want associated with the id
- * @id: lookup key
- *
- * Replace the pointer registered with an id and return the old value.
- * A -ENOENT return indicates that @id was not found.
- * A -EINVAL return indicates that @id was not within valid constraints.
- *
- * The caller must serialize vs idr_find(), idr_get_new(), and idr_remove().
- */
-void *idr_replace(struct idr *idp, void *ptr, int id)
-{
- int n;
- struct idr_layer *p, *old_p;
-
- n = idp->layers * IDR_BITS;
- p = idp->top;
-
- id &= MAX_ID_MASK;
-
- if (id >= (1 << n))
- return ERR_PTR(-EINVAL);
-
- n -= IDR_BITS;
- while ((n > 0) && p) {
- p = p->ary[(id >> n) & IDR_MASK];
- n -= IDR_BITS;
- }
-
- n = id & IDR_MASK;
- if (unlikely(p == NULL || !test_bit(n, &p->bitmap)))
- return ERR_PTR(-ENOENT);
-
- old_p = p->ary[n];
- p->ary[n] = ptr;
-
- return (void *)old_p;
-}
-EXPORT_SYMBOL(idr_replace);
-#endif
-
#ifdef DRM_FULL_MM_COMPAT
#ifdef DRM_NO_FAULT
unsigned long drm_bo_vm_nopfn(struct vm_area_struct *vma,
diff --git a/linux-core/drm_compat.h b/linux-core/drm_compat.h
index 7763da3..61a6d3d 100644
--- a/linux-core/drm_compat.h
+++ b/linux-core/drm_compat.h
@@ -125,12 +125,6 @@
}
#endif
-#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,18)
-#define vmalloc_user(_size) ({void * tmp = vmalloc(_size); \
- if (tmp) memset(tmp, 0, size);\
- (tmp);})
-#endif
-
#ifndef list_for_each_entry_safe_reverse
#define list_for_each_entry_safe_reverse(pos, n, head, member) \
for (pos = list_entry((head)->prev, typeof(*pos), member), \
@@ -275,11 +269,6 @@ int idr_for_each(struct idr *idp,
void idr_remove_all(struct idr *idp);
#endif
-
-#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,18))
-void *idr_replace(struct idr *idp, void *ptr, int id);
-#endif
-
#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,19))
typedef _Bool bool;
#endif
--
1.6.0.6
--
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 06/10] drm: drop Linux < 2.6.16 support
Signed-off-by: Pekka Paalanen --- linux-core/drmP.h |2 -- linux-core/drm_compat.h | 10 -- 2 files changed, 0 insertions(+), 12 deletions(-) diff --git a/linux-core/drmP.h b/linux-core/drmP.h index bc68bfe..6770282 100644 --- a/linux-core/drmP.h +++ b/linux-core/drmP.h @@ -56,9 +56,7 @@ #include #include #include -#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,16) #include -#endif #if defined(__alpha__) || defined(__powerpc__) #include/* For pte_wrprotect */ #endif diff --git a/linux-core/drm_compat.h b/linux-core/drm_compat.h index d265ad1..7763da3 100644 --- a/linux-core/drm_compat.h +++ b/linux-core/drm_compat.h @@ -107,16 +107,6 @@ #define IRQF_SHARED SA_SHIRQ #endif -#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,16) -#define mutex_lock down -#define mutex_unlock up - -#define mutex semaphore - -#define mutex_init(a) sema_init((a), 1) - -#endif - #ifndef DEFINE_SPINLOCK #define DEFINE_SPINLOCK(x) spinlock_t x = SPIN_LOCK_UNLOCKED #endif -- 1.6.0.6 -- 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: changes to upstreaming process for Linux code.
On Fri, 27 Feb 2009 23:54:21 -0800 vehemens wrote: > On Friday 27 February 2009 01:45:50 pm Kristian Høgsberg wrote: > > On Fri, Feb 27, 2009 at 4:40 PM, Dave Airlie wrote: > > > Prompted by how well it worked with Intel, and changes in my personal > > > life leading to reduced time availability (except at 4am...) I'm going to > > > clarify the process for getting patches upstream now. (a...@amd also > > > trialed this to get r600 upstream). > > > > > > 1. Apart from maybe minor changes I will no longer pull drm.git patches > > > into Linux kernel tree automatically. > > > > > > 2. All patches should be sent to dri-devel and me against my drm-next > > > tree. > > > > > > 3. Patches must conform to kernel coding standards and have acceptable > > > checkpatch.pl results. My only major issues with checkpatch.pl is 80 char > > > line length restrictions, please try your best but don't make the code > > > really ugly to achieve this. Some scripts/people are too anal. This also > > > means no kernel version checks upstream (however we might be able to > > > convince people about this, if we get build from Linus tree working). > > > > > > 4. I will accept sub-module maintainers who want to maintain their driver > > > in a git tree, but it'll take a bit of time for me to trust you that I'll > > > pull directly, and patches should still pass by the list. Ask Eric how to > > > do this. > > > > > > 5. if someone wants to step up and maintain drm.git as a going concern > > > let me know, I'm glad to help if I can. > > > > Sounds good to me - one question: should we divorce libdrm from the > > drm.git repo? > > As long as it stays on xorg, I wouldn't object as it would allow drm.git > master to be used for leading edge development. Leading edge development of what, exactly? If libdrm is moved out of drm.git, what is left is... Nouveau DRM? What does this suggestion of "divorce libdrm" mean? Only libdrm itself, or all the libdrm_* additional libraries too? To a single other repo, or each (sub-)library to its own repo? btw. where is Radeon DRM development happening now and in the near future? Do you need drm.git linux-core for anything? -- Pekka Paalanen http://www.iki.fi/pq/ -- 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 2/2] drm_compat: remove kmap_atomic_prot_pfn()
>From b4c40cb00c44e65dd2a722f99e88260e0746bc22 Mon Sep 17 00:00:00 2001
From: Pekka Paalanen
Date: Sat, 14 Feb 2009 22:22:39 +0200
Subject: [PATCH] drm_compat: remove kmap_atomic_prot_pfn()
This function is unused, and yet creates build problems: the symbol
init_mm is not exported by the latest -rc kernels and I don't believe it
ever will be. Even CONFIG_UNUSED_SYMBOLS does not provide it anymore.
If this function is needed in the future, it needs to be reinvented in
any case. So remove it.
Signed-off-by: Pekka Paalanen
---
linux-core/drm_compat.c | 29 -
linux-core/drm_compat.h | 21 -
2 files changed, 0 insertions(+), 50 deletions(-)
diff --git a/linux-core/drm_compat.c b/linux-core/drm_compat.c
index c4ebc2f..67baac5 100644
--- a/linux-core/drm_compat.c
+++ b/linux-core/drm_compat.c
@@ -730,35 +730,6 @@ void *idr_replace(struct idr *idp, void *ptr, int id)
EXPORT_SYMBOL(idr_replace);
#endif
-#if defined(DRM_KMAP_ATOMIC_PROT_PFN)
-#define drm_kmap_get_fixmap_pte(vaddr) \
- pte_offset_kernel(pmd_offset(pud_offset(pgd_offset_k(vaddr), vaddr),
(vaddr)), (vaddr))
-
-void *kmap_atomic_prot_pfn(unsigned long pfn, enum km_type type,
- pgprot_t protection)
-{
- enum fixed_addresses idx;
- unsigned long vaddr;
- static pte_t *km_pte;
- static int initialized = 0;
-
- if (unlikely(!initialized)) {
- km_pte = drm_kmap_get_fixmap_pte(__fix_to_virt(FIX_KMAP_BEGIN));
- initialized = 1;
- }
-
- pagefault_disable();
- idx = type + KM_TYPE_NR*smp_processor_id();
- vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
- set_pte(km_pte-idx, pfn_pte(pfn, protection));
-
- return (void*) vaddr;
-}
-
-EXPORT_SYMBOL(kmap_atomic_prot_pfn);
-
-#endif
-
#ifdef DRM_FULL_MM_COMPAT
#ifdef DRM_NO_FAULT
unsigned long drm_bo_vm_nopfn(struct vm_area_struct *vma,
diff --git a/linux-core/drm_compat.h b/linux-core/drm_compat.h
index 4ae4ba6..a567356 100644
--- a/linux-core/drm_compat.h
+++ b/linux-core/drm_compat.h
@@ -338,27 +338,6 @@ typedef _Bool bool;
#endif
-#if (defined(CONFIG_X86) && defined(CONFIG_X86_32) && defined(CONFIG_HIGHMEM))
-/*
- * pgd_offset_k() is a macro that uses the symbol init_mm,
- * check that it is available.
- */
-# if ((LINUX_VERSION_CODE < KERNEL_VERSION(2,6,25)) || \
- defined(CONFIG_UNUSED_SYMBOLS))
-#define DRM_KMAP_ATOMIC_PROT_PFN
-extern void *kmap_atomic_prot_pfn(unsigned long pfn, enum km_type type,
- pgprot_t protection);
-# else
-#warning "init_mm is not available on this kernel!"
-static inline void *kmap_atomic_prot_pfn(unsigned long pfn, enum km_type type,
-pgprot_t protection)
-{
- /* stub */
- return NULL;
-}
-# endif /* no init_mm */
-#endif
-
#if !defined(flush_agp_mappings)
#define flush_agp_mappings() do {} while(0)
#endif
--
1.6.0.6
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 0/4] Cursor's update inside kernel only
On Mon, 5 Jan 2009 18:55:50 -0200 Tiago Vignatti wrote: > Hi guys, > > Under KMS, we can build a feature to update the cursor directly to screen > without the continuous intervention of the userspace application (X server, > wayland, etc). It's a fastpath for DRM based cursors obtained by short-circuit > the kernel input layer and DRM module. This would solve all cursor's latency > issues that we have in our current model [0]. Reducing latency is a good idea, but I don't think circumventing user space altogether is so good. Consider a case where user space is stalled due to excessive load, and let's think about usability. Much of usability comes from feedback given to a user. If cursor updates are done completely inside the kernel, the mouse will continue to work without any hiccups under severe load (this is what you are aiming for, right?). The user clicks a button, and nothing happens in the GUI, since user space is stalled. The user clicks again. And again. Then clicks another button. It takes several seconds for the user to realize, that the clicks are not getting processed. What's worse, all the clicks are probably queued now and will be processed later, possibly leading to unexpected results. If cursor updates had to visit user space, the mouse cursor would stall and jump. This is bad behaviour in itself, but it is also an immediate feedback to the user, that the system is not responsive. The user cannot even reach a button to click it, before he sees that something is going on. In a bad situation, I think this is the less evil choice. This analysis is based on how I use GUIs, and how I think my mother uses GUIs as I've watched her, and we are on a very different level of thinking on how computers and GUIs with a mouse work. Sure, modern GUIs have mouse enter/leave animations for widgets, but it takes an experienced user to notice that hey, that button didn't turn blue when I moved my mouse over it, something's wrong. Making the mouse cursor jump is something no-one can ignore, even when they are in a hurry. If you embrace the idea that cursor updates have to visit user space, I believe it will make implementing things like secondary cursors and cursors that exceed hardware capabilities (e.g. very large cursors) easier. You don't have to implement a full 3D engine driver in the kernel to just blit the cursor image on screen (aren't simple blitting engines and overlays disappearing in the modern development of graphics hardware?). -- Pekka Paalanen http://www.iki.fi/pq/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] dristat: Fix POSIX_C_SOURCE=199309L define and link against librt
On Sun, 18 Jan 2009 20:49:02 +0100
Rafael Antonio Porras Samaniego wrote:
> in my Gentoo box, "dristat", from "mesa/drm", fails to build because of
> an incorrect define in linux-core/Makefile: "-DPOSIX_C_SOURCE=199309L"
> should be "-D_POSIX_C_SOURCE=199309L". Also, "-lrt" is needed in the
> linking stage.
>
> This problem was filed as a bug [1] to Gentoo's bugzilla but I think
> that it should be fixed at this level.
> [1] http://bugs.gentoo.org/show_bug.cgi?id=254649
Please, fix your build system to use the right Makefile, which is
tests/Makefile. {dri,drm}stat are built with libdrm.
This is purely a Gentoo packaging bug.
See
http://cgit.freedesktop.org/mesa/drm/commit/?id=27fae006853647ad0087067adc4eaa8d4ed4594a
--
Pekka Paalanen
http://www.iki.fi/pq/
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: How to get the physical frame buffer address?
On Mon, 12 Jan 2009 09:51:33 + Paul Winder wrote: > I get the impression the code destined for the kernel only has > modesetting for intel?? Is this cvorrect? > > The modesetting-gem branch seems to have modesetting for radeon and nv. > I need to have full modesetting for a variety of chips, which is why I > was keen on the modesetting-gem branch. If by nv you mean Nouveau (please, don't confuse these two), Nouveau has a KMS-experiment only for a limited set of nv50 class hardware, and IIRC it has been on hold for some time waiting for better memory management. So IMHO saying, that Nouveau has KMS, is exaggeration. Unless someone has continued stillunknown's work, but I have not heard of that. Also, I do not know where or when the real Nouveau KMS-support will be developed. > Is the modesetting-gem branch defunct now? Where else is the modesetting > fro the other chips maintained? -- Pekka Paalanen http://www.iki.fi/pq/ -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] libdrm merge of KMS bits
On Thu, 11 Dec 2008 15:11:23 -0800
Jesse Barnes wrote:
> Initially I thought the merge of the KMS bits into libdrm would be as easy as
> merging the modesetting-gem branch into master. But that branch has a ton of
> stuff in it, including code for radeon and nv that its maintainers probably
> don't want merged yet. So I reverted my initial attempt and came up with this
> patch instead.
>
> If it looks ok, I'll go ahead and commit it. It basically just pulls over
> the
> xf86drmMode.* bits along with the new ioctl definitions in shared-core.
I was going to try and see if this breaks nouveau, but the patch looks
line-break damaged, and I couldn't get it to apply.
Please do not mix the names nouveau and nv.
> diff --git a/libdrm/Makefile.am b/libdrm/Makefile.am
> index a5be36e..c3619a6 100644
> --- a/libdrm/Makefile.am
> +++ b/libdrm/Makefile.am
> @@ -22,13 +22,14 @@ SUBDIRS = . intel
>
> libdrm_la_LTLIBRARIES = libdrm.la
> libdrm_ladir = $(libdir)
> -libdrm_la_LDFLAGS = -version-number 2:4:0 -no-undefined
> +libdrm_la_LDFLAGS = -version-number 2:3:0 -no-undefined
Is this intentional?
>
> AM_CFLAGS = -I$(top_srcdir)/shared-core
> libdrm_la_SOURCES = xf86drm.c xf86drmHash.c xf86drmRandom.c xf86drmSL.c \
> + xf86drmMode.c libdrm_lists.h
> libdrm_lists.h
>
> libdrmincludedir = ${includedir}
> -libdrminclude_HEADERS = xf86drm.h
> +libdrminclude_HEADERS = xf86drm.h xf86drmMode.h
>
> EXTRA_DIST = ChangeLog TODO
--
Pekka Paalanen
http://www.iki.fi/pq/
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] TTM user interface.
On Mon, 15 Sep 2008 20:12:06 +0200 Thomas Hellström <[EMAIL PROTECTED]> wrote: > Austin Yuan wrote: > > Hi, Thomas > > > > >From ttm_placement_user.h, it seems now TTM BO doesn't support user > > buffers. For the case that I want to pass a special memory token to > > kernel to indicate TTM to create a BO from the pages specified by the > > user space memory token, how can I achieve it, especially if a TTM BO > > derive from a SHMEM object? Can I create a SHMEM object with any > > pages backing it ? > > > It's possible to create a shmem object without any pages backing it, if > needed. > > For user-buffers one should probably construct a separate > driver-specific IOCTL. > Since this is an RFC, and I agree that user-buffers are sometimes very > handy I'll include > a user-buffer create IOCTL and send out a new version. > > Some examples of above use case, map pages which store frames from a > > camera into graphics memory space and then display or encode it > > directly avoiding a memory copy, video or display engine operates on > > pages locked by a security engine and CPU access is forbidden for > > digital rights management purpose. Those cases needs user space stuff > > pass some special private date to kernel memory manager for BO > > creation. This thing sounds like something I might use in the future: have a firewire camera to DMA images directly into memory accessible by the GPU, with probably user space handling the synchronization. I'm thinking real-time high resolution image processing and machine vision. And if I could RT-prioritize GPU threads/contexts, it would sound like the ideal environment for RT machine vision apps. It's something I've been dreaming about, just to let you know. -- Pekka Paalanen http://www.iki.fi/pq/ - 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=100&url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] DRM developer guide
On Thu, 19 Jun 2008 15:13:51 -0700 Jesse Barnes <[EMAIL PROTECTED]> wrote: > In a shameless attempt to capitalize on the recent enthusiasm for documenting > things, I've put together a skeletal DRM developer guide. Yay! \o/ > The attached PDF was generated from the attached DocBook template, and > references Linux kernel doc comments in the sources. Unfortunately, the > current DRM has a mix of Linux kernel doc and doxygen documentation, and only > some of the very recent stuff is actually accurate and usable. Btw. which should be used in DRM, Linux kernel doc or doxygen? Without the bsd directory the answer would be obvious to me. > Any thoughts? I have only a couple minor comments as a newbie. Driver initialization: - talks about struct drm_device, then the example has struct drm_driver. Is there a difference? - proper indenting of sample code missing, makes the drm_driver example a bit awkward to read. VBlank event handling: - the last paragraph "...vblank functions into no-ops." seems contradicting the previous paragraph. I'm very much looking forward to the next revision with more goodies. :-) -- Pekka Paalanen http://www.iki.fi/pq/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: TTM vs GEM discussion questions
On Fri, 16 May 2008 10:05:18 +0200 Jerome Glisse <[EMAIL PROTECTED]> wrote: > My current understanding is that on newer GPU each client got its > own memory address space on the GPU. I can manage this space > transparently based on hint from userspace, ie i can place page > either in ram or vram and i can do migration when necessary. As > a result i think i have no obligation that page in VRAM to be > adjacent each to the other. Of course mapping such thing in > userspace vma become cumberstone. This sounds like a feature that could be used to avoid applying any relocations into commands streams, and completely get rid of kernel validation of a command stream beforehand, allowing direct unobstructed command submission from user space to the card. It would just be like "applying relocations in hardware", using page tables instead of rewriting addresses in certain spots in a command stream. Or have I misunderstood something? (Oh, in a later email Glisse writes the same idea.) This sounds interesting, since it would promote command submission that does not go through the kernel at all, which is what Nouveau is already interested in. Somehow I have a recollection that TTM would force the command stream through the kernel, but then again, I'm very new to all this. Just my 2c. -- Pekka Paalanen http://www.iki.fi/pq/ - 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
[PATCH] linux-core Makefile: add GIT_REVISION
>From ee7e21c2cd96ce8b1a31f9013d606ab0ea3699e6 Mon Sep 17 00:00:00 2001
From: Pekka Paalanen <[EMAIL PROTECTED]>
Date: Sun, 20 Apr 2008 20:47:38 +0300
Subject: [PATCH] linux-core Makefile: add GIT_REVISION
This tries to automatically fetch a git revision string and if succeeds,
it #defines GIT_REVISION string macro. Packagers can override it by
'make GIT_REVISION=foo'.
Update Nouveau to use GIT_REVISION, if defined, instead of DRIVER_DATE
in struct drm_driver.
Signed-off-by: Pekka Paalanen <[EMAIL PROTECTED]>
---
Hi,
may I push this to DRM?
Marcheu ok'd it already.
linux-core/Makefile |5 +
linux-core/nouveau_drv.c |4
2 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/linux-core/Makefile b/linux-core/Makefile
index 7f6b123..3af6f37 100644
--- a/linux-core/Makefile
+++ b/linux-core/Makefile
@@ -335,6 +335,11 @@ ifneq (,$(findstring i915,$(DRM_MODULES)))
CONFIG_DRM_I915 := m
endif
+GIT_REVISION := $(shell cd "$(DRMSRCDIR)" && git-describe --abbrev=17)
+ifneq ($(GIT_REVISION),)
+EXTRA_CFLAGS+=-D"GIT_REVISION=\"$(GIT_REVISION)\""
+endif
+
include $(DRMSRCDIR)/Makefile.kernel
# Depencencies
diff --git a/linux-core/nouveau_drv.c b/linux-core/nouveau_drv.c
index e9623eb..c8f57df 100644
--- a/linux-core/nouveau_drv.c
+++ b/linux-core/nouveau_drv.c
@@ -86,7 +86,11 @@ static struct drm_driver driver = {
.name = DRIVER_NAME,
.desc = DRIVER_DESC,
+#ifdef GIT_REVISION
+ .date = GIT_REVISION,
+#else
.date = DRIVER_DATE,
+#endif
.major = DRIVER_MAJOR,
.minor = DRIVER_MINOR,
.patchlevel = DRIVER_PATCHLEVEL,
--
1.5.3.7
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Nouveau] Question About The Steps
People, when you reply, please drop nouveau@ from CC list, as this is not Nouveau-specific. My comments are mixed in the first quoted e-mail. Thanks. On Thu, 05 Jul 2007 09:35:24 +0800 "xiao dan" <[EMAIL PROTECTED]> wrote: > Dear Sir: > Thanks a lot for your reply.Here is the details: > 1>The hardware we have now is the ATI Radeon 9000(For > 1>students,money > is the biggest problem). Nouveau deals with Nvidia graphics. Proprietary Radeon drivers work a little different and the radeon project uses different reverse engineering tools. I do not know much about those. > 2>The operating system we currently use is Redhat 9.0. You do know this OS died in 2004 and even Fedora Legacy shut down early this year? http://en.wikipedia.org/wiki/Red_Hat_Linux > 3>What exactly we want to do is to get the work mechanism of the > 3>ATI > driver from the binary codes under the OS. What do you mean by this? Are you proposing to clean-room reverse engineer (possibly disassemble) the proprietary driver, and write the documentation for someone else, who will then write a driver? There are legal issues involved, so please be very specific about what you want to do, or are going to do. It may make the difference between your contribution being a valuable benefit or completely useless for the community. You also said you are a graduate student. Is this supposed to be related your scientific work, and how? As far as I can tell, there already are (fully?) working open source radeon drivers for 9000 cards. http://dri.freedesktop.org/wiki/ATI I do not know much about the radeon development, but I'm sure you find the people on dri-devel mailing list (CC'd here). Perhaps The irregular Radeon Development Companion can provide you more pointers: http://tirdc.livejournal.com/ > 4>The members of our team are all students.We are interested in > 4>this. > The biggest problem for us is that how to get the work mechanism > of the driver from the binary codes or how the dirver works in the > linux. Waiting for your reply thirstily! Thanks a lot! >yours, > shadow > > > >From: Pekka Paalanen <[EMAIL PROTECTED]> > >To: "xiao dan" <[EMAIL PROTECTED]> > >CC: [EMAIL PROTECTED] > >Subject: Re: [Nouveau] Question About The Steps > >Date: Wed, 4 Jul 2007 12:41:17 +0300 > > > >On Wed, 04 Jul 2007 10:47:46 +0800 > >"xiao dan" <[EMAIL PROTECTED]> wrote: > > > > > Dear Sir: > > > Sorry to bother you! I am a graduate student in China,and my > > > team is currently working on the video card driver. Our target is > > > that the result we get can be used in some kind of Operating > > > System like linux. As newers,the biggest problom for us is that > > > the steps to do the work is not very clear. It will be very kind > > > of you to give us a picture of the proceeding. We have the basic > > > knowledge,but don't know which point to start. > > > >Hello, > > > >at least I did not really understand your question, so I'm asking > >more details. > > > >By the video card driver do you mean Nouveau? > >What hardware are you working with? > >By operating system do you mean specifically Linux, or *BSD or > >something else? > >What is it exactly what you want to do? > >Would you be contributing to the Nouveau code base, under the > >propriate licenses and legal terms? > > > >Thanks. > > -- Pekka "PQ" Paalanen http://www.iki.fi/pq/ - 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: [Nouveau-cvs] renouveau [koala_br]
On Tue, 17 Apr 2007 20:15:53 +0100 Richard Hughes <[EMAIL PROTECTED]> wrote: > Any chance we could get a make dist target for renouveau please? The > attached patch works for me, and allows me to build automated daily > snapshots. I think everyone kind of trusts that the used renouveau version is from the same date as a dump is generated. It would be unfortunate to automatically overwrite a dump from a newer version of renouveau with a dump from an older version, just because the latter was sent later. I know this is more of a dump handling problem than packaging problem. Can you push a new package to users as an easy update? Personally I think it would be nice to have packages versioned by the last date of change to the whole renouveau CVS tree. Hardcoded version number is not so nice for developers. There exists a script which downloads renouveau from CVS, compiles, runs, and makes a package of the results. Just my 2c. ps. I could commit the patch when I get the time. -- Pekka "PQ" Paalanen http://www.iki.fi/pq/ - 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: [nouveau] gentoo ebuild masked by a missing keyword
On Tue, 23 Jan 2007 18:55:10 -0800 "Alexy Khrabrov" <[EMAIL PROTECTED]> wrote: > Well, after solving Gentoo-specific masking issues (thanks to folks > who replied!), libdrm pulled by nouveau fails to build due to the > build's own issues -- is that Gentoo ebuild of nouveau maintained? > The references to the ebuilds are on the wiki, hence I hope it's fair > to ask. I pulled it with layman -a nouveau. Hello I'm the current maintainer of those ebuilds. If you have problems, send your report to me. I don't think anyone else will be interested. As it is said in http://nouveau.freedesktop.org/wiki/GentooEbuilds , nothing is guaranteed. I will not take any pressure from maintaining them, but I do use them myself. If they work for me, they are on low priority. Please, keep in mind that these ebuilds are of extremely experimental nature. -- Pekka "PQ" Paalanen http://www.iki.fi/pq/ - 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.php&p=sourceforge&CID=DEVDEV -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
