tomic(): does a kmap_atomic(pfn)
>
> - io_unmap_atomic(): does a kunmap_atomic(pfn)
>
> so on 32-bit we have the INVLPG TLB overhead and preemption restrictions
> - but we knew that. We'd have to allow atomic_k
if you see something
that interests you feel free to help out.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practice
On 8/8/05, Geert Uytterhoeven <[EMAIL PROTECTED]> wrote:
> On Sun, 7 Aug 2005, Jon Smirl wrote:
> > On 8/7/05, Antonino A. Daplas <[EMAIL PROTECTED]> wrote:
> > > Vladimir Dergachev wrote:
> > > >> I agree that something like the above is acceptable, e
to set everything in one go.
> Separating all those fields into different sysfs attributes will have
> a problem with synchronization.
>
> One workaround is to have another attribute 'Activate'. Nothing is set
> until the 'Activate' attribute is written to. There is still
same config, //8, right? You then just control
what you write to the byte.
8 bpp monochrome (black is all zeroes and white is all ones or vice versa)
8 bpp greyscale
How does this work, is one 24 bit color the key?
32 bpp indexed+RGB 888 with color key to enable RGB888
--
Jon Smirl
[EMAIL PROT
On 8/6/05, Patrick McFarland <[EMAIL PROTECTED]> wrote:
> On Friday 05 August 2005 04:19 pm, Jon Smirl wrote:
> > I've included the scanout types for the R200, what other ones are
> > supported by the various chips? For example I think the R300 can
> > scanout
10:10 palette bypassed
Note, the r200 supports a lot more buffer formats, but these are the
only ones valid for scanout.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19
bf1e823f09802a71db0561 mesa_test.sh
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.2.6 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFC8VIoX1gOwKyEAw8RAjvoAJ9ZR5Ok0YV6WOjB9pWNiBUHFcQC+gCfeGMh
> h50ylD5bloXmpnNF5h2kMAE=
> =bYu+
> -END
Root IOCTLs used by my first test program.
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
--- a/linux-core/drm_drv.c
+++ b/linux-core/drm_drv.c
@@ -65,36 +65,36 @@ drm_ioctl_desc_t drm_ioctls[] = {
[DRM_IOCTL_NR(DRM_IOCTL_GET_MAP)] = {drm_getmap
On 8/3/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jon Smirl wrote:
> > On 8/3/05, Dave Airlie <[EMAIL PROTECTED]> wrote:
> >
> >>I'm not over-the-moon about this approach of changing the syste
ent * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> --
> _______
> Dri-devel mailing list
> Dri-devel@lists.sourceforge.net
> https://lists.sourceforge.net/
DRM_IOCTL_MARK_BUFS
DRM_IOCTL_CONTROL
DRM_IOCTL_AGP_ACQUIRE
DRM_IOCTL_AGP_RELEASE
DRM_IOCTL_AGP_ENABLE
DRM_IOCTL_AGP_ALLOC
DRM_IOCTL_AGP_FREE
DRM_IOCTL_AGP_BIND
DRM_IOCTL_AGP_UNBIND
DRM_IOCTL_SG_ALLOC
DRM_IOCTL_SG_FREE
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net
On 8/3/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-03 at 17:10 -0400, Jon Smirl wrote:
> > On 8/3/05, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2005-08-03 at 16:18 -0400, Jon Smirl wrote:
> > > > On 8/3/0
New version that protects r128 and radeon IOCTLs with root capablity
check. Please review this patch. We need everyone's eyes to make sure
there are no accidental security holes.
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
--- a/linux-core/drmP.h
On 8/3/05, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-03 at 15:02 -0400, Jon Smirl wrote:
> > On 8/3/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2005-08-03 at 14:39 -0400, Jon Smirl wrote:
> > > > > ioctls where removing t
On 8/3/05, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-03 at 16:18 -0400, Jon Smirl wrote:
> > On 8/3/05, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> > > >
> > > > They aren't used in the mesa tree.
> > >
> > > So wh
On 8/3/05, Michel Dänzer <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-03 at 15:14 -0400, Jon Smirl wrote:
> > On 8/3/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> > >
> > > These are the indirect ioctls, which allow the X Server to submit a
> > > buff
On 8/3/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-03 at 15:02 -0400, Jon Smirl wrote:
> > On 8/3/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> > > On Wed, 2005-08-03 at 14:39 -0400, Jon Smirl wrote:
> > > > > ioctls where removing t
On 8/3/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> On Wed, 2005-08-03 at 14:39 -0400, Jon Smirl wrote:
> > > ioctls where removing the root check introduces privelege escalation for
> > > users with read access to the DRM device (at least):
> > > - DRM_R128_
= NULL;
+ dev->sigdata.lock = NULL;
init_waitqueue_head(&dev->lock.lock_queue);
dev->queue_count = 0;
dev->queue_reserved = 0;
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
--- a/linux-core/drmP.h
+++ b/linux-core/drm
tart);
>
> A dma_addr_t (dev_priv->bus_pci_gart) is a long on at least some
> systems. While we may know that it's 32 bits here, a cast will be
> needed to avoid warnings.
I was getting a warning in my build.
>
> ioctls where removing the root check introduces privelege escalation
in AGP space.
3) Deprecation of some radeon variables now calculated by the driver
I haven't converted PCI GART support. You still need to be root for it to work.
Please look it over and tell me if I have created any security holes.
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/linux
ra - http://enigmail.mozdev.org
>
> iD4DBQFC7mEQX1gOwKyEAw8RAlMdAKCZe3qcw61nVEw9mLfS4TCMxjGeRACY1aen
> 2yT61/LyAUhN7ivtLfhdjQ==
> =x6eQ
> -END PGP SIGNATURE-
>
>
> ___
> xorg mailing list
> [EMAIL PROTECTED]
> http://lists.freedes
http://www.khronos.org/news/press/releases/rel45.html
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative
On 7/28/05, Alex Deucher <[EMAIL PROTECTED]> wrote:
> On 7/28/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > Do any of the radeon chips support RGB10 or RGB10_A2 for their scanout
> > buffers?
> >
> > If so, do these chips have 10 bit color maps?
>
>
Do any of the radeon chips support RGB10 or RGB10_A2 for their scanout buffers?
If so, do these chips have 10 bit color maps?
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is Sponsored by the Better Software Conference & EXPO Septembe
I can build with your GLX changes but I can't get the chip
initialized. That doesn't have anything to do with your changes.
Dave will probably clean miniglx up tonight.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sp
back to stand-alone Mesa Xlib rendering if
> the X server didn't support the GLX extension. That was important for
> some of the distros years ago.
Do you want to get rid of GLX_BUILT_IN_XMESA since you're cleaning
everything up?
--
Jon Smirl
[EMAIL PROTECTED]
-
/**
* \name Functions provided by the driver loader.
*/
/[EMAIL PROTECTED]/
extern __DRIscreen *__glXFindDRIScreen(__DRInativeDisplay *dpy, int scrn);
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux
-DDRM_USE_MALLOC
configs/linux-solo-ia64:DEFINES = -DDRI_NEW_INTERFACE_ONLY
-D_POSIX_SOURCE -D_SVID_SOURCE -D_BSD_SOURCE -D_POSIX_C_SOURCE=199309L
-D_GNU_SOURCE -DDRM_USE_MALLOC
include/GL/internal/dri_interface.h:#ifndef DRI_NEW_INTERFACE_ONLY
--
Jon Smirl
[EMAIL PROTECTED
Is anyone interested in working on this while I'm at OLS next week? I
have it all compiling and sort of working, but things are still not
initialized totally right. Something is still messed up when setting
up the DRM driver. I'll make up some diffs if anyone is interested.
--
Jon Sm
buffer
pointers/stride/whatever.
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/src/glx/x11/glxcmds.c b/src/glx/x11/glxcmds.c
--- a/src/glx/x11/glxcmds.c
+++ b/src/glx/x11/glxcmds.c
@@ -72,6 +72,26 @@ static void * DriverCreateContextWrapper
Display *dpy, XVisualInfo *vis, void *shared, __
= 1, /**< no caching, no core dump */
_DRM_SHM = 2, /**< shared, cached */
_DRM_AGP = 3, /**< AGP/GART */
_DRM_SCATTER_GATHER = 4, /**< Scatter/gather memory for PCI DMA */
_DRM_CONSISTENT = 5 /**< Consistent memory
So if I am reading the code right X's GLX implementation is inside of
libGL. So how do I do an alternative GLX implementation? miniglx just
built another libGL. I could do that too but is there a better way?
--
Jon Smirl
[EMAIL PROT
On 7/12/05, Adam Jackson <[EMAIL PROTECTED]> wrote:
> On Tuesday 12 July 2005 11:17, Jon Smirl wrote:
> > On 7/12/05, Adam Jackson <[EMAIL PROTECTED]> wrote:
> > > On Tuesday 12 July 2005 10:03, Jon Smirl wrote:
> > > > Is there a way to build DRI
On 7/12/05, Adam Jackson <[EMAIL PROTECTED]> wrote:
> On Tuesday 12 July 2005 10:03, Jon Smirl wrote:
> > Is there a way to build DRI exactly like X needs from the mesa tree or
> > can this only be done instead the X tree? If I made the right set of
> > stubs could I b
Is there a way to build DRI exactly like X needs from the mesa tree or
can this only be done instead the X tree? If I made the right set of
stubs could I build in the mesa tree? Do I need to define
GLX_BUILT_IN_XMESA?
--
Jon Smirl
[EMAIL PROTECTED
http://lwn.net/Kernel/LDD3/
Chapter 15 explains how DMA works under Linux.
--
Jon Smirl
[EMAIL PROTECTED]
---
This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening
July 14 at 8am PDT/11am EDT. We invite you
visible screens and is a
compute only render device?
In my EGL code contexts are associated with the card, not the screen.
This is causing me problems when I try using DRI which associates them
with screens.
--
Jon Smirl
[EMAIL PROTECTED
ction
XF86DRIAuthConnection
XF86DRIGetClientDriverName
XF86DRIQueryVersion
XF86DRIGetDeviceInfo
XF86DRICloseConnection
XF86DRIGetDrawableInfo
Is there any simple way to sort of this out? I'd rather not build
another version of dri_util.c with slight variations just to support
EGL.
--
Jon Sm
On 7/3/05, Paul Mackerras <[EMAIL PROTECTED]> wrote:
> Jon Smirl writes:
>
> > drmMap never cares about the handle since drmMap turns into mmap and
> > mmap doesn't know about DRM maps.
>
> Huh? drm_mmap certainly does know about DRM maps.
I see now that dr
spend on this project.
The code is in a separate library currently but it is not hard to
merge it into the Linux version of libEGL.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategie
arly if that first module is always getting loaded.
Brian wants to keep libEGL crossplatform and generic so this forces me
into a third library. I'm putting all of the common code into the
third library too. It contains code similar to miniglx.c
--
Jon Smirl
[EMAIL PROTECTED]
---
On 7/3/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
> Any ideas on what to call my DRM sysfs attribute which provides the
> name of the corresponding DRI library? I named it "dri" initially but
> that may not be descriptive enough.
I called it dri_library_name, we can always
human to see which driver the
DRM module needs.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts an
Any ideas on what to call my DRM sysfs attribute which provides the
name of the corresponding DRI library? I named it "dri" initially but
that may not be descriptive enough.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sp
drivers with no DRM. What is up with these?
gamma
s3v
trident
During the EGL driver load process it checks /sys/drm/* looking for
card? entries. When it finds one I need a sysfs attribute in
/sys/drm/card?/dri to tell me which dri library to load.
--
Jon Smirl
[EMAIL PROTECTED
break;
}
}
if (!disp->pSAREA)
return 0;
drmMap never cares about the handle since drmMap turns into mmap and
mmap doesn't know about DRM maps.
--
Jon Smirl
[EMAIL PROTECTED]
patch
Description: Binary data
g pretty well. I'd suggest using it as a test case for
your r300 work. It exercises a large number of OpenGL features some of
which are not comonly used. It is also a good thing to compare to
since it works without problems on the ATI drivers.
http://www.freedesktop.org/wiki/Softwa
Don't the maps always contain the physical address of the object? That
would provide a unique handle.
Where does the handle get used in user space? After I GetMap() to find
the map I need, I pass the offset back into drmMap() not the handle.
Offset is the physical address in most cases.
--
On 6/29/05, Keith Whitwell <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > In i810/server/i810_dri.c there is a call to agp alloc without the
> > type set to zero:
> > drmAgpAlloc(ctx->drmFD, 4096 * 1024, 1, NULL, &dcacheHandle);
> >
> > A type of o
parameter on agp alloc?
This is the only place where a type other than zero is used.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforw
On 6/29/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
> drmAgpAlloc() allocs drm_agp_mem structures which track the agp
> allocs. I could change the map system to allow a single map to be
> paired with each struct drm_agp_mem.
>
> The 2MB restricted you are using was all
zero and that won't work with drmMap(). After changing
to the offset field I am just ignoring the handles.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to
ate a piece of
AGP memory marked restricted.
The drivers would then be changed to alloc the various parts of AGP
space instead of allocing one big chunk and carving it up. By allocing
multiple pieces the master can set different privs on each piece.
Backwards compatibility is maintained since roo
ub-maps which must exist
inside of the predefined AGP map. These sub-maps would lower the priv
requirements for parts of AGP space and allow the clients to run.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migrati
done recently or is this ancient baggage in xf86drm.h that I
can remove?
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward
y the call
> > in-kernel or use something like call_userhelper() to do the work in
> > user space.
>
> As I explained already, I think it should be a userland daemon, that's
> really the best way to deal with access control and would fix all of the
> issues.
How do I c
list = drm_alloc(sizeof(*list), DRM_MEM_MAPS);
memset(list, 0, sizeof(*list));
same as drm_calloc()
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find
e, map->size, found_map->size);
found_map->size = map->size;
}
Should be moved into drm_find_matching_map()
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover
&handle, &size);
> drmGetSAREA(1, &handle, &size);
>
> whereas drmGetSAREA(2,) and upwards would fail in this case.
>
> /Thomas
That will work since the amount of memory being allocated is
constrained by the driver.
--
Jon Smirl
[EMAIL PROTECTED]
--
ned long drm_get_resource_len(drm_device_t *dev, unsigned int resource)
{
return pci_resource_len(dev->pdev, resource);
}
EXPORT_SYMBOL(drm_get_resource_len);
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discove
You can make AddMap simpler by using a stack based drm_map_t and then
allocating the real one at the end. It lets you remove all of the
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
This should be done at the very end after all of the error returns:
if (drm_core_has_MTRR(dev)) {
gain. I think this is going to require an addmap
> helper for dealing with PCI resources, but I think I've got a decent API
> in mind.
I need a prebuilt sarea map if you want to do that.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net
On 6/28/05, Eric Anholt <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-06-28 at 16:22 -0400, Jon Smirl wrote:
> > This fixes so that my egl driver will get started. You probably need
> > to test it further.
> >
> > You are creating the maps in radeon_preinit and it on
This fixes so that my egl driver will get started. You probably need
to test it further.
You are creating the maps in radeon_preinit and it only gets called
once at driver load time. Map creation needs to be moved over to the
open_help function so they will get rebuilt each time.
--
Jon Smirl
ECTED] jonsmirl]#
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you ne
On 6/28/05, Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jon Smirl wrote:
> > From what I can tell vesafb use is pretty rare. A while ago I broke
> > things in DRM CVS so that vesafb wouldn't work, it was
quest an arbitrary number or size of
sarea. If the API allows general requests it has to be root only.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Road
.
Since my drivers aren't running as root they have a hard time
collecting info like this.
Other solutions:
1) call_userhelper() - user mode driver helper that runs in root context
2) put the complex code in the driver and just mark it _init. It will
go poof as soon as the driver load is finish
there some need for user space collecting info about the
hardware and then feeding it back into the driver that I can't see?
7) Any more issues?
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migra
oot transition. After the
call is in the kernel each driver can choose to satisfy the call
in-kernel or use something like call_userhelper() to do the work in
user space.
>
> I'm trying to decide if the stub framework is worth the hassle of making
> generic or wheth
ve to fix the suspend/resume and mode setting code. The radeon is
messed up because of conflicts between the drivers, the i915 is simply
missing needed code - a stub won't help it.
I can also predict the probable outcome on kernel submission if we use
the stub to start build
n tell vesafb use is pretty rare. A while ago I broke
things in DRM CVS so that vesafb wouldn't work, it was about two
months until we got a complaint. DRM CVS is fixed for vesafb but the
long lag indicates that there aren't very many users. After the
problem the user switched to radeo
to be settled (it has been
going on for about 18 months with no action) why not simply fix
intelfb to work right on the i915?
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IB
matched map, at some point it could be
eliminated. The egl drivers I am working on don't run as root so I
need everything pre-added.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
t the driver. I have apps on my local machine that do
this this sequence and it works.
But, I think BenH is about to provide a low level VGA reset program
that eliminates the need for the DRM one. Is that right Ben?
--
Jon Smirl
[EMAIL PROT
On 6/27/05, Alan Hourihane <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 27, 2005 at 09:58:22AM -0400, Jon Smirl wrote:
> > Is it possible to add the suspend/resume support to Intelfb instead of
> > the DRM driver and then just load both drivers? Do we really want to
> > sta
being attached to the hooks.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get
u can do that on the x86 but it doesn't work on all architectures.
I'm sure any one who makes DRM sparse clean would get a big gold star
from Linus.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Lin
("Found existing: offset =
0x%08lx, size = 0x%08lx, type = %d\n",
map->offset, map->size,
0. I'd
> > definitely vote for 120. You will need to do some manual touch up
> > after Lindent. It will mess up formatting of C99 initializers and some
> > constant blocks.
>
> Please, 80 is standard.
I'm sorry, I forgot that you do
he r300 client code is added into the r200 driver, right? Not a third
library like radeon/r200/r300.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadm
all is to the power() function is device
> specific. Maybe this is incorrect though for multiple cards, and should
> be moved to per device classes.
I added ref counting to the global class so it should work now with
multiple cards.
--
Jon Smirl
[EMAIL PROTECTED]
-
#x27;s a problem too, but it is complicated to fix the fbdev error
case. I can put code back in that will work most of the time. The
problem error cases are when multiple DRM drviers are loaded.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email
On 6/24/05, Alan Hourihane <[EMAIL PROTECTED]> wrote:
> On Fri, Jun 24, 2005 at 12:31:06PM -0700, Jon Smirl wrote:
> > CVSROOT: /cvs/dri
> > Module name: drm
> > Repository: drm/linux-core/
> > Changes by: [EMAIL PROTECTED] 05/06/24 12:31:06
> &g
On 6/24/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
> On 6/24/05, Alan Hourihane <[EMAIL PROTECTED]> wrote:
> > Jon,
> >
> > I've noticed you've moved drm_pm_init().
> >
> > The reason it was were it was before is that the sysdev approach ne
n.
It was too complicated gettting all the error paths right. Easier to
just add it all of the time, it doesn't hurt anything.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from I
On 6/24/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
> I'm update with your changes this morning. I'm still seeing this at
> system shutdown. I modprobe drm,radeon and then unloaded them (no
> errors) then shut the system down.
With some more experiments, it only happens
I'm update with your changes this morning. I'm still seeing this at
system shutdown. I modprobe drm,radeon and then unloaded them (no
errors) then shut the system down.
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246 (2.6.12)
EIP is at sysdev_shutdown+0xbd/0xd2
eax: 6b6b6b47 ebx: f9a904c0
Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> --
an't
user swapable memory. There is a limited amout of kernel space memory
available.
> /Thomas
>
>
>
>
>
>
> /Thomas
>
>
>
>
>
>
>
>
>
>
>
--
Jon Smirl
[EMAIL PROTECTED]
On 6/22/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
> > Adding a new map type "so that you can tell them apart" doesn't make a
> > lot of sense to me. Won't two different maps have different offsets?
> > Isn't that enough to differentiate between them
On 6/22/05, Ian Romanick <[EMAIL PROTECTED]> wrote:
> Jon Smirl wrote:
> > I'll add a new map type DRM_VSHM. When initializing, the chip specific
> > driver needs to do something like this:
> >
> > if ((ret = drm_initmap(dev, 0, video_size, 0, _DRM_VSHM, 0)))
7;t always find
it. Length is always 4096.
I fixed some possible issues with the pm code but I still haven't
tracked the problem down.
Jun 22 10:18:56 jonsmirl kernel: Slab corruption: start=e466b000, len=4096
Jun 22 10:18:56 jonsmirl kernel: 000: 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
6b 6b 6b 6b 6b
On 6/22/05, Thomas Hellström <[EMAIL PROTECTED]> wrote:
> Hi.
>
> Jon Smirl wrote:
> On 6/21/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
>
>
> Second choice would be to make a new map type, DRM_VSHM. The specific
> driver would initmap the needed space a
on't care either way but
we only have a few flags and lots of map types.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforw
On 6/21/05, Jon Smirl <[EMAIL PROTECTED]> wrote:
> Second choice would be to make a new map type, DRM_VSHM. The specific
> driver would initmap the needed space at load time. The code
> implementing it would be identical to DRM_SHM, you just need another
> map type defined so
t; think about it..
I wish you luck in chasing this. I have wasted far, far, far too much
time fighting various people over the mode setting API. I have
thousands of lines of rejected patches sitting on my disk. I have
learned my lesson and the code I am currently writing calls fbdev.
--
Jon Smirl
those now since I wasted a year messing around trying
to add mode setting directly to DRM. I now realize that there are
vocal, powerful supporters behind using the fbdev code. I want to get
my server working so I am choosing the path of least resis
1 - 100 of 801 matches
Mail list logo
