On Tue, 2005-02-22 at 01:52 -0500, Jon Smirl wrote:
> Does the kernel need to keep a bit that says the device has been
> posted, don't do it again?
No. The kernel have no idea about what POSTing means in fact. That is
also driver specific.
> Should removing/inserting a driver cause a repost?
The
Does the kernel need to keep a bit that says the device has been
posted, don't do it again? Should removing/inserting a driver cause a
repost? I was going to add bit in pci_dev that tracks the reset status
so that it will persist across unloads. Do we have code to tell if
hardware needs a reset wit
On Tue, 22 Feb 2005 17:32:40 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> And even if we did, then we could have the vga "legacy" driver use the
> firmware loader to "boot" them. And again, you seem to dismiss all my
> other arguments...
I'm not dismissing them, I'm in agreement with
On Tue, 2005-02-22 at 01:05 -0500, Jon Smirl wrote:
> On Tue, 22 Feb 2005 16:13:36 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> > What we can/should provide, is a ncie helper to do the job once the
> > driver decides to have a go at it. I think userspace is the right
> > solution, s
On Tue, 2005-02-22 at 01:03 -0500, Jon Smirl wrote:
> On Tue, 22 Feb 2005 16:13:36 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> > On Mon, 2005-02-21 at 23:56 -0500, Alex Deucher wrote:
> > I think that the driver is the "chief" here and the one to know what to
> > do with the cards
On Tue, 22 Feb 2005 16:13:36 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> What we can/should provide, is a ncie helper to do the job once the
> driver decides to have a go at it. I think userspace is the right
> solution, similar to the firmware loader helpers, as I wrote earlier.
> T
On Tue, 22 Feb 2005 16:13:36 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> On Mon, 2005-02-21 at 23:56 -0500, Alex Deucher wrote:
> I think that the driver is the "chief" here and the one to know what to
> do with the cards it drives. It can detect a non-POSTed card and deal
> with it.
On Tue, 22 Feb 2005 05:13:07 + (GMT), James Simmons
<[EMAIL PROTECTED]> wrote:
> > > 4. Which comes to the next point. The code is not modular enough. Take
> > >drm_bufs.c. Everything is a ioctl function. This has a few
> > > disadvantages.
> > >One is the fbdev layer couldn't just lin
Dave Airlie writes:
> How it has to work, is taking a current DRI 32-bit binary, build a drm
> that should support 64-bits.. see does it work with the current 32-bit
> one... then write a Mesa patch that supports 64-bits and make it work on
> the drm you just made... also take a 64-bit pure drm an
> > 1. Lots of work that would take lots of time. To my knowledge all fbdev
> >developers work in there spare free time. No one does this for a
> >living.
>
> So do most of the drm developers, I know I do and Jon Smirl does, and
> Eric Anholt does and I think us three have been the larges
On Tue, 22 Feb 2005 15:46:03 +1100, Dave Airlie <[EMAIL PROTECTED]> wrote:
> >
> > 1. Lots of work that would take lots of time. To my knowledge all fbdev
> >developers work in there spare free time. No one does this for a
> >living.
>
> So do most of the drm developers, I know I do and Jo
On Mon, 2005-02-21 at 23:56 -0500, Alex Deucher wrote:
> another advantage of the emulator would be that "PC" vga cards could
> be used in non-x86 platforms, which I'm sure would be quite popular...
That's implied indeed... though Jon approach would require the common
code to "know" that we are o
On Mon, 2005-02-21 at 23:42 -0500, Jon Smirl wrote:
> On Tue, 22 Feb 2005 14:12:48 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> > It's up to each driver to detect wether it's card need to be POSTed or
> > not. Anything else would mean infinite breakage.
>
> Your approach is that it
>
> 1. Lots of work that would take lots of time. To my knowledge all fbdev
>developers work in there spare free time. No one does this for a
>living.
So do most of the drm developers, I know I do and Jon Smirl does, and
Eric Anholt does and I think us three have been the largest
contribu
On Tue, 22 Feb 2005 14:12:48 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
>
> > Ben, since I'm not getting any help on LKML maybe you can answer this.
> > Secondary cards needs reset. After looking at a bunch of fbdev drivers
> > their code assumes the card has been reset when their pr
On Tue, 22 Feb 2005 14:12:48 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> It's up to each driver to detect wether it's card need to be POSTed or
> not. Anything else would mean infinite breakage.
Your approach is that it is a per driver problem. I was taking a
different tack and look
> > Do you see any other solution to this then?
>
> You could build this inside of the DRM framework which already
> supports DMA and memory management. DRM doesn't really know anything
> about 3D, it just knows how to send commands to the graphics hardware.
> It's the mesa layer in user space th
> Ben, since I'm not getting any help on LKML maybe you can answer this.
> Secondary cards needs reset. After looking at a bunch of fbdev drivers
> their code assumes the card has been reset when their probe() function
> runs. So this means that we have to run the VBIOS reset before probe
> is cal
On Mon, 21 Feb 2005, Adam K Kirchhoff wrote:
FYI, I've now tried neverputt in a window, instead of fullscreen, and I'm
getting the same lockups as I was previously getting (full lockups, including
mouse, requiring me to ssh in a reboot).
It finally occurred to me to check dmesg:
[drm:radeon_cp
On Mon, 21 Feb 2005 20:34:36 -0500, Adam Jackson <[EMAIL PROTECTED]> wrote:
> On Monday 21 February 2005 20:17, Jon Smirl wrote:
> > I have all of the pieces needed to build this. I just can't figure out
> > where to hook it into the kernel. Worst case is that I have to go
> > modify 75 framebuffer
On Monday 21 February 2005 20:17, Jon Smirl wrote:
> I have all of the pieces needed to build this. I just can't figure out
> where to hook it into the kernel. Worst case is that I have to go
> modify 75 framebuffer drivers to explicitly support reset.
Wandering off-topic here...
You keep saying
On Tue, 22 Feb 2005 08:04:14 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> Hardware support, radeonfb multihead, etc... is all trivial to do once
> we have proper infrastructure. fbdev need a bit of overhaul in it's
> current state (at least proper mecanism for picking where to allocat
On Mon, 2005-02-21 at 16:11 -0500, Alex Deucher wrote:
> If we are going to start "fresh" so to speak, why even mess with
> mergedfb in the new fb/drm driver? it would make more sense to just
> update the 2d and 3d engine offsets to point to whichever framebuffer
> is "active." for dualhead the
>
> First off, has anyone updated the patch lately?
Nope, I think it needs to go back to the drawing board...
The biggest problem with SuSEs patch is that is was written by the looks
of it to cover the DRM and Mesa making changes to both to achieve the
solution, this isn't a way to acheive backwa
On Tue, 22 Feb 2005 08:04:14 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> On Mon, 2005-02-21 at 14:08 -0500, Jon Smirl wrote:
> > On Mon, 21 Feb 2005 19:07:55 +1100, Benjamin Herrenschmidt
> > <[EMAIL PROTECTED]> wrote:
> > > That leads to one missing piece to ultimately merge the fb
FYI, I've now tried neverputt in a window, instead of fullscreen, and
I'm getting the same lockups as I was previously getting (full lockups,
including mouse, requiring me to ssh in a reboot).
It finally occurred to me to check dmesg:
[drm:radeon_cp_dispatch_swap] *ERROR* Engine timed out bef
On Mon, 2005-02-21 at 14:08 -0500, Jon Smirl wrote:
> On Mon, 21 Feb 2005 19:07:55 +1100, Benjamin Herrenschmidt
> <[EMAIL PROTECTED]> wrote:
> > That leads to one missing piece to ultimately merge the fb layer
> > (mode setting) and the kernel DRM (command processing), which is a video
> > memory
On Mon, 21 Feb 2005 19:07:55 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
> That leads to one missing piece to ultimately merge the fb layer
> (mode setting) and the kernel DRM (command processing), which is a video
> memory manager that is independant from the client (X server).
Now y
Hi Vladimir,
On Mon, 21 Feb 2005, John Clemens wrote:
give it a go on my fanless 9600se (RV350 AP).
How much memory do you have ? What kind of CPU and motherboard ?
Duron 1.8G, 256MB ddr, old(ish) via km266 motherboard in a shuttle sk41g.
Gentoo. The card has 128Mb ram.
- glxinfo states r300 DRI
Hi John,
Thank you for testing :)) More below.
On Mon, 21 Feb 2005, John Clemens wrote:
So I've been lurking for a while following the r300 work and decided to give
it a go on my fanless 9600se (RV350 AP).
How much memory do you have ? What kind of CPU and motherboard ?
- glxinfo states r300
>From a google cached copy of the howto. The idsoftware ftp site seems to be
>gone, but I'm certain you can find the latest point release around.
Native Linux Games: Quake 3 Arena-HowTo
Author: cairon
Published: 2004-02-20
Read 15026 times
Size 6.35 KB
Author: cairon
Language: English
I have been looking through Egbert Eich's patch to add 32-bit
compatibility code for the DRM ioctls on 64-bit platforms.
First off, has anyone updated the patch lately?
The patch adds an extra field to the drm_map_t to handle the problem
of the `handle' field being basically a kernel virtual addr
On Sun, 2005-02-20 at 18:42 -0500, Jon Smirl wrote:
> On Mon, 21 Feb 2005 10:00:04 +1100, Dave Airlie <[EMAIL PROTECTED]> wrote:
> > It's also a bad hack that the current miniglx sample_server has to be
> > run then the X server, current miniglx I don't think supports
> > rendering in its "server"
33 matches
Mail list logo
