New kernel API for ROMs

This patch provides a new kernel API for access ROMs from device
drivers. If you're working on a driver that uses the ROM (most video
drivers) please give this patch a try and send some feedback/bugs.

pci_map_rom() - map the rom and provide virtual address, transparently
return shadow/copy if needed. Normal drivers call this

pci_map_rom_copy() - same as pci_map_rom except the ROM will copied,
future reads of ROM will use copy. Hardware with minimal decoding calls
use this

pci_unmap_rom() - release the ioremap if there is one

The ROMs also appear in sysfs and you can use hexdump to see them.

If the Radeon ROM is all FFFF. Load a radeon device driver and it will
appear. Radeon cards have a bug that loading the driver will fix.

=====
Jon Smirl
jonsmirl@yahoo.com


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

On Fri, 6 Aug 2004, Jon Smirl wrote:

This patch provides a new kernel API for access ROMs from device
drivers. If you're working on a driver that uses the ROM (most video
drivers) please give this patch a try and send some feedback/bugs.

pci_map_rom() - map the rom and provide virtual address, transparently
return shadow/copy if needed. Normal drivers call this

pci_map_rom_copy() - same as pci_map_rom except the ROM will copied,
future reads of ROM will use copy. Hardware with minimal decoding calls
use this

pci_unmap_rom() - release the ioremap if there is one

The ROMs also appear in sysfs and you can use hexdump to see them.

If the Radeon ROM is all FFFF. Load a radeon device driver and it will
appear. Radeon cards have a bug that loading the driver will fix.

+unsigned char *
+pci_map_rom_copy(struct pci_dev *dev, size_t *size) {
+	struct resource *res = &dev->resource[PCI_ROM_RESOURCE];
+	unsigned char *rom;
+
+	rom = pci_map_rom(dev, size);
+	if (!rom)
+		return NULL;
+
+	if (res->flags & (PCI_ROM_COPY | PCI_ROM_SHADOW))
+		return rom;
+
+	res->start = (unsigned long)kmalloc(*size, GFP_KERNEL);

What's the maximum size of a PCI ROM? Larger than kmalloc() can handle?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


-------------------------------------------------------
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

Maximum size of a standard PCI ROM is 128KB.  On non-x86 platforms the
code will pick the length up from the size of the PCI window. That
window has no limit.

On the other hand, map_rom_copy is only called by the device driver for
a board that has minimal PCI decoding. The PCI spec allows the address
decoding for something like the ROM and framebuffer to be shared. A few
vendors have implemented this and the result is that you can't read the
ROM and framebuffer at the same time. This is why you need to make the
copy.  We only know of a couple PCI boards that have implemented this.

This memory is not performance critical and can be swapped, is there a
better way to allocate it?

--- Geert Uytterhoeven <geert@linux-m68k.org> wrote:

On Fri, 6 Aug 2004, Jon Smirl wrote:

quoted

This patch provides a new kernel API for access ROMs from device
drivers. If you're working on a driver that uses the ROM (most

video

quoted

drivers) please give this patch a try and send some feedback/bugs.

pci_map_rom() - map the rom and provide virtual address,

transparently

quoted

return shadow/copy if needed. Normal drivers call this

pci_map_rom_copy() - same as pci_map_rom except the ROM will

copied,

quoted

future reads of ROM will use copy. Hardware with minimal decoding

calls

quoted

use this

pci_unmap_rom() - release the ioremap if there is one

The ROMs also appear in sysfs and you can use hexdump to see them.

If the Radeon ROM is all FFFF. Load a radeon device driver and it

will

quoted

appear. Radeon cards have a bug that loading the driver will fix.

quoted

+unsigned char *
+pci_map_rom_copy(struct pci_dev *dev, size_t *size) {
+	struct resource *res = &dev->resource[PCI_ROM_RESOURCE];
+	unsigned char *rom;
+
+	rom = pci_map_rom(dev, size);
+	if (!rom)
+		return NULL;
+
+	if (res->flags & (PCI_ROM_COPY | PCI_ROM_SHADOW))
+		return rom;
+
+	res->start = (unsigned long)kmalloc(*size, GFP_KERNEL);

What's the maximum size of a PCI ROM? Larger than kmalloc() can
handle?

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
geert@linux-m68k.org

In personal conversations with technical people, I call myself a
hacker. But
when I'm talking to journalists I just say "programmer" or something
like that.
							    -- Linus Torvalds


-------------------------------------------------------
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
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

=====
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

Il Sat, Aug 07, 2004 at 07:59:29AM -0700, Jon Smirl ha scritto: 

*This message was transferred with a trial version of CommuniGate(tm) Pro*
Maximum size of a standard PCI ROM is 128KB.

This is the maximun that kmalloc can allocate.

On non-x86 platforms the code will pick the length up from the size of
the PCI window. That window has no limit.

Hum, this is bad... what's the tipical size of video ROMs?

On the other hand, map_rom_copy is only called by the device driver for
a board that has minimal PCI decoding. The PCI spec allows the address
decoding for something like the ROM and framebuffer to be shared. A few
vendors have implemented this and the result is that you can't read the
ROM and framebuffer at the same time. This is why you need to make the
copy.  We only know of a couple PCI boards that have implemented this.

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.


-------------------------------------------------------
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

On Sad, 2004-08-07 at 17:37, Kronos wrote:

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).

You can also read it out to userspace in a loop in chunks thus needing
only a single 4K page or you could mmap it



-------------------------------------------------------
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
--

--- Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

On Sad, 2004-08-07 at 17:37, Kronos wrote:

quoted

You can check and see if the ROM is really big and use vmalloc, if

not

quoted

then you use kmalloc (if I remember correctly my radeon has a 4KB

ROM -

quoted

vmalloc would be overkill).

You can also read it out to userspace in a loop in chunks thus
needing
only a single 4K page or you could mmap it

We have to copy the whole thing when the driver tells us to. After we
copy the ROM the hardware is going to use the address decoder for
something else. There is no safe way to get back to the ROM again other
than to unload the device driver.

=====
Jon Smirl
jonsmirl@yahoo.com


		
__________________________________
Do you Yahoo!?
Y! Messenger - Communicate in real time. Download now. 
http://messenger.yahoo.com


-------------------------------------------------------
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

On Sad, 2004-08-07 at 18:40, Jon Smirl wrote:

We have to copy the whole thing when the driver tells us to. After we
copy the ROM the hardware is going to use the address decoder for
something else. There is no safe way to get back to the ROM again other
than to unload the device driver.

Good point on mmap not working yes. We can still copy it in 4K chunks to
userspace though not keep it in kernel. The rom boot stuff in the design
is in user space.



-------------------------------------------------------
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

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:

quoted

This memory is not performance critical and can be swapped, is

there a

quoted

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
--