Re: radeon-pre-2

[Jon Smirl <jonsmirl@gmail.com>]

The current DRM code doesn't suffer from resource conflicts anymore.
DRM now supports two modes: primary and stealth. In primary mode DRM
behaves like a Linux device driver should, it attaches to it's PCI
IDs, claims it's resources, registers with sysfs, generates hotplug
events, etc.

On the other hand, if vesafb or fbdev are loaded they will be attached
to all of the resources. DRM is blocked now, it can't load and attach
to things like a normal driver. In this case the DRM code reverts to
stealth mode.  Since vesa/fbdev is already attached to the DRM PCI IDs
DRM can't directly attach. Instead the module init code searches the
pci bus for DRM hardware. If DRM finds it's hardware DRM will install
itself and function without informing the kernel that it is there.

Before every one blows up and says how stupid this is, stealth mode
came first, it's what DRM originally did. It's the primary mode code
that is new. Over time the plan is to give DRM the ability to do
take_over_console() and handle printk's. DRM will also gain mode
setting capabilities. Once these capabilities are added the need for a
standalone fbdev will be eliminated. You will still have all of the
fbdev features, they will just be coming out of the integrated code
base, not separate drivers. This is not an attempt to build a new
fbdev, the existing fbdev code is simply being reused and modified to
work in conjunction with DRM.

Stealth and primary mode are transition tools. Once DRM subsumes fbdev
capabilities stealth mode will not be needed anymore and can be
removed.

This is a different strategy than building a base driver that claims
the resources and then loads vesafb, fbdev and DRM on top of the base.
The stealth mode scheme is a smoother transition to coordinating the
video drivers since it doesn't require a simultaneous change to all of
the video drivers. Stealth/primary mode in DRM is already implemented
and tested. Parts of it are already in the kernel and the rest is in
the pipeline.

On Fri, 10 Sep 2004 23:04:56 +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Gwe, 2004-09-10 at 14:31, Felix Kühling wrote:
> > The first region (frame buffer and apperture) is claimed (partially) by
> > vesafb, the second one (MMIO registers) is not claimed at all. I don't
> > see an obvious way to fix this.
> 
> Its already fixed in the stuff I'm working on. Given the list of all
> video devices its simply a matter of taking the mmio address and seeing
> who owns it. That gives you the PCI device so you now know what the VESA
> console is Linux pci_device terms. At that point VESA is attachable to
> the PCI device and so it can veto DRI attaches.
> 
> I've not addressed what occurs if you get an answer in the ISA window
> because for VESA2 allocations I don't think it can occur. If it does
> then Jon's code dealing with finding the live VGA route will handle it
> for most boxes. (Anyone using VESA video on an IBM summit can fix it
> themselves).
> 
> Alan
> 



-- 
Jon Smirl
jonsmirl@gmail.com