From: Benjamin H. <be...@ke...> - 2005-06-18 06:28:23
|
> Can you provide more detail here ? > > The current situation is that when fbdev is loaded the DRM falls back > to using the sysdev approach. If fbdev isn't loaded it takes direct > control as the DRM becomes a real PCI driver and accesses the PCI functions > for suspend/resume directly. > > What's the alternative to sysdev in the current model when fbdev is loaded ?? > > Also, can you explain the ordering issues ?? sysdev's are not in the normal bus dependency tree of the kernel. They are in a separate list. Their suspend routines are called very late in the suspend process, after every other normal device has already been suspended, and with interrupts off. Their resume, logically, is called very early on wakeup, with interrupts off. On a powermac for example, at the time your sysdev "suspend" is called, a radeon will already have been "shut" to D2 or D3 state by radeonfb. In general, you have no guarantee that the bus leading to your gfx chip is still even clocked at the time the sysdev suspend is called. sysdev's are really meant for very low level things, like the CPU frequency control, APICs, etc... I don't see any nice solution to the problem however. What I do to deal with AGP suspend and resume properly (because even that usually doesn't work properly as there is no proper ordering guarantee between an AGP bus driver and the driver for the card on the bus), is that I defined platform specific hacks that radeonfb & uninorth-agp use to pass around function pointers so that radeonfb is the one to decide when to shut AGP down & resume it. We may want to do something a bit nicer though, for DRM, in a similar vein though, maybe by having DRM use the fbdev core notifier mecanism and having fbdev drivers use it to broadcast suspend/resume to DRM... Ben |