-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
quoted
pushl $0
# Kill any dangerous flags
quoted
popfl
movl real_magic - wakeup_code, %eax
cmpl $0x12345678, %eax
jne bogus_real_magic
testl $1, video_flags - wakeup_code
jz 1f
lcall $0xc000,$3
The call to 0xC000:0x0003 is the entry point to POST the card. However
for PCI cards you need to make sure that AX is loaded with the
bus, slot
and function for the card that is being POST'ed. It will pass
this value
to the PCI BIOS Int 0x1A functions in order to find itself, so
if this is
not set many BIOS'es will not work.
The rest of the code you have above seems superfluous to me as we have
never needed to do that. Then again we boot the card using the BIOS
emulator, which is different because it runs within a
protected machine
state.
Have you taken a look at the X.org code? They have code in
there to POST
the video card also (either using vm86() or the BIOS emulator).
I have done some experiments with this video post stuff.
I think this should be done using x86 emulator rather than doing
in real mode. The reason being, with an userlevel emulator we can call
it at different times during resume. The current real mode videopost
does
it before the driver has restored the PCI config space. Some systems
(mostly the ones with Radeon card) requires this to be done after
PCI config space is restored. With a userspace emulator, we can
call it at various places during the driver restore.
I have seen the SciTech's x86 emulator in X.org. I could seperate it out
from X into a stand alone application that does x86 emulation. I use it
to get
the video back on my laptop (which has radeon card), by calling this
user level
emulator using usermodehelper call. I hope we will have x86 emulator
sitting in
a standard place in userspace. That way we can use it in driver restore
and
solve the S3 video restore problem in a more generic way.
Thanks,
Venki
Hi!
quoted
The rest of the code you have above seems superfluous to me as we have
never needed to do that. Then again we boot the card using the BIOS
emulator, which is different because it runs within a
protected machine
state.
Have you taken a look at the X.org code? They have code in
there to POST
the video card also (either using vm86() or the BIOS emulator).
I have done some experiments with this video post stuff.
I think this should be done using x86 emulator rather than doing
in real mode. The reason being, with an userlevel emulator we can call
it at different times during resume. The current real mode videopost
does
Actually Ole Rohne has patch that allows you to call real mode any
time you want.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
"Pallipadi, Venkatesh" [off-list ref] wrote:
I have done some experiments with this video post stuff. I think
this should be done using x86 emulator rather than doing in real
mode. The reason being, with an userlevel emulator we can call it
at different times during resume. The current real mode videopost
does it before the driver has restored the PCI config space. Some
systems (mostly the ones with Radeon card) requires this to be
done after PCI config space is restored. With a userspace
emulator, we can call it at various places during the driver
restore.
I have seen the SciTech's x86 emulator in X.org. I could seperate
it out from X into a stand alone application that does x86
emulation. I use it to get the video back on my laptop (which has
radeon card), by calling this user level emulator using
usermodehelper call. I hope we will have x86 emulator sitting in a
standard place in userspace. That way we can use it in driver
restore and solve the S3 video restore problem in a more generic
way.
We already have all this code completely separate from X and would
release this as part of the Video Boot package for Linux. The kernel
module is one part of it, but the code can be compiled as a stand alone
user land program as well (SNAPBoot we call it right now).
Regards,
---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl