Re: [Linux-fbdev-devel] DRM and pci_driver conversion

[Jon Smirl]

I don't think DRM drivers are doing things correctly yet. DRM is missing the
code for marking PCI resources as being in use while DRM is using them. This
could lead to problems with hotplug.  XFree is also mapping PCI ROMs in without
informing the kernel and that can definitely cause problems. I'm looking at
adding the resource marking code right now.

I am not a fan of having two device drivers (DRM and FB) trying to control the
same piece of hardware, but if we are going to insist on doing it we need to do
it in a way where both drivers work and mark the resources in use independent
of the order in which they are loaded.

So I think we need to implement both the old and new PCI ID schemes and
fallback to the
old one if the other driver is present. DRM also needs to add code marking
resources in use which will also conflict with framebuffer. 

It would flow something like this:
new style probe
if (new probe has device)
   mark resources in use
else
   do old style probe (make sure card is really there)
   assume other driver has marked resources in use

The framebuffer drivers that have DRM parallels would need to implement the
same code. That way it won't matter what order things get loaded.

A second possibility would be to implement a tiny stub for just attaching to
the PCI ID and resources. Then framebuffer and DRM could both share the stub.

A third scheme would disallow mixing DRM and FB. A DRM-console module would be
written to replace FB console. Accelerated console could be written using DRM
since it already knows about the 3D hardware. This would fix the problem with
radeonfb mapping upto 256K of memory into the 1GB kernel space and pushing all
the page tables high. Everything would be coordinated in a single drive so
there is no state saving on VT switch problem either.

--- Eric Anholt <eta@xxxxxxxxxx> wrote:
> On Thu, 2003-10-23 at 12:04, Kronos wrote:
> > Il Mon, Oct 20, 2003 at 07:31:56PM -0700, Eric Anholt ha scritto: 
> > > I recently committed a change to the DRM for Linux in DRI CVS that
> > > converted it to use pci_driver and that probe system.  Unfortunately,
> > > we've found that there is a conflict between the DRM now and at least
> > > the radeon framebuffer.  Both want to attach to the same device, and
> > > with pci_driver, the second one to come along doesn't get probe called
> > > for that device.  Is there any way to mark things shared, or in some
> > > other way get the DRM to attach to a device that's already attached to,
> > > in the new model?
> > 
> > AFAIK no,  pci_dev only  stores one pointer  to the  driver. Two drivers
> > fiddling with the same hw can be dangerous. What will happen if radeonfb
> > starts using hw  accel, touching registers without  DRM knowing it? What
> > is (IMHO) needed is a common  layer that works with hardware and exposes
> > an interface to both radeonfb and DRM. I think that Jon Smirl is working
> > on something like this.
> 
> Apparently loading DRM after radeonfb is okay.  Loading radeonfb after
> DRM is okay as long as the DRM is not in use.  For some cards, the fb
> after the DRM would still be okay (sis, tdfx at the moment, for
> example), but it isn't the case on radeon, apparently.  Other than that
> there aren't any issues I know of.
> 
> I've moved the Linux DRM to old-style probing as pci.txt described,
> which hopefully restores the ability of fb and drm to coexist as well as
> they have in the past.  I hope some linux developers can get this all
> done right so that the two can coexist better.
> 
> -- 
> Eric Anholt                                eta@xxxxxxxxxx          
> http://people.freebsd.org/~anholt/         anholt@xxxxxxxxxxx
> 
> 

=====
Jon Smirl
jonsmirl@xxxxxxxxx

__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/