From: Jon Smirl <jonsmirl@yahoo.com>
To: Kronos <kronos@people.it>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
dri-devel <dri-devel@lists.sourceforge.net>,
fb-devel <linux-fbdev-devel@lists.sourceforge.net>
Subject: Re: [Linux-fbdev-devel] New kernel API for ROMs
Date: Sat, 7 Aug 2004 09:54:57 -0700 (PDT) [thread overview]
Message-ID: <20040807165457.22743.qmail@web14921.mail.yahoo.com> (raw)
In-Reply-To: <20040807163733.GD3714@dreamland.darkstar.lan>
All of the video ROMs I have are 48KB - 64KB in size. But, the copy
code is only triggered by the driver for older PCI cards with minimal
decoding. I am unaware of any video cards with this problem so they
won't make the copy. The only cards I seem to recall having this
problem are some older QLogic disk controllers. We should fix this
alloc as best as we can but most normal users will never see it.
Another solution I'll add is a pci_disable_rom() call that will make
the ROM disappear from sysfs. This would give the minimally decoded PCI
board the option of avoiding the copy and just disabling it. The copy
only needs to happen if user space apps are going to use the ROM
contents after the device driver has loaded.
To get the true size of your ROM look at the front of it for 55 AA the
third byte is then len / 512. Fourth byte is the JMP for the reset
vector.
Note that the code does not copy SHADOW ROMs. These ROMs have already
been copied by the system BIOS to C0000. The code uses the existing
copy.
--- Kronos <kronos@people.it> wrote:
> > This memory is not performance critical and can be swapped, is
> there a
> > better way to allocate it?
>
> Problem is that kmalloc may be unable to find many contiguous memory
> pages.
>
> You can check and see if the ROM is really big and use vmalloc, if
> not
> then you use kmalloc (if I remember correctly my radeon has a 4KB ROM
> -
> vmalloc would be overkill).
>
> Luca
> --
> Home: http://kronoz.cjb.net
> Ci sono due cose che l'uomo non puo` nascondere:
> essere ubriaco ed essere innamorato.
>
=====
Jon Smirl
jonsmirl@yahoo.com
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail
-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source Technology
Group. Come see the changes on the new OSTG site. www.ostg.com
--
prev parent reply other threads:[~2004-08-07 16:54 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-06 21:21 New kernel API for ROMs Jon Smirl
2004-08-07 13:16 ` Geert Uytterhoeven
2004-08-07 14:59 ` Jon Smirl
2004-08-07 16:37 ` Kronos
2004-08-07 16:09 ` [Linux-fbdev-devel] " Alan Cox
2004-08-07 17:40 ` Jon Smirl
2004-08-07 18:51 ` Alan Cox
2004-08-07 16:54 ` Jon Smirl [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040807165457.22743.qmail@web14921.mail.yahoo.com \
--to=jonsmirl@yahoo.com \
--cc=dri-devel@lists.sourceforge.net \
--cc=geert@linux-m68k.org \
--cc=kronos@people.it \
--cc=linux-fbdev-devel@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).