[Linux-fbdev-devel] Re: [PATCH] Provide control of active VGA device on PCI systems

[Benjamin H. <be...@ke...>]

> > The problem is that on some cards (ATIs for example), the BIOS will
> > modify the image in RAM at c0000 and will put in there various infos,
> > like panel type, PLL infos, etc... that can't always be obtained from
> > the "hard" ROM (especially the panel infos). The driver (raeonfb or X,
> > strace X and see it mmap'ing /dev/mem at c0000...) need those things.
> 
> Shouldn't the driver safe that stuff at suspend time for use at resume time?  
> Or do we expect to be able to resume with different hw attached?

That's even more complicated :)

Honestly, I don't know for sure... I suppose the stuff should not change
accross suspend/resume. If the BIOS is used to re-post the on
board/primary card, it will just put the same stuff back in there. BIOS
wrappers that POST secondary cards shouldn't touch the real c0000 area
but some kind of shadow elsewhere. The driver POSTing code should
definitely return the modified shadow area btw...

Another problem with suspend/resume is to re-post the chip on resume,
which is quit a nightmare too. One would think it would be possible to
just re-run the BIOS to re-POST, but that will not always work. On
laptops, the video chip tend not to have any ROM attached (the video
BIOS is somewhere stuffed with the main BIOS image). You can find the
stuff at 0xc0000 but it doesn't necessarily contain the full video BIOS
code...

The ATI driver for example in Windows has a library that "knows" how to
re-POST gazillion of chips, but they can't/won't really opensource this
last I asked.

Ben.