>
> Is it OK to use request_region() for claiming memory mapped I/O registers?
No. MMIO has nothing to see with I/O ports. They are different spaces
(different encodings of cycle type on the PCI bus for example), so they
can't even conflict.
Perhaps a /proc/mmioareas (choose the name you want, I can't find anything
nice right now) should be added. OTOH, PCI should guarantee by design
that no conflict can occur, if you forget the fact most PCI BIOSes are
buggy and some device do not comply with the PCI spec (some do not even
correctly implement the first 0x10 bytes of the configuration space
header).
> The specific cases I have in mind are frame buffer and MMIO regions used by
> frame buffer devices. Furthermore this would allow us to get rid of the ugly
> zorro_{config,unconfig}_board() calls in the drivers for Zorro bus devices.
>
> Is there any good reason why
>
> | typedef struct resource_entry_t {
> | u_long from, num;
> ^^^^^^
> | const char *name;
> | struct resource_entry_t *next;
> | } resource_entry_t;
>
> while get_ioport_list() uses `%04lx' to print the claimed regions? This makes
> me think I should use request_region() for `PC' I/O port regions only.
>
> If we can use request_region() for claiming MMIO, the format specifiers have to
> become `%p', so the full 32 (or 64) bit addresses are dumped.
At the very least a different list of resources should be created for
MMIO. Also this type of resource structure might perhaps be designed to
nicely handle the case where addresses are not the same on both sides of
the bridges (like PreP MMIO and 64 bit machines). In any case, it is very
probably 2.3 stuff...
Greetings,
Gabriel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/